Responses API、WebSocket 接続

OpenAI のエンジニアリング記事が、コーディングエージェント等が Responses API を往復呼び出しする負荷に対し、推論（GPU 上のトークン生成）が高速化するほど、HTTP 上の毎回ハンドシェイクと履歴再検証の比率が相対的に大きくなる点を挙げている。同社は 2025 年頃の単一リクエスト向け最適化（トークン化結果の保持、中間マイクロサービス短絡、安全分類の遅延短縮）で初トークンまでの遅延を約 45% 改善したとし、その後、会話が長いほど毎回フル履歴を再処理する設計の限界を、永続接続＋接続上キャッシュに切り替えることで解消した。プロトタイプはツール呼び出しのサンプリング中に推論を一時停止し、クライアントでツール実行後 response.append 相当のイベントで再開する、単一の長尺レスポンスに近い挙動として説明している。

本番方針では、従来どおり response.create と previous_response_id による会話の継続を維持し、WebSocket 上では前レスポンスのオブジェクト、入出力アイテム、ツール定義、再レンダ用トークンなどを接続メモリに保持し、新規分だけ検証と課金の一部を重ね合わせる。これにより一部の分類器が履歴全体ではなく差分だけを扱え、再トークン化の無駄を減らす。Codex は本番トラフィックの多くを WebSocket モードへ切り替え、Vercel AI SDK では最大約 40%、Cline では 39%、Cursor では 30% 前後の遅延短縮が示されている。1 秒当たり 1000 トークン超の推論が主役になると、API 層の累積遅延が相対的に大きな割合を占めやすい。