この記事で扱うこと
エージェントの応答をリアルタイムで見せるために WebSocket 接続を実験した日の短いふりかえりだ。プロトコル・再接続・観測方法を 1 つの作業にまとめて整理する。（翌日、WebSocket ストリーミングと LCP 改善 で UI・パフォーマンスまでつながる。）
1. WebSocket 接続・再接続・観測
背景知識（概念）
- WebSocket handshake: HTTP で始めてプロトコルを Upgrade する過程。
- Heartbeat: 接続が生きているかを周期的に確認する ping/pong または類似のメッセージ。プロキシ・ロードバランサのタイムアウトを避ける。
どんな状況だったか
HTTP のリクエスト・レスポンス 1 回では、長く続くエージェント出力を自然に見せるのが難しい。WebSocket で接続を維持したままサーバーが複数のメッセージを送る方式を検討した。
初期には 再接続時のメッセージ消失・重複、アイドル接続の切断といった運用上の課題が予想された。ネットワークタブだけでは、メッセージがいつ届くかの把握が難しかった。
目標は 3 つだった — ハンドシェイク・再接続ロジックの整理（接続）、アイドルタイムアウトに備えた heartbeat の設計（安定性）、ストリーミングのタイミングをデバッグする方法を見つけること（観測）。
中心となる作業
- プロトコル: WebSocket のハンドシェイクと再接続ロジックを整理した。
- heartbeat: 接続維持のコスト・タイムアウトを考慮して設計する必要性を確認した。中間のプロキシが先に切断しうるからだ。
- 観測: ネットワークタブだけではストリーミングのタイミング把握が難しかった — アプリログ・フレーム単位のツールを併用すべきという結論。
教訓
- 接続維持のコストを考慮して heartbeat を設計しなければならない — 中間のプロキシが先に切断しうる。
- ネットワークタブだけではストリーミングのタイミングを把握しにくい — メッセージの境界・UI への反映時点は別途計測するほうがよい。
- 再接続は「つなぎ直す」だけでなく状態同期の問題だ — 翌日の UI placeholder・LCP 作業へつながる。
→ Largest Contentful Paint — 翌日のランディング性能作業と接続
派生知識
- Largest Contentful Paint — 翌日のランディング性能作業と接続
関連 TIL
- WebSocket ストリーミングと LCP 改善 — ストリーミング UI・placeholder・LCP