ツール呼び出しでモデルを選ぶ——ベンチより失敗モード

目次▼

1. 1結論を先に
2. 2まず用語の地図
3. 3引数崩壊——「動いているように見えて壊れている」
4. 4幻覚ツール——「存在しない道具を呼ぶ」
5. 5再試行耐性——「失敗から学べるか」
6. 6具体例：ツール呼び出しの失敗モードでモデルを選ぶ
7. 7よくある偏り
8. 8いまの一手

ツール呼び出し（Function Calling）の実装を決めていなくても、「どのモデルが本番に耐えるか」を判断する軸として読める。

---

この記事の使い方

項目	内容
決めること	ツール呼び出し品質でモデルを絞り込む評価軸
決めないこと	特定モデルの優劣ランキング（バージョンで変わるため）
前提	JSON スキーマでツール定義を渡す構成を想定。ファインチューニングなし

---

結論を先に

失敗モード	発生しやすい状況	選定で見るべき指標
引数崩壊	スキーマが複雑・ネストが深い	型一致率・必須フィールド欠落率
幻覚ツール	ツール数が多い・名前が似ている	未定義ツール呼び出し率
再試行耐性の低さ	エラー返却後に同じ誤りを繰り返す	エラーフィードバック後の修正成功率

ベンチマーク（Berkeley BFCL など）は「正常系の正解率」を測る。本番で痛いのは上記3つの異常系であり、ベンチスコアとは相関しない場合がある。

---

まず用語の地図

用語	かみ砕いた意味
ツール呼び出し（Function Calling）	モデルが「この関数をこの引数で実行してほしい」と構造化テキストで指示する仕組み
引数崩壊	モデルが返す JSON の型・キー・値が定義したスキーマと食い違う現象
幻覚ツール	定義していないツール名をモデルが勝手に生成して呼び出そうとする現象
再試行耐性	ツール実行側がエラーを返したとき、モデルが次の呼び出しで正しく修正できる能力
スキーマ（JSON Schema）	ツールの引数の型・必須項目・説明を記述した設計図。モデルへのプロンプトに埋め込まれる
パラレル呼び出し	1ターンで複数ツールを同時に呼び出す機能。対応モデルとそうでないモデルがある

---

引数崩壊——「動いているように見えて壊れている」

なぜ起きるか

スキーマをプロンプトに埋め込む以上、モデルはスキーマを「読んで理解する」のではなく「文脈から補完する」。ネストが深くなるほど、あるいは enum や anyOf が増えるほど、補完の精度が落ちる。

典型的な崩壊パターンは3種類ある。

パターン	例	影響
型ズレ	integer を期待する箇所に "42"（文字列）が入る	バリデーション例外・サイレントバグ
必須フィールド欠落	user_id が省略される	下流 API が 400 を返す
余剰フィールド混入	定義にない debug_mode: true が付く	厳格なバリデーターで拒否される

評価の手順

1. スキーマを段階的に複雑化して正答率の折れ線を引く（フラット→1段ネスト→2段ネスト→anyOf）
2. 必須フィールド欠落率を必ず別集計する（全体正答率に隠れやすい）
3. additionalProperties: false を明示したスキーマで余剰フィールド混入を検出する

チェックリスト

• ネスト2段以上のスキーマで型一致率を計測したか
• 必須フィールド欠落を全体正答率と分けて集計したか
• additionalProperties: false で余剰フィールドを検出したか

---

幻覚ツール——「存在しない道具を呼ぶ」

なぜ起きるか

ツール定義が増えると、モデルはツール名を「記憶から補完」し始める。特に名前が意味的に近いツール群（search_user / find_user / lookup_user）が並ぶと、定義外の名前を生成するリスクが上がる。

幻覚ツールはエラーにならない場合がある。呼び出し側が「知らないツール名は無視する」実装だと、モデルは何かを実行したつもりで、実際には何も起きていない。これが最も発見しにくい失敗モードだ。

評価の手順

条件	測定値
ツール数 5 以下	幻覚ツール呼び出し率（ベースライン）
ツール数 10〜20	同上（増加率を見る）
意味的に近い名前を混在	同上（名前衝突耐性）

「幻覚ツール呼び出し率」は (定義外ツール名の呼び出し回数) / (全ツール呼び出し回数) で計算する。

チェックリスト

• ツール数を 5→10→20 と増やして幻覚率の変化を記録したか
• 呼び出し側が未定義ツールをログに残す実装になっているか
• ツール名の命名規則を統一して衝突を減らしたか（モデル選定と並行して）

---

再試行耐性——「失敗から学べるか」

なぜ重要か

本番では「ツール実行が必ず成功する」前提は成り立たない。API レート制限・バリデーションエラー・権限不足など、エラーは日常的に発生する。そのエラーメッセージをモデルに返したとき、次の呼び出しで修正できるかが再試行耐性だ。

再試行耐性が低いモデルは2つの壊れ方をする。

壊れ方	症状
同じ誤りの繰り返し	エラーメッセージを無視して同一引数で再呼び出し
過剰な謝罪ループ	エラーを受け取るとツール呼び出しをやめてユーザーに謝り始める

評価の手順

エラーフィードバックシナリオを3種類用意して計測する。

シナリオ	エラー内容	期待する修正
型エラー	"expected integer, got string"	引数の型を修正して再呼び出し
権限エラー	"permission denied for tool X"	別のツールに切り替える
部分成功	ツールAは成功、ツールBは失敗	ツールBのみ再試行

指標は「エラー返却後 N ターン以内の修正成功率」。N=1（1回で直せるか）と N=3（3回以内に直せるか）を分けて記録する。

チェックリスト

• エラーメッセージを構造化して返しているか（モデルが解析しやすい形式）
• 「同じ引数での再呼び出し」を検出してループを打ち切る実装があるか
• 修正成功率を N=1 と N=3 で分けて計測したか

---

具体例：ツール呼び出しの失敗モードでモデルを選ぶ

ベンチの総合点より、次の四つの壊れ方を先に見る。

1. 引数崩壊 — 必須フィールド欠落、型違い、単位の取り違え。
2. 幻覚ツール — カタログにない名前を呼び、再試行で同じ誤りを繰り返す。
3. 再試行耐性 — 一時失敗のあと、同じ冪等キーで回復できるか。
4. 権限逸脱 — 読んでよい範囲を超えて書き込みや外部送信に進む。

失敗	観測	ゲート
引数崩壊	スキーマ検証エラー率	本番投入前にフィクスチャで落とす
幻覚ツール	未知ツール名の出現	カタログ外は即拒否＋人間レビュー
再試行破綻	二重副作用／欠損	冪等キーとデッドレターを必須にする
権限逸脱	スコープ外リソースへの到達	最小権限ロールで落とす
沈黙失敗	成功扱いの空応答	必須フィールドの存在チェック

評価の最小セット

ゴールデンフィクスチャを10件用意し、うち3件は故意に壊した引数、2件はカタログ外ツール名を混ぜる。週次では総合ベンチを更新するより、このセットの回帰を先に見る。モデル入れ替えの判定文は「引数崩壊率がX%を超えたらロールバック」と数値で残す。

選定メモの型

• 使うモデル名（差し替え前提で書く）
• 許可ツール一覧と拒否時の人間レビュー先
• 引数崩壊率／未知ツール率の閾値
• 失敗をデッドレターに送る条件

モデル選定の一文テンプレ: 「ツール呼び出しでは、総合ベンチより引数崩壊率と未知ツール率で切る。今週の縦スライスは、カタログ外呼び出しをゼロにし、失敗をデッドレターに送るところまで」。ベンチより失敗モード

現場では「賢いモデル」より「拒否が観測できるモデル」を先に試す。拒否がログに残らない構成は、ベンチが良くても運用に渡せない。

よくある偏り

「ベンチスコアが高いから選んだ」

Berkeley BFCL をはじめとするベンチマークは正常系の網羅性を測る設計が多い。引数崩壊・幻覚ツール・再試行耐性は異常系の評価であり、ベンチスコアとの相関は低い。スコアを参考にするのは構わないが、それだけで選ぶのは危険だ。

「最新モデルなら大丈夫」

モデルのバージョンアップはツール呼び出し品質を改善することもあれば、回帰させることもある。特に再試行耐性は微妙な挙動変化が出やすい。本番採用後も定期的に評価セットを回す仕組みが必要だ。

「プロンプトで補えばいい」

スキーマの説明文を詳細にすることで引数崩壊は減らせる。ただし、それはモデルの弱点をプロンプトで隠しているにすぎない。トークン消費が増え、他の指示との干渉リスクも上がる。モデル選定とプロンプト設計は別の問題として扱う。

「エラーは呼び出し側で吸収すればいい」

呼び出し側でエラーを握りつぶすと、幻覚ツールや引数崩壊が発見されないまま蓄積する。ログに残して定期集計する仕組みがないと、問題の深刻度を過小評価し続ける。

---

いまの一手

本気で評価を始める人へ

1. 評価セットを自前で作る。正常系10件・引数崩壊誘発5件・幻覚ツール誘発5件・再試行シナリオ3件の計23件から始める
2. 計測を自動化する。モデルのレスポンスをパースして型一致率・欠落率・幻覚率を数値で出す
3. モデルを2〜3本並走させる。同じ評価セットで比較し、失敗モードの分布を見る
4. 本番後も月次で回す。モデルのバージョンアップを検知する仕組みとセットで

まだ様子見の人へ

• 自分のユースケースで「ツール数はいくつになるか」「スキーマのネスト深さはどの程度か」を先に整理しておく
• 幻覚ツールを検出するログ設計だけ先に入れておく（実装コストが低く、後で必ず役立つ）
• 再試行ループの打ち切り条件（最大試行回数・同一引数検出）をアーキテクチャ設計に含めておく

---

モデルの選定基準をさらに広げたい場合は、コスト・レイテンシ・コンテキスト長との兼ね合いも論点になる。その視点はシリーズ全体でカバーしている。

→ モデル動向シリーズ一覧｜kakoGENZAI

なお、ツール呼び出しを使ったエージェント構成を事業として評価する視点は、ventures シリーズでも取り上げている。「どのモデルを選ぶか」と「どの構成で事業リスクを取るか」は別の問いだが、判断のタイミングは重なることが多い。