手順書はPDF、位置は写真、作業は動画に分かれている
現場から「この装置のフィルター交換手順が分からない」と連絡が来たとします。手順書はPDF、取り付け位置は写真、去年の作業は動画、原因を話した会議は録音です。
PDFだけを検索する画面では、写真と動画は結果に出ません。担当者は、ファイルの種類とフォルダを知っていないと探せません。
2026年10月6日、Google DeepMindは EmbeddingGemma 2 を公開しました。文章、ソースコード、画像、音声、動画を、同じ形式の数値に変換する埋め込みモデルです。この記事では、その数値で何をまとめて検索できて、何はこれまでどおり設計が必要かを整理します。発表は EmbeddingGemma 2: an open, lightweight multimodal embedding model にあります。
キーワード検索とベクトル検索の使い分けは、頭が良いだけでは足りない──AIの答えは「探す設計」で決まるに書きました。この記事は、そのベクトル検索を画像・音声・動画へ広げるときの仕様と、試す順番です。数値に変換するとはどういう処理かを、先に確認します。
意味が近い情報は、数値も近くなる
埋め込みモデルは、文章や画像を数値の並び（ベクトル）に変換します。意味が近い情報は、ベクトル同士の距離も近くなります。検索は、質問のベクトルに距離が近いベクトルを見つける処理です。
次の2文で、キーワード検索との違いを確認します。Aは「パソコンの電源が入らない」。Bは「コンピュータが起動しない」。共通する単語はほとんどありません。キーワード検索で「電源」を含む文書だけを条件にすると、Bのような言い換えは結果から外れます。
埋め込みは、意味の特徴を数値にします。説明用に3つの数だけにすると、次のような並びです。実際のモデルは768個の数値で、この表の数は架空です。
| 情報 | ベクトルの例（架空） |
|---|---|
| パソコンの電源が入らない | [0.82, 0.14, 0.67] |
| コンピュータが起動しない | [0.80, 0.17, 0.65] |
| 今日の夕食を考える | [0.12, 0.91, 0.23] |
上の2つは、数の並びが似ています。夕食の文は、数の並びが違います。近さを測る代表的な計算が、コサイン類似度です。2つのベクトルの向きが近いほど、値は1に近づきます。このため、利用者が日常の言葉で質問しても、関連する文書を見つけやすくなります。
すでに多くのRAGで使われています。RAGは、登録した資料を検索し、その結果を大規模言語モデルに渡して回答を作る仕組みです。テキスト用の埋め込みが変換できるのは、文章です。画像ファイルや音声ファイルを同じ形式の数値にするには、それらを入力できるモデルが必要です。
画像用と音声用でモデルを分けると、出てきた点数をあとで合わせることになります。点数の範囲がモデルごとに違うと、検索結果の上位が画像だけ、または文章だけになります。質問の条件が増えると、1本のベクトルだけでは、正解の文書をすべて返せないこともあります。その限界は、AI検索の「完璧な夢」は終わった：埋め込みモデルが絶対に見つけられない文書がある理由に整理しました。画像や音声を追加しても、1件につきベクトルは1本です。型番、固有名詞、数値の一致は、キーワード検索やデータベース検索と併用します。
この変換を、画像や音声でも同じ形式の数値で行うモデルが EmbeddingGemma 2 です。
EmbeddingGemma 2は、種類が違っても同じ768個の数値を出す
テキスト用の埋め込みとの違いは、画像、音声、動画も、同じ768個の数値に変換することです。モデルカードは、テキスト（コードを含む）、画像、動画、音声、およびそれらの組み合わせ、と書いています。もとにしているモデルは Gemma 4 です。詳細は EmbeddingGemma 2 model card と論文 EmbeddingGemma 2: Unified and Efficient Multimodal Representations にあります。重みは google/embeddinggemma-2 で公開されています。
パラメータ数は約7億4,000万です。内訳は、文章とコードの本体が約2億7,000万（変換を担う部分が約1億3,000万、埋め込み用が約1億4,000万）、画像と動画の視覚エンコーダーが約1億7,000万、音声エンコーダーが約3億です。視覚エンコーダーは、画像、PDFのページ、スライド、図表、動画のフレームを処理します。ページは画像として登録でき、抽出した本文と併用することもできます。音声エンコーダーは、文字起こしを経由せず、音声ファイルを直接入力にします。画像用と音声用の出力は、その後、共通の変換モデルを通り、768個の数値になります。モデルカードのプーリングは平均です。複数のトークンは、最後に1本のベクトルへまとめられます。
全部を毎回読む必要はありません。読む範囲は、次の4つから選べます。
| 読み込むもの | パラメータ数の目安 |
|---|---|
| 文章とコードだけ | 2億7,000万 |
| 文章とコードに、画像・動画を加える | 4億4,000万 |
| 文章とコードに、音声を加える | 5億7,000万 |
| すべて | 7億4,000万 |
この4つは、どれも768個の数値を出力します。開発者ガイドは、文章だけを読み込んだ設定で作った質問ベクトルを、全機能を読み込んで作った文書ベクトルと直接比較できる、と説明しています。あとから画像検索を追加するとき、計算済みの文章ベクトルを作り直す必要はない、とも書いてあります。説明は EmbeddingGemma 2: The Developer Guide です。
前世代の EmbeddingGemma は文章向けでした。Googleは、ダウンロードが2,000万回を超えた、と発表文に書いています。今回は、文章に加えて画像、音声、動画も変換できます。このモデルが作るのは検索用の数値です。回答の文章は、別の生成モデルが書きます。
仕様の次に、導入前の確認が2つあります。1つは学習データです。学習に使ったデータの時点は2025年1月、とモデルカードにあります。これは、モデルが学習時に見た公開情報の範囲です。社内の手順書は、この日付より新しくても検索できます。検索されるのは、こちらが渡したファイルです。古い版が出るかどうかは、ファイルの更新日と、索引を更新した日時で決まります。
もう1つはライセンスです。利用条件は Apache 2.0 です。発表文は、商用を含む利用ができるライセンスだ、と書いています。同時にモデルカードは、Gemma の禁止用途ポリシーに従うよう求めています。導入前に、禁止用途ポリシーと社内の利用規定を照合します。
同じ形式の数値でも、公開された精度は種類ごとに違います。
公開された精度は、情報の種類ごとに違う
モデルカードの公開評価（全精度、768次元）は、次のとおりです。指標も行ごとに違います。
| 対象 | ベンチマークと指標 | EmbeddingGemma 2 | 前世代 |
|---|---|---|---|
| コード | MTEB（code, v1）の NDCG@10 | 78.68 | 68.76 |
| 多言語の文章 | MTEB（multilingual, v2）の平均 | 61.36 | 61.15 |
| 画像 | MMEB v2（Image）の Hit@1 | 57.28 | 対象外 |
| ページ画像の文書 | MMEB v2（VisDoc）の NDCG@5 | 67.84 | 対象外 |
| 動画 | MMEB v2（Video）の Hit@1 | 50.67 | 対象外 |
| 音声の検索 | MSEB（Retrieval）の MRR@10 | 69.54 | 対象外 |
出典は EmbeddingGemma 2 model card の Overall Evaluation Results です。Googleの発表は、パラメータ10億未満のマルチモーダル埋め込みとして、MTEB Code と MAEB で同規模帯の上位だ、とも書いています。上の表は、その文章の代わりにタスクごとの数値を置いたものです。リーダーボードの再集計はしていません。
コードは、68.76から78.68へ、9.92ポイント上がっています。9.92 ÷ 68.76 は約14.4%です。モデルカードの「コードタスクで前世代比およそ14%」は、この割合です。ソースコードを文章で探すときは、質問側の指示名を CodeRetrieval にします。
多言語の文章は、61.15と61.36で、ほぼ同じです。対応言語は100以上でも、性能は言語によって違います。モデルカードにも、その記載があります。日本語の社内文書は、この表のあとで、自社の質問を使って精度を測ります。
動画の Hit@1 が50.67ということは、そのベンチマークでは、正解が1位になる割合の平均が約50%です。画像の Hit@1 は57.28です。ページ画像の文書は NDCG@5 で67.84、音声の検索は MRR@10 で69.54です。指標が違う行は、数字の大小で優劣を付けません。音声には別指標の MAEB 平均49.87もあります。69.54と49.87も、指標が違うので1つの評価にはまとめません。
類似度の計算は共通です。点数の出方は種類ごとに違います。文章の点数が全体に高く、動画の点数が全体に低いと、混ぜた検索の上位は文章ばかりになります。試作では、種類ごとの順位と、混ぜたあとの順位を両方確認します。
計算は共通でも、1回に入れられる長さには上限があります。
1回に変換できる長さには上限がある
2時間の研修動画について「何分何秒か」を返すには、動画を区間に分割し、各区間の開始時刻を保存します。入力は、すべての種類で 8,192トークン を共有します。文章の1トークンは、単語をより小さく分けた単位です。モデルカードの消費量は次のとおりです。
| 種類 | 1単位あたり | その種類だけのときの上限の目安 |
|---|---|---|
| 文章 | サブワード1つで1トークン | 8,192トークン |
| 画像 | 280トークン（既定） | 約29枚 |
| 動画 | 1フレーム140トークン（既定） | 約58フレーム |
| 音声 | 1秒25トークン | 約327秒（約5.5分） |
動画の既定は、1秒あたり1フレームです。フレームレートは変更できます。音声はモノラル、16kHzです。文章を同時に入れると、画像や音声に使えるトークン数が減ります。
画像や動画のトークン数は、70から1,120の範囲で変更できます。既定より減らすと、同じ8,192トークンに画像やフレームが約114まで入ります。モデルカードに、その注記があります。トークン数を増やすと、図や細かい文字の検索には有利になりやすい、とも書いてあります。論文の比較では、動画は1フレームのトークン数を上げすぎると、入力が長くなり、平均でまとめたときに点数が下がりました。細かい箇所を取る設定と、長い動画を1回の入力にまとめる設定は、別々に決めます。
発表文の「数時間の録音を文章で探す」は、録音を区切って多数登録する使い方です。1回の入力の上限は約5.5分なので、それより長い録音は分割して登録します。2時間の動画を1秒1フレームで分割すると、約58秒ごとに1本のベクトルになります。各区間の開始時刻をメタデータに保存すると、「12分40秒付近」と返せます。区間を長くすると、その中の短い場面は、平均した1本のベクトルでは区別しにくくなります。
この上限を守って登録すれば、ファイル形式を指定しない検索ができます。
ファイル形式を指定しないと、検索結果に何が出るか
質問が「フィルターを交換する方法」なら、手順書に加えて、交換場面の動画や、取り付け位置の写真も候補に入ります。探す前に「PDFか、動画か」を指定する操作は減ります。ファイルの前処理、動画の分割、アクセス権限、精度の確認は、これまでどおり必要です。
社内資料は、報告書も写真も同じ結果に入る
会議は録音、手順はPDF、作業は動画、製品の状態は写真、という保存の仕方はよくあります。質問が「昨年の装置異常の原因と対応」なら、報告書、現場写真、会議の一部、修理動画が同じ検索結果に入ることがあります。
どのフォルダにあるかを知らなくても、保存済みの記録が検索結果に出ます。その記録の内容が正しいかは、別に確認します。版と更新日は、メタデータとして保存します。
長い動画は、分割した区間が候補になる
技術研修が100本、各2時間、とします。「データベースのデッドロックを説明している場面」を探すとき、これまではタイトル、説明文、字幕を検索していました。映像と音声もベクトルにすれば、説明文がない区間も候補になります。
前の節のとおり、2時間を1本のベクトルにはしません。検索結果に出るのは、約58秒などに分割して登録した区間です。その区間がデッドロックの説明かどうかは、人が再生して確認するか、後段のモデルに確認させます。埋め込みが返すのは、区間の開始時刻です。区間の中のどの秒かは、再生して確認します。正確な字幕がすでにある場合は、その文字のキーワード検索も使います。型番や関数名は、音声の類似度より、文字のキーワード検索のほうが正確です。
安全教育の動画も、同じ方法で探せます。質問が「人が転倒しそうになっている場面」なら、場面の説明文が少なくても、映像の数値と質問の数値を比較できます。監視カメラの映像を対象にする場合は、検索精度の確認より前に、利用目的と閲覧権限を決めます。
写真から、手順書と過去の作業動画を出す
故障した部品の写真を入力し、似た写真、保守マニュアル、過去の作業動画を表示する、という流れです。以前から、画像用モデルと文章用モデルを組み合わせれば作れました。共通のベクトルにすると、組み合わせたあとに必要だった点数の調整を減らせます。
見た目が似ていても、型番が違うことがあります。型番と製造番号は、キーワード検索かデータベースで照合します。ベクトル検索の上位は、人が確認する候補の一覧です。
研修資料も、同じ質問で候補にできる
社内研修や授業でも、プリント、録画、実験の写真、説明の音声、発表資料が別々のファイルになります。「三角比が実際に使われている例」という質問に、文章の教材に加えて、測定の動画や写真を候補にする、という使い方です。
類似度が高い教材が、その人の理解度に合うとは限りません。対象者、難易度、単元をメタデータに保存し、類似度の計算のあとに絞ります。資料を全部入れないこと、使える人を分けることは、校内チャットボットを作るときに知っておきたいことに書きました。ファイル形式が増えても、入れる資料の範囲と、使える人の確認は必要です。
ここまでが、検索結果に出るものの話です。次は、システム側で減る作業と、減らない作業です。
減るのは、モデルごとの点数をあとから合わせる処理です
これまでの構成と、共通のベクトルにしたあとの構成を並べます。
| 処理 | 分かれやすい構成 | 共通のベクトルで減ること |
|---|---|---|
| 文章 | テキスト用埋め込み | 別モデルの点数を後段で合わせる処理 |
| 画像 | 画像用埋め込み | 同上 |
| 音声 | 音声認識のあとテキスト埋め込み、または音声専用 | 文字起こしを挟まない経路を選べる |
| 動画 | フレーム抽出、画像モデル、音声認識の結合 | フレームと音声を同じモデルへ渡せる |
| 結果の統合 | モデルごとの点数を調整し、再ランキング | 同じ次元なら類似度を直接比べやすい |
減らせるのは、主に、モデルごとに違う点数をあとから合わせる処理です。画像の大きさの調整、動画の分割、音声のサンプルレート、ファイルの保管、アクセス権は必要です。特定の種類だけ高い精度が必要なら、専用モデルを残す選択もあります。専用モデルをやめるのは、自社のデータで、共通モデルの精度が足りると確認できた処理だけです。
試す前に決める設定は、読み込む範囲、ベクトルの次元、数値の型の3つです。
試す前に、読み込む範囲と次元と数値の型を決める
サンプルの実装には sentence-transformers を使います。開発者ガイドは 6.1.0 以降を案内しています。画像、音声、動画を扱う場合は、追加の依存も含めてインストールします。初回の実行では、Hugging Face から重みを取得します。
pip install -U "sentence-transformers[image,audio,video]" transformers
必要なエンコーダーだけを読み込む
次のコードは、音声エンコーダーを読まず、質問文と写真を比べます。この読み込みは約4億4,000万パラメータで、動画フレームも同じ視覚エンコーダーで扱えます。次元は256に短くしてあります。短くする理由と、短くしたあとの正規化は、次の小見出しで確認します。手順書の細かい図を主な対象にする場合は、同じ引数を768のままにします。ファイル名は例です。そのパスに画像があることが、実行の条件です。
from sentence_transformers import SentenceTransformer
model = SentenceTransformer(
"google/embeddinggemma-2",
config_kwargs={"audio_config": None},
)
query_emb = model.encode(
"この装置のフィルターを交換する手順",
prompt_name="SearchQuery",
truncate_dim=256,
normalize_embeddings=True,
)
image_emb = model.encode(
{"image": "filter_location.jpg"},
truncate_dim=256,
normalize_embeddings=True,
)
print(model.similarity(query_emb, image_emb))
文章の検索では、質問と文書で指示を分けます。SearchQuery は質問側、Document は文書側です。Document はタイトルなしの形式になります。タイトルがある文書は、title: 手順書 | text: 本文 のように自分で整形します。画像、音声、動画には、この指示を付けません。コード検索だけは CodeRetrieval を使います。一覧はモデルカードの Task Instruction Prefixes です。文章と画像と動画を1つのベクトルにまとめるときは、本文中の位置を <|image|> や <|video|>、<|audio|> で示します。呼び方の例は、開発者ガイドの Step 3 にあります。
上のコードの audio_config: None が、約4億4,000万パラメータの読み込みです。文章だけなら、視覚も音声も None にします。索引を文章で始めて、あとから画像を加えるときは、エンコーダーを加えて読み直します。既存の文章ベクトルの再計算は、開発者ガイドの説明では不要です。質問側を文章だけの設定で埋め込んでも、全機能で埋め込んだ画像と、次元が同じなら比較できます。
読み込むときの数値の型は、bfloat16 か float32 です。モデルカードは、float16 を使わない、と書いています。計算途中の数値が float16 で表せる範囲を超え、NaN になるか、エラーなしで精度が落ちるためです。GPUが bfloat16 に対応するなら bfloat16、多くのCPUでは float32 を使います。
次元は、質問と登録データで同じにする
出力の既定は768次元です。Matryoshka Representation Learning は、768個の数値の先頭だけを使っても検索できるようにする学習方法です。使える長さは512、256、128です。384は、モデルカードの対応リストにありません。コードの truncate_dim=256 は、この先頭256個を使う指定です。
次元を短くしたあとは、ベクトルの長さを1に戻す正規化が必要です。コードの normalize_embeddings=True が、その処理です。正規化しないままコサイン類似度を計算すると、エラーにはなりません。順位だけが悪くなります。質問と登録データの次元も、同じにします。768次元の質問は、128次元で保存したデータと比較できません。
保存量の公式例は、bfloat16 で100万件です。768次元が約1.5GB、128次元が約250MB、で約6分の1、と開発者ガイドは書いています。計算は、100万 × 768 × 2バイト = 15億3,600万バイトで、10進のGBなら約1.54GBです。128次元は100万 × 128 × 2バイト = 2億5,600万バイト、256MBです。ガイドの約250MBは、この概数です。検索インデックスやメタデータは含みません。float32で保存するとバイト数は2倍になり、768次元の100万件は約3.07GBです。
モデルカードの切り詰め評価（同じ出典の表）では、次元を下げたときの平均は次のとおりです。
| 次元 | コード MTEB | 多言語テキスト MTEB | MMEB v2 全体 | 音声 MSEB Retrieval |
|---|---|---|---|---|
| 768 | 78.68 | 61.36 | 59.01 | 69.54 |
| 256 | 76.18 | 60.41 | 56.24 | 66.76 |
| 128 | 71.41 | 57.89 | 45.65 | 56.71 |
256次元の MMEB 全体は 56.24 / 59.01 で、768次元の約95%です。開発者ガイドの「256次元でも、画像・動画・音声の検索品質の約95%」は、この計算と一致します。コードは 76.18 / 78.68 で約97%です。128次元の MMEB 全体は 45.65 / 59.01 で約77%です。開発者ガイドは、文章とコードは約90%が残り、画像・動画・音声は約75%まで下がるため、ファイルの種類をまたぐ検索に使う前に、自分たちのデータで確認する、と書いています。128次元は、文章だけの索引か、再ランキングの前に候補を減らす段階向けです。PDFのページ画像や動画を主な対象にする場合は、まず768か512を使います。
ここまでの容量は、保存するベクトルの話です。次は、モデル自体をメモリに載せるときの話です。
モデルのメモリと、検索データの容量は別です
量子化は、重みをより少ないビットで持つ手法です。7億4,000万パラメータを、重みだけ均等に数えると、16ビットで約1.48GB、8ビットで約740MB、4ビットで約370MBです。これは重み配列のサイズです。実行中の中間データ、実行系、視覚と音声でビット数が違うことは入っていません。
論文は、量子化を想定した追加学習済みのチェックポイントについて、Google Pixel 11 Pro 上のピークメモリを書いています。実行時コンパイルのオーバーヘッドを含みます。文章だけが191MB。文章と視覚が447MB。全種類が567MBです。発表文の約191MBは文章だけ、約567MBは全種類の値です。370MBは、重みだけを4ビットで数えた値です。447MBは、文章と画像を動かしたときの実測です。導入時は、使う機器で測った値を使います。
100万件を128次元にすると減るのは、前の小見出しで計算した検索データの容量です。モデル本体の大きさは変わりません。
設定が決まっても、検索で取った資料から回答の文章を書く処理は別です。
近い資料を取る処理は共通にできる。回答の文章は別です
テキスト中心のRAGは、次の順で動きます。文書を長さで分割する。各断片をベクトルにする。ベクトルデータベースへ保存する。質問もベクトルにする。距離が近い断片を取得する。その断片を大規模言語モデルへ渡して文章を作る。
業務の根拠には、図、写真、録音、動画も入ります。マルチモーダルな埋め込みを使うと、このうち「距離が近い資料を取得する」までを、同じ索引で行いやすくなります。取得のあとが、別の処理です。
動画の内容を文章にするのは、生成モデルか字幕です
見つかった区間の説明は、動画を入力できる生成モデルか、区間に付けた字幕・手順文が行います。EmbeddingGemma 2を Gemma 4 と組み合わせると、テキストのトークナイザと音声エンコーダーの系統を共有でき、合計メモリを抑えやすい、と発表文は書いています。メモリを抑えられることと、説明文が正しいことは同じではありません。説明文は、生成結果か、人が付けた字幕で確認します。
権限のないデータは、結果を返す前に外す
会議録音や現場写真には、個人や設備の情報が入ります。権限の判定は、ベクトルへ保存したあとも、検索結果を返す前に行います。除外条件は、索引のメタデータに保存します。取り込み時の前処理と、メタデータによる権限制御は、【社内RAG構築】「ハルシネーション」を殺すためのデータ前処理とアーキテクチャ (応用編)に書きました。画像・音声・動画を同じベクトルにしても、外すタイミングは同じです。保存場所、利用目的、保持期間は、ファイルの種類を増やす前に決めます。
意味が近い手順が、正しい手順とは限らない
権限を通った候補でも、手順が正しいとは限りません。生成モデルは、近い候補を自然な文章にまとめます。候補が別の部品の手順だと、文章が読みやすくても手順は違います。回答には、どのファイルのどの区間かを付けます。型番は、キーワード検索かデータベースで照合します。
この3つを確認したうえで、本番の索引をすぐには置き換えません。
本番の索引は残し、小さい索引で7項目を確認する
最初の対象は、今検索できていない種類を1つにします。たとえば、手順書は検索できるが、作業写真は検索できない、という場合です。対象は文章と画像だけにします。件数は、人が正解を付けられる範囲にします。
確認する項目は、次の7つです。
| 項目 | 確認すること |
|---|---|
| 検索精度 | 用意した質問で、正しい資料が上位に入るか |
| 横断 | 文章の質問から、関連する写真が出るか。写真から手順書が出るか |
| 種類の偏り | 上位が文章だけ、または写真だけになっていないか |
| 応答 | その件数で、待てる時間に返るか |
| メモリ | 想定する機器で、選んだエンコーダーと次元が載るか |
| 厳密な一致 | 型番や固有名詞を、キーワード側が拾っているか |
| 権限 | 権限のない写真が、ベクトルに入っていても結果に出ないか |
精度の指標は、目的で使い分けます。Recall@k は、正解が上位k件に入っている割合です。Precision@k は、上位k件のうち正解である割合です。MRR は、最初の正解が何位かで、1位なら1、2位なら2分の1です。nDCG は、上位ほど重く見たときの並びの良さです。公開ベンチマークの NDCG@10 が78.68であることと、自社の質問で Recall@5 が足りることは、別の測定です。
専用モデルとの比較も、同じ質問セットで行います。処理の数が減っても、必要な写真が結果から漏れるなら、画像側は専用モデルのままにします。採用する基準は、テスト用の質問で、正しい資料が上位に出ることです。
7項目のうち、最初に見るのは「横断」と「権限」です。本番の索引はそのままにして、別の小さい索引で試します。文章と画像を数十件、正解付きの質問を10件前後用意します。次元は256か768で、質問と登録データを同じにします。この2つの結果を確認してから、音声と動画の分割方法を決めます。
作成日: 2026-11-03