似たツールを並べると、AIは意図と違う方を選ぶ

AIエージェントに業務機能をツールとして渡しておけば、依頼内容に応じて適切なツールを自分で選んで実行してくれる——これはAIエージェントの基本的な使い方であり、期待される動作でもあります。しかし、ツールの数や役割分担の設計を誤ると、AIは想定と違うツールを選んでしまうことがあります。

具体例で考える

たとえば、顧客データを管理する業務システムで、AIエージェントに次の2つのツールを渡したとします。

• 有効ステータスの顧客一覧を返すツール
• 検索条件を指定して顧客一覧を返すツール

この状態で「住所が東京都の、有効な顧客一覧を出して」とAIに依頼すると、AIが検索条件を指定できるツールではなく、有効ステータスの顧客一覧を返すツールを呼び出してしまう、という事象が起こり得ます。そのうえで、取得した一覧の中から東京都の顧客だけをAI自身がフィルタリングして回答する、という動きです。

結果として出てきた答えだけを見れば、一見正しく見えます。しかし裏側では、本来は検索条件付きのツールに任せるべき絞り込みを、AIが取得後のデータに対して力技で行っていることになります。

なぜ「動いているように見える」のが厄介なのか

こうした事象の厄介なところは、エラーにならず、見た目上は正しい答えが返ってくる点です。しかし実際には、望ましくない処理経路が使われています。

• 有効ステータスの顧客一覧を返すツールに、取得件数の上限やページネーションがあった場合、AIがフィルタリングする前にデータが切り捨てられ、本来該当するはずの顧客が結果から漏れる可能性があります
• 顧客数が多い業務では、AIが一覧を丸ごと受け取ってから絞り込む形になり、無駄なデータ量がAIとのやり取りに乗ることで、応答速度やコストに影響します
• 「なぜそのツールを選んだか」が業務ロジックとして保証されていないため、同じ依頼でも毎回同じツールが選ばれるとは限りません

テストの段階で結果だけを確認していると気づきにくく、内部でどのツールが呼ばれたかを見て初めて発覚する、という点も見落としやすい理由です。

なぜ起きるのか

原因は、2つのツールが意味的に重なっていたことにあります。どちらも「顧客一覧を返す」という点では共通しており、AIから見ると「有効な顧客」という条件だけでも、有効ステータスのツールで対応できそうに読めてしまいます。人間であれば「検索条件を指定できるツールがあるなら、そちらを使うべきだ」と自然に判断できますが、AIはツールの名前とdescriptionに書かれた文言だけを手がかりに選択します。役割の違いが人間にとって自明であっても、AIにとっては自明ではありません。

公式のガイドラインでも同様の指摘がある

この種の事象は特殊なケースではなく、AIエージェント向けツール設計の一般的な課題として、Anthropic社のエンジニアリングブログ「Writing effective tools for AI agents」でも明確に指摘されています。

同記事は、似た機能のツールが複数存在すると「agents can get confused about which ones to use（エージェントはどちらを使うべきか混乱する）」としたうえで、次のような対策を挙げています。

• ツールの統合: 例えば list_users list_events create_event のような細かいツールを別々に用意するより、目的に応じた schedule_event のような単一ツールに統合するほうが、選択の余地自体を減らせる
• ネームスペーシング: asana_search jira_search のように、関連するツールに共通のプレフィックスを付け、役割の境界を名前の時点で明確にする
• パラメータ名の具体化: user のような曖昧な名前ではなく user_id のように、何を渡すべきかが一目でわかる名前にする

「ツールは多く用意しておけば、AIが賢く選んでくれる」という考え方は誤りで、似た機能のツールが並ぶこと自体がAIにとってのノイズになる、というのが共通した結論です。

対処法とその効果の見え方

この例への対処としては、2つのツールを見直す方法が有効です。有効ステータスの一覧を返すツールを削除し、検索条件を指定できるツールに一本化したうえで、そのdescriptionを「ステータスや住所などの条件を指定して顧客を絞り込む場合は、必ずこのツールを使うこと」という形でより具体的に書き直します。

こうした対処によって、同じ依頼でも意図した通りのツールが選ばれやすくなります。ただし効果の出方は条件の複雑さに左右される点には注意が必要です。今回の例のように「有効ステータス」と「住所」という限られた組み合わせであれば、ツールの統合とdescriptionの修正だけで比較的効果が出やすい一方、条件の種類が多くツール同士の役割分担が複雑な業務では、同じ対処だけでは不十分なケースも考えられます。実際にAIがどのツールを選んでいるかをテストで確認しながら調整していく必要があります。

MCPで既存の業務システムをAI-native化する記事で紹介したように、AIから業務システムを操作できるようにする技術規格そのものは急速に整いつつあります。しかし、ツールを用意すればそれで終わりではなく、「AIが意図通りにツールを選べているか」を個別に検証する工程が欠かせません。

まとめ

AIエージェントに渡すツールは、数が多いほど柔軟に対応できるわけではありません。似た機能のツールが並んでいると、AIはその違いを人間ほど自明には判断できず、想定と違う経路でタスクをこなしてしまうことがあります。ツールはむやみに細かく分けず、役割が重ならないように統合・整理したうえで、実際にAIがどのツールを選んでいるかをテストで確認する——この地道な検証が、AIエージェントを業務システムに組み込むうえでの実用上の勘所になります。