7月6日、Machine Learning MasteryのコントリビューターであるShittu Olumideが「The Complete Guide to Tool Selection in AI Agents」と題した記事を公開した。AIエージェントのツールカタログが肥大化するにつれてツール選択精度が劣化する問題と、それを解決する6つの実践的手法について詳しく紹介されている。
ツールを増やすほどエージェントは壊れる
5つのツールで完璧に動いていたエージェントが、3ヶ月後には40個のファイル操作、CRMアクセス、Slack、カレンダー、3つの検索APIを抱えて誤動作する——この展開はどのエージェントにも起きうる「デフォルトの軌道」だと記事は指摘する。
問題の根本は単純だ。ツール定義（名前・説明・パラメータスキーマ）はリクエストのたびに全件モデルに送られる。ツールが50個を超えると、ユーザーのメッセージが届く前にコンテキストの5〜7%が消費される。さらに「lost in the middle」効果——コンテキストウィンドウの中央部分は注意が向きにくいという現象——により、正解のツールがちょうどその死角に埋もれてしまう。
最悪のケースがツールハルシネーションだ。類似したツール定義が大量に並ぶと、LLMは存在しないツール名を生成したり、正しいツールを呼び出しながら別ツールのスキーマからパラメータを借用したりする。存在しない関数を呼ぶのは「少し間違っている」ではなく「完全な失敗」である。
OpenAIはエージェントあたり128ツールという上限を設けているが、実際には15〜20ツールを超えたあたりから精度の劣化が顕著になると、本番環境を運用するチームの多くが報告している。
最も効果が実証されている手法：検索ベースのツール選択
記事が「最も強力な実証データがある」と位置づけるのが、ベクトル検索によるツール選択だ。
全ツール定義をベクトルストアにインデックスし、受信クエリを埋め込みベクトルに変換して上位K件だけをモデルに渡す。2025年5月に公開されたRAG-MCPペーパーがこの手法の基準実装として参照されており、その数値が顕著だ。なお、RAG-MCPの「MCP」はAnthropicが提唱するModel Context Protocolを指し、AIモデルと外部ツール・データソースを接続するための標準プロトコルだ。RAGの概念をMCPベースのツール選択に適用した研究として注目されている。
- ツール選択精度：**13.62% → 43.13%**（3倍以上）
- プロンプトトークン数：50%以上削減
記事ではFAISSとsentence-transformersを使った実装例が示されている。FAISSはMetaが開発・公開しているオープンソースのベクトル類似検索ライブラリで、大規模な埋め込みベクトルの高速インデックス・検索に広く使われている。ツール説明をスタートアップ時に一度エンコードしてインデックスに格納し、推論時はクエリをエンコードして上位3件を取得するだけだ。
# retriever.py
# pip install sentence-transformers faiss-cpu numpy
from sentence_transformers import SentenceTransformer
import faiss, numpy as np
class ToolRetriever:
def __init__(self, tools, model_name="all-MiniLM-L6-v2"):
self.tools = tools
self.model = SentenceTransformer(model_name)
descriptions = [f"{t['name']}: {t['description']}" for t in tools]
embeddings = self.model.encode(descriptions, normalize_embeddings=True)
self.index = faiss.IndexFlatIP(embeddings.shape[1])
self.index.add(np.array(embeddings, dtype=np.float32))
def retrieve(self, query, top_k=3):
query_emb = self.model.encode([query], normalize_embeddings=True)
scores, indices = self.index.search(np.array(query_emb, dtype=np.float32), top_k)
return [{**self.tools[idx], "score": float(score)}
for score, idx in zip(scores[0], indices[0])]
その前に：ゲーティングで無駄な処理を省く
検索より先に「そもそもツールが必要か」を判定するゲートを設けるべきだというのが記事の提案だ。「ありがとう」「どういう意味ですか」といった会話的なターンに対して、毎回検索とツール選択推論を走らせるのはコストの無駄だ。
実装は正規表現＋アクションキーワードの照合だけでよく、外部依存なしで動く。
def gate(query: str) -> dict:
q_lower = query.strip().lower()
for pattern in CONVERSATIONAL_PATTERNS:
if re.match(pattern, q_lower):
return {"tool_needed": False, "reason": "conversational_pattern"}
has_action_keyword = any(kw in q_lower for kw in ACTION_KEYWORDS)
if not has_action_keyword and len(q_lower.split()) < 5:
return {"tool_needed": False, "reason": "short_with_no_action_keyword"}
return {"tool_needed": True, "reason": "action_keyword_or_long_query"}
会話的ターンが20〜30%を占めるだけで、ゲーティングはレイテンシとトークンコストの両面で元が取れると記事は述べている。依存ライブラリが不要なため、既存のエージェント実装にほぼノーコストで追加できる点も実用上の利点だ。
残り4手法の概要
記事ではさらに4つの手法が解説されている。
ルーティング：クエリをドメインカテゴリ（ファイル操作、コミュニケーション、外部APIなど）に分類し、そのカテゴリに属するツール群だけを候補にする。検索と組み合わせることで精度をさらに高められる。ツール群が複数の明確なドメインに分割できる場合に特に有効だ。
プランニング：複数ステップのタスクで、次に必要なツールを逐次判断するのではなく、タスク開始前に実行計画を立てて必要なツールセットを確定させる。途中で不要なツールを呼ぶリスクを減らし、マルチステップタスク全体の一貫性を高める。
フォールバックロジック：ツール呼び出しが失敗したとき（存在しない関数、不正なパラメータ等）に、再試行・代替ツール選択・ユーザーへの確認といった回復経路を設ける。ハードエラーでエージェントが止まることを防ぎ、本番環境での安定稼働に直結する。
ベンチマークハーネス：上記どの手法が効いているかを計測するための評価基盤。ツール選択精度（正しいツールを選べたか）、パラメータ正確性、トークン消費量を追跡し、手法の効果を数値で確認できるようにする。「計測なしの改善は改善ではない」というのが記事の立場だ。新しい手法を導入したあとに精度が意図せず退行していないかを継続的に検知する仕組みとしても機能する。
実装の優先順位
記事が提示するデプロイ順序は以下のとおりだ：
- ゲーティング（最も安価、依存なし）
- 検索ベース選択（精度改善の主力）
- ルーティング（ドメインが明確な場合に有効）
- プランニング（マルチステップタスク向け）
- フォールバックロジック（本番安定性のために必須）
- ベンチマーク（継続的に計測して退行を検知）
モデルを大きくする必要はない。モデルが見るものを制御するだけで、ツール選択の問題の大半は解決できるというのが記事の主張だ。ツールカタログの肥大化に悩むチームにとって、まずゲーティングと検索ベース選択の2手法を試すだけでも、コストと精度の両面で即効性のある改善が期待できる。
詳細はThe Complete Guide to Tool Selection in AI Agentsを参照していただきたい。
