Nodeflare
記事一覧

MCPにおけるstdio・SSE・Streamable HTTPの違いを徹底解説

MCPのトランスポートであるstdio・SSE・Streamable HTTPの違いを仕様レベルから解説。SSEが廃止された理由、Streamable HTTPが解決した問題、ユースケース別の選び方、SSEからの移行手順まで実務目線でまとめます。

MCPサーバーを作るとき、最初に直面するのが「トランスポートをどれにするか」という選択です。stdio・SSE・Streamable HTTP——三つの名前は目にするものの、何が違うのか、どれを使えばいいのか、なぜSSEはなくなったのか、整理できている人は意外と少ない。

この記事ではMCPのトランスポート層を仕様レベルから実務レベルまで一気に解説します。

📌 はじめに：Nodeflare のご紹介

GitHubで公開されているMCPサーバーを数分でリモートデプロイできるサービス Nodeflare を提供しています。Streamable HTTPで動くリモートMCPをすぐに試せます。

👉 Nodeflare を使ってみる

アジェンダ

  1. トランスポートとは何か——MCPのアーキテクチャを整理する
  2. stdio：ローカルの標準
  3. SSE（HTTP+SSE）：最初のリモートトランスポートと廃止の経緯
  4. Streamable HTTP：現在の標準
  5. 三者の比較表
  6. どれを選ぶべきか——ユースケース別の判断基準
  7. SSEからStreamable HTTPへの移行方法
  8. 今後の動向

1. トランスポートとは何か

MCPの仕様はざっくり二層に分かれています。

  • プロトコル層：メッセージの構造・ツールの定義・リソースの管理など、「何をやりとりするか」を定義する層。JSON-RPC 2.0を使います。
  • トランスポート層：そのメッセージを「どうやって運ぶか」を定義する層。

トランスポートはあくまで「配送手段」なので、トランスポートが変わってもツールのロジックは変わりません。同じサーバーを環境変数一つでstdioにも Streamable HTTP にも切り替えられるのはそのためです。

MCPのトランスポートの歴史はシンプルです。

時期仕様バージョン変更内容
2024年11月2024-11-05stdio と HTTP+SSE を標準として策定
2025年3月2025-03-26Streamable HTTP を導入、SSEを正式に非推奨化
2025年11月最新stdio と Streamable HTTP が二本柱。SSEは後方互換のみ

2. stdio：ローカルの標準

仕組み

stdioはその名の通り、標準入出力（stdin/stdout）を使ってMCPクライアントとサーバーがやりとりするトランスポートです。ClaudeなどのMCPクライアントがサーバープロセスを子プロセスとして起動し、そのプロセスのstdinにJSON-RPCメッセージを書き込み、stdoutから応答を受け取ります。

Claude Desktop
  └─ 子プロセスとしてMCPサーバーを起動
       ├─ stdin  → リクエストを送る
       └─ stdout ← レスポンスを受け取る

ネットワークは一切介在しません。プロセス間通信なので、レイテンシはほぼゼロです。

設定例

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"],
      "env": {}
    }
  }
}

特徴

メリット

  • 設定がシンプル。コマンドとパスを書くだけ
  • 低レイテンシ。ネットワークオーバーヘッドがない
  • 認証が不要。プロセスの起動権限がそのままアクセス権限になる
  • プロセス分離が明確。クライアントが終了すればサーバーも終了する

デメリット

  • 同一マシン上でしか動かない
  • 接続できるクライアントは基本的に1つ
  • Webアプリや別マシンからは利用不可
  • チームで共有できない

向いているケース

  • 個人開発・ローカル開発
  • ファイルシステムやローカルリソースへのアクセス
  • まずMCPを試してみたいとき

3. SSE（HTTP+SSE）：最初のリモートトランスポートと廃止の経緯

仕組み

SSE（Server-Sent Events）を使ったトランスポートは、2024年11月の最初のMCP仕様でstdioと並ぶリモート向けの選択肢として登場しました。HTTPを使うため、ネットワーク越しのアクセスが可能になります。

ただし、この方式はエンドポイントが2つ必要でした。

クライアント → POST /messages  （リクエストの送信）
クライアント ← GET  /sse       （レスポンスの受信、常時接続）

リクエストを送るPOSTエンドポイントと、サーバーからのメッセージを受け取るSSEエンドポイントが分離しており、クライアントは常にSSEの接続を維持しておく必要がありました。

なぜ廃止されたのか

この設計にはいくつかの問題がありました。

1. 常時接続の維持コストが高い
SSEはサーバーとクライアント間のコネクションを張りっぱなしにします。スケールが大きくなるほどコネクション数が増え、サーバーリソースを圧迫します。サーバーレス環境（Cloudflare Workers、AWS Lambdaなど）とは根本的に相性が悪い。

2. エンドポイントが2本ある設計の複雑さ
ルーティング・認証・ロードバランサーの設定を2つのエンドポイントに対して行う必要があり、実装とデプロイの複雑さが増しました。

3. 単方向の制約
SSEはサーバーからクライアントへの一方向ストリームです。双方向のやりとりを実現するためにPOSTと組み合わせるという設計は、根本的に不自然でした。

廃止のタイムライン

  • 2025年3月：MCP仕様 2025-03-26 で正式に非推奨化
  • 2025年4月：TypeScript SDK v1.10.0 で Streamable HTTP をサポート
  • 2026年6月：Atlassian Rovo が SSE サポートを終了
  • 2026年以降：主要クライアントが順次 SSE サポートを削除予定

現時点でSSEを使っているサーバーは、まだ動きはしますが今すぐ移行すべき状態です。

4. Streamable HTTP：現在の標準

仕組み

Streamable HTTPは2025年3月のMCP仕様改定で導入された、現在のリモートMCPの標準トランスポートです。SSEの問題点を解消するために設計されており、エンドポイントは /mcp の1本のみです。

クライアント → POST /mcp  （リクエスト送信）
                  ↓
              サーバーが判断
                  ├─ 単純なレスポンス → JSON で即時返却
                  └─ 長時間処理      → SSEストリームに切り替えて返却

クライアントはリクエスト時に Accept: application/json, text/event-stream を送り、サーバーがレスポンスの形式（JSONかSSEか）を動的に選択します。

実際のリクエスト例

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
Mcp-Session-Id: 1d3f...e7c2
Authorization: Bearer <token>

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": { "name": "read_file", "arguments": { "path": "/docs/readme.md" } },
  "id": 1
}

セッション管理

Streamable HTTPでは Mcp-Session-Id ヘッダーによるセッション管理が標準化されています。これにより、ステートフルな操作（複数のリクエストにまたがるコンテキストの維持）が可能になります。

特徴

メリット

  • エンドポイントが1本でシンプル
  • サーバーレス環境（Cloudflare Workers・Lambda等）と完全に互換
  • 単純なリクエストは即時JSON返却、長時間処理はストリーミング、と使い分けが自動
  • OAuth 2.0 + TLS が仕様レベルで組み込まれている
  • 複数クライアントの同時接続に対応
  • 既存のHTTPインフラ（ロードバランサー・CDN・API Gateway）がそのまま使える

デメリット

  • stdioに比べると設定が多少複雑
  • ネットワークが必要（ローカルのみの用途にはオーバースペック）
  • クライアント側の対応がまだ追いついていない（2025年8月時点で341クライアント中95のみ対応）

向いているケース

  • チームで共有するMCPサーバー
  • プロダクションへの組み込み
  • Webアプリやモバイルからのアクセス
  • 複数のAIクライアントから同時に使うケース
  • サーバーレス環境へのデプロイ

5. 三者の比較表

項目stdioHTTP+SSE（廃止）Streamable HTTP
現在の位置づけ✅ 現役・推奨⚠️ 非推奨・後方互換のみ✅ 現役・推奨
通信方式プロセス間（stdin/stdout）HTTP（エンドポイント2本）HTTP（エンドポイント1本）
ネットワーク不要必要必要
リモートアクセス❌ 不可✅ 可✅ 可
複数クライアント❌ 基本1つ✅ 可✅ 可
サーバーレス対応❌ 不可❌ 相性悪い✅ 完全対応
認証（OAuth）不要別途実装が必要仕様に組み込み済み
レイテンシ最小中程度中程度
設定の複雑さ低中中
スケール✅ ローカルで十分❌ コネクション管理が重い✅ オートスケール対応
導入障壁低い中程度中程度

6. どれを選ぶべきか

個人・ローカル開発 → stdio

試してみたい、自分だけで使う、ローカルのファイルやリソースにアクセスしたい——この状況ならstdioで十分です。設定が一番簡単で、動かすまでが早い。

チーム・プロダクション → Streamable HTTP

複数人が使う、Webアプリに組み込む、CI/CDで動かす、安定して動いてほしい——このどれか一つでも当てはまるならStreamable HTTPを選んでください。

SSEを使っている場合 → 即移行

SSEは非推奨です。今はまだ動きますが、2026年以降は主要クライアントが対応を終了していきます。後回しにせず移行してください。

ハイブリッド構成も有効

実務ではstdioとStreamable HTTPを両方使う構成も一般的です。たとえば：

  • ローカルのファイルシステムアクセス → stdio
  • 共有のAPIコール・クラウドサービス連携 → Streamable HTTP（リモート）

mcp-remote や Cloudflare の supergateway のようなツールを使うと、Streamable HTTPサーバーをstdioとしてラップしてクライアントに見せることもできます。

7. SSEからStreamable HTTPへの移行方法

TypeScript SDKを使っている場合の移行は比較的シンプルです。

1. SDKをアップデート

npm install @modelcontextprotocol/sdk@latest

Streamable HTTPのサポートはv1.10.0（2025年4月リリース）から追加されています。

2. トランスポートを差し替える

// Before（SSE）
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";

app.get("/sse", (req, res) => {
  const transport = new SSEServerTransport("/messages", res);
  server.connect(transport);
});

app.post("/messages", (req, res) => {
  transport.handlePostMessage(req, res);
});

// After（Streamable HTTP）
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

app.all("/mcp", (req, res) => {
  const transport = new StreamableHTTPServerTransport();
  server.connect(transport);
  transport.handleRequest(req, res);
});

3. クライアント設定を更新

// Before
{ "url": "http://localhost:3000/sse" }

// After
{ "url": "http://localhost:3000/mcp" }

移行期間中は両方のエンドポイントを並走させることが可能です

// /sse と /mcp を並走させる（移行期間中の対応）
app.get("/sse", handleSSE);      // 旧クライアント向け
app.all("/mcp", handleStreamable); // 新クライアント向け

8. 今後の動向

MCP仕様の進化は速く、トランスポート周りも変化が続いています。いくつかの注目ポイントを挙げます。

クライアント側の対応遅れ
2025年8月時点の調査では、341のMCPクライアントのうちStreamable HTTPに対応しているのは95のみです。stdioは339と圧倒的に多い。仕様は進んでいますが、エコシステム全体の追随にはまだ時間がかかります。

サーバーレスへの最適化が続く
Streamable HTTPはサーバーレス環境での動作を前提に設計されていますが、さらなる最適化（セッション管理の改善・コネクションプーリングなど）が仕様レベルで議論されています。

SSE廃止のデッドラインが迫っている
AtlassianのRovoは2026年6月30日にSSEサポートを終了しています。他の主要クライアントも同様の方向に進んでいます。今SSEを使っているなら、移行は急務です。

まとめ

stdioSSEStreamable HTTP
使うべきか✅ ローカルなら❌ 今すぐ移行✅ リモートなら

シンプルにまとめるとこうなります。ローカルで動かすならstdio、リモートで動かすならStreamable HTTP。SSEは使わない。

トランスポートはあくまでメッセージの配送手段なので、適切なものを選んでおけば後からの切り替えも大きくはありません。ただし、最初からStreamable HTTPで設計しておくほうが、チーム共有・スケールアウト・セキュリティの面でのちのち楽になります。

Nodeflare でStreamable HTTP対応のリモートMCPをすぐに試す

GitHubで公開されているMCPサーバーを、Streamable HTTP対応のリモートサーバーとして数分でデプロイできます。

👉 Nodeflare を使ってみる

nodeflareNodeFlare

MCP専用ホスティングサービス

GitHubにあるMCPを簡単デプロイ・簡単運用で最適化
無料で始める

他の記事

2026年6月28日

Discord を MCP で完全自動化運用する手順（Nodeflare × Claude Code）

GitHubの Discord MCPサーバーをNodeflareにデプロイし、Claude Codeで「Reddit取得 → 要約 → Discord自動投稿」を完全自動化する手順を解説。Bot設定・デプロイ・OAuth接続・定期実行まで一気通貫で紹介します。

2026年6月27日

Filesystem MCPの実務で役立つ使い方を徹底的解説

Filesystem MCPを実務でどう使うか、具体的なユースケースを7つ解説。ドキュメント管理・コードレビュー・ログ解析・チーム共有ドライブ・AIエージェントの記憶としての活用まで、セキュリティ設計のポイントもあわせて紹介します。

2026年6月27日

MCPをリモート化するメリット5選

MCPサーバーをリモート化すると何が変わるのか？チーム共有の効率化・ローカル環境の汚染防止・スケールアウト・OAuth認証の集中管理・マルチクライアント対応まで、5つのメリットを実務目線で具体的に解説します。

他の記事を読む