MCP（Model Context Protocol）の普及で、ローカルLLMのエージェントにも「MCPサーバーを2〜3台繋いだらツールが30個になった」という状況が当たり前になりました。ここで重要なのは、接続したツールの定義（名前・説明・引数スキーマ）は、使う・使わないに関係なく毎回すべてモデルに渡されることです。「ツールが増えると選択精度が落ちる」「似た名前のツールを取り違える」という指摘は業界で相次いでいますが、日本語×ローカルLLMでの実測データはほぼありません。そこで、当サイトの日本語エージェント信頼性ベンチと同一の6タスク・同一採点のまま、ツール数だけを5個→15個→30個に増やす3条件を7モデル×各18試行（計378試行）、RTX A6000で実測しました。

結論

  • 上位モデルはツール30個でも壊れません。Gemma4 26BとQwen3.6 35Bは3条件すべて満点（各54/54試行）でした。
  • 「似た名前のツールを取り違える」は1件も起きませんでした。get_weather（現在の天気）に対する get_weather_forecast（週間予報）のような近接名トラップを最大25個仕込んでも、取り違え（wrong_tool）は378試行で0件。壊れたJSON・引数スキーマ違反も0件です。
  • 劣化が出るときの中身は「取り違え」ではなく「呼ばない」。ツール数と共に一貫して下がったのは旧世代のQwen2.5 7Bだけ（100→94→89%）で、増えた失敗はすべてno_call＝呼ぶべき場面でツールを使わず文章で答える、でした。
  • レイテンシへの影響はA6000では軽微（ツール5→30個で中央値+0.0〜0.4秒程度・参考値）。
  • 実務指針: 30個程度までは「モデル選び」と「説明文の書き分け」で安全圏。ただし数百個規模はコンテキスト消費が別次元になり、ツールの検索型ロード等の設計が必要です（後述）。

背景 — MCPの「ツール数問題」とは

MCPの仕組み ― 接続したサーバーのツール定義は、使う・使わないに関係なく毎回すべてモデルに渡る

ファイル操作MCP

read_filewrite_filesearch_files…

GitHub MCP

create_issuesearch_repositories…

カレンダーMCP など

create_calendar_event…

モデルへの入力（毎回のリクエスト）

ツール定義の束（使わない分も含む）

本記事の実測はここを 5個 → 15個 → 30個 に増やして比較

あなたの質問

「東京の天気を教えて。」

ツール定義はコンテキスト（モデルが一度に読める量）を常時消費します。数百〜数千個の規模では読むだけで数十万トークンに達しうる、という報告もあります（本文の根拠リンク参照）。

ツール定義はシステムプロンプトの一部としてモデルに毎回入力されます。Anthropicのエンジニアリングブログは、数十のMCPサーバーで数百〜数千のツールに接続するエージェントではリクエストを読む前に処理するトークンが数十万に達しうると指摘しています（根拠: Anthropic – Code execution with MCP）。また同社のツール設計ガイドは「ツールは多いほど良いわけではない」として、タスクに関係するツールだけを選択的に持たせる設計を推奨しています（根拠: Anthropic – Writing effective tools for agents）。

学術側でも、6つの商用LLM×30のMCPツールスイート・約2万API呼び出しの大規模評価で「MCP統合は必ずしも性能向上につながらない」ことが報告され（根拠: Help or Hurdle? — arXiv:2508.12566）、ツール定義を全部渡す代わりに関連ツールだけ検索して渡すRAG-MCPで選択精度が大きく改善したという報告もあります（根拠: WRITER – RAG-MCP）。

つまり「ツール数はタダではない」が業界の共通認識です。ではコンテキスト長もGPUも限られるローカルLLM・日本語タスクでは、何個まで安全なのか——それが本記事の実測です。

計測方法

  • ベース: 日本語エージェント信頼性ベンチと同一の6タスク（天気・足し算・Web検索・タイマー・メールのツールを呼ぶべき5問＋雑談1問＝呼ぶべきでない1問）・同一採点・各3回＝18試行/条件・temperature 0.7。
  • ツール数3条件: 5個（既存ベンチと同一構成＝歴代実測との互換アンカー）／15個／30個。追加分の距離子（distractor）は実在の代表的MCPサーバー（filesystem・fetch・github・slack・time・memory・sqlite・puppeteer・gdrive・calendar相当）の典型ツールを再現したものです。
  • 近接名トラップを意図的に含めます: get_weather_forecast（↔正解 get_weather）、multiply_numbers（↔ add_numbers）、search_files・search_repositories・search_documents（↔ search_web）、send_slack_message（↔ send_email）、create_calendar_event・get_current_time（↔ set_timer）。説明文は「現在の天気 vs 明日以降の予報」のように明確に書き分けてあるため、取り違えは曖昧さでなくモデルの選択ミスとして数えられます。
  • 15個・30個の条件ではツールを関数名でソートして渡し、正解ツールが先頭に並ぶ有利を消しています（MCPクライアントの一般的な挙動に合わせた設計）。
  • 計測スクリプトは scripts/bench_mcp_tools.py（ollama /api/chat・A6000・ollama 0.31.1）。数値の一次記録は監査用YAML（docs/measurements/）に保存しています。
仕込んだ「近接名トラップ」― 名前が紛らわしくても、説明文だけで選び分けられるか

✓ get_weather

現在の天気を取得

⚠ get_weather_forecast

明日以降の週間予報（現在の天気は対象外）

✓ add_numbers

2つの数値を足し算

⚠ multiply_numbers

2つの数値を掛け算

✓ search_web

Webを検索

⚠ search_files / search_documents

ローカル・社内文書の検索（Webは対象外）

✓ send_email

メールを送信

⚠ send_slack_message

Slackに投稿（メールは送れない）

✓ set_timer

タイマーを分単位でセット

⚠ create_calendar_event / get_current_time

予定の作成・現在時刻の取得

左＝タスクの正解ツール、右＝わざと混ぜた紛らわしいツール（実在MCPサーバー相当の距離子25個の一部）。説明文は明確に書き分けてあるため、取り違えたらモデルの選択ミスとして数えます。結果: 7モデル×378試行で取り違えは0件でした。

実測結果 — 5個 vs 15個 vs 30個

① ツール5個（既存FCベンチと同一構成＝互換アンカー）
  • Qwen3.5 2B83%
  • Qwen3.5 4B94%
  • Qwen2.5 7B100%
  • LFM2.5 8B100%
  • gpt-oss 20B89%
  • Gemma4 26B100%
  • Qwen3.6 35B100%
② ツール15個（MCPサーバー2〜3台相当・距離子10個追加）
  • Qwen3.5 2B100%
  • Qwen3.5 4B100%
  • Qwen2.5 7B94%
  • LFM2.5 8B94%
  • gpt-oss 20B83%
  • Gemma4 26B100%
  • Qwen3.6 35B100%
③ ツール30個（MCPサーバー5〜6台相当・距離子25個追加）
  • Qwen3.5 2B89%
  • Qwen3.5 4B100%
  • Qwen2.5 7B89%
  • LFM2.5 8B100%
  • gpt-oss 20B89%
  • Gemma4 26B100%
  • Qwen3.6 35B100%

各条件18試行（6タスク×3回・temp0.7・A6000・ollama 0.31.1）。1試行=5.6ptのため±1〜2試行差はノイズ。ツール5→30個で一貫して下がったのはQwen2.5 7Bのみ、Gemma4 26B・Qwen3.6 35Bは全条件満点（54/54）。要検証。

モデル5個15個30個増えた失敗の中身
Qwen3.5 2B83%100%89%誤呼び出し（雑談に呼ぶ）×2〜3。ツール数と無相関
Qwen3.5 4B94%100%100%5個条件のno_call×1のみ（ノイズ範囲）
Qwen2.5 7B100%94%89%no_call が単調増加（唯一の一貫した劣化）
LFM2.5 8B100%94%100%15個条件のno_call×1のみ（ノイズ範囲）
gpt-oss 20B89%83%89%no_call×2〜3。ツール数と無相関の定常癖
Gemma4 26B100%100%100%なし（54/54）
Qwen3.6 35B100%100%100%なし（54/54）

18試行/条件のため1試行=5.6pt。±1〜2試行（≒6〜11pt）の差はノイズとして読んでください。ツール5個条件は2026年6月の歴代実測と全モデル±1試行内で一致しており、ベンチの再現性の傍証になっています。

所見 — 「壊れ方」の通説と実測のズレ

ツールを増やすと何が壊れるのか ― 通説と実測（378試行）のズレ

起きなかった失敗（通説が警告するもの）

  • 似た名前のツールを取り違える0件
  • 壊れたJSONを返す0件
  • 引数スキーマを壊す0件

実際に起きた失敗（17件）

  • 呼ぶべき場面で呼ばない（no_call）＝萎縮12件
  • 雑談にツールを呼ぶ（誤呼び出し）＝呼びすぎ5件

no_callはQwen2.5 7B（ツール数と共に増加）とgpt-oss 20B（数と無関係の定常癖）、誤呼び出しはQwen3.5 2Bに集中。

378試行中361件は正解。失敗は「形」（JSON・ツール名）ではなくすべて「判断」（呼ぶ・呼ばない）で起きました＝ツールが増えると壊れるのではなく、呼ばなくなる。

  1. 取り違え0件の意味: 業界で語られる「似た名前のツールを取り違える」失敗は、説明文が明確に書き分けられていれば30個規模では起きませんでした。これは裏返すと「取り違えが起きる環境は、ツール数ではなく説明文の曖昧さが原因の可能性が高い」ということです。ツール定義の説明文はエージェントの精度部品です（Anthropicのガイドと同じ結論を、日本語ローカルLLMの一次データで確認）。
  2. 劣化は「萎縮」として現れる: Qwen2.5 7Bで増えたのはすべてno_call——選択肢が30個に増えると「どれも選ばない」方向に倒れる。取り違えて誤動作するより安全側の失敗ですが、「呼ばれないエージェント」は仕事をしません。当サイトの過去実測（単発・連鎖・量子化）でも、失敗は常に「形」でなく「判断」で起きており、今回も同じパターンでした。
  3. 世代の効果が大きい: 同じQwen族でも、2024年世代のQwen2.5 7Bだけが一貫して劣化し、2026年世代のQwen3.5 4Bはツール30個で満点でした。サイズよりも学習世代——大量ツールを前提にした最近の学習（MCP時代のデータ）の効果と推測されます（推測・要検証）。
  4. 小型の癖・中型の癖はツール数と無関係に出る: Qwen3.5 2Bの誤呼び出し（雑談にツールを呼ぶ）は5個でも30個でも出る持病で、gpt-oss 20Bのno_call×2〜3も3条件でほぼ一定でした。ツール数を絞っても、モデル固有の癖は消えません。
  5. レイテンシ: ツール5→30個で応答中央値は+0.0〜0.4秒程度（A6000・プレフィックスキャッシュ込みの参考値）。強いGPUでは実用上無視できますが、プロンプト処理が遅いエッジ機（Pi5等）ではツール定義の肥大がそのまま待ち時間になるはずで、未測定です（要検証）。

エージェントを組むときの実務指針

  • 〜30個は「設計で安全圏」: 新しめのツール対応モデル（Qwen3.5 4B以上・Gemma4・Qwen3.6）を選び、ツールの説明文を書き分ければ、MCPサーバー数台ぶんのツール数は精度の壁になりません。
  • ツール説明文は「隣のツールとの違い」を書く: 今回トラップが機能しなかった最大の要因は「現在の天気（予報は対象外）」のような排他条件の明記です。名前の工夫より説明文の書き分けが効きます。
  • 使わないMCPサーバーは外す: 精度が保たれても、ツール定義はコンテキストと処理時間を常時消費します。コンテキスト長が短く prefill も遅いローカル環境では、クラウド以上に「絞る」価値があります（エージェントループの設計）。
  • 数百個規模は別の設計へ: ツールの検索型ロード（必要なツールだけ都度渡す）やコード実行型MCPが提案されています（根拠: Anthropic・WRITER）。本実測は30個までの話です。
  • 旧世代モデルを使い続けるなら要再測定: 手元のモデルがQwen2.5世代以前なら、ツールを足すたびに「呼ばれない」失敗が静かに増えている可能性があります。

精度等について

  • 各条件18試行の小サンプルです。±1〜2試行の差はノイズであり、本文の結論は「3条件で一貫した傾向」だけに絞っています（それでも経験則・要検証）。
  • タスクは代表6問で、実務のエージェントより簡単です。多段の連鎖×大量ツールの組み合わせは未測定で、連鎖では差が大きく開くことが分かっています（連鎖ベンチ）。
  • 距離子は実在MCPサーバーの典型ツールを再現した「相当品」で、各サーバーの実スキーマそのものではありません。また説明文は意図的に明確へ書き分けており、雑な説明文のツール群では結果が悪化しうると考えるのが安全です。
  • 30個までの実測であり、100個・数百個への外挿はできません。コンテキスト長の限界（モデル・量子化・ollama設定に依存）に近づくと別の失敗が出るはずです。
  • 実測はollama 0.31.1・公開GGUF・temperature 0.7での結果です。別ランタイム・別テンプレートでは挙動が変わる可能性があります。

関連