100 ツール型エージェントは罠か ソハイル・シャイク氏ら指摘

100 ツール型エージェントは罠か？「肥満型」設計の致命的な欠陥と解決策

AI エージェントの開発において、「使えるツールをすべて一度にプロンプトに含める」というアプローチが、小規模なデモでは機能しても、大規模システムでは致命的な誤りであることが明らかになりました。ソハイブ・シャイク氏らによる分析によると、ツール数が数百に増えると精度は劇的に低下し、コストと遅延も膨れ上がります。本記事では、なぜこの「肥満型」設計が失敗するのか、そして「RAG for Tools」と呼ばれる新しいアーキテクチャでどう解決できるのかを解説します。

「100 ツール罠」の正体：コンテキストオーバーロードによる崩壊

多くの開発者が陥る典型的な設計パターンがあります。データベース照会、メール送信、カレンダー確認など、システムが持つすべての機能（ツール）の定義を、ユーザーのクエリごとにモデルに渡す方法です。ソハイブ氏はこれを「肥満型エージェント（Fat Agent）」と呼びます。

小規模な環境では、例えば 10 個程度のツールであれば、このアプローチでも問題なく動作し、約 78% の確率で正しいツールを選択できます。しかし、システムが成長しツール数が数百に達すると、状況は一変します。

「モデルは長いコンテキストの先頭と末尾により強く注意を向けます。数百ものツールスキーマが中間に詰め込まれると、モデルはそれらを確実に使用できません。」

ツール数が増えるにつれ、モデルは類似する機能を混同したり、存在しない架空のツール名を生成し始めたりします。

• 10 ツール時: 精度約 78%
• 100 ツール時: 精度約 40%（半数以上が誤り）
• 741 ツール時: 精度13.6%（正解は 8 つに 1 つのみ）

これは特定のツール定義が悪いからではなく、すべてのリクエストでカタログ全体を強制的に読み込ませる設計そのものが、モデルの判断能力を麻痺させているためです。

セマンティックルーティング：精度 83% を維持する「RAG for Tools」

この問題を解決するのがセマンティックルーティング（Semantic Routing）、つまりツールに対する RAG（検索拡張生成）アプローチです。これは、ユーザーのクエリに基づいてベクトル検索を行い、関連性の高い数個のツールのみを動的に取得・注入する仕組みです。

実験結果では、この手法を採用した場合、ツールカタログが 741 個あっても精度は83%を維持し続けることが示されました。モデルは常に「数百の中から選ぶ」のではなく、「関連する 3〜5 個から選ぶ」という状態に保たれるためです。

「ルーターはまずユーザーのクエリを確認します。そして最も関連性の高い 3〜5 つのツールを取得し、それらだけをモデル呼び出しに注入します。」

このアプローチには明確なメリットがあります。

1. 精度の安定: カタログサイズに関わらず、焦点を絞ったリストから選択するため誤りが激減する。
2. コスト削減: 不要なツール定義を排除し、トークン使用量を約99% 削減（741 ツール環境で 127,000 トークン→約 1,000 トークン）。
3. レイテンシの改善: プロンプトサイズが小さくなるため、ファーストトークンの生成までの時間を短縮し、リアルタイム応答性を確保します。

実装パターン：オフライン索引化とランタイム選抜

セマンティックルーティングの実装は、既存の RAG インフラを活用すれば比較的スムーズです。以下の 3 ステップで構成されます。

1. オフラインでのインデックス構築

まず、ツールカタログを作成します。各ツールには明確な名前、説明、JSON スキーマが必要です。次に、これらの「説明」を埋め込みモデル（Embedding Model）に通し、ベクトルデータベース（Chroma DB, Pinecone, Qdrant など）に保存します。

2. ランタイムでのクエリ処理

ユーザーが質問を投げると、システムは同じ埋め込みモデルでそのクエリを変換します。その後、ベクトルインデックスを検索し、説明がクエリに最も近い上位 K 個（推奨：K=5）のツールを特定します。

3. コンテキスト注入と実行

検索結果として得られた「関連する数個のツール」のみをプロンプトに追加し、LLM に呼び出させます。これにより、モデルは巨大なカタログではなく、文脈に即した短いリストから最適な関数を選択します。

「これは新しいソフトウェアのアイデアではありません。遅延読み込みやジャストインタイムコンパイルの原則を、LLM のコンテキスト管理に応用しているだけです。」

実装時の注意点とチェックリスト

このアーキテクチャは万能ではありませんが、適切に設計すれば大規模システムでも信頼性を担保できます。

• K（取得数）の調整: K=3 は高速・低コストですが、K=5 が強力なデフォルトです。K を大きくするとエッジケースを回収しやすくなりますが、トークン数とレイテンシが増加します。テストセットで精度目標を満たす最小の K を選定してください。
• 説明の質: ルーターの精度はツール説明の質に依存します。「ユーザーが実際に使う言葉」で記述し、意図やアクションを明確に含める必要があります。
• フォールバック戦略: ルーターが誤って必要なツールを見逃した場合に備え、モデルがタスクを完了できない場合は K を広げる再検索パスや、全ツールリストへのフォールバックを用意してください。

結論：小規模なら「肥満型」でも OK、大規模は必ずルーティングへ

ソハイブ氏らの分析は、AI エージェント開発における重要な転換点を示しています。ツール数が 20 個未満のシステムでは、静的にすべての定義を読み込む「肥満型」アプローチでも十分機能します。しかし、50 個を超え、特に 100 ツールを超える大規模環境では、この設計は破綻します。

「エージェントにツールを追加すると失敗し始めたら、必ずしもプロンプトが悪いわけではありません。それは、アーキテクチャがモデルに間違った問題を解決させようとしている可能性を示しているだけです。」

開発者は「ツール追加＝性能向上」という誤った前提を捨て、動的なセマンティックルーティングを採用することで、スケーラブルで信頼性の高い AI 製品を実現できるはずです。すでに RAG インフラを持つチームなら、今日からでもこのパターンへの移行が可能です。