先に結論
埋め込みモデルは、ベンチマークの勝ち負けだけで選ぶと失敗します。
RAG や社内検索では、実際には次の4点が効きます。
- テキスト検索の精度
- PDF / 画像 / 音声まで一緒に検索したいか
- ベクトル DB のコストをどこまで削りたいか
- 既存スタックにどれだけ自然に載るか
ざっくり結論を先に言うとこうです。
- Voyage 4: テキスト中心の retrieval 品質と価格最適化を両立したい人向け
- Gemini Embedding 2: 画像・動画・音声・PDF まで含むマルチモーダル検索を作りたい人向け
- Cohere Embed v4: 長い文書と mixed-modality 入力を企業検索に載せたい人向け
- OpenAI text-embedding-3-large: 既存 OpenAI ワークフローに素直に組み込みたい人向け
つまり、RAG の母艦を text-first で作るか、multimodal-first で作るか が最初の分かれ目です。
なぜ今この比較が重要か
2026年は、RAG の論点が「LLM を何にするか」から retrieval をどう作るか へかなり移っています。
理由は単純で、回答品質の多くは生成モデルより前段で決まるからです。
- 欲しい文書を拾えない
- PDF や画像が検索に乗らない
- 長文を truncate して重要情報を落とす
- ベクトル次元が重くてストレージ費が膨らむ
- query と document で最適なモデルを分けにくい
このへんが詰まると、上にどんな LLM を載せても伸びません。
しかも 2025〜2026 で各社の方向性がかなり分かれてきました。
- Google は ネイティブなマルチモーダル埋め込み を前面に出した
- Voyage は shared embedding space とコスト最適化 を前面に出した
- Cohere は 企業検索向けの長文・PDF・画像対応 を強化した
- OpenAI は テキスト埋め込みの扱いやすさと既存採用のしやすさ を維持した
同じ「embedding model」でも、実際には強い設計思想が違います。
比較表
| サービス | 強い用途 | 向いているチーム | 弱くなりやすい点 | 評価 |
|---|---|---|---|---|
| Gemini Embedding 2 | マルチモーダル検索、PDF/画像/音声/動画をまたぐ retrieval | Google / Vertex AI 文脈で multimodal RAG を作りたいチーム | preview 段階で、text-only の実運用実績や周辺エコシステムはこれから | 4.7 |
| Voyage 4 | テキスト中心の高精度 retrieval、query/document のコスト最適化 | retrieval 品質と vector DB コストのバランスを重視するチーム | ネイティブ multimodal は主役ではない | 4.8 |
| Cohere Embed v4 | 企業検索、長文 PDF 検索、mixed-modality 入力 | 長い文書や semi-structured data を企業検索に載せたい組織 | OpenAI / Google 比で開発者の既存採用はやや限定的 | 4.6 |
| text-embedding-3-large | OpenAI ベースの RAG、標準的な多言語テキスト検索 | まず OpenAI で堅く始めたいチーム | text-only なので multimodal retrieval では不利 | 4.5 |
4モデルの違いをひとことで言うと
Gemini Embedding 2
Gemini Embedding 2 の本質は、マルチモーダルを最初から単一ベクトル空間で扱えること です。
Google は 2026年3月に Gemini Embedding 2 を public preview として出し、テキスト・画像・動画・音声・PDF を統一的に埋め込めるようにしました。8,192 トークンの入力、3072/1536/768 などの柔軟な次元設定、100以上の言語対応が大きな特徴です。
つまり、
- PDF の中身を検索したい
- 画像付きマニュアルを引きたい
- 音声や動画断片まで検索対象にしたい
- text-to-image / text-to-document を同じ基盤で寄せたい
という要件ではかなり魅力があります。
一方で、現時点では preview なので、まずは text RAG を安定運用したい ケースでは慎重に見るべきです。
Voyage 4
Voyage 4 の強みは、retrieval 品質の高さと運用コストを両立しやすいこと です。
Voyage 4 系は shared embedding space を打ち出していて、同じ 4 シリーズの中で生成したベクトルを互換的に扱えます。これにより、たとえば document 側は高精度なモデルで埋め込み、query 側は軽量モデルで回すといった非対称な設計がしやすいです。
さらに 2048 / 1024 / 512 / 256 の次元、量子化、32k 文脈に対応していて、検索品質を落としすぎずに vector DB コストを削る設計 がしやすいです。
RAG を実務で回すと、モデル単価よりも index サイズや query 数のほうがじわじわ効きます。Voyage 4 はそこにかなり強いです。
Cohere Embed v4
Cohere Embed v4 は、企業検索を強く意識したマルチモーダル埋め込み です。
Cohere は Embed v4 で 128k 文脈、画像とテキストの mixed input、PDF を含む text-to-mixed-modality retrieval を前面に出しています。Matryoshka embeddings にも対応していて、256 / 512 / 1024 / 1536 の次元を選べます。
そのため、
- 長い PDF や報告書を切らずに扱いたい
- 画像を含む社内資料を検索したい
- 企業向け検索基盤として Azure / SageMaker などにも載せたい
という文脈では有力です。
Google ほど広いプロダクト面の勢いはなくても、検索ユースケースに対する製品設計はかなり明快 です。
OpenAI text-embedding-3-large
text-embedding-3-large は、一番わかりやすい高性能テキスト埋め込みの標準候補 です。
OpenAI は MIRACL と MTEB の改善を打ち出し、3072 次元を基本にしつつ、dimensions パラメータで短くしても精度を保ちやすい点を強みとしてきました。
要するに、
- OpenAI API をすでに使っている
- text-only の RAG をまず早く立ち上げたい
- 新しいベンダーを増やしたくない
- 多言語テキスト検索を無難に強化したい
というケースでは非常に使いやすいです。
ただし、画像・音声・PDF をまたいだ retrieval を主目的にすると、text-only であることが制約になります。
実務観点で比較すると何が違うか
1. 純テキストの retrieval 品質
この軸では Voyage 4 がかなり強い です。
Voyage は Retrieval Embedding Benchmark 系の評価と shared embedding space の設計を武器にしていて、query と document の役割を分けた最適化がしやすいです。テキスト中心の RAG で、検索品質・速度・コストを全部見るならまず候補に入ります。
OpenAI text-embedding-3-large も十分強いですが、今の比較軸では “堅い標準” の位置づけです。明確な multimodal 要件がないなら依然有力ですが、retrieval 専業ベンダーの細かい最適化では Voyage が一歩前に見えます。
2. マルチモーダル検索
ここは Gemini Embedding 2 と Cohere Embed v4 が主役です。
Gemini Embedding 2 は動画・音声・PDF まで含むのが広いです。Cohere Embed v4 は画像 + テキスト + PDF を企業検索で扱う文脈に強く、128k 文脈も効きます。
もし要件が「画像も検索したい」程度ならどちらも候補ですが、動画や音声まで射程に入れるなら Gemini、長い文書や業務 PDF を企業検索に載せるなら Cohere のほうが素直です。
3. vector DB コスト最適化
ここは Voyage 4 と OpenAI が扱いやすいです。
- Voyage 4: shared space + 256/512/1024/2048 次元 + 量子化
- OpenAI:
dimensionsで 3072 から短縮可能 - Cohere: Matryoshka 対応で 256〜1536
- Gemini: 768 / 1536 / 3072 推奨で柔軟性あり
ただし実務では、単に短くできるだけでなく 短くしても retrieval が崩れにくいか が大事です。この観点では、コスト最適化を前提に設計思想が見えやすい Voyage 4 が強いです。
4. 導入のしやすさ
ここは既存スタックで答えが変わります。
- Google / Vertex AI を既に使っている → Gemini Embedding 2
- OpenAI API が既に標準 → text-embedding-3-large
- 検索専業ベンダーを入れてもよい → Voyage 4 / Cohere Embed v4
特に OpenAI は、最初の一歩の導入ハードルが低い のが強みです。
逆に Google / Cohere / Voyage は、retrieval の要件がはっきりしているほど旨味が出ます。
5. 将来の伸びしろ
- Gemini Embedding 2: multimodal retrieval の本命候補。今後 preview を抜けて安定するとかなり強い
- Voyage 4: retrieval 最適化の完成度が高く、RAG の母艦として使いやすい
- Cohere Embed v4: 企業検索向けにはかなり実務的。長文・PDF の扱いが強い
- OpenAI text-embedding-3-large: 標準選択肢として依然強いが、multimodal 面では守勢
どの人にどれがおすすめか
Gemini Embedding 2 がおすすめの人
- 画像・PDF・音声・動画まで検索対象にしたい人
- Google AI Studio / Vertex AI を使っている人
- 将来的に cross-modal retrieval を本格化したい人
Voyage 4 がおすすめの人
- テキスト中心の RAG を本気で改善したい人
- query 数が多く、ベクトルコストも気になる人
- query/document でモデルを分ける非対称設計をしたい人
Cohere Embed v4 がおすすめの人
- 長い PDF をそのまま検索したい人
- 企業資料や mixed-format ドキュメントを扱う人
- 検索専用スタックとして Cohere を評価したい組織
OpenAI text-embedding-3-large がおすすめの人
- まず OpenAI で無難に始めたい人
- text-only の検索基盤が主目的の人
- 既存の OpenAI アプリに埋め込みを足したい人
迷ったときの選び方
まず text RAG を強くしたいなら
Voyage 4 を第一候補にしてください。
retrieval 品質とコスト最適化の両方に効きやすく、設計意図がかなり明快です。
既存 OpenAI スタックで最短導入したいなら
text-embedding-3-large が堅いです。
ベンダーを増やさずに、一定以上の多言語検索品質を確保しやすいです。
PDF・画像・音声をまとめて検索したいなら
Gemini Embedding 2 が有力です。
とくに動画・音声まで視野にあるなら、候補の中でも一番方向性がはっきりしています。
長文 PDF と企業検索を優先するなら
Cohere Embed v4 がかなり噛み合います。
128k 文脈と mixed-modality input は、業務文書の検索基盤で効きやすいです。
まとめ
埋め込みモデル選びは、単なる API 比較ではありません。どんな検索体験を作りたいかの設計選択 です。
- Voyage 4: text-first の retrieval を最も実務的に強くしやすい
- Gemini Embedding 2: multimodal retrieval の伸びしろが大きい
- Cohere Embed v4: 長文 PDF を含む企業検索に強い
- text-embedding-3-large: OpenAI 標準で始めるなら今も有力
ベクトル検索を本番で回すと、生成モデルより先に retrieval の粗が収益や利用継続率に響きます。だからこそ、埋め込みモデルは「なんとなく有名」ではなく、検索体験の主語で選ぶべき です。
参考情報
- Google: Gemini Embedding 2 は 2026-03-10 時点で public preview。text / image / video / audio / PDF を単一空間で扱い、出力次元は 128〜3072、推奨は 768 / 1536 / 3072。
- Voyage AI: Voyage 4 系は 2026-01 発表。shared embedding space、32k 文脈、2048 / 1024 / 512 / 256 次元、量子化に対応。
- Cohere: Embed v4 は 128k 文脈、mixed text/image input、Matryoshka embeddings、PDF を含む multimodal retrieval を訴求。
- OpenAI: text-embedding-3-large は 3072 次元を基本に、
dimensionsで短縮可能。MIRACL / MTEB 改善を打ち出している。