GoogleはGemini APIのテキスト埋め込みモデルgemini-embedding-001を、2026年7月14日に停止する。推奨移行先はgemini-embedding-2である。

期限だけを見ると、これはモデルIDを変更する小規模なAPI移行に見える。しかし、埋め込みモデルの変更は生成モデルの置き換えよりも基盤への影響が深い。埋め込みは検索インデックスそのものを構成する座標系であり、モデルが変われば既存ベクトルと新しいクエリベクトルの意味的な位置関係を保証できない。

したがって、正しい移行単位はAPI呼び出しではなく、文書分割、前処理、ベクトル生成、保存、検索、再ランキング、回答生成までを含む検索パイプライン全体である。

確認できた変更

Googleの公式資料から確認できる主な差分は次の通りである。

項目gemini-embedding-001gemini-embedding-2
提供状態2026年7月14日に停止一般提供
主な入力テキストテキスト、画像、動画、音声、PDF
複数入力文字列リストから個別ベクトルを返せる複数入力は1つの集約ベクトルになるため、個別処理はBatch API等が必要
タスク指定task_typeフィールドプロンプト内のタスク指示
標準次元30723072
次元削減output_dimensionalityoutput_dimensionality
非標準次元の正規化手動正規化が必要自動正規化
検索用途テキスト検索中心クロスモーダル検索へ拡張可能

特に注意すべきなのは、API形状が似ていても意味的な互換性はないことである。gemini-embedding-001で生成した文書ベクトルの集合に、gemini-embedding-2で生成したクエリベクトルを投入しても、検索品質は保証されない。

なぜ全件の再埋め込みが必要か

埋め込みモデルは、入力を高次元空間の座標へ変換する。類似した内容が近い座標へ配置されるよう学習されているが、その座標軸に共通の標準はない。

同じ3072次元であっても、旧モデルの第1要素と新モデルの第1要素が同じ意味を表すわけではない。次元数が一致することは、同じベクトルデータベースへ保存できることを意味するだけで、距離計算に意味があることを意味しない。

移行時に次の構成を作ってはならない。

文書ベクトル: gemini-embedding-001
検索クエリ:   gemini-embedding-2

また、新規文書だけを新モデルで埋め込み、既存文書を旧モデルのまま残す構成も危険である。同じ検索結果集合の中に異なる座標系が混在するため、スコアを比較できない。

正しい構成は、新旧のインデックスを分離する方法である。

旧インデックス
  文書: gemini-embedding-001
  クエリ: gemini-embedding-001

新インデックス
  文書: gemini-embedding-2
  クエリ: gemini-embedding-2

新インデックスの品質を確認後、検索トラフィックを切り替える。

タスク指定の変更を見落とさない

gemini-embedding-001では、RETRIEVAL_DOCUMENT、RETRIEVAL_QUERY、SEMANTIC_SIMILARITY、CLASSIFICATIONなどをtask_typeとして指定できた。

gemini-embedding-2では、同じフィールドを使う方式ではない。検索、質問応答、ファクトチェック、コード検索などの目的を、入力テキストの先頭へ指示として含める。

たとえば検索では、クエリと文書を異なる形式にする。

クエリ:
task: search result | query: 契約解除の条件を知りたい

文書:
title: 解約条項 | text: 契約期間中の解除について...

この変更は単なる構文差ではない。旧システムでtask_typeを設定していたにもかかわらず、新システムでタスク指示を削除すると、検索目的に最適化された表現を失う可能性がある。

文書側とクエリ側のテンプレートは、ソースコード内に散在させず、バージョン付きの前処理仕様として管理するべきである。

次元数は同じにすればよいのか

両モデルの標準出力は3072次元で、768、1536などへ縮小できる。既存のベクトルデータベースが768次元で設計されている場合、新モデルでも768を選べばスキーマ変更を避けられる。

ただし、同じ次元数を選ぶことと同じ検索品質を得ることは別問題である。

確認すべき項目は次の通りである。

  • 文書とクエリで同じ次元数を使っているか
  • cosine、dot product、Euclideanのどれを使うか
  • 保存前に二重に正規化していないか
  • HNSWやIVFなどのインデックス設定が新しい分布に適しているか
  • 既存の類似度閾値を流用していないか
  • 再ランキング前に必要な候補数を確保できるか

gemini-embedding-2は非標準次元でも自動正規化する。旧モデル向けに手動正規化を入れていたコードは、数値上は動作しても不要な処理になる。前処理をモデル別に明示し、暗黙の共有関数を見直す必要がある。

移行で最も時間がかかる部分

大規模RAGでは、APIコードの変更より再埋め込みに時間がかかる。

処理時間は概ね次で決まる。

  • 文書件数
  • チャンク数
  • 1チャンクの長さ
  • APIのレート制限
  • バッチ処理の並列数
  • 失敗時の再試行
  • ベクトルデータベースへの書き込み速度
  • 差分更新中に発生する新規文書量

100万文書が平均5チャンクなら、生成対象は500万ベクトルになる。停止直前に開始すると、レート制限や再試行により完了しない可能性がある。

再埋め込みジョブには少なくとも次の状態を持たせる。

pending
embedding
embedded
indexed
verified
failed_retryable
failed_terminal

「API呼び出しが成功した」だけでは完了にしない。ベクトルの次元、有限値、保存件数、文書IDとの対応、インデックス反映まで検証する。

推奨する移行手順

1. 利用箇所を棚卸しする

ソースコードだけでなく、環境変数、SaaS連携、ノートブック、バッチジョブ、評価スクリプトから次を検索する。

gemini-embedding-001
models/gemini-embedding-001
task_type
RETRIEVAL_DOCUMENT
RETRIEVAL_QUERY
SEMANTIC_SIMILARITY

2. 前処理仕様を固定する

チャンク長、オーバーラップ、タイトル付与、HTML除去、言語正規化、タスク指示、次元数を決め、設定として保存する。

移行と同時にチャンク分割まで大幅変更すると、品質差の原因がモデルなのか前処理なのか分からなくなる。最初の比較では変更点を最小化し、その後に最適化する。

3. 新しいインデックスを作る

既存インデックスを上書きせず、別名で作成する。

knowledge-v1-embedding001
knowledge-v2-embedding2

エイリアスまたはルーティング設定で切り替えられる構成にする。

4. 評価セットを作る

検索品質は目視だけで判断しない。実際の問い合わせから、少なくとも次を含む評価セットを作る。

  • 明確な単一回答
  • 複数文書を必要とする質問
  • 表記ゆれと略語
  • 日本語と英語の混在
  • 数値、型番、固有名詞
  • 否定表現
  • 類似するが不正解の文書
  • コード検索
  • 更新日時が重要な質問

5. 指標を比較する

最低限、次を新旧で比較する。

  • Recall@k
  • Precision@k
  • MRR
  • nDCG
  • 正解文書が最初に出る順位
  • 検索レイテンシー
  • 埋め込み生成費用
  • 保存容量
  • 回答生成後の正答率

最終的な目的がRAG回答である場合、検索指標だけでなく、取得文書を使った回答品質も評価する。

6. 二重検索で差分を観測する

本番クエリを旧インデックスと新インデックスへ同時に送り、利用者には片方だけ返すシャドー評価が有効である。

記録する項目は次の通りである。

  • 上位k件の重複率
  • 正解文書の順位差
  • スコア分布
  • ゼロ件率
  • 再ランキング後の順位
  • 回答の引用元差

7. 切り替えとロールバックを準備する

停止日前に新インデックスを本番化する。旧モデル停止後は旧インデックスへの新規クエリ生成ができないため、実質的なロールバック期間は停止前までである。

アプリケーションの設定だけで検索先を切り替えられるようにし、インデックス名をコードへ直書きしない。

よくある誤判断

モデル名だけ変えて動作確認を終える

HTTP 200が返ることと、検索品質が維持されることは無関係である。RAGでは誤った文書が自然な文章で回答へ混入するため、障害として見えにくい。

既存ベクトルをそのまま使う

次元数が一致しても座標系は互換ではない。全件再埋め込みが必要である。

類似度閾値を固定する

モデルが変わるとスコア分布も変わる。旧モデルで0.75を採用していたからといって、新モデルでも同じ閾値が適切とは限らない。

バッチ入力の挙動を見落とす

旧モデルで文字列リストから複数の個別埋め込みを得ていたコードは、新モデルで同じ意味にならない。個別リクエストまたはBatch APIへ設計を変更する。

評価用クエリも新モデルへ変えてしまう

評価の正解データと測定方法まで同時に変えると、比較不能になる。正解ラベルは固定し、モデル差を測定する。

編集部分析

今回の停止が示すのは、埋め込みモデルを「交換可能なAPI」として扱う設計の限界である。

生成モデルはプロンプトと出力を保存していれば、新旧モデルを同じ入力で比較しやすい。一方、埋め込みモデルは過去に作成した数百万件のベクトルが状態として残る。モデルのライフサイクルが、そのままデータ基盤の再構築周期になる。

今後のRAG設計では、ベクトルそのものを一次データと考えるべきではない。一次データは原文、チャンク境界、メタデータ、前処理バージョンであり、ベクトルは再生成可能な派生物として扱う必要がある。

原文を保持せず、ベクトルしか残していないシステムは、モデル終了時に移行できない。保存費用を削減するため原文を破棄する設計は、モデル依存リスクを過小評価している。

また、今回の移行先は多モーダル埋め込みに対応する。これは単なる性能向上ではなく、検索対象を画像、動画、音声、PDFまで広げられる変化である。ただし、期限対応と機能拡張を同時に進めると検証範囲が急増する。まずテキスト検索の互換移行を完了し、その後に多モーダル化を別プロジェクトとして評価する方が安全である。

実務チェックリスト

  • [ ] gemini-embedding-001の利用箇所を全環境で確認した
  • [ ] 原文とチャンク情報が再生成可能な形で残っている
  • [ ] 新旧モデルのベクトルを同じインデックスへ混在させていない
  • [ ] task_typeからプロンプト内タスク指示へ移行した
  • [ ] 複数入力の挙動差を確認した
  • [ ] 次元数と距離関数を固定した
  • [ ] 新しいベクトルインデックスを別名で作成した
  • [ ] 全件再埋め込みの進捗と失敗を追跡できる
  • [ ] Recall@k、MRR、nDCGを新旧で比較した
  • [ ] 類似度閾値を再調整した
  • [ ] 本番クエリでシャドー評価した
  • [ ] 検索先を即時切り替えられる
  • [ ] 2026年7月14日より前に新モデル側を本番化した

一次情報