Google、オープンソースのマルチモーダル埋め込みモデル「EmbeddingGemma 2」を公開：自然言語でテキスト、画像、音声、動画を検索

スマートフォンに保存されたフォトアルバム、会議の録音、動画の中から特定のシーンを探そうとしても、ファイル名まで覚えているとは限りません。コンテンツの内容そのもので検索するには、埋め込みモデル（Embedding Model：テキスト、画像、音声などの現実のコンテンツを高次元の数学的ベクトルに圧縮し、コンピューターが意味的な類似度を比較できるようにするアルゴリズム）と呼ばれるモデルが必要です。テキスト専用だった前世代の小型モデルは、リリース後に累計2,000万回以上のダウンロードを記録し、テキスト資料の処理を担ってきました。新世代では、これが画像、録音、動画へとさらに拡張されています。

Google DeepMindは、オンデバイス向けに全く新しいオープンソースのマルチモーダル埋め込みモデル EmbeddingGemma 2 を発表しました。Gemma 4アーキテクチャをベースに構築され、商用利用が可能なApache 2.0ライセンスを採用しています。コンテキスト長を4倍の8,192トークンへと拡張しただけでなく、7億4,000万（740M）の総パラメータ数で、テキスト、コード、画像、動画、音声のすべてを同一の768次元ベクトル空間に収めています。着脱可能なモジュール構造とマトリョーシカ式のベクトル切り詰め技術により、タスクに応じて必要なエンコーダのみを読み込むことができ、開発者はより短いベクトルを使ってストレージ使用量を削減することが可能です。

1つの検索クエリで、いかにしてテキスト・画像・音声を見つけ出すのか

ローカル検索やプライベートRAG（Retrieval-Augmented Generation：関連資料を検索してから生成モデルに渡して回答させる手法）システムにおける一般的な手法は、まず異なるフォーマットをテキストに変換することです。アルバム内の動画を検索する場合、システムはまず音声認識モデルを呼び出して動画内の会話をテキスト化し、次に画像認識モデルを呼び出してタグを生成し、最後にテキスト埋め込みモデルを使って照合する必要があります。これでは処理ステップが増加し、短いテキストでは表現しにくい情報――例えば波の環境音、ギターのコード進行、あるいは動画内の特定のカメラワークによる映像表現――が失われてしまう恐れがあります。

EmbeddingGemma 2の根本的なブレイクスルーは、ネイティブなマルチモーダルアライメントにあります。テキスト、画像、動画、音声を、学習の段階から同一の768次元の数学的空間を共有するように設計しています。例えば公式デモ動画では、猫の写真、テキストの「cat」、そして猫の鳴き声が、エンコード後にこの共有高次元空間内で互いに近い位置へとマッピングされます。異なるモダリティのコンテンツが同じベクトル空間に投影されているからこそ、システムは音声や映像をあらかじめテキストに変換することなく、幾何学的距離やコサイン類似度を計算するだけでそれらの関連性を直接比較できます。

クエリと対象データのフォーマットが異なっていても、意味的な類似度を直接比較できます。具体的な実装において、このプロセスは明確なステップに分かれています：

1. データの事前エンコードとインデックス構築：ローカルアルバムの写真、動画クリップ、録音データなどを、あらかじめEmbeddingGemma 2によって768次元のベクトルとしてエンコード・抽出し、オンデバイスのベクトルインデックスデータベースに保存します。
2. クエリのリアルタイムエンコード：システムは入力されたクエリを同一空間のベクトルへとエンコードします。例えば「海辺の夕日の動画を探して」と発話した場合、この音声を直接ベクトルに変換し、動画クリップのベクトルと比較することができます（これは処理フローを理解するための例です）。
3. 同一空間での類似度照合と取得：統一されたベクトル空間内でクエリベクトルと各データベクトルの類似度を計算し、スコアの高い順にソートして候補となる元データを取得します。
4. 生成が必要な場合は大規模モデルへ渡す：検索による位置特定のみが目的であれば、候補となる元データをそのままユーザーに提示します。要約、質疑応答、推論などの処理がさらに必要なアプリケーションの場合は、検索された候補コンテンツをオンデバイスのGemma 4などの生成モデルに送って回答を生成させます。

同一の表現は、分類やクラスタリングにも利用できます。分類は、入力ベクトルとあらかじめ設定されたカテゴリベクトルを比較し、より近いカテゴリを選択する処理です。GoogleのMediaPipe Decision Task APIのミニゲームデモでは、マルチモーダルな入力に基づいて、JUMP、DUCK、SPRINTといった事前定義されたアクションの中から選択を行っています。（それぞれジャンプ、しゃがむ、ダッシュを指します）一方、クラスタリングは事前にカテゴリを指定せず、ベクトル空間上で位置が近いデータをグループ化することで、多様なフォーマットのコンテンツを整理しやすくします。

EmbeddingGemma 2が出力するのは数値表現です。検索されたコンテンツがユーザーの問いに答えられるかどうかは後続の処理に依存します。これらのステップがすべてデバイス上で実行される場合、ベクトル抽出と照合の一連の処理はすべてローカルチップ上で完結します。アルバムや録音データをクラウドサーバーにアップロードする必要がないため、ネットワークのラウンドトリップが削減され、元データをデバイス内にとどめることができます。

テキストのみを検索する場合、なぜモデル全体を読み込む必要がないのか

テキストやコードの検索のみを必要とするアプリケーションでは、画像や音声のコンポーネントを一緒にメモリへ読み込む必要はありません。EmbeddingGemma 2はモジュール式アーキテクチャを採用しています：

モデル全体は24層のTransformerで構成され、内部次元は512であり、プロジェクション層を介して標準の768次元ベクトルを出力します。その総パラメータ数7億4,000万（740M）は、タスクに応じて選択的に読み込むことが可能です：

1. テキストバックボーン（270Mパラメータ）：1億3,000万パラメータのTransformerバックボーンネットワークと、1億4,000万パラメータの埋め込み層で構成され、多言語テキストおよびコード全体の解析を担当します。
2. ビジョンエンコーダ（170Mパラメータ）：静止画および動画から抽出したフレームの解析に特化しています。
3. オーディオエンコーダ（300Mパラメータ）：多言語の音声および各種環境音の解析に特化しています。

どの部分を読み込むかは、アプリケーションが処理するデータの内容に応じて決定されます：

• テキスト／コード専用タスク（Text only）：Sentence-Transformersなどのフレームワークにおいて、設定でビジョンエンコーダとオーディオエンコーダを空に指定すると、モデルは270Mのパラメータのみを読み込みます。Googleが公表したPixel 11 Proでの量子化結果では、テキストの重みによるアクティブRAM消費量は約191 MBにまで抑えられます。
• 画像・テキスト検索タスク（Text + Vision）：オーディオコンポーネントを無効化することで、組み合わせのパラメータ数はわずか440Mとなります。
• テキスト・音声タスク（Text + Audio）：ビジョンエンコーダを無効化し、組み合わせのパラメータ数は570Mとなります。音声や環境音の処理のみが必要で、視覚的な検索が不要なシナリオでは、ビジョンエンコーダを読み込まずに済みます。
• フルマルチモーダル（Full Multimodal）：すべてのコンポーネントをロードし、パラメータ数は740Mに達します。同一端末での量子化後、フルマルチモーダルモデルの重みによるアクティブRAM消費量は約567 MBにとどまります。なお、これら2つの数値にはアプリケーション全体、検索インデックス、生成モデルのオーバーヘッド全体は含まれていません。

さらに、EmbeddingGemma 2はGemma 4アーキテクチャから派生しているため、Gemma 4生成モデルと同一のテキストトークナイザーおよびオーディオエンコーダを共有しています。これは、開発者がスマートフォン上で完全なオンデバイスRAGパイプライン（EmbeddingGemma 2が資料検索を担当し、Gemma 4が要約・回答を担当）を構築する場合、メモリ上で2つのモデルが一部の汎用的な低層の重みを共有できることを意味し、組み合わせて実行する際のメモリ消費削減に寄与します。

8Kは共通のバジェット、混合入力では合算して計算する

前世代のテキスト専用モデルのコンテキストウィンドウは2,048（2K）トークンにとどまり、長大な技術文書や複数ターンの対話を扱う際には細かく分割せざるを得ませんでした。EmbeddingGemma 2はコンテキスト長を4倍に拡張し、8,192（8K）トークンに達しています。

注目すべきは、この8,192トークンがすべてのモダリティで共有される統一バジェットプールであるという点です。モデルには明確なモダリティ換算基準が定義されています：

• テキストおよびコード：標準的なトークン化メカニズムに従い、約1サブワード（Subword：トークナイザーが分割する最小の意味単位）あたり1トークンを消費します。テキストのみを入力する場合、最大で8,192トークンまで対応可能です。
• 音声信号：16 kHzのモノラル（mono）音声が求められ、消費レートは1秒あたり25トークンで固定されています。音声のみの場合、8Kのウィンドウには最大327秒（約5.5分）の連続音声を直接収めることができます。
• 動画信号：デフォルトでは1 fps（1秒あたり1フレーム抽出）のサンプリングレートを採用し、動画フレーム1枚あたりデフォルトで140トークンを消費します。1回の入力につき最大で約58フレーム（すなわち約58秒の連続フレーム抽出動画）を入力可能です。
• 静止画像：画像1枚あたりデフォルトで280トークンを消費し、1回の入力につき最大で約29枚の画像を収容できます。

これらの上限は、それぞれ単一のモダリティのみを入力した場合の計算です。テキスト、画像、動画、音声を混合して入力する場合、この8Kのバジェットを共有して消費するため、各モダリティの上限を同時に満たすことはできません。この点は、長尺の音声ライブラリにおける検索と、1回あたりの8Kエンコード上限との関係を整理する上でも重要です。紹介にある「数時間の録音からコンテンツを探す」を実現するには、長尺の録音をコンテキストに適したセグメントに分割して個別にインデックスを構築し、クエリに応じて関連セグメントを取得します。これは、録音全体を一度にエンコードすることとは異なります。

さらに柔軟な点として、公式には視覚ソフトトークンの弾力的バジェット調整機能も提供されています。開発者はタスクの要件に応じて、画像1枚または動画1フレームが占有するトークン数を70〜1,120ソフトトークンの間で自由に調整できます。細部の要求が高くない一般的な分類タスクであれば、70トークンまで下げることで、1回の入力に最大約114枚もの画像や動画フレームを収めることが可能です。一方、緻密な回路図や複雑なエンジニアリング図面などの視覚的文書を扱う場合は、トークン配分を増やすことで、計算リソースをわずかに多く消費する代わりに、より精細な視覚的表現を得ることができます。

それだけでなく、EmbeddingGemma 2は真のマルチモーダル自由インターリーブ入力をサポートしています。入力テキスト内で、<|image|>、<|video|>、<|audio|>といったプレースホルダーを随時使用できます。例えば、販売中のトレイルランニングシューズをインデックス化する場合、入力は次のように記述できます：

emb = model.encode({
    "text": "越野防水跑鞋。<|image|> 采用透气网面设计。<|image|> 湿滑岩石抓地力实测：<|video|>",
    "image": ["shoe.jpg", "mesh.jpg"],
    "video": "demo.mp4",
})

モデルはプレースホルダーの相対位置に基づき、テキストによる説明、2枚のクローズアップ画像、1本のテスト検証動画を統合して1つの完全な768次元ベクトルへと融合します。その後、ユーザーが「濡れた岩場でも滑らない靴」といったシンプルな自然言語で検索すれば、このテキスト・画像・動画が統合されたレコードを検索することが可能です。

ベクトル短縮でどれだけ容量を節約でき、どれだけ品質が低下するのか

オンデバイス機器では演算コアが逼迫しているだけでなく、ローカルストレージやメモリも極めて貴重です。従来の768次元の浮動小数点ベクトルを数百万件も保存すれば、スマートフォンのストレージにとって大きな負担となります。

そのため、EmbeddingGemma 2にはMRL（Matryoshka Representation Learning：マトリョーシカ表現学習）技術がネイティブに統合されています。この技術は学習時に損失を最適化し、あらかじめ設定された複数のプレフィックス次元がそれぞれ有効な表現として機能するようにしますが、ベクトルの各次元が重要度順に厳密に並ぶことまでは保証しません。したがって、開発者はモデルを再学習させることなく、ベクトル出力時に対応する先頭次元を切り出すだけで、768次元を512次元、256次元、さらには128次元へと切り詰めることができます：

公式のテストデータからは、極めて明確なエンジニアリング選定指針を導き出すことができます：

1. 256次元は評価の出発点として適している：完全な768次元と比較して、256次元はベクトルのストレージサイズを3分の1に縮小します。公式ベンチマークでの品質低下は小さく（多言語テキストは61.36から60.41への低下にとどまり、コードは78.68から76.18、音声も約0.48ポイントの低下）、アプリケーションの要件を満たすかどうかは実際のデータにおける検索結果を見て判断できます。
2. 128次元のマルチモーダル利用には慎重を期す必要がある：128次元はベクトル容量を6分の1に圧縮でき、テキストやコードの指標はまずまずのスコアを維持しますが、複雑な視覚評価やクロスモーダル評価において（MMEB v2で59.01から45.65へと大幅に下落）、情報損失が非常に顕著になります。そのため、128次元は要件が極めて厳しい純粋なテキストのオンデバイスシナリオでのみ推奨され、マルチモーダル環境で使用する場合は厳密なオフラインでの業務検証を経る必要があります。

小型モデルの価値は、品質とスケールをあわせて比較してこそ見えてくる

Googleが公表した評価結果によると、比較的小規模でありながら一部のより大規模なモデルに匹敵または凌駕しているものの、図にはさらに高いスコアを記録している大規模モデルも存在します。ここでの価値は限られたリソースにおける品質にあり、すべての指標で首位を獲得することではありません：

• コード検索の向上：Googleが公表したフル精度のMTEB Code (v1)コードベンチマークにおいて、EmbeddingGemma 2は 78.68 というスコア（NDCG@10：上位10件の検索結果におけるランキング関連性を評価する指標）を記録し、第1世代のテキスト専用モデルの68.76点と比較して9.92ポイント増加しました（相対的に約14%の向上）。これらの結果は、ローカルIDEでのコードインデックス作成、セマンティックコード検索、オンデバイスのプログラミングAgentにおけるコンテキスト想起への適用を後押しするものです。ブログ付属の比較グラフでは、270Mのテキストコアはコード検索において一部の小型モデル（Qwen3 0.6Bの約75.4点など）を上回り、その数倍のサイズを持つ8Bの大規模モデルの水準（約80.8点）に迫っています。（注：公式の元画像から読み取れるプロット値は約76.7点であり、公式モデルカードの表に正式記載された78.68点とは乖離があります。評価の正確なスコアはモデルカードに記載された数値を基準とすべきです）

• 画像および文書理解における目覚ましいパフォーマンス：MIEB Lite画像埋め込みベンチマークにおいて 64.64 点を獲得し、jina-v5-omni-small（約61.5）を上回り、3B規模のLCO-Embedding-Omni-3B（約65.7）に迫っています。さらに、マルチモーダル視覚文書理解（MMEB v2 VisDoc）では67.84のスコアを記録しました。このベンチマークは視覚文書の検索に対応するものであり、レポート全体の推論や質疑応答の能力と直接同一視することはできません。

• 図中の複数の専用モデルを上回る音声性能：MAEB音声ベンチマークテストにおいて、モデルは 49.39 点を獲得し、MSEB検索評価では 69.54 点を記録しました。約30億パラメータ規模のe5-omni-3B（約48.6）に迫り、図中のいくつかの音声専用モデル（large_clapの約34.5、MuQ-MuLanの約28.4、Qwen2-Audio-7Bの約35点など）を上回っています。（注：元画像の横軸ではマルチモーダルのプロット位置が約670Mの概算位置に打たれており、音声スコアの図上のプロット読み取り値も約48.7と、モデルカードの正確な値49.39とわずかに乖離しています。モデルカードに記載されたパラメータ規模は740M、スコアは49.39です）

• 前世代と同水準を維持した多言語テキスト：100以上の言語をカバーするMTEB multilingual (v2)テストにおいて 61.36 点を記録し、前世代（61.15）とおおむね同水準を維持しました。主な強化ポイントはコードと新たに追加されたマルチモーダル対応にあります。

導入前に確認すべき数値精度・正規化・タスクプレフィックス

EmbeddingGemma 2を実際のプロダクションパイプラインに導入する際、注意すべき設定が3点あります：

落とし穴1：float16の使用は厳禁、必ずbfloat16またはfloat32を使用すること

EmbeddingGemma 2の内部活性化値の範囲は、float16の動的表現範囲を超えています。 torch.float16 を用いて推論を行うと、明示的なエラーを出さずにモデルが NaN（Not a Number：非数）や品質の劣化したベクトルを返す可能性があります。

• 正しい対処法：ハードウェアアクセラレーションがサポートされている環境では、必ず torch.bfloat16（float32と同じ指数範囲を持ち、1数値あたりのストレージはfloat32の約半分）を選択します。一方、ネイティブのbfloat16をサポートしていない環境（モデルカードでは大半のCPUでfloat32の使用が推奨されています）では、フォールバックとして torch.float32 を使用する必要があります。

落とし穴2：MRLによる切り詰め後は必ずL2正規化を再実行すること

正規化ベクトルの内積を用いてコサイン類似度を計算する場合、ベクトルの長さを1にする必要があります。スライス構文を使って768次元から256次元へと切り出した場合、切り詰められた先頭256成分の平方和は明らかに1ではなくなります。 切り詰めた後に L2正規化（L2 Normalization：ベクトルをそのユークリッド長で割り、ベクトルの長さを1にリセットする幾何学的操作）を行うのを忘れると、その後の内積によるベクトル比較時にエラーは出ないものの、サイレントな偏りが発生する恐れがあります――表面上は一見妥当に見えて実際には歪んだ類似度スコアが算出され、ランキング品質がひそかに損なわれます。公式モデルカードでは、手動スライスによるこの問題を防ぐため、呼び出し時にパラメータを通じて直接切り詰めと正規化を行うことを推奨しています。

• 正しい対処法：ライブラリの呼び出し時に自動正規化パラメータを直接指定するか、手動で正規化を実行します：

query_emb = model.encode(
    query,
    truncate_dim=256,          # 声明截断维度
    normalize_embeddings=True  # 强制要求截断后重新归一化！
)

また、クエリとデータベースの次元数は完全に一致している必要があります。768次元のクエリベクトルを使って256次元のベクトルデータベースを検索することは絶対に避けてください。

落とし穴3：タスクプレフィックスを正しく使い、非テキスト入力にはプレフィックスを付けないこと

EmbeddingGemma 2は、学習時に簡潔なタスクプレフィックスを使用しています。入力テキストの前にタスクに応じたプレフィックスを付与することで、品質の向上が期待できます。

• 非対称検索（Asymmetric：文書検索、コード検索、質疑応答など）：検索語と検索対象コンテンツの形態が異なるため、クエリと資料のそれぞれにプレフィックスを使い分ける必要があります。
  • ウェブ／文書検索：Queryの形式は task: search result | query: {query} とし、検索対象文書の形式には必ずタイトルを連結します：title: {title} | text: {content}（タイトルがない場合は title: none | text: {content} と記述）。
  • コード検索：クエリには prompt_name="CodeRetrieval"（task: code retrieval | query: {query} に対応）を使用でき、コードファイル側は title: {ファイル名またはクラス名} | text: {コード} と設定します。
• 対称比較（Symmetric：文の類似度、テキスト分類、クラスタリングなど）：双方に同一の指示プレフィックスを使用します（例：task: sentence similarity | query: {content}）。
• 最も重要な原則：すべてのプレフィックス指示は純粋なテキストにのみ有効です！画像、動画、音声には生の信号をそのまま渡し、いかなるテキスト指示プレフィックスも絶対に付加しないでください。

体験アプリから開発ツールまで：試用を始めるためのロードマップ

まずは公式が提供するリファレンスアプリケーションから、オンデバイスにおけるマルチモーダル埋め込みの具体的な用途を確認できます：

• Google AI Edge Gallery（写真・動画の位置特定）：テキストや画像でアルバムを検索するInstant Media Searchや、自然言語や音声で動画内の特定の瞬間を特定するVideo Moments Finderが含まれます。公式の発表動画では、プレゼンターが「ろうそくを吹き消す」というキーワードで誕生日の動画を検索したところ、返された結果は動画ファイル全体ではなく、動画タイムライン上でろうそくを吹き消す正確な時間位置へと直接ジャンプし、ユーザーはその瞬間から直接再生することができました。
• Google AI Edge Foresight（オンデバイス・マルチモーダルRAGの連携）：デモでは、アプリケーションがバックグラウンドで質問音声をリアルタイムに聞き取ってエンコードし、それに基づいてローカルストレージ内のテキスト、画像、システム構成図を検索した上で、Gemma 4がローカルで回答の要約を生成します。「埋め込みモデルが資料を探し」「生成モデルが回答する」という連携が実際に成立しており、機密データがデバイスの外に出ることはありません。
• MediaPipe Decision Task API（事前定義分類と決定ルーティング）：入力表現とあらかじめ定義された候補ベクトルの類似度比較を利用し、低レイテンシのリアルタイム意図分類や決定ルーティング機能をアプリケーションに提供します。

現在、モデルの重みは Hugging Face および Kaggle で正式に公開されており、Gemini Enterprise Agent PlatformのModel Gardenでも近日中にサポートが開始される予定です。

開発者は実行環境に応じて適切なエントリーポイントを選択できます：

• モデルのダウンロードとオンデバイス実行：重みはHugging FaceとKaggleで公開されており、LiteRT Communityからはオンデバイス向けに量子化・最適化された専用バージョンが提供されています。モバイル開発者は、Google AI Edgeが提供する MediaPipe スイートを利用してすぐに使えるベクトル抽出を実現できるほか、LiteRT（旧TensorFlow Lite）を用いて高度にカスタマイズされたモデル組み込みを行うことも可能です。ウェブ環境では、transformers.jsとWebGPUを用いたフロントエンド単体でのローカル実行がサポートされています。
• サーバーサイドとローカルツールボックス：発表記事に挙げられているツールには、sentence-transformers、transformers、vLLM、SGLang、AppleエコシステムのMLX、そして個人開発者向けのllama.cpp、Ollama、LMStudioが含まれます。生成されたベクトルはQdrantなどの最新ベクトルデータベースに保存可能で、モデルのファインチューニングはUnslothが提供する専用ガイドに沿って進めることができます。

Googleの完全版発表動画では、特定の専門分野の語彙や資料（動画内で例示された法的契約書、医療画像、技術製品カタログなど）に適応させるために、ファインチューニングが可能であることも説明されています。ファインチューニングの役割は、モデル規模を増大させることなくバーティカル領域の専門的な表現をより深く理解させ、検索精度を向上させる点にあります。ただし、動画で触れられている法律や医療のシナリオは適用先の可能性を示す例示に過ぎず、実際の運用にあたっては自身のデータを用いて検索効果を検証する必要があります。開発者はUnslothが提供するファインチューニングガイドを参照するか、Gemma Cookbookの関連サンプルから着手することができます。

モデルは100以上の言語をサポートしていますが、言語によってパフォーマンスが同一とは限りません。また、検索品質は実際のデータやタスクの内容にも左右されます。EmbeddingGemma 2が担うのは表現（ベクトル）の生成であり、アプリケーション側で検索結果のフィルタリングや利用ルールのハンドリングを行い、実際のデータを用いて有効性を検証する必要があります。