Gemma 4 は 1 つのモデルではありません。もし 1 つだけ覚えるなら、E2B と E4B は edge ルート、26B A4B と 31B は workstation ルートだという点です。2026年4月3日時点では、この分け方がどの benchmark スクリーンショットよりも重要です。なぜなら、最初にスマホから入るのか、ノートPCから入るのか、ワークステーションから入るのか、あるいは hosted な試用面から入るのかを決めるからです。
Gemma 4 が通常の「新モデル発表」と少し違って見えるのもここです。これは抽象的に Google が次の open model を出した、という話ではありません。Apache 2.0 の下で公開された 4 モデル構成のファミリーであり、小さい枝は効率・ローカル実行・モバイル寄り、大きい枝は長いコンテキストと重いローカル推論寄りです。公開資料だけを読むと表面積が大きく感じられますが、実際に役立つ問いは 1 つです。必要なのは edge モデルか、それとも workstation モデルか。
本記事の主要な事実関係は、2026年4月3日に Google の Gemma release log、launch blog、Gemma 4 model card、Gemini Developer API pricing page、Android Developers Blog を基に確認しました。
まず決めるべきこと：どの Gemma 4 ルートから始めるか
| 実際にやりたいこと | まず見るべきもの | 理由 | 主な注意点 |
|---|---|---|---|
| オフライン、低遅延、端側、モバイル、小さめのローカルデバイス | E4B | edge 側の最も素直な default。E2B より余裕がありつつ、効率的な local use 向け | 大きい枝より context ceiling は低く、最も重い workstation reasoning には不向き |
| Gemma 4 の中で最も軽い入口 | E2B | RAM、battery、latency が本当の制約なら最も合理的 | E4B より ceiling は低い |
| ワークステーション級のローカル推論を現実的に始めたい | 26B A4B | 3.8B active parameters の MoE で、大きい枝の default 候補になりやすい | 「単純な dense 大モデル」よりプロダクトの読み方は少し複雑 |
| dense な大型モデルを明示的に選びたい | 31B | raw quality や fine-tuning の土台を重視するならこちら | 26B A4B よりハードウェア負荷が重い |
| self-hosting の前に大きい枝を試したい | AI Studio の 26B A4B / 31B | もっとも早い公式 try-now ルート | 現在の pricing page は通常の paid Gemma SKU としては見せていない |
| 端末上で audio / speech を扱いたい | E4B または E2B | native audio は小さい枝にある | 大きい枝は同じ audio ポジションではない |
最も使いやすい default recommendation は単純です。edge ハードウェアから入るなら E4B、ワークステーションから入るなら 26B A4B。 まずはこの 2 点を入口にし、最小 footprint や dense 31B が本当に必要なときだけ外していくのが実務的です。
Gemma 4 とは何か
Gemma 4 は Google の最新オープンモデルファミリーです。公式 release log では 2026年3月31日、公開 launch blog では 2026年4月2日 と記録されています。Google は Gemma 4 を Gemini 3 と並ぶ open-model 系列として位置づけていますが、だからといって「Gemini を安くした別名」という話ではありません。実際に重要なのは deployment boundary です。Gemma は自分で動かし、調整し、配備できる open-weight family であり、Gemini は Google が管理する model line です。
この違いは、読者がしている意思決定そのものを変えます。Gemini を選ぶときは、多くの場合 API 契約と価格の判断です。Gemma 4 を選ぶときは、まず deployment surface の判断です。ローカル edge モデルを回すのか、workstation 級のローカルモデルを回すのか、それとも open model を評価するための hosted try-now surface を使うのかを決める必要があります。
今回 Google は product boundary もかなり明確にしています。official model card によれば、Gemma 4 は text と image input を受ける multimodal open model family で、小さいモデルは native audio input も扱え、出力は text です。ここは launch week で誤解されやすいので、はっきり言う価値があります。Gemma 4 は 画像生成モデルでも動画生成モデルでもありません。 OCR 的理解、coding、reasoning、text-centered workflows のための open multimodal family です。
本当の分かれ目：edge モデルと workstation モデル
Gemma 4 を理解するうえで役に立つのは、「抽象的にどれが最強か」を問うことではありません。どの deployment problem をどの枝が解いているかを見ることです。
edge 枝は E2B と E4B です。official model card では、どちらも 128K context、text と image input、そして native audio input を持ちます。さらに Google の Android announcement では、この枝が AICore / 次世代 Gemini Nano の device-side path と結びついていることが示されています。つまり、これは単なる「小型版」ではなく、latency、battery、local execution、制約の強いハードウェアを重視するための枝です。
この edge 枝の中では、E4B が多くの読者にとって最も素直な default です。E2B より余裕があり、それでいて Google が on-device と AI Edge に向けて押している側にいます。E2B は efficiency-first の選択で、footprint を最優先にするときに初めて積極的に選ぶべきモデルです。
workstation 枝は 26B A4B と 31B です。両方とも 256K context に上がり、長文書、広い code context、より重いローカル推論に向いた枝になります。ここで特に面白いのは 26B A4B です。official model card では total 25.2B、inference 時の active parameters は 3.8B と説明されています。実務的には、これが workstation 側の最初の default になりやすいという意味です。長い context と強めの reasoning tier を得ながら、最大 dense モデルを最初の強制選択にしなくて済みます。
31B は dense large model です。raw な dense-model quality や dense な fine-tuning base を優先したいときには理にかなっています。ただし重要なのは、「数字が最大だから default」という読み方をしないことです。多くの local developer にとって、最初に試すべきは 31B ではなく 26B A4B です。
Gemma 3 から何が変わったのか
Gemma 4 のアップグレードは、単純に「benchmark が上がった」という話ではありません。より深い変化は、Google がこの family を使いやすい形に整理したことです。
まず、大きい枝は 256K context に達し、小さい枝は 128K を維持しています。これにより Gemma 4 は、長文書や repository-scale のローカル作業で、ただの軽量 open release よりもはるかに実用的になります。次に、launch materials と model card は native system-role support と native function-calling posture を明確に押し出しています。これは agentic / structured workflow で重要です。さらに、family の split 自体がはっきりしました。edge 側は添え物の小モデルではなくなり、workstation 側も曖昧な一枚板ではなくなりました。
能力面の伸びも実在します。official model card では、31B が Gemma 3 27B より AIME 系の数学や LiveCodeBench 系の coding でかなり強い結果を示しています。ここで大事なのは benchmark 崇拝ではなく、今回の launch が cosmetic ではないと理解することです。Gemma 4 の下には、能力の伸びと family design の改善が両方あります。
もう 1 つ大きいのが deployment posture です。Google は AI Studio を大きい枝の try-now surface に、AI Edge / Android を小さい枝の on-device route に、そして Hugging Face、Ollama、MLX、llama.cpp、vLLM を self-hosted path に置いています。要するに、Gemma 4 の価値は「賢くなった」だけではなく、どこで使うべき family なのかが前よりずっと読みやすくなったことにあります。
今どこで Gemma 4 を動かすべきか
どこで Gemma 4 を動かすべきかは、選んだ枝で決まります。
大きい枝をいちばん簡単に 試したいなら、Google の launch blog は 31B と 26B A4B を AI Studio に向けています。ローカル stack を組む前に workstation 側の感触を見るには最短の公式ルートです。ただし 1 点だけ境界を明確にしておく必要があります。現在の Gemini Developer API pricing page は Gemma 4 を free only として見せており、通常の paid managed model と同じような line item にはしていません。つまり、「今すぐ試せる」は正しい一方で、「普通の有料 Gemini API SKU のように使える」と言い切るのは現状の公開 pricing とズレます。
一方で edge 枝を見ているなら、公式シグナルは別方向です。Android Developers Blog は Gemma 4 を AICore Developer Preview と将来の Gemini Nano 4 搭載デバイスの流れに接続し、launch materials も E4B / E2B を AI Edge の流れに置いています。小さい枝は toy release ではなく、明確な on-device path として扱われています。
self-hosted local control が欲しいなら、Google の launch materials でも Hugging Face、Kaggle、Ollama、Transformers、MLX、llama.cpp、vLLM といった open-model ecosystem が強調されています。ワークステーションで Gemma 4 を回したい、ローカル coding workflow に組み込みたい、あるいは broader local stack の一部にしたいなら、ここが本筋です。次にやるべきことが local provider 設定なら、続けて読む価値が高いのは英語版の OpenClaw LLM setup guide です。
さらに production-scale deployment を考えている場合、Google はこの話を Google Cloud の方向へ寄せています。現在の pricing page からは、Gemma 4 が通常の paid hosted Gemini line item として振る舞っているとは読めません。ここも product boundary として重要です。
シナリオ別の実用的な選び方
一般的な edge default が欲しいなら、まず E4B です。Google が edge 側にかけている product investment と、ローカル multimodal use に必要な余裕のバランスがいちばん良いからです。
本当の制約が memory、battery、latency なら、E2B から始めるべきです。family 全体の default ではありませんが、footprint が何より重要なときにはもっとも正直な答えです。
workstation 級の local coding / reasoning model が欲しいなら、26B A4B が最重要の recommendation です。MoE の設計により、大きい枝に入るためにいきなり最重の dense モデルへ行く必要がありません。ローカルで coding、reasoning、長文 context を扱いたい開発者には、これが最初の評価対象として最も自然です。
raw dense-model quality や fine-tuning headroom を最優先するなら、31B へ進みます。ハードウェア予算に余裕があり、dense な大型モデルを意図的に選ぶときだけここが正解になります。
on-device audio understanding が必要なら、E2B / E4B に留まるべきです。audio support の product boundary は model card で明確に示されており、単純な parameter count よりも重要です。
まだ Gemma 4 が自分に必要か判断したいだけなら、いきなりローカル構築から入らないことです。大きい枝は AI Studio、小さい枝は Android / AI Edge preview から始めるのが合理的です。枝を決める前に local deployment を作り込むのが、いちばん無駄が大きい進め方です。
Gemma 4 が向かない場面
Gemma 4 は open weights、Apache 2.0、長い context、強い reasoning posture、明確な edge ambition など、魅力的な言葉が一度に並ぶので、過大評価されやすい側面があります。それでも、すべての人にとって最適な答えになるわけではありません。
もし本当に必要なのが 安定した managed API contract と明確な paid pricing なら、Gemma 4 は現時点で managed Gemini route ほど素直ではありません。現在の pricing page は、むしろその境界をはっきり見せている点に価値があります。この場合は英語版の Gemini API pricing guide のほうが次に読むべき内容に近いはずです。
また、欲しいものが 最強クラスの closed frontier model であり、open weights や self-hosting の運用負担を持ち込みたくないなら、Gemma 4 はそもそも探している答えではないかもしれません。Gemma 4 の強さは開放性と deployability にあり、open model と managed frontier system の境界を消すことではありません。
さらに、画像生成や動画生成 が目的なら Gemma 4 は明確に外れです。official model card が示すとおり、Gemma 4 は text と visual input を受けて text output を返す multimodal open model family であり、画像生成ラインでも動画生成ラインでもありません。
最後に持っておくべき考え方
Gemma 4 は「launch week の新しいブランド名」として見るより、2 本立ての open family として見るのが正解です。
1 本目は edge トラック。E2B と E4B で、local execution、multimodal on-device use、device-level practicality が中心です。2 本目は workstation トラック。26B A4B と 31B で、長い context と重いローカル推論が中心です。このトラックを最初に正しく選べば、Gemma 4 はかなり分かりやすくなります。逆にそこを飛ばすと、4 つのモデルがまた曖昧に見えてしまいます。
だから一番役に立つ quick answer もシンプルです。serious edge ルートなら E4B、serious workstation ルートなら 26B A4B。 さらに小さくするのは効率が本当の bottleneck のときだけ、さらに重くするのは dense 31B の代償を自覚しているときだけにしましょう。