AIエージェント
道具を増やすほど、エージェントは選べなくなる——『全部渡す』をやめて『検索して渡す』へ
要点: エージェントに道具(ツール/MCP)をたくさん持たせると賢くなる——という直感は、実務では裏返る。道具の一覧が長くなるほど、正しい道具を選ぶ精度は落ちる。しかも道具の「説明書」だけで文脈(コンテキスト)の大半が食われる:GitHub・Slack・Sentry のわずか3つの MCP(約40の道具)で、20万トークンの文脈のうち14.3万がツール定義に消えた、という報告もある1。研究が示す直し方は、全部を常時見せるのをやめ、必要な道具だけを検索して渡すこと。ある手法(RAG-MCP)では、道具選択の精度が13.62%から43.13%へ3倍超に上がり、プロンプトのトークンも半分以下に減った2。
何が起きるのか
道具が増えると二つの問題が同時に起きる。一つは選択の混乱。「エージェントは何個の道具を見せられるべきか」を正面から測った研究は、20〜3,251個の登録から道具を提示して、多すぎる一覧はモデルを迷わせ、少なすぎると正解を取りこぼすという板挟みを示した3。そのうえで、質問ごとに見せる数を動的に変えるやり方が、固定サイズより良かった——同じ精度を、平均50個ではなく約7個の提示で達成し、3,251個の難しい問い(ToolBench)では、5個に絞ると16.7%を解けたのに、大きな固定リストでは0%だった3。
もう一つは文脈の圧迫。標準的な MCP 構成では、仕事を始める前に文脈の約7割がツール定義で埋まる、との実務報告がある1。文脈が長く詰まるほど推論自体が鈍る「コンテキスト・ロット」も、18のモデル(Claude Sonnet 4・GPT-4.1・Gemini 2.5 Flash ほか)で一貫して観測されている4。つまり、道具を足すことはタダではない——選びにくくし、考える余白を削る。
直し方=検索して渡す
向かっている答えは、より大きな文脈窓ではなく、検索(retrieval)だ。全ての道具の説明を毎回プロンプトに積むのでなく、いまの質問に意味的に近い道具だけを取り出して渡す。RAG-MCP はこの発想で、選択精度を13.62%→43.13%に上げ、プロンプトを半分以下にした2。同じ方向——必要になったときに道具を能動的に探し出す——のやり方は、MCP-Zero をはじめ複数の独立したグループが競って作っており5、単発のアイデアではなく一つの流れになっている。
実務で何を変えるか
エージェントに道具を持たせる側なら、勘所は絞れる。
- 「全部見せる」を既定にしない。 使える道具を無条件に全部プロンプトへ積むのは、選択精度と文脈の両方を削る31。質問ごとに、渡す道具を検索して絞るほうへ寄せる。
- 道具の数は動的に。 固定の上限より、問いに応じて見せる数を変えるほうが良い、という結果が出ている(同じ精度を約7個で)3。多ければ良いでも、少なければ良いでもない。
- 「道具を持っているか」でなく「正しく選べるか」を測る。 一覧に道具があることと、その場で選べることは別だ。評価は選択精度で見る。
- ただし検索も万能ではない。 絞っても精度は43%どまり——道具選びは依然として難しく、検索は取り違えという新しい失敗の面も足す2。「大きな文脈窓に全部入れれば済む」でも「検索を入れれば解決」でもなく、渡す道具を絞る設計が要る、という段階だ。
出典
-
MCP のツール定義がコンテキスト予算を食う問題の実務報告——GitHub・Slack・Sentry の3 MCP(約40道具)で20万トークン中14.3万がツール定義に、標準構成で約72%が着手前に埋まる、との集計。https://redis.io/blog/from-reasoning-to-retrieval-solving-the-mcp-tool-overload-problem/ ↩ ↩2 ↩3
-
“RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation”(arXiv:2505.03275)。意味的検索で関連する道具だけを渡し、選択精度を13.62%→43.13%、プロンプトトークンを50%超削減。https://arxiv.org/abs/2505.03275 ↩ ↩2 ↩3
-
Vyzantinos Repantis, Ameya Gawde, Harshvardhan Singh, Joey Blackwell II, “How Many Tools Should an LLM Agent See? A Chance-Corrected Answer”(arXiv:2605.24660, 2026-05-23)。20〜3,251個の登録で検証。多すぎる一覧は選択を混乱させ、動的サイズが固定を上回る(同精度を平均約7個提示で・ToolBench 難問で5個に絞ると16.7% vs 固定0%)。Bits-over-Random(偶然当たりを補正した指標)を提案。https://arxiv.org/abs/2605.24660 ↩ ↩2 ↩3 ↩4
-
Chroma の「Context Rot」研究。18のモデル(GPT-4.1・Claude Sonnet 4・Gemini 2.5 Flash・Qwen3-32B ほか)で、入力が長くなるほど単純な課題でも一貫して性能が落ちることを報告。https://research.trychroma.com/context-rot ↩
-
必要時に道具を能動的に探す方向の独立した試みの例——MCP-Zero(arXiv:2506.01056, Active Tool Discovery)ほか、Toolshed/ScaleMCP/LiveMCPBench など、大規模ツール環境での検索・絞り込みを扱う研究群。https://arxiv.org/abs/2506.01056 ↩
この記事はAIが下書きし、人間が編集・公開しています。