API設計

SSE（Server-Sent Events）さーばーせんといべんつ

リアルタイム通信イベントストリームHTTPプッシュ通知WebSocketロングポーリング

SSEって何？

簡単に言うとこんな感じ！

サーバーから「新しい情報が来たよ！」って一方通行でリアルタイムに通知してくれる仕組みだよ。株価表示やChatGPTの回答が少しずつ流れてくるあの感じ、まさにSSEが使われてるんだ！

SSE（Server-Sent Events）とは

SSE（Server-Sent Events） とは、Webサーバーからブラウザ（クライアント）に向けて、一方向でリアルタイムにデータを送り続ける通信の仕組みです。通常のHTTP通信は「ブラウザが聞いて、サーバーが答える」の一往復で終わりますが、SSEでは一度接続を開いたら、サーバーが好きなタイミングで次々とデータをプッシュし続けられます。

特徴的なのは、既存のHTTPプロトコルをそのまま使う点です。専用のプロトコルや複雑な設定は不要で、text/event-stream という特別なContent-Typeを使うだけで動作します。また、接続が切れた場合に自動的に再接続する機能がブラウザ標準で備わっており、実装がシンプルで信頼性も高いのが特長です。

実務では、ChatGPTのようなAIチャットの回答ストリーミング、株価・為替のリアルタイム更新、ニュースフィードの自動更新、進捗バーの状態通知など、「サーバーから継続的に情報を流したい」シーンで広く使われています。

SSEの仕組みと構造

SSEは、クライアントが一度HTTPリクエストを送ったあと、サーバーが接続を切らずにデータを流し続けるという構造です。

役割	動作
クライアント（ブラウザ）	`EventSource` APIで接続を開く。以降は受信専用
サーバー	`Content-Type: text/event-stream` で応答し、データを随時送信
データ形式	`data: メッセージ内容\n\n` の形式（テキストベース）
切断・再接続	ブラウザが自動的に再接続（再接続間隔も指定可能）

イベントストリームのデータ形式

サーバーが送るデータは非常にシンプルなテキスト形式です。

data: {"message": "Hello!"}

event: stockUpdate
data: {"ticker": "AAPL", "price": 182.5}
id: 42

: これはコメント行（ハートビートに使われる）

retry: 3000

各フィールドの意味：

フィールド	意味
`data:`	送信するデータ本体（JSON文字列も可）
`event:`	イベントの種類名（省略時は `message`）
`id:`	イベントID（再接続時の続き位置に使う）
`retry:`	再接続までの待機ミリ秒
`:`	コメント（接続維持のハートビートに活用）

クライアント側のJavaScript実装例

// たった数行で受信できる！
const source = new EventSource('/api/stream');

source.onmessage = (event) => {
  console.log('受信:', event.data);
};

source.addEventListener('stockUpdate', (event) => {
  const data = JSON.parse(event.data);
  console.log('株価更新:', data.price);
});

source.onerror = () => {
  console.log('切断（自動再接続します）');
};

歴史と背景

2004年頃 — Ajaxが普及し始め、「ページを丸ごと更新せずにデータを取得したい」ニーズが高まる
2006年頃 — ロングポーリング（サーバーが意図的に応答を遅らせ、更新があったら返す手法）が普及。ただし実装が複雑で負荷も高かった
2008年 — Ian Hickson（HTML5の主要設計者）がSSEの仕様を提案。HTMLのLiving Standardに組み込まれる
2009年 — WebSocket も同時期に提案され、双方向通信の選択肢として登場
2011年 — HTML5の一部として主要ブラウザ（Chrome・Firefox・Safari）がSSEをサポート開始
2012年 — W3CがSSEを正式勧告として公開
2022年〜現在 — ChatGPTをはじめとする生成AIのストリーミング応答にSSEが採用され、一気に注目度が上昇。OpenAI APIもSSEベースのストリーミングを採用

WebSocket・ロングポーリングとの比較

リアルタイム通信を実現する手法は複数あります。用途に合わせた選択が重要です。

方式通信方向プロトコル主な用途 SSE Server-Sent Events サーバー → クライアント（一方向） HTTP/1.1以上 AIストリーミング、ニュースフィード WebSocket ws:// / wss:// 双方向専用プロトコル（HTTPからアップグレード）チャット、オンラインゲームロングポーリング Long Polling 都度リクエスト HTTP/1.1 古いシステムとの互換性が必要な場合通常ポーリング Polling 定期リクエスト HTTP シンプルな状態確認、低頻度の更新

SSEを選ぶべきシーン・避けるべきシーン

✅ SSEが向いているケース

サーバーからクライアントへの一方向の通知で十分なとき
生成AIの回答ストリーミング（テキストを少しずつ表示）
株価・スポーツスコアなどのリアルタイム更新表示
HTTP/2環境でスケールさせたいとき（多重化が効く）
ファイアウォールやプロキシ越しの通信（HTTPなので通りやすい）

❌ SSEが向いていないケース

クライアントからもリアルタイムにデータを送りたい（チャット・ゲームなど）→ WebSocket を使う
バイナリデータ（画像・音声）を効率よく送りたい → WebSocket が適切
IE11など古いブラウザのサポートが必要な場合（SSEは非対応）

規格・RFC番号	内容
WHATWG Living Standard	SSEの公式仕様（Server-Sent Events）。W3C勧告ではなくWHATWG管理
RFC 7230	HTTP/1.1の基本仕様。SSEが依拠するプロトコル
RFC 9113	HTTP/2の仕様。SSEとの組み合わせで多重化が可能
RFC 6455	WebSocketプロトコルの仕様。SSEの比較対象