Google Gemma 4 Launchとは何か
本記事では、Google DeepMindが公開したオープンウェイトモデル群「Gemma 4」の発表について解説する。結論から言うと、Gemma 4の重要点は単なる性能向上ではない。Googleが、端末寄りの小型モデルと、ローカル実行しやすい高性能モデルを同じファミリーとして切り分けて出し直したことに意味がある。
公開資料を見ると、Gemma 4はE2B、E4B、26B A4B、31Bの4モデルで構成される。小さい2モデルはモバイルやエッジ寄り、大きい2モデルはコンシューマーGPUやワークステーション寄りという役割分担が明確だ。つまりGoogleは、Geminiのようなクラウド中心の高機能モデルとは別に、「手元のハードウェアでどこまでできるか」を重視する開発者向けの選択肢をさらに厚くしたと見てよい。
公式発表はGoogle公式ブログ、技術概要はGoogle AI for DevelopersのGemma 4 overview、詳細仕様はGemma 4 model cardで確認できる。発表直後からKaggle、Hugging Face、Ollama、LM Studioなどでも扱われている。
何が起きたのか / 何が発表されたのか
Gemma 4は、Google AI for Developersのリリース一覧では2026年3月31日付、Google公式ブログでは2026年4月2日付で案内されている。日付表記に少し差はあるが、2026年3月末から4月初旬にかけてGemma 4ファミリーが一般公開されたと理解すればよい。
今回の発表で重要なのは、モデルサイズだけでなく設計思想が分かれていることだ。E2BとE4Bは「effective parameter」を掲げる軽量系で、音声入力にも対応する。26B A4BはMixture of Experts構成で、総パラメータは大きいが推論時に使うアクティブパラメータを絞り、速度と推論効率を重視する。31BはDense構成で、品質重視の中心モデルという位置づけだ。
機能面では、最大256Kコンテキスト、可変解像度の画像理解、thinking mode、ネイティブのfunction calling、system role対応、構造化出力を含むエージェント向け機能が前面に出ている。GoogleはGemma 4を、単なるチャットモデルではなく、コード生成、マルチステップ推論、ツール利用、視覚理解を含む「agentic workflows」向けのオープンモデル群として打ち出している。
また、Gemma 4はApache 2.0で公開されており、商用利用を含む実装の自由度が比較的高い。これは、試験導入だけでなく、社内ツールや自社製品への組み込みを検討する企業にとって大きい。Gemma系が「研究用の軽量モデル」から「実運用も見据えたオープンモデル」へ一段進んだと受け止める理由はここにある。
背景
この発表が注目される理由は、オープンウェイトモデルの競争軸が変わってきたからだ。以前は「どのベンチマークで強いか」「何Bモデルでどこまで出るか」が主戦場だったが、2025年後半以降は、長文コンテキスト、マルチモーダル、エージェント機能、ローカル実行の現実性がより重要になっている。
前世代のGemma 3は、128Kコンテキスト、140超の言語、テキストと画像への対応、function callingを備え、「単一GPUやTPUでも扱いやすい高性能オープンモデル」として位置づけられていた。Gemma 4はそこから一歩進み、より長いコンテキスト、thinking mode、より明確なハードウェア別のラインアップ、そして小型モデルでの音声入力対応まで含めて再設計されている。
GoogleにとってGemma 4は、Geminiと競合する存在ではなく補完関係にある。Google自身も、GemmaをGemini由来の研究・技術をもとにしたオープンモデル群として説明している。つまり「最高性能はクラウドAPIで、制御性やローカル性はGemmaで」という二層構えが、Googleの開発者向け戦略として見えやすくなった。
この技術・製品・サービスで何ができるようになるのか
Gemma 4で分かりやすく変わったのは、「今までローカルでやりにくかったこと」を、用途別に現実的な構成で選べるようになった点だ。
まず、小型のE2BとE4Bは、テキストと画像だけでなく音声入力にも対応する。これにより、端末上での簡易音声アシスタント、現場端末での音声付き入力、オフライン寄りのマルチモーダル処理といったユースケースが広がる。Googleはこれらを、スマートフォン、Raspberry Pi、Jetson Nanoのようなエッジ環境でも近いレイテンシで動かす方向を強く打ち出している。
次に、26B A4Bと31Bでは、ローカルなコーディング支援や長文ドキュメント処理がかなり現実的になる。256Kコンテキストがあるため、長い仕様書、複数の資料、ある程度大きいコードベースを一度に渡して推論させやすい。特に26B A4BはMoE構成により、総パラメータの大きさに比べて推論時の負担を抑える考え方が採られており、「31Bほど重くはしたくないが、小型モデルでは物足りない」という層に向く。
さらに、ネイティブのfunction callingやsystem role対応は、実務では意外に効く。従来は、オープンモデルを業務フローに組み込む際、外側のアプリケーションで無理にJSON整形をさせたり、曖昧なプロンプトで役割制御をしたりする場面が多かった。Gemma 4では、その部分がより正式な機能として整理されたため、問い合わせ分類、社内検索、コード補助、端末操作支援のようなエージェント型実装を組みやすい。
画像理解の面でも、単に「画像が読める」ではなく、可変解像度と可変アスペクト比に対応したことが実務向きだ。スクリーンショット、チャート、UI、PDF由来の画像、帳票のように形がまちまちな入力を、用途に応じた解像度で扱いやすい。これはOCRや図表理解の実装に効くが、もちろん精度は入力品質や推論設定に左右されるため、万能と考えない方がよい。
既存競合との比較
Gemma 4を評価するうえで重要なのは、単純な「最強かどうか」ではなく、どのハードウェア帯と用途を狙っているかを見ることだ。ここでは既存競合として、MetaのLlama 4 Scout、Mistral Small 4、そして前世代のGemma 3を比較対象にする。
| モデル | 主な特徴 | 向いているケース | 向いていないケース |
|---|---|---|---|
| Gemma 4 | 4サイズ構成。E2B/E4Bは音声対応の軽量系、26B A4BはMoE、31BはDense。最大256Kコンテキスト。 | 端末向けからワークステーション向けまで、同じ系統で選びたい。ローカル実行、視覚理解、コード補助、エージェント実装を両立したい。 | 単一モデルで超長大コンテキストだけを最優先したい場合。最高性能をクラウドAPIで即利用したい場合。 |
| Llama 4 Scout | Metaは公式に、ネイティブマルチモーダルでsingle H100効率、10Mコンテキストを打ち出している。 | 非常に長いコンテキストを重視するサーバー寄りの用途。画像と長文を同時に扱う大規模ワークロード。 | モバイルや超軽量端末での段階的展開。小型モデルまで同じファミリーで揃えたい場合。 |
| Mistral Small 4 | Openモデル。256kコンテキスト、119B total / 6.5B activeのハイブリッド構成。推論、コーディング、マルチモーダルを1つに統合。 | APIと自己ホストの両方を見据えつつ、統合型の小〜中規模オープンモデルを探している場合。 | 音声対応の超軽量エッジモデルまで同じブランドで揃えたい場合。端末最適化を最重視する場合。 |
| Gemma 3 | 128Kコンテキスト、画像理解、140超言語、function calling対応。単一GPUで扱いやすい路線を強調。 | Gemma系の既存資産を維持しつつ、比較的軽めの運用を続けたい場合。 | 音声入力、小型モデルのオンデバイス強化、256Kクラスの長文処理を求める場合。 |
価格、性能、用途、導入しやすさ、将来性、安全性の観点で整理すると、Gemma 4の強みは「サイズ戦略の分かりやすさ」と「ローカル寄りの実装現実性」にある。Llama 4 Scoutは超長文文脈の魅力が大きく、Mistral Small 4は統合型の設計が魅力だが、Gemma 4はE2B/E4Bと26B/31Bの役割分担が明快なため、導入計画を立てやすい。
一方で、純粋な最大性能だけを見れば、用途によっては他の大型オープンモデルやクラウドAPIに分がある可能性もある。Google自身もGemma 4をGeminiと補完関係で説明しており、「何でもGemma 4で置き換える」より、「どこまでをローカルに寄せたいか」で選ぶ方が実態に合う。
懸念点・注意点
第一に、Gemma 4は“オープン”ではあるが、導入コストがゼロになるわけではない。31Bや26B A4Bはローカル実行に向くとはいえ、実際には相応のGPUメモリや推論環境が必要になる。GoogleはコンシューマーGPUやワークステーションを想定しているが、ノートPCや一般的な軽量端末で快適に回せる範囲は、主にE2B/E4Bだと見ておいた方が安全だ。
第二に、音声対応は全サイズではない。Gemma 4の音声入力はE2BとE4Bにネイティブ対応している一方、26B A4Bと31Bはテキストと画像が中心だ。したがって「大きいモデルほど何でもできる」と単純に考えると設計を誤る。
第三に、ベンチマークの読み方にも注意がいる。GoogleはArena系や各種ベンチマークで強い数値を示しているが、評価日は固定されており、thinking modeの有無や比較対象の設定によって見え方は変わる。公開直後の数値は参考になるが、実運用で重要なのは自社データ、自社UI、自社ツールと組み合わせたときの安定性だ。
第四に、アプリケーション安全性は別途設計が必要になる。GoogleはGemma 4について高い安全性と信頼性を強調しているが、オープンモデルを自社運用する以上、入力制御、出力検査、権限制御、ログ監査まで含めて考えなければならない。特にエージェント用途では、function callingが強力であるほど誤動作時の影響も大きくなる。
最後に、現時点で不明な点もある。たとえば、各端末クラスにおける実効速度やバッテリー影響、実アプリでの音声性能のばらつきは、公式情報だけでは十分に読み切れない。ローンチ直後のため、今後はコミュニティ実測や各種ランタイムの最適化状況も見ていく必要がある。
よくある質問
Gemma 4はGeminiの代わりになりますか？
完全な代替というより、用途が違う。GeminiはGoogleのクラウド中心の先端モデル群で、Gemma 4はオープンウェイトで調整・自己ホストしやすいことが価値だ。社内環境での制御性やローカル処理を重視するならGemma 4の意義は大きい。
どのサイズを選べばよいですか？
スマートフォン、エッジ端末、軽量なローカル実行を優先するならE2BまたはE4Bが候補になる。コード支援、長文処理、ローカルRAG、視覚理解をより高品質で回したいなら26B A4Bか31Bを検討したい。まずは用途より先に、使えるハードウェア帯を決めるのが失敗しにくい。
Gemma 4は音声入力に対応していますか？
対応しているが、ネイティブ音声入力はE2BとE4Bが中心だ。26B A4Bと31Bはテキストと画像が主な入力になる。音声重視なら小型モデル側から検討した方がよい。
Gemma 4は商用利用できますか？
Googleのドキュメントでは、Gemmaはオープンウェイトで責任ある商用利用を認めるとされ、Gemma 4のモデルカードではApache 2.0ライセンスが示されている。実際に製品へ組み込む際は、ライセンス本文と利用条件を自社法務と一緒に確認したい。
Gemma 4はローカルPCで画像入力も使えますか？
使える。Gemma 4は全モデルで画像入力に対応しており、可変解像度の扱いも特徴の1つだ。ただし、画像を含む長文推論はテキストのみより重くなるため、快適さはGPUやランタイムに左右される。
まとめ
GoogleのGemma 4 Launchで本当に重要なのは、「Googleがまたオープンモデルを出した」という事実そのものではない。端末寄りの軽量モデルと、ローカル高性能モデルを1つのファミリーとして整理し、エージェント、視覚理解、コード、長文処理まで実務寄りに広げたことが本質だ。
特に注目すべき読者は、ローカルLLMを検討している開発者、社内データを外部APIに出しにくい企業、音声や画像を含むオンデバイス体験を作りたいプロダクト担当者だ。逆に、最高性能だけをすぐ使いたいなら、Geminiを含むクラウドAPIの方が合うケースも多い。
今後の見どころは、E2B/E4Bの実機性能、26B A4Bの実運用での速度と品質のバランス、そして各種ランタイムでの最適化がどこまで進むかだ。Gemma 4はベンチマークだけでなく、「どのハードウェアで、どんな体験を成立させるか」という現場の問いに対して、かなり具体的な答えを出し始めたモデル群だと言える。
