Gemini Embedding 2とは？料金と画像・音声の横断検索

結論：Gemini Embedding 2は「文章も画像も音声も、同じ物差しで検索できる」モデル

Gemini Embedding 2（gemini-embedding-2）は、Gemini API で初めてのマルチモーダル埋め込みモデルです。テキスト・画像・動画・音声・ドキュメントをひとつの埋め込み空間に写すため、「文章で検索して画像がヒットする」「画像で検索して該当する資料が出る」といったモダリティをまたぐ検索が、追加の変換なしで成立します。対応言語は100言語以上です。

実務でいちばん効くのは、社内資料の検索です。これまでは PDF の文章とスライドの図、現場写真、会議の録音がそれぞれ別の仕組みで管理され、横断して探せませんでした。共通の埋め込み空間に載せると、これらが1つの検索窓に収まります。

料金：テキストは100万トークン0.20ドル、無料枠もある

公式の料金表（USD・100万トークンあたり）は次のとおりです。無料枠が用意されているため、PoC の段階では実質ゼロ円で検証できます（無料枠のデータは Google のプロダクト改善に使われる点だけ注意）。

テキストだけで足りる用途なら、従来の gemini-embedding-001（$0.15 / 100万トークン、バッチ $0.075）も引き続き使えます。「安いから001」ではなく「画像や音声を混ぜるかどうか」で選ぶのが判断軸です。差額は100万トークンで0.05ドル＝日本円で10円未満なので、将来マルチモーダル化する見込みがあるなら最初から Embedding 2 で作ってしまったほうが移行コストがかかりません。

コスト感の目安

日本語の資料は目安として1文字あたり1トークン前後です。A4で1,000文字の社内文書を1万本インデックスすると約1,000万トークン＝約2ドル（テキスト）。1回作った埋め込みは作り直さない限り課金されないので、費用の山は初回のインデックス時だけです。音声・動画は桁が変わるので、まず文字起こししてテキストとして入れるか、必要な区間だけ入れるかを先に決めます。

次元数は3072が既定、768へ削っても品質は落ちにくい

Embedding 2 は MRL（Matryoshka Representation Learning）で学習されており、ベクトルの先頭部分だけを切り出しても意味が保たれる設計です。既定は3072次元ですが、output_dimensionality で 1536 や 768 に切り詰められます。公式が推奨するのは 768 / 1536 / 3072 の3つです。

ここに旧モデルとの実務的な差があります。Embedding 2 は切り詰めた次元も自動で正規化されますが、gemini-embedding-001 では自分で正規化する必要がありました。正規化を忘れると、類似度がベクトルの向きではなく長さに引っ張られ、検索結果が静かにおかしくなります。エラーにならないぶん気づきにくい、典型的な事故です。

ベクトルDBの保存量は次元数に比例するので、10万件規模でも 3072→768 で保存コストは約4分の1になります。まず768で作り、精度が足りなければ上げる、という順序が現実的です。

テキスト用途では「タスクの指示」を前に付ける

Embedding 2 でテキストを扱うときは、task_type パラメータではなくプロンプト側にタスクの接頭辞を書く方式が公式の推奨です（task_type は gemini-embedding-001 向けの指定方法として残っています）。検索用途なら「質問側」と「文書側」で書式を変えるのが定石で、同じ文章でも用途に合わせた向きのベクトルになります。

ここは実装で最も差が出るところです。質問と文書をまったく同じ書式で埋め込んでいる実装は珍しくありませんが、それだけで検索の当たりが目に見えて悪くなります。

私たちも社内ナレッジ検索や独自AIの構築でこの設計をよく扱います。記事の途中で恐縮ですが、こうした仕組みづくりのご相談も承っております。よろしければあわせてご覧ください。

最短で試す手順

1. Google AI Studio で API キーを取得する（無料枠で検証できる）。
2. models/gemini-embedding-2:embedContent にテキストを投げ、ベクトルが返ることを確認する。
3. output_dimensionality を 768 にして、保存サイズと精度のバランスを見る。
4. 質問側・文書側の接頭辞を分け、手元の実データ20〜30件で「探したいものが上位に来るか」を目視で確認する。
5. 件数が増えたら Batch API（半額）でまとめてインデックスする。

自前でベクトルDBを持ちたくない場合は、Gemini API 側で取り込み・分割・索引まで面倒を見てくれる Gemini APIのFile Searchで社内文書検索を作る方法 のほうが早く立ち上がります。File Search はテキストを gemini-embedding-001、画像・マルチモーダルを gemini-embedding-2 で処理する構成です。

導入前に押さえておく注意点

• 無料枠のデータは学習に使われる：本番の社内文書を入れる前に有料ティアへ切り替える。
• モデルを変えたら全件作り直し：埋め込みはモデルごとに互換性がない。001 と 2 のベクトルを同じ索引に混ぜない。
• 音声・動画は単価が二桁違う：文字起こしを挟むだけでコストが1/30以下になることもある。Gemini 3.5 Transcribeの文字起こしと組み合わせる構成が有効。
• 検索は「当てにいく」設計が要る：埋め込みだけで精度が出ないときは、キーワード検索との併用（ハイブリッド検索）を先に検討する。

モデルの世代や料金の全体像はGemini Flash系の料金と世代の違い、Google 側の企業向け基盤の位置づけはGemini Enterprise Agent Platformで整理しています。

社内の検索を作りたい方へ

「資料はあるのに探せない」は、多くの会社で最初にAIの効果が出る領域です。どこから手を付けるかの整理からご相談いただけます。