Gemini Embedding 2とは？料金・仕様・OpenAI比較とマルチモーダルRAG実装を解説

Gemini Embedding 2は、Googleがテキスト・画像・動画・音声・PDFの5モダリティを単一のベクトル空間へ射影する初のネイティブマルチモーダル埋め込みモデルです。2026年3月10日にgemini-embedding-2-previewとしてパブリックプレビューが公開され、2026年4月22日にモデルIDgemini-embedding-2で一般提供（GA）へ移行しました。本記事はGA版の確定仕様に基づき、5モダリティの入力上限、GA公式料金、OpenAI・Cohereとの選定比較、gemini-embedding-001からの移行判断、Python実装までを実装目線で整理します。

まとめ：Gemini Embedding 2の要点（GA版）

• ステータス／ID：2026年4月22日にGA。安定版のモデルIDはgemini-embedding-2（プレビューのgemini-embedding-2-previewは移行済み）。プレビュー期間中の仕様変動リスクは解消済み。
• 料金（100万トークンあたり・有料標準）：テキスト0.20ドル、画像0.45ドル、音声6.50ドル、動画12.00ドル。Batch APIは各50%（テキスト0.10ドル等）。無料枠あり。音声・動画はテキストの30〜60倍単価で、モダリティ選定がコストを支配する。
• 入力上限：テキスト8,192トークン／画像6枚／音声180秒／動画120秒／PDF6ページ（1ファイル）。出力は128〜3,072次元（MRL）。
• 次元縮小：GA版は768・1536次元も自動正規化される。旧gemini-embedding-001で必須だった手動L2正規化は原則不要（ベクトルDBの距離指標だけ確認）。
• 選定：画像・音声・動画を横断検索するならGemini Embedding 2が現状唯一の商用選択肢。テキスト専用でコスト最優先ならOpenAI text-embedding-3-small（0.02ドル）が依然合理的。
• 移行：gemini-embedding-001とは埋め込み空間が非互換のため全データの再エンベディングが必須。Batch API＋新旧インデックス並行運用でダウンタイムを抑える。

gemini-embedding-001からの設計転換とGA版で確定した基本仕様

Gemini Embedding 2の前身gemini-embedding-001は、2025年7月にGAとなったテキスト専用モデルです。テキスト検索では高評価でしたが、画像や動画を含むデータには別モデル・別インデックス・結果統合用のグルーコードが必要で、運用が分岐する課題がありました。Gemini Embedding 2はGeminiアーキテクチャのマルチモーダル理解を土台に、5つのメディアタイプを1モデルで処理する第2世代として設計されています。

音声・動画を文字起こしなしで直接埋め込むネイティブ処理の設計思想

従来は動画や音声を扱う際、まず音声認識で文字起こしし、そのテキストを埋め込む間接パイプラインが一般的でした。この方式は文字起こし精度に品質が依存し、話者のトーンなど非言語情報が変換段階で失われます。Gemini Embedding 2は音声を波形として、動画をモーションとして直接理解し、テキスト変換ステップを挟みません。変換で失われていた情報が保持されるため、音声・動画のセマンティック表現の質が上がります。

異なるモダリティを同一ベクトル空間に射影する仕組みと多言語対応

最大の特徴は、すべての入力を同一の高次元ベクトル空間に射影する点です。デフォルトは3,072次元の浮動小数点ベクトルで、テキストクエリで画像を検索する、動画クエリで文書を探すといったクロスモーダル検索がコサイン類似度の計算だけで成立します。テキストエンコーダと画像エンコーダを別々に訓練してから対照学習で空間を揃えるCLIP系と異なり、Gemini Embedding 2はGeminiアーキテクチャ上でエンドツーエンドに訓練され、モダリティ間の意味関係をひとつのモデルで捉えます。100以上の言語に対応し、多言語とマルチモーダルの両軸でカバレッジが広い設計です。

8192トークン入力窓がRAGチャンク設計に効く理由

テキスト入力上限は8,192トークンです。広い入力窓は、より大きなチャンクを1回で埋め込めるため、文書内の共参照や長距離依存を保持したままベクトル化できます。小さなチャンクに割ったときの「コンテキスト断片化」が減り、チャンク総数が下がることでベクトルDBのストレージとインデックス管理コストも抑えられます。ただしチャンクを大きくしすぎると検索粒度が粗くなるため、2,000〜4,000トークン程度を出発点に、文書構造とタスク粒度で調整するのが実務的です。

gemini-embedding-001とは埋め込み空間が非互換という移行前提

見落とせない制約が、前世代gemini-embedding-001との埋め込み空間の非互換です。両モデルが生成するベクトルは別空間に属し、直接比較すると不正確な結果になります。既存データをgemini-embedding-001で埋め込み済みなら、Gemini Embedding 2への移行時には全データの再エンベディングが必須です。数千件なら数分ですが、数百万件規模ではコストと時間が無視できません。移行の具体手順は後半の「業務要件別の導入判断」で扱います。

テキスト・画像・音声・動画・PDFを単一空間へ統合する5モダリティの入力仕様

Gemini Embedding 2の中核価値は、5モダリティを1つのAPIコールで処理し統一空間にマッピングする点です。各メディアに個別モデルとインデックスが必要だった構成が単一モデルに集約され、開発・運用の複雑さが下がります。まず、本番でのエラー回避に直結するモダリティ別の入力上限を押さえます。

モダリティ別の入力上限と対応フォーマット（GA版）

音声はプレビュー時の80秒からGAで180秒へ拡張されました。いずれも1リクエストあたりの上限であり、100ページのPDFなら6ページ以下のセグメントに分割して個別に送信し、得られたベクトルをベクトルDBへ格納します。

画像＋テキストのインターリーブ入力で1つの集約ベクトルを得る使い所

1つのコンテンツエントリ内にテキストと画像などを混在させて送信すると、統合された1つの集約ベクトルが返ります。ECサイトの商品なら、説明テキストと商品画像を同時に1つの埋め込みとして処理でき、画像の色合いとテキストの「パステルカラー」という記述がベクトル上で近接します。従来はテキストと画像の埋め込みを別々に生成して平均化する後処理が要りましたが、モデル内部で統合されるため精度と効率の両方が改善します。画像＋テキスト＋ハッシュタグが混在するSNS投稿の類似検索にも直接使えます。

複数エントリの個別ベクトルとポストレベル集約の使い分け

contentsに複数エントリを配列で送ると、各エントリに個別の埋め込みが返ります。一方、1エントリ内に複数パーツ（テキスト＋画像）を入れると集約ベクトルになります。判断基準は明快で、各コンテンツを独立した検索対象にしたいなら複数エントリで個別ベクトルを取得します。SNS投稿のように複数メディアで1つの意味単位を構成するなら、Googleが推奨するポストレベル集約（各メディアの個別埋め込みを取得後に平均化）が適します。大量処理ではエントリをまとめる方がAPIコール数を減らせ、Batch APIと組み合わせるとコストも下がります。

MTEBスコアの実態から読むテキスト検索精度とドメイン別の得意・不得意

ベンチマークは選定材料のひとつですが、Gemini Embedding 2は総合スコアが高い一方でタスク・ドメインによる濃淡が大きく、総合スコアだけでの判断は自社データでの実測結果と乖離しがちです。以下の数値は各評価プラットフォームの報告値であり、評価方法やデータセットで変動します。最終判断は自社データでの実測を前提にしてください。

英語検索でEloレート1605という報告値と読み方

独立評価プラットフォームAgentsetの検証では、Gemini Embedding 2は英語テキスト検索でEloレート1605を記録し、2位のzembed-1（1590）、3位のVoyage 4（1586）を上回ったと報告されています。ただし上位3モデルの差は僅かで、データセットが変われば順位が入れ替わる程度です。重要なのは総合勝率と個別データセット勝率の乖離で、最も強いSciFact（科学文献）で勝率71%、FiQA（金融QA）では51%とほぼ偶然レベルでした。学術・科学系検索に強く、金融のように専門用語と数値の一致が効く領域ではトップモデルとの差が消える、という得意不得意が明確です。

MRL次元別スコアが示すコスト対精度のバランス

Gemini Embedding 2はMatryoshka Representation Learning（MRL）を採用し、ベクトルの先頭次元に重要な意味情報が集中します。3,072次元を768・1536次元へ切り詰めても精度低下が小さく、Google公式ドキュメントのMRL次元別MTEBスコアは2,048次元で68.16、1,536次元で68.17、768次元で67.99、512次元で67.55と報告されています。1,536次元が2,048次元をわずかに上回る点は、多くの本番環境で768〜1,536次元の選択が合理的であることを示します。768次元なら3,072次元に対しストレージが約4分の1、距離計算コストも大きく下がります。次元縮小時の正規化はGA版で自動化された点を後半の実装で扱います。

FiQAで勝率51%にとどまる弱点はリランカー併用で補う

前述のとおりGemini Embedding 2はFiQAで勝率51%、MSMARCOのような汎用短文検索でも50%を下回るケースが報告され、すべてのタスクで一様にトップではありません。金融領域は正確な数値・銘柄コード・専門用語の一致が精度を左右し、セマンティック理解だけではカバーしきれません。対処はリランカーの併用です。まずGemini Embedding 2で候補を粗く絞り、次にクロスエンコーダ型リランカーで精密に再順位付けする2段階設計が有効です。768次元で高速に候補を100件程度へ絞り、フル3,072次元で再計算してからリランカーへ渡す構成も効きます。ランクフュージョンで複数検索の結果を統合するRRF（Reciprocal Rank Fusion）の仕組みとスコア計算も、この段階で組み合わせられます。

先代embedding-001との直接対決で勝率80%という世代間ギャップ

Agentsetの評価では、Gemini Embedding 2はgemini-embedding-001と直接比較して48勝6敗（勝率80%）と報告されています。テキスト専用タスクに限っても先代を大きく上回り、マルチモーダルが不要でテキスト検索だけが目的でも移行にメリットがある水準です。ただしFiQA・MSMARCOの結果が示すとおり全タスクで80%が保証されるわけではないため、移行前に自社データでリフト幅を確認してから判断してください。

OpenAI text-embedding-3・Cohere Embed v4との機能・コスト・精度の選定比較

埋め込みモデルの選定は、精度だけでなくコスト・対応モダリティ・既存エコシステムとの統合・運用の柔軟性を総合評価します。Gemini Embedding 2は多くの観点で競争力を持ちますが、テキスト専用ならOpenAI、エンタープライズ向けならCohere、セルフホスト前提ならオープンソースがそれぞれ強みを持ちます。

主要3モデルの次元数・入力上限・対応モダリティ一覧

最も顕著な差はモダリティのカバレッジです。動画・音声・PDFをネイティブに埋め込める商用モデルは、現時点でGemini Embedding 2のみです。テキスト専用の用途ならOpenAI text-embedding-3-largeも十分ですが、今後マルチモーダルが必要になる可能性があるなら、Gemini Embedding 2を基盤に据える方が将来の再設計リスクを避けられます。

テキスト単価は最大10倍差、選定は3軸で切り分ける

運用コストはデータ量に線形比例するため、単価差はスケール時に効きます。OpenAI text-embedding-3-smallは100万トークンあたり0.02ドルと最安クラス、text-embedding-3-largeは0.13ドル、Gemini Embedding 2のテキストは0.20ドルで、OpenAI smallの約10倍です。月間100億トークンならOpenAI smallの200ドルに対しGemini Embedding 2は2,000ドルと年間で約2万ドルの差になります。ただしGemini Embedding 2のBatch APIは50%割引で、バッチ主体なら1,000ドルまで圧縮できます。テキストのみで純粋にコスト最優先ならOpenAI small、マルチモーダルが要るならGemini Embedding 2、というのが基本の切り分けです。処理量・リアルタイム要件・マルチモーダル必要性の3軸で判断してください。

オープンソースを含む選定観点

オープンソースも強力な選択肢です。Alibaba Qwen3-Embedding-8BはMTEBマルチリンガルで上位、Apache 2.0で無料利用でき、NVIDIA NV-Embed-v2はセルフホストでのコスト最適化に向きます。Voyage-3.5は100万トークンあたり0.06ドルの低価格で高精度を実現します。整理すると、マルチモーダル必須ならGemini Embedding 2、テキスト精度最優先でセルフホスト可ならQwen3-Embedding-8BかNV-Embed-v2、Google Cloud基盤を利用中で統合性重視ならGemini Embedding 2、OpenAI依存ならtext-embedding-3-large、コストと精度のバランスならVoyage-3.5が候補です。単一の「最強」は存在せず、業務要件で選びます。埋め込みの前提となるベクトル検索とセマンティック検索の違いを押さえておくと、比較軸を誤りません。

Gemini Embedding 2のGA公式料金と本番適用のコスト設計

本番では、APIコスト・レートリミット・スケーラビリティが運用の成否を左右します。GA移行に伴い料金が確定したため、モダリティごとの単価とコスト最適化のパターンを押さえます。

GA公式料金表（100万トークンあたり）

参考までに、テキスト専用のgemini-embedding-001は100万トークンあたり0.15ドル（Batch 0.075ドル）です。Gemini Embedding 2で注意すべきは音声・動画がテキストの30〜60倍単価である点で、プレビュー時に一部の解説が示した「音声0.50ドル」は誤りです。音声・動画中心のワークロードは事前のコスト試算が必須になります。無料枠はプロトタイピングに十分で、本番はGoogle Cloud Billingをリンクした有料Tier（Tier1〜3でレートリミットが段階的に上がる）へ移行します。

モダリティ別のコスト試算例

テキスト10万件（1件平均500トークン＝合計5,000万トークン）を埋め込むと、標準で10ドル、Batchで5ドルです。ここに音声1万本（1本180秒＝合計180万秒）を追加すると、音声は0.00016ドル/秒で約288ドル（Batchで約144ドル）となり、テキストの約29倍のコストがかかります。動画は0.00079ドル/フレームで単価が最も高く、動画中心の設計では上限120秒への分割数がそのままコストに直結します。テキストは大量でも安価、音声・動画は件数を絞る、という配分がコスト設計の基本です。リアルタイム性が不要な初期インデックス構築や定期更新はBatch APIに寄せて半額化します。

Matryoshka次元768でストレージを約75%削減する

本番のコスト最適化では、API費用よりベクトルDBのストレージ費用に効くのがMRL次元の選択です。3,072次元のfloat32ベクトルは1件約12KBですが、768次元なら約3KBとなり、ストレージが約75%削減されます。1,000万件なら3,072次元で約120GB、768次元で約30GBとなり、月額費用に直結します。実装はoutput_dimensionalityで目的の次元数を指定するだけで、GA版は768・1536次元も自動正規化されるため追加処理は原則不要です（詳細は次章）。

Gemini APIとGemini Enterprise Agent Platformで始める導入手順とPython実装

Gemini Embedding 2はGemini APIと、Vertex AIから改称したGemini Enterprise Agent Platform（旧Vertex AI）の両方から利用できます。技術スタックとクラウド環境に応じて経路を選び、テキスト埋め込みからマルチモーダル、次元調整、フレームワーク連携までを段階的に実装します。

google-genai SDKの初期セットアップ

Gemini API経由の初期セットアップは次の手順です。Google AI StudioにGoogleアカウントでログインし、API Keysページでキーを発行して安全に保管します。次にPython環境でpip install google-genaiを実行し、環境変数GEMINI_API_KEYにキーを設定、テストリクエストで疎通を確認します。Gemini Enterprise Agent Platform経由の場合は、Google Cloudプロジェクトの作成と該当APIの有効化が加わり、既存のIAM設定・VPCネットワーキング・組織レベルのアクセス制御をそのまま利用できます。いずれの経路でもSDKは最新版を使ってください。

テキストを埋め込む基本コード

テキスト埋め込みはembed_contentにモデル名とコンテンツを渡すだけです。GA版のモデルIDはgemini-embedding-2を指定します。

from google import genai
client = genai.Client()
result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="検索対象のテキスト",
)
vec = result.embeddings[0].values  # 3072次元のfloat配列

複数テキストはcontentsにリストで渡すとバッチ送信でき、個別リクエストの繰り返しよりネットワークオーバーヘッドを抑えられます。task_typeで検索クエリ用・検索ドキュメント用・分類用・クラスタリング用など用途を明示すると検索精度が変わるため、用途に合わせて指定します。

画像・音声・動画のマルチモーダル埋め込み

マルチモーダル入力は対象メディアをバイト列にしてPart.from_bytesで渡します。mime_typeを変えるだけで同じ構造のまま画像・音声・動画に対応します。

from google.genai import types
result = client.models.embed_content(
    model="gemini-embedding-2",
    contents=[types.Part.from_bytes(data=image_bytes, mime_type="image/png")],
)

音声はmime_typeをaudio/mp3やaudio/wavに、動画はvideo/mp4に変更します。大きなファイルはFiles APIで事前アップロードしてファイル参照を渡すと、Base64エンコードのメモリ負荷を避けられます。1つのコンテンツエントリにテキストPartとメディアPartを並べれば、クロスモーダルな集約ベクトルが得られます。

output_dimensionalityによる次元縮小と正規化の扱い（GA版で変更）

ストレージや検索速度の最適化で次元を縮小する場合はoutput_dimensionalityを指定します。ここがGA版での重要な変更点です。旧gemini-embedding-001では768・1536次元の出力に正規化が施されず、L2正規化を手動で適用する必要がありました。GA版のGemini Embedding 2は768・1536次元も自動正規化されるため、この手動処理は原則不要です。

from google.genai import types
result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="検索対象のテキスト",
    config=types.EmbedContentConfig(output_dimensionality=768),
)

ベクトルをそのままベクトルDBに格納して問題ありませんが、自前でクライアント側トランケーションを行う場合や、DBの距離指標がコサインを前提とする場合は、念のため格納前にノルムを確認してください。挙動が旧世代の記述と混在した解説が残っているため、正規化まわりはGA版の仕様（自動正規化）を基準に判断します。

LangChain・LlamaIndex・ベクトルDB連携でマルチモーダルRAGを構築する

Gemini Embedding 2はLangChain、LlamaIndex、Haystack、Weaviate、Qdrant、ChromaDB、Pinecone、Google Vector Searchとの連携が公式サポートされ、既存のRAGパイプラインへ組み込めます。設計手順は、対象ドキュメントをモダリティごとに分類し、テキストはチャンキング、画像・音声・動画はファイル単位で管理、各コンテンツをGemini Embedding 2で埋め込んでメタデータ（ファイルタイプ・ソースURL・作成日時など）とともにベクトルDBへ格納、検索時はクエリを同じモデルで埋め込んで類似検索、というものです。LangChainではGoogleGenerativeAIEmbeddingsにモデル名gemini-embedding-2を指定します。格納先の選定はベクトルデータベースの仕組みや、PostgreSQL上でベクトル検索を行うpgvectorの基本も判断材料になります。

RAG・クロスモーダル検索・音声ナレッジベースなど業務要件別の導入判断

導入判断はスペックやスコアだけでなく、自社の業務要件に照らした導入シナリオで描きます。代表的なユースケースごとに、メリット・設計上の考慮点・移行判断を整理します。

テキストRAG：チャンク戦略とタスク指示の非対称最適化

テキストRAGでの最大のメリットは、8,192トークンの入力窓とタスク指示の組み合わせです。従来は512〜1,024トークンで分割するのが一般的でしたが、より大きなチャンクを許容できるため境界での文脈断絶が減ります。タスク指示を使うと、検索クエリ側には「クエリの意図に最適化した表現」を、ドキュメント側には「主題と詳細を包括的に表現」する指示をそれぞれ与える非対称最適化ができ、マッチング精度が上がります。チャンクは文書構造とタスク粒度で決め、2,000〜4,000トークン＋300〜500トークンのオーバーラップが出発点です。

カスタマーサポート：スクリーンショットから類似チケットを横断検索

サポート現場では、ユーザーがエラー画面のスクリーンショットを送るケースが日常的です。従来はOCRでテキスト抽出してから検索する間接方式で、配色・レイアウト・アイコンといった視覚的コンテキストが落ちて精度に限界がありました。クロスモーダル検索を使えば、スクリーンショットをそのまま埋め込み、過去チケットや技術ドキュメントとの類似度を直接計算できます。OCRが不要になり、視覚的な類似性も検索に反映されるため、テキスト一致では見つからなかった関連チケットが発見されます。既存チケット（テキスト＋添付画像）を事前に埋め込み、新規問い合わせ時にスクリーンショットをクエリにする設計が基本形です。

音声ナレッジベース：会議録音を文字起こしなしで検索する設計判断

会議録音は膨大な知識資産でありながら検索困難なデータの代表です。従来は音声認識で文字起こししてから埋め込む多段パイプラインで、コスト・遅延・精度の3課題を抱えていました。音声ネイティブ埋め込みなら文字起こしを省けますが、設計上の判断が要ります。第一に、音声上限が180秒のため、録音を180秒以下へ分割します。話者変更やトピック切り替え点で区切るのが理想ですが、まずは固定長分割から始めても構いません。第二に、テキストクエリで音声を検索する際の期待精度を事前評価します。正確なキーワード一致が必要なシナリオでは、文字起こしを併用するハイブリッド方式が安全です。前章の料金表のとおり音声は単価が高いため、対象範囲を絞る運用が現実的です。

法務ディスカバリー：画像・動画を含む証拠の横断検索での再現率向上

法務ディスカバリー（訴訟の証拠開示）での導入事例が複数メディアで報じられています。VentureBeatの報道によれば、リーガルテック企業Everlaw社がGemini Embedding 2を訴訟ディスカバリーに用い、数百万件の記録から画像・動画を含む証拠を横断検索する際の再現率（Recall）が約20%向上したとされています。従来のキーワード検索と人手レビューの組み合わせでは発見できなかった画像・動画内の証拠を特定できる点が主因です。法務は検索の網羅性が価値に直結するため、Recall向上は直接的なビジネス効果になります。ただし証拠として使う場合は再現性が求められるため、モデルバージョンの固定とベクトル保存ポリシーを含めた運用設計が必要です。なおEverlaw社の事例はVentureBeatの報道に基づき、Google公式ブログでは具体的なパートナー名は公開されていない点に留意してください。

embedding-001からの移行：全データ再エンベディングとダウンタイム最小化

gemini-embedding-001ベースのシステムから移行する場合、埋め込み空間が非互換のため全データの再エンベディングは避けられません。本番稼働中の停止は許容しがたいため、ブルーグリーンデプロイメントを応用した並行運用が推奨です。まず新しいベクトルインデックス（Gemini Embedding 2用）を既存とは別に作成し、Batch API（50%割引）で全データを再エンベディングして新インデックスへ格納します。完了後に検索精度の回帰テストで新旧を比較し、カナリアリリース方式で1%→10%→50%→100%とトラフィックを段階的に切り替えます。コサイン類似度の閾値やリランカーのパラメータは新旧の空間で異なる場合があるため、切り替え前に必ず調整してください。より高度なRAG構成を検討する段階ではOmniRAGと従来RAGの違いも参考になります。

よくある質問

Gemini Embedding 2はまだプレビューですか？

いいえ。2026年3月10日にプレビュー（gemini-embedding-2-preview）が公開され、2026年4月22日に一般提供（GA）へ移行しました。安定版のモデルIDはgemini-embedding-2です。GA移行によりプレビュー期間中の仕様変更リスクは解消され、本番組み込みが可能になっています。

Gemini Embedding 2の料金はいくらですか？

100万トークンあたり、テキスト0.20ドル、画像0.45ドル、音声6.50ドル、動画12.00ドルです（有料標準Tier）。Batch APIはいずれも50%割引で、テキスト0.10ドル、画像0.225ドル、音声3.25ドル、動画6.00ドルとなります。無料枠もあります。音声・動画はテキストより大幅に高単価のため、モダリティ構成に応じた試算が必要です。最新の正確な価格はGoogle公式の料金ページで確認してください。

gemini-embedding-001から乗り換えるべきですか？

テキスト検索だけでも先代との直接比較で勝率80%と報告されており、精度面では移行メリットがあります。ただし両モデルは埋め込み空間が非互換で全データの再エンベディングが必須です。数百万件規模ではBatch API＋新旧インデックス並行運用でコストとダウンタイムを抑え、切り替え前に自社データで精度のリフト幅を確認してから判断するのが安全です。

OpenAIのtext-embedding-3とどちらを選ぶべきですか？

画像・音声・動画を横断検索するならGemini Embedding 2が現状唯一の商用選択肢です。テキスト専用でコスト最優先なら、100万トークンあたり0.02ドルのOpenAI text-embedding-3-smallが依然合理的です。今後マルチモーダルが必要になる可能性があるなら、再設計リスクを避けてGemini Embedding 2を基盤に据える判断もあります。

768次元に縮小したとき正規化は必要ですか？

GA版のGemini Embedding 2は768・1536次元も自動正規化されるため、原則として手動のL2正規化は不要です。output_dimensionalityで次元を指定して返ったベクトルをそのまま格納できます。旧gemini-embedding-001では手動正規化が必要だったため、その前提で書かれた古い解説と混同しないよう注意してください。自前でトランケーションする場合のみ、格納前にノルムを確認します。

関連記事

• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理
• ベクトル化とインデックス構造から理解するベクトルデータベースの仕組み
• RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説
• pgvectorの基本概要とPostgreSQLにおけるベクトル検索の重要性
• OmniRAGとは？基本概念と従来のRAGとの違い