AIエージェントはモデル選びが重要だった。RTX 5070 Ti 16GBで7つのローカルLLMに同じ実務をさせて比較

前回の記事では、RTX 5070 Ti 16GBのPCでローカルAIエージェントを動かし、ファイル操作やWeb検索、記事作成などを実際に試しました。

AIエージェントって結局何ができる？ RTX 5070 Ti 16GBでローカル実行して分かったこと

そこで次に気になったのが、

「AIエージェントに使うモデルを変えると、実際の仕事の結果はどれくらい変わるのか？」

という点です。

普通のチャットで少し質問するだけなら、どのモデルもそれなりに答えてくれます。

ところがAIエージェントとして使う場合は、それだけではありません。

• ファイルを読む
• 大量の情報から必要なものを判断する
• 決められた形式で出力する
• ツールを正しく呼び出す
• 余計な処理をしない
• 指示を最後まで守る

といった能力が必要になります。

今回は7種類のローカルLLMに、Google Search Consoleの実データを使ったまったく同じブログ分析作業をさせて比較しました。

結論から書くと、かなり大きな差が出ました。

そして「一番大きなモデルを使えばいい」という単純な話でもありませんでした。

今回やらせた仕事

今回AIエージェントにやらせたのは、Google Search Consoleのデータを見て、既存記事をどう扱うべきか判断する作業です。

対象には、実際に私のブログで公開している記事のSearch Consoleデータを使用しました。

処理の流れは大まかに次のようになっています。

1. Google Search Console APIからデータ取得
2. Pythonで数値を機械的に整理
3. 整理済みJSONをAIエージェントが読む
4. 検索クエリを検索意図ごとに分類
5. 記事を変更するか、様子を見るか判断
6. 必要なら改善候補を出す
7. 決められたJSON形式で保存
8. PythonのValidatorで出力を検証

つまり単純な「この数字を見て感想を言ってください」というテストではありません。

実際のブログ運営で自動化したい処理に近い形にしました。

なぜ数値計算をAIにやらせなかったのか

今回、Search Consoleのクリック数や表示回数、CTRなどの計算自体はAIに任せていません。

そこはPythonで処理しています。

たとえば、

• クリック数
• 表示回数
• CTR
• 掲載順位
• 取得できた検索クエリの割合

といったものは普通のプログラムで計算した方が、速くて正確です。

AIに任せたのは、

「これらの検索クエリは同じ意図なのか」

「この記事は今すぐ直すべきなのか、それともまだ様子を見るべきなのか」

といった、単純な数式では決めにくい部分です。

これは後になってかなり重要なポイントだと感じました。

テスト環境

項目	環境
OS	Windows 11
GPU	GeForce RTX 5070 Ti 16GB
CPU	Core i7-12700K
メモリ	48GB
推論	llama.cpp
AIエージェント	Hermes Agent
Context	65,536

モデルごとに量子化方式や最適な設定が異なるため、すべての実行条件を完全に同一にはしていません。

あくまで、

「RTX 5070 Ti 16GBでそのモデルを実際に使うなら、この設定で使う」

という実用寄りの比較です。

一方で、AIエージェントへ渡す実際のユーザープロンプト、入力データ、出力先、Validator、採点方法は固定しました。

比較した7モデル

今回の主要比較に使用したのは次の7モデルです。

• Qwen3.8-27B
• Gemma 4 12B
• Qwen3-14B
• gpt-oss-20B
• Ministral-3-14B
• LiquidAI LFM2.5-2.6B
• IBM Granite 4.2 8B

モデルサイズは2.6Bから27Bまでかなり幅があります。

採点方法

今回は100点満点の独自スコアを作りました。

評価項目	配点
JSON構造・ルール遵守	20点
記事をどう扱うかの判断	20点
検索意図の分類	40点
監視対象の選定	20点

重要なのは、JSONが壊れていたり、存在しないIDを出力した場合です。

この場合は採点以前の問題なので、Validatorで失敗として扱いました。

また各モデルは基本的に4回実行しています。

生成AIは同じPromptでも毎回答えが変わる可能性があるため、1回だけ良い結果が出ても実用性があるとは判断しません。

結果

モデル	Validator PASS	有効Run平均	平均時間
Qwen3.8-27B	3 / 4	69.62	約146秒
LFM2.5-2.6B Q8	3 / 4	59.60	49.67秒
Gemma 4 12B	4 / 4	53.99	30.84秒
Qwen3-14B	4 / 4	53.24	39.48秒
gpt-oss-20B	2 / 4	50.20	72.55秒
Ministral-3-14B	4 / 4	39.24	163.79秒
Granite 4.2 8B	0 / 4	―	―

※これは今回作成したGoogle Search Console分析タスクに対する結果です。

モデルそのものの総合性能をランキングしたものではありません。

Qwen3.8-27B：一番精度が高かったが重い

今回もっとも高い結果を出したのはQwen3.8-27Bでした。

有効Runの平均は69.62点。

検索クエリを意味ごとに分類する能力も、今回のモデル群では明確に上でした。

一方で平均処理時間は約146秒。

毎日のように大量の記事を処理させるには少し重いです。

そのため現在の印象は、

「全部の記事を処理するモデル」ではなく、「本当に判断が必要な記事だけ渡すモデル」

です。

Gemma 4 12B：今回の実務用途では一番使いやすい

Gemma 4 12Bは最高得点ではありません。

平均53.99点です。

しかし4回すべてValidatorを通過し、平均時間は30.84秒でした。

今回比較したモデルの中では、速度と安定性のバランスがかなり良いです。

日常的なブログ監視を毎日実行するなら、今のところGemma 4 12Bを第一候補にしたいと思います。

AIエージェントでは、一度だけ高得点を出す能力よりも、

「毎回きちんと仕事を終わらせる」

ことが重要になります。

LFM2.5-2.6B：2.6Bとは思えない結果

今回かなり驚いたのがLiquidAIのLFM2.5-2.6Bです。

モデルサイズはわずか2.6B。

今回は品質低下をできるだけ避けるためQ8_0を使用しました。

RTX 5070 Ti上では、64K Contextで起動してもGPUメモリ使用量は約4.5GBでした。

それにもかかわらず、3/4回でValidatorを通過し、有効Run平均は59.60点。

Gemma 4 12Bより高い平均点になりました。

ただし1回は、

q001 or mg001

という存在しない複合IDを生成してValidatorに拒否されています。

したがって完全に安心して任せられるわけではありません。

それでも、2.6Bというサイズを考えると非常に興味深い結果です。

Qwen3-14B：悪くはないが立ち位置が難しい

Qwen3-14Bは4/4回Validatorを通過し、平均53.24点でした。

数字だけを見ると十分使えます。

しかしGemma 4 12Bが53.99点、30.84秒だったのに対して、Qwen3-14Bは53.24点、39.48秒。

少なくとも今回の用途では、Gemmaより大きなモデルを使うメリットを感じにくい結果になりました。

「小型モデルより賢く、大型モデルより軽い中間モデル」として期待していましたが、今回のタスクではその立ち位置にはなりませんでした。

gpt-oss-20B：速さはあるが構造化出力が不安定

gpt-oss-20Bは2/4回しかValidatorを通過できませんでした。

有効Run平均は50.20点です。

問題になったのは、モデルの知識そのものというより、厳密な出力ルールです。

schema_versionを文字列にしたり、存在しない参照IDを使ったりするRunが発生しました。

普通のチャットで多少表現を間違える程度なら問題ありません。

しかし、後ろにプログラム処理が続くAIエージェントでは、こうした小さなフォーマット違反がそのまま処理失敗になります。

Ministral-3-14B：今回の用途では厳しかった

Ministral-3-14Bは4/4回Validator自体は通過しています。

しかし平均39.24点で、処理時間は約164秒。

Qwen3.8-27Bよりモデルは小さいのに、今回の環境・設定では処理時間もかなり長くなりました。

以前の別テストではファイル整理などを比較的高速にこなした場面もあったため、モデルそのものが悪いわけではありません。

今回のような日本語の意味分類と慎重なSEO判断には向いていなかった、という結果だと考えています。

Granite 4.2 8B：今回もっとも興味深かった失敗

IBM Granite 4.2 8Bは、ある意味今回もっとも面白いモデルでした。

最初に簡単な動作確認をしたところ、

• 東京は日本の首都か
• フランスの首都
• 2+2
• 水の化学式
• 日本の通貨

という5問をテストしました。

さらに、

• Non-thinking
• Low-effort thinking
• Full thinking

の3モードで試しました。

結果は15問すべて正解。

Hermes Agentからファイルを読み、JSONを書き、もう一度読み直すツール操作も正常に成功しました。

ここだけを見ると、かなり使えそうに見えます。

ところがGSCタスクでは、4回中1回もValidatorを通過できませんでした。

特に何度も繰り返したのが、出力Schemaに例として書かれていた、

"q001 or mg001"

という表現の誤解です。

本来これは、

「q001のようなquery_id、またはmg001のようなmerged_group_idを使う」

という意味です。

しかしGraniteは、

"q001 or mg001"

全体を1つのIDだと解釈しました。

しかも自分の推論の中で、

「この形式に合わせるべきだ」

と誤解を強化しながら同じ出力を何度も生成しました。

別のRunでは入力ファイルだけでなく、ValidatorやPromptまで次々と検索し、最大iterationを使い切って最終JSONそのものを作れませんでした。

最終結果は、

0 / 4 PASS。

これはかなり重要な結果だと思います。

簡単な質問に答えられる＝AIエージェントとして使える、ではない

Graniteの結果から特に感じたのがこれです。

普通にチャットして、

「東京は日本の首都ですか？」

と質問すれば正解します。

ファイル操作もできます。

それでも、複数の制約がある実作業では失敗する。

つまり、

「普通に会話すると賢く見えるモデル」と「AIエージェントとして安定して仕事を任せられるモデル」は必ずしも同じではありません。

今回の比較で一番強く感じた部分です。

モデルサイズだけでは結果を予測できなかった

今回の結果をパラメータ数だけで並べても、ほとんど意味がありません。

2.6BのLFMが59.60点。

12BのGemmaが53.99点。

14BのQwen3が53.24点。

20Bのgpt-ossは2/4回しかValidatorを通過できず、8BのGraniteは0/4。

一方27BのQwen3.8は最も高精度でした。

大きいモデルほど賢くなる傾向そのものを否定するつもりはありません。

しかしAIエージェントの実作業では、それ以外の能力がかなり影響します。

• 指示遵守
• Tool Calling
• 構造化出力
• 日本語理解
• 検索意図の分類
• 余計な行動をしないこと
• 再現性

こうした能力の組み合わせによって結果が大きく変わりました。

「一番良いモデル」を探すより、仕事ごとに選ぶ方がよさそう

今回の検証を始めた当初は、

「ローカルAIエージェントに使うなら、どのモデルが一番良いのか？」

を知りたいと思っていました。

しかし今は少し考え方が変わっています。

一番良いモデルを1つ決める必要はないのではないか。

という考えです。

今回の結果だけなら、たとえば次のように使い分けられます。

用途	候補
毎日の高速な一次判定	Gemma 4 12B
VRAMを節約した軽量処理	LFM2.5-2.6B
重要なSEO判断・意味分析	Qwen3.8-27B

たとえば100記事を毎日確認するとします。

いきなり100記事すべてを27Bモデルへ渡す必要はありません。

まず普通のPythonプログラムで、数値的に変化のあった10記事だけを抽出。

その10記事をGemmaで一次判定。

その中から本当に判断が必要な2記事だけをQwen3.8-27Bへ渡す。

こうした構成の方が現実的です。

そもそも全部をAIにやらせる必要もない

今回Google Search Consoleの分析を作っていて、もう一つ考えが変わりました。

AIエージェントだからといって、すべての処理をAIにやらせる必要はありません。

むしろ、数値処理や明確なルールで決められる部分は普通のプログラムに任せた方が良いです。

今後作ろうとしているSearch Consoleの定期分析では、次のような構成を考えています。

Search Console API

↓

Pythonでデータ取得・集計・異常検出

↓

必要な記事だけローカルLLMへ渡す

↓

検索意図や修正方針など、曖昧な部分だけAIが判断

↓

人間が最終確認

この方が、AIだけですべて処理するよりも安定するはずです。

Validatorはかなり重要だった

今回の実験では、AIが出力したJSONをPythonで必ず検証しました。

これを入れていなければ、GraniteやLFM、gpt-ossの一部の失敗を、

「それっぽいJSONが出ているから成功」

と判断していた可能性があります。

AIエージェントを自動運転するなら、

AI自身に「ちゃんとできました」と判断させるだけでは不十分

だと思います。

普通のプログラムで検証できる部分は、必ず外側から確認する。

これは今後も使いたい設計です。

今回の結論

今回7つのローカルLLMを同じ実務タスクで比較して、モデルによって想像以上に結果が違うことが分かりました。

特に印象に残ったのは、

• 27BのQwen3.8は精度が高いが遅い
• Gemma 4 12Bは高速で安定している
• 2.6BのLFMが予想以上に強い
• モデルサイズと実務性能は単純には比例しない
• 簡単な質問に答えられても、エージェント業務では失敗することがある
• 構造化出力には外部Validatorが重要

という点です。

そして一番重要だと感じたのは、

「どのAIモデルが一番賢いか」ではなく、「何をさせるのかを先に決めて、その仕事に合うモデルを選ぶ」

ことです。

ローカルAIエージェントを使うなら、一つの巨大モデルですべてを処理するより、役割ごとにモデルを使い分ける方が面白いかもしれません。

次は今回の結果を実際のブログ運営へつなげて、

Google Search Consoleを定期的に取得・分析し、必要な記事だけAIに判断させる仕組み

を作ってみようと思います。

AIに全部任せるのではなく、普通のプログラムとAIをどう分担させるのが良いのか。

次はそこを実際に試してみます。