ONE-PAGE BRIEF
探し物の内容を言葉にし、近い候補から元資料へ戻る
対象となる二つの検索課題と、仕組み・評価・構成の要点を一枚にまとめた。
WHAT IT IS
コード・画像・音声・動画を、端末内で探すモデル
EmbeddingGemma 2は、情報を意味の近さで探すための埋め込みモデル。テキストとコードに加え、画像・音声・動画の入力を共通の数値表現に変える。Google DeepMindがGemma 4をベースに開発し、Apache 2.0で公開した。
検索アプリの中では、資料を索引に入れる処理と、検索文を変換する処理を担当する。検索結果から回答文を作る場合は、別の生成モデルを組み合わせる。
公式ブログの公開日は2026-10-06。本ページは10/7編集号であり、公式ページに正確な公開時刻は記載がない。
一次出典：[1] 発表 ・ [2] モデルカード ・ [7] ライセンス
WHO THIS HELPS
関数名を知らない人と、資料の場所を忘れた人へ
エンジニア：処理の内容から関連コードを探す
「失敗した送信を、間隔を空けて再試行する処理」は分かるが、関数名やファイル名が分からない。自然言語の説明とコード片を照合する検索の候補になる。
PM・検索担当：媒体をまたいで説明や場面を探す
「保存に失敗した場面を説明していた資料やデモ録音」を、文書・画面画像・音声・動画の区間から探す。見つけた候補を元資料や対応する場面で確かめる。
上記は編集部が作った架空の業務例。実際の検索結果や、導入後の時間短縮を示すものではない。
一次出典：[3] 開発ガイド ・ [5] AI Edge
THE PROBLEM
完全一致と媒体ごとの検索だけでは、探し方が限られる
キーワード検索は、関数名・ID・製品名を正確に指定する場面に強い。一方、検索文と対象の言い回しが違うと、必要な情報を見逃すことがある。埋め込み検索は意味の近さから候補を拾う手段を加える。
文書・画像・録音が別の検索機能に分散している場合、共通のベクトル空間を使う設計で、媒体をまたぐ候補検索を組み立てられる。媒体別の取り込みや、原本への参照は引き続き必要だ。
埋め込み計算を端末内に置けば、その処理の外部送信と通信依存を減らせる。完全にオフラインで使うには、検索の索引や回答生成、ログも含めた構成を確認する。
一次出典：[1] 発表 ・ [3] 開発ガイド ・ [5] AI Edge
HOW SEARCH WORKS
検索文と対象を変換し、近い候補から元資料へ戻る
- 1 検索文と対象コードは関数やファイル、文書は段落、音声・動画は区間など、検索して開き直せる単位にする。
- 2 意味ベクトル検索文と各対象を同じモデル空間の数値列に変換する。標準の出力は768次元。
- 3 近い候補検索用の索引に保存したベクトルと照合し、類似度で候補を順位付けする。
- 4 元資料・場面ファイルや対応する時間の区間を開いて内容を確かめる。回答文が必要なら別モデルを使う。
検索文と資料では、役割に合う指示名を使う。通常の検索はSearchQueryとDocument、コード検索の質問にはCodeRetrievalを使う。画像・音声・動画の入力にテキスト用の接頭辞を付けない。
この説明と図は編集部の概念図。EmbeddingGemma 2による検索を、このページでは実行していない。
一次出典：[2] モデルカード ・ [3] 開発ガイド ・ [4] 推論ガイド
WHAT CHANGED
コード評価は改善。多言語テキストはほぼ横ばい
Googleの提供元評価では、EmbeddingGemma 1から2への変化はコード検索の改善と、画像・音声・動画への拡張が目立つ。多言語テキストの総合評価は小幅な変化だった。
| 同じベンチマーク内の比較 | EmbeddingGemma 1 | EmbeddingGemma 2 | 変化 |
|---|---|---|---|
| MTEB Code v1 NDCG@10のタスク平均 | 68.76 | 78.68 | +9.92ポイント |
| MTEB multilingual v2 複数指標のタスク平均 | 61.15 | 61.36 | +0.21ポイント |
この数値はGoogleの評価報告。独立追試と、日本語の業務データでの精度は未確認。コードと多言語テキストの行は異なる評価であり、行同士の数値から性能の優劣は判断できない。
一次出典：[1] 発表 ・ [2] モデルカード
SIZE AND QUALITY
270Mから740M。短いベクトルは容量と品質の交換になる
必要な入力に応じて、エンコーダーを省略できる。テキストとコードだけなら270M、画像を加える構成は440M、音声を加える構成は570M、全構成は740Mパラメータ。Mは百万を表す。
全構成の内訳は、テキスト・コード270M、画像170M、音声300M。パラメータ数は必要RAMを表す値ではない。実際のメモリー使用量は、数値精度、実行環境、入力と索引を含む構成で変わる。
MRLは、768次元のベクトルを512・256・128次元へ短くする仕組み。同じ数値型なら、256次元のベクトル本体は768次元の1/3、128次元は1/6になる。索引の管理情報やモデルの重みまで同じ比率で減るとは限らない。
| 出力次元 | ベクトル本体の比率 | MMEB v2 Overall | MTEB multilingual v2 |
|---|---|---|---|
| 768 | 1 | 59.01 | 61.36 |
| 256 | 1/3 | 56.24 | 60.41 |
| 128 | 1/6 | 45.65 | 57.89 |
MMEBとMTEBは別のベンチマーク。列をまたいで同じ「精度」として比較しない。独立追試は未実施。128次元でのマルチモーダル品質の低下も、選択時に考慮する。
一次出典：[2] モデルカード ・ [3] 開発ガイド
A SMALL TRIAL
同じ質問と正解候補で、既存検索と比べる
最初は架空の資料とコードで、小さな比較を設計する。以下は編集部の試行案。モデルの実行結果や測定値を含まない。
- 質問と正解候補を先にそろえる
言い換えで探す質問、関数名・IDで探す質問を用意する。正解のコード片や資料を、人が先に決める。
- 同じ対象で検索方式を比較する
キーワード検索、既存の埋め込みモデル、EmbeddingGemma 2を比べる。テキスト・コードの索引から始め、媒体を追加する際も同じ評価用の質問と正解候補を使う。
- 検索品質と端末の負荷を記録する
正解が上位候補に入る質問の割合、待ち時間、RAM使用量を測る。初回の取り込み・索引作成と、普段の検索の待ち時間を分ける。
- 容量が問題になったら次元を比較する
まず768次元を基準にする。256次元などとの品質差を、同じ質問・候補数・対象端末で測る。検索ヒット率の定義と候補数も記録する。
実装前に読む公式の設定条件（説明用・未実行）
- 開発ガイドはSentence Transformers 6.1.0以降を案内。バージョンと実行環境を確認する。
- 通常のロードは全エンコーダーを読み込む。テキスト専用は公式設定名
config_kwargs={"vision_config": None, "audio_config": None}で、不要な入力のエンコーダーを明示的に無効化する。 - 一般検索は
SearchQuery、資料はDocument。コード検索の質問はCodeRetrieval。Documentはタイトルなしの形式を付けるため、実際のタイトルを使う場合は公式の書式に合わせる。 - 推論の数値精度は
bfloat16またはfloat32。float16は使わない。 - 次元を短くした後はL2正規化し、質問と資料を同じ次元にする。公式は
truncate_dimとnormalize_embeddings=Trueを案内。 - 入力の上限は共通の8,192トークン。媒体を混在させる場合も、この枠を共有する。
ここに示した設定名は公式資料の説明用。インストール、モデルのダウンロード、推論は本ページでは実行していない。
一次出典：[2] モデルカード ・ [3] 開発ガイド ・ [4] 推論ガイド
一次出典：[2] モデルカード ・ [3] 開発ガイド
THE DECISION
完全一致・旧モデル・クラウドAPIとの比較が導入判断になる
関数名・IDが分かる
キーワード検索を併用する。意味検索だけで識別子の完全一致を置き換えるかは、評価用の質問で確かめる。
旧EmbeddingGemma 1
コード検索や新しい媒体が必要なら、移行効果を測る。テキスト中心の用途では、品質差と索引の移行にかかる手間を比べる。
クラウドAPI
検索品質、通信の待ち時間、API利用料と端末内での運用コストを比べる。モデルのライセンスだけで、総運用費は決まらない。
完全ローカルの設計
ベクトルストア、回答生成モデル、ログ、テレメトリーまで配置と送信先を確認する。埋め込みモデル単体の導入で、プライバシーや規制への適合を保証できない。
Apache 2.0は商用利用を含む利用条件の確認先になる。採用時にはライセンス本文も確認する。AndroidのML Kit経由の提供は、10/6の公式記事では今後数週間の予定とされている。
一次出典：[2] モデルカード ・ [3] 開発ガイド ・ [5] AI Edge ・ [7] ライセンス