Gemma 4 E2Bとは？
Gemma 4はGoogle DeepMindのオープンウェイトモデルファミリーで、E2Bは比較的小さなバリアントのひとつだ。Googleのモデルカードは、このサイズをモバイルおよびエッジ環境での利用対象としている。名称を「保存されたパラメータの総数」と誤解しないようにしたい。GoogleがE2Bについて示すのは23億の有効パラメータであり、埋め込みを含めると51億となる。これは定義の異なる関連指標であり、どちらも実際のダウンロードファイルのバイト数を直接表すものではない。
同じモデルカードでは、コンテキストを128,000トークン、入力をテキスト・画像・E2Bの音声、出力をテキストとし、ライセンスをApache 2.0としている。候補の絞り込みに使えるモデルレベルの事実ではあるが、ある変換済みパッケージがすべての機能を保持していること、特定のAndroidランタイムが対応APIを公開すること、特定の端末がメモリや温度の制約内でタスクを完了できることを証明するものではない。
この区別が重要なのは、モデル名だけではデプロイ構成が分からないからだ。アプリには正確な成果物、トークナイザーと会話形式、ランタイムビルド、バックエンド、入力と出力の上限が必要になる。Googleの公式Gemma 4モデルカードはファミリー仕様を、Gemma 4の公式ページは全体像を説明している。いずれもスマートフォン別の互換性一覧ではない。
主な仕様と読み方
上の仕様カードにはモデルレベルで確認できる項目を掲載している。パッケージ容量と最低RAMが「未公開」なのは意図的だ。モデルカードは共通の量子化ダウンロードサイズや最低端末メモリを定めていない。コミュニティが公開する変換モデルに独自のファイル情報が付くことはあるが、その情報は特定のリポジトリとリビジョンに属し、すべてのE2Bパッケージに一般化できない。
コンテキスト長にも正確な説明が必要だ。128Kはモデルカードに記載された上限で、モバイルアプリが全長を実用できる保証ではない。1回のリクエストには、システム指示、会話履歴、タスク本文、書式トークン、画像または音声の表現が含まれる場合がある。生成回答にも余地が必要だ。ランタイムの設定上限はさらに低い可能性があり、端末はモデル、作業用バッファー、キャッシュ、アプリ状態、OSのプロセスを同時に保持しなければならない。入力を受理しただけで、途中で切り捨てられたりメモリ不足で止まったりしたなら、128Kのワークフローを完了したとは言えない。
同様に「音声入力」は、E2Bがそのまま完成した音声製品であることを意味しない。音声機能にはマイク権限、前処理、モデルが受け付ける入力表現、出力整形、再生や翻訳の部品が別途必要になりうる。それぞれの段階を個別に確認すべきだ。モデルカード上のモダリティからアプリのエンドツーエンド機能を主張せず、実際に確認した成果物とランタイムを明記する。
どの端末で動くのか？
Googleは小型のGemma 4をモバイルやエッジ向けと説明している。これは設計上のターゲットであり、端末別の互換性判定ではない。そのため、このページはブランド単位の対応機種一覧を示さず、「最低4GB」や「8GB以上」といったメモリ下限も掲載しない。その結論には、正確なモデルファイル、ランタイム版、OSビルド、バックエンド、タスク、端末構成の測定が必要だ。
Android評価では「対応」という表現を再現可能なテスト記録に結び付ける。SoCとメモリ構成、OSビルド、アプリビルド、LiteRT-LMの依存関係と版、モデルリポジトリと不変リビジョン、ファイル名、取得可能なダイジェスト、要求したバックエンド、入力形式、コンテキスト設定、出力上限を記録する。初回起動とモデル初期化のコールドパス、繰り返し利用のウォームパスを両方測る。1台のテスト結果はその構成に関する証拠であり、同じブランドの全端末に適用できる証拠ではない。
Google AI Edgeの公式LiteRT-LM Kotlinガイドは、Android/JVMのEngine APIを説明し、初期化はUIスレッド外で行うこと、終了時にEngineを閉じてリソースを解放することを示している。CPU/GPU/NPUの設定や、GPUとNPU利用時に追加構成が必要になりうる点も掲載されている。ただし、すべてのGemma成果物、ランタイム版、アクセラレータードライバー、端末の組み合わせを認証する文書ではない。端末仕様表から対応バックエンドを推測せず、ログとテストで実際に初期化された経路を確認する。
強みと制約
公式情報から見ると、ローカル推論、小型モデル、テキスト・画像・音声の入力、明確なオープンウェイトライセンスを重視するチームにとって、E2Bは検証候補になる。埋め込み込みの総数より有効パラメータ数が少なく、Googleは小型Gemma 4をモバイルとエッジに位置付けている。これは「テストする理由」であって、「テストを省略する理由」ではない。
アプリ開発チームにとって重要な問いには、汎用回答がない。変換済み成果物の最低RAM、単一のファイルサイズ、Android端末対応表、長時間利用の電池・温度影響、個別タスクの品質はモデルカードからは分からない。公開benchmarkの数値は特定タスクと条件に結び付いており、社内の現場メモ、ある言語ペア、スマートフォンでの長時間セッションを予測する値として扱えない。多数言語で学習されたという説明も、すべての言語と用途で均一な品質を保証しない。
さらに、モデルの能力とユーザー向け機能全体を区別する必要がある。E2Bそのものはマイク操作、安定した音声分割、言語選択、モデル配信、キャンセル、失敗時の復旧、プライバシー説明を提供しない。これらはアプリとランタイム側の責務だ。端末互換性の表現を決める前に、2026年のオフラインAI翻訳ガイドのように、ローカルモデル・ダウンロード済み言語資源・クラウド処理の違いも確認するとよい。
具体的な評価シナリオ：現場メモのプライベート要約
電波が届かない場所でも使うAndroid現場記録アプリを開発するチームを想定しよう。メモには人名、日付、否定表現（「バルブを再度開けないこと」など）、担当者に結び付ける必要がある作業が含まれる。判断すべきなのは「E2Bは優秀か」ではない。固定したE2B成果物を明示したランタイムで対象端末に載せ、許容できる忠実度、使い勝手、失敗復旧でタスクを完了できるか、である。
以下は提案するテストであり、Coveや特定機種が達成済みの結果ではない。合成メモを使った小規模でプライバシーに配慮したfixtureを作り、期待される要約をレビュー済みの形で用意する。長さや文体に幅を持たせても、設定を比較する前にケースを固定する。重大な欠落、矛盾、根拠のない追加をどう判定するかも先に決める。プライバシーレビューが明示的に許可しない限り、個人が特定できる実際の現場記録を外部評価サービスに送ってはならない。
再現可能なAndroidテスト手順
- 候補を固定する。 上流モデル名と正確なリポジトリ、変更されないリビジョン、ファイル名、長さ、取得可能なダイジェスト、トークナイザー/テンプレート、ライセンスを記録する。変換済みか、公開者は誰か、どのモダリティファイルが含まれるかも記す。「Gemma 4 E2B」という表示名だけでは再現できない。
- ランタイムとタスクを固定する。 Androidアプリビルド、LiteRT-LMの版、端末/OSビルド、指定バックエンドと実際の初期化結果をログに残す。プロンプト、入力上限、出力形式、サンプリング設定、キャンセル方針を定義する。初期化をUIスレッド外で行い、ライフサイクル終了時にリソースを閉じることを確認する。
- 固定fixtureを実行する。 短いメモから始め、事前に決めた段階で入力を長くする。人名、日付、否定、担当者、指定した行動が保持されたか採点する。形式不正、切り捨て、ロード失敗、プロセス終了、再試行も正式な結果として扱う。失敗ケースを黙って除外したり、別プロンプトの点数と混ぜたりしない。
- リソースとライフサイクルを測る。 一貫した測定境界でモデルロードとリクエストの各段階を記録する。プロセスメモリと端末状態を確認し、ウォームアップ後にも同じ負荷を繰り返し、バックグラウンド/復帰もテストする。CPU/GPU/NPUを比較する場合、実出力から有効なバックエンドを確認する。アクセラレーターを要求しただけではDelegate初期化の証明にならない。
- オフラインを独立に検証する。 モデルのセットアップ完了後に通信を遮断してアプリをコールド起動し、同じfixtureを実行して失敗処理を確認する。接続を戻したら、リモート推論、分析、アカウント確認、モデル更新サービスへの試行を調べる。端末内生成と、アプリが一切通信しないことは別々の主張である。
- 範囲を限定して公開する。 生ログ、fixtureまたはプライバシーに配慮したfixture識別子、採点規則、失敗ケース、測定境界を残す。正確な成果物、ランタイム、端末、OS、タスクを明記する。1回の成功を「Androidで動く」「全フラッグシップに対応」と言い換えたり、一般的な速度/メモリ値へ外挿したりしない。
実行前に決める合格条件
- タスク忠実度： 全ケースを同じ事前定義ルーブリックで採点し、人名、否定、日付、作業担当を保持する基準を結果を見る前に決める。
- ランタイム信頼性： ロード、初回/反復応答、キャンセル、前後切り替え、終了を記録する。クラッシュ、隠れたフォールバック、未報告の切り捨ては失敗として扱う。
- リソースとオフライン境界： メモリ/時間の測定点を再現可能にし、想定バックエンドの実動作を確認する。機内モードで非開示のリモート推論経路なしに完了する。
これらの条件に汎用の数字を作ってはならない。製品チームは利用者のタスクと対象端末クラスに合わせて、結果を見る前に基準を決め、数値と証拠を一緒に公開する。必要な信号をビルドから取得できない場合は、その不足を合格にせず、証拠ギャップとして記録する。
| 候補 | 公式情報が示すこと | 追加で必要な検証 |
|---|---|---|
| Gemma 4 E2B | 23億有効パラメータ（埋め込み込み51億）、128Kコンテキスト、テキスト/画像/音声入力、テキスト出力、Apache 2.0。 | 正確なAndroid成果物、ロード、メモリ、タスク品質、速度、電池、温度、オフライン時のライフサイクル。 |
| Gemma 4 E4B | 45億有効パラメータ（埋め込み込み80億）、128Kコンテキスト、テキスト/画像/音声入力、テキスト出力。 | 大きな構成と品質のバランスが対象端末に合うか。パラメータ数から必要RAMを推測しない。 |
| クラウド推論サービス | 推論がユーザーの端末ではなくリモート基盤で行われる。 | 接続要件、プライバシーレビュー、費用、サービス条件、障害時の動作が用途に合うか。 |
別のモデル系列も、比較前に一次資料を確認する。Qwen 3.5 2Bのページでは文書上の仕様とモバイル実測を区別している。モデル一覧表は仕様のカタログであり、実機benchmarkではない。
選ぶべき場面、避けるべき場面
チームが正確な成果物を固定して配信でき、Androidランタイム統合を担当し、タスク固有の品質ルーブリックを持ち、代表端末でメモリ、復旧、オフライン動作を評価できるなら、E2Bを候補に加えられる。モバイル/エッジ向けという公式の位置付けやテキスト・画像・音声入力が機能要件に合う場合も、評価する理由になる。Apache 2.0はライセンス確認の有用な手掛かりだが、法務レビューでは実際に使用する成果物のライセンス文面と告知を確認する。
「2.3Bなら軽いはず」、128Kコンテキストの記載、別の人の端末で動いたデモだけを根拠に採用してはならない。配布物の容量や版管理が許容できない、ロードの待ち時間が機能要件に合わない、変換物が必要モダリティを含まない可能性がある、または未測定の端末保証が必要なら、互換性を約束する証拠は不足している。別モデルやランタイムを評価するか、必要なテストが揃うまで主張を保留する。
Coveの実装について確認できる範囲
CoveのAndroidリポジトリには、Hugging Faceの特定リビジョンに固定されたE2B LiteRT-LM設定があり、ひとつの成果物について期待ファイル長 2,583,085,056 バイトが記録されている。一方、SHA-256設定欄は空だ。この数値は開発時のストレージ事前確認用で、実測ダウンロード結果でも全Gemmaパッケージ共通のサイズでもない。これは開発設定の存在を示すだけで、ファイルの検証済みダウンロード、一般ユーザー端末での実行、署名済み公開リリース、特定機種の動作確認を証明しない。公開状況と端末性能の証拠は別に管理されているため、このページはAPKの配布やスマートフォン対応を約束しない。Coveのアプリ状況ページでは現在、検証済みAPKリンクではなく公開通知を案内している。
よくある質問
ページ上部の質問はモデルカードとデプロイ証拠の範囲に限定している。特に「モバイル向けに設計」「モバイル版成果物が端末で動く」「アプリストアでダウンロード可能」は別の意味だ。将来いずれかの表現を強める場合は、正確な成果物、ランタイム、実機記録、または正式なリリース記録が必要になる。
編集状況：Google DeepMindおよびGoogle AI Edgeの一次資料とCove Androidソース設定に基づき、2026-09-25に更新。日本語版はAIによる翻訳・編集であり、サイト所有者による日本語校閲は未確認。