アーキテクチャ

エージェント通信における WebSocket vs SSE：MCP がどちらも選ばなかった理由

著者：IdeaBosque最終更新：2026年9月11日

重要なポイント

MCP 2026-07-28 仕様は HTTP+SSE を非推奨とし、Streamable HTTP で置き換えました——WebSocket ではなく——ステートレスサーバーは標準 HTTP インフラ（WAF、ロードバランサー、認証プロキシ）で永続的な接続管理なしに動作するため（MCP specification）。
A2A は HTTP 上の JSON-RPC 2.0 と SSE をタスク出力のストリーミングに使用します——トランスポートは配管であり、プロトコルのセマンティクス（タスクライフサイクル、INPUT_REQUIRED 状態）がエージェント間通信を機能させるものです（A2A protocol）。
CVE-2026-16496（CVSS 10.0）は Terraform MCP のステートフル SSE トランスポートモードを悪用しました——盗まれたセッション ID により、攻撃者は別のユーザーの認証情報でツール呼び出しを実行できました。ステートレストランスポートはパッチレベルではなくアーキテクチャレベルで攻撃面を排除します（NVD）。
WebSocket はカスタム MCP トランスポートとして利用可能ですが、仕様作者が意図的に回避したセッション管理の複雑さを追加します——プロトコルはトランスポート非依存ですが、標準トランスポート（stdio、Streamable HTTP）が本番ケースをカバーします（MCP specification）。
2026年9月17日の AGNTCon+MCPCon Europe での「Stateless: The Future of MCP Transports」セッションは、ステートレストランスポート方向の最初の主要カンファレンス検証です——Google と Hugging Face（MCP Transport Working Group メンテナー）により発表（Linux Foundation）。

トランスポートの問題はインフラの配管のように聞こえますし、実際そうですが——この選択は本番環境で現れるセキュリティ、スケーラビリティ、運用上の結果をもたらします。Model Context Protocol が2026年7月28日に HTTP+SSE を非推奨とし Streamable HTTP で置き換えたとき、仕様作者は意図的なエンジニアリング決定を行いました：永続的な接続よりもステートレスサーバー、カスタムプロトコルよりも標準 HTTP、そしてデュアルエンドポイント SSE モデルよりも単一エンドポイントです。WebSocket は双方向であり SSE はそうではないにもかかわらず、WebSocket を選択しませんでした。理由は WebSocket が間違っているからではなく、MCP がサービスを提供する特定のワークロード（エージェントとデータソース間のツール呼び出し）では、双方向の機能がセッション管理のオーバーヘッドに見合わないからです。

この記事は3つのトランスポートオプション——SSE、WebSocket、Streamable HTTP——を、それらを使用する2つのエージェントプロトコル（MCP と A2A）に対してマッピングし、B2B エージェントデプロイメント向けの意思決定マトリックスを提供します。9月17日の AGNTCon セッションがタイミングを具体的にします：ステートレストランスポートは仕様からカンファレンス検証へと移行しており、非推奨 SSE トランスポートを実行しているチームには12ヶ月の移行ウィンドウがあり、そのうち2ヶ月がすでに経過しています。

3つのトランスポートとそれぞれの機能

SSE（Server-Sent Events）—— 非推奨のデフォルト

SSE は単方向プロトコルです：サーバーは長寿命の HTTP 接続を介してクライアントにデータをプッシュし、クライアントは同じ接続でメッセージを送り返すことはできません。クライアントのすべてのアクション——生成のキャンセル、タスク中のエージェントのステアリング、ツール呼び出しの承認——には個別の HTTP POST リクエストが必要です（WebSocket.org）。

MCP は 2024-11-05 仕様でリモートサーバーのトランスポートとして SSE を使用していました。このモデルには2つのエンドポイントが必要でした：サーバーからクライアントへのメッセージ用の SSE エンドポイントと、クライアントからサーバーへのメッセージ用の個別の POST エンドポイントです。サーバーは両方の接続にわたってセッション状態を維持していました。3つの制限が非推奨を促しました：再開可能なストリームのサポートなし、長寿命の高可用性接続の要件、そして SSE 経由でのみ配信されるサーバーメッセージです（MCP specification PR #206）。

A2A はまだストリーミングモードで SSE を使用しています。SendStreamingMessage メソッドはタスク更新を SSE イベントとして配信します——トークン差分、アーティファクトチャンク、状態遷移です。これは A2A にとって正しい選択です。なぜならストリーミングは一方向（サーバーからクライアント）であり、クライアントの制御メッセージ（キャンセル、サブスクライブ）は個別の JSON-RPC 呼び出しを通じて行われるからです（A2A protocol）。SSE はシンプルで、標準 HTTP で動作し、本質的にサーバープッシュであるワークロードに WebSocket のセッション管理を必要としません。

WebSocket —— MCP が標準化しなかった双方向オプション

WebSocket はクライアントとサーバー間の永続的で双方向の接続を提供します。HTTP アップグレードハンドシェイクの後、接続は開いたままになり、両側がいつでもメッセージを送信できます。これは単一チャネルで真の双方向通信を必要とするアプリケーションに適したプリミティブです：チャット、共同編集、マルチプレイヤーゲーム、取引ダッシュボード（Ably）。

AI エージェントの場合、双方向のケースは現実のものです。エージェントワークフローは実行中にクライアントからサーバーへのメッセージを必要とします：生成のキャンセル、タスク中のエージェントのステアリング、ツール呼び出しの承認または拒否、フォローアップコンテキストの送信です。SSE では、これらのそれぞれが個別の HTTP リクエストです。WebSocket では、トークンストリームと同じ接続に乗ります（WebSocket.org）。

MCP 仕様は WebSocket を標準化していません。カスタムトランスポートとして利用可能です——仕様は「クライアントとサーバーは追加のカスタムトランスポートメカニズムを実装してもよい」と述べており、JSON-RPC メッセージ形式を保持する限り——しかし標準トランスポートは stdio（ローカルサーバー用）と Streamable HTTP（リモートサーバー用）です（MCP specification）。GitHub issue（#493）が HTTP モデルを簡素化するために WebSocket を標準トランスポートとして追加することを提案しましたが、採用されずにクローズされ、仕様は代わりに Streamable HTTP に移行しました（GitHub）。

MCP が WebSocket を標準化しなかった理由は運用上のものであり、技術的なものではありません。WebSocket はサーバーが永続的な接続を維持し、セッションの健全性を管理し、再接続ロジックを処理し、切断された接続に対処することを要求します。これは SSE を負担にしたのと同じステートフル接続の負担です。MCP 作者はステートレスサーバーを望んでいました——任意のインスタンスが任意のリクエストを処理でき、共有セッションストアなしで、プレーンなラウンドロビンロードバランシング——そして WebSocket の永続的な接続モデルはその目標に対して機能します。

Streamable HTTP —— MCP が代わりに選んだもの

Streamable HTTP は MCP 仕様の SSE 対 WebSocket 問題に対する回答です。サーバーは POST と GET の両方を処理する単一の HTTP エンドポイント（例：https://example.com/mcp）を公開します。クライアントはすべての JSON-RPC メッセージを POST として送信します。サーバーはプレーンな JSON ボディで応答するか、結果が長時間実行の場合はレスポンスを SSE ストリームにアップグレードできます。主要な設計選択：サーバーは永続的な接続を維持する必要がありません。すべてのリクエストは自己完結型です（MCP specification）。

これにより MCP は長寿命接続要件なしに SSE のストリーミング機能を获得し、セッション管理オーバーヘッドなしに WebSocket の双方向機能を获得します。クライアントは POST（標準 HTTP）でメッセージを送信し、サーバーはオプションの SSE（標準 HTTP）でレスポンスをストリーミングし、サーバーはステートレスにできます（標準 HTTP インフラ）（Bright Data；Auth0）。

セキュリティの議論は具体的です。Auth0 の分析：Streamable HTTP では、「標準的な `Authorization: *** ヘッダーをすべての封筒にスタンプできます。メールルームは最初のメッセージだけでなく、すべてのメッセージのスタンプをチェックします。」旧 SSE トランスポートでは、認証トークンは接続時に一度確立され、永続的な接続がすべての後続メッセージを運びました——セッション ID を盗んだ攻撃者からのメッセージを含めて（Auth0）。

意思決定マトリックス

基準	SSE（非推奨）	WebSocket（カスタム）	Streamable HTTP（MCP 標準）
方向	サーバー → クライアントのみ	双方向	POST（クライアント→サーバー）+ オプションの SSE
接続モデル	長寿命、永続的	長寿命、永続的	リクエストごと（ステートレス）
サーバー状態	ステートフル（接続ごとのセッション）	ステートフル（接続ごとのセッション）	ステートレス（リクエスト間にセッションなし）
ロードバランシング	スティッキーセッションが必要	スティッキーセッションが必要	プレーンラウンドロビン
スケーリング	制限あり（クライアントごとに1接続）	制限あり（クライアントごとに1接続）	高（任意の HTTP インフラ）
認証	接続時	ハンドシェイク時	リクエストごと（すべての POST に Bearer）
再開可能性	なし	なし	なし（しかしステートレスは再開するセッションがないことを意味）
インフラ	SSE 対応プロキシが必要	WebSocket 対応プロキシが必要	標準 HTTP（WAF、LB、CDN、認証プロキシ）
セキュリティ面	セッション ID 盗難（CVE-2026-16496）	永続接続でのセッションハイジャック	トランスポート層になし（盗むセッションなし）
MCP ステータス	非推奨、12ヶ月のサンセット	カスタムトランスポート（非標準化）	2026-03-26 以降の標準リモートトランスポート
A2A ステータス	ストリーミングモードに使用	未使用	未使用（A2A は JSON-RPC over HTTP + SSE を使用）
最適	シンプルなサーバープッシュ（A2A タスクストリーミング）	真の双方向（チャット、コラボ）	エージェントからツールへの呼び出し（MCP）

この表はほとんどの B2B チームが尋ねる質問に答えます：エージェントがリモート MCP サーバー上のツールを呼び出す必要がある場合は、Streamable HTTP を使用してください。エージェントがタスク出力を別のエージェントにストリーミングする必要がある場合は、A2A の SSE ストリーミングモードを使用してください。クライアントがサーバーと同じ頻度でメッセージを送信するリアルタイムの共同作業インターフェースを構築している場合、WebSocket が適切なプリミティブです——ただしそれはカスタムトランスポートであり、プロトコル標準ではありません。

3つのトランスポートの比較：

セキュリティの次元 —— なぜステートレスが重要なのか

ステートレストランスポートの選択を検証した CVE は CVE-2026-16496、HashiCorp の Terraform MCP Server における CVSS 10.0 の認証バイパスです。この脆弱性はステートフルな streamable-HTTP トランスポートモードに影響しました：別のユーザーの MCP セッション ID を取得したユーザーが、そのユーザーの Terraform 認証情報を使用してツール呼び出しを実行できました。攻撃ベクトルは、サーバーが攻撃者が盗んで再利用できるセッション状態を保持しているためにのみ存在します。ステートレスサーバーには盗むセッションがありません（NVD；The Hacker News）。

これはステートフルなトランスポートモードが単なる運用の複雑さではなく、セキュリティ上の責任であるという本番環境の証拠です。SSE の12ヶ月の非推奨ウィンドウは現在、単なる運用期限ではなくセキュリティ期限です。非推奨の HTTP+SSE トランスポートをまだ実行している 1,227 のサーバーが最も影響を受ける集団であり——セッションハイジャックの攻撃面を抱えている集団です。

ステートレスプロトコルとサーバー側のセッション状態を置き換える明示的ハンドルパターンのより深い扱いについては、MCP 2026-07-28：B2B エージェントデプロイメントにおけるステートレスプロトコルの意味を参照してください。

A2A が異なる点 —— そしてなぜ機能するのか

A2A はストリーミングに SSE を使用し、Streamable HTTP ではありません。違いはワークロードです。MCP ツール呼び出しは短いリクエスト/レスポンス操作です——データベースのクエリ、レコードの取得、計算の実行。サーバーはリクエストを処理し結果を返します。ストリーミングはオプションで稀です。A2A タスクは明示的なライフサイクル管理を伴う長時間実行操作です——2分かかる価格評価、1時間かかるコンプライアンスチェック。ストリーミングは進行状況の更新であり、結果自体ではありません。

A2A の SSE ストリーミングはサーバープッシュのみであり、タスクの進行にとって正しい方向です：タスクに取り組むエージェントが呼び出し元エージェントに更新を送信します。呼び出し元エージェントの制御メッセージ（キャンセル、更新のサブスクライブ）は個別の JSON-RPC 呼び出しを通じて行われます。制御チャネルが個別の標準 HTTP リクエストであるため、ストリーミングチャネルで双方向通信は必要ありません（A2A protocol；Google Developers Blog）。

これがトランスポートの問題が配管であり、アーキテクチャではない理由です。MCP と A2A は異なるワークロードを持つため異なるトランスポートを使用しますが、どちらも標準 HTTP 上に構築されています。プロトコルのセマンティクス——MCP のステートレスなツール呼び出しと A2A のステートフルなタスクライフサイクル——がエージェント通信を機能させるものです。トランスポートはメッセージを運びます。それはメッセージを定義しません。

完全なプロトコルレベルの比較（スコープ、トランスポート、認証、状態、ヒューマンインザループ）については、A2A vs MCP：エージェント通信に適したプロトコルの選択を参照してください。

WebSocket が正しい答えになる場合

WebSocket は間違っていません。MCP と A2A が標準化していない特定のワークロードに対する正しいトランスポートです：

リアルタイムコラボレーティブインターフェース——クライアントがサーバーと同じ頻度でメッセージを送信する、複数のオペレーターが同じエージェントを同時にステアリングする共有エージェントダッシュボード。
高頻度の双方向通信——HTTP リクエストのオーバーヘッドがプロヒビティブな、同じチャネルで市場データを受信し注文を送信する取引エージェント。
カスタム MCP トランスポート——標準トランスポートが適合しない場合、仕様は JSON-RPC メッセージ形式とライフサイクル要件を保持する限りカスタムトランスポートを明示的に許可します（MCP specification）。

トレードオフは運用の複雑さです。長寿命の双方向接続の維持には、セッションの健全性、再試行、切断された接続、メッセージプロトコルに対する明示的なロジックが必要です（Nimble Way）。ほとんどの B2B エージェントデプロイメント——NetSuite を呼び出すエージェント、価格エージェントに委譲する調達エージェント——では、この複雑さはワークロードによって正当化されません。

ステートレスのトレンド

業界の方向性は明確です。MCP は2026年7月28日にステートレスになりました。A2A はステートフルなタスクマシンを使用しますが、トランスポートはステートレスです（HTTP + SSE、サーバー上に永続的なセッションなし）。9月17日の AGNTCon+MCPCon Europe セッション——「Stateless: The Future of MCP Transports」、Kurtis Van Gent（Google）と Shaun Smith（Hugging Face、MCP Transport Working Group メンテナー）により発表——はステートレストランスポート方向に特化した最初の主要カンファレンスセッションです（Linux Foundation；sched.com）。

Shaun Smith は同じカンファレンスでキーノートも行います：「Getting to Stateless MCP: In Production」——これはステートレストランスポートが仕様から本番デプロイメントガイダンスへと移行していることを示します。非推奨 SSE トランスポートを実行しているチームにとって、12ヶ月の移行ウィンドウ（2027年7月終了）が運用期限です。セキュリティ期限はより早い：サーバーがステートフル SSE トランスポートを実行する毎日は、CVE-2026-16496 が悪用するセッションハイジャック面を抱える毎日です。

エージェント通信における WebSocket vs SSE の問題には明確な答えがあります：MCP に基づいて構築している場合はどちらでもない。Streamable HTTP を使用してください。A2A タスク出力をストリーミングする場合は SSE を使用してください。ワークロードが真に双方向であり、運用の複雑さが正当化される場合にのみ WebSocket を使用してください。トランスポートは配管です。プロトコルのセマンティクス——ステートレスなツール呼び出し、ステートフルなタスクライフサイクル、明示的ハンドル、ヒューマンインザループ状態——がエージェントシステムを本番で機能させるものです。