MCPのstdioとSSE｜トランスポートの違いと選び方

MCPの設定を調べていると、「stdio」と「SSE」という言葉が並んで出てきます。どちらも接続方法を指す言葉ですが、自分がいま触っている設定がどちらの話なのかは、最初は判断しにくいところです。

この記事では、トランスポートを「どうつなぐか」という一つの軸として整理し、stdioとHTTP側（SSE／Streamable HTTP）を比較します。設定例に出てくるcommandやurlから、自分の接続がどちらのタイプかを見分けられるところまでが範囲です。

MCPの役割（Host／Client／Server）の解説や、JSON設定の書き方そのものはここでは扱いません。

今日の結論

• トランスポートは、メッセージの中身ではなく「どうつなぐか」という運び方を決める層です。
• stdioは、クライアントが自分のマシン上でサーバーをプロセスとして起動し、標準入出力でやり取りする方式です。
• HTTP側の現行仕様名はStreamable HTTP。SSEという言葉は、製品の接続方式名・旧HTTP+SSE方式・応答のストリーム形式という複数の意味で使われています。
• 設定例ではcommand／argsとurl（製品によってはtype）のどちらが書かれているかを見れば、自分の接続がどちら側かを切り分けられます。
• どちらを選ぶかは接続先の案内と、使っているクライアントの対応状況に従うのが基本です。設定の書き方と初回の接続確認は別記事で扱います。

トランスポートは役割とは別の「どうつなぐか」

MCPには、Host・Client・Serverという役割の話と、メッセージをどう運ぶかというトランスポートの話があります。この二つは別のレイヤーです。役割の全体像を先に押さえたい場合は、MCPの仕組み入門にまとめてあります。

MCP仕様のTransports Overviewでは、トランスポートが違っても、やり取りされるメッセージの意味は変わらないと位置づけられています。JSON-RPCで表現されたリクエストや通知の中身は共通で、違うのは「どの経路で届けるか」という部分だけです。つまり、stdioを選んでもHTTP側を選んでも、MCPサーバーが提供するツールや機能そのものが変わるわけではありません。変わるのは接続の作り方と、どこで動かすかという点です。

現行の標準的なトランスポートは、stdioとStreamable HTTPの二つです。

stdio：ローカルで起動して標準入出力でつなぐ

stdioは、クライアントが自分のマシン上でMCPサーバーをサブプロセスとして起動し、標準入力（stdin）と標準出力（stdout）でJSON-RPCメッセージをやり取りする方式です。サーバーは改行区切りのメッセージをstdinから読み取り、stdoutへ書き出します。ログなどの補助的な出力はstderrに逃がす設計になっていて、stdout側にはMCPのメッセージ以外を書き込まない決まりです。

向いているのは、同じマシン上で完結するローカルツールや、クライアント側が起動から終了までのプロセス管理を担う場面です。設定でまず見る項目はcommandとargs。npxやpythonなど、サーバーを起動するコマンドとその引数を書く形になります。

ログがstderrに出ている場合、正常動作でもエラーのように見えることがあります。動作確認や切り分けの詳しい手順は初回セットアップの記事に譲り、ここでは「stdio＝ローカル起動＋標準入出力」という枠組みだけ押さえておけば十分です。

HTTP側：SSEとStreamable HTTPを分けて読む

HTTP側の呼び方は、現行のMCP仕様ではStreamable HTTPで統一されています。単一のMCPエンドポイントに対してHTTPでメッセージを送り、応答はJSONでまとめて返る場合と、SSE（Server-Sent Events）のストリームで返る場合があります。応答の形式が変わるだけで、エンドポイントは一つという設計です。

ここで紛らわしいのが「SSE」という言葉の使われ方です。執筆時点で確認した公式ドキュメントの範囲では、少なくとも3つの意味で登場します。

1. 製品の接続方式名: 製品のUIや設定が接続方式の一つとして並べる名前（例: Cursorの設定画面）
2. 旧HTTP+SSE方式: Streamable HTTPより前にあった方式そのもの
3. 応答のストリーム形式: Streamable HTTPの応答が取り得るストリーム形式の名前

検索で「SSE」に行き当たったときは、どの意味で使われているかを文脈で確認してから読み進めると、混同を避けられます。

製品側の扱いにも差があります。Cursor公式のMCPドキュメントでは、stdio・SSE・Streamable HTTPの3方式を並べています。一方でClaude Code公式のMCPドキュメントはHTTP（Streamable HTTPのエイリアスとしてstreamable-httpも使えます）を推奨し、SSEは非推奨という案内です。全製品が同じ3方式を対等に扱っているわけではなく、実際の対応は製品ごとに確認したほうが確実です。設定場所はCursorのMCP設定やClaudeのMCP設定にまとめています。

向いているのは、接続先がURLで案内されるリモートサーバーや、複数の環境から同じサーバーへつなぐ場面です。認証が必要な場合は、OAuthなど利用先の案内に従う形になり、実装の詳細はここでは扱いません。

比較の軸を表にまとめます。

優劣を決めるための表ではなく、迷ったときにどこを見るかを整理するための表です。速さや安全性の一般的な優劣は、ここでは扱いません。

設定例のtype・command・urlで自分の接続を見分ける

自分の接続がstdio側かHTTP側かを見分ける手順は、次の3つです。

1. 接続先の案内が「起動コマンド」か「URL」かを確認する
2. 設定ファイルのキーにcommand／argsがあるか、urlがあるかを見る
3. typeの値を求める製品なら、stdio／sse／httpなどを案内と照合する

たとえば、ローカル起動のイメージは"command": "npx"のような形。HTTP接続のイメージは"url": "https://..."のような形です。ここでは見分け方を示すための断片であり、完全な設定ファイルとしては配布していません。

typeの必須・任意は製品によって差があります。Cursorのstdio設定ではtypeの指定が必須ですが、リモート接続はurlだけで動く例もあります。Claude Codeではurlがあるのにtypeが無いと設定エラー扱いになり、"type": "http"（またはsse／ws）を加えるよう案内が出ます。製品ごとに必須性が違うため、ここでは見分け方の観点にとどめます。

設定ファイルの型やキーの追記、構文エラーの直し方はMCP設定ファイルの書き方で扱っています。JSON編集そのものに迷ったら、そちらを先に確認してください。

接続先とクライアント案内に合わせて選ぶ

どちらのトランスポートを使うかは、次の順で決めるのが安全です。

1. 接続先（使いたいMCPサーバー）の公式案内を確認する
2. 利用しているクライアントの対応表記を見る
3. 設定のキー（command／argsかurlか）を案内に合わせる
4. 初回の接続確認・呼び出しテストに進む

迷ったときの目安は、「案内が起動コマンドならstdio側、URLならHTTP側」です。未確認の製品にこの対応をそのまま当てはめて推測するのは避けてください。

次の一手は記事によって分かれます。JSON設定の編集で迷ったらMCP設定ファイルの書き方、初回の接続・動作確認はMCPの導入手順、役割の全体像を先に知りたい場合はMCPの仕組み入門です。MCP関連の記事を一覧で探したいときはMCPガイドから辿れます。

---

本記事の内容は執筆時点（2026-09-11）の情報に基づきます。公式ドキュメントと仕様を参照しており、掲載の接続例は実機未検証です。トランスポート名称・製品の対応方式・設定キーは変更される可能性があります。接続成功や安全性、速度の優劣を保証するものではありません。重要な判断は公式ドキュメントで確認してください。