AIエージェントのステートフル継続：なぜトランスポート層が重要になったのか

主要なポイント エージェントのワークフローでは、トランスポート層が第一級の関心事となります。マルチターンでツールを多用するループは、単一ターンのLLM利用では無視できるようなオーバーヘッドを増幅させます。 ステートレスなAPIはコンテキストの増加に対してスケーリングが困難です。各ターンで完全な履歴を再送信すると、ペイロードが線形に増加し、レイテンシも高まります。 ステートフルな継続によりオーバーヘッドが劇的に削減されます。コンテキストをサーバー側でキャッシュすることで、クライアントから送信されるデータを80%以上削減し、実行時間を15〜29%短縮できます。 この利点はプロトコル固有のものではなく、アーキテクチャ的なものです。コンテキストの再送信を回避するあらゆるアプローチが、同様の利益をもたらす可能性があります。 パフォーマンス向上にはトレードオフが伴います。ステートフルな設計は、信頼性、観測可能性（observability）、ポータビリティにおいて課題を導入するため、慎重に検討する必要があります。 飛行機の問題 最近のフライト中、機内インターネットを購入し、Claude Codeを使おうとしました。エージェントは複数のファイルを読み取り、コードベースの構造を理解し、編集を行い、テストを実行する必要があり、典型的なエージェントワークフローでは10〜15回のツール呼び出しが行われます。しかし、インターネット接続が非常に悪く、3回目または4回目のターンになるとリクエストがタイムアウトしてしまいました。各ターンで会話履歴全体（元のプロンプト、読み込んだすべてのファイル、提案されたすべての編集、テストの出力）が再送信されており、ペイロードは数百キロバイトに膨れ上がっていました。帯域幅が制限されたリンクでは、この増大するペイロードがボトルネックとなっていました。 この経験は、AI コーディングエージェントが成熟するにつれてますます重要になっていることを浮き彫りにしました：トランスポート層（Transport Layer）は、単純なチャットよりもエージェントワークフローにおいてより重要な役割を果たします。単発のチャット完了では、プロンプトを送信して応答を受け取ります。一方、エージェントによるコーディングセッションでは、モデルがコードを読み取り、変更を提案し、テストを実行し、エラー出力を確認し、問題を修正して反復するといった、10回、20回、あるいは50回以上の連続したターン（対話ステップ）が行われます。各ターンごとに会話のコンテキストは拡大し、HTTP 上では、この拡大するコンテキスト全体が毎回再送信されなければなりません。 2026年2月、OpenAI はレスポンス API に対して WebSocket モードを導入し、サーバーメモリに会話履歴をキャッシュすることでこの問題を解決しました。私はこれを試すことに興奮し、HTTP と比較してどのようにパフォーマンスが発揮されるかを確認しました。 エージェント・コーディングループ AI コーディングエージェントは、特に2025年12月以降、多くの組織において新奇な存在から日常のワークフローへと移行しました。Claude Code、OpenAI Codex、Cursor、Cline などのツールは、現在、マルチファイル編集、テストスイートの実行、失敗するビルドへの反復処理を日常的に行っています。OpenAI によると、Codex のみの週間アクティブユーザー数は160万人を超えており、Codex チームの典型的なエンジニアは4〜8つの並列エージェントを同時に実行しています。 これらのエージェントの中核となるのは「エージェントループ」です。これは、タスクが完了するまで繰り返されるモデル推論とツール実行のサイクルです： コーディングエージェントのループ：各ターンで、モデルはタスク完了を示す応答を返すか、ツール呼び出しを推奨します。その応答はタスクが完了するまでモデル推論にフィードバックされます。 エージェントループの1ターンでは、通常、コードベースを理解するために複数のファイルを読み取り、いくつかのファイルを編集し、テストを実行します。これには10〜15回のツール呼び出しが含まれ、複雑なリファクタリングの場合ではさらに多くなります。その後、それらのツール呼び出しの結果がLLM（大規模言語モデル）推論サーバーに送信されます。問題が解決した場合、LLMサーバーはそれ以上ツール呼び出しを行わない応答を返します。そうでない場合、LLMサーバーは追加のツール呼び出しを推奨し、エージェントループの次のターンが始まり、このプロセスは問題が解決するまで続きます。各ターンでは、モデルがこれまでに発生した事柄の全コンテキストを受信する必要があります。 HTTPオーバーヘッドの問題 OpenAIのResponses API over HTTPや、より古いChat Completions APIなど、HTTPベースのAPIでは、各ターンがステートレスなリクエストとなります。サーバーは前のターンで何が行われたかを記憶しないため、クライアントはすべてのデータを再送信しなければなりません： システム指示とツール定義（約2 KB） 元のユーザープロンプト すべての過去のモデル出力（モデルが記述した完全なコードブロックを含む） すべてのツール呼び出し結果（ファイル内容、コマンド出力を含む） これは、リクエストペイロードが各ターンごとに線形に増加することを意味します。ベンチマークでは、HTTP経由でクライアントが送信する実際の1ターンあたりのバイト数とWebSocketの場合を比較して測定しました： gpt-4o-mini を使用し、10回のタスク実行におけるターンごとの平均送信バイト数。HTTP は線形に増加するのに対し、WebSocket は一定のままです。 9ターン目には、HTTP は WebSocket に比べてリクエストあたりのデータ量が約10倍に達しています。これは、OpenAI の Responses API における WebSocket モードが、サーバー側のメモリ内状態を保持する永続的な接続を維持しているためです。最初のターン以降、各ターンで送信されるのは以下のデータのみとなります： キャッシュされた状態を参照する previous_response_id（約60バイト） 新しいツール呼び出しの出力（通常、ファイルコンテンツやコマンド出力で1〜3KB程度） このペイロードは、何ターン目であってもほぼ一定のままです。 既存ベンチマークが示すもの 独自のテストハーネスを構築する前に、公開されているデータを確認しました。 OpenAI の主張：Responses API の WebSocket モードは、ツール呼び出しが重い低レイテンシ・長時間実行型のエージェント向けに設計されています。20回以上のツール呼び出しを含むワークフローでは、冗長なコンテキストの再送信を排除し、ターン間でサーバー側のメモリ内状態永続性を活用することで、エンドツーエンドの実行速度を最大40%高速化します。 Cline による独立した検証：Cline チームは、標準的な HTTP API インテグレーションに対して GPT-5.2-codex の WebSocket モードをテストし、以下の結果を報告しました： 単純なタスク（ツール呼び出しが少ない）で約15%高速化 複雑なマルチファイルワークフロー（ツール呼び出しが多い）で約39%高速化 最良のケースでは50%高速化 WebSocket ハンドシェイクは最初のターンでわずかな TTFT（Time To First Token）のオーバーヘッドを追加しますが、その後の処理で迅速に相殺されます このパターン：高速化の規模はワークフローの複雑さに比例します。1〜2回のツール呼び出しを含む単純なタスクでは、利点は最小限（場合によってはWebSocketハンドシェイクによるわずかなオーバーヘッドが生じる）です。10回以上のツール呼び出しを伴う複雑なタスクでは、文脈の再送信を行わないことによる累積的な節約が各ターンで複合的に作用するため、劇的な改善が見られます。 ベンチマーク：主張の検証 これらの主張を制御された測定で検証するため、OpenAIのResponses APIに対して現実的なエージェント型コーディングワークフローをシミュレートするベンチマークハーネスを構築しました。このハーネスはオープンソースです。 方法論 複雑さが異なる3つのコーディングタスクを定義しました： 失敗するテストの修正 — テストファイルを読み取り、コンポーネントを読み取り、バグを修正し、テストを実行する（約10〜15ターン、12〜17回のツール呼び出し） 検索機能の追加 — 既存のコンポーネントを読み取り、機能を実装し、テストを実行する（約5〜15ターン、4〜21回のツール呼び出し） APIレイヤーのリファクタリング — プロジェクトの一覧表示、ファイルの読み取り、呼び出し元の検索、複数ファイルの更新、テストの実行（約6〜11ターン、10〜20回のツール呼び出し） 各タスクでは、現実的なファイル内容、テスト出力、コマンド出力を含むシミュレートされたツール応答を使用して、トランスポート層の違いを分離して評価します。モデルはOpenAIに対して実際のAPI呼び出しを行い、どのツールをいつ呼び出すか、そしていつ停止するかを決定します。非確実性はモデルの動作にあり、ツール応答にはありません。 2つのテスト構成： Cell Approach Per-turn behavior 1 HTTP Responses API Full conversation context is re-sent every turn 2 WebSocket Responses API previous_response_id + incremental input only 測定項目は以下の通りです。 TTFT（Time to First Token：最初のトークン生成までの時間）：各ターンでモデルが生成を開始するまでの速度。 送信バイト数：クライアントがタスクごとにアップロードするデータ量。 受信バイト数：ストリーミングイベントとして返されるデータ量。 総時間：エージェントワークフロー全体のエンドツーエンドの経過時間。 各構成について3回実行し、その結果を集計しました。テストには、最先端のコーディングモデルであるGPT-5.4と、小型で高速なモデルであるGPT-4o-miniの2つのモデルを使用し、トランスポート層の影響がモデルサイズを超えて一貫して現れるかを確認しました。 結果 すべての実行において、タスクは平均して8〜11ターン、タスクあたり9〜16回のツール呼び出しとなり、モデルやトランスポートモードによってばらつきがありました。 相対パフォーマンス（WebSocket対HTTP）： Metric GPT-5.4 GPT-4o-mini Total time 29% faster 15% faster Bytes sent 82% less 86% less First-turn TTFT 14% lower ~same GPT-5.4の詳細な結果： Metric GPT-5.4 HTTP GPT-5.4 WebSocket Delta Avg total time/task 40.8 s 28.9 s −29% Avg TTFT (all turns) 1,253 ms 1,111 ms −11% Avg TTFT (first turn) 1,255 ms 1,075 ms −14% Avg bytes sent/task 176 KB 32 KB −82% Avg bytes recv/task 485 KB 343 KB −29% 主要な発見 WebSocketは、クライアントから送信されるデータを80〜86%削減し、一貫してその結果を示しています。これはモデルの種類、APIのばらつき、タスクの複雑さに関わらず独立して確認できる最も信頼性の高い結果です。HTTPではタスクごとに153〜176 KBのデータが送信されるのに対し、WebSocketでは21〜32 KBです。これは、会話履歴が増大するたびに再送信する必要がないという直接的な結果です。 WebSocketは、エンドツーエンドの実行速度を15〜29%高速化します。GPT-5.4を使用した場合、WebSocketは29%高速であり、これは複雑なワークフローにおいてClineが報告した39%と概ね一致しています。この高速化は、ターンごとにアップロードするデータ量が減少することと、サーバー側での処理が潜在的に高速化されること（完全なコンテキストを再解析してトークン化する必要がないため）の組み合わせによるものです。 最初のトーンにおけるTTFT（Time To First Token：初回応答までの時間）は、各アプローチ間で同程度です。WebSocketのハンドシェイクによるオーバーヘッドは無視できるレベルであり、両方のモデルにおいて最初のトーンのTTFTはHTTPのノイズ範囲内でした。この利点は、会話履歴が増大するペイロードのアップロードを回避できる継続的なターンで顕著になります。 この効果はモデルに依存しません。GPT-4o-mini（詳細な結果はリポジトリを参照）でも同じベンチマークを実行し、データ送信量の削減（86%）とエンドツーエンド実行の高速化（15%）という一貫した結果を確認しました。GPT-5.4の方が時間節約の幅が大きかった（29%対15%）のは、おそらく最先端モデルがより長い応答を生成し、ターンごとに蓄積されるコンテキスト量が多いためです。 なぜ高速なのか：アーキテクチャの理由 パフォーマンスの違いは、冗長なデータ伝送を排除した直接的な結果です。 HTTP：設計上ステートレス ターン1: クライアント → [システム + プロンプト + ツール] → サーバー ターン2: クライアント → [システム + プロンプト + ツール + ターン1 + 出力1] → サーバー ターン3: クライアント → [上記すべて + ターン2 + 出力2] → サーバー ... ターンN: クライアント → [システム + プロンプト + ツール + 過去のすべてのターン] → サーバー 各リクエストは独立しています。サーバーはそれを処理してレスポンスを返し、すべての情報を忘却します。クライアントはゼロから完全なコンテキストを再構築しなければなりません。 WebSocket: 状態維持型継続（Stateful Continuation） ターン1: クライアント → [システム + プロンプト + ツール] → サーバー（サーバーはレスポンスをキャッシュ） ターン2: クライアント → [前回のID + ツール出力] → サーバー（サーバーはキャッシュから読み込み） ターン3: クライアント → [前回のID + ツール出力] → サーバー（サーバーはキャッシュから読み込み） ... ターンN: クライアント → [前回のID + ツール出力] → サーバー（一定サイズのペイロード） サーバーは、接続ローカルメモリ内に最新のレスポンスを保持します。継続（Continuation）はそのキャッシュされた状態を参照するため、クライアントは新しい情報のみを送信します。 ベンチマークに基づく帯域幅の計算 典型的な10ターンのコーディングタスクにおける実際のGPT-5.4データを使用: HTTPで送信された総バイト数（クライアント → サーバー）: 1タスクあたり176 KB（測定平均値） コンテキストが蓄積されるにつれて、ターン0では2 KBからターン9では38 KBに増加 WebSocketで送信された総バイト数: 1タスクあたり32 KB（測定平均値） ターンを通じて常に2〜4 KBで平坦に推移 これはクライアント送信バイト数において82%の削減であり、1タスクあたり144 KBの節約となります。これは数千の並行セッション全体で累積します。 アーキテクチャからの教訓 1. API互換性 versus パフォーマンス：プロトコルの代償 OpenAI互換のHTTP API（/chat/completionsエンドポイントおよびResponses API）が事実上の標準となっています。すべてのLLMツール、SDK、オーケストレーションフレームワークはこのAPIを扱います。しかし、この互換性には代償があります：このAPIは本質的にステートレスであり、すべてのリクエストに対して完全なコンテキストを再送信する必要があります。 WebSocketモードはこの互換性を破り、断片化を引き起こします。 現在、どのプロバイダーがWebSocketをサポートしているのでしょうか？ Provider / Gateway WebSocket API Streaming method OpenAI Responses API ✅ (2026年2月以降) WebSocket frames (JSON) Google Gemini API ⛔ (text/coding) ✅ (audio/video) WebSocket frames Anthropic Claude API ⛔ Server-Sent Events (SSE) OpenRouter ⛔ SSE (OpenAI互換) Cloudflare AI Gateway ✅ (gateway layer) WebSocket frames Local models (Ollama, vLLM) ⛔ SSE コーディングエージェントの中で、どのプロバイダーがWebSocketをサポートしているのでしょうか？ Coding Agent WebSocket support Notes OpenAI Codex ✅ (native) Built on the Responses API Cline ✅ (OpenAI only) First to integrate, reported 39% speedup Claude Code ⛔ Uses Anthropic SSE API Cursor ⛔ HTTP-based multi-provider Windsurf ⛔ HTTP-based multi-provider Roo Code ⛔ Cline fork, may inherit support OpenCode ⛔ Multi-provider, HTTP-based WebSocket は現在、OpenAI 固有の優位性です。エージェントがプロバイダー間で切り替える必要がある場合、例えば推論処理の重いタスクには Claude を、速度重視には GPT を使用する場合、OpenAI 以外の呼び出しごとに WebSocket のパフォーマンス上の利点を失うことになります。 Google の Gemini Live API も WebSocket を使用していますが、これはテキストベースのエージェントワークフローではなく、リアルタイムのオーディオ/ビデオストリーミング用に設計されています。Cloudflare の AI Gateway は複数のプロバイダーの前に配置された WebSocket エンドポイントを提供していますが、内部では HTTP にプロキシしており、OpenAI の実装を高速化するサーバー側の状態キャッシュは提供されません。 2. スケーリング時のプロトコルオーバーヘッド：ターンごとのバイト数が重要になる場合 単一の会話において、コンテキストの再送信によるオーバーヘッドは無視できるレベルです。しかし、サーバーの視点からは、2026 年のエージェントによるコーディングのスケーリングにおいて、これは重要な問題となります。 主要な単一プロバイダーの並行セッション数を推定します：OpenAI Codex の週間アクティブユーザーは 160 万人、GitHub Copilot の有料サブスクライバーは 470 万人です。Claude Code は年間換算で 25 億ドルの収益を生成しており、100 万人以上のアクティブ開発者を示唆しています。Cline、Cursor、Windsurf、Roo Code、OpenCode なども数百万人のユーザーを追加しています。保守的に見積もって、週に 500 万〜1,000 万人の開発者が AI コーディングエージェントをアクティブに使用しています。OpenAI のような主要な単一プロバイダーの場合、ピーク時に重複セッションが発生する中でユーザーの 10〜20% がアクティブであると仮定すると、ピーク時の並行するエージェントコーディングセッション数は約 100 万回と推定されます。 この規模において、測定されたタスクごとのデータを使用すると： HTTP: 1,000,000セッション × タスクごとに送信される176 KB = 40秒間のタスクあたりクライアントからサーバーへのペイロードが176 GB WebSocket: 1,000,000セッション × タスクごとに送信される32 KB = 40秒間のタスクあたりクライアントからサーバーへのペイロードが32 GB これは、40秒間のタスクにおいて144 GBのイングレス（受信）トラフィックの削減、つまり29 Gbpsの削減を意味します。数百万のリクエストを処理するプロバイダーにとって、これはAPIゲートウェイ、トークナイザー（各HTTPリクエストで完全なコンテキストを再トークナイズする必要がある）、およびネットワークインフラストラクチャの負荷を軽減します。サーバー側の節約は、クライアント側の節約よりも重要であると言えます：受信、解析、トークナイズするデータが少ないということは、全員にとって最初のトークンまでの時間（time-to-first-token）が短くなることを意味します。 3. サーバー側の状態：真の革新 重要な洞察は、WebSocketがプロトコル自体のために高速であるわけではないということです。TCPベースのWebSocketはHTTP/2と同様のフレーム化オーバーヘッドを持っています。速度の源泉はサーバー側の状態管理にあります：WebSocketサーバーは、接続ローカルな揮発性メモリに最新の応答を保存しており、これにより完全な会話を再トークナイズすることなくほぼ即時の継続が可能になります。 これにはアーキテクチャ上の意味があります： 状態は揮発性です：接続を処理する特定のサーバーのメモリ上にのみ存在します。接続が切断されると、状態は失われます（store=true の場合を除く）。 多重化不可：各 WebSocket 接続は一度に1つのレスポンスのみを処理します。並列エージェント呼び出しには、複数の接続が必要です。 60分の制限：接続は1時間後に自動終了するため、1時間を超えるセッションには再接続ロジックが必要です。 同様のシステムを設計するアーキテクトにとって、このパターンは明確です。以前のコンテキストに基づいて連続したリクエストを行うプロトコルの場合、そのコンテキストをサーバー側（揮発性メモリのみであっても）に保持することで、リクエストごとのオーバーヘッドを劇的に削減できます。 4. 状態性のスペクトル コンテキスト蓄積問題に対する異なるアプローチは、異なるトレードオフを提供します： アプローチ 状態の場所 耐久性 レイテンシ 帯域幅 HTTP（ステートレス） クライアントのみ N/A 高い（コンテキストとともに増加） 高い（コンテキストとともに増加） HTTP + store=true サーバー（永続化済み） 耐久性あり 中程度（サーバーが永続ストアから再構築） 低い（増分入力） WebSocket + store=false サーバー（メモリ内） 揮発性 低い（再構築不要） 低い（増分入力） WebSocket + store=true サーバー（メモリ内 + 永続化） 耐久性あり 低い（ハッピーケースでは再構築不要） 低い（増分入力） ほとんどのエージェントワークフローにとっての最適解は、WebSocket + store=false です。これにより、最も高速な継続実行が可能になり、データがプロバイダーのサーバーに永続化されません（これは「ゼロデータ保持」ポリシーを遵守する企業にとって重要です）。また、接続が切断された場合、途中からの回復を試みるのではなく、タスクを最初から再起動します。 5. 並列実行：マルチプレクシングではなく、複数の接続 各 WebSocket 接続は一度に一つのレスポンスを処理します。マルチプレクシングは行われません。並列タスク（例えば、典型的な Codex エンジニアが同時に 4〜8 人のエージェントを実行する場合）には、個別の WebSocket 接続が必要です。WebSocket がもたらす帯域幅の節約は接続ごとに適用されますが、実行速度が速いため、並列 HTTP リクエストよりも並列接続の方が API のレート制限により厳しく適用される可能性があります。 HTTP が依然として適切な選択となる場合 WebSocket モードが常に優れているわけではありません。以下のケースでは HTTP を使用してください： シンプルでターン数の少ないインタラクション：1〜2ターンのインタラクションでは、コンテキスト再送信のオーバーヘッドは無視できる程度であり、追加される複雑さを正当化するものではありません。 マルチプロバイダーのサポート：OpenAI、Anthropic、Google、ローカルモデルの間で切り替える必要がある場合、標準的なHTTP APIが共通の分母となります。WebSocketモードは現在OpenAI固有のものであり、これを採用するとプロバイダーロックインが発生します。 ステートレスなインフラストラクチャ：永続的な接続を維持できないサーバーレス関数（Lambda、Cloud Functions）上でバックエンドを実行する場合、HTTPが唯一の選択肢となります。 デバッグと観測可能性：HTTPリクエストは、標準的なツールを使用してログに記録、再生、デバッグするのが容易です。WebSocketストリームには特殊なツールが必要です。 結論 エージェント的なコーディングワークフローにおいて、ステートレスなHTTPからステートフルなWebSocket接続への移行は、意味のあるパフォーマンスの向上をもたらします。具体的には、エンドツーエンドの実行が29%高速化し、クライアント側で送信されるデータ量が82%減少し、GPT-5.4を用いたOpenAI Responses APIとの制御されたベンチマーク検証により、TTFT（Time To First Token）が11%低減することが確認されています。 しかし、WebSocketの利点にはトレードオフが伴います。現在これはOpenAI固有のものであり、開発者がモデル間で切り替えを望むエコシステムにおいてプロバイダーロックインを生み出しています。主要な代替案のいずれも、テキストベースのエージェントワークフローに対して同等のWebSocketサポートを提供していません。それらには、AnthropicのClaude API、Google Gemini、OpenRouter、ローカルモデルサーバーが含まれます。 エージェントシステムを構築するアーキテクトへの教訓は、WebSocket を盲目的に採用することではありません。それは、AI ワークフローが単一ターンからマルチターンへとシフトするにつれて、チャットボットには無関係だったトランスポート層の判断がエージェントにとって重要な要素になることを認識することです。WebSocket、サーバーサイドセッションキャッシュ、またはカスタムステートフルプロトコルのいずれかを通じて、増大する会話コンテキストの再送信を回避するあらゆるシステムは、同様の成果を得ることになります。問題は、業界がステートフルな LLM 継続のための標準に収束するか、それともこれがプロバイダー固有の競争優位性として残るかどうかです。 ベンチマークハーネスとすべての結果はここから入手可能です。 著者について アニル・メンディラッタ アニル・メンディラッタは、Netflix の Playback Backend 所属のシニアソフトウェアエンジニアで、分散システムに関する深い専門知識を持っています。彼は AI 支援コーディングと 0 から 1 までのシステム構築を楽しんでいます。 続きを読む表示 less

AIエージェントのステートフル継続：なぜトランスポート層が重要になったのか

背景や根拠まで確認しますか？

調べる

選ぶ

サイト