AIエージェントが動くかは、「AIが正しい形式でツールを呼べるか（function calling）」にかかっています。引数を壊したJSONで返したり、必要な時にツールを呼ばなかったりすると、多段の自動化はそこで止まります。そこで、ローカルLLM7モデルに同じ6タスクを投げ、ツール呼び出しの正答率を自前で実測しました。

ベンチについて: この実測を日本語エージェント信頼性ベンチと呼びます。単発のツール呼び出し・前の結果を使う多ターン連鎖・量子化耐性を、日本語タスクで横断評価する当サイト独自のベンチマークです。評価軸・採点基準は「計測方法」、対象モデルと結果は本記事の実測結果（下表）の通りです。

結論

  • 現代のツール対応モデルは89〜100%で高信頼。「ローカルではエージェントは無理」は誤解。
  • 完璧（100%）: Qwen3.5 4B / Gemma4 26B / LFM2.5 8B（MoE）。
  • 小型（Qwen3.5 2B）は誤呼び出し（不要なのにツールを呼ぶ）が出やすい。
  • 旧世代（Gemma2 2B）はそもそもツール非対応——エージェント用途では真っ先に外れます。
  • ただし“連鎖”で本性が出る: 前の結果を使う多ターンのエージェントにすると成功率は56〜100%に開き、単発100%のモデルが67%に急落。単発の成績は連鎖を予測しません（後述・最重要）。
  • 長い連鎖（5〜6段）で地力がむき出し: ツール必須の5〜6段では100%(Gemma4)〜17%(LFM2.5が崩壊)に開く。サイズは無関係（2Bが8B MoEを圧倒）。
  • 10段超では“暴走ループ”も: Qwen2.5 7Bが10都市タスクで平均206回ツールを呼び続け終了不能に。本番ではコスト/レイテンシ爆発のリスク＝上限ガード必須。
  • 効くのは量子化より“モデル族”×言語: 壊れたJSONは3族（Qwen/Llama/Mistral）×日英で0件。だがLlama・Mistralは英語90〜100%なのに日本語50〜60%——日本語タスクはQwen系が明確に優勢でした。

実測結果

ツール呼び出しの正答率（代表6タスク×3回＝18試行・temp0.7・A6000実測）
  • Qwen3.5 4B100%
  • Gemma4 26B100%
  • LFM2.5 8B（MoE）100%
  • Qwen3.6 35B94%
  • Qwen2.5 7B94%
  • Qwen3.5 2B89%
  • Gemma2 2B（旧）非対応

現代のツール対応モデルは89〜100%で高信頼。小型のQwen3.5 2Bは「不要なのに呼ぶ」誤呼び出しが2回。Gemma2 2Bはそもそもツール非対応（ollamaが400で拒否）。18試行の実測＝小サンプル・要検証。

モデル正答率内訳（18試行中）
Qwen3.5 4B100%全問正解
Gemma4 26B100%全問正解
LFM2.5 8B（MoE）100%全問正解
Qwen3.6 35B94%1回だけツール未呼び出し
Qwen2.5 7B94%1回だけ引数ミス
Qwen3.5 2B89%2回 誤呼び出し（不要時に呼んだ）
Gemma2 2B（旧）非対応ollamaが400エラーで拒否

計測機: RTX A6000・ollama 0.30.7。ツール呼び出しの正否はモデル依存で、機種（速度）には依りません。生成速度の実測は検証DBへ。

計測方法

  • タスク: 代表6問。天気取得・足し算・Web検索・タイマー・メール送信の5問（ツールを呼ぶべき）＋、雑談1問（ツールを呼ぶべきでない）。
  • 試行: 各タスク3回＝18試行／モデル。温度 temperature=0.7（実際のエージェントに近い設定）。
  • API: ollama の /api/chat（tools対応）。返ってきた tool_calls を採点。
  • 採点（1試行ごと）: 正しいツール名＋妥当な引数なら「正解」。次は不正解として分類——未呼び出し／別ツール／引数ミス／壊れたJSON／誤呼び出し（不要時）。

「正しいJSONで呼べるか」だけでなく、「呼ぶべきでない時に呼ばない自制」も測っているのがポイントです。

所見

  • 賢さ＝ツール信頼性ではない: 最大の35B（Qwen3.6）より、4BのQwen3.5や8BのLFM2.5（MoE）の方が満点でした。ツール呼び出しは「モデルの躾（学習データ）」の差が出ます。
  • 小型は“過剰呼び出し”に注意: Qwen3.5 2Bは雑談にもツールを呼ぶ誤作動が出ました。エージェントでは「呼ばない判断」も同じくらい重要です。
  • 旧世代はそもそも非対応: Gemma2 2Bはツールを渡すとエラー。エージェントを作るなら、まず“ツール対応モデルか”を確認してください。

マルチターン連鎖の実測（ここで本当の差が出る）

単発のツール呼び出しは現代モデルがほぼ横並び（89〜100%）。でも本物のエージェントは、ツールの結果を見て次のツールを呼ぶ多ターンの連鎖です。そこで、前の結果を使う3つの連鎖タスクで実測しました。

  • 「東京と大阪の気温をそれぞれ調べて→2つを足す」（天気2回→足し算）
  • 「12と8を足して→その合計に3を掛ける」（前の結果を次の引数に使う）
  • 「検索して→その結果をメール送信」（検索→メールの順序）

ツールの結果をモデルに戻し、ゴールまで正しくやり切れたかを採点しました（3タスク×3回＝9試行・temp0.7・最大6ターン）。

① 単発（1回のツール呼び出し）の正答率
  • Gemma4 26B100%
  • Qwen3.6 35B94%
  • Qwen2.5 7B94%
  • Qwen3.5 4B100%
  • LFM2.5 8B100%
  • Qwen3.5 2B89%
② マルチターン連鎖（前の結果を使う本物のエージェント）の成功率
  • Gemma4 26B100%
  • Qwen3.6 35B89%
  • Qwen2.5 7B78%
  • Qwen3.5 4B67%
  • LFM2.5 8B67%
  • Qwen3.5 2B56%

単発はほぼ横並び（89〜100%）なのに、連鎖は56〜100%へ大きく開く。単発100%のQwen3.5 4B・LFM2.5 8Bが連鎖では67%に急落＝単発の成績は連鎖を予測しない。3連鎖タスク×3回＝9試行・要検証。

結果は単発と一変します。
モデル単発連鎖（多ターン）
Gemma4 26B100%100%
Qwen3.6 35B94%89%
Qwen2.5 7B94%78%
Qwen3.5 4B100%67%
LFM2.5 8B100%67%
Qwen3.5 2B89%56%

最大の発見: 単発100%でも連鎖は67%まで落ちます（Qwen3.5 4B・LFM2.5 8B）。一方 Gemma4 26Bは連鎖も100%で、エージェント総合力では頭一つ抜けました。単発の成績だけでモデルを選ぶと、エージェントにした途端に失敗する——これは一次実測でしか見えない落とし穴です。

連鎖が落ちる主因は「前の結果を次の引数に正しく使えない」「途中で止まる」。一般に大きめ・賢いモデルほど連鎖に強い傾向ですが、サイズだけでは決まりません（LFM2.5 8Bは単発満点でも連鎖は67%）。エージェントを本気で作るなら、連鎖で検証してからモデルを決めてください。

さらに長い連鎖（5〜6段）では、本格的に崩れる

2〜3段でこれなら、もっと長い連鎖は？ ツールを必ず使う5〜6段のタスク（例「東京・大阪・名古屋の気温を調べ→合計→2倍」「検索→気温2件→合算→メール」）で実測しました。採点はτ-bench流の最終状態基準です。

長連鎖（5〜6段・ツール必須タスク）の成功率（A6000実測・2タスク×3回＝6トライアル）
  • Gemma4 26B100%
  • Qwen3.5 4B83%
  • Qwen3.5 2B67%
  • Qwen2.5 7B50%
  • LFM2.5 8B17%

5〜6段でも成功する組み合わせは限られ、100%(Gemma4)〜17%(LFM2.5)に開く。サイズは無関係＝2BのQwen3.5(67%)が8BのLFM2.5(17%)を圧倒。最難は『検索→気温2件→合算→メール』の合成タスク。

手数が増えるほど崩れる典型 ― LFM2.5 8B
単発 100%短連鎖(2-3段) 67%長連鎖(5-6段) 17%

単発満点・最速のMoEが、手数が伸びるほど早期離脱（平均ツール呼出2.7回で停止）。「単発が速くて得意」は長いエージェントを予測しない典型例。

※ 純粋な算術5段タスクは指標から除外。強いモデル(Gemma4)はツールを使わず暗算で正答（ツール0回で「答えは210」）し、ツール連鎖の測定にならないため。エージェント評価はツールを使わざるを得ないタスクで測るべき、という方法論的教訓（測定プロトコル参照）。各9試行・要検証。

長くなるほど、モデルの地力がむき出しになります。 Gemma4 26Bは5〜6段でも100%を維持する一方、単発満点・最速のLFM2.5 8Bは17%まで崩壊（手数の途中で力尽きる）。しかもサイズは無関係——2BのQwen3.5が8BのLFM2.5を圧倒しました。最難は「検索→気温2件→合算→メール」のような種類の違うツールを跨ぐ合成タスクです。手数が増えるほど1ステップの信頼性が結果を支配する、という掛け算の効果が一次データで裏付けられました。

10段超では「暴走ループ」も出る

5〜6段で崩れるモデルがあるなら、その先は？ 10都市の気温を集めて合算する深い連鎖（10段超・ツールを使わざるを得ない設計）で実測しました。

深い連鎖（10段超・10都市の気温を集めて合算など・ツール必須）の成功率（A6000実測・2タスク×3回＝6トライアル）
  • Gemma4 26B83%
  • Qwen3.5 4B67%
  • Qwen3.5 2B67%
  • Qwen2.5 7B33%
  • LFM2.5 8B17%

10都市の気温を集めて合算する深い連鎖。Gemma4が最安定。10都市の収集と合算はGemma4・Qwen3.5 4B/2Bが3/3で完遂——ここでも2B/4Bが7B/8Bを上回り、サイズは無関係。

⚠ 暴走ループの実例 ― Qwen2.5 7B

10都市タスクで平均206回のツール呼び出し（上限20ターンの間、気温の再取得を延々と繰り返し終了できず）。同じQwenでも4B/2Bは8〜13回で正しく完遂したのに、7Bだけが暴走しました。

「ローカルは課金ゼロ」でも、暴走は時間と電力を浪費します。本番では無限ループ＝コスト/レイテンシ爆発のリスク。最大ステップ数の上限ガードと終了条件の設計が必須——長いほど起きやすく、モデル選びと同じくらい足場（コード側の制御）が効きます。

手数を5〜6段からさらに10段超へ伸ばすと、成功する組み合わせはより限られ、終了不能（暴走/途中離脱）が増える。各6トライアル・要検証。

ここで新しい失敗が出ました。Qwen2.5 7Bは10都市タスクで平均206回もツールを呼び続け、終了できず暴走（同じQwenの4B/2Bは8〜13回で正しく完遂）。「ローカルは課金ゼロ」でも暴走は時間と電力を浪費し、本番では無限ループ＝コスト爆発のリスクです。だから最大ステップ数の上限ガードなど、足場（コード側）の設計がモデル選びと同じくらい重要になります。

量子化はツール信頼性に効くか（同じ7Bで比較）

「Q4に圧縮するとツール呼び出しが壊れる」とよく言われます。本当か、同じ Qwen2.5 7B をfp16／Q8／Q4_K_Mで、単発を各48試行＋連鎖9試行ずつ実測しました（前回の18試行から増やし、失敗の“種類”まで見ています）。

量子化を強めても「構造化出力の“形”」は崩れない（Qwen2.5 7B・A6000実測）
量子化単発
正答		JSON崩れ
bad_json		ツール誤
wrong_tool		引数誤
bad_args		未呼出
no_call		連鎖
成功
fp16（無圧縮）100%000067%
Q8_094%002056%
Q4_K_M（標準）90%000467%

要点: 壊れたJSON・誤ったツール選択は全量子化で0件（単発144試行中0）。量子化で落ちるのは僅かな判断（呼ぶ/呼ばない・引数の正しさ）だけで、構造化出力の“形”はQ4でも保たれる。連鎖は67/56/67%で単調劣化は出ず（9試行＝小サンプル）。単発48試行/モデル・temp0.7・要検証（追試で確度を上げる）。

結論はやや意外で、ローカル利用者には朗報です。
  • 壊れたJSON・ツール誤選択は、全量子化で1件も出ませんでした（単発144試行中0件）。「Q4にすると構造化出力が壊れる」は、少なくともこのモデルでは起きませんでした。
  • 量子化で落ちるのは構造化出力の“形”ではなく“判断”——Q4は「呼ぶべき時に呼ばない（no_call）」が4件、Q8は「引数の値ミス（bad_args）」が2件。総合正答率は fp16 100%→Q8 94%→Q4 90% と小幅に下がる程度。
  • 連鎖（多ターン）は 67／56／67% で単調な劣化は出ず（9試行＝小サンプルでノイズ範囲）。

まとめると、標準のQ4_K_Mでもツールの“形式”は保たれ、実用域。メモリに余裕があれば高精度（fp16）が一段安定しますが、「Q4はエージェントに使えない」は誇張でした。ツール信頼性で本当に効くのは量子化よりモデルの素性（前述の連鎖性能）です（単発48・連鎖9試行／temp0.7／A6000実測）。

別のモデル族（Llama3.1）でも勾配は成立——ただし地力は別物

「Q4で落ちないのはQwenだけでは？」 別アーキの Llama3.1 8B でも fp16/Q8/Q4 で実測しました。

量子化↑で正答↑は「モデル族を問わず」成立。ただし“地力”の差は桁違い（A6000実測）
量子化Qwen2.5 7BLlama3.1 8B
Q4（標準）90%38%
Q894%46%
fp16（無圧縮）100%50%
共通の頑健性: 壊れたJSON・ツール誤選択は両族・全量子化で0件（10構成×48＝480試行中0）。量子化を強めても両族とも正答は単調にしか下がらず、構造化出力の“形”は壊れない。

だが地力は別物。Llama3.1 8Bは日本語の文字列引数を破損させ（実例: 検索query=「バータカストは帮を食し」、メール件名=「参數」(本来「会議」)、雑談で誤って都市=「本国市」を生成）、ASCIIの数値・メールアドレスは正しいのに日本語タスクのvalidが50%止まり。連鎖でも同じ単調勾配（Q4 0%→Q8 11%→fp16 33%）だがQwen2.5 7Bの78%には遠く及ばない。日本語エージェントではモデル族選びがQ4/fp16の選択より遥かに効く。経験則・要検証。

量子化↑で正答↑という勾配は、モデル族を問わず成立します（Llamaは単調に Q4 38%→fp16 50%）。そして壊れたJSONは両族・全量子化でゼロ。ただし地力（特に日本語の引数生成）はモデル族で桁違いでした。Llama3.1 8Bは日本語の検索クエリやメール件名を文字化けさせ（数値・メールアドレスは正確なのに）、日本語タスクの正答が50%止まり。日本語でエージェントを組むなら、量子化の前にまずモデル族（Qwen系が優勢）を選ぶ——これが実測の結論です。

その低さは「日本語」のせい——英語＋3族目で検証

「Llamaは本当にエージェントに弱いのか？」を切り分けるため、同じタスクを英語で、さらに3族目の Mistral 7Bを加えて測りました。

日本語 vs 英語のツール正答率（fp16・各48試行・A6000実測）――地力は英語、崩れるのは日本語
モデル族日本語英語日本語の失敗モード
Qwen2.5 7B100%100%なし（日英とも良好）
Mistral 7B60%96%no_call（日本語だと呼ばない）
Llama3.1 8B50%100%bad_args（日本語引数が文字化け）
要点: Llama3.1・Mistralは英語なら90〜100%なのに日本語で50〜60%へ急落。つまりツール呼び出しの地力はあるのに、日本語の処理で崩れる（壊れたJSONは3族×2言語×全量子化で0件＝形は常に正しい）。日本語での崩れ方は族で違い、Llamaは引数を文字化け（bad_args）、Mistralはそもそも呼ばない（no_call）。

結論: 日本語でエージェントを組むなら、量子化やサイズより先に「モデル族」を選ぶ——日本語タスクでは Qwen系が明確に優勢。英語中心なら Llama/Mistral も十分戦力。各48試行・temp0.7・要検証。

答えははっきりしました。Llama3.1もMistralも、英語なら90〜100%。日本語だけが50〜60%に落ちます——つまりツール呼び出しの地力は十分にあり、崩れるのは日本語の処理です。しかも崩れ方が族で違い、Llamaは日本語の引数を文字化け（bad_args）、Mistralはそもそも呼ばない（no_call）。一方 Qwen系は日本語でも100%。日本語エージェントのモデル選びは、量子化やサイズより「族」が決定的、というのが3族・2言語の実測結論です。

構造化出力は「モデルを問わず」壊れない（A6000・7構成336試行）

量子化だけでなく、モデルを横断しても同じ傾向が出るか。A6000常駐の主要モデルを各48試行（合計336）で、失敗の“種類”まで採点しました。

構造化出力は「モデル・量子化を問わず」壊れない（A6000・7構成×48＝336試行）
336単発試行（7構成）
0壊れたJSON（bad_json）
0ツール誤選択（wrong_tool）
モデル / 量子化正答呼忘れ
no_call		過剰呼出
false_pos		引数誤
bad_args
Gemma4 26B100%———
Qwen2.5 7B（fp16）100%———
LFM2.5 8B98%—1—
Qwen3.5 4B98%1——
Qwen2.5 7B（Q8）94%——2
Qwen2.5 7B（Q4）90%41—
Qwen3.5 2B85%—6—

失敗はすべて判断（JSONの形式崩れは0）。最小のQwen3.5 2Bは「不要なのに呼ぶ」過剰呼出が6件と突出、Gemma4 26Bは48/48で完璧。警戒すべきはJSON崩れより、小型モデルの過剰呼出・呼忘れ。各48試行・temp0.7・A6000実測・要検証。

  • 壊れたJSON・ツール誤選択は、7構成すべてで0件（336試行中0）。現代のツール対応モデルは、サイズ・量子化を問わず構造化出力の“形”は安定しています。
  • 失敗はすべて判断。最小のQwen3.5 2Bは「不要なのに呼ぶ」過剰呼び出しが6件と突出し、Gemma4 26Bは48/48で完璧でした。
  • 実装の示唆: ローカルエージェントで警戒すべきは「JSONが壊れる」ことより、小型モデルの過剰呼び出し・呼び忘れ（判断）と、前述の連鎖の安定性。JSONをバリデータで縛る以上に、ツール説明文の明確化と重要操作の承認ゲートで「呼ぶ／呼ばない」を制御する方が効きます。

エージェントを作るときの指針

  • まず「ツール対応モデル」を選ぶ（Qwen3.5/3.6・Gemma4・LFM2.5 などは良好）。手元で動くかは動くか診断で確認。
  • 小型モデルは“呼びすぎ”を検証してから本番へ。プロンプトやツール説明文で誘導を絞る。
  • MCPでツールを増やしても、上位モデルは30個まで壊れない——似た名前のトラップ入りでツール5/15/30個を比較した実測はMCPツール数スケーリング実測へ。劣化する場合も取り違えではなく「呼ばない」方向に出ました（旧世代のQwen2.5 7Bで顕著）。
  • 速度・電力・機材選びは機材の選び方、エージェントの全体像はローカルでAIエージェントを動かすへ。

新展開：エッジ向けFC特化モデル「FunctionGemma」

2026年、GoogleがFunctionGemmaを公開しました。Gemma 3 270Mをベースに、自然言語を構造化された関数・API呼び出しへ変換することに特化した超小型モデルです（出典：Google Developers Blog・モデル概要）。

  • 270Mで超軽量：スマホやJetson Nano級のエッジでの動作を想定した設計とされる。256k語彙でJSON・多言語を効率的にトークン化。
  • 本記事の結論と整合：「構造化出力の信頼性はモデルの素性で決まる」を、汎用の賢さではなく“呼び出しに特化”した設計で突き詰めた一例。
  • 自分用に育てる前提：そのまま使うより、妖怪QLoRAのケースのように自分のツール群へFTして“専用エージェント”の土台にする使い方（Hugging Face / Unsloth等で学習、llama.cpp / Ollama / vLLMで配信）。
  • ライセンスはGemma license（Apache-2.0ではない）＝商用は条件を要確認。

超小型ゆえ単体での長い連鎖は本記事の大型機ほど期待できませんが、「狭いタスクをエッジで確実にツール化」する用途では有力です。最適化の順序でいう「形式はFT」をエッジで実践する選択肢が増えつつあります。

精度等について

  • 試行は小サンプル（7モデル比較は単発18・連鎖9試行、量子化比較は単発48試行）。値は目安で、温度・プロンプト・量子化・ollamaのバージョンで変動します。
  • タスクは代表例。連鎖は10段超まで測定済ですが、現実のエージェントはネスト・並列ツール・20段超でさらに難しくなります（今後の課題）。なお純粋算術の連鎖は、強いモデルが暗算で解けてツール連鎖の測定にならないため指標から除外しました。
  • 量子化勾配は Qwen2.5 7B・Llama3.1 8B・Mistral 7B の3モデル族×日英で確認（壊れたJSONは全条件で0件）。Llama/Mistralの低スコアは日本語タスク特有（英語は90〜100%）で、"これらの族が弱い"と一般化はできません。より多くの族・言語での追検証が望まれます。

「ローカルでエージェントは動くのか？」——少なくともツールを正しく呼ぶ土台は、現代モデルなら十分に整っている、というのが実測の答えです。