コラム · · Team LATENT
写真も音声も意味で探す。EmbeddingGemma 2で変わるローカル検索
文章、写真、音声、動画を同じ検索用ベクトルで扱うEmbeddingGemma 2。生成AIとの役割の違いから、手元の資料を探す仕組み、必要なモデル容量、ベクトルを短くする条件まで、ローカル検索の使い道を整理する。
「雨の日に駅で撮った写真」を探したい。ファイル名も撮影日も覚えていない。写真、録音、メモが別々のアプリにあると、思い出した言葉と保存した資料を結びつけるだけでも手間がかかる。内容の意味から探せれば、整理の仕方を覚えていなくても候補へ近づける。
Googleが2026年10月6日に発表したEmbeddingGemma 2は、こうした検索を端末内で組むためのモデルだ。文章を生成する会話AIとは役割が違う。文章、コード、画像、動画、音声を、似た内容を比べられる数値の列へ変換する。検索対象と検索したい言葉を同じ方法で表せば、近い資料を探せる。
この記事の要点
- EmbeddingGemma 2は、異なる種類の資料を共通の768次元ベクトルに変換する検索用モデルだ。返答を書く生成LLMは、必要な場合に別途組み合わせる。
- 全体は740Mパラメータで、テキスト270M、画像170M、音声300Mからなる。不要なエンコーダを省けるため、扱う資料に合わせて構成を選べる。
- ベクトルは512・256・128次元へ短くできるが、128次元ではマルチモーダルの検索品質低下に注意が要る。端末内の検索速度や精度は、自分の資料と構成で確かめる。
見つけるAIと、返答を書くAI
埋め込みとは、内容の特徴を数値の列で表すことだ。EmbeddingGemma 2では、標準の出力に768個の値が並ぶ。たとえば検索語と写真をそれぞれ変換し、数値の列の向きが近い候補を上へ出す。768個の値を人間が読む必要はなく、アプリが類似度の計算に使う。
FIGURE 01
異なる資料を、同じ方法で比べられる形へ
文章で写真を探す場合も、検索語と資料の両方を埋め込みに変換する。
文章・コード
写真・文書画像
音声・録音
動画の場面
共通の768次元ベクトル
意味の近い候補を検索
元の画像・音声・資料を表示する
返ってくるのは、まず似ている資料の候補だ。「この録音のどこで納期を相談したか」を探して該当箇所を開く用途なら、長い返答を生成しなくても役に立つ。見つけた内容を説明文にまとめたい場合は、検索結果を別の生成LLMへ渡す。この検索と生成の組み合わせが、RAGと呼ばれる構成の基本になる。
類似度が高いことは、資料の内容が正しいという保証ではない。検索語に関係する文章でも、古い決定や否定された案かもしれない。元資料、日付、該当箇所へ戻れる画面にしておくと、利用者は候補を自分で確かめられる。
写真・録音・コードを横断して探す
使い道を考えるときは、「何でも理解するAI」より、手元で見失いやすい資料を一つ思い浮かべると具体的になる。ファイル名にない情景を言葉で探す、録音を話題で探す、関数名が分からないコードを役割から探す。検索の入力と保存した資料が同じ形式でなくてもよい点が、マルチモーダル検索の利点だ。
| 探したいもの | 検索の例 | 結果で残したい情報 |
|---|---|---|
| 写真 | 駅のホームで傘を持つ人 | 元画像と撮影情報 |
| 会議の録音 | 納期を変更すると決めた場面 | 再生位置と前後の会話 |
| 動画 | 作業手順を実演している部分 | 該当時刻と元動画 |
| コード | 期限切れのセッションを消す処理 | ファイル名と関数の周辺 |
表の検索文は、用途を説明するための例であり、LATENTが正解率を測った結果ではない。GoogleはAI Edge Galleryで、自然な言葉や画像からローカルの写真を探す例と、動画の場面を探す例を紹介している。資料の種類が違っても同じ画面から候補へ進めると、アプリを切り替えて探す手間を減らせる。
資料を準備してから検索する
端末内で検索するには、モデルを置くだけでは足りない。アプリは対象の資料を読み、必要な単位に分け、埋め込みを作って保存する。文書なら節や段落、音声や動画なら時間で区切るなど、探した結果から元の場所へ戻れる単位を決める。
FIGURE 02
準備する処理と、毎回の検索を分ける
資料側のベクトルは先に保存し、検索のたびには入力側のベクトルを作る。
事前の準備
資料を分割し、元の位置を記録
各部分の埋め込みを作る
ベクトルと位置を保存
検索するとき
検索入力を埋め込みに変換
保存したベクトルと類似度を比較
近い元資料を表示
説明文が必要なら、別の生成LLMへ
見つけた資料を渡して返答を作る。検索だけなら、この処理は不要。
Googleの実装例では、端末内のSQLiteへベクトルを保存し、コサイン類似度で近いものを探している。コサイン類似度は、ベクトルの向きの近さを比べる方法だ。検索に大規模なクラウド基盤が必須というわけではなく、資料量と応答時間に合わせて保存方法を選べる。
初回に資料を読み込む時間と、準備済みの資料を検索する時間も分けて考えたい。新しいファイルを加えたときは、その部分の索引を更新する。資料を削除したなら、検索結果から消えるように保存済みの情報も更新する。検索モデルが小さくても、アプリにはこうした日々の管理が必要になる。
使う入力だけを読み込む
740Mは、約7億4,000万パラメータという全体の規模を表す。その内訳はテキストが270M、画像が170M、音声が300Mだ。画像や音声を扱わない用途では、対応するエンコーダを省いて読み込める。テキスト検索だけなら、画像と音声の分まで常に動かす必要はない。
FIGURE 03
扱う資料に合わせてモデルを構成する
公表パラメータ数の内訳。Mは100万を表す。容量や速度を直接示す数字ではない。
270M
テキスト
文章・コードを扱う基本部分
170M
画像
画像を扱うときに加える
300M
音声
音声を扱うときに加える
テキストのみ270M ／ テキスト＋画像440M ／ テキスト＋音声570M ／ 全体740M
GoogleはPixel 11 Proの量子化構成で、テキストのみ約191MB、全モダリティで約567MBのactive RAMという値も公表した。これは公表された特定構成の値だ。写真の読み込み、動画の展開、検索用データベース、アプリ本体まで含めた総使用メモリとは分けて読む必要がある。
端末で扱えるかを判断するときは、モデルの重みだけでなく、一度に読み込む資料と索引の大きさも見る。大量の動画を最初に処理する時間、検索中の応答、電池の減り方は、それぞれ別に確かめたい。本稿では実機での処理速度や消費電力を測定していない。
出典：Googleの発表とPixel 11 Proでの公表メモリ値
6分の1になるのは何か
MRLという学習方法により、出力ベクトルは768次元から512、256、128次元へ短くできる。同じデータ型で値を保存するなら、128個の値は768個の6分の1になる。減るのは、このベクトルを構成する要素の数だ。モデル全体や元の写真が6分の1になる意味ではない。
FIGURE 04
短くなるのは、保存するベクトルの列
768次元を100%とした要素数の比率。同じデータ型で保存する場合の単純計算。
768
100%
512
66.7%
256
33.3%
128
16.7%
128次元では、マルチモーダルの検索品質が大きく下がる。短くした後の品質確認を省かない。
公式資料は、128次元を主にテキスト向けとしており、マルチモーダル品質の大幅な低下に注意を促している。写真や音声を横断する検索なら、まず768次元で比較の基準を作り、512や256へ短くした結果を同じ検索例で比べる方法が分かりやすい。小さくできる上限を、そのまま推奨設定にしないことだ。
比べるときは、欲しい資料が上位に残るか、よく似た別の資料が先に出ないかを確かめる。保存容量を節約できても、探し直す回数が増えるなら使い勝手はよくならない。どの次元数が適するかは、資料の種類と、検索で見落としたくない内容によって変わる。
検索の順位を崩さない実装
文章を検索するときは、検索する文と保存する資料に、それぞれ用途に合う短い指示を付ける。公式ガイドには検索語用と文書用、コード検索用などの形式がある。たとえば「この入力は探したい内容だ」と「この入力は候補の資料だ」を区別するために使う。画像や音声へ同じテキスト用の前置きを付けるものではない。
保存した資料と検索語は、同じモデル・同じ設定の埋め込み空間で比べる。次元数もそろえる必要があり、768次元の検索語を128次元の索引へそのまま渡して比較はできない。ベクトルを短くした後はL2正規化を行い、長さをそろえてから類似度を計算する。切り取る前の正規化だけでは、短縮後の長さは保たれない。
Sentence Transformersなどで元の重みを動かす場合、公式資料はbfloat16またはfloat32を指定し、float16を使わないよう説明している。float16ではNaNや品質の劣化が起きうるためだ。単に「半精度なら軽い」と選ばず、量子化して配布された端末向けモデルの構成とも区別する。
出典：Sentence Transformersでの公式推論ガイド
8,192トークンの入力枠があっても、長い録音や大量の画像を無制限に一度で読めるわけではない。Googleは音声や画像、動画フレームを組み合わせた入力を説明しているが、同じ入力枠を分け合う。検索結果をどの細かさで示したいかを考えて資料を区切る方が、結果の場所を確かめやすい。
最初に試す範囲を決める
最初の用途としては、よく探す資料を少量に絞り、正解が分かる検索例を用意すると判断しやすい。写真なら探したい写真、録音なら再生したい箇所を先に決める。検索語の言い換えや、似ているが違う候補も加えれば、見た目のよいデモだけで終わらず、自分の用途で使えるかを確かめられる。
資料を外部へ送らずに探したいなら、埋め込みの作成、索引の保存、類似度の計算まで端末内に置く。要約も必要になった時点で、生成LLMをどこで動かすかを決めればよい。検索した資料を自分で読める用途なら、最初から大きな会話モデルを組み合わせる必要はない。
利用できる配布物と、今後の予定も分けて見たい。モデルは公式のHugging Faceなどで提供されている。一方、Google AI Edgeの記事は、ML Kitから使えるAndroid向けサービスについて「今後数週間」と説明している。10月8日時点で、この提供予定をすでに利用できる機能としては扱わない。
ライセンス表示はApache 2.0だが、モデルカードにはGemma Prohibited Use Policyへ従う旨の記載もある。「オープン」という言葉だけで条件を判断せず、導入時にはライセンス本文と、モデルカードが示す利用条件を確認したい。
EmbeddingGemma 2で身近になるのは、手元の資料へ意味から戻る検索だ。モデルのサイズを知るだけでなく、どの資料を探し、どこへ戻りたいかを決めると、小さなローカルAIの使い道が具体的になる。
出典と確認範囲
2026年10月8日時点の一次資料に基づく解説。パラメータ数、対応次元、端末のactive RAMはGoogleの公表値であり、LATENTの実機測定ではない。図の点群は概念表示、次元の棒は要素数の計算である。モデルのダウンロードや端末へのインストール、ベンチマークは行っていない。