Server-Sent Events（サーバセントイベンツ、略称SSE）は、サーバからブラウザへ片方向にストリーミング配信を行うためのWeb標準技術です。HTML5の一部としてWHATWG／W3Cで策定され、現在はHTML Living Standardの「Server-sent events」セクションで定義されています。通常のHTTPレスポンスを開いたまま、text/event-streamというContent-Typeでテキストイベントを継続的に送り続ける仕組みで、ブラウザ側ではEventSource APIを使うだけで簡単に購読できます。WebSocketと比較してプロトコルが単純であり、HTTPの認証・キャッシュ・プロキシ機構をそのまま利用できる点が大きな魅力で、通知・実況・ダッシュボード・LLMストリーミング応答などの片方向シナリオで広く活用されています。
この記事の目次
- SSEを支える3つの基本要素
- SSEの典型的な処理フロー
- SSE運用で押さえる注意点
- SSEとWebSocketの使い分け
- まとめ
SSEを支える3つの基本要素
SSEのレスポンスはContent-Type: text/event-streamで配信され、本文は「data: 」「event: 」「id: 」「retry: 」といった行ベースのテキスト形式で構成されます。1つのメッセージは空行で区切られ、複数行のdataを並べることで改行を含むペイロードも表現できます。eventフィールドにイベント名を指定すると、クライアントは特定の名前のイベントだけを購読できるため、通知種別ごとに購読ロジックを分けることが可能です。
ブラウザ側ではEventSource APIが標準で提供されており、new EventSource("/events") とするだけで自動再接続つきの購読が始まります。途中で接続が切れても、最後に受信したidを保持しておき、再接続時にLast-Event-IDヘッダで送り返すことで「どこから再開すべきか」をサーバに伝えられます。retryフィールドでは再接続までの待機時間（ミリ秒）を指定でき、サーバ側から再接続戦略を制御できる柔軟性も備えています。
SSEの典型的な処理フロー
SSEを使ったアプリケーションは、まずクライアントがGETリクエストでサーバの/eventsエンドポイントへ接続するところから始まります。サーバは200 OKでtext/event-streamヘッダを返し、Connection: keep-aliveを維持したままレスポンスボディの書き込みを継続します。ハートビートとして定期的にコメント行「: keep-alive」を送ることで、プロキシによるアイドル切断を防ぐのが一般的なテクニックです。
サーバはイベント発生のたびに、event・data・idフィールドを並べたテキストブロックをflushして送信します。クライアントはonmessageまたはaddEventListener("イベント名")で受信し、JSON.parseしてアプリケーションに反映します。切断が発生するとEventSourceは自動的に再接続を試み、保存していたLast-Event-IDをヘッダに付与するため、サーバはそのIDより新しいイベントだけを再送することで重複なく続きを配信できます。
SSE運用で押さえる注意点
SSEを本番運用する際は、ブラウザの同一オリジンに対するHTTP接続数の上限が問題になります。HTTP/1.1では同一オリジンあたり最大6接続程度に制限されており、複数タブで同じSSEを開くと簡単に枯渇します。HTTP/2やHTTP/3を有効にすることで多重化が効き、この制約は実質的に解消できるため、SSEを本格採用するならHTTP/2以上の利用がほぼ前提となります。
また、Nginxなどのプロキシはデフォルトで応答をバッファリングするため、proxy_buffering offなどの設定でストリーミングを通すように調整する必要があります。クライアント側のアイドル切断を防ぐためには、サーバから15〜30秒間隔でコメント行のハートビートを送るのが定石です。認証はSSE自体には組み込まれていないので、CookieやAuthorizationヘッダなどHTTP層の仕組みをそのまま使い、未認証接続は早期に切断する設計を取ります。Last-Event-IDをどう生成し、どう保持するかについては設計段階で統一しておかないと、再接続時に重複や欠落が発生するため注意が必要です。
SSEとWebSocketの使い分け
SSEとWebSocketはどちらもリアルタイム通信を実現しますが、最適な用途が異なります。SSEは「サーバからクライアントへの片方向ストリーミング」に特化しており、HTTPの上にそのまま乗るためファイアウォール・認証・キャッシュ・ロギングといった既存のWebインフラと相性が抜群です。通知・実況スコア・ライブダッシュボード・LLMトークンストリーミングなど、サーバが一方的にイベントを流し続ける用途には最適な選択肢です。
一方、WebSocketはクライアントからの送信も同等に行える完全な双方向通信を実現し、バイナリも自由に扱えます。チャットやマルチプレイヤーゲーム、共同編集のようにクライアント側からも頻繁にメッセージを送るアプリケーションではWebSocketの方が自然です。ChatGPTのようなLLMサービスがSSEでトークンストリームを返すのは典型例で、簡潔さ・既存インフラとの互換性・自動再接続といったSSEのメリットを活かしているといえます。
まとめ
Server-Sent Eventsは、テキストベースのHTTPレスポンスをそのまま延長する形で、サーバからクライアントへ片方向のリアルタイム配信を実現する標準技術です。EventSource APIによる簡潔な購読、自動再接続、Last-Event-IDを使った再開といった機能を、追加のプロトコルなしに利用できます。通知・実況・ダッシュボード・LLMストリーミングなど、片方向で十分なシナリオでは、WebSocketよりもシンプルで運用しやすい選択肢として強い存在感を放っています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント