MCPのHTTP+SSEが正式に非推奨に — Streamable HTTPへの移行期限
MCPのHTTP+SSEトランスポートは2025-03-26から非推奨でしたが、2026-07-28で正式なDeprecated状態になりました。移行期限と、いま何をすべきかを示します。
MCPのHTTP+SSEトランスポートは何が変わったのか
MCPのHTTP+SSEトランスポートは、プロトコルバージョン2025-03-26からずっと非推奨でした。それが2026-07-28の仕様改訂(SEP-2596)で、新しく制定された機能ライフサイクルポリシーのもと、正式な「Deprecated」状態として登録されました。実質的な扱いが変わったわけではありません。これまで文章で「非推奨」と書かれていただけの状態に、いつまでに移行すべきかという期限つきの正式な仕組みが付いた、というのが正確なところです。
HTTP+SSEとは、2024-11-05のMCP仕様で定義されていたトランスポートです。サーバーがPOSTエンドポイントとは別にSSE(Server-Sent Events)のGETエンドポイントを持ち、サーバー主導のメッセージをそこで配信する方式でした。現行の後継はStreamable HTTPで、移行先として仕様に明記されています。
MCPの新しい機能ライフサイクルポリシーとは
SEP-2596が導入したのは、HTTP+SSEという一つのトランスポートの話にとどまらない、仕様全体の機能を管理する枠組みです。仕様に含まれる個々の機能は、Active・Deprecated・Removedの3状態のいずれか一つを取ります。
| 状態 | 意味 | 実装者が取るべき対応 |
|---|---|---|
| Active | 意味現行の仕様リビジョンに含まれる機能 | 実装者が取るべき対応通常どおり規定に沿って実装する |
| Deprecated | 意味仕様には残るが削除が予定されている機能 | 実装者が取るべき対応新規実装では採用しない。既存実装は最短削除日までに移行する |
| Removed | 意味draftから削除され、次の現行リビジョンには存在しない機能 | 実装者が取るべき対応次のリビジョンを対象にする実装はこの機能に依存できない |
ある機能がDeprecatedになるには、それを提案するSEPが必要です。SEPには、代替機能への移行パス(または移行パスが不要である旨)と、削除までに置く最低12か月の猶予期間を明記しなければなりません。この12か月は、機能が最初にDeprecatedと記された仕様リビジョンのリリース時点から数えます。猶予期間が明けて最初にCurrentとしてリリースされたリビジョンで、その機能は初めて削除の対象になり得ます。これが「最短削除日(earliest removal)」です。ただし猶予期間が明けても即座に削除されるわけではなく、実際に削除するかどうかはリリース準備の際にコアメンテナが判断します。
唯一の例外が、公開済みのセキュリティアドバイザリがある、または実際に悪用が確認されているといった深刻なセキュリティリスクを伴う機能で、この場合はコアメンテナの承認を得て猶予期間を短縮できます。それでもDeprecatedになってから最短削除日までは90日以上を確保しなければならないと定められています。
HTTP+SSEはいつ使えなくなるのか
HTTP+SSEはこのライフサイクルポリシーが作られる前からすでに非推奨だった機能なので、他の新規Deprecated機能とは扱いが異なります。仕様の非推奨機能レジストリでは、HTTP+SSEの最短削除日は「SEP-2596がFinalに達してから3か月後」と記載されています。新規にDeprecatedになった機能に適用される最低12か月のルールではなく、既存の非推奨状態をそのまま引き継ぐ形の、より短い移行期間が設定されています。
同じ2026-07-28の改訂では、Roots・Sampling・LoggingもSEP-2577で新規にDeprecated登録されました。こちらは通常どおり最低12か月ルールが適用され、最短削除日は2027-07-28以降です。SamplingのincludeContextパラメータが取れる"thisServer"と"allServers"という値も、HTTP+SSEと同じSEP-2596の移行措置で登録されています。削除日はSampling機能自体の削除日に従うという入れ子の扱いです。
HTTP+SSEの3か月という猶予は、Roots・Sampling・Loggingの12か月ルールより明確に短くなっています。すでに1年以上前から非推奨だった機能を正式な枠組みに乗せ直したという経緯の違いが、そのまま期間の違いに表れています。
このポリシーのもとで実際に削除された機能は、まだ一つもありません。Deprecatedはあくまで削除の予告であり、猶予期間中は仕様上も実装上も問題なく動き続けます。
SDKは非推奨をどう教えてくれるのか
機能ライフサイクルポリシーは、SDK側の対応義務も定めています。Tier 1に分類される公式SDK(TypeScript SDKなど)は、機能がDeprecatedになったリビジョンがCurrentとしてリリースされたら、次のリリースまでに対応が必要です。その機能のAPIを各言語のネイティブな仕組み(TypeScriptなら@deprecatedのJSDocタグ)でマークし、可能ならDeprecationWarningのような実行時警告も出すことになっています。HTTP+SSEを使うコードをSDK経由で書いていれば、エディタの警告やコンソールログでこの変更に気づける設計です。SDKがこの義務を継続的に果たせない場合は、Tier格下げの対象になるという運用も定義されています。
Streamable HTTP自体も2026-07-28で変わった — 何を直す必要があるか
ここで注意したいのは、移行先であるStreamable HTTP自体もこの2026-07-28で仕様が変わったという点です。具体的には、サーバー主導メッセージ用のGETストリームエンドポイントと、プロトコルレベルのセッション(Mcp-Session-Idヘッダー)が削除されました。セッション廃止の背景と移行方法はMCPのセッションID(Mcp-Session-Id)はなぜ廃止されたのかで扱っています。
サーバー・クライアント間の対話的なやり取り(サンプリングやエリシテーション)も、GETストリームで独立したリクエストを送る方式から、レスポンス自体にリトライを促す往復パターンへ置き換わっています。この仕組みはMRTR(Multi Round-Trip Requests)と呼ばれます。詳細はMCPのMRTRとはにまとめています。つまり「HTTP+SSEからStreamable HTTPへ移す」という一段階の移行に見えて、実際には移行先のStreamable HTTP自体も同じ改訂でかなり作り替わっています。古いStreamable HTTP実装(2025-03-26〜2025-11-25版)を持つサーバーも、あわせて更新が必要になる場面があります。
2026-07-28のStreamable HTTPだけに対応するサーバーが、旧いHTTP+SSEクライアントからのトラフィックを受けた場合の動きも決まっています。通常のPOSTへの応答が失敗した後、クライアント側がGETリクエストでendpointイベントを待つフォールバック動作に入ります。双方向の後方互換を保ちたいサーバーは、新旧両方のエンドポイントを並行して待ち受ける構成を取ることになります。
Claude CodeでSSEサーバーを使っているならどうするか
Claude CodeのCLIドキュメントは、この仕様上の非推奨と歩調を合わせて、SSEトランスポートをすでに非推奨と案内しています。claude mcp addでサーバーを追加するとき、HTTPで届くサービスには--transport httpが推奨オプションです。SSEエンドポイントしか提供していないサービスに限って、--transport sseを使うという位置づけになります。
# 推奨: HTTPトランスポートで追加する
claude mcp add --transport http notion https://mcp.notion.com/mcp
# SSEエンドポイントしか無いサービスに限って使う(非推奨扱い)
claude mcp add --transport sse asana https://mcp.asana.com/sse自分で運用しているMCPサーバーがSSEエンドポイントしか持たないなら、Streamable HTTPへの対応を進めるのが移行の本筋です。Claude Codeに接続する側の設定手順はClaude Code MCP設定ガイドを参照してください。サーバー自体をStreamable HTTP対応で組み直す手順はMCPサーバー自作ガイドにまとめています。SSEのままの外部サーバーに依存しているだけの立場なら、自分側で今すぐ直せる部分はありません。提供元がStreamable HTTPへ対応するのを待つことになります。
移行でつまずきやすい点
HTTP+SSEからStreamable HTTPへの移行そのものは仕様上シンプルですが、実際の作業では次の点で足を止めることが多くあります。
- エンドポイントの付け替えだけで移行が完了すると思い込む。前段で触れたとおり、Streamable HTTP自体が2026-07-28でセッションとサーバー主導リクエストの扱いを変えています。旧いStreamable HTTP実装(2025-03-26〜2025-11-25版)からの移行でも、
Mcp-Session-Idに依存したコードや、サーバーからの独立したリクエスト送信を前提にしたコードは書き直しが必要です。 - 後方互換を「両対応すれば安全」と考えて期限を意識しない。新旧両方のエンドポイントを並行して待ち受ける構成は移行期間中は有効ですが、HTTP+SSEはあくまで最短削除日が付いた機能です。猶予期間があるうちに旧エンドポイントへの依存を減らしておかないと、実際の削除が決まったタイミングで慌てることになります。
- クライアント側のフォールバック処理を試さずに公開する。POSTが失敗した後にGETで
endpointイベントを待つという後方互換のフォールバックは、実装によって細部の挙動が揺れやすい箇所です。新旧両方のクライアントで実際に接続を試してから公開するのが安全です。
まとめ
HTTP+SSEは2025-03-26からずっと非推奨でした。それが2026-07-28で新設された機能ライフサイクルポリシーのもとに正式登録され、SEP-2596がFinalに達してから3か月後という具体的な最短削除日が付きました。影響を受けるのは、自作あるいは自社運用のMCPサーバーがSSEエンドポイントに依存している場合です。移行先のStreamable HTTP自体もこの改訂でセッションとMRTRまわりが変わっているため、単純なエンドポイントの付け替えでは済まないケースがあります。Claude Codeから接続する側では、--transport httpを既定にしておけば、この移行を意識する必要はほとんどありません。