Google Gemma 4 登場——「Apache 2.0」というライセンス選択がモデル性能より重要な理由

この記事のポイント

2026年4月2〜3日、Googleはオープンモデルファミリー「Gemma 4」を発表した。Google Cloud Nextの場で公開されたこのモデルは、2B・4B・26B・31Bの4サイズ構成でスマートフォンからクラウドまでをカバーする。技術的な進化は確かに目を引く。しかしビジネスの文脈で最も注目すべきは、採用されたライセンスだ——Apache 2.0。

この一点が、企業のAI戦略に与える影響は、ベンチマークスコアの差分より大きいかもしれない。

まずGemma 4とは何か

Gemma 4はGoogleの最新プロプライエタリモデル「Gemini 3」と同じ技術基盤から派生した、オープンウェイトモデルのシリーズだ。4つのモデルは用途に応じて設計が分かれている。

E2B・E4B（エッジ向け） はスマートフォン、Raspberry Pi、IoTデバイスを対象に設計された。コンテキストウィンドウは128Kトークンで、テキストに加えて画像・動画・音声入力に対応する。

26B MoE（Mixture of Experts） は少し特殊な構造をとる。パラメータ総数は260億だが、1回の推論で実際に動くのは約38億分だけだ。128個の小さなエキスパートのうち、一度に8つ（＋共有1つ）だけが活性化する設計で、計算コストを大幅に抑えつつ品質を維持する。Arena AIリーダーボードでは全オープンモデル中6位に位置する。

31B Dense はフルサイズのモデルで、同ランキング3位。NVIDIA H100（80GB）1枚に乗る設計で、量子化版なら一般向けGPUでも動く。数学推論ベンチマーク「AIME 2026」で89.2%、コーディングベンチマーク「LiveCodeBench v6」で80.0%を記録している。

すべてのモデルに共通するのは、マルチモーダル対応、256K（大型モデル）のコンテキストウィンドウ、ファンクションコーリングの標準搭載、140以上の言語への対応だ。

「Gemma税」が消えた日

率直に言って、Gemma 3までのライセンスは企業にとって扱いにくかった。

Gemma 1・2・3は独自ライセンスで提供されていた。商用利用には制限があり、月間アクティブユーザーが一定数を超えると追加条件が発生した。Googleが「終了権限（termination rights）」を持つ条項もあり、長期的なビジネス継続に関するリスクを内包していた。

法務担当者にとってこれは「確認が必要な案件」になる。LLMを使った新製品を出そうとするたびに、ライセンス条件を精査して、用途が適法か確認して、上長に承認を取る——というプロセスが発生する。これは金銭的コストというより、意思決定の速度を下げる摩擦だ。

Gemma 4が採用したApache 2.0は、その摩擦を取り除く。

Apache 2.0には月次アクティブユーザー制限がない。商用製品への組み込みは自由で、ファインチューニングした派生モデルの再配布も問題ない。ライセンスの解釈をめぐる社内レビューが不要になり、「使っていいかどうか確認する時間」が「どう使うかを設計する時間」に変わる。

Llama 4との決定的な差

タイミング的に比較しないわけにはいかない。MetaはGemma 4の直後、Llama 4をリリースしている。

Llama 4は「コミュニティライセンス」を採用している。月間アクティブユーザーが7億人を超える場合は別途MetaのApprovalが必要、月次利用者数に基づく制限がある、MetaのAI製品の競合に使用できない——これらの条件がついている。

Apache 2.0にはそれがない。Qwen 3.5も同じくApache 2.0を採用しており、今後「オープンモデル＝Apache 2.0」が業界標準として定着していく可能性がある。Gemma 4の選択は、その流れに乗るものだ。

ベンダーロックインを避けるという価値

もう一つ、企業が見落としがちな論点がある。ベンダーロックインのリスクだ。

クラウドAPIで提供されるモデルは、価格改定、利用規約変更、サービス廃止などのリスクを常に抱える。OpenAIやAnthropicのモデルを製品の中核に据えた場合、そのモデルが値上げされたとき、または利用規約が変わったとき、移行コストが問題になる。

オープンウェイトのGemma 4はその点が違う。モデルウェイトを自社サーバーやオンプレミス環境に持ってくることができ、ベンダーの政策変更に依存しない運用が可能だ。HuggingFace、Kaggle、Ollama、Google AI Studioなど複数のルートから入手でき、ファインチューニングして自社データに特化させることもできる。

オンデバイスAIが現実になる

E2B・E4Bモデルのターゲットはスマートフォンとエッジデバイスだ。ここにも実務的な意味がある。

ユーザーの端末内でAIが動くなら、データをクラウドに送る必要がない。医療記録、財務情報、個人の会話——プライバシーセンシティブなデータを扱う業務では、オンデバイス処理はコンプライアンス上の要件になりうる。GDPRや個人情報保護法の観点から、「データが端末の外に出ない」構成は非常に説明しやすい。

さらに、オフライン環境での動作も担保できる。工場内、病院内、フライト中——ネットワーク接続が安定しない環境でもAIが動く製品を作れる。

実際に企業が使う場面

ここまでの話を整理すると、Gemma 4が企業にとって選択肢になるシナリオはいくつか浮かぶ。

社内ドキュメント検索・要約に使いたいが、データをクラウドに送りたくない——31B Denseをオンプレに立てれば、社内情報をモデルに学習させた上で完全ローカル運用ができる。

カスタマーサポートのFAQ生成や問い合わせ分類に使いたいが、商用利用の法的確認を毎回したくない——Apache 2.0なら一度確認すれば終わる。

スマートフォンアプリに軽量AIを組み込みたいが、APIコストを抑えたい——E4BをオンデバイスでOllama経由で動かせば、推論コストはゼロに近づく。

256Kのコンテキストウィンドウは、長文書類の処理に実用的な余地を生む。数十ページのPDFを一括で処理したり、長いコードベースを丸ごと渡してレビューさせる用途でも、切れ目なく処理できる。

ライセンスが「モデルの実力」になる時代

個人的に思うのは、AIモデルの選択基準が変わりつつあるということだ。

2年前であれば、「どのモデルが一番賢いか」がほぼ唯一の軸だった。今は違う。ビジネスで使うモデルを選ぶ際、開発者が実際に検討する項目には、ベンチマークスコアに加えて、ライセンスの柔軟性、オンプレ・エッジへのデプロイ可否、ファインチューニングの自由度、長期的な可用性が含まれる。

Gemma 4はその全てを一定水準でクリアした。性能面でも世界トップクラスのオープンモデルと競合できる位置にいる。Apache 2.0というライセンス選択は、技術的な革新ではないが、企業が「使える」と判断するための最後のハードルを取り除いた。

ベンチマークは競合に追いつかれる。しかし、一度変えたライセンスポリシーは、エコシステムに根を張ってから変えるのは難しい。Googleがここで放った「Apache 2.0宣言」の影響は、スコアボードの数字より長く続くかもしれない。

Sources: