Gemma 4 12Bリリースされたので、早速試してみたけど私の使い方には「うーん」な結果だった

新しいツールやモデルがリリースされると、つい試したくなってしまいます。
特にローカルで動くLLM（大規模言語モデル）の進化は目覚ましく、新しい名前を聞くたびに「今度はどれくらい賢くなったのだろう」と胸が躍るものです。

「Gemma 4 12B」がリリースされたという話を耳にしました。
私の環境でも動かせそうだったので、さっそく試してみることにしたのです。

結論から言うと、私の今の使い方においては、以前から使っている「llm-jp-4」のほうが、ずっと実用的で使いやすいと感じました。

今回は、実際に両方のモデルに同じ質問を投げかけてみた結果をもとに、私がそう感じた理由を少しお話ししてみたいと思います。

私のローカルLLMの付き合い方

そもそも、私はローカルLLMをそれほど高度な用途には使っていません。
主な用途は、毎朝のニュース記事の要約です。

あらかじめ登録しておいたニュースのテキストをローカルLLMに流し込み、要点をいくつか書き出してもらう。
それくらいの、比較的シンプルな使い方をしています。

そのため、私がローカルLLMに求めているのは、何よりも「軽さ」と「速さ」、そして「それなりに自然な日本語」です。
朝の忙しい時間に、何分も待たされたり、PCのファンが爆音で回り続けたりするのは、避けたいなと思っています。

そんな前提を持ちつつ、今回は少し複雑なテキストを読ませてみることにしました。
現在、私は「動画を編集するようなAIエージェントのカンパニー（仕組み）」を作るための設計書を書いています。

その設計書をローカルLLMに見せて、「何か問題点や改善すべき点があれば指摘してほしい」と頼んでみたのです。

期待の「Gemma 4 12B」に聞いてみた結果

まずは、新しく登場した「gemma4:12b」に設計書を読み込ませてみました。
12B（120億パラメータ）というサイズは、ローカルで動かすにはそこそこ大きなモデルです。

期待しながら出力を待っていたのですが、返ってきた文章を見て、私は少し困惑してしまいました。
以下は、実際に出力された内容の一部です。

設計書の 内容を 見る 時、 次の 5 つの ポイント で 修正 / 追加 させる ことを 強く 煎します。

### 1. 「差し 戻し」 フィードバックの 伝送 メカニズム （重要）

現在の 設計書 では、「人間ガ 梶 戻し を したら、 エージェントガ 再実行 させる」 と 記述 されて 居ますが、「どの ように 人間の 指示（Feedback）を LLM の コンテキストに 入れるか」 の 明示的 な 実装が 足り ません。

- 指摘: 単に revise_cutting に 戻る だけでは、 エージェ️⃣ントガ 「何処を 直せば 良いか」 を 知ら れば なり ません。

一見すると、それらしい指摘をしているように見えます。
しかし、よく読んでみると、日本語の接続詞や言葉選びがかなり不自然です。

「強く 煎（すす）します」
「人間ガ 梶（さし） 戻し を したら」
「知ら れば なり ません」

さらに読み進めると、状況はより深刻になっていきました。

4. 事前 処理 （Preprocessor） の VFR 対策

設計書 の コメント 箇所 で 「VFR → CFR」 の 修正 を 捏 然 度 低 係 居 せる 為に、「如何 支援 係 居 せる 為に」 が 足り ませんが。

- 指摘: 素材 以上 デ 筈り 案件 捏 然 度 低 係 居 せる 為に、 スマホ 🎥 覚 捏 然 度 低 係 居 せる 為に VFR （可変 フレームレート） は FFmpeg の -vsync cfr で 「強力 に」 照射 させ させる 事を 衷します。

「捏 然 度 低 係 居 せる 為に」という謎のフレーズが何度も繰り返されています。

絵文字が突然混ざり、文法も崩壊してしまっていて、正直に言って何を言っているのかさっぱり分かりません。
英語のニュアンスをそのまま不自然に翻訳しようとして失敗しているのか、あるいは日本語の学習データが偏っているのか。

いずれにせよ、私の環境では、この出力を解読するだけで一苦労してしまいます。
これでは、設計書のレビューどころではありませんでした。

一方で、「llm-jp-4」に聞いてみた結果

次に、同じ設計書を「llm-jp-4」に読み込ませてみました。

こちらは、日本の研究機関やコミュニティが主導して開発している、日本語に特化したモデルです。
出力された結果を見て、私はほっとしました。

## 2️⃣ Human-in-the-Loop（ヒューマン承認）実装の抜け漏れ

| 欠落ポイント | なぜ重要か | 推奨実装 |
|---|---|---|
| フィードバックの保存形式 | 現在は「人間が指示したら再実行」だけで、どの情報が次回のプロンプトに反映されるかが未定義 | `HumanInstructionHistory`（配列）を `project_state.json` に追加し、各エントリに <br>・timestamp<br>・agentId<br>・originalPrompt<br>・humanFeedback<br>・appliedFlag を持たせる |

このように、きれいに整理されたテーブル（表）形式で出力してくれました。

日本語の表現も、きわめて自然です。
「フィードバックの保存形式が未定義である」という指摘も、非常に的を射ています。
この指摘内容が技術的に100%正しいかどうかは、また別の議論かもしれません。

しかし、少なくとも「ツールとして、こちらの意図を理解し、対話が成立している」という安心感があります。
読んでいてストレスがなく、思考の壁打ち相手として十分に機能してくれていると感じました。

２つのモデルを比較してみて

今回の試行を通じて、両者の特徴は以下のように整理できるのではないかと思います。

ローカルLLMの比較イメージ

【Gemma 4 12B】
・スペック上のポテンシャルは高い（かもしれない）
・しかし、日本語の出力に大きな偏りや崩れがある
・メモリ消費が多く、動作が重い
・出力の解読にコストがかかる

【llm-jp-4】
・日本語の理解と表現力が非常に安定している
・表組みなどを活用した、視覚的に分かりやすい出力が得意
・動作が比較的軽快で、私の環境でもスムーズに動く
・実用的な「道具」として、すぐに使える

もちろん、Gemma 4 12Bにも良いところはあるはずです。

多言語での処理能力や、特定のタスクにおける推論能力は、llm-jp-4を上回っている部分もあるかもしれません。

しかし、私のように「日本語のドキュメントを読み込ませて、日本語で自然なフィードバックをもらう」という用途においては、そのポテンシャルを発揮しきれていないように感じます。
どれだけ裏側の知能が高くても、アウトプットの日本語が壊れてしまっては、受け取る側としては使いこなせません。

また、私の環境では、Gemma 4 12Bを動かすとかなりのメモリを消費し、出力までの待ち時間も長く感じられました。
毎朝のニュース要約というルーティンワークに使うには、少し荷が重いというのが正直なところです。

私がローカルLLMに求めるもの

今回の件を経て、私は自分がローカルLLMに何を求めているのかを、改めて実感することになりました。
私が欲しいのは、世界で一番賢い、超巨大なモデルではありません。

私の手元にあるPCで、
「すっと立ち上がり」
「さっと日本語を理解し」
「それなりに使える要約や指摘を、すぐに返してくれる」
そんな、軽くて速いモデルです。

日常の道具として使う以上、この「軽快さ」と「日本語の安定感」は、何物にも代えがたい価値だと思います。
どれだけ技術が進化しても、自分の生活のテンポに合わないツールは、自然と使わなくなってしまうものです。

そういう意味で、今回は「llm-jp-4」の使いやすさを再認識する良い機会になりました。

これからも、いろいろと試してみたい

とはいえ、新しいモデルを試すのをやめるつもりはありません。
ローカルLLMの世界は、本当に日進月歩です。

もしかしたら来月には、今のllm-jp-4よりもさらに軽くて、賢くて、日本語が堪能なモデルが登場しているかもしれません。
そうした新しい選択肢が現れたら、私はまた嬉々としてダウンロードし、試してみるのだろうと思います。

そうやって、自分の生活や仕事にちょうどいい道具を探していくプロセス自体が、私にとっては楽しい時間なのだと感じています。
みなさんも、もしローカルLLMを試す機会があれば、スペックの数字だけでなく、「自分の環境での心地よさ」を基準に選んでみると、面白い発見があるかもしれません。