通信が切れても、回答の続きへ戻れるか？
まず図全体の流れを見て、細部は「原寸で読む」を開いて確認してください。原寸の図は横にスクロールできます。正常な流れの次に、失敗時の分岐を追いましょう。
速く届くことと失わないことは別
回答が少しずつ表示されると、利用者は処理の進行を確認できます。ただし接続が続いていることは、回答が保存された証拠にはなりません。この章は学習用の概念設計です。実行はサーバーに残り、接続は画面へ結果を届ける一時的な経路と考えます。非同期実行と配信を分けると、タブを閉じても処理を追跡できます。
原寸で読む（横にスクロール）
図では、接続先が変わっても同じ実行IDに戻ります。再接続のたびにモデルを最初から呼び出す構成では、切断が重複実行を生みます。
SSE、EventSource、fetch、WebSocket
SSEはサーバーからクライアントへイベントを流す形式と仕組みであり、EventSourceはそれを受け取るブラウザーのインターフェース（API）です。fetchでもレスポンス本文を逐次読み取れるが、SSEの解析や再開はアプリ側で実装します。WebSocketは双方向のメッセージ経路を提供します。MDNのSSE解説とWebSocket解説で基本的な違いを確認できます。
| 方法 | 向く用途 | アプリが考えること |
|---|---|---|
| EventSourceでSSE | 進捗や回答の受信 | 認証方式と再開履歴 |
| fetch streaming | POSTや独自ヘッダーを伴う配信 | 解析、再接続、カーソル |
| WebSocket | 継続的な双方向イベント | 再接続、認証、流量制御 |
標準のEventSourceでは任意の認証ヘッダーを設定できないため、同一オリジンの安全なセッション設計などと合わせて選びます。URLへ長期トークンを埋め込むと履歴やログに残るおそれがあります。WebSocketを選ぶ理由は「リアルタイムだから」ではなく、クライアントからも頻繁に情報を送る必要があるかという点です。送信や停止が時々起きる程度なら、HTTP操作と片方向配信でも構成できます。
再開できるイベントの契約
イベントには実行ID、その実行内の単調な連番、種別を付けます。たとえばrun-7 / 42 / text.deltaです。カーソルは最後に適用した番号を示します。受信しただけで番号を進めず、表示状態へ適用した後に進めます。二重受信は番号で除き、途中が抜けた場合は不足分を取得します。
原寸で読む（横にスクロール）
仮の設計ではイベントを24時間保持し、確定した回答とスナップショットをそれより長く残します。この時間は製品仕様ではありません。保持期間を過ぎたカーソルには再開不可を明示し、版番号付きスナップショットへ戻します。スナップショットが連番80まで含むなら81以降を適用します。スナップショット取得と購読開始の間の更新も、同じ履歴から追える必要があります。
接続内の順序だけでは、再接続後の欠落を防げません。通知用のpub/subが一度流すだけなら、過去イベントを読み直す保存先を別に持ちます。最終回答だけが必要な画面なら、逐次イベントの完全な復元を省き、確定状態の再取得へ切り替える選択もあります。
遅い端末と切れた回線を扱う
原寸で読む（横にスクロール）
ブラウザーの標準WebSocketのインターフェースには受信側のネイティブなバックプレッシャーがありません。これは「受け手が遅ければ送信側が自動で待つ」と期待できないという意味です。メッセージサイズ、頻度、接続ごとのバッファに上限を置き、細かな進捗はまとめます。上限を超えたら接続を閉じ、保存状態から再同期します。音声や操作イベントをすべて同じように破棄してはいけません。
ハートビートは接続の生存を確かめる補助であり、仕事が進んでいる証明ではありません。タイムアウト後の再接続には待機とジッターを入れ、一斉再接続による負荷を抑えます。再接続時にも認証・対象の実行の閲覧権限を検証します。WebSocketのブラウザー接続ではOriginも検証するが、Originだけで本人確認はできません。購読中の権限失効時に配信を止める方法も決めます。
設計例：AI回答の配信
受付HTTPでメッセージを保存して実行IDを返します。ワーカーが回答を生成し、永続化したイベントを配信します。画面はHTTPで停止要求を送り、SSEで進捗を受け取ります。停止受理と実行停止の完了を異なる状態にします。接続が切れてもワーカーを自動停止するかどうかは、通信仕様とは別の製品判断です。
この構成の代償は履歴の保存と再同期処理です。短い通知だけなら定期的な状態取得の方が運用を単純にできます。一方、音声会話のように遅延と双方向性が重要なら、メディア用の経路も検討します。
練習と解答
画面は42まで適用済みで、再接続後に42、43、45を受け取りました。どう対応しますか。42は重複として捨て、43を適用し、44の欠落を検出します。45を無条件に続けて表示せず、履歴を補うか整合したスナップショットへ戻します。履歴が期限切れなら、新しい実行を始めるのではなく現在の確定状態を取得します。
押さえたいポイント
接続を一時的な配信路として扱い、実行状態・履歴・再開カーソルを別に管理する。
出典・さらに読む
- MDN: Using server-sent events内容の確認日: 2026-10-23
- MDN: WebSocket API内容の確認日: 2026-10-23
学習と設計検討のための概念的な構成例です。稼働中のKumyuの実装を表す図ではありません。