Googleは10月6日、写真や音声をテキストと同じ仕組みで検索できるオープンモデル「EmbeddingGemma 2」を公開した。初代EmbeddingGemmaが扱っていたテキストとコードに、画像、動画、音声を加え、異なる種類のデータを共通のベクトル表現へ変換できる。モデル全体でも7億4000万パラメータで、テキストだけなら2億7000万パラメータの部分だけを読み込んで使える。ライセンスはApache 2.0だ。
コード検索の評価は初代から大きく向上した一方、多言語テキストの総合スコアはほぼ横ばいだった。QwenやJinaなどの競合と比べても、どの種類のデータを検索するのか、どれだけ長い入力を扱うのか、端末側の負担をどこまで抑えたいのかによって、選ぶ理由が分かれる。
必要な機能だけを読み込める7億4000万パラメータ
EmbeddingGemma 2は、テキスト用の2億7000万パラメータを中心に、画像用の1億7000万パラメータと、音声用の3億パラメータのエンコーダーを組み合わせる。テキストと画像だけなら約4億4000万、テキストと音声なら約5億7000万となり、必要のないモダリティ向けの部分をメモリーへ読み込まずに済む。動画は画像用エンコーダーでフレームを処理する。
埋め込みモデルが生成するのは回答文ではない。文章や画像、音声などの内容を表す「ベクトル」と呼ばれる数値の列だ。検索したい内容と保存済みのデータをそれぞれベクトルへ変換し、互いに近いものを探す。
そのため、単語が完全に一致していなくても意味の近さから検索できる。例えば「雨の山道で滑りにくい靴」という文章を入力し、それに合いそうな商品写真を探すといった仕組みを作れる。
従来も、写真から説明文を生成したり、音声を文字起こししたりしたうえで、テキスト用の埋め込みモデルへ渡す方法はあった。EmbeddingGemma 2では、画像や音声のエンコーダーが得た情報をテキストと共通の768次元ベクトル空間へそろえる。途中で画像説明や文字起こしを生成する工程を減らせるうえ、発話内容だけでなく、画像そのものや環境音なども検索対象にできる。テキストと画像など、複数の形式を組み合わせた入力を一つのベクトルへ変換することもできる。
ただし、関連する資料を探すことと、その資料を読んで回答を作ることは別の処理だ。検索拡張生成（RAG）で使う場合、EmbeddingGemma 2が関連データを探し、Gemma 4などの生成モデルがそれを基に回答を作る。Googleが公開したコード検索のデモでも、検索にはEmbeddingGemma 2、エージェント側にはGemma 4を組み合わせている。
Googleは量子化したモデルをPixel 11 Proで動かした例として、テキスト部分だけなら約191MB、全モダリティを読み込んでも約567MBのアクティブRAMで動作すると説明している。これは特定の端末と量子化方式を使った場合の値であり、検索索引やアプリ本体、処理中に必要となる一時領域まで含めたアプリ全体のメモリー使用量ではない。
また、公開されているベンチマークはフル精度モデルによる評価だ。小さく量子化した端末向け構成でも、まったく同じスコアになるとまでは言えない。
コード検索は大幅に向上、多言語テキストはほぼ横ばい
初代EmbeddingGemmaとの違いが最もはっきり表れているのがコード検索だ。Googleが公開したモデルカードでは、MTEBのコード評価が68.76から78.68へ上昇した。一方、多言語テキストの評価は61.15から61.36への小幅な上昇にとどまる。
| Google公表の評価 | EmbeddingGemma初代 | EmbeddingGemma 2 | スコア差 |
|---|---|---|---|
| MTEB多言語v2、タスク平均 | 61.15 | 61.36 | +0.21 |
| MTEBコードv1、NDCG@10のタスク平均 | 68.76 | 78.68 | +9.92 |
出典はEmbeddingGemma 2のモデルカード。第2世代の値はフル精度、768次元での評価となる。
NDCG@10は、検索結果の上位10件に関連性の高い候補をどれだけ適切な順番で並べられたかを見る指標だ。コードそのものを生成する能力や、バグを修正する能力を測定したものではない。
9.92ポイントの上昇を初代の68.76で割ると、相対的な改善幅は約14.4%となる。Googleが説明する「約14%改善」は、このベンチマークスコアの比率を指す。検索処理が14%高速になったという意味でも、コードの不具合を14%多く修正できるという意味でもない。自然言語で処理内容を説明し、それに関連するコードを探すような用途でまず意味を持つ改善だ。
Googleが公開したコード検索の比較図では、EmbeddingGemma 2はQwen3-Embedding-0.6Bとpplx-embed-v1-4bを上回る一方、Qwen3-Embedding-8Bには届いていない。テキスト部分が2億7000万パラメータという小さな構成で、より大きなモデルと競える点は特徴と言えるが、8B級まで含めて最も高性能なモデルになったわけではない。
また、この順位はGoogleが公表したベンチマーク結果であり、端末上での消費電力や検索時間を同じ条件で比較したものでもない。
評価結果については、第三者のベンチマーク基盤への登録作業がまだ進行中だ。10月7日時点で、MTEBへのモデル登録PRと評価結果の提出PRはいずれも未マージとなっている。
Google側の開発者は、評価時に使った指示文の正確な構成は公開できないとしつつ、指示自体は提供済みのプロンプトから作られており、MTEBとSentenceTransformersを使って結果を再現できると説明している。一方、MTEB側からは再現性を確保するため、指示テンプレートや実装方法をより明確にするよう求める意見が出ている。
したがって、現時点の数値は「誤りが判明したスコア」ではないが、MTEB側で正式に登録・検証が完了した値でもない。Googleが公開した評価値として扱い、今後の登録結果を確認するのが妥当だ。
Qwen3-Embedding-0.6Bは、テキストとコードを対象とする約6億パラメータのモデルで、最大32Kトークンの入力と最大1024次元の出力に対応する。EmbeddingGemma 2の8Kより長い入力を一度に処理でき、同シリーズには4Bと8Bの大型モデルもある。
コードを小さな単位に分割して端末内で索引化する用途なら、EmbeddingGemma 2の小ささを生かせる。一方、長い文書や大きなコードファイルを一度に処理したい場合は、Qwenの32Kという入力長が重要になる。
多言語テキストでは、初代との差が0.21ポイントにとどまるため、検索精度そのものが大幅に向上したとは言いにくい。初代は約3億パラメータのテキスト専用モデルで、最大入力は2K、出力は768次元だった。
第2世代ではテキスト部分を2億7000万パラメータへ小型化しながら、入力長を8Kへ広げ、さらに画像・動画・音声にも対応した。多言語スコアを大きく伸ばすよりも、小型化とマルチモーダル化を同時に進めた点に意味がある。
100言語以上への対応も、日本語の業務文書で必要な検索精度を保証するものではない。導入時には、実際に扱う日本語データを使って精度を確認する必要がある。
画像と音声では、競合モデルとの順位が入れ替わる
画像評価のMIEB Liteでは、EmbeddingGemma 2のタスク種別平均スコアは64.64だった。Googleの比較図では、画像とテキストを扱うSigLIPのbase版とso400m版に加え、jina-embeddings-v5-omni-smallやBidirLM-Omni-2.5B-Embeddingを上回っている。一方、LCO-Embedding-Omni-3Bはさらに高い位置にある。
ここでは、画像分野のスコアとモデル全体の性能を分けて見る必要がある。
例えばjina-embeddings-v5-omni-smallは、全体で約17億パラメータを持ち、テキストだけでなく画像、動画、音声、PDFまで扱える。EmbeddingGemma 2の7億4000万パラメータはその半分以下だが、画像検索のスコアだけで両モデルの用途全体の優劣が決まるわけではない。
音声評価のMAEBでは、EmbeddingGemma 2は49.39を記録した。Googleの比較図ではlarger_clap_general、MuQ-MuLan-large、Qwen2-Audio-7B、Qwen2.5-Omni-3Bなどを上回る一方、jina-embeddings-v5-omni-nanoやBidirLM、LCO-Embedding-Omni-7Bには届いていない。
画像ではJinaのomni-smallを上回っても、音声ではJinaのomni-nanoが上位に来る。どの種類のデータを検索するかによって、競合するモデルも順位も変わる。
MAEBは、話し声だけでなく、音楽、環境音、音声とテキストをまたぐ検索などを含む評価だ。2026年2月に公開されたMAEBのプレプリントでは、100言語以上を含む30タスクを扱い、環境音に強いモデルが多言語音声では弱いなど、モデルごとの得手不得手も報告している。
そのため、49.39というスコアを「音声検索の正答率49.39%」と読み替えることはできない。
Googleは別のMMEB v2でも、画像57.28、視覚文書67.84、動画50.67という結果を公表している。ただし、画像と動画ではHit@1、視覚文書ではNDCG@5を使っており、MIEB Liteとも評価方法が異なる。
写真検索で高いスコアを出したからといって、図表を含む文書検索や、動画の中から特定の瞬間を探す処理まで同じ割合で優れているとは言えない。
実際にモデルを選ぶ際には、「写真に何が写っているか」を探したいのか、「音声で何を話しているか」を探したいのか、それとも「文書内の図表が何を示しているか」を探したいのかを先に決める必要がある。
Qwen、Jina、Geminiでは得意な使い方が異なる
Qwen3-VL-Embeddingは、テキスト、画像、動画を共通のベクトルへ変換する検索モデルだ。2B版は32Kの入力と最大2048次元の出力に対応し、8B版では最大4096次元まで使える。EmbeddingGemma 2より長い入力を処理できる一方、公式仕様に音声入力は含まれていない。
主要なモデルの仕様を並べると、同じ「埋め込みモデル」でも想定する検索システムが異なることが分かる。
| モデル | 公表パラメータ数 | 主な入力 | 最大入力枠 | 標準・最大出力次元 |
|---|---|---|---|---|
| EmbeddingGemma 2 | 全体740M、テキストのみ270M | テキスト・画像・動画・音声 | 8192トークンを共有 | 768、128まで短縮可能 |
| Qwen3-Embedding-0.6B | 0.6B | テキスト・コード | 32K | 最大1024 |
| Qwen3-VL-Embedding-2B | 2B | テキスト・画像・動画 | 32K | 最大2048 |
| jina-embeddings-v5-omni-small | 約1.7B | テキスト・画像・動画・音声・PDF | 32768 | 1024、32まで短縮可能 |
| Gemini Embedding 2 | 非公表 | テキスト・画像・動画・音声・PDF | 8192 | 最大3072 |
仕様は各開発元の公開資料による。モデルごとにトークンの数え方や画像・動画の処理方法が異なるため、32K対応だから日本語の文章を常に8Kモデルの4倍読める、という意味ではない。出力ベクトルの次元数も、それだけで検索精度の順位を決めるものではない。
Qwen3-VLは独自のMMEB v2評価でも高いスコアを公表しているが、視覚文書の評価用データを更新したことも明記している。Googleが公開した評価とは、モデルへの入力方法や評価条件まで完全にそろえた比較ではない。
異なる開発元が示したベンチマークの数字をそのまま引き算するよりも、「長い資料を一度に処理したい」「音声も同じ索引へ入れたい」といった用途から候補を絞る方が、実際の設計には役立つ。
Jinaのomni-smallには、既存のテキスト索引を活用しやすいという特徴がある。同社は、jina-embeddings-v5-text-smallとテキストのベクトル空間を共有しており、すでにテキスト用モデルで作成した索引を、画像や音声からも検索できると説明している。
すでにJinaのテキストモデルで大量の索引を作っている場合、マルチモーダル化のために既存データをすべて再変換せずに済む可能性がある。
一方、Jinaの公開モデルはCC BY-NC 4.0ライセンスで、商用利用については別途問い合わせるよう案内している。EmbeddingGemma 2や、ここで比較したQwenのモデルはApache 2.0で公開されているため、自社製品へ組み込む際の条件にも違いがある。
「重みをダウンロードできる」という点が同じでも、商用利用まで同じ条件とは限らない。
Gemini Embedding 2も名前は近いが、提供方法が異なる。こちらはGemini APIを通じて使うマルチモーダル埋め込みモデルで、モデルそのものの実行はGoogle側のサービスに任せる。最大3072次元のベクトルを生成でき、768次元や1536次元などにも変更できる。
端末内の写真や録音をネットワークへ送らず検索したいEmbeddingGemma 2と、クラウドAPIを使って大規模な索引を生成するGemini Embedding 2では、そもそも想定する運用方法が異なる。
入力できる量も同じではない。Gemini Embedding 2は音声を最大180秒、動画を最大120秒まで扱い、動画は最大32フレームにサンプリングする。
EmbeddingGemma 2では、テキスト、画像、音声などが共通の8192トークン枠を使う。音声は毎秒25トークン、標準設定の画像は1枚280トークンとして計算される。
付随するテキストなどがない単独入力なら、単純計算では音声は約327秒、画像は約29枚相当になる。動画についてもトークン数だけなら約58フレーム分に相当するが、配布されている入力処理の設定では、毎秒1フレーム、最大32フレームが既定となっており、それを超える場合は均等にサンプリングする。
長い録音や動画を検索対象にする場合、モデルの最大入力値だけでなく、どの単位で分割し、どの場面を索引へ残すのかという設計も重要になる。
また、同じ768次元のベクトルを出力するモデル同士でも、そのベクトルを直接比較できるとは限らない。モデルが違えば、数値が表している空間そのものが異なるためだ。
Googleも、初代のgemini-embedding-001からGemini Embedding 2へ移行する場合には、既存データを新モデルで再度埋め込みへ変換する必要があると説明している。Jinaのように既存モデルとの互換性を明示している例は個別の設計であり、「出力次元が同じなら索引をそのまま使える」という一般則はない。
ベクトルを短くすると、保存容量と検索精度の両方が変わる
EmbeddingGemma 2は、標準の768次元ベクトルを512、256、128次元へ短縮できる。これは、先頭側の次元ほど重要な情報を持つよう学習するMatryoshka Representation Learning（MRL）を採用しているためだ。
ベクトルを短くすれば保存容量と検索時の計算量を減らせるが、検索精度への影響は用途によって大きく異なる。
| 出力次元 | ベクトル成分の容量比 | 多言語MTEB v2 | コードMTEB v1 | MMEB v2総合 | 音声MSEB検索 |
|---|---|---|---|---|---|
| 768 | 1 | 61.36 | 78.68 | 59.01 | 69.54 |
| 512 | 2/3 | 61.17 | 77.24 | 58.38 | 69.18 |
| 256 | 1/3 | 60.41 | 76.18 | 56.24 | 66.76 |
| 128 | 1/6 | 57.89 | 71.41 | 45.65 | 56.71 |
出典は10月6日に公開されたEmbeddingGemma 2の次元別評価。同じフル精度モデルから出力するベクトルの次元数だけを変えた結果だ。列ごとに評価指標が異なるため、比較すべきなのは各列の中で次元を短くした際の変化となる。
Googleの公表値では、768次元から128次元へ短縮すると、MMEB v2の総合スコアは59.01から45.65へ低下する。相対的な低下率は「（59.01−45.65）÷59.01×100」で約22.6%となる。
これは正答率が22.6ポイント下がるという意味ではない。ベンチマークスコアの相対的な変化だ。
一方、コード検索では78.68から71.41となり、同じ計算で低下率は約9.2%にとどまる。ベクトルの短縮による影響が、検索対象によって大きく違うことが分かる。
256次元なら、MMEB v2総合は56.24、コードは76.18を維持する。保存するベクトルの要素数を3分の1にしながら、128次元よりも多くの検索性能を残せる。
テキストやコードの大量索引を作り、まず候補を大まかに絞り込む用途と、写真や動画から目的のデータを正確に探したい用途では、どこまで次元を削るかを別々に考えた方がよい。
保存容量への効果は単純に計算できる。100万件のベクトルを1要素4バイトのfloat32で保存する場合、ベクトル成分だけなら768次元で3.072GB、256次元で1.024GB、128次元なら0.512GBとなる。
計算は「100万件×次元数×4バイト」で、GBは10進表記としている。
ただし、これはベクトルそのものだけの容量だ。検索用の索引構造やメタデータ、元となる写真・音声・文書は含んでいない。そのため、768次元から128次元へ縮めても、データベース全体やアプリ全体の保存容量がそのまま6分の1になるわけではない。
モデルの重みそのものを小さくする「量子化」と、生成したベクトルの次元数を減らすことも別の処理だ。
さらに、ベクトルを短縮した場合はL2正規化をやり直す必要があり、検索クエリ側と保存済みデータ側の次元数もそろえなければならない。モデルカードでは、通常の推論にbfloat16またはfloat32を使うよう案内しており、float16ではNaNが発生したり検索品質が低下したりする可能性があるため、使用を避けるよう求めている。
端末内で写真や録音をまとめて検索するアプリを作るなら、まず768次元や256次元で必要な検索精度を確認し、そのうえで索引サイズとのバランスを見て次元数を決める方法が現実的だ。
一方、長い入力を一度に処理したい、すでに作った索引を再利用したいといった条件があるなら、QwenやJinaの設計も候補になる。
EmbeddingGemma 2の特徴は、単純にベンチマークで最も高いスコアを出すことではない。テキスト、画像、動画、音声を同じ検索基盤へまとめながら、必要な機能だけを読み込み、ベクトルの大きさも端末の容量や求める精度に合わせて調整できる点にある。
