gemma4:12bがollamaで直った — 0.30.5で3層バグ全解消を実測確認【回避策は不要に】

こんにちは。梅雨の足音が聞こえてきて、部屋の GPU の熱がこもりやすくなる頃ですね。

gemma4:12b は ollamaOllama（ローカルLLMランタイム）手元の PC でオープンウェイトの LLM を手軽に動かすための、無料のソフト。詳しく →（ローカルで AI モデルを動かすための道具）の 0.30.5 で直りました。前日まで私の環境で起きていた「落ちる（SIGFPE）」「Linux 向けに配られていない（macOS専用配布）」「日本語が崩れる」の3つの不具合が半日で全部解消され、公式のタグ（配布名）で素直に動きます。速度は RTX 4070 Ti の実測で 52t/s。これまでの回避策は引退させてよく、残る作法は think:false を付けることだけです。

前日に「壊れている」と記録したのと同じ環境・同じ条件で、答え合わせをしました。同じ Gemma 4 系の小さいモデルについては Gemma 4 E4B、ランクS確定——24問採点とOCR比較でわかった得意・苦手 に書いているので、あわせて読むとつながりが見えやすいと思います。

gemma4:12b は、少なくとも私の検証環境では、2026-06-05 時点で素直に使える状態になりました。前日までの「壊れている」という評価は、もうそのままでは当てはまりません。ここははっきり言います。ollama 0.30.5 で SIGFPE は解消され、公式タグ gemma4:12b も Linux に降りてきて、GGUFGGUF（ggml Unified Format）llama.cpp 系のソフトでローカル LLM を動かす時に使う、モデルの保存形式。詳しく →（ローカル LLM でよく使われるモデルファイルの形式）の日本語崩れも修正されました。

なので、以前やっていた次の回避策は、原則として引退させて構いません。

• Modelfile で text blob を挟む
• llama.cpp 経由で逃がす
• 「とりあえず動く別ルート」を維持し続ける

ただし、think: false だけはまだ必要です。gemma4 は思考モデル（答える前に「考える」部分を別に出すモデル）なので、これを付けないと出力が thinking 側に流れ、「動いているのに空っぽに見える」ことがあります。

確かめたのは、前日に「壊れている」を記録した同じ環境（RTX 4070 Ti 12GB）です。項目ごとの方法と結果は次のとおりです。

細かく言うと、温度（出力のばらつき）は temperature 0 にそろえ、速度は ollama サーバーが報告する値（eval_count / eval_duration）で測っています。24問テストは同じ問題セット・同じ採点基準で測り直し、結果の JSON は実測台帳に保存しました。修正がいつ入ったかは、GitHub のリリースノートと Hugging Face の lastModified（どちらも一次ソース）で確認しています。

導入の手順そのものは導入ガイド（続報2節を追記済み）に、GPU ごとの可否や速度は早見表記事にまとめてあるので、ここでは「何が直ったか」の答え合わせに絞ります。

時刻は UTC で並べます。JST は混ぜません。

• 2026-06-04 朝: ollama 0.30.4 で 3 層切り分け検証。SIGFPE、配布形態、日本語崩れを確認
• 2026-06-04 15:42 UTC: ggml-org 側で GGUF 再変換
• 2026-06-04 17:00 UTC: ollama v0.30.5 リリース。リリースノートに Fix gemma4:12b floating point exception crash と明記
• 2026-06-05: 同一環境で再検証。公式タグ gemma4:12b が使えること、日本語崩れが消えたことを確認

ここまでが一次ソースで確かめられた事実です。原因の推測とは分けて、まず事実だけを時系列で固定しておきました。

出たばかり（day-one）で壊れていたモデルが半日で直る、かなり珍しいケースです。「昨日ダメだったのに今日はいける」がいちばんややこしいので、時系列を切って残しておく意味があると考えています。

今回の問題は、ひとまとめにすると見誤ります。私の検証では、少なくとも次の3層に分かれていました。

SIGFPE は 0.30.5 で再現しなくなった

前日まで、gemma4:12b は ollama 上で floating point exception（計算の途中で起きる異常終了）を起こしていました。これが 0.30.5 で修正され、同じ 4070Ti 12GB で再現しなくなったのが今回の大きな変化です。前日に実際にクラッシュしていた経路（HF から GGUF を直接 pull → generate）そのものでも、0.30.5 では正常に生成できました。

ここで、原因の見立てを一段戻す必要が出ました。落ちる原因がハード寄りに見えても、実際にはランタイム（モデルを動かすソフト側）の修正で落ちなくなることがあります。GPU だけを疑って終わると外す、ということですね。

Linux にも公式タグが来た

前は 12b 系の扱いがやや特殊で、macOS 専用配布という見え方をしていました。それが今回、gemma4:12b（7.6GB）が Linux にも配布され始め、ollama pull gemma4:12b でそのまま導入できるようになっています。

実務ではここがかなり大きいです。以前は回避策として Modelfile や llama.cpp に逃がす判断が必要でしたが、今は少なくとも「まず公式タグを試す」という順番でよくなりました。

日本語崩れは GGUF の再変換で直った

もう一つが、日本語出力の崩れです。前日の検証では、「日本の四季について教えてください」を temp0 で投げると、「三千島」という幻覚（実在しないものをもっともらしく書くこと）や、トークン分裂っぽい不自然なスペースが出ていました。

因果を雑にしないために、前日と同じ ggml-org リポジトリの GGUF を pull し直し（中身の blob が新しいものに置き換わっていることを digest で確認したうえで）、同じ質問・temp0 で比べました。結果は、桜・お花見・三寒四温 を含む、普通の構造化された日本語に戻っています。「同じ配布元の変換物が、再変換の前後で直った」ことを直接確かめられた形です。

なお、新しく登場した公式タグ gemma4:12b（こちらは別の変換物で、vision/audio 込みの 7.6GB）でも、同じ質問で正常な日本語を確認しました。どちらの経路でも日本語は直っています。

見た目だけの差ではありません。こういう崩れがあると、「文章は出るけれど、そのまま社内文書には使えない」という判断になります。地味ですが、効く差です。

比較は条件をそろえないと意味がないので、ここでは同じ質問・temp0・同じ GPU だけを見ます。条件は次のとおりです。

• GPU: 4070Ti 12GB（同一機）
• 温度: temp0
• 質問: 「日本の四季について教えてください」
• モデル: 同じ ggml-org リポジトリの GGUF（Q4_K_M）。修正前=旧 blob／修正後=再変換後の新 blob（digest が別物であることを確認済み）

修正前は、三千島 のような幻覚が混じり、文章の途中に不自然な分裂やスペースが入って、日本語としてのまとまりが崩れていました。修正後は、桜、お花見、入道雲など季節の説明が自然に出て、構造化された日本語として読めます。そのまま実務のたたき台に使えるレベルまで戻りました。

大事なのは、「日本語が出るようになった」ではなく 「崩れ方が消えた」 という点です。

24問テストを測り直した結果は次のとおりです。

• D（日本語）: 29 → 45点（+16）
• 総合: 173/240（B） → 186/240（77.5%・A）

俳句の問題では、以前 松尾芭人 と崩れていた固有名詞が、今回は満点回答になりました。分かりやすい改善です。

ただし、一つ注意があります。A/B/C の微差は、ランタイムの違い（llama.cpp day-one → ollama 0.30.5）込みです。これをそのまま「ollama のほうが全体的に上」と読むのは雑で、ビルドの成熟度の差として読むのが妥当です。モデルそのものの差というより、同じモデルがどこまで整っているかを見ている、と考えるのが近いと思います。

直ったけれど、完璧になったわけではない

新しい粗もあります。

• A3 でデーヴァナーガリー文字（ヒンディー語などの文字）の混入が 1 箇所
• C2 は、メカニズム説明は正しいのに出力値を誤答

「直った」は「完璧になった」と同じではありません。 つい持ち上げたくなるところですが、直った点と残る癖は分けて見ないと判断を誤ります。

速度の結果も、回避策を捨てやすい材料でした。

• 52.2〜52.7 t/s
• VRAM 8.1GB
• GPU 使用率 100%
• 4070Ti 12GB で回避策版と同速（52.25 t/s）

公式タグへ移っても、速度面のコストはゼロでした。見た目が直っても遅くなるなら話は別ですが、今回はそうではないので、少なくとも速度を理由に回避策を残す必要は薄いです。

ただし、8GB 帯は引き続き崖の縁です。VRAM の実測が 8.1GB なので、8GB のカードではまだ余裕がありません。ここは以前の判断を変えていません。GPU ごとの可否や速度は、早見表記事を見ていただくのが早いです。

• gemma4:12b GPU速度ガイド（2026）

回避策を組んだ方がいちばん気になるのは、「いつ捨てていいのか」だと思います。

もう公式タグを試してよい

次のどれかに当てはまるなら、まず ollama pull gemma4:12b を試してください。

• gemma4:12b が動かないという古い情報を見て迷っている
• SIGFPE が原因で止まっていた
• Modelfile や llama.cpp 迂回を入れている
• 公式対応を待つべきか、もう戻すべきか判断したい

この場合、今は回避策を維持するより、公式タグへ戻すのが自然です。以前作ったテキスト blob の Modelfile や llama.cpp 迂回も、公式タグで同じ速度（52t/s）が出るので、原則引退で問題ありません。0.30.4 以前を使い続ける事情がある場合だけ残してください。OS やライブラリの版が違うと手順が変わることもあるので、本番の環境へ入れる前にテスト環境で一度動かしておくと安心です。

think:false はまだ必要

繰り返しになりますが、think:false は必要です。0.30.5 にしたのに応答が空なら、ほぼ間違いなくこの付け忘れです。

/api/generate よりも /api/chat + think:false のほうが確実でした。gemma4 は reasoning モデルなので、ここを外すと「反応がない」と誤認しやすいです。

# 0.30.5 以降の最短手順（これだけで動きます）
ollama pull gemma4:12b

curl localhost:11434/api/chat -d '{
  "model": "gemma4:12b",
  "messages": [{"role": "user", "content": "こんにちは"}],
  "think": false,
  "stream": false
}'

今の作法を一言でまとめると、こうなります。

• モデル本体の回避策: 不要
• 推論の見え方対策: think:false を付ける

なお、8GB の GPU で動くようになったわけではありません。そこは変わっておらず、VRAM 実測 8.1GB で 8GB カードは引き続き崖の縁です。GPU 別の可否は早見表記事をご覧ください。

社内やチームで共有するなら、次の順で伝えると誤解が減ります。

1. ollama 0.30.5 で gemma4:12b の SIGFPE は修正済み
2. 公式タグ gemma4:12b が Linux でも配布開始
3. 日本語崩れも GGUF 再変換で改善
4. 速度は回避策版と同等
5. 残る注意点は think:false

逆に、「完全に別物になった」「もう何も気にしなくていい」「どの GPU でも同じ」という言い方は避けたほうがいいです。そこまで言うと実態から外れます。「直ったけれど、まだ作法は残る」くらいがちょうどいいところです。

前日に「壊れている」と記録していたからこそ、翌日の「直った」を同じ条件で確かめられました。こういう答え合わせは派手さはないですが、現場ではかなり役に立ちます。

古い情報と新しい情報が混ざっているときは、まず時系列を切る。次に、同じ条件で再現する。最後に、回避策を残すか捨てるかを決める。今回の判断材料も、その順で見るのがいちばん安全だと思います。

• ollama v0.30.5 リリースノート（GitHub）
• ggml-org/gemma-4-12B-it-GGUF（Hugging Face）
• gemma 4 のAIワークロードページ（META-MARK）

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