AIがツールを呼んでくれない・別のツールを選ぶときの原因の切り分け方

症状から原因をたどる判断表

まず次の表で、症状に近い行から確認します。上の行ほど先に疑います。

• 1、症状：ツールの存在に触れず、自力で答える、疑う場所：接続・登録、最初の確認：ツール一覧に出ているか
• 2、症状：一覧にはあるが、呼ばずに回答する、疑う場所：指示・設定、最初の確認：依頼文とtool_choice等の設定
• 3、症状：呼ぶが、いつも別のツールになる、疑う場所：説明の重なり、最初の確認：2つの説明を並べて違いを比較
• 4、症状：状況で呼んだり呼ばなかったりする、疑う場所：ツール数、最初の確認：今回の依頼に不要なツールが混ざっていないか
• 5、症状：呼ぶが、引数が欠ける・形式違いでエラー、疑う場所：引数の定義、最初の確認：スキーマの必須項目・型・例

手順0: ツールが見えているかを確認する

説明をどれだけ直しても、AIに定義が渡っていなければ呼ばれません。

MCPでは、クライアントがサーバーへtools/listを送ってツール一覧を取得する流れです。サーバーがlistChangedを宣言している場合は、一覧が変わった時に通知が飛びます（MCP仕様 Tools（2025-06-18版））。確認ポイントは次のとおりです。

• 使っているアプリのツール／MCP一覧画面に、対象ツールが表示されているか
• 追加や編集の直後なら、再接続や再起動をしたか
• 同じ画面で、ツールが無効（オフ）になっていないか

また同仕様は、安全のためツール呼び出しの前に人が拒否できる仕組み（確認画面など）を置くことを勧めています。確認が出ている画面で拒否や無視をすると、「呼ばれなかった」ように見えることがあります。承認の履歴や通知も見てください。

指示と設定を疑う（呼ばずに答えるとき）

一覧に出ているのに呼ばれないなら、次に指示を見ます。

AnthropicのAPIでは、tool_choiceの初期値はautoで、ツールを使うかどうかはモデルが判断します。anyは「どれかを必ず使う」、toolは「指定ツールを使う」、noneは使わせない設定です。ツールの定義を渡さなければnone扱いになります（Anthropic: Define tools）。

注意点があります。モデルや拡張思考の設定によっては、選べるtool_choiceに制限があります。また強制すると、通常は付く前置きの文章が省かれる場合があります。強制は「原因の切り分け用」に短く使い、常用は避けるのが無難です。

OpenAIのドキュメントも、システムプロンプトで各関数を「いつ使うか／使わないか」を書くことを勧めています。またallowed_toolsで、その場面で使えるツールを絞れます（OpenAI: Function calling）。

試す依頼文（説明用の例）

次の依頼は、必ず「顧客検索」ツールで調べてから回答してください。
ツールを使わずに推測で答えないでください。
ツールが使えない場合は、使えない理由を先に書いてください。

依頼: 東京都在住で、先月に購入履歴のある顧客を3件挙げて

これで呼ばれるようになれば、原因は指示側です。システムプロンプトに「顧客に関する質問では、まず顧客検索を使う」と恒久的に書きます。それでも呼ばれなければ、説明か接続に戻ります。

説明文とツール数を疑う（別のツールを選ぶとき）

AIはツールの名前・説明・引数の説明を材料に選びます。Anthropicは、ツール性能で最も重要な要素は説明の詳しさだとし、次を含めるよう勧めています。

• ツールが何をするか
• いつ使うか、いつ使わないか
• 各引数の意味と影響
• 返さない情報など、制限事項

目安は1ツールにつき3〜4文以上です（Anthropic: Define tools）。

説明の直し方（説明用の例）

役割が近い2つのツールを想定します。

修正前
search_docs : 文書を検索する
search_wiki : 社内情報を検索する

修正後
search_docs : 契約書・見積書などのPDFを全文検索する。
  「契約」「見積」「請求」に関する質問で使う。
  社内の手順や用語の質問には使わない。更新日時は返さない。
search_wiki : 社内Wikiの手順・用語・FAQを検索する。
  契約書や見積書などの個別文書には使わない。

違いが「対象」「使う場面」「使わない場面」として書かれていれば、AIは迷いにくくなります。

数と重なりの整理

ツールが多い、または似たものが並ぶと選択が曖昧になります。公式資料に沿った対処は次のとおりです。

• 関連する操作を1つにまとめ、action引数で分ける（Anthropic）
• 名前にサービス名を付ける（例: github_list_prs、slack_send_message）（Anthropic）
• 最初に渡すツールを少なくする。OpenAIはツール数が増えた場合に、関連するツールだけを渡す方法やツール検索を紹介しています

実務では、複数のMCPサーバーを一度につなぐと数が増えます。その依頼に要らないサーバーを一時的に切って挙動が変わるなら、原因は数と重なりです。

引数の定義を疑う（呼ぶが失敗するとき）

ツールは選ばれても、引数が欠ける・型が違うことがあります。MCPでは、未知のツールや不正な引数は通信上のエラー、API失敗や入力値の不備はツール結果のisError: trueとして返す、と分けています（MCP仕様 Tools）。どちらのエラーかを、ログで先に見分けます。

エラーが引数に絡むなら、次を点検します。

1. 必須項目（required）が本当に必須か。任意なのに必須扱いになっていないか
2. 各引数に説明があるか。形式が決まっているなら、説明に具体例（例: 2026-10-27形式）を書く
3. 選択肢が決まっている値はenumにする
4. 複雑な入力はinput_examplesで有効な入力例を付ける（Anthropic。例はスキーマに合っていないと400エラーで、トークンも少し増える）

あわせて、エラー時にサーバーが返す文面を「何が足りないか」まで分かるものにすると、AIが再試行で直しやすくなります。これは編集上の提案です。

修正の優先順位

どこから直すか迷ったら、手間が小さく、効果の切り分けがしやすい順に進めます。

1. 見えているか確認（一覧、再接続、承認の履歴）
2. 依頼文に一時的に明記して、呼ばれるか試す
3. 説明に「使う場面／使わない場面」を足す
4. 不要なツールを切る、またはツール名に接頭辞を付ける
5. 引数の説明・enum・例を足す
6. 最後に、tool_choiceの強制やstrictなどの設定を検討する

AIに点検を任せる依頼文

ツール定義をAIに見せて、改善案を出してもらうこともできます。ただし最終的な適用と動作確認は人が行います。

以下は私のツール定義(JSON)です。次の観点で点検し、表で答えてください。
1) 説明に「何をするか／使う場面／使わない場面」があるか
2) 他のツールと説明が重なっていないか(重なるペアを列挙)
3) 引数の説明・型・必須指定・enumに不足がないか
最後に、修正案を優先度の高い順に3つだけ提示してください。
※ APIキーや社内の固有名は含めていません。

(ここに定義を貼る)

定義にはAPIキー、社内URL、顧客名を含めないでください。含まれる場合は、ダミーの値に置き換えてから貼ります。

修正後は、確認用の依頼を3〜5個用意し、「呼ばれるべき依頼」と「呼ばれてはいけない依頼」の両方で試します。呼ばれてはいけない依頼も混ぜないと、説明を強めすぎて誤って呼ばれる副作用に気づけません。