Google DeepMindがオープンモデル「Gemma 4」をリリースしました。前世代のGemma 3から大幅に進化し、ライセンスもApache 2.0に変更。商用利用の制限が完全に撤廃されました。
今回、ローカル環境（VRAM 12GBのGPU）で実際に動かし、業務で使えるかテストした結果をまとめます。
【モデルラインナップ】
Gemma 4は4つのバリエーションがあります。
・E2B（7.2GB）：軽量・高速。テキスト＋画像＋音声対応
・E4B（9.6GB）：バランス型。テキスト＋画像＋音声対応
・26B MoE（18GB）：128専門家中8つを選択して推論。動画対応
・31B Dense（20GB）：最高性能。
「E」は「effective」の略で、総パラメータ数より少ないパラメータで効率的に推論します。
VRAM 12GBの環境ではE2BとE4Bが動作可能です。26B以上はVRAM 12GBでは厳しく、クラウド推論か大容量VRAM向けです。
【テスト環境】
・OS: NixOS unstable
・GPU: RTX 4070 VRAM 12GB
・ローカルLLM 実行環境: Ollama 0.20.0（Gemma 4対応版）
・比較対象: translategemma:12b（Google翻訳特化モデル）
【テスト1: 英語記事の日本語要約】
英語ニュース記事を「2〜3文で日本語に要約して」と指示した結果です。
・E4B：正確で自然な日本語。情報の取捨選択も適切
・E2B：正確で簡潔。E4Bよりやや情報量が少ない
・translategemma:12b（比較用）：正確で簡潔。翻訳特化モデルとしての安定感
3モデルとも実用レベルの品質でした。翻訳特化モデルと汎用モデルで品質差がほぼ見えないのは、Gemma 4の基礎力の高さを示しています。
【テスト2: Thinking Mode（推論モード）の効果】
Gemma 4にはThinking Modeがあります。ONにするとモデルが「考える過程」を内部で展開してから回答します。
同じ日本語要約タスクでの比較です。
・Thinking OFF：出力61トークン、約29トークン/秒
・Thinking ON：出力432トークン（内部推論含む）、約29トークン/秒
OFFにするとトークン数が87%削減されますが、回答品質はほぼ同じでした。
単純な翻訳・要約にはOFFが効率的です。一方、複雑な計画立案や推論が必要なタスクではONにすることで、より具体的で質の高い出力が得られました（時間帯の提案やリスク分析など）。
Ollama APIでは "think": false を指定するだけで切り替えられます。
【テスト3: Function Calling（関数呼び出し）】
Gemma 4はネイティブでFunction Callingに対応しています。これは「AIが外部ツールを呼び出す」ための仕組みで、自動化やエージェント構築に不可欠な機能です。
天気取得ツールを定義して「東京の天気は？」と聞いたところ、E4B・E2Bともに正しいJSON形式で `get_weather(location: "Tokyo")` を生成しました。
translategemmaなど従来のGemmaモデルにはこの機能がなかったため、ローカルLLMでのエージェント構築が格段にやりやすくなります。
【テスト4: 構造化出力（日本語コーチングプラン）】
最も厳しいテストとして、XMLタグ付きの複雑なプロンプトで日本語の行動計画を生成させました。
・5行の方針パート（指定フォーマット遵守）
・TODO項目5つ（「TODO: 」プレフィックス遵守）
・禁止ツールの言及なし
・250語以内の制約
E4Bはこの構造化出力を正しく生成しました。Thinking ONにすると時間帯指定まで追加され、さらに実用的な出力になりました。
【テスト5: 画像認識（スーパーのチラシ解析）】
ローカルLLMの画像認識が実用レベルかを試すため、実際のスーパーのチラシ画像を読み込ませて商品名と価格をJSON形式で抽出させました。
結果、13商品の名前と価格を正しくJSON配列で出力しました。クラウドAPI（GPT-5.4）の38商品には及びませんが、ローカルで完結する点が大きな意味を持ちます。
2週間前に同じテストをQwen 2.5 VL（8.3B）やその他のローカルVisionモデルで試した際は、タイムアウト・空応答で全滅でした。Gemma 4 E4Bは実効4.5Bと軽量なため、12GB VRAMでも安定して画像処理が完了しました。
【テスト6: 音声認識（日本語文字起こし）】
E4B/E2Bは最大30秒の音声入力にも対応しています。日本語の音声合成エンジン（AivisSpeech）で生成したWAVファイルで精度を検証しました。
既知のテキストから音声を生成し、gemma4:e4bに文字起こしさせて原文と比較した結果です。
テスト1（短文）：
原文 「東京都の人口は約1400万人です。2026年4月の桜の開花は例年より遅れています。」
結果 読点1つの差異のみ。ほぼ完璧。
テスト2（長文・金額を含む）：
原文 「フリーランスエンジニアの月収は…平均すると50万円から80万円程度…」
結果 「月収」→「日給」、「50万円」→「5万円」に誤認識。
短い文や明瞭な発話では高精度ですが、類似音（月収/日給）や数値の桁（50万/5万）で誤りが発生しました。Whisperなどの専用音声認識モデルと比べると精度は劣ります。
Thinking Modeの影響も検証しました。同じ音声をThinking ONで文字起こしすると、「月収」が「年収」に、「50万円」が「500万円」に変わりました。モデルが「年収なら500〜800万が妥当」と推論し、数字を辻褄が合うように補正してしまったのでしょう。
つまり、音声認識の精度自体はON/OFFで同じですが、Thinking ONでは推論が誤認識を増幅するリスクがあります。
テキスト生成では品質を上げるThinking Modeが、音声認識では逆効果になるという興味深い発見でした。
1つのモデルでテキスト・画像・音声を扱えるのは運用上の大きなメリットです。議事録のような正確性が求められる用途には専用モデルが適していますが、音声メモの大まかな内容把握や、他の処理と組み合わせたマルチモーダルワークフローでは十分実用的です。
【E4B vs E2B 使い分け】
・E4B（推奨）：翻訳・要約・コマンド生成・構造化出力・Function Calling。品質重視のタスク全般
・E2B：分類・タグ付け・簡単な応答生成など、速度重視のタスク。185トークン/秒の高速推論が活きる場面
迷ったらE4Bですね。
【まとめ】
Gemma 4で変わったこと。
・ライセンス → Apache 2.0で商用利用完全自由
・Function Calling → ローカルLLMでエージェント構築が現実的に
・Thinking Mode → タスクに応じてON/OFFで品質と効率を両立
・翻訳品質 → 専用モデルに匹敵する汎用モデルの登場
・構造化出力 → 4.5Bパラメータで複雑なフォーマット指示に従える
・マルチモーダル → 1モデルでテキスト・画像・音声を処理。専用モデル不要
・安定性 → ベンチマーク強者よりも実務で安定した出力
ローカルLLMの実用性が一段階上がったリリースだと感じました。特にFunction Callingのネイティブ対応は、これまでクラウドAPIに頼るしかなかったワークフローの自動化をローカルで完結させる道を開きました。
