単方向リアルタイムデータ配信のためのServer-Sent Events（SSE）アーキテクチャ
SSEはHTTP上の単方向イベント形式とEventSourceの再接続機能を提供しますが、履歴・再送・完全な配信はアプリケーション側の設計が必要です。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
Server-Sent Events（SSE）の形式とEventSourceの動作
Server-Sent Events（SSE）は、ブラウザーのEventSource APIでHTTP応答本文をUTF-8のイベントストリームとして受信する方式です。WebSocketと異なり、APIはサーバーからクライアントへのイベント受信を中心に設計されています。規格が定めるのはイベント形式とクライアント動作であり、サーバー側の履歴保存や復旧サービスは含みません。
応答のメディアタイプはtext/event-streamです。data:、event:、id:、retry:などを行ごとに解釈し、空行でイベントを通知します。コロンで始まる行はコメントです。再接続時には、受信済みの最後のIDをLast-Event-IDで送ることがありますが、履歴を保持し、カーソルを解釈して再送する処理はアプリケーション側に必要です。Accept: text/event-streamはユーザーエージェントが設定してよいヘッダーで、EventSourceのコンストラクターから任意のリクエストヘッダーを指定する機能ではありません。
専門家の視点：再接続カーソルとイベント復元は別の機能
AblyのAmber Dawson（Content Lead）は、LLMストリーミングの実装記事で、Last-Event-IDは再接続時に最後のイベントIDを知らせる仕組みであり、履歴の保存や再送そのものではないと整理しています。欠落分を届けるには、サーバー側のログ保持、IDによる検索、順序付き再生、重複や履歴期限切れへの対処が必要です。これはAblyの実装経験に基づく解説で、SSE規格が提供する保証ではありません。WHATWG規格もクライアントの再接続を定義し、サーバー側の保存機能までは規定していません。
運用上の設計：規格と配備環境を分ける
EventSourceはサーバーからUTF-8テキストイベントを受信するAPIです。接続が切れると再試行し、id:を受け取っていれば再接続要求にLast-Event-IDを含められます。任意のリクエストヘッダーを設定するAPIではなく、Accept: text/event-streamも規格上はユーザーエージェントが設定してよい項目です。応答のContent-Typeはtext/event-streamである必要があります。バッファリング、アイドルタイムアウト、接続数はサーバー、プロキシ、ブラウザー、HTTPバージョンの組み合わせで異なります。HTTP/2は接続上でストリームを多重化できますが、SSE接続の維持や遅延のない配信、欠落イベントの復元は保証しません。実際の中継経路全体を試験してください。