Qwen3.5 vs Gemma 4｜ローカルLLMの「エージェント性能」を比較して見えた使い分けの勘所

海外のRedditコミュニティ（r/LocalLLaMA）で、ローカルLLMの新しい評価軸が注目を集めている。「エージェント性能」——つまり、AIが複数のステップを自律的にこなす能力の比較だ。従来のベンチマークはテキスト生成の精度や速度が中心だったが、実用シーンではもっと複雑なタスクを任せたい場面が増えてきた。今回話題になったのは、Qwen3.5-27BとGemma 4-31Bという2つのモデルを「エージェント的な仕事」で比較した検証。結果には明確な性格差が見えており、どちらを選ぶかは用途次第という結論になる。

ローカルLLMの「エージェント性能」とは何か

エージェント性能とは、LLMが単発の質問応答ではなく、複数のステップを自律的に計画・実行・検証・修正できる能力を指す。たとえば「サーバーの状態を確認して、結果をTelegramに通知する」というタスクを考えてみてほしい。人間がやるなら、環境変数の確認、APIの呼び出し、レスポンスの整形、メッセージ送信、送信結果の確認——と、少なくとも5つのステップを踏む。エージェント性能が高いモデルは、この一連の流れを指示1回で完遂できる。

従来のLLM評価では「質問に対してどれだけ正確な回答を返すか」が主な指標だった。MMLUやHumanEvalといったベンチマークがその代表例。しかし実際にローカルLLMを業務や自動化に使おうとすると、求められるのは「1回の正確な回答」ではなく「一連の作業を最後までやり切る力」になる。途中でエラーが出たときに自分で気づいて修正できるか。必要な情報を自分で取得しにいけるか。こうした能力がエージェント性能の核心部分。

r/LocalLLaMAでは、GLM 5.1というモデルが複雑なソーシャル推論ゲーム（Blood on the Clocktower）で高い自律性を示したという報告もあり、エージェント性能への注目度は急速に高まっている状況だ。企業のAIエージェント開発でも「6割が本番稼働」に達しているという調査結果があり、エージェント的な使い方はローカル・クラウドを問わずLLM活用の主流になりつつあると考える。

Qwen3.5-27B vs Gemma 4-31B——エージェント動作の比較結果

r/LocalLLaMAに投稿された検証では、Qwen3.5-27BとGemma 4-31Bの両モデルをQ5_K_XL量子化で動かし、エージェント的なタスクの遂行能力を比較している。検証条件はコンテキスト長150,000トークン、Flash Attention有効、推論モード（reasoning）オン。実際のタスクとしてTelegram通知の自動化が使われた。

両モデルの動作特性は、一言で「慎重型」と「直感型」に分かれる。以下の表はRedditでの検証報告をもとに整理したもの。

Qwen3.5——慎重な多段ステップ型

Qwen3.5-27Bの最大の特徴は、タスク完遂へのこだわりにあると筆者は見ている。検証報告によると、このモデルはまず環境変数を確認し、APIを呼び出し、失敗したら原因を分析して再試行するという流れを自発的に行う。最終的にTelegramメッセージが「完璧」だったという結果は、この自己修正ループが機能している証拠だろう。

ただし、この慎重さにはトレードオフがある。別のRedditユーザーの報告では、Qwen3.5は思考トークン（内部推論プロセスで消費するトークン）が10,000以上に膨れ上がることがあるという。コードのリファクタリングのような複雑なタスクでは特に顕著で、丁寧に背景情報を記述する傾向が強い。これは正確性を高める反面、推論時間とVRAM消費を押し上げる要因になる。

CPU環境（Haswell世代のi7、32GB DRAM）での実測では、Qwen3.5-27BのQ4_K_M量子化版の実行は非常に低速になるという報告もあった。GPU環境との速度差は歴然で、エージェント用途でCPUのみの実行は現実的ではないことがわかる。

Gemma 4——高速だが詰めに課題

Gemma 4-31Bは対照的なキャラクター。「4Bや9Bモデル並みに速い」という報告がr/LocalLLaMAの複数のスレッドで見られ、推論速度の面では明らかな優位性を持っている。URL特定のような情報検索タスクでは、Qwen3.5より少ないステップで目的の情報にたどり着く傾向がある。

問題は「最後の詰め」の部分。今回の検証ではTelegramメッセージが途中で切れてしまったという結果が出ている。速くて正確な初動判断を見せるものの、最終的な出力の完成度で取りこぼしが発生するケースがあるようだ。

さらに気になるのが、ロングコンテキストでの精度低下に関する指摘。r/LocalLLaMAのトップコメントでは「Gemma 4はロングコンテキストで明らかに崩れる場面がある。Qwen3.5にはそれがない」という趣旨の報告があった。コンテキスト長を150,000トークンに設定するようなエージェント的な使い方では、この差が決定的になる可能性がある。

一方で、単発のコーディングや短い文脈でのタスクでは「驚異的」という評価も寄せられている。この評価の割れ方を見ると、タスクの種類と文脈の長さによってGemma 4の実力は大きく変動すると考えるのが妥当だろう。なお、Googleが推奨する設定パラメータを適用すると「やや遅くなるが精度が上がる」という報告もあり、デフォルト設定のままでは本来の性能を引き出せていない可能性もある。

エージェント用途に必要なGPUスペックの目安

エージェント用途でローカルLLMを動かすには、VRAM 16GB以上のGPUが実用ラインの目安となる。Qwen3.5-27BやGemma 4-31Bといった27B〜31Bクラスのモデルは、Q5量子化でもモデル本体だけで14〜16GB前後のVRAMを消費する。さらにエージェント用途ではコンテキスト長を長く設定するため、KVキャッシュ（推論中に蓄積される中間データ）のVRAM消費も無視できない。

当サイトの検証環境（RTX 5060 Ti 16GB / i7-14700F / 96GB RAM）では、Ollamaを使ったデフォルト量子化のベンチマークで以下の結果を得ている。

押さえておきたいのは、Gemma 4系モデルの推論速度がQwen3.5のMoE版（35b-a3b）と比べて明確に速い点。gemma4:26bが37.0 tokens/secに対し、qwen3.5:35b-a3bは18.7 tokens/sec。Redditでの「Gemma 4は4Bや9Bモデル並みに速い」という報告と整合する結果になった。

ここで注意したいのは、上記ベンチマークはデフォルトのコンテキスト長で計測したものという点。エージェント用途で150,000トークンのコンテキスト長を設定すると、KVキャッシュがVRAMを大幅に圧迫する。VRAM 16GBでは、Q5量子化のモデル本体を読み込んだ状態で確保できるKVキャッシュの余裕が1〜2GB程度しか残らないケースも考えられる。

RTX 4070 Super（Oculink接続）でのqwen3.5:35b-a3bが6.8 tokens/secという数値も示唆的だ。帯域幅が制限されるOculink環境では、エージェントの多段タスクに必要なレスポンス速度を確保しにくい。エージェント用途ではPCIe直結のGPUが望ましいと筆者は考える。

VRAM容量別の目安を整理すると、以下のようになる。

筆者の見解——用途で選ぶローカルLLMエージェント

ここからは筆者の独自分析になる。Redditの検証結果と当サイトのベンチマークデータを総合すると、Qwen3.5とGemma 4の使い分けは「何を最優先するか」で決まると考える。

完遂率を重視するならQwen3.5-27B。 自動化スクリプトの生成、CI/CDパイプラインの構築、定型業務の自動化など「結果が正しくなければ意味がない」タスクにはQwen3.5が向いている可能性が高い。自己修正ループがあるため、多少時間がかかっても最終出力の品質が安定するという報告は説得力がある。思考トークンが膨らみやすい点はVRAMとのトレードオフだが、最終結果の信頼性を考えれば許容範囲ではないだろうか。

応答速度と対話性を重視するならGemma 4-31B。 短いタスクを次々とこなすインタラクティブな使い方、コードの部分修正、情報検索のアシスタントといった用途では、Gemma 4の速度が活きる場面が多いと筆者は見ている。ただしロングコンテキストでの精度低下が報告されている点は要注意で、長い会話履歴を維持しながらエージェント的に使う場合はQwen3.5のほうが安定するかもしれない。

実際の運用では、1つのモデルに固執するよりも両方を使い分けるアプローチが現実的だろう。OllamaやLM Studioのようなツールでは複数モデルの切り替えが容易なので、タスクの性質に応じて選択する運用がローカルLLMの強みを最大限に活かせる。クラウドAPIと違い、モデル切り替えに追加コストがかからないのもローカル環境の利点。

もう一つ、見落とされがちな観点がある。エージェント性能は量子化の精度にも左右されるという点だ。今回の検証ではQ5_K_XLという比較的高品質な量子化が使われていたが、VRAMを節約するためにQ3やQ4に落とすと、特に多段推論での精度に影響が出る可能性がある。VRAM容量に余裕があるほど高品質な量子化を選べるため、エージェント用途では「モデルが載るギリギリのVRAM」ではなく「余裕を持ったVRAM」を確保することが重要になると考える。

ローカルLLMのエージェント性能評価はまだ発展途上の分野で、今後もモデルのアップデートやllama.cppの最適化によって状況は変わっていくはず。あなたの環境ではどちらのモデルが使いやすいと感じているだろうか。VRAM 16GBでエージェント的なタスクを試しているなら、ぜひ両モデルを比較してみてほしい。

まとめ

ローカルLLMの「エージェント性能」は、単発の精度評価では見えない実用上の差を浮き彫りにする。Qwen3.5-27Bは慎重な自己修正で最終結果の品質を高め、Gemma 4-31Bは速度で勝るが長コンテキストや複合タスクの詰めに課題が残る。万能な1モデルは存在せず、用途に応じた選択が現時点での最適解だろう。

エージェント用途を試すなら、まずVRAM 16GB以上のGPU環境を整え、OllamaやLM Studioで両モデルを動かしてみるのが最も確実な判断方法になる。ローカルLLMやOllamaの始め方については別記事で詳しく解説しているので、これから環境構築を始める方はそちらも参考にしてほしい。

よくある質問（FAQ）

Q: Qwen3.5-27BやGemma 4-31BはVRAM 12GBで動かせる？
A: Q4以下の量子化を適用すれば起動は可能だが、エージェント用途で必要な長コンテキスト設定ではVRAMが不足しやすい。実用的にはVRAM 16GB以上を推奨する。

Q: エージェント用途でコンテキスト長はどれくらい必要？
A: 多段タスクの実行には最低でも8,000〜16,000トークンが目安。自動化スクリプトのような複雑なタスクでは32,000トークン以上が望ましく、Redditの検証では150,000トークンに設定されていた。

Q: Qwen3.5とGemma 4以外にエージェント性能が高いローカルLLMはある？
A: GLM 5.1が複雑なソーシャル推論ゲームで高い自律性を示したという報告がある。ただしローカル向けモデルのエージェント性能評価はまだ発展途上で、定番のベンチマークが確立されていないのが現状。

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

おすすめパーツ 価格まとめ

本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。