Googleが今回Gemma 4を公開した（1）

この記事群は3つの記事に分けて書きました。現在の記事では、リリース情報、モデル名、プロトコルを明確に説明します。次の記事では Googleが今回Gemma 4を公開した（2）：RTX 3060 12GBでローカル実行してみた、真の現実的なのは26B A4B を書きます。そして最後の記事では Googleが今回Gemma 4を公開した（3）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのかで締めくくります。

まず、今回具体的に何がリリースされたのかを明確にしましょう

昨年の Gemma 3 は 2025年3月12日にリリースされ、今回の Gemma 4 は 2026年4月2日と、確かに約1年空いています。しかし、今回は「27Bの次は何だろう」という考え方で探すのはやめましょう。公式が提示した主要な4つのサイズは、もはや単に総パラメータ数で区分けされているわけではありません。 | E2B | Dense | 2.3B effective，5.1B 含 embeddings，128K context | デバイス側、超軽量ローカル |

今回、結局何を発行したのかを明確にする

モデル名	構造	主要な数値	代表的なユースケース
`E4B`	Dense	有効パラメータ 4.5B、埋め込み込み含む 8B、コンテキスト長 128K	元の 4B の小型モデルをメインラインとして展開

今回到底发布了什么说清楚

モデル名	構造	主要な数値	代表的なユースケース
`26B A4B`	MoE	合計 25.2B、アクティブ約 3.8B、コンテキスト 256K	コンシューマー向けGPU、ローカルデプロイメント、品質と速度の両立

まず、今回具体的に何を出したのかを明確にする

モデル名	構造	主要な数値	代表的なユースケース
`31B`	Dense	30.7B dense、256K context	最高性能の追求、ランキングでの優位性、より安定した品質

今回、結局何を出したのかを明確にする

表面だけを見ると、今回のネーミングはより混乱していると感じるかもしれません。しかし実際は混乱しているのではなく、Googleが意図的に3つの異なるアプローチに分割しているのです：

小規模モデル・デバイス側向けに E2B / E4B を提供
ローカルプレイヤー路線として 26B A4B を提供
品質と上限を重視した路線として 31B を提供これが、多くの人が最初に「以前の馴染んだアップグレードパスが途切れた」と感じる理由です。アップグレード版を提供していないわけではなく、Googleはもはや総パラメータ数という単一の次元だけで製品を売りたいわけではないのです。

「E」と「A」は今回、装飾文字ではありません

このモデル名の中で、最も誤解を招きやすいのが E4B と A4B です。 E2B や E4B に含まれる E は、公式では effective parameters（実効パラメータ）を指します。これら2つのモデルは Per-Layer Embeddings を使用しているため、総パラメータ数と真の有効パラメータ数が同じ基準ではありません。平たく言えば、Googleは「これは過去のような『単なる 4B の密なモデル』ではない」と注意喚起しています。一方、26B A4B に含まれる A は active parameters（アクティブパラメータ）を指します。総容量は 25.2B ですが、各トークンで実際に活性化するのは約 3.8B です。これがMoE（Mixture of Experts）の鍵であり、モデル全体のサイズは大きいものの、実行時に実際に計算に参加する部分はかなり小さいということです。そのため、この2つの名前はどちらも「4B」を含んでいますが、その意味合いは全く異なります。

E4B は小規模モデルのメインラインです。
26B A4B は大規模なMoEであり、ローカル推論時には「アクティブな規模が約 4B 程度」というイメージに近いです。この命名規則は当初は確かに不自然ですが、過去のものよりも実際のデプロイ体験により近くなっています。

以前 Gemma 3 を使っていた場合、今回どういう対応関係で探せばいいか

私が思うに、この世代で最も誤解しやすいのは、これを Gemma 3 の線形なアップグレードだと捉えてしまう点です。

使用する習慣から考えると、だいたい以下のように理解できます：

これまで 4B で軽いタスクを動かしていた人は、まずは E4B を見てください。
これまで 27B でモデルの限界値を見ていた人は、今度は 31B を見てください。
これまでコンシューマー向けのグラボで「十分強力だけど、完全に動かせなくなるほどではない」というバランス点を探していた人は、重点的に 26B A4B を見てください。

この部分を先に整理しておかないと、後からローカルにデプロイする際に非常に迷いやすいです。「いつものアップグレード版がないな」と文句を言いながら、実際自分に合っているモデルを見逃してしまう可能性があります。

今回最も価値のあるアップデートは、実はパラメータではない

今回「ようやく腑に落ちた」と感じさせたのは、ランキングではなくプロトコル（ライセンス）でした。以前のバージョンの Gemma の利用規約が全く使えないわけではありませんが、ずっとどこか引っかかる部分がありました。特に以下のようなことを気にされている場合：

再配布
蒸留や二次加工を行う
モデルを自社の製品ラインに組み込む
商用展開を行うといった場合、常にライセンス条項内の通知（notice）、下流利用の制限、付帯する契約などをどう処理すべきかを確認する必要がありました。 Gemma 4 が今回直接 Apache 2.0 に変更されたことで、状況が非常にクリアになりました。核となるメッセージは極めて明確です：
商用利用が可能である
改変が可能である
再配布が可能である義務は主に、ライセンス、通知（notice）、改変の説明といったオープンソースの世界で馴染み深いものに留まるというものです。つまり、Googleが今回単にモデルをオープンソースにしたのではなく、「皆が安心して使えるかどうか」という点まで含めて整備してくれたのです。

コミュニティからの初期評価は、基本的に2つのラインに集約される

最初の週の口コミだけを見ると、大まかに2つの声があります。

1つ目のラインは、「31B は確かに実力がある」というものです。公式が発表したスコアは非常に強力です。Arena AI のテキストランキングでは、31B がリリースされた時点でオープンソースモデルの上位にランクインし、LiveCodeBench v6 でも Gemma 3 27B よりかなり向上しています。多くの人が最初に抱く感想は、「このサイズでこれだけの性能が出せるのは、期待を上回っている」というものです。

2つ目のラインは、「26B A4B はローカルユーザーのための生命線のようなものだ」というものです。一見して最も華やかなフラッグシップモデルというわけではありませんが、非常に現実的です。特にデータセンターではなく、コンシューマー向けのグラフィックボードやワークステーション、さらには古いマシンで動かす場合、ローカルでの体験はむしろこのラインに落ち着きやすいのです。

もちろん、最初の口コミには非常に現実的な前提があります。それはエコシステムがまだ追いついている最中だということです。テンプレート、量子化、推論フレームワーク、フロントエンドツールなど、多くのものがまだ完全に追いついていません。そのため、現段階で目にするレビューは、以下の2つのレイヤーに分けて見るのが最善です。

モデル本体: 今回は確かに大きな進歩があった
ローカル体験: 今後もツールの成熟度に影響され続けるだろう

第1回の結論について

単に今回のGoogleが何を発表したのかを知りたいだけであれば、一言で十分です。「Gemma 4」は、「小さいものから大きいものまで並べる密度の高いモデル」という古い考え方ではなく、デバイス側、ローカルデプロイ、品質の上限という3つの道を分離しました。「E4B」、「26B A4B」、「31B」と名前は奇妙ですが、背後にあるのは非常に現実的なデプロイメントの分業です。しかし、もし私に今回の最大の変化は何だと尋ねられたら、やはりこの判断になります。パラメータでも、ベンチマークスコアでもなく、Googleがようやく「Gemma 4」を皆がより安心して使えるオープンソースライセンスに組み込んだことです。この一歩こそが、表の数字以上に重要です。次の記事では、発表会の論調は語らず、直接ローカルマシンに戻ります。やはりアップグレードされていない「RTX 3060 12GB」を使い、なぜ私が最初に注目したのは「31B」ではなく「26B A4B」だったのか、という点です。

参考資料

作成上の注記

元のプロンプト

$blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルでのデプロイを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GBのNVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関するレビューを検索してください。重要な点として、今回のGoogleによる更新でモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものです。昨年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図した「罠」を理解していました。コンソールでの五芒星の出力は非常に厄介なので、直接アスキーアート（文字）としてハードコーディングし、コンソールに直接出力しました。原文は以下の通りです：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑であるため（座標変換やピクセル充填が関わる）、最も古典的で視覚効果が高い方法はアスキーアート（文字芸術）を使用することです。」私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画することに成功したのです。以前はローカルでの翻訳タスクにGemma4をよく使っていました。現在ブログにある多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。同時にフォーラムを閲覧し、私は「VRAMが不足している場合、モデルパラメータを上げると、生成トークンの速度が急激に低下する」ということに気づきました。なぜそうなるのか説明してください。Macではこの問題は発生しません。統一メモリを使用しているため、技術的な理由を説明してください。また、もし速度が必要な場合は、やはりNVIDIAのVRAM大容量のグラフィックボードが必要です。Macのソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。

ライティングの骨子まとめ

第1の記事では、「今回具体的に何がリリースされたのか」と「プロトコルがなぜ重要なのか」を明確に伝えることに専念し、ローカル体験に関する話題は取り上げないようにする。
モデルラインナップの説明は、まずモデル群を分解してからアルファベットの意味を説明するという順序にし、前回のバージョンよりも論理的な流れを重視する。
プロトコルに関する部分は、「今回緩和されたのはパラメータではなく、利用制限である」という判断軸を維持する。
コミュニティの評価については、まとめに留め、ローカル体験に関する記述は過度に盛り込まないようにする。