MCPサーバーを複数接続すると遅くなる？ツール数とコンテキスト消費を解説

Claude CodeやAIエージェントでMCPを使い始めると、接続するMCPサーバーが徐々に増えていきます。GitHub、Filesystem、Slack、Database、社内ドキュメント、ブラウザ操作と追加していくと、「MCPサーバーを増やすほどClaude Codeが遅くなるのでは？」「使っていないMCPでもコンテキストを消費するのか？」という疑問が出てきます。

結論から言うと、MCPサーバーの接続数だけで、速度やトークン消費が決まるわけではありません。より影響が大きいのは、そのサーバー群から最終的にモデルへ公開されるTool Definitionの数と大きさです。

10台のサーバーを接続していても、それぞれ2個ずつの小さなToolしかなければ20 Toolsです。反対に1台のMCP Gatewayが100 Toolsを公開していれば、サーバーは1台でもTool Catalogは巨大になります。

さらにClaude Codeでは、MCPのTool Definitionは既定で遅延読み込みされる、と公式に説明されています。この記事では、何が遅くなり得るのか、Tool数とコンテキストの関係、Claude Codeでの確認方法、Tool Searchやdefer_loadingを使う場面を整理します。Tool Searchの詳しい数値と考え方はAIエージェントが存在しないツールを呼び出す原因｜Tool Callingのハルシネーション対策で解説しているため、この記事ではMCPの構成の側から扱います。

なお、この記事は公式ドキュメントで確認できる仕組みと数値をもとに整理しています。実際の速度は環境によって変わるため、特定の実測値は示していません。

MCPサーバーの数とTool数は別に考える

まず、MCP Server数と利用可能なTool数を分けて考えます。

構成1
Server A: tool_a, tool_b
Server B: tool_c, tool_d
Server C: tool_e
  → MCP Server 3台 / Tools 5個

構成2
Server A: 100 Tools
  → MCP Server 1台 / Tools 100個

AIモデルのContextという意味では、構成2のほうが重くなる可能性があります。「MCPを10個接続したから重い」というより、「接続したMCPから何個のTool Definitionがモデルへ渡されているか」を見るほうが重要です。

遅くなる原因は3種類に分けて考える

MCPを増やして重く感じたとき、原因は1つとは限りません。次の3つに分けると切り分けやすくなります。

• 接続管理の負荷：Processの起動、Network通信、Tool一覧の取得
• Tool Definitionのコンテキスト消費：Tool名・Description・inputSchemaをモデルへ渡す分
• Tool Resultのコンテキスト消費：Toolを実行した結果が履歴に積み上がる分

これらは別の問題です。接続管理が軽くてもTool Definitionが巨大なら、モデルへ渡すコンテキストは大きくなります。

stdioサーバーを増やすとProcess起動コストは増える

stdio MCPでは、HostがMCP Serverを子Processとして起動します（仕組みはMCPのstdioとStreamable HTTPの違い｜ローカル・リモート構成の選び方で解説しています）。stdio Serverを5台登録してHostがすべて起動するなら、Python・Node.js・Dockerなどの子Processが複数立ち上がります。Runtimeの起動、Moduleの読み込み、設定やCredentialの確認が、サーバーの数だけ発生します。

そのためMCPサーバーを大量に登録すると、Hostの起動時間やMemory使用量に影響する可能性はあります。ただしこれはHost側の負荷であり、モデルの推論やコンテキストの話とは別です。

Remote MCPではNetwork通信とCache Hintが関係する

Streamable HTTPのRemote MCPならLocal Processの起動はありませんが、Host → Network → MCP Serverの通信が発生します。複数Serverからtools/listを取得するなら、その分のRequestが必要です。

MCP 2026-07-28では、tools/listの結果にttlMsとcacheScopeというCache Hintを付けられ、Clientは一定期間その結果を再利用できます。仕組みと設定はMCPサーバーが起動するのにツール一覧が表示されない原因｜tools/listを確認で解説しています。ただし、これはTool一覧の取得負荷を減らす仕組みで、モデルへ渡すTool Definitionの量を減らすものではありません。

Tool Catalogはコンテキストを消費する

AIモデルが「GitHubのIssueを検索するのか、Slackを検索するのか」を判断するには、利用可能なToolの情報が必要です。Tool Definitionは概念的に次のような情報です。

{
  "name": "search_issues",
  "description": "Search GitHub issues",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Issue search query"
      },
      "repository": {
        "type": "string",
        "description": "Repository name"
      }
    },
    "required": ["query"]
  }
}

1個なら小さなものですが、同様の定義が100個あり、そのすべてを最初からモデルへ読み込ませる方式なら大きなContextになります。ユーザーから見るとContext Windowは「会話履歴・CLAUDE.md・読み込んだファイル」を想像しやすいですが、Tool Definitionもその一部です。

また、Tool数だけでなく1 Toolあたりの定義の大きさも関係します。概念的には「Tool数 × 平均のTool Definitionサイズ」です。50 Toolsでも簡潔なら比較的小さく、20 Toolsでも巨大なJSON Schemaと長いDescriptionが並べば重くなります。

Anthropicが示している目安

AnthropicのTool Searchのドキュメントには、次のような数値があります。

• GitHub・Slack・Sentry・Grafana・Splunkを接続する典型的なMulti-server構成では、Tool Definitionだけで約55,000 Tokensを消費し得る
• 利用可能なToolが30〜50個を超えると、Claudeが正しいToolを選ぶ精度が下がり始める
• Tool Searchを使うと、この消費を通常85%以上減らせ、必要な3〜5個のToolだけを読み込む

重要なのは、「5 Serverだから55,000 Tokens」ではないことです。各Serviceが大量のToolとSchemaを提供しているためで、サーバー数ではなく最終的なTool Catalogの大きさが効いています。また、これはMCP Protocolの上限ではなく、ClaudeでToolを使う場合の目安です。

Claude CodeではMCPのTool Definitionは既定で遅延される

では、Claude Codeで「使っていないMCPでもコンテキストを消費するのか」。2026年10月時点のClaude Code公式ドキュメント（コスト管理のページ）では、次のように説明されています。MCPのTool Definitionは既定で遅延され、Claudeが特定のToolを使うまでは、Tool名とServer instructionsだけがコンテキストに入る、という内容です。

つまりClaude Codeの既定では、MCPサーバーを増やしても、全Toolの完全な定義が毎回モデルへ渡されるわけではありません。コンテキストを消費するのは、Tool名の一覧と各ServerのInstructionsです。Server instructionsもコンテキストに入るため、長くなりすぎないよう注意します。

ただし、公式ドキュメントでは、次の構成ではTool Searchが使われず、Tool Definitionが先に読み込まれるとされています。

• Google Cloud Agent Platformで、Claude 4.5より前のモデルを使っている
• ANTHROPIC_BASE_URLが自社（First-party）以外のホストを指している（多くのProxyがtool_referenceを転送しないため）
• Azure上でホストされたMicrosoft Foundryのデプロイを使っている
• ENABLE_TOOL_SEARCH=falseを設定している（毎ターン、すべてのTool Definitionがコンテキストへ入る）

これらの構成では、「Tool Definitionが先に読み込まれる」前提で、Toolの数と大きさを見直します。

ENABLE_TOOL_SEARCHで挙動を切り替える

環境変数ENABLE_TOOL_SEARCHで、Tool Searchの挙動を切り替えられます。Claude CodeのドキュメントのAgent SDKのページに値の一覧があります。

• 未設定：Tool Searchが有効で、Tool Definitionは遅延され、必要に応じて検索・読み込みされる
• true：常にTool Searchを有効にする。Proxyがtool_referenceに対応していないと、Requestが失敗する
• auto：遅延できるTool Definitionの合計がモデルのContext Windowの10%に達したらTool Searchを有効にする。それ未満なら全Toolを先に読み込む
• auto:N：autoの閾値をN%にする（auto:5なら5%）。値が小さいほど早く有効になる
• false：Tool Searchを無効にする。全Tool Definitionを毎ターン読み込む

autoの閾値に数えられるのは、遅延できるTool Definitionです。BashやReadなど中核の組み込みToolは常に先に読み込まれ、閾値には含まれません。また、特定のServerをTool Searchの対象から外すalwaysLoadという設定もあります（詳細はClaude Code公式のMCPのページを参照してください）。

Tool Searchは、Claudeが検索するたびに1往復ぶんの通信が増えます。Toolが多い場合は、毎ターンのContextが小さくなる効果で相殺されますが、Toolが10個前後で定義も小さいなら、先にすべて読み込むほうが通常は速いと説明されています。1回の検索で読み込まれるのは、既定で関連性の高い最大5個です。

/contextと/mcpで実際の消費を確認する

Claude Codeのコスト管理のドキュメントでは、MCPのオーバーヘッドを減らす方法として、次のようなものが挙げられています。

• /contextを実行して、何がコンテキストを消費しているかを確認する
• /mcpで設定済みのServerを確認し、使っていないものを無効にする
• gh・aws・gcloud・sentry-cliのようなCLI Toolがあるなら、MCP Serverより優先する（Toolごとの一覧が増えないため、コンテキスト効率がよい）

特定のServerの影響を見たいときは/usageも使えます。Pro・Max・Team・Enterpriseのプランでは、直近の使用量がSkill・Subagent・Plugin・MCP Serverごとの割合で表示されます。ただしMCP Serverの割合に数えられるのは、そのServerのTool Resultを消費したRequestだけなので、Tool Definitionの消費量を直接示すものではありません。

「MCPを何台入れたか」ではなく、/contextで実際の消費を見る、というのが最初の切り分けになります。公式の説明どおりに遅延されないという報告がGitHubのIssueにもあるため（バージョンや接続方式によって挙動が変わる可能性があります）、まず実測で確認してください。Claude Code全体のコンテキスト管理はClaude Code コスト・コンテキスト管理完全ガイドも参考になります。

APIでMCPコネクタを使うならdefer_loadingを指定する

Claude Codeではなく、Claude APIのMCPコネクタ（ベータ機能）でMCPを使う場合は、mcp_toolsetでToolごとの設定ができます。Tool Definitionをモデルの初期Contextへ入れたくないなら、defer_loadingを指定します。個々のToolの定義に直接書くのではなく、default_configでServer全体、configsでToolごとに指定します。

{
  "type": "mcp_toolset",
  "mcp_server_name": "google-calendar-mcp",
  "default_config": {
    "defer_loading": true
  },
  "configs": {
    "search_events": {
      "enabled": false
    }
  }
}

この例では、Server全体を遅延読み込みにしたうえで、search_eventsだけを無効にしています。設定の優先順位は、Toolごとのconfigs、default_config、システムの既定値の順です。

Tool Searchを使う場合、公式は最もよく使う3〜5個のToolは遅延させず常時ロードしておくことを勧めています。Toolを呼ぶたびに検索を挟まずに済むからです。名前はサービス名やリソース名でPrefixを揃える（github_、slack_など）と、1回の検索でグループごとヒットしやすくなります。公式のドキュメントでも、query_slackよりsearch_slack_messagesのように対象まで含めた名前、「Search Slack messages by keyword, channel, or date range」のように具体的なKeywordを含むDescriptionのほうが、検索に引っかかりやすいと説明されています。

Tool Searchが不要な場合もある

Tool Searchは、大規模なTool Catalogで効果が出る仕組みです。公式は、次のような場合に使うことを勧めています。

• 利用可能なToolが10個以上ある
• Tool Definitionの合計が10,000 Tokensを超える
• Toolが増えるにつれて選択精度が落ちている
• 複数のMCP Serverを集約している

逆に、Toolが10個未満で、すべてを毎回使い、定義も小さい（合計100 Tokens未満程度）なら、通常のTool Callingのほうが適していると説明されています。「MCPを10個超えたら遅い」というProtocol上の制限があるわけではなく、導入するかどうかの実用的な判断基準です。10個の小さなToolなら問題にならず、8個でもSchemaが巨大なら大きくコンテキストを使います。

MCPサーバーを統合してもTool数が同じなら解決しない

10個のMCP Serverを1つのGatewayへ統合したとします。変更前が「10 Servers・合計100 Tools」で、変更後が「1 Gateway・100 Tools」なら、Processや接続の管理は単純になります。しかしモデルへ100個すべてのDefinitionを渡しているなら、Tool Contextの問題はほぼ残ります。

逆に、10 Serverのままでも、Taskごとに必要なToolだけを公開できればコンテキストは抑えられます。Server Consolidation（サーバーの統合）とTool Context Optimization（コンテキストの最適化）は別の問題です。

Paginationやキャッシュはコンテキスト削減とは別

MCPのtools/listはPaginationに対応しています。Toolが大量にあるServerでは、50個ずつのPageに分けて返せます。これはNetworkやSerializationの負荷を下げるうえでは有効です。しかし、Clientが最終的に全Pageを取得して150 Toolsすべてをモデルへ渡すなら、モデルのContext消費は150 Tools分のままです。

キャッシュも同じです。tools/listをキャッシュすればServerへのRound Tripは減りますが、キャッシュしたDefinitionを毎回モデルへ渡す方式なら、モデルが扱う量は変わりません。Prompt Cachingも、同じ内容を繰り返し処理する費用を下げるものであり、Context Window上のToken数そのものが消えるわけではありません。

Pagination / list_changed / Cache
  → Tool一覧の「取得方法」を効率化する

Tool Search / defer_loading / 用途別の有効化
  → モデルへ実際に読み込む「Definitionの量」を絞る

Tool Resultもコンテキストを消費する

Tool Catalogを小さくしても、Tool実行後に巨大なResultを返せばContextは増えます。最初にTool Definitionで消費し、Toolを呼ぶたびにResultで消費し、その履歴が次のTool Callにも持ち越されます。長時間動くAgentほど影響が大きくなります。

Claude Codeでは、MCP Toolの出力が10,000 Tokensを超えると警告が表示され、既定の上限は25,000 Tokensです。上限はMAX_MCP_OUTPUT_TOKENS環境変数で変更できますが、上げる前にToolが返す量を絞る設計を優先するべきでしょう。Result側の設計はMCPで巨大なレスポンスを返してはいけない理由｜トークン消費を減らす設計で解説しています。コンテキスト全体が足りなくなる原因はAIエージェントのコンテキストが足りなくなる原因｜履歴圧縮・ツール設計も参考になります。

Tool Definitionを小さくする設計

Tool Searchに頼る前に、Definition自体を小さくできる場合があります。

• Descriptionを必要十分に絞る：「何をするToolか」「いつ使うか」「似たToolと何が違うか」が分かる範囲にします。長い利用マニュアルはPromptやSkillなど別の仕組みへ分けます。
• inputSchemaを必要なFieldに絞る：深いNested ObjectやFieldごとの長い説明は、そのままコンテキストになります。書き方はMCPツールのinputSchemaはどう書く？JSON Schemaの実例付きで解説で解説しています。
• 似たToolを増やさない：同じ意味のToolが複数あると、選択精度も下がります。
• 万能Toolへまとめない：Tool数を減らすためにexecuteへすべて詰め込むと、inputSchemaが巨大になり、何を指定すべきかも複雑になります。

Tool、Resource、Promptの役割分担も関係します。Resourceは必要なときにresources/readされる参照データなので、大量の知識をすべてTool Descriptionへ入れるより、Resourceとして必要な分だけ取得させるほうが効率的な場合があります（MCPのtools・resources・promptsの違い｜何をどこに実装するべきか）。

Toolを動的に公開する方法もあるが万能ではない

MCPではServer実行中にTool一覧を変えて、変化をClientへ通知できます。仕様上はnotifications/tools/list_changedで通知し、Clientがtools/listを再取得します。たとえば最初はenable_github・enable_databaseのようなToolだけを公開し、有効化した後に関連Toolを追加する、という設計も考えられます。

ただしHost側のTool Catalog更新やContext管理に依存するため、Server側でToolを出し入れすれば必ずコンテキストが小さくなるとは限りません。大規模な環境では、Hostが対応しているTool Searchや遅延読み込みのほうが扱いやすい場合があります。

実際のTool Catalogを測る

Server数だけでは判断できないため、実際のTool Catalogを確認します。tools/listを取得して、Tool数とDefinitionの大きさを集計できます。次のコードはClient APIの形を示す擬似コードです。利用するSDKに合わせて読み替えてください。

import json

summary = []

for server_name, client in clients.items():
    result = await client.list_tools()

    size = sum(
        len(json.dumps(tool.model_dump()))
        for tool in result.tools
    )

    summary.append(
        (server_name, len(result.tools), size)
    )

for name, count, size in sorted(
    summary, key=lambda x: x[2], reverse=True
):
    print(f"{name}: {count} tools, {size} chars")

文字数はToken数そのものではなく、あくまで比較のための目安です。たとえばServer Aが12 Tools、Server Bが48 Tools、Server Cが3 Toolsなら、Server Bを重点的に見直したほうが改善幅は大きくなります。Server Cを消して3 Tools減らすより効果があります。

用途ごとにMCPを有効化する

Tool Searchが使えない構成や、そもそも不要なMCPが多い場合は、単純な対策が有効です。Web開発中に使うのがGitHub・Filesystem・Databaseだけなら、Slack・Sentry・Google Drive・Notionまで常時有効にする必要はありません。

Coding用
  GitHub + Filesystem + DB

運用調査用
  Sentry + Grafana + Logs

ドキュメント作業用
  Drive + Notion + Docs

Claude CodeではMCP ServerをUser・Project・Localなどのスコープに定義できるため、案件や用途ごとに必要なServerだけをProjectやLocalへ置くと、モデルへ見せるTool Catalogを自然に小さくできます。使っていないServerは/mcpで無効にもできます。Claude CodeでのMCPの基本的な設定はClaude Code MCP完全ガイド｜GitHub・Figma・DBを接続してAIの能力を拡張する方法で解説しています。MCPは「インストールできるから全部有効」にするのではなく、「現在のTaskで使う可能性があるか」を基準に有効化すると効率的です。

MCPサーバーの複数接続に関するよくある質問

遅さを感じたらServer数よりTool Definitionの総量を確認する

MCPサーバーを複数接続すれば、stdio Processの起動やRemote Serverへの通信など、接続管理の負荷は多少増えます。しかしAIモデル側で大きな問題になりやすいのは、Server数よりも、そこから公開されるTool Definitionの総量です。「10 Server × 2 Tools」と「1 Server × 100 Tools」では、後者のほうがTool Contextを大きく消費する可能性があります。

Claude Codeでは、MCPのTool Definitionは既定で遅延され、Toolを使うまではTool名とServer instructionsだけがコンテキストに入ります。実際の消費は/contextで確認でき、不要なServerは/mcpで無効にできます。Tool Searchが使われない構成では、Tool Definitionが先に読み込まれるため、Toolの数と大きさを見直します。

Tool数が多いClaude APIの構成では、Tool Searchとdefer_loadingで必要なToolだけを読み込めます。ただしPaginationやキャッシュはコンテキストの削減策ではありません。さらにTool Result自体もコンテキストを消費するため、Tool Catalogを小さくする、必要なToolだけ読み込む、Tool Resultも小さく返す、という3段階で設計すると効率的です。

MCPサーバーを増やして重いと感じたら、「何台接続しているか」ではなく、「最終的に何個・どれだけの大きさのTool Definitionをモデルへ見せているか」を確認するのが、最初の切り分けになります。