コンテンツにスキップ

露出ツール数

このダイヤルは何か

露出ツール数は、エージェントが 1 回の LLM 呼び出し時に「使用可能なツール」として認識するツールの数を制御するパラメータです。LLM の function calling や tool use の仕組みでは、利用可能なツールの定義をシステムプロンプトに含めて渡します。この定義の数が、エージェントのツール選択精度・レイテンシ・コストに直接影響します。

AI エージェントシステムでは、MCP サーバの普及によりエージェントが接続可能なツールの総数が急速に増えています。データベース検索、ファイル操作、Web 検索、メール送信、カレンダー操作、コード実行、外部 API 呼び出し、管理系ツールなど、数十〜数百のツールが利用可能な環境は珍しくありません。しかし、これらをすべて同時に LLM に見せると、ツール選択の精度が急激に低下します。

このダイヤルの核心は「すべてのツールを常に見せる」のではなく、「タスクの文脈に応じて必要なツールだけを動的に露出する」という動的スコーピングの考え方にあります。これは C1 Tool Gateway / MCP Broker が提供するチョークポイントで実現します。

効かなすぎる害 ⇔ 効きすぎる害

露出ツール数が少なすぎる場合（効かなすぎ）

必要なツールを過度に制限すると、以下の問題が生じます。

  • タスク完了不能：エージェントが必要なツールにアクセスできず、ユーザーの要求を遂行できません。「メールを送って」と依頼されたのにメール送信ツールが露出されていなければ、エージェントは無力です。
  • 不自然な迂回：直接的なツールがないため、エージェントが非効率な代替手段を試みます。ファイル書込ツールがないのにコード実行ツールでファイルを生成しようとするなど、意図しない副作用を引き起こす可能性があります。
  • ツール選択のための再呼び出し：エージェントが「このツールが必要だがアクセスできない」と判断し、ツールの追加をリクエストするか、別のアプローチを模索するために追加のLLM呼び出しが発生します。結果的にレイテンシとコストが増加します。
  • ユーザー体験の低下：「これはできません」という応答が頻発し、エージェントの有用性に対する信頼が損なわれます。

露出ツール数が多すぎる場合（効きすぎ）

ツールを過剰に露出すると、以下の害が発生します。

  • ツール選択ミスの増加：LLM はツール定義の中から最も適切なものを選ぶ必要がありますが、選択肢が増えるほど精度が低下します。類似した名前や説明のツールがある場合（search_database と query_database）、間違ったツールを選択する確率が上がります。
  • 幻ツール呼び出し：多数のツール定義に「圧倒」された LLM が、定義にないツールを呼び出そうとすることがあります。これは完全に不正な呼び出しであり、エラーハンドリングが必要になります。
  • プロンプトの肥大化：各ツールの定義（名前、説明、パラメータスキーマ）はトークンを消費します。50 ツールの定義で概ね数千トークンになり、コンテキストウィンドウの有意な部分を占有します。これにより実際のタスク処理に使える枠が狭まります。
  • レイテンシの増加：入力トークン数の増加により、LLM の推論時間が増えます。ツール定義の解析と選択に計算リソースが消費されます。
  • セキュリティリスクの拡大：不必要なツール（管理系、削除系）が露出されていると、インジェクション攻撃や誤操作による意図しない副作用のリスクが高まります。最小権限の原則に反します。

決め方

露出ツール数の設定は [task_variability] と [input_trust] のバランスで決まります。

  • [task_variability]：タスクの種類が多様で、どのツールが必要になるか事前に予測しにくい場合は、露出数を多めにする必要があります。ただし上限は設けます。タスクが定型的で使うツールが予測可能な場合は、最小限に絞り込めます。
  • [input_trust]：入力の信頼度が低い場合、攻撃者がツール選択を操作するリスクがあるため、露出ツールを最小限にし、とくに副作用のあるツールの露出を制限します。
  • [failure_cost]：誤ったツール選択による失敗コストが高い場合、露出数を減らして選択精度を上げます。不可逆な操作を行うツール（送金、メール送信、データ削除）は、明確に必要な文脈でのみ露出します。
  • [cost_sensitivity]：ツール定義のトークン消費によるコスト増を気にする場合、動的スコーピングでコスト効率を上げます。

実践的な動的スコーピングの戦略は以下のとおりです。

  1. タスクの種類を分類する（情報検索、データ操作、コミュニケーション、管理等）
  2. 各カテゴリに必要なツールセットを定義する
  3. ユーザーの入力やタスクの文脈から適切なカテゴリを判定する
  4. 該当カテゴリのツールのみを露出する
  5. タスク進行中に別カテゴリのツールが必要になったら動的に追加する

目安値（出発点）

指標 目安 補足
同時露出ツール数の上限 10〜20 これを超えるとツール選択精度が目に見えて低下する
1 カテゴリあたりのツール数 3〜7 カテゴリ内での選択が容易な粒度
副作用ありツールの同時露出 3〜5 副作用なしツールより厳しく制限
ツール定義のトークン消費 概ね 2,000〜5,000 トークン コンテキストウィンドウの概ね 5〜10% 以下に収める

ツールの総数が 20 を超える場合は、動的スコーピングが必須です。30 を超える場合は、ルーティング層（ツールカテゴリを選ぶ第一段のLLM呼び出し → カテゴリ内のツールを使う第二段の呼び出し）の導入を検討します。

実践的なアドバイス

  • 動的スコーピングは「引き算」で考えてください。全ツールから不要なものを除外するのではなく、タスクに必要なツールだけを「足す」方式の方が安全です。デフォルトでは最小限のツール（読み取り系のみ）を露出し、タスクの文脈に応じて書込系・通信系を追加します。
  • ツール定義の説明文を明確にしてください。ツール数を制限するだけでなく、各ツールの description を曖昧さなく記述することが選択精度に大きく寄与します。「データを検索する」ではなく「PostgreSQL の customers テーブルから条件に一致する顧客レコードを検索する」のように具体的に書きます。
  • 類似ツールの統合を検討してください。search_by_name、search_by_id、search_by_date のように細分化されたツールは、1 つの search ツールにパラメータで分岐させる方が LLM の選択ミスを防げます。ただし、パラメータスキーマが複雑になりすぎると別の問題が生じるため、バランスが必要です。
  • ツールの使用頻度を計測し、スコーピングの最適化に活用してください。ほとんど使われないツールを常時露出しているなら、そのツールはオンデマンドでの追加に切り替えます。逆に、動的追加が頻発するツールは最初から露出した方が効率的です。
  • 段階的な権限昇格を設計してください。E1 Risk-Based Approval と連携し、最初は読み取り系ツールのみ、タスクの進行に応じて書込系ツールを追加、高リスク操作は人間承認後に一時的に露出する、という段階的なアプローチが安全です。

関連パターン