In Silico

AIエージェント

MCPのツールが多すぎるとツール選択を誤る：原因と、検索で絞る対策

2026/7/3 （更新: 2026/10/11）

🤖 AIを使用して執筆

  • ツール選択
  • AIエージェント
  • MCP
  • RAG-MCP
  • Tool Search Tool
  • Claude Code
  • OpenHands
  • MCP-Zero
  • LiveMCPBench
  • BFCL
  • ToolBench
  • BM25
  • 埋め込み
  • ツール定義
  • コンテキストウィンドウ
  • コンテキスト・ロット
  • 選択精度
  • 被覆
  • 提示率
  • 検索
  • トークン
  • プロンプト
  • Anthropic
  • OpenAI
  • Chroma
目次
背景・問い・要点
背景

AIに仕事をさせるとき、使えるツールを増やすほど有能になる、と考えるのは自然だ。ファイルを読む、検索する、外部のサービスに問い合わせる。できることが増えれば、任せられる仕事の幅も広がるように見える。ツールを足す作業は成果が目に見えるし、足しただけ効くように思える。

だがツールは、渡した瞬間から場所を取る。AIは仕事を始める前に、どんなツールがあり、それぞれ何をして、どう呼び出すのかという説明書を読み込む。並べただけで説明書がAIの一度に読める量を占め、考えるのに使える分がその分だけ減る。しかも並んだ数が増えるほど、目の前の仕事にどれが要るのかという判断そのものが難しくなる。人間の作業者でも、道具箱が大きすぎれば選ぶのに迷う。

つまり増やすことには二つの代償がある。選びにくくなることと、始める前に読める量を使ってしまうこと。どちらもツールそのものの出来とは関係がなく、渡し方の側で起きている。

問い

ツールは多いほうがよいのか。それとも、渡し方のほうを変えるべきなのか。

要点

多いほうがよい、は裏返る。効くのはツールを増やすことではなく、必要なツールだけを検索して渡すことである。 ツール／MCP（エージェントが呼び出せる外部機能とその接続規格）の一覧が長すぎると、正しいツールを選ぶ精度はむしろ落ちる。しかもツールの「説明書」だけで、仕事を始める前にコンテキストのかなりの部分が埋まる。Anthropic は、つないだ MCP のツール定義が数万から十数万トークンに達した例を挙げている1。研究が示す直し方は、全部を常時見せるのをやめ、必要なツールだけを検索して渡すこと。ある手法（RAG-MCP）では、ツール選択の精度が3倍超に上がり、プロンプトのトークンも約半分に減った2。

モデル・例示

ツールが100個あるとき、全部渡すか5個に絞るか

※ この節の数値は説明のための仮定で、測定値ではありません。

ツールの説明書が1個あたり500トークンだとする。100個を全部渡すと、仕事を始める前に5万トークンが埋まる。5個に絞れば2,500トークンで済む。

正しく答えられる割合は、正解のツールが一覧に入る割合と、入ったときに選べる割合の積で決まる。全部渡すと正解は必ず一覧に入るが、似たツールが多いので選べるのは半分だとする。このとき正しく答えられるのは 100% × 50% で 50% になる。5個に絞ると正解が漏れる問いが2割出るが、入っていれば9割選べるとする。このときは 80% × 90% で 72% になる。

1個だけ渡すと、入っていれば必ず選べるので、選べる割合は100%に見える。だが正解が入る問いが6割なら、正しく答えられるのは60%にとどまる。絞るほど選びやすくなる一方で、正解が漏れる問いも増える。

何が起きるのか

ツールが増えると二つの問題が同時に起きる。一つは選択の混乱。Anthropic は自社の経験として、最も多い失敗はツールの取り違えと引数の誤りで、とくに名前の似たツールで起きると書いている1。「エージェントは何個のツールを見せられるべきか」を正面から測った査読前の研究は、20〜3,251個の登録で、一覧の長さを変えながら、正解のツールがその一覧に入る割合を測った3。そのうえで、質問ごとに見せる数を動的に変えるやり方は、固定数より常に良いわけではなく、条件によって勝ち負けが入れ替わる。同じやり方でも、スコアラーと登録が変わると探す深さが変わり、BFCL では BM25 で平均7.4個まで探すが、埋め込みでは1.4個で止まる。BFCL（370個の登録）で BM25 を使うと、50個提示の正解到達率 90.8% に対し、平均7個の提示で 90.3% とほぼ並ぶ。だが同じ BFCL で埋め込みを使うと、5個固定の 97.5% に対して動的は 85.0% と大きく下回る。ToolBench（登録3,251個・1問あたり候補50個の集合で測る）の集計でも固定が上回り、5個固定 64.7%・20個固定 77.3% に対し動的は 61.9% だった。動的側が上回るのは、5個固定と同じくらいの深さで比べた難問側である。正解が6〜20番手に沈む76問では、平均5.7個まで探す動的のやり方が16.7%に届き、5個固定は0%だった。20個固定はこの76問をすべて一覧に入れるので、動的の利点は深さを抑えたまま一部を拾える点にある（本稿の計算）。ここでの数字は実行の成功率ではなく、正解のツールが一覧に入っていた割合（被覆）である。

選択そのものは、BFCL の120問で Claude Sonnet 4.6 に選ばせて別に測っている。平均2.2個の動的一覧は、常に5個を見せるより正確に選び、精度は 93.1% 対 87.1% だった（いずれも正解が提示された問いに限った割合）。ただし正解を一覧に入れられた割合（提示率）は 76.9% 対 84.2% と動的のほうが低く、その積である最終正答率は 71.7% 対 73.3% で5個固定のほうが高い。中難度の23問では選べた割合が 76.8% 対 60.9% と開くが、動的が正解を提示できたのはその 62.3% だけなので、最終正答率は 47.8% 対 60.9% で、ここでも5個固定が上回る（本稿の計算）。1個だけ見せれば選べた割合は 100% になるが、提示率も最終正答率も 65.0% にとどまる。なお著者らは、この実験の探索器を指標の性質を調べるための探りであって本番構成の提案ではないと明記している3。

もう一つはコンテキストの圧迫。Anthropic は、5つの MCP サーバーの58ツールだけで、会話が始まる前に約5.5万トークンがツール定義で埋まる構成を例に挙げ、社内では最適化前のツール定義が13.4万トークンに達した例も見たと書いている1。13.4万トークンは、20万トークンのコンテキストウィンドウなら約3分の2にあたる（本稿の計算）。Chroma の研究は、入力が長くなるほど性能が落ちる「コンテキスト・ロット」も、18のモデル（Claude Sonnet 4・GPT-4.1・Gemini 2.5 Flash ほか）で一貫して観測している（実験ごとに入るモデルは異なる）4。ただし課題はどれも、長さの効果だけを見るよう意図して単純にしてある。そのうち会話の質問応答（LongMemEval）では、答えに要る部分だけの約300トークンを渡すほうが、無関係な部分を含む約11.3万トークンの全履歴を渡すより、どのモデルでも正答率が高かった4。著者らは、より複雑な統合や多段推論では劣化がさらに厳しくなると予想すると書いている。つまり、ツールを足すことはタダではない。足したツールは選択を難しくし、考えるのに使えるコンテキストを削る。

直し方＝検索して渡す

向かっている答えは、検索（retrieval）だ。全てのツールの説明を毎回プロンプトに積むのでなく、いまの質問に意味的に近いツールだけを取り出して渡す。RAG-MCP はこの発想で、最も近い MCP サーバー1つ分のスキーマだけをプロンプトに入れ、選択精度を13.62%→43.13%に上げ、プロンプトのトークンを約半分（49.2%減）にした2。この比較の表には、キーワードの一致で先に候補を絞る条件も載っており、プロンプトのトークンは全部提示より減ったが、精度は 18.20% にとどまった。測ったのは MCPBench の web 検索の課題で、モデルは qwen-max-0125 の1つだけである。原典は試行を20回と書くが、20回の割合では 13.62% も 43.13% も出ないので、実際の分母は追えず、小数点以下の桁は額面どおりには読めない。必要になったときにツールを能動的に探し出すという同じ方向のやり方は、MCP-Zero をはじめ複数の研究グループが並行して作っており5、単発のアイデアではなく一つの流れになっている。

これは研究の中だけの話ではない。実在するプロ用ハーネスも、同じ直し方を実装している。Anthropic は2025年11月、ツール定義を最初から読み込まず、必要になった時点で検索して渡す API 機能（Tool Search Tool、ベータ）を公開した1。社内評価では、大きなツール集合での MCP 評価の精度が、Opus 4 で 49% から 74% に、Opus 4.5 で 79.5% から 88.1% に上がったという。ただし課題や件数を明かしていない自社評価の値で、同社もツールが10個未満の小さな集合では利点が薄いと書いている。Claude Code も MCP のツールについて、起動時にはツールの名前とサーバーの指示だけを読み込み、定義は必要になってから検索して取り出す方式を既定にしている6。OpenAI も API に同じ方式のツール検索（tool_search）を用意し、関数と MCP サーバーのツールの定義を後から読み込めるようにしている7。ただし OpenAI の文書は、トークンと費用が減る「可能性がある」と書き、既定を決める前に課題の完了・入力トークン・待ち時間を比べるよう勧めている。

Anthropic はコンテキスト設計を論じた別のエンジニアリング記事で、外部ツールのコンテキストコストを「注意の予算」として扱い、用意するツールの集合そのものを絞れとも書いている。そこでは「最もよく見る失敗様式の一つは、機能を広く覆いすぎたり、どのツールを使うべきか判断が曖昧になる、膨れたツール群だ。人間の技術者がある状況でどのツールを使うべきか断定できないなら、AIエージェントにそれ以上を期待はできない」と述べる8。ただし、この記事が「必要になってから取り出す」と論じるのはツールの定義ではなくデータの側（ファイルパスや保存済みクエリを、その場で取りに行く）である。OpenHands は逆側からツールの集合を絞る。OpenHands はツールを足す基準を「LLM がコードで直に書くのは容易でないもの」か「外部モデルを包むもの」の時だけ、と明示し、コードで容易に書けることはツールにしない9。研究が示す「検索して渡す」と、これら実装や設計指針が採る「そもそもツールの集合を絞る／必要になってから取り出す」は、同じ向きを指している。

ただし検索も万能ではない。RAG-MCP でも精度は43%どまりで2、実在の70サーバー527ツールで測った LiveMCPBench でも、Claude の2モデルの失敗を人手で分けると、半分は検索が合うツールに届かないことによるものだった5。ツール選びは依然として難しく、検索そのものが新しい失敗の面を足す。

出典9件

  1. Anthropic「Introducing advanced tool use on the Claude Developer Platform」2025-11-24. https://www.anthropic.com/engineering/advanced-tool-use — Tool Search Tool（ベータ）の公開。58ツールで約5.5万トークン、社内で13.4万トークンの例。精度の向上は自社評価。 ↩ ↩2 ↩3 ↩4

  2. 「RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation」arXiv, 2025（掲載先未確認）. https://arxiv.org/abs/2505.03275 — 最も近い MCP サーバー1つの定義だけを渡し、全部提示と比べた。 ↩ ↩2 ↩3

  3. Repantis ほか「How Many Tools Should an LLM Agent See? A Chance-Corrected Answer」arXiv, 2026（査読前）. https://arxiv.org/abs/2605.24660 — 一覧の長さと正解の被覆を9条件で、Claude Sonnet 4.6 の選択精度を BFCL の120問で測った。 ↩ ↩2

  4. Chroma「Context Rot」. https://research.trychroma.com/context-rot — 18のモデルで、入力が長くなるほど単純な課題でも性能が落ちると報告。実験ごとに含まれるモデルは異なる。 ↩ ↩2

  5. MCP-Zero（arXiv:2506.01056）ほか、ツールを能動的に探す研究. https://arxiv.org/abs/2506.01056 — 同じ方向に ScaleMCP https://arxiv.org/abs/2505.06416 と LiveMCPBench https://arxiv.org/abs/2508.01780 がある。LiveMCPBench は実在の70サーバー527ツール・95課題で12モデルを測った。 ↩ ↩2

  6. Claude Code「Connect Claude Code to tools via MCP」閲覧2026-09. https://code.claude.com/docs/en/mcp — 「Scale with MCP tool search」節。ツールの定義を必要になるまで読み込まず、tool search を既定とする。既定になった時期はこの頁からは分からない。 ↩

  7. OpenAI「Tool search」API ドキュメント, 閲覧2026-10. https://developers.openai.com/api/docs/guides/tools-tool-search — 関数と MCP サーバーの定義を defer_loading で後回しにし、tool_search で読み込む。トークンと費用の削減は「可能性がある」と書く。 ↩

  8. Anthropic「Effective context engineering for AI agents」閲覧2026-07. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — 膨れたツール群を失敗様式に挙げ、最小限のツールの集合を勧める設計指針。just-in-time はデータ取得の議論で、製品の既定動作の規定ではない。 ↩

  9. Wang ほか「OpenHands: An Open Platform for AI Software Developers as Generalist Agents」ICLR 2025. https://arxiv.org/abs/2407.16741 — AgentSkills にツールを足すのは、LLM がコードで容易に書けないものか外部モデルを包むものの時だけ、と明示する。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。