MCPのstdioとStreamable HTTPはどう選ぶ？2026年版の判断基準

結論

MCPのトランスポートは、機能の多さではなくプロセスの所有者と利用範囲で決めます。同じ端末でMCPクライアントがサーバーを子プロセスとして起動し、利用者ごとに閉じた権限で使うなら stdio が第一候補です。複数端末・複数利用者から一つのサービスへ接続し、OAuth、ゲートウェイ、監視、レート制限を必要とするなら Streamable HTTP を選びます。

もう一つ重要なのは仕様日です。2026年8月13日時点の最新仕様は 2026-07-28 で、プロトコル本体はステートレスになりました。以前の initialize / initialized、Mcp-Session-Id、GETで開くSSEストリームを前提にした設計を、そのまま新規実装の判断材料にしてはいけません。

この記事の対象読者

初めてMCPサーバーを作り、stdioとHTTPのどちらにするか迷っている開発者
ローカルMCPをチーム共有のリモートMCPへ移行したい運用担当者
2025年までの記事やサンプルを使っており、2026-07-28仕様との差を確認したい人
認証、ログ、再試行、停止方法まで含めて接続方式を決めたい人

MCP全体の用語から確認したい場合は、先にはじめてのMCP入門を読むと判断しやすくなります。

stdio

Streamable HTTP

配置

同じ端末の子プロセス

独立したHTTPサービス

主な利用範囲

一人・一端末・一クライアント

複数端末・複数利用者・複数クライアント

メッセージ経路

stdin/stdoutの改行区切りJSON-RPC

単一MCPエンドポイントへのPOST

認証の中心

プロセス環境とOS権限

OAuth、Origin検証、スコープ

運用の中心

起動、終了、stderr、再起動

可用性、429、監査ログ、ロールバック

向く例

IDEのローカルファイル検索

社内SaaSを操作する共有ツール

新規実装の基準。どちらも同じMCPメッセージを運び、違うのは配送とライフサイクルである。

まず見る判断表

質問	Yesなら	理由
クライアントがサーバープロセスを起動・終了できるか	stdio寄り	プロセスの寿命をクライアントに任せられる
サーバーとクライアントは同じ端末にあるか	stdio寄り	公開HTTP面を持たずに済む
複数の利用者や端末から同じサービスを使うか	Streamable HTTP寄り	独立した共有エンドポイントが必要になる
利用者ごとにOAuthスコープを付与するか	Streamable HTTP寄り	MCPのHTTP認可フローへ統合しやすい
WAF、ゲートウェイ、集中監視が必要か	Streamable HTTP寄り	HTTPヘッダーを使って経路制御・観測できる
オフライン環境でも使う必要があるか	stdio寄り	ローカル依存だけで完結しやすい
サーバーを独立して水平スケールしたいか	Streamable HTTP寄り	2026-07-28では各リクエストを別インスタンスへ配送できる

「将来リモート化するかもしれない」だけで最初からHTTPにする必要はありません。ツール本体の入出力と権限判定をトランスポートから分離しておけば、まずstdioで検証し、利用者と運用要件が増えた時点でHTTPアダプターを追加できます。

2026-07-28仕様で変わった境界

MCP公式の2026-07-28リリース解説では、プロトコル本体がリクエスト／レスポンス型のステートレス設計になったと説明されています。各リクエストはプロトコルバージョン、クライアント情報、能力を _meta に持ち、事前のハンドシェイクは必須ではありません。

世代	主な特徴	新規実装での扱い
2026-07-28	`initialize`とセッションIDを廃止。各リクエストが自己記述的	基準にする
2025-03-26〜2025-11-25	Streamable HTTPだがセッションや旧SSE動作を含む	互換要件がある時だけ維持する
2024-11-05 HTTP+SSE	POSTエンドポイントと独立SSEエンドポイントを使う旧方式	非推奨。移行計画を作る

旧クライアントも受け入れる場合、現行仕様のstdio互換手順は、まず server/discover を試し、応答の種類からmodernかlegacyかを判断する方法を示しています。特定の一つのエラーコードだけでlegacyと決めつけず、SDKの対応表とタイムアウトを含めて検証します。

stdioを選ぶときの実装要件

公式stdio仕様では、クライアントがMCPサーバーを子プロセスとして起動します。サーバーは stdin から1行1メッセージのJSON-RPCを読み、stdout へ有効なMCPメッセージだけを書きます。ログは stderr に分離します。

実装で外せない点は次の通りです。

stdout に起動メッセージやデバッグ文字列を出さない
1メッセージ内へ未エスケープの改行を入れない
stdin が閉じたら速やかに終了する
異常終了時にクライアントが再起動できるよう、処理を再試行可能にする
認証情報はMCPのHTTP認可フローではなく、環境やOSの安全な資格情報管理から渡す

stdioはネットワークへ公開しない分、攻撃面を小さくできます。しかし安全性を自動的に保証するわけではありません。子プロセスは起動ユーザーのファイル、環境変数、コマンド実行権限を引き継げます。読み取り専用ディレクトリ、明示的な許可リスト、秘密値を含めないログを設計してください。

Streamable HTTPを選ぶときの実装要件

公式Streamable HTTP仕様では、サーバーが単一のMCPエンドポイントを公開し、クライアントは各JSON-RPCメッセージを個別のHTTP POSTとして送ります。応答は単一JSON、またはそのリクエストに限定したSSEです。

2026-07-28では、最低限次を実装・検証します。

Origin ヘッダーが存在する場合は検証し、不正なら403を返す。Origin なしの非ブラウザクライアントも、認証・認可なしで信頼しない
ローカル公開なら 127.0.0.1 にバインドし、安易に 0.0.0.0 へ公開しない
MCP-Protocol-Version と本文中のバージョン不一致を拒否する
Mcp-Method、必要な場合は Mcp-Name を受け取り、ゲートウェイ側でも観測する
JSON応答とリクエスト単位のSSE応答をクライアントが両方扱えるようにする
OAuthを使う場合はツール単位の最小スコープと同意画面を用意する

公式Authorization仕様上、認可自体はMCP全体で必須ではありません。ただしHTTPで保護対象のデータや操作を公開するなら、認証なしを既定にしない方が安全です。特に書き込みツールは、ログイン済みであることと、そのツールを呼べるスコープがあることを別々に確認します。

選定から接続確認までの具体手順

1. ツールの権限を棚卸しする

各ツールについて「読む対象」「変更する対象」「外部送信」「課金」「公開」の有無を書き出します。書き込み、削除、公開、購入を含むなら、人間の確認を必要とする境界も決めます。MCPとhooksの安全境界も併せて使えます。

2. 利用者と配置を一文で書く

次のテンプレートを埋めます。

利用者: 個人 / チーム / 外部顧客
クライアント: 1種類 / 複数種類
サーバー配置: 同一端末 / 社内ネットワーク / インターネット
認証: OS権限 / OAuth / その他
可用性目標: ベストエフォート / 業務時間 / 常時

「個人、1クライアント、同一端末、OS権限」ならstdioから始めます。「チーム、複数クライアント、インターネット、OAuth」ならStreamable HTTPです。

3. modernだけか、legacy互換も持つか決める

新規サーバーは2026-07-28を基準にします。既存クライアントが旧仕様しか話せない場合だけ、期限付きの互換レーンを設けます。廃止日はクライアント更新率、legacy呼び出し件数、エラー率で判断します。

4. 正常系より先に失敗系を試す

stdioなら、不正なstdout、プロセス強制終了、入力EOF、処理中キャンセルを確認します。Streamable HTTPなら、不正Origin、無効トークン、スコープ不足、バージョン不一致、429、SSE切断を確認します。

5. 観測項目を固定する

共通して、リクエストID、ツール名、クライアント版、プロトコル版、成功・失敗、所要時間を記録します。HTTPではステータスコードと認可結果、stdioではプロセス終了コードと再起動回数も必要です。トークン、秘密値、ツールの機密入力・出力は記録しません。

接続時の代表的な症状はMCPサーバー接続トラブルシューティングに切り分け手順があります。

公開前チェックリスト

よくある質問

ローカルMCPサーバーはすべてstdioにすべきですか？

同じ端末でクライアントが子プロセスを管理できるならstdioが第一候補です。ただし、複数アプリから常駐サービスを共有する、HTTPの認証・監視基盤へ統合する、といった要件がある場合はローカルでもStreamable HTTPが適することがあります。

Streamable HTTPには常時接続のSSEが必要ですか？

2026-07-28仕様では各JSON-RPCメッセージを個別のPOSTで送り、応答はJSONまたはそのリクエストに限定したSSEです。変更通知が必要な場合だけsubscriptions/listenの長時間ストリームを使います。

2025-11-25以前のMCPクライアントも同じエンドポイントへ接続できますか？

実装側が互換処理を持てば可能ですが、自動的に保証されるわけではありません。server/discoverによる世代判定、対応SDKの互換表、legacy用経路を確認し、modernとlegacyの成功率を分けて監視してください。

まとめ

stdioとStreamable HTTPの優劣を決めるのではなく、誰がプロセスを持ち、どこから何人が使い、どの認証・運用基盤が必要かを決めるのが先です。同一端末の子プロセスならstdio、共有する遠隔サービスならStreamable HTTPが基本です。

そして2026年の新規実装では、必ず仕様日を固定してください。2026-07-28のステートレスなリクエストモデルと、2025-11-25以前のセッション前提を混ぜず、互換レーンが必要なら期限と観測項目を持たせます。それが、接続できるだけでなく安全に終了・移行できるMCP設計になります。