広告掲載
MCP.so
ログイン
ブログに戻る

MCP SSE は非推奨？はい。後継の Streamable HTTP を解説

2026年10月15日MCP.so TeamMCP.so Team

MCP SSE は非推奨？はい。HTTP+SSE トランスポートは仕様 2025-03-26 で非推奨となり、Streamable HTTP に置き換えられました。その後の変更点、クライアント対応状況、移行手順を解説します。

はい。最初の 2024-11-05 版 MCP 仕様にあった HTTP+SSE トランスポートは、仕様リビジョン 2025-03-26 で非推奨となり、Streamable HTTP に置き換えられました。現行の 2026-07-28 版仕様では、新しい機能ライフサイクルポリシーのもとで正式に Deprecated（非推奨）として登録されており、そのポリシーの確定から 3 か月後に削除できるようになります。新しいサーバーは Streamable HTTP を使うべきです。既存の SSE サーバーは、移行期間中もほとんどのクライアントで引き続き動作します。

ひとつ区別しておくべき点があります。フォーマットとしての SSE がなくなるわけではありません。Streamable HTTP も、必要なときはレスポンスを Server-Sent Events でストリーミングします。非推奨になったのは、常時接続の SSE コネクションと 2 本目の POST エンドポイントを組み合わせた古いトランスポート設計です。

新旧の比較

HTTP+SSE（2024-11-05、非推奨）Streamable HTTP（2025-03-26 以降）
エンドポイント2 つ：GET /sse ストリーム + POST /messages?sessionId=...1 つ（例：/mcp）ですべてを処理
接続クライアントごとに常時開いた SSE ストリームメッセージごとに個別の POST。ストリームはそのレスポンスの間だけ存在
レスポンス形式常に SSE ストリームで届く通常の JSON または SSE ストリーム（リクエストごとに選択）
セッション必須、サーバーのメモリに保持2025 年の各リビジョンでは任意、2026-07-28 で削除
サーバーレス／エッジとの相性悪い：長時間接続とスティッキールーティングが必要良い：ステートレスなリクエストを任意のロードバランサーの背後で処理
仕様上の状態2025-03-26 から非推奨現行

なぜ置き換えられたのか

SSE の設計は本番環境での運用が困難でした。各クライアントは接続している間ずっとコネクションを開いたままにします。POST への返信は別のコネクションで返ってくるため、ロードバランサーは両方を同じインスタンスに振り分ける必要がありました。リクエストのタイムアウトが短いサーバーレスプラットフォームでは、安定してホストできませんでした。Streamable HTTP は、単一のエンドポイントと通常のリクエスト／レスポンスのセマンティクスでこれを解決しました。サーバーが SSE に切り替えるのは、最終結果の前に進捗や通知をストリーミングする必要があるときだけです。

2025-03-26 以降の変更点

Streamable HTTP 自体も、導入後に変化しています：

  • 2025-03-26：Streamable HTTP が導入されました。任意のセッション（Mcp-Session-Id）、サーバー起点のメッセージ用の任意のスタンドアロン GET ストリーム、Last-Event-ID による再開可能なストリームを備えていました。
  • 2025-06-18 と 2025-11-25：MCP-Protocol-Version ヘッダーが追加され、認可ルールが厳格化されました。トランスポートの形は変わっていません。
  • 2026-07-28（changelog）：MCP はステートレスになりました。initialize ハンドシェイクとプロトコルレベルのセッションが削除されました。GET ストリームは subscriptions/listen リクエストに置き換えられ、再開機能は削除されました。POST には Mcp-Method と Mcp-Name ヘッダーが必須となり、ゲートウェイはボディを解析せずにルーティングできます。同じリリースで HTTP+SSE は正式に Deprecated へ再分類されました（SEP-2596）。

実際には、2025 年半ばに書かれた「Streamable HTTP」サーバーと今日書かれたサーバーは、通信上の見た目が少し異なります。現行の SDK はどちらにも対応しています。

後方互換性：新旧はどうやって通信するのか

仕様にはフォールバックが定義されているので、異なる時期のクライアントとサーバーでも通信できます：

  • 両方に対応するクライアントは、まず URL に POST します。400、404、405 で失敗した場合は GET を試します。サーバーが SSE の endpoint イベントを返せば、旧トランスポートで続行します。
  • 旧クライアントへの提供を続けたいサーバーは、新しい /mcp エンドポイントと並べて、旧来の /sse と /messages エンドポイントを提供します。
  • 2025 年時代の Streamable HTTP トラフィックを受け取った 2026-07-28 サーバーは、GET/DELETE に 405 を返し、Mcp-Session-Id と Last-Event-ID を無視します。認識できる新しいエラーを含まない 400 を受け取ったクライアントは、initialize にフォールバックします。

公式 SDK v2 はこれをコードとして実装しています：

  • TypeScript（@modelcontextprotocol/server 2.x）：サーバー側はもう HTTP+SSE を一切提供しません。createMcpHandler は Streamable HTTP を提供し、2025 年時代のクライアントにはデフォルトでステートレスに応答します。まだ移行できないデプロイ向けに、凍結されたコピーが @modelcontextprotocol/server-legacy/sse に含まれています。これは非推奨で、v3 で削除される予定です。クライアントには引き続き SSEClientTransport があります。
  • Python（mcp 2.x）：mcp.run(transport="sse") は旧クライアント向けに今も動作しますが、ドキュメントでは新しいものをこの上に作らないよう明記されています。クライアントは引き続き sse_client(...) で接続できます。

クライアントはまだ SSE サーバーに対応している？

今のところ、ほとんどは対応しています。2026 年 10 月時点：

クライアントStreamable HTTP旧 SSE
Claude Code--transport http--transport sse は引き続き使用可能（非推奨と表示）
VS Code"type": "http"まず HTTP を試し、SSE にフォールバック。"type": "sse" も使用可能
Cursorurl エントリ対応
ChatGPT対応対応（リモートサーバーのみ）
MCP Inspector v2/mcp で終わる URL/sse で終わる URL。その他のパスは --transport の指定が必要

「非推奨」というラベルは、今後の方向性を示しています。新しいクライアントやゲートウェイは Streamable HTTP にしか対応しない可能性があります。仕様からこのトランスポートが削除されれば、SDK からも削除されます。

あなたにとっての意味

接続のどちら側にいるかによって変わります：

  • MCP サーバーを使っている場合。 今すぐ何かが壊れることはありません。サーバーのドキュメントが /sse と /mcp の両方の URL を提示しているなら、/mcp を選び、クライアントのトランスポートを HTTP に設定してください。/sse の URL は他の選択肢がないサーバーにだけ使い、それらは移行するか消えるものと考えておきましょう。
  • SSE サーバーを保守している場合。 クライアントがまだ両方のトランスポートに対応している今のうちに、移行を計画してください。新旧のエンドポイントは並行して運用できるので、ユーザーに一斉切り替えを強いる必要はありません。
  • クライアントやゲートウェイを開発している場合。 まず Streamable HTTP を実装してください。SSE フォールバックは、ユーザーがまだ旧サーバーに接続している間だけ残し、使われた回数をログに記録しておけば、いつ削除できるかがわかります。

サーバーがどちらを使っているか見分ける方法

  • /sse で終わる URL はほぼ確実に旧トランスポートです。/mcp は通常 Streamable HTTP を意味します。
  • 簡易チェック：Accept: application/json, text/event-stream を付けて MCP リクエストを POST します。Streamable HTTP サーバーは JSON または SSE の message イベントを返します。旧方式のみのサーバーは、通常 POST に 404/405 を返し、GET でのみストリームを開きます。
  • または、MCP Inspector に --transport http で接続させ、成功するかを確認します。

サーバー開発者向けの移行手順

  1. SDK をアップグレードする。 TypeScript：@modelcontextprotocol/sdk 1.x から @modelcontextprotocol/server 2.x へ移行します（アップグレードガイドには codemod があります）。Python：mcp 2.x へ。FastMCP は MCPServer に名前が変わっています。
  2. トランスポートの配線を置き換える。 TypeScript：SSEServerTransport と /sse・/messages ルートを削除し、/mcp などの 1 つのルートで createMcpHandler(factory) を提供します。Python：transport="sse" を transport="streamable-http" に変更します。
  3. 状態をコネクションの外に出す。 SSE セッションごとに保持していたもの（ログイン中のユーザー、カーソル、キャッシュ）は、認証済みユーザーやツール引数として渡される ID をキーにして、自前のストレージに置きます。
  4. 旧エンドポイントをしばらく残す。 既存の設定が動き続けるよう /mcp の横で凍結版の SSE トランスポートを提供し、/sse にどれだけトラフィックが来ているかをログに記録します。
  5. 公開 URL を更新する。 README、レジストリの server.json（remotes に "type": "streamable-http"）、そして MCP.so の掲載情報を /mcp に向けて更新します。
  6. 両方の世代をテストする。 Inspector で、新しいエンドポイントには --transport http、古いエンドポイントには --transport sse を使ってテストします。トラフィックがゼロになったら、あるいは仕様から削除される前に、/sse を削除します。
  7. プロキシ設定を見直す。 Streamable HTTP も一部のレスポンスはストリーミングするため、nginx などのプロキシでは text/event-stream のレスポンスバッファリングを無効にし、適切なタイムアウトを設定してください。

移行したサーバーのホスティングについては、MCP サーバーのデプロイ方法を参照してください。プロトコルのおさらいは MCP の仕組みをどうぞ。

次のステップ

MCP サーバーディレクトリで、すでに Streamable HTTP エンドポイントを提供しているサーバーを探してみましょう。Sentry、Notion、GitHub などの公式リモートサーバーは、現在の構成を学ぶうえで良い参考になります。

よくある質問

MCP SSE は非推奨ですか？

はい。HTTP+SSE トランスポートは MCP 仕様 2025-03-26 で非推奨となり、Streamable HTTP に置き換えられました。2026-07-28 版仕様では正式に Deprecated として登録されており、新しいサーバーで採用すべきではありません。

MCP の SSE と Streamable HTTP の違いは何ですか？

旧 SSE トランスポートは 2 つのエンドポイントと、クライアントごとの常時接続ストリームおよびサーバー側セッションを必要としました。Streamable HTTP は 1 つのエンドポイントですべてのメッセージを POST で送り、サーバーは通常の JSON か、ストリーミングが必要なときだけ短命な SSE ストリームで応答します。

Streamable HTTP でも SSE は使われますか？

はい、レスポンス形式としては使われます。Streamable HTTP サーバーは 1 つのレスポンスの中で進捗や通知を Server-Sent Events としてストリーミングできますが、常時接続の SSE や別の messages エンドポイントはもうありません。

既存の MCP SSE サーバーは動かなくなりますか？

今すぐではありません。Claude Code、VS Code、Cursor、ChatGPT などほとんどのクライアントは今も SSE サーバーに接続できますが、仕様から削除できる状態になっているため、Streamable HTTP への移行を計画し、旧トラフィックがなくなるまで新旧のエンドポイントを並行運用してください。
広告掲載