リモートMCPサーバーとローカルMCPサーバー：stdio、Streamable HTTP、そしてチームが選ぶべきもの

MCP仕様が定義する2つのトランスポート

Model Context Protocolはすべてのメッセージをjson-RPCとしてエンコードします。仕様（リビジョン2025-11-25）はそのメッセージを運ぶ標準トランスポートを正確に2つ定義し、クライアントは可能な限り1つ目をサポートすべきだとしています。

1. stdio。 クライアントがサーバーをサブプロセスとして起動します。サーバーは標準入力からJSON-RPCメッセージを読み、標準出力に1行1メッセージで書きます。標準エラーにログを出してもよく、stdoutにはそれ以外を書いてはいけません。
2. Streamable HTTP。 サーバーは https://example.com/mcp のような単一のHTTPエンドポイントを持つ独立したプロセスで、POSTとGETを受け付けます。クライアントからのメッセージはすべてPOSTです。サーバーは1つのJSONオブジェクトで応答するか、複数のメッセージを送る場合はServer-Sent Eventsストリームを開きます。2024-11-05リビジョンの古いHTTP+SSEトランスポートを置き換えたもので、旧方式は現在非推奨です。

「ローカル」と「リモート」はこの2つの日常的な呼び名です。ローカルサーバーはほぼ常にstdio、リモートサーバーは常にStreamable HTTPです。Streamable HTTPサーバーをlocalhostで動かすこともでき、仕様はそうしたサーバーは127.0.0.1にのみバインドすべきだとしていますが、一般的な形は上の2つです。仕様のトランスポートの節に完全な規則があり、リモートサーバーの用語集エントリがその短い版です。

ローカルサーバーの仕組み

何か、たいていはNode、Python、Goで書かれた小さなプログラムをインストールし、実行コマンドとともにAIアプリの設定に追加します。アプリが起動するとプロセスが生成されます。サーバーは通常、アプリから渡される環境からAPIキーやデータベースのパスを読みます。アプリを閉じるとプロセスは終了します。

これはMCPの元々の形であり、今も多くの種類のサーバーにとって正しい形です。

• 指定したフォルダを読むファイルシステムサーバー
• シェルのプロファイルに接続文字列を置いたデータベースサーバー
• マシンにインストール済みのCLIツールのラッパー
• 午後のうちに試作しているもの全般

強みは単純さと局所性です。ネットワークも、TLS証明書も、ログインも、マルチテナントもありません。サーバーは起動した本人ひとりに仕えます。仕様は、stdioサーバーはOAuth認可フローを使わず、環境から認証情報を取るべきだとしています。

弱みは、同じ事実をチームの側から見たものです。各人が自分のコピーをインストールし更新します。各コピーに固有の鍵が要ります。ノートPCの設定ファイルにある鍵は、コピーされ、誤ってコミットされ、退職時に残されうる鍵です。そして誰が何を呼んだかを中央で知る手段がありません。

リモートサーバーの仕組み

リモートサーバーはウェブサービスです。URLでアプリに追加します。最初の呼び出しでサーバーは 401 Unauthorized とメタデータへのポインタを返し、アプリは認可サーバーを発見してブラウザを開き、あなたがサインインしてスコープのセットを承認すると、以後すべてのリクエストは Authorization ヘッダーにベアラートークンを載せます。アプリ内のMCPクライアントがこの一連の手順を処理し、ユーザーに見えるのは同意画面だけです。

Streamable HTTPには、ユーザーや運用者として気づくいくつかの仕組みがあります。

• セッション。 サーバーは初期化時に MCP-Session-Id ヘッダーを返すことができ、以後クライアントはすべてのリクエストでそれを送らなければなりません。サーバーはいつでもセッションを終了でき、その後クライアントは新しいセッションを開始します。
• ストリーミング。 長いツール呼び出しでは、サーバーはSSEストリームを開き、進捗通知を送り、最後に応答を返せます。接続が切れた場合、クライアントは Last-Event-ID で再接続でき、サーバーは取りこぼしを再送できます。
• Originの検証。 サーバーはすべての接続で Origin ヘッダーを検証し、不正なものは 403 で拒否しなければなりません。悪意あるウェブページがブラウザ経由でサーバーと通信するのを防ぐためです。
• 毎回の認証。 トークンは各リクエストのヘッダーに載せ、URLには決して入れません。サーバーはそのトークンがこのサーバー向けに発行されたものかを確認しなければなりません。

見返りは、ひとつのデプロイが全員に仕えることです。誰も何もインストールしません。アクセスは人ごとに付与され、承認した範囲に限定され、サーバー側から取り消せます。すべての呼び出しをトークンの背後にいる人に紐づけて監査できます。

代償は、サービスを運用することになる点です。ホスティング、TLS、稼働率、レート制限、テナント分離、そしてOAuth認可サーバーかそれとの連携。自分ひとりしか使わないサーバーには大仕掛けすぎます。

リモートとローカルのMCPサーバー比較

どちらを使うべきか

3つの質問をしてください。

誰のデータか。 サーバーが自分のファイルや自分だけが触るデータベースを読むならローカル。複数人が共有し、会社に属するレコードがあり、人によって権限が異なるシステムを読むならリモート。ローカルサーバーには「Priyaは案件金額を見られるがTomは見られない」を表現する手段がありません。与えられた鍵の権限で動くだけです。

誰がインストールするのか。 答えが「自分が一度」ならローカルで十分。「全メンバーが、しかも更新し続ける」なら、リモートサーバーはその手間を丸ごとなくします。私たちはローカル版が1週間以内に破綻するのを見てきました。ある人の設定には古い鍵があり、別の人の設定にはその人のマシンでしか動かないパスがある、という具合です。

誰かが辞めたらどうなるか。 ローカルサーバーなら、その人の鍵はあなたには見えないファイルの中にあります。OAuthに支えられたリモートサーバーなら、アカウントを取り消せばその人が作ったすべてのトークンが次の呼び出しで終わります。

小さなチームの妥当な規則はこうです。各人のノートPC上の開発ツールにはローカルサーバー、チームが実際に仕事をするすべての製品にはリモートサーバー。

チームが自前のリモートサーバーをホストすべきとき

ほとんどのチームは、ベンダーが運用するリモートサーバーに接続します。自前でホストする意味がある場合もあります。ベンダーのいない社内システム、人ごとの権限でアシスタントに問い合わせさせたいデータベース、自作のAPIなどです。その前に、ツールそのもの以外の部分を見積もってください。

1. 認可サーバー。 MCP認可仕様はPKCEとメタデータ発見を備えたOAuth 2.1を想定しています。自分で運用するか、対応するIDプロバイダをサーバーの前に置きます。
2. すべてのリクエストでのトークン検証。 トークンが他のリソースではなく自分のサーバー向けに発行されたことの確認を含みます。
3. テナント分離。 リクエストのトークンが見えるものを制限しなければなりません。そのトークンを中心にリクエストごとに新しいインスタンスまたはコンテキストを作り、人をまたいで何もキャッシュしない構造にします。
4. レート制限と監査。 忙しいクライアントひとつが他を飢えさせてはならず、後で誰がどのツールを実行したか分かる必要があります。
5. 運用。 TLS、稼働率、クライアントを壊さずにツール一覧をバージョン管理すること。

このリストが必要に対して重く見えるなら、サーバーはローカルのままにするか、ベンダーを待ってください。

Atrixがリモート専用である理由

私たち自身のMCPサーバーは、この選択の実例です。Atrixは共有のワークスペースで、チームのプロジェクト、文書、顧客、カレンダー、人事レコードがそこにあり、各人が見られるものは異なります。ローカルサーバーなら、作った人と同じ権限を持つひとつの鍵をすべてのノートPCで動かすことになり、サーバーは実際に誰が尋ねているのかを知る術がありません。

そのためAtrixのサーバーは https://atrix.dev/api/mcp という単一のリモートエンドポイントで、Streamable HTTPで動きます。インストールするパッケージはありません。Claude Codeでは設定全体が1行、claude mcp add --transport http atrix https://atrix.dev/api/mcp に続けて /mcp からAuthenticateを選ぶだけです。ブラウザが開き、ワークスペースを選んでスコープを承認すると、クライアントは短命のアクセストークンとローテーションするリフレッシュトークンを保存します。サーバーは提示されたトークンを中心にリクエストごとに新しいインスタンスを構築するため、リクエスト間やワークスペース間で何も共有されず、すべての呼び出しはツール、結果、対象によって監査されます。85のツールを公開し、公式MCPレジストリとGlamaに掲載されています。機能ページでツールの内容を説明しています。

制限も実在します。オフラインモードはなく、Atrixアカウントなしでは使えません。レート制限はトークンあたり毎分120呼び出し、30書き込みです。そしてスコープは本人がすでにできることを狭めることしかできないため、誰かのアカウント経由で接続したアシスタントがその人以上のものを見ることはありません。すべてに届くサーバーが必要なら、これはそれではありませんし、私たちはそれが正しいトレードオフだと考えています。

FAQ

リモートMCPサーバーとローカルMCPサーバーの違いは何ですか

ローカルサーバーは自分のマシンでサブプロセスとして動き、stdioで通信し、認証情報は環境から得ます。リモートサーバーはHTTPSのURLでStreamable HTTPで動き、各ユーザーをOAuthで認証し、ひとつのデプロイで多数のユーザーに仕えます。

stdioとStreamable HTTPはどちらが良いですか

一般にどちらが良いということはありません。仕様は両方を定義し、クライアントには可能な限りstdioをサポートするよう求めています。stdioはより単純でネットワーク露出がなく、Streamable HTTPはサーバーが共有されるか、ユーザーのマシン外でホストされる場合の唯一の選択肢です。

Streamable HTTPサーバーをローカルで動かせますか

はい。仕様は、ローカルで動くHTTPサーバーはlocalhostにのみバインドすべきで、DNSリバインディングを防ぐために Origin ヘッダーを検証しなければならないとしています。単一ユーザーのサーバーとしてはstdioより一般的ではない形です。

リモートMCPサーバーにOAuthは必要ですか

MCP認可仕様は、HTTPトランスポートを使う実装はこの仕様に従うべきだとし、OAuth 2.1の上に構築されています。代わりに貼り付けたベアラートークンを受け付けるサーバーもありますが、それはより単純で、より弱い方法です。トークンは長命で、設定ファイルに置かれ、同意画面によるスコープ制限がありません。

HTTP+SSEトランスポートはどうなりましたか

2024-11-05リビジョンで定義され、2025-03-26でStreamable HTTPに置き換えられました。現行の仕様はこれを非推奨とし、クライアントとサーバーが旧形式との互換性を保つ方法を説明しています。

AtrixのMCPサーバーはローカルで使えますか

いいえ。https://atrix.dev/api/mcp のリモート専用です。ワークスペースのデータが共有であり、人ごとの権限を呼び出しごとにサーバー側で強制する必要があるためです。

次のステップ

アシスタントをAtrixに接続するなら、開発者向け概要にClaude Code、Claude Desktop、ChatGPT、Cursorの正確な手順があり、MCP機能ページにツールの一覧があります。自前のサーバーをどう作るか決めるなら、まずMCPクライアントとリモートMCPサーバーのエントリを読んでください。