このガイドの中で、あなたは見ることができる：
- MCPトランスポート技術の歴史と、SSEからStreamable HTTPへの移行が起こった理由。
- SSEとは何か、古いMCPバージョンではどのように使われていたのか。
- Streamable HTTPとは何か、そしてMCPの現行バージョンではどのように適用されているのか。
- SSEとStreamable HTTPの比較表。
- プロトコルの仕様に関する最新情報の入手方法
さあ、飛び込もう！
MCPが使用するトランスポート・プロトコルの歴史
MCP（モーダルコンテキスト・プロトコル）は、今日最も人気があり、広く使われているAIプロトコルのひとつだが、プロトコル・バージョン2025-03-26から、HTTP+SSEトランスポート・メカニズムに代わり、ストリーマブルHTTPが採用された。これはプロトコルのアーキテクチャに大きな変化をもたらした。
さて、この2つの輸送メカニズムが何なのかを説明する前に、この変化について理解を深めておこう。
AIプロトコルにトランスポート・メカニズムが必要な理由
MCPのようなAIプロトコルは、プロトコルのアーキテクチャの異なるコンポーネント間の情報交換を容易にするトランスポート・メカニズムを必要とする。
具体的には、MCPは、クライアントとサーバー間のワイヤフォーマットとしてJSON-RPC 2.0を使用する。JSON-RPCメッセージの伝送には、HTTP+SSEやStreamable HTTPなどの標準的なトランスポートメカニズム（stdioのうち、ローカルサーバー上の標準インおよび標準アウトを介した通信用）に依存する。
こうした特殊なトランスポートレイヤーが必要なのは、従来のHTTPのリクエスト・レスポンスモデルは、リアルタイムのAI通信には非効率的だからだ。プレーンなHTTPでは、接続の頻繁なセットアップにより、高いオーバーヘッドとレイテンシが発生するからだ。対照的に、MCPは連続的で低遅延のデータストリームを必要とし、HTTP+SSEとStreamable HTTPはそれを処理するように設計されている。
変更の理由
MCPは当初、リモートシナリオでサーバーからクライアントへのストリーミングを可能にするためにHTTP+SSEを使用していました。しかし、これら3つの大きな制約が、この変更を正当化しました：
- リジューム可能なストリームをサポートしていない。
- サーバーが長寿命で可用性の高い接続を維持する必要がある。
- SSE 経由でのサーバー・メッセージの配信のみを許可する。
Streamable HTTPはこれらの問題に対処する。ステートレス通信を可能にし、SSEのオンデマンド・アップグレードもサポートする。これにより、最新のインフラとの互換性が向上し、より安定した効率的な通信が保証される。
HTTP+SSEからストリーマブルHTTPへの移行の影響
トランスポート・プロトコルとしてHTTP+SSEからStreamable HTTPへの移行は、MCPにとって重要な変化でした。これはプロトコルの実装に顕著な変更をもたらし、多くのサードパーティのMCPクライアントとサーバ・ライブラリを適応させる必要がありました。
ただし、この記事を書いている時点では、MCPクライアントとサーバーは、非推奨のHTTP+SSEトランスポートとの下位互換性を維持できます。
SSE（サーバー送信イベント）
SSE（Server-Sent Events）とは、ウェブクライアントがサーバーからの自動更新を受け取ることを可能にするメカニズムである。これらの更新は “イベント“と呼ばれ、単一の長時間のHTTPコネクションを介して送信されます。
WebSocketとは異なり、SSEは一方向性であり、データはサーバーからクライアントにのみ流れる。SSEは、通常text/event-streamMIMEタイプでフォーマットされたイベントのストリームを、サーバーがこのオープンな接続を介して送信することで機能する。
MCPにおけるHTTP+SSEの使用
こうしてMCPはバージョン2024-11-05でSSEに頼った：
サーバーは2つのエンドポイントを提供しなければならない：
- クライアントが接続を確立し、サーバーからメッセージを受信するための SSE GET エンドポイント。
- クライアントがサーバーにJSON-RPCメッセージを送信するための通常のHTTP POSTエンドポイント。
クライアントが接続すると、サーバーはクライアントがメッセージを送信するために使用するURIを含むエンドポイントイベントを送信する必要があります。その後、クライアントの JSON-RPC メッセージはすべて、この URI への HTTP POST リクエストとして送信されます。
サーバーは、オープンな SSE 接続を介してイベントをストリーミングすることで応答し、永続的なセッションをシミュレートする。詳細には、サーバー・メッセージは SSEメッセージ・イベントとして配信され、その内容はイベント・データ内の JSON としてエンコードされる。
単一応答の場合、サーバーはメッセージを送信し、ストリームを閉じる。継続的な通信では、コネクションはオープンされたままです。
長所と短所
MCPでSSEを使用する主な長所と短所は以下の通りである：
大きな結果のストリーミング：部分的な結果を即座に送信できるため、MCPツールが大規模なデータを処理する間や、外部APIの応答を待つ間の遅延を避けることができます。
イベント・ドリブン・トリガー：アラートやステータスの更新など、変更をクライアントに通知するための未承諾のサーバー・イベントをサポートします。
シンプルさ：標準的なHTTPを使用するため、特別なプロトコルや複雑な設定を必要としません。
単方向のみ：データは SSE チャネル内でサーバからクライアントにのみ流れる。クライアントはメッセージ送信に個別のHTTP POSTリクエストを使用しなければならない。
👎長期間のコネクション・リソースの使用：オープンなコネクションを維持することは、特に規模が大きくなると、多くのサーバー・リソースを消費します。
ストリーミング可能なHTTP
MCPの文脈では、ストリーマブルHTTPとは、純粋なHTTPを使用してクライアントとサーバー間でデータをストリーミングするための手法である。これは、長時間のコネクションを必要としないリアルタイム通信への扉を開くものです。
柔軟性と後方互換性のためにSSEを使用することは可能ですが、このトランスポート メソッドはもはや必要ありません。これにより、MCPは、高可用性の持続的接続を維持するオーバーヘッドなしに、 ステートレスサーバーをサポートすることができる。
ℹ️おまけ：なぜ WebSocket ではなく、ストリーマブル HTTP + オプションの SSE なのか？
- 単純なステートレスRPC呼び出しにWebSocketを使用すると、不必要なネットワークと運用のオーバーヘッドが追加されます。
- ブラウザは、
AuthorizationのようなヘッダーをWebSocketにアタッチすることができず、SSEとは異なり、WebSocketを標準的なHTTPツールで再実装することはできない。 - WebSocket のアップグレードはGET リクエストでのみ動作するため、POST ベースのフローは複雑で、アップグレード手順が必要なため遅くなります。
MCPでストリーミング可能なHTTP
Streamable HTTPトランスポートでは、サーバーは複数のクライアント接続を処理できるスタンドアロン・プロセスとして動作する。通信には標準的な HTTP POST と GET リクエストを使用する。
オプションとして、サーバはSSEを使用して複数のメッセージをクライアントにストリーミ ングすることができます。これは、シンプルなリクエスト/レスポンス・ツールのための基本的なMCPサーバと、ストリーミングやリアルタイムのサーバからクライアントへの通知など、より高度な機能を提供するMCPサーバの両方に対応します。
サーバーは、POSTとGETの両方のメソッドをサポートする単一のHTTPエンドポイント（「MCPエンドポイント」と呼ばれる）を公開しなければなりません。
下図は、Streamable HTTPを使用したMCPクライアントとサーバー間の通信フローを示 しています：
切断された接続を再開し、失われた可能性のあるメッセージを再配信するために、 MCPサーバーはストリームごとにIDを割り当てます。これらのIDは、各ストリーム内でカーソルの役割を果たします。
様々な相互作用が考えられるため、実装の詳細についてはMCPの公式文書を参照してください。
長所と短所
MCPでStreamable HTTPを使用する主な利点は以下の通りである：
ステートレス・サーバーをサポート：常時接続、長寿命コネクションの必要性がなくなります。
プレーンHTTP：SSEを必要とせず、標準的なHTTPサーバーを使用して実装できます。
インフラにやさしい：一般的なHTTPミドルウェア、プロキシ、ホスティングプラットフォームと互換性があります。
下位互換性：以前のHTTP+SSEトランスポートの上に段階的に構築されます。
オプションのストリーミング：必要に応じて、サーバーをSSEにアップグレードし、応答をストリーミングすることができます。
注：本稿執筆時点では、Streamable HTTPトランスポート・メカニズムには、特筆すべき欠点はない。
SSEとストリーマブルHTTPの比較：概要
以下のSSEとStreamable HTTPの表で、2つのトランスポート・メカニズムを比較してください：
| アスペクト | HTTP+SSE | ストリーミング可能なHTTP |
|---|---|---|
| 通信タイプ | 単方向（サーバー → クライアント） | 双方向(GET/POSTによるクライアント↔サーバー) |
| HTTPプロトコルの使用 | ストリーミングにはGET、クライアント・メッセージには個別のPOST | 単一のエンドポイントから標準的なHTTP POSTとGETを使用する。 |
| ステートフルネス | ステートフル | ステートフルだが、ステートレスサーバーをサポート |
| 長時間のHTTP接続が必要 | はい | いいえ |
| 高い可用性が必要 | 接続の持続性 | いいえ、ステートレスまたはエフェメラルなサーバーで動作します。 |
| スケーラビリティ | 限定 | 高い |
| ストリーミング対応 | あり（テキスト/イベントストリーム経由） |
あり（オプションの拡張機能としてSSE経由） |
| 認証サポート | はい | はい |
| 再開と再配達のサポート | いいえ | いいえ |
| 顧客数 | 複数 | 複数 |
| MCPでの使用 | プロトコル・バージョン2025-03-26以降、非推奨 |
プロトコル・バージョン2025-03-26で導入 |
| 下位互換性 | – | SSEベースのクライアントとの完全な下位互換性 |
MCPにおける輸送方法の将来
MCPは2024年11月にリリースされたので、まだ非常に若いプロトコルだ。これを考慮すると、最も広く使われているHTTP 1.1は20年近い歴史がある。
したがって、MCPの仕様がまだ進化していることは驚くことではない。立ち上げから数ヵ月後、コミュニティがSSEからStreamable HTTPへの移行を決定したように、近いうちにさらなる変更が起こるかもしれない。
MCP公式GitHubリポジトリのDiscussionsページをチェックすることで、最新の情報を入手できます。MCPのウェブサイトでは、次期バージョンのプロトコルの最新ドラフトを確認することもできる。
結論
このSSEとStreamable HTTPの比較ブログ記事では、なぜMCPがSSEからStreamable HTTPに移行したのかを学びました。特に、この2つのトランスポート・メカニズムがどのようなもので、人気のAIプロトコルであるMCPの情報伝送にどのような影響を与えるのかを理解していただけたと思います。
ここで説明されているように、非推奨の最新のMCP仕様に準拠したいサードパーティのMCPサーバーは、Streamable HTTPを実装する必要があります。最新で、パワフルで、機能豊富なMCPサーバーをお探しなら、Bright DataのMCPサーバーをご覧ください。
Bright DataのMCPサーバーは、最新バージョンのfastmcpをベースに構築されており、SSEとの下位互換性を維持しながら、Streamable HTTPの完全なサポートを保証します。新鮮なウェブデータ、あらゆるウェブページでのエージェントブラウザとのインタラクションなど、AIワークフローを拡張する20以上のツールを提供します。
完全なチュートリアルについては、AIエージェント開発のためのGoogle ADKとMCPサーバーの統合に関する記事をご覧ください。
今すぐBright Dataのアカウントを無料で作成し、AIエージェントやアプリケーションを強化するためのインフラストラクチャをテストしてください！
