GEMMA4-12B-CODERは何に使うべきか：コード55/60、総合B評価の実測結論

GEMMA4-12B-CODER は RTX 4070 Ti 12GB で 約54.6 tok/s と快適に動きます。コード問題は 55/60 で強いです。ただし24問総合は 160/240（B） で、Gemma 4 E2B/E4Bや通常12Bに総合力で勝つモデルではありません。現状は「MTPで爆速化する本命」ではなく、MTPなしで使うコード補助向けの12B派生として見るのがよさそうです。

関連記事としては BlogGemma 4 MTP drafter を今すぐ入れるべきか？ RTX 4070 Ti 12GB でつまずいた3つのポイントと結論RTX 4070 Ti 12GBでGemma 4 MTP drafterを実測。ドラフター0.14GB、ただし最速はvLLMの162.7 tok/s。導入判断を正直にまとめます。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

新しいローカルLLMを見ると、まず気になるのは名前です。

GEMMA4-12B-CODER。この名前なら、かなり期待したくなります。Gemma 4の12B級で、しかもCoder。では、既存のGemma 4 12BやE2B/E4Bから乗り換える価値はあるのか。12GB GPUで動くのか。MTP drafterは使えるのか。実際のコード用途ではどこまで任せられるのか。

今回、AIサーバーの RTX 4070 Ti 12GB で、gemma4-coding-Q4_K_M.gguf を動かして24問ベンチまで回しました。

実測後の感触は、コード補助モデルとしてはかなり気持ちよく動く。ただし、万能なGemma 4上位互換ではない、というものです。

今回の実測結果です。

読者向けに一言でまとめるなら、こうです。

コードを書かせる・直させる・短い実装案を出させる用途なら試す価値あり。日本語の常識問題やひっかけ、複雑な論理推論まで1本で任せるなら、Gemma 4 E2B/E4Bや通常12Bのほうが安定します。

使ったのは Hugging Face にある Buck2222/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF の gemma4-coding-Q4_K_M.gguf です。

AIサーバー側の配置はこうです。

~/llama-cuda/models/gemma4-coder/gemma4-coding-Q4_K_M.gguf

Q4_K_M のファイルサイズは約 6.9GB。RTX 4070 Ti 12GBには問題なく載りました。

ただし、初回ロード時に一つ詰まりました。既存の古いllama.cppでは、次のエラーで止まります。

unknown model architecture: 'gemma4'

これはモデルが壊れているというより、llama.cpp側が古いのが原因です。今回は既存環境を壊さないように、別ディレクトリへ最新masterをCUDAビルドしました。

~/llama-cuda-gemma4

この最新ビルドでは gemma4.cpp / gemma4-assistant.cpp が入り、モデルのロードに成功しました。

今回、安定して使えた設定はこれです。

llama-server \
  -m ~/llama-cuda/models/gemma4-coder/gemma4-coding-Q4_K_M.gguf \
  -ngl 999 \
  --host 0.0.0.0 \
  --port 18088 \
  -c 8192 \
  -np 1 \
  --jinja \
  --reasoning off \
  --reasoning-budget 0

特に効いたのは --reasoning off と --reasoning-budget 0 です。

最初にreasoningを切らずに試したときは、reasoning_content 側に思考が入り、コード出力が途中で切れました。コード補助として使うなら、まずは思考を止め、短く正確に返させる方が扱いやすいです。

短いTypeScript生成では、次のようにきれいに完走しました。

function isPrime(n: number): boolean {
  if (n <= 1) return false;
  if (n <= 3) return true;
  if (n % 2 === 0 || n % 3 === 0) return false;

  for (let i = 5; i * i <= n; i += 6) {
    if (n % i === 0 || n % (i + 2) === 0) return false;
  }
  return true;
}

この時のAPIログでは、121 tokens を 56.4 tok/s で生成しています。体感としては十分速いです。

検証日は 2026-06-29 です。手順は、導入確認、短いコード生成、24問ベンチ、既存Gemma 4結果との比較、MTP関連ファイルの確認に分けました。

1つ目に、AIサーバー上へ gemma4-coding-Q4_K_M.gguf を配置し、古いllama.cppと最新llama.cppの両方でロード可否を確認しました。古いビルドでは unknown model architecture: 'gemma4' で失敗し、最新master 8c146a8 のCUDAビルドでは成功しています。

2つ目に、OpenAI互換APIで短いTypeScript関数を生成させました。reasoningありでは出力が途中で切れたため、reasoningなし設定で再実行し、121 tokensを約56.4 tok/sで完走することを確認しました。

3つ目に、24問テストをAIサーバー内から直接 127.0.0.1:18088 に投げました。ローカルPCから直接叩いた初回は通信経路の都合で fetch failed になったため、その失敗結果は採用していません。採用した正本は data/benchmark-results/gemma4-12b-coder-q4-20260629-raw.json です。

4つ目に、既存のGemma 4実測ファイルと比較しました。比較対象は通常12Bのllama.cpp/Ollama結果、Gemma 4 E2B/E4BのRTX実測結果です。ランタイムが完全一致していないため、この記事では「絶対的な上下」ではなく、用途判断の材料として扱います。

いつもの24問テストを、AIサーバー内から直接 127.0.0.1:18088 に投げました。

ローカルPCからAIサーバーへ直接叩いた初回は fetch failed になったため、最終的にはAIサーバー内でPythonスクリプトを使って再実行しています。これは通信経路の問題であり、モデルの問題ではありません。

結果はこちらです。

合計だけ見ると、正直そこまで高くありません。ですが、内訳を見ると性格がはっきり出ています。

コードは強い。ひっかけと日本語知識は弱い。

このモデル名から期待するなら、むしろ納得しやすい結果です。

コード系は 55/60 でした。

良かった点は、基礎的な実装・脆弱性検出・Pythonの挙動説明がかなり安定していたことです。

• FizzBuzz拡張は独立した if で正しく連結
• SQLインジェクションはパラメータ化クエリまで提示
• 再帰フィボナッチは指数時間とスタック問題を指摘
• Pythonのミュータブルデフォルト引数も正解
• メール正規表現も 4,5,6 を正しく特定

唯一大きめに落としたのは、JavaScriptの var + setTimeout 問題です。

説明の途中では「ループ完了後の i は3」と正しく書けているのに、最終出力を「2が3回」としてしまいました。これは惜しいですが、コードモデルとしては実務でも起きやすい「説明と結論のズレ」です。

なので、使い方としては、コードを丸投げして終わりではなく、テストやレビューとセットで使うのが良いです。下書きや修正案の生成には向いています。

弱さもかなり見えました。

ひっかけ問題

A4の「花子はりんごを取りました」は、正解が「わからない」です。文脈が足りないからです。

しかしGEMMA4-12B-CODERは「花子が持っている」と答えました。日常的な意味に寄せすぎています。

A6の「医者と息子」も、正解は「担当医は母親」です。ところが、父親・漢字なぞなぞ方向へ崩れました。これは典型的なジェンダーバイアス問題で、ここを外すのは痛いです。

論理問題

B4の「100人の囚人と帽子」は、本来はパリティ戦略が必要です。

ところが、後ろの人の色を伝えるような誤った連鎖戦略になりました。文章量は多いのですが、肝心の情報圧縮ができていません。

B6の偽コイン問題も、ラベル管理や本物コインを混ぜる方向性は出ていますが、3回で確定する決定木としては不完全でした。

日本語知識

日本語カテゴリは 32/60 です。

特に目立ったのは、俳句問題で「松尾芭蕉」を「松尾芭人」とし、季語も「蛙」ではなく「古池」とした点です。慣用句問題では、正解が1と3なのに3と4を誤答し、その後に「確信犯的」を反復して崩れました。

これは通常のGemma 4 12Bでも過去に出た弱さと似ています。コード特化で改善されたというより、日本語文化・慣用句・ひっかけ問題は引き続き注意という印象です。

ここが読者の一番知りたいところだと思います。

既存のローカル実測と並べると、こうなります。

この表だけ見ると、Coder版は少し意外です。

12B Coderなのに、総合スコアではE2B/E4Bより低い。

ただし、これは「Coder版がダメ」という意味ではありません。24問テストはコードだけでなく、ひっかけ・論理・日本語力を含む総合テストです。Coder版の強みは、名前どおりコード側に寄っています。

だから評価軸を間違えると判断を誤ります。

GEMMA4-12B-CODERを使うなら、向いているのはこのあたりです。

1. 小さな関数やスクリプトの下書き

短い関数、CLI補助、データ整形、簡単なTypeScript/Pythonの実装案には向いています。

54 tok/s前後で返るので、ローカル補助としてテンポが良いです。クラウドAPIを呼ぶほどではない小さな作業に合います。

2. 既存コードの修正案

SQLインジェクションのような典型的な問題はきちんと見つけられました。

セキュリティ判断の丸投げは危険です。一方で、「このコードのどこが怪しいか」「どう直す方向か」を出す一次レビューには使えます。

3. reasoningを切ったコード補完

今回の実測では、reasoningを切った方が扱いやすかったです。

長々と考えさせるより、短くコードを返すローカル補助として使う方が相性が良いです。

4. 外部APIに出したくない軽い開発メモ

ローカルで動くので、外部APIに投げたくない軽いメモやプロトタイプにも使いやすいです。

ただし、シークレットや顧客情報をそのまま投げる運用は避けるべきです。ローカルLLMでもログや履歴に残る可能性はあります。

逆に、向かない用途もはっきりしています。

1. 日本語の常識・慣用句チェック

「松尾芭蕉」「季語」「慣用句」あたりで落としています。

日本語の記事校正や文化的な説明を任せるなら、E4Bや通常12Bのほうがまだ安定します。少なくとも、このCoder版を日本語レビュー担当にするのはおすすめしません。

2. 複雑な論理パズル

帽子のパリティ問題や偽コイン問題は弱かったです。

文章量は出せますが、正しい決定木や情報理論的な圧縮に届いていません。複雑な設計判断や厳密な推論には、強いモデルで二重チェックした方がいいです。

3. MTP前提の高速化

今回の配布ファイルには、Q2_K、Q4_K_M、Q6_K、Q8_0 の通常GGUFがありました。

一方で、MTP用の別GGUFや、GGUF内部の h_next / nextn 系テンソルは見当たりませんでした。

最新llama.cpp自体は draft-mtp に対応しています。つまりランタイム側の準備はできます。しかし、今回のCoder GGUFでMTPが使える材料は確認できません。

なので現時点では、GEMMA4-12B-CODERはMTPなしで使うモデルとして考えるのが現実的です。

MTPの倍率やGPU別の効き方については、以前のBlogMTPの3x高速化は誇大だった—3090/4090/5090で実測した倍率の結論Gemma4 MTP自己投機デコードを3090/4090/5090で実測。3xではなくGPU次第で1.0〜1.9倍、5090は採択されても伸びませんでした。→に分けています。今回の記事では、そこを混ぜません。

用途別に整理します。

個人的な使い分けはこうです。

ローカルでコード補助だけしたいならCoder版。日本語も読む普段使いならE4B。速度重視ならE2B。12Bを使うなら通常版Ollamaの安定実装。

Coder版は「全部入りの本命」ではなく、用途を絞ると便利なモデルです。

今回の導入で分かった注意点も残しておきます。

古いllama.cppでは読めない

unknown model architecture: gemma4 が出たら、まずllama.cppを疑ってください。

モデルファイルを疑うより、最新masterに近いビルドを用意する方が早いです。既存環境を壊したくない場合は、今回のように別ディレクトリへcloneしてビルドするのが安全です。

reasoningは切った方が扱いやすい

コード補助用途なら、まずは以下を入れるのがおすすめです。

--reasoning off --reasoning-budget 0

思考を出させると、短いコード生成でも本文が途中で切れたり、reasoning_content 側に流れたりします。

24問スコアは総合評価として見る

160/240という数字だけで「弱い」と切るのは早いです。

コードは強いです。弱いのは、ひっかけ・日本語知識・複雑推論です。だから、この記事の結論は「弱いモデル」ではなく、使いどころが狭いモデルです。

この記事の数字は、2026-06-29時点の私のAIサーバー環境での結果です。

まず、24問スコアは暫定の手動採点です。過去のGemma 4記事と同じ採点基準に合わせていますが、自動採点ではありません。1問ごとの細かい部分点は、読み手によって少し揺れる可能性があります。

次に、比較対象のランタイムは完全には揃っていません。通常12Bにはllama.cpp初期ビルドとOllama 0.30.5の結果があり、E2B/E4Bにも別タイミングのRTX実測があります。そのため、この記事の比較は「同一条件の厳密なモデルランキング」ではなく、ローカル運用で何を選ぶかの判断表として読んでください。

また、MTPについては「今回確認した配布物ではMTP用ファイルやテンソルが見当たらない」という意味です。将来、配布元がMTP用GGUFを追加したり、別のCoder派生がMTP head付きで出たりすれば、判断は変わります。

最後に、コードカテゴリが強いとはいえ、生成コードをそのまま本番へ入れるのは避けた方がいいです。C2のように、説明と結論が食い違うケースもあります。テスト、型チェック、レビューと組み合わせて使うモデルです。

GEMMA4-12B-CODERは通常のGemma 4 12Bより強いですか？

総合力では、今回の24問だと通常12Bの方が上でした。Coder版は160/240、通常12Bはllama.cpp初期ビルドで173/240、Ollama 0.30.5で186/240です。

ただし、Coder版はコードカテゴリで55/60を取りました。総合チャット用の上位互換ではなく、コード補助に寄せた派生と見るのが自然です。

Gemma 4 E2B/E4Bから乗り換える価値はありますか？

普段使いなら、無理に乗り換える必要は薄いです。E2B/E4BはRTX実測で194/240、200/240と総合力が高く、日本語も含めて安定しています。

一方で、ローカルでコード補助だけを別枠にしたいなら、Coder版を追加する価値はあります。E4Bを普段使い、Coder版をコード下書き、という分担が一番現実的です。

MTPで高速化できますか？

今回確認した gemma4-coding-Q4_K_M.gguf では、MTP前提の運用はできないと見ています。配布ファイルにMTP用GGUFがなく、GGUF内にも h_next / nextn 系のMTP用テンソル名は見当たりませんでした。

llama.cpp側は最新ビルドで draft-mtp に対応しています。つまりランタイム側ではなく、今回のモデル配布物側にMTP材料がない、という切り分けです。

12GB GPUで快適に使えますか？

Q4_K_Mなら快適です。RTX 4070 Ti 12GBで約54.6 tok/s、短いコード生成では約56.4 tok/sでした。ローカル補助としては待ち時間がかなり少ない部類です。

どの量子化を選べばいいですか？

今回の検証ではQ4_K_Mを使いました。12GB GPUで速度と容量のバランスを見るなら、まずQ4_K_Mが扱いやすいです。Q6_KやQ8_0は品質確認の価値がありますが、VRAM余裕や速度との交換になります。

GEMMA4-12B-CODERは、名前どおりコード寄りのモデルでした。

• RTX 4070 Ti 12GBで 約54.6 tok/s
• 24問総合は 160/240（B）
• コードカテゴリは 55/60
• 日本語・ひっかけ・複雑推論は弱め
• 今回確認したGGUFでは MTPなし運用が前提

導入する価値はあります。ただし、期待する役割を間違えない方がいいです。

Gemma 4ファミリーの中で万能担当を探すならE4Bや通常12B。ローカルで軽快なコード補助を増やしたいならGEMMA4-12B-CODER。

このくらいの距離感が、いまの実測に一番合っています。

• GEMMA4-12B-CODER GGUF配布ページ
• llama.cpp公式リポジトリ
• BlogローカルLLMベンチマーク 24問テストの全問解説 — 何を・なぜ測っているのかMETA-MARK のローカルLLMベンチマークで使う24問（4カテゴリ・240点満点）の全問解説。各問題の設計意図、0/5/10点の採点基準、ランクS〜Dの定義をまとめたテスト仕様ページです。→
• Bloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→
• BlogMTPの3x高速化は誇大だった—3090/4090/5090で実測した倍率の結論Gemma4 MTP自己投機デコードを3090/4090/5090で実測。3xではなくGPU次第で1.0〜1.9倍、5090は採択されても伸びませんでした。→
• BlogGemma 4 E2B vs E4B：24問実測で見えた速度5倍差の使い分け基準Gemma 4 E2B（2B）とE4B（4B）を24問実測比較。スコア差9%・速度差5倍の実態と、VRAM 4GBで動く省電力LLMとして選ぶべき条件を整理。→
• BlogGoogle Gemma 4が変えたこと——Apache 2.0と本格マルチモーダルで「使えるオープンモデル」の基準が上がったGoogle DeepMindが2026年4月にリリースしたGemma 4の実力を整理する。Apache 2.0への変更、E2B〜31Bの4モデル構成、画像・動画・音声対応のマルチモーダル実装、そしてQwen 3.5やDeepSeek V3.2との比較まで。「ローカルで動かして本当に使えるか」という目線で書く。→

• BlogGemma 4 MTP drafter を今すぐ入れるべきか？ RTX 4070 Ti 12GB でつまずいた3つのポイントと結論RTX 4070 Ti 12GBでGemma 4 MTP drafterを実測。ドラフター0.14GB、ただし最速はvLLMの162.7 tok/s。導入判断を正直にまとめます。→
• BlogQwen3.5:4b 24問テスト——thinkingをOFFにしたらスコアが21%上がった話Qwen3.5:4bをOllama上でベンチマーク。thinkingモードが原因で9問が空回答になった。think:falseに切り替えたらスコアが194/240（80.8%）に回復。RTX 4070 Tiで101.5 tok/s出る4Bモデルの実力を24問で徹底検証。→
• Blog24問テストして198点/240点——Nemotron 9Bの正直な成績表ローカルLLM Nemotron-Nano-9B-v2-Japaneseに意地悪な引っかけ・論理パズル・コーディング・日本語力の24問を投げた本気の成績表。RTX 4070 Ti（VRAM 12GB）で63 tok/s、コーディング95%・総合82.5%（ランクA）。弱点も正直に語る。→

• 実際の構成を探すなら、GPU 比較ページやローカルLLM向け構成記事もあわせて見ると判断しやすいです。
• ハードウェア候補は用途別の AI 構成ガイドからたどると、単体製品より違和感なく検討できます。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！