OpenAI、Responses APIでWebSocket対応：エージェント遅延を最大40%削減

これまでAIコーディングエージェントが遅い原因といえば、モデルの推論時間そのものでした。しかし推論エンジンが高速化した結果、今度は手前のAPI通信そのものがボトルネックになるという逆転現象が起きています。

OpenAIはResponses APIにおいてWebSocketのサポートを開始したと発表しました。これにより、エージェントワークフローのレイテンシが最大40%削減され、最初のトークンが返るまでの時間（TTFT）も約45%短縮されました。

モデルが速すぎてAPIが追いつかない問題

Codexなどのエージェントがバグを修正する場合、コードの読み込み、編集、テストの実行などを繰り返すため、何十回ものAPIリクエストが往復します。

従来のHTTP経由では、リクエストごとに接続を確立し、会話履歴やツール定義を最初からすべて送り直して解析する必要がありました。GPT-5やGPT-5.2のように毎秒65トークン程度で動いていた時代は、推論の待ち時間に隠れてAPI側のオーバーヘッドは気になりませんでした。

ところが、Cerebrasの専用ハードウェア上で動くGPT-5.3-Codex-Sparkは毎秒1000トークン、瞬間最大4000トークンを叩き出します。モデルがどれだけ高速になっても、サーバー側のCPU処理を待たされる状態に陥っていました。

状態をメモリに保持する長接続アプローチ

そこでOpenAIは、gRPCではなく開発者が扱いやすいWebSocketを採用しました。コネクションを維持したまま、直前のレスポンス状態、レンダリング済みトークン、ツール定義をサーバー側メモリにキャッシュする仕組みです。

クライアントは次のリクエスト時にprevious_response_idを送るだけでよく、安全性チェックや検証も新しく追加された入力分だけに絞られます。さらに中間サービスの経由を減らしたり、課金処理を非同期化するなどの改善も加えられました。

この効果は実環境ですぐに現れています。VercelのAI SDKでレイテンシが最大40%減少し、Clineの複数ファイル処理は39%高速化、CursorでもOpenAIモデルの動作が最大30%速くなりました。

なぜ重要か

AIシステムのボトルネックが、GPUの計算力からトランスポート層やサービス周辺のアーキテクチャへと移り変わっていることを示す象徴的な動きです。

CursorやClineなどを日常的に使う開発者にとって、エージェントが自律的に試行錯誤する際の待ち時間が3〜4割削られる恩恵は絶大です。これまで数分かかっていた複雑なリファクタリングが劇的に軽快になり、作業の中断を防げます。

OpenAIの設計で巧みなのは、APIの形式を大幅に変えるのではなく、従来のresponse.createをベースに導入できる互換性を保った点です。推論速度の競争が激化するなか、競合他社もAPIパイプライン全体の再設計を迫られることになりそうです。