LLM（大規模言語モデル）にツール呼び出し機能を持たせたエージェントを本番運用しているエンジニアに向けて、ツール数の増加が引き起こすコスト問題を整理します。ツールを増やすたびに何が起きているか、意外と見落とされがちなので確認していきます。
エージェントに複数のツール（関数呼び出しの候補）を渡す場合、各ツールのJSONスキーマ（名前・説明文・パラメータ定義をまとめたデータ構造）がまるごとリクエストに含まれます。モデルはそのターンで実際に使うツールを1つだけ選びますが、使わなかった残り全部の定義も律儀に読み込んでいます。
さらに厄介なのは、この処理が会話のターンごとに繰り返される点です。多くのLLM APIはステートレス（前回のやり取りを覚えていない設計）なので、次のターンでもツール一覧を丸ごと再送信する必要があります。ツールが8個程度なら誤差ですが、200個規模になると請求書の主役が会話内容ではなくツール定義になります。
判断が必要になる場面
MCP（Model Context Protocol、AIとツール・データソースをつなぐ標準規格）を使って複数のサーバーからツールをかき集めている構成では、この問題が起きやすくなります。異なるチームや異なる時期に作られたMCPサーバーを束ねると、get_customer・get_customer_profile・fetch_customer_recordのような、機能が重複した名前違いのツールが自然と増えていきます。
こうなるとモデルにとっての負担はトークン量だけではありません。似た名前のツールが並ぶメニューから1つを選ばせる作業自体が、選択精度を落とす原因になります。モデルが賢くなくなったわけではなく、渡された選択肢そのものが曖昧なのです。
判断軸
ツール総数が最初の軸です。目安として30個を超えたあたりから、ツール一覧を毎回フルで送るコストが無視できなくなります。逆に数十個未満なら、後述する検索方式を導入しても割に合わないケースが目立ちます。
呼び出し頻度の偏りも見るべき軸です。実際の運用では、ごく一部のツールが呼び出しの大半を占めることが珍しくありません。よく使うツールと滅多に呼ばれないツールが混在しているなら、両者を同じ扱いにする必要はありません。
タスクの分岐パターンも判断材料になります。1つのエージェントが多様なタスクを横断的にこなすのか、それとも特定ドメインに閉じた作業を繰り返すのかで、適した構成が変わってきます。
運用コストも軽視できません。ルーティングルールやサブエージェント分割は、ツールが追加・変更されるたびに人手でメンテナンスが必要になります。仕組みを作った時点では良くても、半年後にルールが陳腐化していないかは別問題です。
選択肢の比較
| 方式 | ターンあたりのトークンコスト | 大規模時の選択精度 | 運用コスト |
|---|---|---|---|
| フラットなツール一覧 | ツール数に比例して増加 | 50個を超えると急落しやすい | ほぼゼロ |
| タスク種別で手動分割 | 分割内では低い | ルーティングが正しければ良好 | 高い（ルールが陳腐化する） |
| ドメイン別マルチエージェント | サブエージェント内では低い | ドメイン内は良好、横断は苦手 | 高い（引き継ぎ処理が必要） |
| ツール検索方式 | カタログ規模によらずほぼ一定 | 検索精度に依存 | 低い（インデックスは自動管理） |
表にある「ツール検索方式」は、Microsoft FoundryがBuild 2026で発表したTool Search機能が代表例です。全ツールのスキーマを毎回送る代わりに、tool_searchとcall_toolという2つのメタツールだけをモデルに渡します。エージェントは「やりたいこと」を自然文で説明し、候補を絞り込んでから実際のツールを呼び出す仕組みです。
この方式は検索のための往復（1回分のレイテンシ増加）と引き換えに、カタログをまるごと送る必要をなくします。30個を超えるあたりからこの取引は割に合いやすくなりますが、それ未満だと検索のオーバーヘッドの方が目立つ場合があります。
見落とされがちなのが、検索方式と固定呼び出し（ピン留め）の併用です。Foundryでは頻繁に使うツールを検索の対象から外し、常に一覧に残す設定ができます。実運用では一部のツールが呼び出しの大半を占めるため、よく使うものを固定しつつ残りだけ検索対象にすれば、フラットなコストのままレイテンシの悪化を避けられます。
ケース別の推奨
ツール数が30個未満で、かつ各ツールの役割が明確に分かれているなら、フラットなツール一覧のままで問題ありません。検索方式を入れても、往復のレイテンシが増えるだけでメリットが乏しいケースです。
ツール数が50個を超え、かつ呼び出し頻度に明確な偏りがあるなら、検索方式とピン留めの併用が有力な選択肢になります。よく呼ばれるツールを固定し、残りを検索対象にする設計です。
ドメインごとにタスクがはっきり分かれていて、ドメイン間の行き来がほとんど発生しないなら、マルチエージェント分割も検討に値します。ただしサブエージェント間の引き継ぎ処理は、思ったより複雑になりがちです。
MCPサーバーを複数チームが独立に追加していく運用なら、まずget_customerのような重複ツールが実際にどれだけ存在するか棚卸しするところから始めるのが現実的です。ツールカタログの整理なしに検索方式だけ導入しても、曖昧なメニューが小さくなるだけで根本解決にはなりません。
あえて見送るべき条件
ツール数が数十個に満たない小規模なエージェントに、検索方式を導入する必要はありません。往復のレイテンシと実装コストが、削減できるトークン量に見合わないためです。
タスクごとの呼び出しパターンがほぼ均一で、特定のツールへの偏りがない場合も、ピン留めの効果は限定的です。この場合は検索方式単体の導入で十分と考えられます。
ルーティングルールやドメイン分割をすでに運用していて、それが安定して機能しているなら、無理に検索方式へ移行する必要はありません。動いている仕組みを壊すコストの方が高くつくことがあります。
確認すべきこと
まず自分のエージェントが抱えるツール数を数えてください。次に、直近のログから呼び出し頻度の分布を確認し、上位数個のツールが呼び出しの何割を占めるか見てみるのが出発点です。
MCP経由でツールを集約している場合は、名前や説明文が似ているツールが重複していないか棚卸ししてください。Foundryのサンプルではazd ai agent initでエージェントを雛形から作成し、azd ai toolbox createでツールボックスをMCPエンドポイントとして公開する流れが用意されています。手元の構成がこの規模の問題に該当するかどうか、まずはツール数とログの偏りから判断するのが確実です。