WebSockets の Responses API におけるエージェントワークフローの効率化

Codex にバグ修正を依頼すると、関連するファイルを見つけるためにコードベースをスキャンし、コンテキストを構築するためにそれらを読み取り、編集を加え、修正が機能したことを確認するためにテストを実行します。内部的には、これは Responses API への何度もの往復リクエストを意味します。つまり、モデルの次のアクションを判断し、コンピューター上でツールを実行し、そのツールの出力を API に送り返し、これを繰り返します。

これらすべてのリクエストが積み重なることで、ユーザーはCodexが複雑なタスクを完了するのを数分待つことになる場合があります。レイテンシの観点では、Codex エージェントのループは主に3つの段階に時間を費やします。API サービス内での処理（リクエストの検証と処理）、モデル推論、そしてクライアント側の処理（ツールの実行やモデルのコンテキスト構築）です。推論（インファレンス）は、モデルが GPU 上で実行され、新しいトークンを生成する段階です。これまでは、GPU 上での LLM 推論がエージェントループの中で最も時間のかかる部分だったため、API サービスのオーバーヘッドは目立ちにくいものでした。推論が高速になるにつれて、エージェント型ロールアウトによる累積的な API オーバーヘッドがより目立つようになります。

この投稿では、API を使用したエージェントループをエンドツーエンドで40%高速化し、ユーザーが推論速度の毎秒65トークンから毎秒1,000トークン近くへの向上を体感できるようになった方法を解説します。私たちは、キャッシュの活用、不要なネットワークホップの排除、問題を迅速に検知できるようにするための安全性スタックの改善、そして最も重要なのは、一連の同期的な API コールを行う必要があるのではなく、Responses API への永続的な接続を確立する仕組みを構築することによって、これに取り組みました。

Responses API では、GPT‑5 や GPT‑5.2 などの従来のフラッグシップモデルは、およそ毎秒65トークン（TPS）で動作していました。高速なコーディングモデルである GPT‑5.3‑Codex‑Spark の立ち上げにあたり、私たちの目標は桁違いの高速化、すなわち1,000TPS 超を実現することでした。これは、LLM 推論向けに最適化された専用の Cerebras ハードウェアによって可能になりました。ユーザーがこの新しいモデルの本来の速度を体感できるようにするため、API のオーバーヘッドを削減する必要がありました。

2025年11月ごろ、私たちは Responses API でパフォーマンス改善スプリントを開始し、単一リクエストにおけるクリティカルパスのレイテンシに対して多くの最適化を実施しました：

• マルチターン応答でコストの高いトークン化やネットワーク呼び出しを省略するために、レンダリング済みトークンとモデル構成をメモリ内にキャッシュする
• 中間サービスへの呼び出しをなくし、推論サービス自体を直接呼び出すことで、ネットワークホップの遅延を削減する（例えば、画像処理の解像度調整など）
• 特定の会話により迅速にフラグを立てられるようにするための、安全性スタックの改善

これらの改善により、最初のトークンが返されるまでの時間（TTFT）は約45%改善されました。これは API の体感的な応答性を示す指標ですが、それでも GPT‑5.3‑Codex‑Spark にとっては十分な速さではありませんでした。こうした改善を行ってもなお、Responses API のオーバーヘッドはモデルの速度に対して大きすぎました。つまり、ユーザーはモデルを実行する GPU を利用できるようになる前に、API を実行している CPU の処理を待たなければなりませんでした。

より根本的な問題は構造的なものでした。つまり、各 Codex リクエストを独立したものとして扱い、後続のリクエストごとに会話の状態やその他の再利用可能なコンテキストを毎回処理していました。会話の大部分に変更がなかった場合でも、会話履歴全体に紐づく処理のコストを支払っていました。会話が長くなるにつれて、その繰り返し処理のコストが増大しました。

設計をより洗練させるために、私たちはトランスポートプロトコルを見直しました。HTTP で毎回新しい接続を確立し、フォローアップリクエストのたびに会話履歴全体を送信するのではなく、永続的な接続を維持して状態をキャッシュできないだろうか、と考えたのです。その考え方は、検証と処理が必要な新しい情報のみを送信し、再利用可能な状態を接続の存続期間中メモリにキャッシュしておくというものでした。これにより、重複作業による負担が軽減されます。

WebSockets や gRPC の双方向ストリーミングを含む、いくつかの異なるアプローチを検討しました。WebSockets を採用したのは、シンプルなメッセージ転送プロトコルであるため、ユーザーが Responses API の入出力の形式を変更する必要がないからです。開発者にとって使いやすく、既存のアーキテクチャにも大きな混乱もなく適合しました。

最初の WebSocket プロトタイプは、Responses API のレイテンシに関する可能性の認識を変えました。API スタック全体に深い専門知識を持つ Codex チームのエンジニアが、Codex エージェントを一晩稼働させてプロトタイプを作成しました。

そのプロトタイプでは、エージェント型のロールアウトは、単一の長時間実行される Response としてモデル化されました。asyncio の機能を使用すると、ツール呼び出しがサンプリングされた後、Responses API はサンプリングループ内で非同期にブロックされ、その後 response.done イベントをクライアントに返します。ツール呼び出しを実行した後、クライアントはツールの結果を含む response.append イベントを送り返します。これによりサンプリングループのブロックが解除され、モデルは処理を続行できます。

ここでのたとえとしては、ローカルのツール呼び出しをホスト型のツール呼び出しとして扱うことです。モデルがウェブ検索を呼び出すと、推論ループはブロックされ、ウェブ検索サービスを呼び出し、そのサービスの応答をモデルコンテキストに配置します。私たちの設計でも同様のことを行いましたが、リモートサービスを呼び出す代わりに、モデルのツール呼び出しを WebSocket 経由でクライアントに送り返しました。クライアントが応答すると、クライアントのツール呼び出しの応答をコンテキストに追加し、サンプリングを続行しました。

この設計は、エージェントのロールアウト全体で発生する API 関連の重複作業をなくしたため、非常に効果的でした。推論前の作業を一度行い、ツールの実行のために一時停止し、最後に推論後の作業を一度行うことができます。

しかし残念ながら、その代償として、よりなじみが薄く、より複雑な API 設計になってしまいました。そのため開発者が、新しいやり取りの方式に合わせて API 連携を書き直すことなく、WebSocket サポートを簡単に組み込めるようにしたいと考えました。

今回リリースしたバージョンでは、使い慣れた形式に戻しました。つまり、同じボディで response.create を引き続き使用し、previous_response_id を使って前回のレスポンスの状態から会話コンテキストを継続します。

WebSocket 接続では、サーバーは以前のレスポンス状態の接続スコープのインメモリキャッシュを保持します。後続の response.create に previous_response_id が含まれている場合、会話全体を一から再構築する代わりに、その状態をキャッシュから取得します。

そのキャッシュされた状態には以下が含まれます。

• 前の response オブジェクト
• 以前の入力アイテムと出力アイテム
• ツール定義と名前空間
• 以前にレンダリングされたトークンのような、再利用可能なサンプリングアセット

インメモリの前回の応答状態を再利用することで、複数の大幅な最適化を実現できました：

• 一部の安全性クラシファイアとリクエスト検証機能が、毎回すべての履歴を対象にするのではなく、新しい入力のみを処理するようにする
• 不要なトークン化を省けるように、追加していくレンダリング済みのトークンのインメモリキャッシュを保持する
• リクエスト間で実績のあるモデル解決／ルーティングロジックを再利用
• 請求処理などの非ブロッキングな推論後の処理を後続のリクエストと重複させる

目標は、オーバーヘッドを最小限に抑えたプロトタイプにできる限り近づけつつ、開発者がすでに理解し、それを基に構築してきた API の形状を維持することでした。

WebSocket モードの構築に2か月にわたって集中的に取り組んだ後、主要なコーディングエージェントのスタートアップがこれを自社のインフラに統合し、安全に段階的にトラフィックを増やせるよう、アルファ版を公開しました。アルファ版ユーザーはこれを高く評価し、エージェントを活用したワークフローにおいて最大40%の改善⁠（新しいウィンドウで開く）を報告しました。好意的なアルファ版フィードバックを受けて、私たちはリリースする準備が整っていました。

リリースの結果は即座に現れました。Codex は Responses API のトラフィックの大半を WebSocket モードへ迅速に移行し、レイテンシが大幅に改善されました。GPT‑5.3‑Codex‑Spark では、目標の 1,000 TPS を達成し、最大 4,000 TPS のバーストも確認できたことから、Responses API が実際の本番トラフィックにおいて大幅に高速な推論にも追随できることが示されました。その影響は開発者コミュニティにもすぐに現れました。

• Codex はトラフィックの大部分を迅速に WebSockets に移行しました。GPT‑5.3‑Codex⁠（新しいウィンドウで開く）、GPT‑5.4⁠（新しいウィンドウで開く） などの最新モデルを利用するCodexユーザーは、WebSocketモードによる高速化の恩恵を受けられます。
• Vercel は AI SDK に WebSocket モードを統合し、レイテンシが 最大40%⁠（新しいウィンドウで開く） 低下しました。
• Cline のマルチファイルワークフローは 39%より高速化⁠（新しいウィンドウで開く）しました。
• Cursor の OpenAI モデルが最大30%高速化⁠（新しいウィンドウで開く）しました。

WebSocket mode は、2025年3月の Responses API の提供開始以来、最も重要な新機能の1つです。OpenAI の API チームと Codex チームの緊密な連携により、わずか数週間でアイデア段階から本番稼働まで進めることができました。これは、エージェントのロールアウト時のレイテンシを大幅に改善するだけでなく、開発者の高まりつつあるニーズにも応えます。つまり、モデル推論の高速化が進むにつれて、そうした改善をユーザーに届けるには、推論を取り巻くサービスやシステムも高速化する必要があります。