Gemma系を1から解説 — 系譜・特徴・使いどころ

GoogleのオープンウェイトLLM「Gemma」を系譜から解説。蒸留・局所注意・実効パラメータという各世代の発明、ライセンスの実務注意、Ollamaでのローカル運用までを1本で通す。

Gemma: Open Models Based on Gemini Research and Technology

レストランとパンの配布 — オープンウェイトとは何か

ChatGPTやGeminiは「レストラン」です。おいしい料理（回答）は出てきますが、厨房には入れず、レシピも持ち帰れません。閉店（サービス終了や値上げ）したら、それまでです。

Googleが2024年から続けているGemmaは、これに対して「焼き上がったパンの配布」に近いモデルです。レシピ（学習データと学習手順）は非公開でも、パンそのもの＝学習済みの重みは自分のPCに持ち帰れます。切って使っても（推論）、生地から焼き直しても（微調整）、自分の店で出しても（製品への組み込み）かまいません。こういう配り方のモデルをオープンウェイトモデルと呼びます。

GemmaはGeminiと同じ研究・技術から派生した「弟分」のシリーズで、2024年の初代から2026年のGemma 4まで、ほぼ1年に1世代のペースで進化してきました。この記事では系譜を順に追いながら、各世代で何が発明されたのか、見落とすと事故になるライセンスの話、そしてOllamaを使った手元での実運用までを通して解説します。

前提: 「7B」の読み方とファミリーという考え方

LLMの名前に付く「2B」「7B」はパラメータ数です。Bはbillion（10億）で、7Bなら「調整可能な数値が70億個入った巨大な関数」を意味します。手元で動かせるかは、この数を1個あたり何バイトで持つかで決まります。16bit（2バイト）なら7Bで約14GB、4bitまで圧縮（量子化）すれば約3.5GB＋α。つまり メモリ ≈ パラメータ数 × 1パラメータのバイト数 という掛け算だけで、必要メモリの当たりが付きます。

「ファミリー」とは、同じ設計思想と学習パイプラインから作られたサイズ違い・用途違いの兄弟たちのことです。同じ世代内ではトークナイザや作法が共通なので、小型で試して大型に差し替える、といった乗り換えが楽になります。

第1世代: Gemma 1（2024年）— 参入と土台

初代Gemmaは2024年2月に2Bと7Bの2サイズで公開されました。中身はAttention機構を積み重ねた標準的なデコーダ型Transformerで、文脈長は8Kトークン。当時すでにMetaのLlama系がオープンウェイト市場を先行しており、Googleが「Geminiの技術で作った小型・高品質モデル」で参入した、という位置づけです。

このとき確立した約束事は今も続いています。各サイズにbase版（続きを予測するだけの素の状態）とinstruct版（-itが付く、指示に従うよう追加調整済み）の2種類があること。チャットに使うのは必ず-it側です。また本流とは別に、コード特化のCodeGemma、画像＋言語のPaliGemmaなど、派生ブランチが横に生える構図もここから始まりました。

第2世代: Gemma 2（2024年）— 蒸留という発明

2024年6月、Gemma 2が27Bと9Bで登場します（後に2Bも追加）。最大の特徴は、小型モデルを知識蒸留（knowledge distillation）で学習したことです。

蒸留を比喩で言うと、過去問と模範解答（正解1つ）だけで独学する代わりに、家庭教師の「迷い方」まで教わる勉強法です。通常の学習では「次の単語はcatが正解」という1点だけを教えますが、蒸留では大型の先生モデルが出す確率分布——「catが70%、kittenが20%、dogが5%…」——を丸ごと真似させます。正解以外への確率の割り振り方にこそ、先生の知識が詰まっているからです。

この「分布のなだらかさ」を制御するのが温度$T$です。

式(1)の$z_i$はモデルが出す生のスコア（ロジット）、$T$が温度です。$T=1$が素のsoftmax、$T$を大きくすると全スコアが縮んで差が付きにくくなり、分布は平らになります。つまり式(1)は、候補ごとのスコアを温度で割り、$\exp$に通して負の値をなくし、最後に全部の合計で割って合計が1になるよう揃え直す——要するに百分率に直す——という手順を書いたものです。先に大きな$T$で割るほど1位と2位の差は縮んでから比べられるので、これは「モデルの自信が下がる」と同じことを言っています。蒸留では$T$を上げて先生の分布を「ならして」から真似させることで、2位以下の候補に込められた情報まで生徒に流し込みます。

蒸留の効果は「同じサイズでより賢い」に直結します。小型モデルが生データから独学するより、大型モデルが咀嚼した分布から学ぶ方がサンプル効率が良い——Gemma 2の2B/9Bはこの路線で、サイズの割に強いモデルという評判を作りました。

もう一つの発明が注意機構の省エネ化です。Gemma 2は、文全体を見渡す全域注意と、近所の窓の中だけを見る局所注意（スライディングウィンドウ）を層ごとに交互に配置しました。全部の層で全文を見渡すのは贅沢すぎる、という割り切りです。

第3世代: Gemma 3（2025年）— 目を持ち、長文を読む

2025年3月のGemma 3は1B・4B・12B・27Bの4サイズ構成で、変化が最も大きい世代です。

目が付いた。 4B以上はSigLIPという画像エンコーダを内蔵し、画像を入力できるマルチモーダルモデルになりました。派生のPaliGemmaで実験していた路線が本流に合流した形です。

文脈が8Kから128Kへ。 1Bを除き、一度に読める長さが16倍になりました。これを可*能にしたのが局所注意の徹底です。Gemma 2で1:1だった局所と全域の比率を5:1まで局所に寄せ、KVキャッシュ——過去トークンの中間結果を貯めておくメモリ——の膨張を抑えています。全域注意のコストは文脈長の2乗で伸びるので、長文対応とは本質的に「2乗の曲線からどう逃げるか」の勝負です。

もう一つ実務に効いたのが、QAT（量子化を見込んだ追加学習）済みチェックポイントの公式配布です。4bit化はふつう品質を削りますが、量子化されることを前提に追加学習した公式版が出たことで、「手元の4bit運用」の品質底上げが公式にサポートされました（量子化の仕組みはLLM量子化を1から解説で詳述しています）。

第3.5世代: Gemma 3n — 「実効パラメータ」の登場

同じ2025年には、スマホ・エッジ向けのGemma 3nが出ます。ここで初めてE2B / E4Bという奇妙なサイズ表記が登場しました。Eはeffective（実効）の意味です。

仕掛けはマトリョーシカ人形に例えられます。大きい人形（総パラメータ）の中に小さい人形（実効パラメータ）が入れ子になっていて、メモリが苦しい端末では内側の小さいモデルだけを動かせる設計（MatFormer）です。総パラメータは5B超でも、メモリと計算の振る舞いは2B相当——それがE2Bという表記の意味です。音声入力への対応もこの系統から始まりました。

第4世代: Gemma 4（2026年）— E系が主力に、ライセンスも転換

2026年3月末に公開されたGemma 4は、3nで実験した実効パラメータ路線を主力に昇格させました。小型はE2B・E4B、大型には一部のパラメータだけを使うMoE（専門家混合）構成が並び、「総パラメータで名乗り、実効コストで動く」世代です。そしてもう一つの大きな転換が、次節で述べるライセンスのApache 2.0化です。

筆者の環境（M1 Max・メモリ64GB）でも、OllamaのE4B（4bit量子化で約10GB）を常用しています。体感として日本語の応答は自然で、JSON形式の出力指示も安定しており、社内ツールのAPIフォールバック先として実戦投入できる水準です。

ライセンス — 「オープン」の中身を確認する

ここは飛ばすと事故になる節です。Gemma 1〜3のライセンスは、Apache 2.0やMITのような標準オープンソースライセンスではありません。「Gemma利用規約（Gemma Terms of Use）」という独自ライセンスで、商用利用は可能ですが、(1)禁止用途ポリシーの遵守、(2)モデルや派生モデルを再配布するとき同じ利用制限を下流にも課す義務、が付きます。つまり自社製品にGemma 3を同梱して配る場合、その製品のユーザーにもGoogleの利用条件が及びます。OSI定義の「オープンソース」ではなく「オープンウェイト」と呼び分けられるのはこのためです。

Gemma 4はここが変わり、Apache 2.0——再配布・改変が自由で特許条項も持つ、ソフトウェア業界標準のライセンス——で公開されました。製品同梱や再配布のハードルは大きく下がっています。ただし世代によってライセンスが違う以上、「Gemmaだから大丈夫」ではなく使う世代の条文を確認するのが正しい姿勢です。モデルの生成物の扱いと、微調整に使う自社データの権利は、モデル本体のライセンスとはまた別の論点として残ることにも注意してください。

手を動かす: Ollamaでローカル運用

ローカル運用の最短ルートはOllamaです。導入から起動までは2行で済みます。

brew install ollama          # macOSの場合。他OSは公式サイトから
ollama run gemma3:4b         # 初回は自動ダウンロード→対話開始

タグでサイズと変種を選びます。gemma3:27bのようにサイズを変える、gemma3:4b-it-qatのようにQAT版を指す、世代を変えてgemma4:e4bを試す、という具合です。設定はModelfileに書きます。

# Modelfile
FROM gemma3:4b
PARAMETER temperature 0.7    # 出力の多様性（式(1)のTそのもの）
PARAMETER num_ctx 32768      # 文脈長。既定値はモデル上限よりずっと短い

temperatureは式(1)の$T$が生成時のサンプリングに転用されたもので、下げるほど堅実に、上げるほど多様になります。最重要なのがnum_ctxです。Ollamaはメモリ節約のため、モデルの上限（Gemma 3なら128K）よりはるかに短い文脈長を既定にしています。長い文書を貼り付けても、超過分は警告なく切り捨てられる——「読ませたはずの前半をモデルが知らない」というローカルLLM最頻出のトラブルはここが原因です。

HTTP APIとして使う場合はOLLAMA_HOST=0.0.0.0で外部からの接続を受け付けられますが、Ollamaには認証機構がありません。公開ネットワークに素で晒さず、トンネルやリバースプロキシの内側に置くのが原則です。

現場ではこう使う

どの職種が、いつ使うか。 典型は3つです。①バックエンド/プロダクト開発者が、個人情報や社外秘を含むデータを外部APIに送らずに処理したいとき（ローカル推論なら データが手元から出ない）。②商用APIのコスト・レート制限・障害へのフォールバック先として（筆者の実運用がまさにこれで、API障害時にOllama→商用APIの順で試す構成にしています）。③モバイル/組み込みエンジニアが端末内推論を仕込むとき——3n/4のE系はこの用途のために生まれています。

実際に触るもの。 ollama pull/run、Modelfileのnum_ctxとtemperature、API公開時のOLLAMA_HOST/OLLAMA_ORIGINS、Hugging Faceでの-itとbaseの選択、QATタグ。この記事の用語がそのままパラメータ名です。

知らないと事故になる落とし穴。

• base版をチャットに使う: 指示に従わず文章の続きを書き始めます。会話用途は必ず-it。
• num_ctxの既定値: 前述の通り、長文が黙って切り捨てられます。RAGで文脈を詰め込む構成では真っ先に疑う場所です。
• 世代とライセンスの取り違え: Gemma 1〜3の再配布には利用条件の伝播義務があります。製品同梱・社外配布の前に、使っている世代の条文確認を。
• 量子化の削りすぎ: 4bitより下に落とすと、英語より先に多言語の自然さとJSONなどの構造化出力が壊れがちです。日本語品質が要件なら量子化を1段戻して比較を。

面接で問われたら。「なぜGemma 2は蒸留を使ったのか」——小型モデルが生データから独学するより、大型モデルの出力分布（正解以外への確率の割り振り＝式(1)を温度でならしたもの）を真似る方がサンプル効率が良いから、が筋道です。ここまで読んだあなたは式付きで答えられます。

まとめ — 系譜は「制約との戦い」の記録

• Gemma 1: オープンウェイト参入。base/-itの作法と派生ブランチの構図を確立
• Gemma 2: 蒸留で「サイズの割に賢い」を実現。局所×全域注意の省エネ化が始まる
• Gemma 3: 画像入力と128K文脈。局所5:1とQAT公式配布で「手元で動く」を本気でサポート
• Gemma 3n → 4: 実効パラメータで端末内へ。ライセンスはApache 2.0へ転換

各世代の発明は、どれも「メモリと計算の制約の中でどれだけ賢くできるか」への回答でした。その制約の正体——注意機構の2乗コストとKVキャッシュ——を深掘りしたい方は、Attention機構を1から理解するとKVキャッシュを1から解説へどうぞ。