エージェント能力はチャット能力と別物【専用評価が要る理由】

「チャットで賢いモデルなら、エージェントにしても賢い」——これは誤りです。チャットの強さとエージェントの強さは別の能力軸で、しかも失敗の出方が違い、掛け算で効きます。だからモデル選びの基準そのものが変わり、専用のスコアカードが必要になります。この記事は、その理由を構造化して論証します。

本質的な違いは「ループを誰が回すか」

チャット（人間がループを回す）

1. 1. モデルが出力する
2. 2. 人間が読む・判断する
3. 3. 人間がツールを実行する
4. 4. 人間が結果を戻す → 1へ

制御・判断・誤り訂正・実行を毎ターン人間が担う＝人間がオーケストレータ。

エージェント（コードがループを回す）

1. 1. モデルがツールを選ぶ
2. 2. コードがツールを実行
3. 3. モデルが結果を観測する
4. 4. ゴールまで自分で反復 → 1へ（人間の介在なし）

人間は最初の指示と重要操作の承認だけ。モデルはループの“内側の意思決定主体”。

Anthropicの整理では、ワークフローは「LLMとツールを事前定義のコードパスで動かす系」、エージェントは「LLMが自らのプロセスとツール使用を動的に方向づけ、達成方法の制御を保持する系」です。より簡潔には**「LLMが自律的にツールをループで使うこと」**（根拠: Anthropic「Building Effective Agents」）。

• チャットで作業する＝実態は、人間がオーケストレータ。出力を読む・判断する・ツールを実行する・結果を戻す——を毎ターン人間が担う。
• エージェント＝この人間の役割をコード（足場）＋モデルで自動化する。モデルはループの内側の意思決定主体として、自分でツールを選び、結果を観測し、ゴールへ反復する。

「行動できるか（ツールを自律で使えるか）」が境界線です。

だから「どのモデルか」が別問題になる

チャットの強さ（知識テスト・対話の好まれ度）とエージェントの強さは相関が弱い。エージェントで効いてくるのは、チャット評価では測れない軸です。

• ツールコール／構造化出力の忠実度（正しいJSON・スキーマ遵守）。ツール使用の精度は、モデル規模（パラメータ数）より引数の正しさとスキーマ遵守に強く依存します（根拠: BFCL/関数呼び出し評価）。
• マルチターンの状態・文脈管理（観測が毎ステップ累積する）。
• 誤り回復（一度失敗して諦めず別手を試せるか）。
• 「行動しない」判断（不要なツール呼び出しの抑制）。

チャット評価で測る軸と、エージェントで効く軸は、ほとんど重なりません。

チャットのベンチで上位でも、エージェントで効く下4軸はそもそも測られていない——だから順位が入れ替わります。

信頼性は「掛け算」で効く

1ステップの成功率が95%でも、20ステップ連鎖すれば 0.95²⁰ ≈ 0.36 まで落ちます。実際は誤りに相関があり回復もあるので単純な p^N ではありませんが、ホライズン（手数）が長いほど1ステップの信頼性が結果を支配する傾向は変わりません（経験則・要検証）。

1ステップの成功率	1ステップ	5ステップ	10ステップ	20ステップ
99%	99%	95%	90%	82%
95%	95%	77%	60%	36%
90%	90%	59%	35%	12%
80%	80%	33%	11%	1%

例: 1ステップ95%でも20ステップ連鎖で36%。手数が長いほど1ステップの信頼性が結果を支配します。※実際は誤りに相関があり回復もあるので単純な p^N ではない（経験則・要検証）。

外部のベンチでもこれは顕著で、最先端の関数呼び出しエージェントですらタスク成功率は50%未満、しかも不安定で、同じタスクを8回連続成功できる率（pass^8）は小売ドメインで25%未満に落ちます（根拠: τ-bench（Sierra/arXiv））。

当サイトの実測でも「チャット≠エージェント」が出ている

これは外部の話だけではありません。当サイトが7モデルを実測したところ、単発のツール呼び出しは89〜100%でほぼ横並びなのに、前の結果を使う多ターン連鎖にすると56〜100%へ大きく開き、単発100%のモデルが連鎖では67%に急落しました。

単発（チャット的）の成績は、連鎖（エージェント的）を予測しない——これが一次データでの証拠です。さらに5〜6段の長い連鎖にすると差は決定的になり、単発満点・最速のLFM2.5 8Bは17%まで崩壊する一方、Gemma4 26Bは100%を維持しました（手数が増えるほど地力がむき出しになる＝まさに「掛け算」）。詳細はfunction calling＆連鎖の実測へ。

ローカルモデルだと、差はさらに開く

ここがローカルAI特有の論点で、専用スコアカードの存在理由そのものです。

• ツールコール対応の質のバラつきが大きい。チャットは流暢な小型モデルでも、エージェントループでは崩れやすい（経験則・要検証）。
• 量子化は「構造化出力の“形”」は壊さない（実測）。同じQwen2.5 7Bをfp16/Q8/Q4で各48試行測ると、壊れたJSON・ツール誤選択は全量子化で0件。落ちるのは僅かな判断（呼ぶ/呼ばない・引数）だけで、標準のQ4でも実用域でした。「動く（tok/s）」と「動いても賢いまま」は別問題ですが、少なくともツールの“形式”はQ4で保たれます。
• 文脈窓が狭いと観測の累積で破綻しやすい（経験則・要検証）。
• レイテンシ × ステップ数 ＝ 総実時間。Jetson／ラズパイ級では1ステップの遅延が全体を支配します（経験則・要検証）。
• 救いもあります。スキーマを明示し、バリデータで縛り、リトライを設計すれば、小型モデルでも関数呼び出しの信頼性を相当カバーできます（根拠: 小型モデルの関数呼び出しに関する研究・要検証）。

量子化	単発 正答	JSON崩れ bad_json	ツール誤 wrong_tool	引数誤 bad_args	未呼出 no_call	連鎖 成功
fp16（無圧縮）	100%	0	0	0	0	67%
Q8_0	94%	0	0	2	0	56%
Q4_K_M（標準）	90%	0	0	0	4	67%

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

つまりローカルで本当に効くのは「量子化でJSONが壊れること」ではなく、判断（いつ・どう呼ぶか）と連鎖の安定性です。だから、チャット評価とは別軸を測るエージェント・スコアカードが要る。ツール選択・軌跡・Nステップ再現性・誤り回復は、チャットのベンチではそもそも測定対象に入りません。

まとめ

• 本質的違いは**「ループを誰が回すか」**。チャットは人間、エージェントはコード＋モデル。
• エージェント能力は別の能力軸で、ツール忠実度・状態管理・回復・抑制が効き、信頼性は掛け算で結果を支配する。
• だからチャットの強さはエージェントの強さを予測しない。ローカルでは量子化・文脈・遅延でさらに差が開く。

「結局どのローカルモデルがエージェント向きか」を一次実測で総合評価したのがエージェント実用度スコアカード、作り方はローカルでAIエージェントを動かすにまとめています。こうした能力をどう測っているか（能力天井×デバイス実行性の2層）は測定プロトコルで公開しています。