MCP Streamable HTTP移行設計——セッション管理・後方互換・水平スケール

Q: Streamable HTTPとは何か

Streamable HTTPは、単一の/mcpエンドポイントでPOST・GETを受け付け、応答をapplication/jsonとSSEストリームの間で動的に切り替えられるMCPの標準トランスポートです。MCP 2025-06-18仕様でHTTP+SSEを公式に置き換えました。

Q: 接続の再開性（Resumability）はどう実装するか

MCP仕様はSSEイベントIDとLast-Event-IDヘッダーによる再開メカニズムを定義します。サーバーがストリームごとに一意のイベントIDを付与し、クライアントが再接続時にLast-Event-IDで再開位置を指定します。接続断はリクエストキャンセルと同義ではありません。

エンタープライズ環境でMCPサーバーを本番運用している組織が直面する共通の壁がある。ロードバランサーでスティッキーセッションが必要になり、オートスケールが機能しない。AtlassianのRovoは2026年6月30日をもってHTTP+SSE廃止を宣言し、Keboolaはすでに2026年4月1日に廃止を実施済みだ。MCP 2025-06-18仕様が導入したStreamable HTTPは、こうした課題に対するプロトコル層の回答だ。

Streamable HTTPとは何か

Streamable HTTPは、単一の/mcpエンドポイントでPOST・GETを受け付け、応答をapplication/jsonとSSEストリームの間で動的に切り替えられるMCPの標準トランスポートです。MCP 2025-06-18仕様でHTTP+SSEを公式に置き換えました。

旧HTTP+SSEトランスポート（2024-11-05仕様）は2つのエンドポイントを必要とした。GETでSSEに接続し、サーバーがendpointイベントを返してから初めてPOSTでリクエストを送る手順だ。Streamable HTTPはこれを単一のMCPエンドポイント（例: https://example.com/mcp）に統合した。

クライアントがJSON-RPCメッセージを送る際の基本フローは次の通りだ。

クライアントはAccept: application/json, text/event-streamを付けてHTTP POSTを送る
サーバーがシンプルなリクエスト/レスポンスの場合: Content-Type: application/jsonで1つのJSON-RPCレスポンスを返す
サーバーがストリーミング（通知・進捗を含む）の場合: Content-Type: text/event-streamでSSEを開始し、途中でServer-to-Client通知を送りながら最終レスポンスを返す

クライアントはGETでMCPエンドポイントにSSE接続を開いて、サーバー起点のリクエストや通知を受信することもできる。この設計により、LLM呼び出しを伴う長時間エージェント操作でも単一エンドポイントで制御できる。

セッション管理の設計

Streamable HTTPのセッション管理はMcp-Session-Idヘッダーで実現します。サーバーが初期化レスポンスでセッションIDを付与し、以降の全リクエストにクライアントがヘッダーとして添付します。セッションIDはUUIDかJWTで暗号学的に一意にする必要があります。

セッションIDの仕様要件

仕様が規定する主な要件は以下の通りだ。

セッションIDはInitializeResultを含むHTTPレスポンスのMcp-Session-Idヘッダーに付与する（サーバーは任意）
セッションIDを受信したクライアントは、以降の全HTTPリクエストにMcp-Session-Idヘッダーを含める（MUST）
セッションIDはグローバルに一意かつ暗号学的に安全であること（UUID・JWT・暗号ハッシュ等）
セッションIDはASCII可視文字（0x21〜0x7E）のみ使用可

セッション失効時、サーバーは当該セッションIDを含むリクエストにHTTP 404を返す。クライアントは404受信後にセッションIDなしで新規InitializeRequestを送り直して再確立しなければならない（MUST）。クライアントがセッションを終了する場合は、Mcp-Session-Idヘッダーを付けてMCPエンドポイントへHTTP DELETEを送る。

ステートレス運用と水平スケール

セッションIDを割り当てないステートレスサーバーは、任意のリクエストを任意のインスタンスが処理できる。AWS ALBやCloudflare Load Balancerなどの標準L7ロードバランサーがスティッキーセッション設定なしでそのまま使えるため、オートスケールグループとの組み合わせが素直に機能する。

MCP公式ブログ（2025年12月）の「Future of MCP Transports」では、2026年Q1のSpec Enhancement ProposalsでMcp-Session-Idをプロトコル層から除去しフル・ステートレス化する方向性が示されている。エンタープライズの水平スケール環境を前提にする場合、今からステートレスMCPサーバーを設計しておくと将来の移行コストが下がる。

接続の再開性（Resumability）はどう実装するか

MCP仕様はSSEイベントIDとLast-Event-IDヘッダーによる再開メカニズムを定義します。サーバーがストリームごとに一意のイベントIDを付与し、クライアントが再接続時にLast-Event-IDで再開位置を指定します。接続断はリクエストキャンセルと同義ではありません。

再開機能を実装する場合の設計要点は3点だ。

サーバーはSSEイベントにidフィールドを付与する（セッション内でストリームを跨いでグローバルにユニーク）
クライアントが切断後に再接続する際、HTTP GETにLast-Event-IDヘッダーを付けてMCPエンドポイントに送る
サーバーはLast-Event-ID以降のイベントを再送しストリームを再開する（他ストリームのメッセージは再送してはならない: MUST NOT）

仕様は「切断をリクエストのキャンセルと解釈すべきでない（SHOULD NOT）」と明示する。キャンセルが必要な場合はCancelledNotificationを明示的に送る。本番環境でLLM呼び出しを含む長時間エージェント操作を扱う場合、このセマンティクスを正確に実装しないとリトライストームが発生する。

セキュリティ要件と本番実装チェックリスト

Streamable HTTP実装はOriginヘッダー検証・認証・ローカルホスト限定バインドの3点が必須または強く推奨されます。Originヘッダー検証の省略はDNSリバインディング攻撃に直結します。

要件	仕様レベル	内容
`Origin`ヘッダー検証	MUST	全接続でOriginを検証しDNSリバインディングを防ぐ
ローカルバインド（ローカル実行時）	SHOULD	`0.0.0.0`でなく`127.0.0.1`のみにバインドする
認証実装	SHOULD	OAuth 2.1ベースの認可フローを実装する
`MCP-Protocol-Version`ヘッダー	MUST（初期化後）	全リクエストに`MCP-Protocol-Version: 2025-06-18`を付与する

MCP-Protocol-Versionヘッダーが無効または未サポートの場合、サーバーは400 Bad Requestを返す（MUST）。ヘッダーを受信しない場合のデフォルトは2025-03-26として後方互換を保つ。OAuth 2.1の詳細な実装についてはMCPサーバーのOAuth 2.1認可フローも参照のこと。

後方互換と移行パスの設計

旧HTTP+SSEクライアントをサポートするサーバーは旧エンドポイント群と新MCPエンドポイントを並行提供します。クライアント側は新仕様でのPOST試行→失敗時にSSEフォールバックする「自動判定パターン」で新旧を透過的に吸収できます。

サーバー側の並行稼働戦略

旧トランスポートクライアントと共存する場合の推奨方針は次の通りだ。

旧HTTP+SSEのSSEエンドポイント（GET）とPOSTエンドポイントを既存のまま維持する
新しい/mcpエンドポイントをパラレルに追加し、新仕様クライアントに対応する
MCP-Protocol-Versionヘッダーで新旧を判別し、対応するコードパスに振り分ける

クライアント側の自動判定パターン

新旧サーバーを透過的に扱う実装の流れ：

サーバーURLへInitializeRequestをPOSTする
成功（2xx）→ Streamable HTTPとして通信継続
HTTP 4xx（405/404等）→ GETに切替えて旧HTTP+SSEのSSEストリームを試みる。endpointイベントが返ってくれば旧トランスポートで処理する

Atlassian Rovo（2026年6月30日廃止）やKeboola（2026年4月1日廃止済み）など大規模MCPクライアントが廃止期限を宣言し始めている。エンタープライズ向けMCPサーバーを提供している場合は、2026年内に移行を完了させる計画が必要だ。

KuuではRDEサービスを通じて、MCP Streamable HTTP移行のアーキテクチャ設計と本番実装をエンタープライズ向けに提供している。ステートレス化・OAuth 2.1認可フロー統合・CI/CDパイプラインへの組み込みを含む設計支援が可能だ。

参考

まとめ

MCP 2025-06-18仕様のStreamable HTTPは、旧HTTP+SSEの「2エンドポイント問題」とスティッキーセッションによるスケーリング制約を解消するプロトコル設計だ。エンタープライズ実装の要点をまとめる。

単一エンドポイント化: /mcpのPOST/GET両対応に統一。応答はJSON単体かSSEストリームかをサーバーが動的に選択する
セッション管理: UUID/JWTベースのMcp-Session-Idを実装するか、ステートレスモードで水平スケール優先にするかを設計段階で決定する
再開性: Last-Event-IDベースのSSEイベントID管理を実装し、接続断時のメッセージロストとリトライストームを防ぐ
セキュリティ: Originヘッダー検証（MUST）とOAuth 2.1認可を組み合わせ、MCP-Protocol-Versionヘッダーの処理を実装する
移行期限: 2026年内の大手MCPクライアント廃止宣言に備え、旧HTTP+SSEとの並行稼働期間を計画に組み込む

MCP Streamable HTTP移行の設計・実装はKuuの RDEサービスにご相談ください。