見出し画像

ローカルLLMのコーディング能力を4軸で比較してみた―― ベンチマークでは互角なのに、実際に動かすと差が出た

きっかけ:VRAM32GBで実用的なAIコーディングは可能か?

VRAM 32GB環境を手に入れたので、ローカルLLMで実用的なAIコーディングが可能か知りたくなった。ClaudeやCodexの課金を減らないか調べたくなった。

VRAM 16GB環境で試していた時には、心もとないプログラミングしかできなかった。だが、HumanEval的な「関数単体の実装問題をどれだけ解けるか」というベンチマークではいい結果が出ている。実用とは乖離していると感じていた。

実務でLLMにコードを書かせるときは、単一の関数よりも「複数ファイルにまたがるアプリ」や「見た目のあるWeb UI」を書かせることの方が多い。関数一つが解けることと、ファイルが10個を超えるアプリを崩壊させずに書けることは、たぶん別の能力

そこで、正答率(ベンチマーク)だけでなく、UIデザインの出来栄え規模が大きくなったときの崩れにくさ指定したデザインルールをどれだけ守れるかも含めた4軸で、ローカルLLM同士を比較するツールを作ってみた。

作ったもの:4軸で比較するフレームワーク

LM Studio(OpenAI互換API)経由でモデルにタスクを投げ、自動で結果を保存・採点するツールをPython(FastAPI+素のJS)で組んだ。

③が今回一番の狙いだったが、後から④も追加した。実務でLLMにコードを書かせるとき、「自由にデザインさせる」よりも「既存のデザインシステムに従わせる」場面の方がむしろ多い。

検証環境

LM Studio 0.4.19 / 32GB VRAM(2モデル同時ロード不可のため、実行時にlms unload --all → lms loadで自動切り替え)

比較したのは以下の2モデル。

VRAM使用量がほぼ同じ(18.85GB/18.63GB)モデル同士の組み合わせ。ただしQwen側はコーディング特化モデル・MoE、Gemma側は汎用モデル・Denseという非対称性はある。

結果1:ベンチマークは互角。でも速度が13倍違う

8問とも両モデル全問正解。正答率では差がつかなかった。

Qwenが約13倍速く、生成量も4分の1程度。MoE(実働3B)とdense 31Bという構成差がそのまま表れた形だ。ここだけ見ると「Qwenの圧勝」に見える。

結果2:UIデザインは一長一短

ダッシュボード生成タスクを見比べると、傾向がはっきり分かれた。

Gemmaが生成したダッシュボード。要素は豊富だが「User Acquisition」のグラフが空白のまま描画されていない。

Qwenが生成したダッシュボード。プロンプトの言語(日本語)に自動で追従し、要素数は少なめだが破綻がない。

  • Gemma: 英語UI。折れ線グラフ+棒グラフ+取引テーブル(アバター画像付き)と要素が多く作り込まれている。ただし「User Acquisition」セクションの棒グラフが実際には描画されず空白になっているバグがあった。

  • Qwen: プロンプトの言語(日本語)に自動で追従し、日本語UIで生成。要素数は少なめだが、期間切替タブ付きの棒グラフがきちんと描画されていて破綻がない。

生成時間もGemmaが99〜227秒/タスクに対し、Qwenは10〜19秒/タスクとここでも大差だった。

結果3:規模テストで見えた「壊れるコード」、複数回試すとくっきり

Tier1(単一ファイル)〜Tier4(認証付きAPI、15ファイル前後)まで難度を上げていくと、構文自体はどちらも全ファイル正しい(py_compileでエラーなし)。ここまでは互角に見えた。

ただしimportの整合性を見ると、Qwenに気になる傾向が出た。

# Qwenが生成した main.py(エントリポイント)
from fastapi import FastAPI
from .database import engine, Base
from .routers import bookmarks

main.pyはアプリの一番外側、uvicorn main:appやpython main.pyで直接実行される想定のファイルだ。ここで相対import(from .)を使うと、実行時にImportError: attempted relative import with no known parent packageで確実に起動失敗する。Gemmaは同じ構成でfrom database import engineのような絶対importを使っていて、こちらは問題なく動く書き方だった。

単発の結果だけで判断するのは危ういので、モデルサイズ・アーキテクチャの異なる3パターン(Gemma4-31B dense、Gemma4-26B-A4B MoE、Qwen3-Coder-30B)でTier3・Tier4を複数回ずつ実行し、発生率を数えてみた。

Qwen3-Coder-30Bは計測した全回で発生——もう偶然では説明できない、完全に系統的な癖だ。Gemmaはdense/MoEで多少差はあるものの、Qwenに比べれば大幅に少ない。「Qwenは高速だが、ファイル数が増えると実行時に確実に落ちるコードを書きがち」という傾向がはっきりした。

結果4:デザインシステムへの追従はどちらも及第点、ただし壊れ方が違う

最後に④、あらかじめ用意したデザインシステムCSS(色・余白のCSS変数と.btn/.card/.inputなどのコンポーネントクラス)を渡し、「独自の<style>は書かず、指定クラスだけでUIを組んでほしい」と指示するテストをやってみた。ログインフォーム・チームメンバー一覧・設定ページの3タスクで試した。

Qwenが生成したログインフォーム(指定デザインシステム適用)

Gemmaが生成した同じタスクの結果。見比べても差がほとんど分からないくらい、どちらも指定ルールに素直に従えている

ログインフォームタスクでは、両モデルとも独自CSSを一切書かず、指定されたクラスだけで見た目もほぼ同じ結果を出してきた。「自由に作らせる」②の結果とは対照的に、ルールを与えられればどちらも忠実に守れることが分かる。

3タスク通して見ると、Qwenは1件だけ未定義のクラス名(badge-invited)を自分で作ってしまう違反があった。用意したデザインシステムに「招待中」を表すバッジの色が定義されていなかったため、既存の命名規則を真似て近い名前をでっち上げた形だ。独自の<style>を書くよりは行儀の良い壊れ方だが、「無いものは作ってしまう」傾向は覚えておきたい。

Gemmaは残り2タスクで応答自体が空になり、比較ができなかった。同じ現象は③の反復検証中にも複数回見られていて、このモデル固有の生成安定性の問題っぽい。

まとめ

  • 関数単体のベンチマークでは正答率に差がつかず、Qwenの圧勝に見えた

  • しかし複数ファイルにまたがる規模テストまで踏み込むと、Qwenはエントリポイントで相対importを使い、実行時に確実に落ちるコードを書くという弱点が見えた(発生率100%)

  • Gemmaは遅いが、この種の崩れはdense 8%・MoE 20%程度と、Qwenに比べれば大幅に少なかった

  • UIデザインも、Gemmaは要素豊富だが描画バグがあり、Qwenはシンプルだが破綻がない、という似た構図だった

  • 一方、デザインシステムを与えて従わせるテストでは両モデルとも及第点。自由にやらせると差が出るが、ルールを与えれば忠実に守れることも分かった

どう使い分けるか

4軸の結果を踏まえて、実際の用途ごとに整理するとこうなる。

用途 おすすめ 理由 ちょっとしたスクリプト・単発の関数実装 Qwen 速度が圧倒的(13倍)。正答率も互角で、短いコードなら壊れ方の弱点も出にくい その場でチャットしながら試行錯誤するプロトタイピング Qwen 生成が速いので「ダメならすぐ聞き直す」ループが高速に回せる 複数ファイルにまたがるアプリを一発で動かしたい(生成後に自分で直さない前提) Gemma 相対importで実行時に落ちる確率がQwenは100%、Gemmaは8〜20%と大幅に低い 既存のデザインシステム・コーディング規約に従わせたい実装支援 どちらでも可 ルールを与えると両モデルとも忠実に守れる。この用途なら速いQwenを選んで問題ない CI・自動化パイプラインなど、無人で確実に動く出力が必要な場面 Gemma(ただし要監視) Qwenの相対importバグは無人実行だと致命的。ただしGemmaにも生成が空応答になる不具合が別途あるため、どちらを使うにせよリトライ処理は用意した方がよい

一言でまとめると、「動けばいい・自分がすぐレビューする」ならQwen、「一発で動くことを期待する・人手を離れて動かす」ならGemma、デザインルールへの追従だけならどちらでも困らない、という使い分けになる。

振り返り

一番の学びは、「関数一つ解けるか」のベンチマークだけでは、実務で使えるかどうかの答えにならないということだ。今回もベンチマークの正答率だけ見ていたら「Qwen一択」で終わっていた。ファイル数を増やすテストを加えたことで、初めて見えてくる弱点があった。

もう一つの学びは、単発の実行結果で「このモデルはこういう性質だ」と結論づける危うさだ。MoE版Gemmaが1回失敗しただけで最初の仮説を覆しかけたが、複数モデル・複数回試して初めて「Qwenは系統的、Gemmaはブレの範囲内」という確かな傾向が見えてきた。傾向を主張するなら、最低でも3回程度は反復して確かめる必要があると痛感した。

用途ごとの向き不向きがはっきり整理できたことと、ローカルLLMでAIコーディングできる規模感の感触を得られたことが、今回の一番の収穫です。


いいなと思ったら応援しよう!

TakkunBlue よろしければ応援お願いします!