# Responses API に WebSocket 登場、エージェントのループが 40% 速く！

やっほー、しぃちゃんだよ！今日は「速さ」のお話だよ。エンジニアにとって待ち時間って地味にストレスだよね。その待ち時間をどうやって削ったのか、ワクワクする裏側の話が出てきたから紹介しちゃうね！

## なにが発表されたの？

OpenAI の News で、Responses API に WebSocket を使った新しいモードを入れて、エージェントのループを end-to-end で 40% 速くしたよ、っていう発表があったの。

Codex にバグ修正をお願いすると、コードベースを探して、ファイルを読んで、編集して、テストを走らせて…って、裏では Responses API へのリクエストが何十往復もするんだって。この積み重ねが、複雑なタスクだと「数分の待ち時間」になっちゃう。そこにメスを入れた、っていうお話なの。

## 今までどうだったの？

エージェントのループの遅さは、大きく 3 つの段階に分かれるんだって。API サービス側（リクエストの検証や処理）、モデルの推論、そしてクライアント側（ツールの実行やコンテキスト作り）。

昔は GPU で動くモデル推論がいちばん遅かったから、API 側のオーバーヘッドはその陰に隠れて目立たなかったの。ところが推論がどんどん速くなると…隠れていた API 側のコストが急に目立つようになっちゃったんだ。

実際、これまでの主力モデル GPT-5 や GPT-5.2 は毎秒 65 トークン（TPS）くらい。でも高速コーディングモデルの GPT-5.3-Codex-Spark は、専用の Cerebras ハードウェアで 1,000 TPS 超えを狙ってたの。モデルがこんなに速くなると、API 側が足を引っ張っちゃうんだよね。

## これで何が変わるの？

いちばん大きいのは、Responses API に「持続的な接続」ができるようになったこと。今までは follow-up のたびに HTTP で新しく接続して、会話の履歴を丸ごと送り直してたの。だから会話が長くなるほど、同じ処理を何度も繰り返して重くなってた。

新しい WebSocket モードでは、接続している間はサーバー側が状態をメモリにキャッシュしておいて、新しく必要になった情報だけを送ればよくなったの。結果、みんなが体感する推論速度は 65 TPS から 1,000 TPS 近くまでジャンプ！ しかも本番トラフィックでは瞬間的に 4,000 TPS まで出たんだって。

## 深く潜ってみよう

まず 2025 年 11 月ごろ、OpenAI は単発リクエストの最適化スプリントをやったの。レンダリング済みトークンやモデル設定をメモリにキャッシュ、中間サービスへの呼び出しを減らして推論サービスを直接叩く、安全性の分類器を速くする…。これで time to first token（TTFT、最初の 1 トークンが返るまでの時間）が約 45% 改善。でも GPT-5.3-Codex-Spark にはまだ足りなかったの。

そこで transport 自体を見直したんだ。WebSockets と gRPC 双方向ストリーミングを比べて、最終的に WebSockets を採用。単純なメッセージ転送プロトコルだから、開発者が入出力の形を変えなくて済むのが決め手だったよ。

最初の試作は、エージェントの一連の動きを「1 つの長いレスポンス」として扱う大胆なもの。ツール呼び出しが出たら `asyncio` でサンプリングループを止めて、`response.done` をクライアントに送る。クライアントがツールを実行して `response.append` で結果を返すとループが再開…という仕組み。ローカルのツール呼び出しを、web search みたいなホスト型ツールと同じように扱うイメージなんだって。これで API の重い処理を「前処理 1 回・後処理 1 回」に減らせた。

でもこの形は API の使い勝手がガラッと変わって難しかったから、本番版では見慣れた形に戻したの。`response.create` を同じボディで呼びつつ、`previous_response_id` で前の状態を引き継ぐ方式だよ。WebSocket 接続中はサーバーが前のレスポンスの状態（レスポンスオブジェクト、入出力アイテム、ツール定義、レンダリング済みトークンなど）をメモリに持っていて、次のリクエストではそれを再利用するの。おかげで安全性の分類器や検証は新しい入力だけを処理、トークン化もスキップ、課金みたいな後処理は次のリクエストと重ねて実行…と、無駄をどんどん削れたんだ。

この WebSocket モードは、最新の [GPT-5.3-Codex](https://developers.openai.com/api/docs/models/gpt-5.3-codex) や [GPT-5.4](https://developers.openai.com/api/docs/models/gpt-5.4) を使うときにも効いてくるよ。

## まとめ

- Responses API に WebSocket モードが登場、エージェントのループが end-to-end で 40% 高速化
- 持続的な接続でサーバーが状態をキャッシュ、follow-up ごとの会話履歴の送り直しをやめたのがカギ
- `previous_response_id` で見慣れた API の形はそのまま、内部だけ賢く再利用
- GPT-5.3-Codex-Spark で 1,000 TPS を達成、本番では瞬間 4,000 TPS も
- 反響も大きくて、Vercel の AI SDK は最大 [40% 高速化](https://x.com/aisdk/status/2026031263925039591)、Cline は [39% 速く](https://x.com/cline/status/2026031848791630033)、Cursor 上の OpenAI モデルは最大 [30% 速く](https://x.com/leerob/status/2026030244407468259)

エージェントを実運用に載せてる開発者や、Codex みたいなコーディングエージェントの遅延に悩んでる人にはとくに刺さる話だと思うな。推論が速くなるほど、その周りの仕組みも速くしないと恩恵が届かない…っていう視点、すごく勉強になったよ！