ベクトル検索の埋め込みモデル比較【2026年版】：OpenAI・Voyage・Gemini・Cohere・Qwen・BGE

ベクトル検索に最適な埋め込みモデルは、必要な答えを安定して見つけられるモデルです。まずは低コストのテキスト検索の基準として OpenAI text-embedding-3-small を試し、検索性能を重視するなら Voyage 4 と比較します。音声や動画も検索対象に含むなら、Google Gemini Embedding 2 が候補です。OpenAI の small は入力100万トークン当たり $0.02 から利用できます。ただし、より大きな負担になるのは、互換性のないモデルへ切り替える際にベクトルインデックスを再構築する作業です。

埋め込みモデルは、コンテンツをベクトルと呼ばれる数値の並びに変換します。これにより、使われている言葉が違っても、意味の近い情報を検索できます。サポートボットなら、「アカウントに入れない」という問い合わせを、適切なログインのトラブルシューティング記事に結び付ける仕組みです。検索拡張生成（RAG）は、こうして取得した資料を、回答を生成するモデルに渡します。

仕様、料金、ライセンスは、2026年10月15日に各提供元の公開ページで確認しています。 本記事は公式ドキュメントに基づく比較であり、実機で精度やレイテンシを測定したベンチマークではありません。以下の推奨は、自分の環境で評価を始めるための候補です。冒頭の料金は OpenAI の料金表に基づきます。

ベクトル検索に使う埋め込みモデルの比較一覧

検索要件を満たすモデルのうち、最も安いものから検討します。そのうえで、対応言語、入力形式、デプロイの制約に応じて候補を入れ替えます。以下の7つのモデルファミリーで、マネージドAPI、プライベート環境への導入、ダウンロード可能な重みをカバーしています。

料金は、セルフホストと記載した行を除き、テキスト入力100万トークン当たりの通常の有料料金です。通貨は米ドルです。ベクトルデータベース、回答生成、リランキングの費用は含みません。リランキングとは、検索で得た候補を別のモデルで採点し直す処理です。トークンへの分割方法は提供元によって異なるため、同じ文書でも課金対象のトークン数は変わります。

「オープンウェイト」は、モデルのファイルを入手して自分で実行できるという意味です。計算資源、導入、保守まで無料になるわけではありません。また、「多言語対応」も、すべての言語で同じ精度が出ることを意味しません。顧客が実際に使う、質問側と文書側の言語の組み合わせで検証してください。

比較候補に入れたい埋め込みモデル

1. OpenAI text-embedding-3：テキスト検索の実用的な出発点

OpenAI text-embedding-3-small と text-embedding-3-large は、ホスト型のテキスト埋め込みモデルです。一般的なヘルプセンター検索やサポートボットを立ち上げる創業者には、まず small を勧めます。モデル用サーバーを運用せずに、低コストで比較の基準を作れるためです。small が適切な文章を繰り返し取り逃すようなら、large を比較候補に加えます。そうした具体例がないまま large に費用をかけると、判断に最も役立つ検証を飛ばしてしまいます。

次元数： 既定値は small が1,536、large が3,072です。どちらも dimensions パラメーターで短いベクトルを出力できます。
最大入力： どちらも1入力当たり8,192トークンです。
対応言語・モダリティ： 多言語のテキストに対応します。画像、音声、動画は受け付けません。参照したドキュメントに対応言語の総数は記載されていません。
実行環境： OpenAI のホスト型埋め込みAPI。仕様、モダリティ。
向いている用途： テキスト中心のアプリで、測定可能な比較基準をすばやく作りたい場合。
特徴： 同じAPIで small と large を比較でき、出力サイズも調整できます。
料金： 入力100万トークン当たり small は $0.02、large は $0.13。通常料金を2026年10月15日に確認しています。料金表。
無料トライアル： 初回APIクレジットは前提にせず、有料利用として予算を組みます。

制約になるのは入力形式です。トラブルシューティングのPDFからテキストだけを抽出すると、押すべきボタンを示したスクリーンショットが失われることがあります。OpenAI のどちらの埋め込みモデルも、その視覚情報を復元することはできません。抽出後も答えが残るならテキスト埋め込みを使い、ページの見た目が答えを伝えているならマルチモーダルモデルと比較します。

モデルの大きさとベクトルの大きさも分けて考えてください。large の出力次元数を減らせば既存のストレージ制約に収まるかもしれませんが、それで small と互換になるわけではありません。ベクトルの長さが同じでも、スキーマが一致するだけです。意味を同じように配置するモデルだとは判断できません。

検索の失敗が見える状態で基準を作る

最初の構成は、なぜその検索結果が出たのかを説明できる程度にシンプルにします。

1. 1

   答えを含む単位で資料を分割する

   ヘルプセンターの記事をトピックやセクションごとに分割します。各文章に、文書タイトル、出典URL、顧客のアクセス権限、固定のチャンクIDを持たせます。モデルのコンテキストウィンドウを埋めるためだけに、無関係な手順をまとめないでください。

2. 2

   埋め込みの設定を固定する

   text-embedding-3-small を選び、出力次元数を記録します。保存するすべての文章をその設定で埋め込み、同じ次元数のベクトルインデックスを作成します。元のテキストは別途保存します。

3. 3

   回答生成を加える前に検索を確認する

   テスト用の質問を同じ設定で埋め込み、近い文章を取得して内容を確認します。もっともらしい生成回答が出ると、検索段階で誤った資料を選んでいた事実が見えなくなることがあります。

4. 4

   同じ質問で別のモデルを比較する

   large または Voyage 用に、比較専用のインデックスを作ります。資料のチャンクと関連性ラベルは固定します。アプリにとって意味のある改善が得られた場合にだけ、比較したモデルを採用します。

2. Voyage AI 4：検索性能を重視する場合のAPI比較候補

Voyage AI の Voyage 4 ファミリーは、検索品質が製品の中核になる場合に、基準モデルと並べて検討したいホスト型のテキスト埋め込みモデルです。まず voyage-4 で比較を始め、レイテンシやコストを重視するなら lite、提供元が汎用モデルの最上位品質と位置付ける選択肢を試すなら large を評価します。顧客が同じ不具合を違う言葉で説明する技術文書検索のほうが、簡単なキーワード一致ばかりを集めるより、有用なテストになります。

次元数： 既定値は1,024です。voyage-4-lite、voyage-4、voyage-4-large はいずれも256、512、2,048にも対応します。
最大入力： いずれも32,000トークンです。
対応言語・モダリティ： 多言語のテキストに対応します。モデル一覧に対応言語の総数は記載されていません。Voyage のマルチモーダルモデルとは別のモデルです。
実行環境： Voyage AI のホスト型埋め込みAPI。モデル仕様。
向いている用途： APIを選ぶ前に検索性能を比較検証できる開発者。
特徴： 汎用の Voyage 4 ファミリー内で埋め込みに互換性があります。
料金： 入力100万トークン当たり、4-lite は $0.02、4 は $0.06、4-large は $0.12。2026年10月15日に確認しています。料金表。
無料トライアル： 料金ページには、現行の汎用モデルに対して初回2億トークンの無料枠が記載されています。利用するモデルの割り当てを確認してください。

この互換性は運用面で役立ちます。Voyage はファミリー内で埋め込み空間を共有すると説明しているため、質問側のモデルを変える評価で、必ずしもすべての文書ベクトルを作り直す必要はありません。出力次元数をそろえ、実際に使う文書側と質問側の組み合わせで測定してください。Voyage の名前が付くすべてのモデルに、この互換性があると考えてはいけません。

注意すべきなのは、入力が通知なく切り詰められることです。APIの truncation 設定は既定で true です。長い文書の末尾が破棄されていても、有効なベクトルは生成されます。取り込み処理の開発中は truncation=false にして、上限を超えた入力が明確に失敗するようにし、チャンクの切り方を修正してください。大きなコンテキスト上限は、意味のまとまりを保った文章を扱う余裕です。マニュアル全体を1件の検索結果にする理由にはなりません。APIの動作。

コードだけの資料群には、提供元の voyage-code-4 もあります。リポジトリに関する質問で、特化モデルと汎用モデルを比較してください。一部のサポート記事にコード片があるという理由だけで、特化モデルを追加する必要はありません。

3. Google Gemini Embedding 2：幅広い入力に対応するマルチモーダル候補

Google Gemini Embedding 2 は、テキストと画像、音声、動画、PDFページを結び付けて検索したい場合に検討するマネージドモデルです。文章のガイドと製品デモの録画を扱うサポートシステムなら、それらを同じ埋め込み空間に置けます。こうした入力に有用な根拠が含まれるからこそ候補に入れ、自分の資料で検索性能を比較してください。テキストだけのヘルプセンターでは、入力形式の多さがそのまま利点になるとは限りません。

次元数： 128〜3,072。Google の推奨は768、1,536、3,072です。
最大入力： 8,192トークンです。
対応言語・モダリティ： 100言語超。テキスト、画像、音声、動画、PDFに対応します。
実行環境： Gemini API。安定版のモデルIDは gemini-embedding-2 です。モデルカード、対応機能。
向いている用途： テキスト抽出だけでは十分に表現できない資料を、マネージド環境で検索する場合。
特徴： テキストと画像に加えて、音声と動画も同じベクトル空間に配置できます。
料金： 通常料金は入力100万トークン当たり、テキスト $0.20、画像 $0.45、音声 $6.50、動画 $12.00。2026年10月15日に確認しています。料金表。
無料トライアル： APIの無料枠があります。所定の利用上限が適用されます。

制約になるのは、入力形式ごとに異なる取り込み条件です。全体の入力制限の範囲内で、1リクエストにつき画像は最大6枚、音声は180秒、動画は120秒、PDFは最大6ページのファイル1つまでです。動画処理で使われるのは最大32フレームで、動画の音声トラックは処理されません。ナレーション付きのデモでは、映像だけでなく、話されている説明をどう扱うかも明確に設計する必要があります。入力制限。

埋め込む各項目とともに、タイムスタンプやページ参照を保存してください。正しい動画が見つかるだけよりも、必要な場面を開けるほうが便利です。PDFも、ファイルが見つかるだけでなく、答えのあるページまで分かることが重要です。この移動のしやすさは、チャンク分割とメタデータで決まります。

既存の Google 利用者は移行時にも注意が必要です。gemini-embedding-001 と gemini-embedding-2 の埋め込み空間には互換性がありません。次元数を同じにしても互換性は保てません。Google は、両モデル間を移行する際に既存の資料を再埋め込みする必要があると明記しています。移行ガイド。

4. Cohere Embed 5：企業文書の検索と柔軟なデプロイ

Cohere Embed 5 は、長い文書、表、グラフ、テキストと画像が混在するページの検索に取り組むチームの候補です。現行ファミリーは embed-v5.0-pro と embed-v5.0-fast です。図表やレイアウトを含むマニュアルを社内サポートアシスタントで検索するなら、ページの視覚情報を踏まえた検索を、既存のテキスト抽出と比較してください。確認すべきなのは、取り込み処理を経ても正しい手順が失われないかです。

次元数： 既定値は2,048。256、512、768、1,024、1,536にも対応します。
最大入力： Pro、Fast ともに128Kトークンです。
対応言語・モダリティ： 100言語超。テキスト、画像、テキストと画像の混在入力に対応し、文書ページを表した入力も扱えます。
実行環境： Cohere API、Model Vault、Microsoft Foundry、Amazon SageMaker。VPC内やオンプレミスへの商用プライベートデプロイにも対応します。仕様、デプロイと対応言語。
向いている用途： 共有の公開API以外へのデプロイ要件がある、企業向け文書検索。
特徴： Pro と Fast は埋め込み空間を共有するため、Pro でインデックス化した資料を Fast で検索できます。
料金： テキスト100万トークン当たり Fast は $0.08、Pro は $0.12。画像はどちらも100万トークン当たり $0.40 と記載されています。2026年10月15日に確認しています。テキスト料金、画像料金。
無料トライアル： レート制限付きの試用APIキーは無料ですが、本番環境や商用目的では利用できません。

長いコンテキストウィンドウは、文章を理解するために前後の文脈が必要な場合に役立ちます。ただし、検索設計の問題がなくなるわけではありません。返されたチャンクがハンドブック全体を含むなら、回答モデルはその中から必要な文章を探さなければなりません。入力に収まるという理由だけで長い単位を選ばず、長い文脈をまとめて表現した場合と、セクション単位で分割した場合を比較してください。

Cohere は float、int8、バイナリの出力表現にも対応します。これらはベクトル内の数値を保存する形式であり、小さい表現にするとメモリ使用量や検索の挙動が変わる場合があります。選んだデータベースと検索実装で扱える形式を確認し、圧縮した構成そのものを測定してください。フルサイズの float ベクトルで得た結果だけでは、小さいバイナリインデックスの品質を確認したことにはなりません。

提供元は引き続き embed-v4.0 のドキュメントも公開しています。コンテキストは128K、既定の次元数は1,536です。これは独立した条件で評価すべき既存モデルであり、現行ファミリーの仕様ではありません。また、プライベートデプロイが可能でも、Embed 5 が Apache ライセンスでダウンロードできるわけではありません。導入には商用のデプロイ条件が関わります。

5. Qwen3-Embedding：構成を選べるオープンなテキストモデル

Qwen3-Embedding は、サイズの異なるテキスト埋め込みモデルをダウンロードして利用できます。データの保管場所や実行環境の管理がアーキテクチャを左右する場合に、有力なセルフホスト候補です。社内限定の技術文書を検索する企業なら、関連性の目標を満たす最小のモデルから始めます。最初から最大のチェックポイントを選ぶと、回答が改善するか分からないうちに、モデル選びがインフラ構築プロジェクトになってしまいます。

次元数： 最大出力次元数は0.6Bで1,024、4Bで2,560、8Bで4,096です。ファミリー全体で次元数の調整に対応します。
最大入力： これらのモデルはいずれも32Kトークンです。
対応言語・モダリティ： 100言語超に対応し、コード検索も可能です。入力はテキストです。ここで扱うのは Qwen3-Embedding であり、別ファミリーの Qwen3-VL ではありません。
実行環境： 自前のインフラ。提供元の Sentence Transformers、Transformers、vLLM、Text Embeddings Inference の実装例を利用できます。モデルカード。
ライセンス： Apache 2.0。ライセンスファイル。
向いている用途： モデルと出力のサイズを管理できる、セルフホストの多言語テキスト検索。
特徴： タスク指示で検索の目的を指定できます。
料金： オープンウェイト、セルフホスト。インフラ費用に一律の100万トークン単価はありません。
無料トライアル： 重みをダウンロードできます。実行環境と計算資源は自分で用意します。

課題になるのは、推論サービスの運用費用と負荷がかかったときの挙動です。インデックス作成のスループットと、対話的な質問のレイテンシは別々に測定してください。資料の一括取り込みはキューで待たせられますが、サポートの回答を待つ顧客には、推論の遅れがそのまま伝わります。大きいモデルが製品に適するかは、バッチサイズ、入力長、ハードウェア、同時実行数で決まります。

検索時の指示はモデルカードに従ってください。質問のフォーマットも評価対象の設定の一部なので、チェックポイントや出力次元数とともに記録します。ある指示形式のベンチマーク結果で、本番の別のプロンプトまで検証できたことにはなりません。候補の比較中は、文書側と質問側の入力ルールを固定してください。

セルフホストが特に有効なのは、自分で管理できること自体に価値がある場合や、実測した処理量から運用負担に見合うと判断できる場合です。小さなヘルプセンターの埋め込みが、自動的に安くなるわけではありません。ハードウェア費を数える前でも、ホスト型APIのわずかなトークン料金のほうが、モデルサービスを保守する手間より安く済む場合があります。

6. BAAI BGE-M3：密ベクトルだけにとどまらないオープンな検索モデル

BAAI BGE-M3 は、同じモデルで密ベクトル、疎ベクトル、マルチベクトルの検索を試したい場合に候補となるオープンモデルです。密ベクトルは意味の近さを捉え、疎な表現は語彙の特徴に重みを付けます。マルチベクトル検索は複数のベクトルを保持し、より豊かな照合を行います。製品の識別子やエラーコードを含むサポート資料は、これらの方式を比較するのに適しています。意味が近いというだけでは、別の識別子を誤って返す場合があるためです。

次元数： 密ベクトルの埋め込みは1,024次元です。疎ベクトルとマルチベクトルの出力は、それぞれ異なる構造を持ちます。
最大入力： 8,192トークンです。
対応言語・モダリティ： 100言語超のテキストに対応します。
実行環境： 提供元の FlagEmbedding 実装を使ったセルフホスト。モデルカード。
ライセンス： MIT。提供元のモデルカードのメタデータに記載されています。
向いている用途： 語彙と意味のシグナルを組み合わせるハイブリッド検索を評価できる開発者。
特徴： 同じモデルファミリーから、複数の検索用表現を得られます。
料金： オープンウェイト、セルフホスト。計算資源とストレージの費用は利用者が負担します。
無料トライアル： 重みをダウンロードできます。ホスト型サービスの無料利用枠が含まれるわけではありません。

注意点は、複数の表現を生成できても、データベースが自動でそれらを利用するわけではないことです。密ベクトルだけを保存して密ベクトル検索を実行するなら、構築したのは密ベクトル検索のシステムです。疎ベクトルやマルチベクトルの出力を使うには、それらに対応したインデックス作成とスコアリングが必要で、結果の組み合わせ方も決める必要があります。

まず密ベクトル検索から始め、部品名、エラー文字列、識別子の厳密な一致など、語彙のシグナルが役立つ質問でその要素を追加します。その改善によって、幅広い言い換えへの対応が悪化しないかも確認してください。リランカーは、補正の対象となる検索候補を確認できるようになってから追加します。

BGE-M3 を候補に入れる理由は、この柔軟性です。過去の公開時のベンチマークが、現在のすべてのAPIに勝ると証明しているからではありません。単純な密ベクトルの埋め込みだけでよければ、検索を複雑にする前に、Qwen やホスト型の基準モデルと比較してください。

7. Google EmbeddingGemma：ローカル検索で使い分ける2つの世代

Google EmbeddingGemma 2 は、ユーザーの端末内でテキストやメディアを検索するアプリの候補です。デスクトップのナレッジツールなら、すべての項目をホスト型埋め込みAPIに送らずに、メモとスクリーンショットや録音をまとめてインデックス化できます。現行モデルと初代の embeddinggemma-300m は、対応入力、コンテキスト長、ライセンスが異なります。ビルドで使うリポジトリを正確に固定してください。

次元数： EmbeddingGemma 2 は768次元を出力し、512、256、128も選べます。
最大入力： 8,192トークンです。
対応言語・モダリティ： 100言語超。コードを含むテキスト、画像、動画、音声に対応します。
実行環境： ローカルまたは自前のインフラ。提供元は Sentence Transformers の実装例を公開しています。総パラメーター数740Mには、必要に応じて読み込める画像・音声エンコーダーが含まれます。モデルカード。
ライセンス： EmbeddingGemma 2 は Apache 2.0。モデルカードに記載されています。
向いている用途： マルチモーダル埋め込みが必要な、ローカルまたはオフラインのアプリ。
特徴： アプリで必要なモダリティのエンコーダーを選んで読み込めます。
料金： オープンウェイト、セルフホスト。端末のリソースや、利用するホスト型インフラの費用は利用者が負担します。
無料トライアル： 重みをダウンロードできます。

初代の EmbeddingGemma-300m は、別のテキスト専用モデルとして引き続き利用できます。パラメーター数は300M、入力上限は2,048トークン、次元数は768で、512/256/128にも対応します。学習対象には100を超える自然言語が含まれます。Sentence Transformers で実行できますが、リポジトリの利用には Google の Gemma Terms of Use への同意が必要です。この旧チェックポイントに、EmbeddingGemma 2 の Apache ライセンスを当てはめないでください。初代モデルと利用条件。

制約になるのは、端末で使えるリソースです。モデルのファイルを読み込めるかどうかより、利用可能なメモリ、発熱時の挙動、ほかのアプリ処理との同時実行が重要です。ユーザーが通常の操作をしている間に、バックグラウンドでインデックス作成を走らせて検証してください。小型モデルでも、取り込み処理が端末を占有すれば使い心地は悪くなります。

ベクトルを短縮する場合は Google の正規化手順に従い、質問側と文書側の次元数をそろえてください。タスクのプレフィックスも保持します。これらの設定もモデルのデプロイの一部です。検索品質が変わってから調べ直せばよい、という扱いにはできません。

検索システムやサポートボットに合うモデルの選び方

品質を比べる前に、具体的な要件で候補を絞ります。決め手は、どの失敗がアプリを使いものにならなくするかです。答えを取り逃すことなのか、視覚的な根拠が失われることなのか、許容できない場所にデータを送ることなのか、それとも応答が遅すぎることなのかを明確にします。

テキスト用の埋め込みモデルはどう選ぶ？

ホスト型のテキストアプリなら、OpenAI small と Voyage 4 から始めます。既存のAPI内で比較したい場合は OpenAI large を、文書の構造とプライベートデプロイが重要な場合は Cohere を加えます。ユーザーが実際に困っている失敗を改善でき、レイテンシと総費用が許容範囲に収まる場合にだけ、別のモデルを採用します。

多言語サポートでは言語をまたぐ例も評価してください。スペイン語の質問に英語の記事で答えるケース、現地の製品名、複数言語が混ざったメッセージ、別の文字体系に転写された用語などです。「100言語超に対応」しているだけでは、最も重要な言語の組み合わせでうまく検索できるとは判断できません。

オープンソースの埋め込みモデルはどう選ぶ？

構成を調整できるテキスト検索には Qwen3-Embedding、語彙と意味の両方が重要な検索には BGE-M3、ローカルのマルチモーダル入力には EmbeddingGemma 2 を比較します。ライセンスは、実際に使うチェックポイントに適用されるものを確認してください。セルフホストは、測定可能な運用コストを伴うデプロイの選択です。APIを無料で使うことと同義には扱わないでください。

資料に撮影した手順書、図、録画されたデモが含まれるなら、テキストを抽出するか、元のモダリティを残すかを意識して選びます。テキスト抽出だけで十分な場合もあり、そのほうがデバッグしやすいこともあります。失われる画像や音声の情報によって答えが変わる場合に、マルチモーダル検索を使います。

ローカルで動かす埋め込みモデルはどう選ぶ？

本記事でローカルのマルチモーダル用途を検討するなら、最初の候補は EmbeddingGemma 2 です。テキスト専用の比較には、Qwen の小さいモデルと BGE-M3 が入ります。ユーザーに提供する実際のハードウェアで測定してください。開発用ワークステーションの結果だけでは、インデックス作成と質問処理を同時に行うノートPCや小型サーバーでの性能はほとんど分かりません。

判断の基準： 関連性、レイテンシ、デプロイ、言語の要件を満たす、最もシンプルな候補を維持します。評価済みの別モデルが重要な失敗を解消し、移行に見合う効果があるときに切り替えます。

MTEBを参考にし、自分のデータで検証する

MTEB リーダーボードは、候補を見つけるために使います。あらゆる用途に共通する勝者を決めるものではありません。MTEB（Massive Text Embedding Benchmark）は、検索、分類、クラスタリング、類似度などのタスクを扱います。リーダーボードでは、言語、分野、モダリティ別にも確認できます。異なるタスク群のスコアを、そのまま比較できるとは限りません。

RAGの埋め込みモデルを評価するなら、対象の言語と分野に関係する検索結果を確認します。視覚資料を扱うなら、適切なマルチモーダルまたは文書検索のベンチマークを確認してください。結果を判断の根拠にする前に、ベンチマークのバージョンと設定を記録します。本記事では、リーダーボードの数値スコアは引用していません。

最初の評価には、実際の質問100件と、それぞれの答えを含む資料の文章にラベルを付けたデータセットが役立ちます。これは評価を始めるためのサンプル数の提案であり、統計的な確実性を保証するものではありません。正しい答えが存在しない質問、曖昧な言い回し、厳密な識別子、提供する言語の組み合わせも含めてください。

モデルの比較中は、資料のチャンク、アクセス権限、取得件数、リランカーの有無や設定を固定します。そうしないと、改善した理由がモデルなのか、周辺の処理パイプラインなのか分かりません。上位10件を取得する場合、recall@10 は関連資料をどれだけ含められたかを測り、nDCG@10 は関連性の高い結果を上位に置くほど高く評価します。

続いて、失敗例を目視で確認します。正しい文章が欠けていたのか、順位が低すぎたのか、権限フィルターで除かれたのか、抽出時に内容が損なわれたのかを調べます。インデックスに入っていない文章は、モデルをアップグレードしても取り戻せません。質問のレイテンシと取り込みのスループットを別々に測り、次元数や圧縮方式を変えた後は、難しいケースを再検証してください。

ベクトルを保存し、検索に使う場所

Pinecone は、外部で生成したベクトルを保存できるマネージドのベクトルデータベースです。推論APIを通じて、一部の埋め込みモデルも提供しています。モデルカタログには、推論APIで使える埋め込みモデルとして llama-text-embed-v2、multilingual-e5-large、pinecone-sparse-english-v0 が掲載されています。これは、Gemini、OpenAI、Voyage を自分で呼び出し、そのベクトルをアップロードする構成とは別の選択肢です。

対応モデルが自分の評価基準を満たし、テキストからベクトルへの変換をサービス側に任せたいなら、統合された埋め込み機能を使います。モデル、メディアの前処理、セルフホストのエンコーダーを自分で管理したいなら、ベクトルを生成して持ち込みます。Pinecone のインデックス作成ドキュメントでも、この2つの方式を区別しています。

サポートボットでは、検索の仕組みと合わせて、元のテキスト、固定ID、アクセス制御のメタデータ、引用元を保持してください。埋め込みの類似度はアクセス許可ではありません。どのデータベースを選んでも、アプリ側で検索対象をユーザーが閲覧できる資料に限定する必要があります。

保存先の選び方はベクトルデータベース比較、Pinecone の別途発生する費用は Pinecone の料金解説で扱っています。アシスタントが検索のタイミングを判断したり、質問を書き換えたり、追加検索を行ったりする場合は、エージェント型RAGの解説でその流れを説明しています。埋め込みモデルは情報の表現を作り、検索システムはその使い方を決めます。

次元数によって必要な保存容量は変わる

ベクトルの次元数は、データベースを踏まえて選びます。float32 精度では、数値1つが4バイトを占めます。そのため、100万本のベクトルを保存する場合、1,536次元では生のベクトル値だけで 6.144 GB、3,072次元では 12.288 GB が必要です。いずれも10進表記のギガバイトで計算した値であり、メタデータ、インデックス構造、レプリカなど、データベースのオーバーヘッドは含みません。

埋め込みのトークン料金が安くても、出力を小さくする意味があるのはこのためです。モデルのパラメーター数とベクトル次元数を混同してはいけない理由でもあります。前者は実行するエンコーダーに影響し、後者は保存・検索するすべての表現に影響します。

次元削減は、提供元が対応を明記した方法で検証してください。対応が記載されていないモデルのベクトルを、任意に切り詰めてはいけません。正規化が必要な場合は、一貫して適用します。そのうえで、次元を減らしたベクトルそのものを評価してください。保存容量を節約できても、必要な根拠を取得できなければ意味がありません。

モデルの切り替えにはインデックスの移行が伴う

新しいモデルの埋め込み空間に互換性がなければ、資料全体の再構築を予算に含めます。古い文書ベクトルを残したまま質問側のAPIのモデル名だけを変えると、両者の次元数が同じでも、通常は照合が機能しなくなります。Google が説明する embedding-001 から embedding-2 への移行は、その明確な例です。

適用範囲が明示された例外もあります。Voyage の汎用4ファミリーと Cohere の Embed 5 Pro/Fast は、埋め込み空間の共有を明記しています。これは特定のモデル同士を組み合わせられるという意味であり、異なる提供元のモデルを自由に混ぜられるという意味ではありません。実際の組み合わせを検証し、次元数と表現形式の設定をそろえてください。

再埋め込みの費用は、実際の入力トークン数で見積もります。例として、平均500トークンのチャンクが100万個なら、合計は5億トークンです。Gemini Embedding 2 の公開されている通常のテキスト料金では、埋め込み処理の料金は $100 と計算できます。データベースへの書き込み、旧環境と新環境の並行保存、前処理、質問処理、開発作業は含まず、割引も考慮していません。料金の出典。

トークン料金は、むしろ対応しやすい部分かもしれません。移行には、元の文書、取り込み設定、そして新環境を構築する間も本番システムを稼働させられるだけの容量が必要です。インデックスの各バージョンとともに、モデルID、次元数、正規化、チャンク分割のバージョン、質問用・文書用の指示を保存してください。

1. 1

   比較用のインデックスを別に作る

   保存してある元のチャンクを、新しい設定で再埋め込みします。既存のインデックスはリクエストへの応答を続けます。対応するレコードを比較できるように、固定の文書IDを使います。

2. 2

   同じ評価を再実行し、悪化した箇所を調べる

   同じラベル付きの質問で新しい候補を比較します。関連性に加え、権限、引用先、欠落した文書、質問のレイテンシを確認します。一括取り込みの間に変更された文書も考慮してください。

3. 3

   モデルとインデックスを同時に切り替える

   対応する新しいエンコーダーとインデックスへ、設定変更をまとめて適用して質問を送ります。本番の挙動が評価時と異なった場合に切り戻せるよう、旧モデルと旧インデックスの組み合わせを十分な期間残します。

比較対象を選んだ基準

本記事では、検索、RAG、サポートボットの選定において、明確な役割を持つ7つのモデルファミリーを選びました。公開されている入力上限、次元数、モダリティ、対応言語、デプロイ方法、ライセンス、現行料金を考慮しています。提供元のページは記載の確認日に確認し、保存容量と費用の例は、明示した前提から計算しました。

本記事のためにモデルのベンチマークや負荷試験を実施したわけではありません。掲載順は、一般的なテキスト中心の開発者に勧める評価の順序であり、実測した精度のランキングではありません。コード特化、分野特化、その他のマルチモーダルファミリーは、独立した順位付きのカードにはしていません。その専門性がアプリを左右する場合は、自分の比較候補に加えてください。

避けたいモデルの選び方

画像や音声を直接検索するために OpenAI text-embedding-3 を選ぶことは避けてください。これはテキスト用ファミリーです。文字を抽出する構成自体は有効ですが、元の画像や音にしか存在しない情報は失われます。

新規開発で、旧世代の Voyage 3 を無条件に出発点にすることは避けてください。Voyage の現行ドキュメントは新しいファミリーを推奨しています。すでに評価済みの環境を運用しているなら、移行コストを払う理由が生まれるまでは維持します。

測定せずに Qwen3-Embedding-8B をノートPC向けの既定モデルにすることは避けてください。まず端末のレイテンシとリソースの上限を把握し、大きなチェックポイントの効果が運用コストに見合うかを評価します。

密ベクトルの出力しか保存しないのに、BGE-M3 を「ハイブリッド検索」用に選ぶことは避けてください。その機能を得るには、追加の表現を利用する検索設計が必要です。

EmbeddingGemma のすべてのチェックポイントが Apache 2.0 だと考えることは避けてください。現行の EmbeddingGemma 2 のモデルカードには Apache 2.0 と記載されていますが、初代300Mのリポジトリには Gemma の利用条件が適用されます。検索性能だけでなく、デプロイでも正確なバージョンが重要です。

よくある質問

RAGにおすすめの埋め込みモデルは？

低コストのホスト型テキストモデルとして OpenAI text-embedding-3-small を基準にし、自分の質問で Voyage 4 と比較するところから始めます。資料のモダリティによって答えが変わるなら、Gemini Embedding 2 や Cohere Embed 5 も比較に加えます。本記事のセルフホスト候補は Qwen3-Embedding、BGE-M3、EmbeddingGemma です。ラベル付けした根拠を安定して取得できるモデルが、実用上の最適解です。

無料で試せる埋め込みモデルは？

ホスト型モデルの評価では、Gemini にAPIの無料枠、Voyage に初回のトークン枠があります。Cohere はレート制限付きの試用キーを提供していますが、本番環境や商用での利用はできません。顧客向けアプリを無料枠に依存させる前に、実際に使うモデルの利用枠と本番利用の条件を確認してください。

RAG向けに無料で入手できる埋め込みモデルは？

セルフホストのテキストRAGなら Qwen3-Embedding と BGE-M3、ローカルのマルチモーダルRAGなら EmbeddingGemma 2 も比較してください。重みをダウンロードしてエンコーダーを自分で運用できますが、推論、保存、保守には引き続きリソースを使います。ライセンスは正確なチェックポイントと対応付け、ホスト型APIとの比較には、そうした運用費用も含めてください。

次に取り組むのは、現在の検索が答えを見つけられないサポートの質問を集め、それぞれの答えを含む文章にラベルを付けることです。資料全体を投入する前に、AI業務ワークフローの監査チェックリストで、ワークフローと成功基準を明確にしてください。