ローカルMCPとリモートMCP、Claude Codeでどちらを選ぶか

Claude CodeのMCPサーバーは、自分のマシンでプロセスとして起動するローカル(stdio)接続と、ネットワーク越しにHTTPで呼び出すリモート接続のどちらかで動きます。どちらが優れているという話ではありません。誰がサーバーを保守するか、チームに設定をどう共有するか、レイテンシと監査ログのどちらを優先するかで、答えが変わります。

ローカルとリモートは「誰が何を管理するか」の違い

ローカル(stdio)接続はclaude mcp add -- npx -y ...のように、あなたのマシン上でサーバーのプロセスを直接起動します。ファイルシステムへの直接アクセスや、自作スクリプトの実行に向いています。リモート(HTTP)接続はclaude mcp add --transport http ...のように、クラウド上で運用されているサーバーに接続します。公式ドキュメントも、クラウドベースのサービスに接続する場面ではHTTPを推奨し、直接的なシステムアクセスやカスタムスクリプトにはstdioが向くと整理しています。この役割分担が、以降の4つの判断軸すべての土台になります。

判断軸は4つです。レイテンシ(通信経路にネットワークを挟むかどうか)、監査ログ(誰が何をしたかを追跡できるか)、保守性(ランタイムの更新や接続断への対応を誰が担うか)、チーム共有(設定と実行環境をどこまでチームで揃えられるか)です。この4つのうち1つでも軽視すると、後から接続方式を選び直す手間が発生します。

チーム共有はスコープが決める、接続方式ではない

Claude CodeのMCPサーバーには、接続方式(stdio/HTTP)とは別に「スコープ」という設定の可視範囲があります。この2つを混同しないことが重要です。

チームで同じMCPサーバーを使いたいなら、接続方式に関係なくプロジェクトスコープを選び、.mcp.jsonをコミットします。ここで接続方式の違いが効いてきます。プロジェクトスコープのstdioサーバーを共有すると、チームメンバー全員が同じランタイム(Node.jsやuv、Dockerなど)を自分のマシンに用意する必要があります。プロジェクトスコープのHTTPサーバーなら、メンバーは認証さえ済ませればよく、ローカル環境の差でサーバーが動かないという事態が起きません。

レイテンシは通信経路の有無で決まる

ローカルのstdioサーバーは標準入出力を使ったプロセス間通信で完結し、ネットワークの往復が発生しません。リモートのHTTPサーバーは呼び出しのたびにネットワークを経由するため、原理上はローカルより往復のぶんだけ遅くなります。ただし実際の体感差はサーバー自身の応答速度や回線状況に左右されます。頻繁に呼び出すツールでレイテンシが気になるなら、まず計測してから判断するのが安全です。

タイムアウトの掛かり方も違います。HTTP・SSE・claude.aiコネクタのサーバーには、最初の応答バイトが返るまでを見張る「per-requestタイマー」があり、60秒・そのサーバーのツールタイムアウト・MCP_TIMEOUTのうち最も長い値が採用されます。stdioとWebSocketのサーバーにはこのper-requestタイマー自体がありません。ネットワーク越しの接続だからこそ必要になった、リモート固有の安全装置です。

監査ログはOTelイベントで残せる、ただし取得は自分で設定する

Claude CodeはOpenTelemetryのログイベントを監査データの出どころとして提供しています。mcp_server_connection(接続・切断・失敗)、tool_result(ツール呼び出しの結果)、tool_decision(許可・拒否の判断)の3種類のイベントに、ユーザーのメールアドレスやセッションIDといった識別情報が付きます。これはstdio・HTTPどちらの接続方式でも同じ仕組みが働き、接続方式そのものが監査ログの有無を左右するわけではありません。

ただし既定のままでは、ユーザー設定のMCPサーバー名やツール名は"mcp_tool"という文字列に匿名化されます。サーバー名・ツール名・呼び出し引数まで含めた詳細なログが必要なら、OTEL_LOG_TOOL_DETAILS=1を明示的に設定し、OTLPログエクスポーターの送信先をSIEM(セキュリティ情報イベント管理)側に向けます。

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_LOG_TOOL_DETAILS=1
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https://siem.example.com:4318/v1/logs"

接続方式による差が出るのはここから先です。リモートMCPサーバーは、Claude Code側のOTelログとは別に、サーバーを運営する事業者側が独自のアクセスログを保持している場合があります。これはサーバー運営者の実装次第で、Claude Code側から中身を確認する手段はありません。ローカルのstdioサーバーは、あなたが起動したプロセスそのものなので、ログを残すかどうかも含めて全てあなたの管理下にあります。

保守性はランタイムを誰が持つかで変わる

ローカルのstdioサーバーは、npx -y package@latestのようにバージョン指定を省くと、起動のたびに最新版を取得します。動作が急に変わったときの原因調査が難しくなるため、本番運用ではバージョンを固定しておくのが無難です。加えて、Node.jsやuv、Dockerといったランタイムのインストールと更新は各自のマシンで行う必要があります。

リモートのHTTPサーバーは、サーバー自体の更新をサービス提供者が担います。あなたのマシンには何もインストールする必要がなく、認証情報の管理だけが残ります。個人の検証や、ファイルシステムに直接触れる必要があるツールはローカル、チーム全体で使う外部サービス連携はリモート、という住み分けが自然です。

起動や応答が遅いサーバーを個別に調整したいときは、MCP_TIMEOUT環境変数でサーバー起動のタイムアウトを、.mcp.jsonエントリのtimeoutフィールドでサーバーごとのツール実行タイムアウトを変更できます。どちらも接続方式を問わず使える調整項目ですが、リモートサーバーは前述のper-requestタイマーが別に掛かるため、応答が遅いサービスに接続するときはこちらの上限も合わせて確認します。

接続が切れたときの挙動も違う

保守性を左右するもう1つの要素が、接続が落ちたときにClaude Codeがどう振る舞うかです。リモート(HTTP/SSE)サーバーがセッション中に切断されると、Claude Codeは指数バックオフで自動的に再接続を試みます。最初は1秒、そこから倍々に間隔を伸ばしながら最大5回まで再試行し、対話セッションでは/mcpにサーバーが保留中と表示されます。ローカルのstdioサーバーはあなたのマシン上の1プロセスなので、Claude Codeはこれを自動で再接続しません。プロセスが落ちたら、自分でサーバーを再起動する必要があります。

アイドルタイムアウトの既定値も接続方式で違います。HTTP・SSE・WebSocket接続のサーバーは、応答も進捗通知も無いまま5分経過するとツール呼び出しが打ち切られます。stdioサーバーはこの既定値が30分と長く設定されています。ローカルで時間のかかる処理を実行させる用途では、この差が実用上の余裕になります。

最初の接続そのものが失敗するケースの扱いも、リモート固有です。HTTP・SSEサーバーへの初回接続が5xxエラー・接続拒否・タイムアウトなど一時的な原因で失敗した場合、Claude Codeは最大3回まで再試行し、それでも失敗すればそのサーバーをfailedとして扱います(stdioサーバーはこの再試行の対象外です)。セッション途中の切断に対する再接続とは別に、起動直後からリモートサーバーが繋がらない場合の挙動として押さえておく価値があります。

判断軸の早見表

実際に試す

チームで共有するリモートサーバーは、プロジェクトスコープでHTTP接続を追加し、.mcp.jsonをコミットします。

claude mcp add --transport http notion \
  --scope project \
  https://mcp.notion.com/mcp

個人用のローカルツールは、既定のローカルスコープのままstdioで追加すれば十分です。

claude mcp add local-tool \
  --env API_KEY="your-key" \
  -- npx -y @example/mcp-server

よくあるつまずき

プロジェクトスコープの.mcp.jsonは自動承認されない。クローンしたリポジトリで.mcp.jsonを開いても、ワークスペースを信頼するダイアログを一度通らない限りサーバーはPending approvalのままです。claude -p実行やAgent SDKセッション、クラウドセッションなどの非対話セッションでは、この承認プロンプト自体を表示できないため、Claude Codeはプロジェクトスコープのサーバーを承認を求めずそのままロードします。入れたくないサーバーがある場合は、disabledMcpjsonServersで個別に除外するか、--strict-mcp-configでロード対象そのものを絞り込みます。

同じ名前のサーバーを複数スコープで定義してしまう。ローカルスコープとプロジェクトスコープに同名で別のエンドポイントを登録すると、Claude Codeは警告を出したうえで優先順位(ローカル→プロジェクト→ユーザー)の高い方だけを使います。OAuthのサインインもエンドポイントごとに別管理なので、プロジェクトを跨ぐと再認証が必要になることがあります。

リモートサーバーを削除すると認証情報も消える。OAuthトークンとクライアント登録情報はサーバーをclaude mcp removeした時点で一緒に削除されます。再追加すると再度サインインが要ります。誤って削除・再追加を繰り返すと、そのたびにチーム全員が再認証を求められる点にも注意します。

ローカルのstdioサーバーが落ちたことに気づかない。リモートサーバーは切断が/mcpパネルに表示され再接続も自動ですが、ローカルのstdioプロセスが異常終了しても、Claude Codeは黙って次のツール呼び出しでエラーを返すだけです。長時間セッションでは、ときどき/mcpでサーバーの状態を確認する習慣が有効です。

まとめ

ローカルとリモートの選択は、接続方式(stdio/HTTP)とスコープ(ローカル/プロジェクト/ユーザー)という2つの独立した軸を組み合わせて決めます。レイテンシを優先するならローカル、チームでのランタイム管理を減らしたいならリモート、監査ログはどちらでもOTelの設定次第です。接続断への対応や再接続の自動化まで含めて考えると、運用の手離れが良いのはリモートに軍配が上がります。プロトコルレベルでのstdioとリモート接続の技術的な違いはMCPクライアントの仕組み、リモートMCPのOAuth認証の詳細はリモートMCPのOAuth認証にまとめています。