70B級の巨大モデルを動かしても、ツールを1回も呼べなければエージェントとしては役に立ちません。
この記事では、ローカルAIエージェント向けモデルの選び方を、Dockerの実測評価と各モデルのスコアをもとに整理します。
この記事でわかること
- パラメータ数とツール呼び出し性能が一致しない理由
- Dockerが21モデル・3,570テストで測った主要スコア
- 2026年時点で実務に使えるモデルの目安
- 量子化がツール呼び出しに与える影響
パラメータ数はエージェント性能の指標にならない
ローカルLLM（大規模言語モデルを自分のPCで動かす方式）を選ぶとき、VRAMに収まる最大パラメータ数を基準にする人は多いです。しかしエージェント用途では、この判断は外れやすくなっています。
エージェントとは、LLMが外部ツール（API呼び出し、ファイル操作、Web検索など）を使ってタスクを実行する仕組みです。ツール呼び出し（function calling）とは、モデルが「どの関数を、どんな引数で実行するか」を構造化データとして出力する能力を指します。会話が上手いモデルでも、ここが弱ければエージェントは動きません。
Dockerは2025年6月、ショッピングカートAPIを題材にした実務寄りの評価を公開しました（参考）。21モデルに対し3,570テストを実施し、最大5ラウンドのエージェントループでツール選択のF1スコアを計測しています。
結果は明快です。GPT-4が0.974で最上位、ローカルモデルのQwen3 14B（Q4_K_M量子化）が0.971とほぼ同点です。一方、Llama 3.3 70Bは0.607にとどまり、パラメータ数が20倍以上少ないLlama 3.2 3B（0.727）より低いスコアでした。
| モデル | ツール選択F1 |
|---|---|
| GPT-4 | 0.974 |
| Qwen3 14B（Q4_K_M） | 0.971 |
| Qwen3 8B（F16） | 0.933 |
| Llama 3.1 8B | 0.835 |
| Gemma3 4B | 0.733 |
| Llama 3.2 3B | 0.727 |
| Llama 3.3 70B | 0.607 |
パラメータ数はツール呼び出しの信頼性をほとんど予測できません。MMLUやHumanEvalのような汎用ベンチマークの高スコアも、エージェントの実用性を保証しません。
ツール呼び出しがエージェントの生命線になる理由
推論力とツール呼び出しは別物です。論理パズルや長文要約に強いモデルでも、関数呼び出しが不安定ならエージェントとしては機能しません。逆に、推論はそこそこでもツールを確実に呼べるモデルは、データ取得やコマンド実行など実務タスクをこなせます。
Dockerの評価では、ツール呼び出し専用と謳われたxLAM 8B（0.570）やWatt 8B（0.484）も低スコアでした。汎用モデルのQwen3 8B（0.933）の方がはるかに安定しています。「ツール呼び出し対応」と書かれているだけでは不十分で、実際のエージェントループでの挙動を確認する必要があります。
同じモデルでもタスクの複雑さで結果が変わります。Llama 3.2 3BはDockerのショッピングカートテストでは0.727を記録した一方、より複雑なReActエージェント設定では9回の試行すべてでツール呼び出しがゼロだった、という独立検証も報告されています（参考)。ベンチマークの設計次第で評価が大きく変わる点は、選定時に自分のワークフローで試す理由になります。
規模別に見るおすすめモデル
中規模GPU向け：Qwenファミリー
https://github.com/QwenLM/Qwen3
Dockerの評価でもQwen3 14Bと8Bがローカルモデルのトップでした。14Bは精度重視、8Bはレイテンシを半分近く抑えつつF1 0.933を維持するバランス型です。単一GPUで実用ラインを狙うなら、Qwen3.5 9BあたりがVRAMと性能の交点になりやすいです。
Qwen公式のBFCL V4結果でも、Qwen3.5 27Bが68.5%、9Bが66.1%と高水準を示します。4Bは50.3%、2Bは43.6%と落ち込み、汎用モデルでは7〜9B付近に能力の境目があることが示唆されています。
エッジ・スマホ向け：Gemma 4 E2B
https://huggingface.co/google/gemma-4-E2B
Googleは2026年4月、エッジ向けのGemma 4ファミリーを公開しました。E2Bは実効パラメータ2.3Bで、ネイティブの関数呼び出しに対応しています（参考）。一般用途モデルを縮小したものとは異なり、エージェント用途を前提に学習されています。量子化すれば約1.5GBのメモリで動かせ、スマートフォンやRaspberry Piでもツール呼び出しループを回せます。複雑な多段タスクではQwen3.6 27Bクラスには及びませんが、「小さいがツールを呼べる」という点で選択肢になります。
大規模モデルでも方針は同じ
Nvidia Nemotron 3 Super 120B、Mistral Devstral 2 123B、OpenAI gpt-oss-120bなど、2026年に登場する大規模オープンモデルもエージェント・ツール利用を主要用途として打ち出しています。規模が変わっても「ツール呼び出しを学習目標に含めたモデルか」が選定基準です。
量子化はツール呼び出しを壊さない
ローカル運用ではGGUFなどの量子化が必須です。精度低下が構造化出力に効くのでは、という懸念はありますが、Dockerの検証ではQwen3 8BのF16（0.933）とQ4_K_M（0.919）の差はわずかでした。同じブログでも、テストした範囲では量子化による有意な性能差は見られなかったと報告されています。
ただし量子化の校正データにツール呼び出しが含まれない場合、スキーマ遵守が崩れる可能性は指摘されています。標準的なGGUF量子化で大きな問題は起きにくい一方、本番投入前に自分のツール定義で動作確認するのが確実です。
ローカルエージェントのモデル選定チェックリスト
Ollama、Docker Model Runner、llama.cpp、Open WebUIなどでローカルエージェントを組む場合、VRAMに収まる最大モデルではなく次の観点で選びます。
- ツール呼び出しの実測スコア — Dockerのmodel-testやBFCLなど、関数呼び出しを直接測るベンチマークを参照する
- 学習目的 — エージェント・コーディング向けに設計されたモデルか（Qwen3 Coder Next、Devstral 2など）
- 自分のタスクでの試行 — ショッピングカート程度の単純タスクと、複数ツールを連鎖する実タスクで挙動が変わる
- VRAMと速度のトレードオフ — Qwen3 14Bは高精度だが1インタラクション約142秒、8Bは約84秒（Docker計測値）
14Bで毎回正しい関数を呼べるモデルは、70Bで半分しか成功しないモデルより実務価値が高いです。ローカルAIエージェントの本質は「賢く語ること」ではなく「正しく動くこと」にあります。