Googleの新埋め込みモデル、画像も音声もまとめて検索

写真の整理アプリに「あの時の花火の写真」で検索できる機能をつけたい。そう考えたとき、画像や音声まで検索対象に広げると、オフラインで動くモデルはどれだけ重くなるのか気になる人は多いはずだ。クラウドのAPIに頼らずアプリに組み込むとなると、サイズの上限はさらに厳しくなる。

Googleは2026年10月6日(米国時間)、埋め込みモデル「EmbeddingGemma 2」を公開した。テキストだけでなく、画像・音声・動画・コードも1つの空間にまとめて扱える。スマートフォンで実際に動かした数値も公式ブログで示されている。

その数値がどれだけの軽さなのか、なぜそんな小さなモデルに5種類もの対象を詰め込めるのか、ここから見ていく。

検索の裏にある「埋め込み」という仕組み

テキストも画像も音声も一緒に検索できるというとき、その裏では何が起きているのか。「花火の写真を探す」とき、人は言葉と画像を頭の中で結びつけて照合している。コンピュータが同じことをするには、言葉も画像も音声も同じ物差しで測れる数値の並びに変換する必要がある。この変換を担うのが埋め込み(embedding)モデルで、変換後の数値の並びをベクトルと呼ぶ。似た意味の言葉や画像ほど、ベクトル同士の距離が近くなるように作られている。

EmbeddingGemma 2は、この埋め込みをテキスト・画像・音声・動画・コードの5種類で共通の空間に対応させたモデルだ。公式ブログによると、Gemini Embeddingと同じ技術をベースに、端末上での推論を前提に作られている。ネットに接続していない状態でも、端末の中だけで検索やRAG(検索で見つけた情報をもとに回答を作る仕組み)が完結する。

対応する種類が増えるほど、モデルは重くなりそうに思える。実際のところはどうなのか。

スマホでも1GBを切るメモリで動く

Googleが示した数値を見ると、予想より軽い。Google Pixel 11 Proで量子化を適用した場合、テキストのみの利用で約191MB、画像・音声・動画まで含めた全モダリティでも約567MBだという。

画像・音声・動画まで足しても、全体で1GBを切る。対応するモダリティが増えるほどモデルも重くなるはずだと予想していた自分には、この数字が意外だった。この数値はGoogleが自社の計測環境で示した公表値であり、第三者による独立検証ではない。とはいえ、スマートフォンのアプリに同梱できる範囲の大きさだと分かる。

なぜ、これだけ多くの種類を扱いながらこの軽さに収まるのか。

モジュール構成とベクトル圧縮

理由は2つある。1つは、モデルがモジュール式になっていることだ。公式ブログによると、EmbeddingGemma 2の総パラメータ数は約7.4億(740M)。内訳は次のとおりで、必要な部品だけを組み合わせて使う。

• テキストのみの構成: 最小約2.7億(270M)
• 画像エンコーダ: 1.7億(170M)
• 音声エンコーダ: 3億(300M)

写真しか検索しないアプリなら画像エンコーダだけを足せばよく、使わない部品は持たずに済む。

もう1つは、ベクトルの次元を目的に応じて削れることだ。EmbeddingGemma 2が基本で出力するベクトルは768次元になる。これをMatryoshka Representation Learning(MRL)という技術で512・256・128次元まで切り詰められる。写真を1,000枚持つアプリなら、768次元のベクトルを1,000個抱えるより、128次元に削った1,000個を持つほうが保存先の容量もメモリも小さくて済む。Googleは、この圧縮でローカルのベクトルデータベースとメモリ使用量を最大6倍削減できるとしている。

必要な部品だけを足す設計と、ベクトルの次元を削る設計。この2つが組み合わさって、5種類の対象を扱いながらスマホに収まる軽さを実現している。

対応できる処理量にはどんな違いがあるのか、初代のEmbeddingGemmaと比べてみる。

初代からどう変わったか

初代のEmbeddingGemmaは2025年に公開され、公式ブログによれば2,000万回を超えるダウンロードを記録している。ただしテキスト専用で、画像や音声には対応していなかった。

出典: Google公式ブログ。初代のパラメータ数と埋め込み次元数は、この発表では触れられていない。

表から分かるのは、対応モダリティの広がりだけでなく、コード検索の精度も大きく上がっている点だ。1件あたりの処理量(コンテキスト)も4倍に伸び、音声なら最大約5.5分、画像なら29枚、動画なら58フレームを端末上でまとめて扱える。

では、この新しいモデルを実際にアプリへ組み込むには、何が必要になるのか。

自分のアプリにどう組み込むか

EmbeddingGemma 2はApache 2.0ライセンスで公開され、商用利用もできる。公式ブログによると、入手先と組み込み方は次のとおりだ。

• 重みはHugging FaceとKaggleから入手できる。オンデバイス向けに最適化した版はLiteRT Community(Hugging Face)にある
• オンデバイスでの推論には、MediaPipe・LiteRT・transformers.js・WebGPUが使える
• サーバー側での推論・サービングには、transformers・sentence-transformers・MLX・vLLM・llama.cpp・SGLang・Ollama・LM Studioが対応する
• ベクトルの保存にはQdrant、追加学習にはUnslothが使える
• Gemini Enterprise Agent Platform Model Gardenでの提供は近日対応予定で、2026年10月時点ではまだ使えない

対応ツールの幅は広く、普段ローカルでモデルを動かしている人なら、使い慣れた環境にそのまま載せられる組み合わせが見つかりやすい。

組み込む手段は揃っているとして、実際にはどんなアプリでの利用が想定されているのか。

想定されている利用例

公式ブログは、Googleが社内で試した例をいくつか挙げている。

• Instant Media Search: テキストや画像を手がかりに、端末内のメディアライブラリから似た写真・動画を探す。Google AI Edge Galleryというサンプルアプリで動かしている
• Video Moments Finder: テキストや音声での問いかけから、動画の中で該当する場面を探し出す。こちらも同じサンプルアプリに含まれる
• Google AI Edge Foresightアプリ: EmbeddingGemma 2でローカルのファイルを検索し、見つけた内容をもとにGemma 4が文脈に沿った推論を行う
• コード検索: ローカルのコードベースにインデックスを作り、コーディングエージェントが参照する検索先として使う

冒頭で挙げた「花火の写真を探す」という例は、このInstant Media Searchに近い使い方になる。検索対象が写真だけでなく動画・音声・コードにまで広がった今、1つのモデルで複数の検索機能を組める余地が増えた。

まとめ

EmbeddingGemma 2は、テキストに加えて画像・音声・動画・コードも1つの埋め込み空間で扱える新しいモデルだ。総パラメータ数は約7.4億で、Googleの公表値によればスマートフォン上でも全モダリティ込みで567MBのメモリに収まる。モジュール式の構成で必要な部品だけを足し、ベクトルの次元をMRLで削れる設計がこの軽さを支えている。

初代と比べるとコンテキストウィンドウが4倍に伸び、コード検索の精度も上がった。Apache 2.0ライセンスでHugging FaceとKaggleから入手でき、MediaPipeやOllamaなど普段使われているツールにそのまま載せられる。ネット接続のない環境でも、写真・動画・音声を横断した検索やRAGを、1つの小さなモデルで組める段階に来ている。