# Gemma 4 ガイド：どのモデルを選び、どこで動かすべきか

> Gemma 4 は単一モデルではなく、4モデルから成るオープンファミリーです。実務では E2B / E4B を端末向け、26B A4B / 31B をワークステーション向けとして捉えると一気に分かりやすくなります。

- URL: https://blog.laozhang.ai/ja/posts/gemma-4-guide
- Published: 2026-04-03
- Updated: 2026-04-03
- Author: AI Free API Team (https://blog.laozhang.ai/ja/about)
- Category: AIモデルガイド
- Tags: Gemma 4, Google AI, オープンモデル, ローカルLLM, モデル選定

---
Gemma 4 は 1 つのモデルではありません。もし 1 つだけ覚えるなら、**`E2B` と `E4B` は端末向け、`26B A4B` と `31B` はワークステーション向け**だという点です。**2026年4月3日**時点では、この分け方がどの benchmark スクリーンショットよりも重要です。なぜなら、最初にスマホから入るのか、ノートPCから入るのか、ワークステーションから入るのか、あるいはオンラインの試用枠から入るのかを決めるからです。

Gemma 4 が通常の「新モデル発表」と少し違って見えるのもここです。これは抽象的に Google が次の open model を出した、という話ではありません。Apache 2.0 の下で公開された 4 モデル構成のファミリーであり、小さい枝は効率・ローカル実行・モバイル寄り、大きい枝は長いコンテキストと重いローカル推論寄りです。公開資料だけを読むと表面積が大きく感じられますが、実際に役立つ問いは 1 つです。**必要なのは端末向けモデルか、それともワークステーション向けモデルか。**

_本記事の主要な事実関係は、2026年4月3日に Google の Gemma release log、launch blog、Gemma 4 model card、Gemini Developer API pricing page、Android Developers Blog を基に確認しました。_

## まず決めるべきこと：どこから始めるか

![Gemma 4 の family split board。端末向けラインとワークステーション向けラインを比較](https://blog.laozhang.ai/posts/ja/gemma-4-guide/img/family-split-board.webp)

| 実際にやりたいこと | まず見るべきもの | 理由 | 主な注意点 |
|---|---|---|---|
| オフライン、低遅延、端側、モバイル、小さめのローカルデバイス | `E4B` | 端末向けの最も素直な標準候補。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 よりハードウェア負荷が重い |
| 自前運用の前に大きい枝を試したい | AI Studio の `26B A4B` / `31B` | もっとも早い公式の試用経路 | 現在の pricing page は通常の paid Gemma SKU としては見せていない |
| 端末上で audio / speech を扱いたい | `E4B` または `E2B` | native audio は小さい枝にある | 大きい枝は同じ audio ポジションではない |

最も使いやすい基本方針は単純です。**端末側から入るなら `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 を選ぶときは、まずどこで動かすかの判断です。ローカルの端末向けモデルを回すのか、ワークステーション級のローカルモデルを回すのか、それとも open model を評価するためのオンライン試用枠を使うのかを決める必要があります。

今回 Google は product boundary もかなり明確にしています。official model card によれば、Gemma 4 は text と image input を受ける multimodal open model family で、小さいモデルは native audio input も扱え、出力は text です。ここは誤解されやすいので、はっきり言う価値があります。Gemma 4 は **画像生成モデルでも動画生成モデルでもありません。** OCR 的理解、coding、reasoning、テキスト中心の実務のための open multimodal family です。

## 本当の分かれ目：edge モデルと workstation モデル

![Gemma 4 の model map。サイズ、context window、modalities、実運用の向き先を比較](https://blog.laozhang.ai/posts/ja/gemma-4-guide/img/model-map.webp)

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 つ大きいのが、使いどころの整理です。Google は AI Studio を大きい枝の試用先に、AI Edge / Android を小さい枝の端末側の入り口に、そして Hugging Face、Ollama、MLX、llama.cpp、vLLM を自前運用の道筋に置いています。要するに、Gemma 4 の価値は「賢くなった」だけではなく、**どこで使うべき family なのかが前よりずっと読みやすくなった**ことにあります。

## 今どこで Gemma 4 を動かすべきか

![Gemma 4 の access routes board。AI Studio、AI Edge、self-hosted runtimes、Google Cloud を整理](https://blog.laozhang.ai/posts/ja/gemma-4-guide/img/access-routes.webp)

どこで 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](https://blog.laozhang.ai/en/posts/openclaw-llm-setup) です。

さらに **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 契約と明確な paid pricing** なら、Gemma 4 は現時点で Gemini の managed ルートほど素直ではありません。現在の pricing page は、むしろその境界をはっきり見せている点に価値があります。この場合は英語版の [Gemini API pricing guide](https://blog.laozhang.ai/en/posts/gemini-api-pricing) のほうが次に読むべき内容に近いはずです。

また、欲しいものが **最強クラスの 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 は「新しいブランド名」として見るより、**2 本立ての open family** として見るのが正解です。

1 本目は **端末向けのライン**。`E2B` と `E4B` で、local execution、multimodal on-device use、device-level practicality が中心です。2 本目は **ワークステーション向けのライン**。`26B A4B` と `31B` で、長い context と重いローカル推論が中心です。このラインを最初に正しく選べば、Gemma 4 はかなり分かりやすくなります。逆にそこを飛ばすと、4 つのモデルがまた曖昧に見えてしまいます。

だから一番役に立つ quick answer もシンプルです。**端末向けを本気で見るなら `E4B`、ワークステーション向けを本気で見るなら `26B A4B`。** さらに小さくするのは効率が本当の bottleneck のときだけ、さらに重くするのは dense `31B` の代償を自覚しているときだけにしましょう。