Claude Media
MCPのHTTP+SSEが正式に非推奨に — 最短削除日とStreamable HTTPへの移行
MCP解説

MCPのHTTP+SSEが正式に非推奨に — 最短削除日とStreamable HTTPへの移行

MCPのHTTP+SSEトランスポートは2025-03-26から非推奨でしたが、2026-07-28で正式なDeprecated状態になりました。削除可能時期と、立場別の確認点を示します。

読了目安 約10分

MCPのHTTP+SSEトランスポートは何が変わったのか

HTTP+SSEは、プロトコルバージョン2025-03-26からずっと非推奨でした。2026-07-28の仕様改訂(SEP-2596)で、新設された機能ライフサイクルポリシーのもと、正式な「Deprecated」状態として登録されました。動作の扱いが変わったわけではありません。文章で「非推奨」と書かれていただけの状態に、削除可能になる時期を示す仕組みが付いた、というのが実態です。

HTTP+SSEは、2024-11-05のMCP仕様で定義されたトランスポートです。サーバーは2本のエンドポイントを持ちます。クライアントが接続して受信するSSE(Server-Sent Events)用と、メッセージを送るPOST用です。接続時にサーバーがendpointイベントでPOST先のURIを知らせ、以降のクライアントのメッセージはそこへ送られます。サーバーのメッセージはSSEのmessageイベントで届きます。

後継のStreamable HTTPは、MCPエンドポイント1本でPOSTを受ける形です。移行先として、2026-07-28の仕様の非推奨機能レジストリにも明記されています。

あゆみ

HTTP+SSEが削除可能になるまでの経路

  1. 2024-11-05HTTP+SSEを定義

    当時唯一のリモートトランスポートでした。

  2. 2025-03-26Streamable HTTPが登場

    仕様の注記でHTTP+SSEは非推奨とされました。レジストリの「Deprecated in」もこの日付です。

  3. 2026-07-28ライフサイクルポリシーで正式にDeprecated

    SEP-2596がHTTP+SSEをレジストリに登録しました。

  4. SEP-2596がFinalに達してから3か月後最短削除日(earliest removal)

    削除の資格を得る日で、削除が決まる日ではありません。

機能ライフサイクルポリシーは何を決めたのか

SEP-2596が導入したのは、HTTP+SSE一つに限らず、仕様の機能全体を管理する枠組みです。個々の機能はActive・Deprecated・Removedの3状態のどれか一つを取ります。

状態意味実装者への期待
Active意味現行リビジョンに含まれる機能実装者への期待規定どおり実装する
Deprecated意味仕様には残るが削除が予定されている機能実装者への期待新規実装では採用せず、既存実装は最短削除日までに移行する
Removed意味draftから削除され、次の現行リビジョンに存在しない機能実装者への期待次のリビジョンを対象にする実装は依存できない

Deprecatedにするには、提案するSEPが必要です。SEPには移行パス(不要ならその旨)と、削除までの猶予期間を書きます。猶予期間は最低12か月で、機能が最初にDeprecatedと記されたリビジョンのリリース時点から数えます。猶予が明けて最初にCurrentとして出たリビジョンで、その機能は削除の対象になり得ます。

猶予が明けても自動では消えません。削除はコアメンテナがリリース準備の中で決め、Deprecatedのまま長く残る機能もあり得ると書かれています。唯一の例外は、公開済みのセキュリティアドバイザリや実際の悪用があり、その場で取れる緩和策がない機能です。この場合はコアメンテナの承認で猶予を縮められますが、Deprecatedから最短削除日まで90日以上は確保されます。

HTTP+SSEの削除はいつ可能になるのか

HTTP+SSEは、ポリシーができる前から非推奨だった機能です。そのため他の機能とは起点が違います。レジストリの最短削除日は「SEP-2596がFinalに達してから3か月後」で、12か月ルールの適用外です。レジストリ自身が、HTTP+SSEとincludeContextの値は既に非推奨と書かれていた機能で、SEP-2596が移行規定のもとで再分類したと説明しています。

同じ2026-07-28の改訂で、Roots・Sampling・Logging・Dynamic Client Registrationは新規にDeprecated登録されました。こちらは12か月ルールの対象です。最短削除日は2027-07-28以降の最初のリビジョンになります。SamplingのincludeContextの"thisServer"と"allServers"は、HTTP+SSEと同じSEP-2596で登録されました。削除時期はSampling本体に従います。六つの機能の期限の並びはMCPの非推奨機能レジストリで一覧にしています。

ポリシーのもとで実際に削除された機能は、レジストリ上まだありません。Deprecatedの間、HTTP+SSEは仕様に残ります。

SDKは非推奨をどう知らせるのか

ポリシーは、公式SDKの側の義務も定めています。Tier 1のSDKは、機能がDeprecatedになったリビジョンがCurrentとして出たあと、次のリリースで対応するAPIを各言語の標準の仕組みで非推奨表示にします。表示には、非推奨にしたSEPと最短削除日を、仕組みが許す範囲で添えることが求められます。TypeScriptなら@deprecatedのJSDoc、Javaなら@Deprecated、.NETなら[Obsolete]です。非推奨の機能が使われたときの実行時警告は、PythonのDeprecationWarningのように、できれば出す扱いです。

義務を果たし続けられないSDKは、Tier格下げの手続きの対象になります。Tier 1のSDK経由なら、少なくとも非推奨表示では気づける設計です。

一方で、仕様から機能が消えてもSDKが同時にコードを落とす義務はありません。SDKの対応期間は、各SDKが持つリビジョン対応方針で決まります。

Streamable HTTPも同じ改訂で変わった

移行先のStreamable HTTP自体も、2026-07-28で形が変わりました。サーバー主導メッセージ用のGETストリームのエンドポイントと、プロトコルレベルのセッション(Mcp-Session-Idヘッダー)が削除されています。セッション廃止の背景はMCPのセッションID(Mcp-Session-Id)はなぜ廃止されたのかにあります。

サーバーからの問い合わせも、GETストリーム経由の独立したリクエストではなくなりました。サンプリングやエリシテーションは、レスポンスにリトライを促す往復パターンで扱います。これがMRTR(Multi Round-Trip Requests)で、MCPのMRTRとはに詳細があります。

旧Streamable HTTP(2025-03-26〜2025-11-25)と2026-07-28の仕様は、Last-Event-IDによる再開も含めて形が違います。2026-07-28のみに対応するサーバーが旧クライアントから受けるトラフィックは、次のように扱うよう定められています。

旧クライアントの動き2026-07-28のみ対応のサーバーの応答
MCPエンドポイントへのGET・DELETE2026-07-28のみ対応のサーバーの応答405 Method Not Allowed
Mcp-Session-Idヘッダー付きのリクエスト2026-07-28のみ対応のサーバーの応答ヘッダーを無視し、セッションIDを発行も返送もしない
Last-Event-IDヘッダー2026-07-28のみ対応のサーバーの応答無視する(ストリームは再開できない)

HTTP+SSEのクライアントともやり取りしたいサーバーは、旧来の2本のエンドポイントを新しいMCPエンドポイントと並べて動かし続けます。仕様は、旧POSTエンドポイントと新エンドポイントの統合も可能だが複雑になりがちだ、と書いています。

クライアントが旧サーバーを見分ける手順は仕様の改訂で違う

クライアントが旧サーバーを扱うときの判定は、2025-03-26の仕様と2026-07-28の仕様で条件が変わっています。

手順

2026-07-28の仕様でのHTTP+SSEサーバーの見分け方

  1. 1

    サーバーのURLにPOSTする

    Acceptヘッダーを仕様どおりに付けて、MCPエンドポイントとしてPOSTします。成功すれば、Streamable HTTPに対応したサーバーです。

  2. 2

    失敗した場合は本文を見る

    400・404・405のいずれかで、かつ本文が現行のJSON-RPCエラーでなければ、旧サーバーの疑いがあります。現行のサーバーは、バージョン不一致・不明なメソッド・ヘッダー検証失敗で、認識できるJSON-RPCエラーを返します。

  3. 3

    同じURLにGETしてendpointイベントを待つ

    SSEのストリームが開いて最初にendpointイベントが届けば、旧HTTP+SSEのサーバーです。以降の通信は、すべてそのトランスポートで行います。

2025-03-26の仕様は、POSTでInitializeRequestを送り、HTTP 4xx全般で失敗したらGETへ進む、と書いていました。2026-07-28では対象が400・404・405に絞られ、本文の確認が加わっています。

立場別の確認点

くらべる

立場で変わる対応

サーバー側

MCPサーバーを自分で運用している

SSEエンドポイントしか持たない場合、Streamable HTTPのMCPエンドポイントを追加するのが移行の本筋です。上の表のとおり、旧Streamable HTTPのセッションやGETに依存したコードも、2026-07-28では書き直しの対象になります。組み直しの手順はMCPサーバー自作ガイドにあります。

利用側

外部のSSEサーバーに接続しているだけ

自分で直せる箇所はありません。提供元の対応が前提になります。Claude Codeでの設定は、次の節のとおり接続側のオプションで決まります。

Claude CodeでSSEサーバーを使うときの設定

Claude Codeのドキュメントは、SSEトランスポートを非推奨として案内しています。HTTPで使えるサービスには、HTTPサーバーとして追加します。SSEのエンドポイントしか持たないサービスについても、同じ--transport httpで追加できます。Claude CodeがまずHTTPを試し、サーバーが受け付けなければSSEへ切り替えるためです。この自動切り替えには、v2.1.265以降が必要です。HTTP+SSEにしか対応しないサーバーが最初のリクエストに422などの別の4xxを返す場合は、v2.1.274で接続できるように直っています。

それより古いバージョンで使う場合や、SSEで直接つなぎたい場合は、--transport sseを指定します。v2.1.287で、空の設定ディレクトリを使って次のコマンドを実行したところ、どちらも警告なしで追加できました。

claude mcp add --transport sse asana https://mcp.asana.com/sse
claude mcp add --transport http notion https://mcp.notion.com/mcp

書き込まれた設定ファイルでは、asanaが"type": "sse"、notionが"type": "http"として記録されました。claude mcp add --helpでは、--transportに指定できる値はstdio・sse・httpです。

"mcpServers": {
  "asana":  { "type": "sse",  "url": "https://mcp.asana.com/sse" },
  "notion": { "type": "http", "url": "https://mcp.notion.com/mcp" }
}

SSEで直接つなぐ場合も、--headerで認証ヘッダーを付けられます。

claude mcp add --transport sse private-api https://api.company.com/sse \
  --header "X-API-Key: your-key-here"

JSONで書くときは、urlに対してtypeを必ず指定します。typeが無いエントリはstdioサーバーとして読まれ、urlがあるのにtypeが無いというエラーでスキップされます。HTTPやSSE、WebSocketは、"type": "http"・"sse"・"ws"で区別します。Claude Codeに接続する側の設定全般はClaude Code MCP設定ガイドにあります。

まとめ

削除日はまだ決まっておらず、SEP-2596がFinalに達してから3か月後以降という下限があるだけです。移行時期は、レジストリでその日付が確定するのを見て決める形になります。自前のSSEサーバーは、Streamable HTTPを2026-07-28の仕様に合わせて作れば、旧セッション依存のコードも同時に片付きます。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →