概要

Codexにバグ修正を依頼すると、関連ファイルの走査・読み込み・編集・テスト実行といった一連の処理が発生します。内部的にはこれは多数のResponses APIリクエスト（モデルの次のアクション判定 → ローカルツールの実行 → ツール出力をAPIへ送り返す → 繰り返し）を伴い、複雑なタスクではユーザーが完了を待つ時間が数分に及ぶこともあります。

エージェントループのレイテンシーは主に3つの段階で時間を消費します：APIサービス内の処理（リクエスト検証や処理）、モデル推論、クライアント側の時間（ツール実行やモデルコンテキスト構築）。推論はGPU上でトークンを生成する段階です。かつては推論が最も遅かったためAPIオーバーヘッドは隠れがちでしたが、推論が高速化するにつれてエージェントの総合的なAPIオーバーヘッドが無視できなくなりました。

本記事では、キャッシュ、不要なネットワーク往復の排除、安全性スタックの改善、そして最も重要な対策としてResponses APIへの「永続接続」を導入することで、エージェントループをエンドツーエンドで最大40%高速化し、推論速度を65 TPSからほぼ1,000 TPSへ跳ね上げた方法を説明します。

APIがボトルネックになった経緯

Responses APIでは、従来のフラッグシップモデル（GPT‑5やGPT‑5.2）はおおよそ65 TPSで動作していました。GPT‑5.3‑Codex‑Sparkのリリースに向け、専用のCerebrasハードウェアによって1,000 TPS超（オーダーオブマグニチュードの向上）を目標にしました。モデルの実際の速度をユーザーが実感できるようにするためには、APIオーバーヘッドを削減する必要がありました。

2025年11月頃にResponses APIのパフォーマンス改善スプリントを開始し、単一リクエストの重要経路上のレイテンシを下げるために多くの最適化を導入しました：

• レンダリング済みトークンやモデル設定をメモリにキャッシュして、マルチターンのレスポンスで高コストなトークナイゼーションやネットワーク呼び出しをスキップ
• 中間サービスへの呼び出しを排除してネットワークホップを減らす（例：画像解像度処理を省略し推論サービスへ直接呼び出し）
• 会話を迅速にフラグ付けできるように安全性スタックで一部の分類器を高速化

これらの改善によりTTFT（time to first token）は約45%改善しましたが、GPT‑5.3‑Codex‑Sparkの速度にはまだ十分ではありませんでした。構造的な問題として、我々は各Codexリクエストを独立して扱い、会話状態や再利用可能なコンテキストをフォローアップごとに毎回処理していました。会話履歴が長くなるほど、その繰り返し処理のコストが増大しました。

永続接続（persistent connection）の構築

設計を詰め直し、HTTPで新規接続を張って毎回フル会話履歴を送るのではなく、永続接続を維持して状態をキャッシュできないかと検討しました。新しい情報だけを送信し、再利用可能な状態は接続の寿命中にメモリ内でキャッシュすることで、冗長な処理を減らす方針です。

WebSocketsとgRPC双方向ストリーミングなどを検討した結果、既存のResponses APIの入出力形状を変えずに実装でき、開発者フレンドリーで既存アーキテクチャに小さな破壊で組み込めるWebSocketsを採用しました。

最初のWebSocketプロトタイプは、Responses APIのレイテンシに関する期待を大きく変えました。Codexチームのあるエンジニアがプロトタイプを夜通し動かし、エージェントのロールアウトを単一の長時間実行Responseとしてモデル化しました。asyncioの機能を使い、Responses APIはツール呼び出しがサンプリングされた後にサンプリングループ内で非同期にブロックし、response.doneイベントをクライアントへ送ります。クライアントはツール実行後にresponse.appendイベントでツール結果を返し、これがサンプリングループを再開させモデルの処理が続行されます。

ローカルツール呼び出しをホストされたツール呼び出しのように扱うイメージです。モデルがウェブ検索を呼ぶとき、推論ループはブロックしてウェブ検索サービスを呼び、その応答をモデルコンテキストに置きます。我々の設計では、リモートサービスを呼ぶ代わりにモデルのツール呼び出しをWebSocket経由でクライアントへ送り、クライアントが応答したらその結果をコンテキストに入れてサンプリングを再開します。

このアプローチは、エージェントのロールアウト全体で繰り返されるAPIの重複作業を排除できるため非常に効果的でした。事前推論の作業を一度だけ行い、ツール実行のために一時停止し、事後推論の作業を最終で一度だけ行えるようになります。ただし、この方法はAPIの形状が従来の同期的な呼び出しと比べて複雑になる欠点があり、開発者に対して新しい対話モード用の統合を書き直してもらう必要がありました。

APIの互換性を保ちつつ段階的に導入する工夫

最終的にローンチしたバージョンでは、開発者が既存の統合を書き換える必要がないようにAPI形状を馴染みのあるものに戻しました：引き続きresponse.createを同じボディで使用し、前回のレスポンスの文脈を継続するためにprevious_response_idを使います。WebSocket接続上では、サーバーは接続スコープのメモリ内キャッシュに前回レスポンスの状態を保持します。フォローアップのresponse.createがprevious_response_idを含む場合、フル会話を再構築するのではなくそのキャッシュ状態を取得します。

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

• 直前のresponseオブジェクト
• 過去の入力・出力アイテム
• ツール定義と名前空間
• 再利用可能なサンプリングアーティファクト（既にレンダリングされたトークンなど）

このメモリ内のprevious response状態を再利用することで、以下の主要な最適化が可能になりました：

• 一部の安全性分類器やリクエストバリデータを毎回履歴全体ではなく新しい入力だけに対して走らせる
• レンダリング済みトークンのメモリキャッシュを保持し、追加して不要なトークナイゼーションをスキップ
• モデル解決／ルーティングの成功ロジックをリクエスト間で再利用
• 課金などの事後推論の非ブロッキング作業を次のリクエストと重ねて実行

目標は、最小オーバーヘッドのプロトタイプにできるだけ近づけつつ、開発者が既に理解し構築しているAPI形状に収めることでした。

新たな速度基準の設定

WebSocketモードの構築に2か月のスプリントを行い、主要なコーディングエージェントのスタートアップとアルファをローンチしてインフラへ統合してもらい、安全にトラフィックを段階的に増やしてもらいました。アルファ利用者からは最大で約40%のワークフロー改善という高評価が寄せられました。

ローンチ結果は即時に現れました。Codexは短期間でResponses APIトラフィックの大半をWebSocketモードに移行し、レイテンシ改善を実感しました。GPT‑5.3‑Codex‑Sparkでは目標の1,000 TPSを達成し、バーストで4,000 TPSを記録することもあり、Responses APIがより高速な推論に実運用環境で追随できることを示しました。

開発コミュニティでの影響も早く現れました。Codexのユーザーは最新モデル（GPT‑5.3‑Codex、GPT‑5.4など）でWebSocketモードの恩恵を受けています。具体的な導入例と効果の一部は以下のとおりです：

• VercelはAI SDKにWebSocketモードを統合し、レイテンシが最大約40%低下
• Clineのマルチファイルワークフローが約39%高速化
• CursorでのOpenAIモデル利用が最大約30%高速化

WebSocketモードは、Responses APIが2025年3月にローンチして以来の最も重要な新機能の一つです。アイデアから本番稼働まで数週間で実装できたのは、OpenAIのAPIチームとCodexチームの緊密な連携のおかげです。推論が高速化するにつれて、推論を取り巻くサービスやシステムも同様に高速化して初めて、モデルの性能向上をユーザーへ還元できるというニーズに応えます。

著者

Brian Yu、Ashwin Nathan（Members of the Technical Staff）

謝辞

Responses APIおよびCodexチームの皆様に特別な感謝を示します。彼らがWebSocketモードの作成に取り組みました。

---

関連コンテンツ（続けて読む）

• From model to agent: Equipping the Responses API with a computer environment — Engineering Mar 11, 2026
• Beyond rate limits: scaling access to Codex and Sora — Engineering Feb 13, 2026
• Harness engineering: leveraging Codex in an agent-first world — Engineering Feb 11, 2026