RAGを組んだのに「検索が微妙に的を外す」「日本語の質問だと関連文書が出てこない」——その原因の多くは、生成側のLLMではなくEmbedding（埋め込み）モデルの選定ミスにあります。チャンクをどんなに丁寧に切っても、ベクトル化の段階で意味を取りこぼせば、リランカーやLLMがいくら頑張っても拾えません。
実際にRAGの検証を回していると、「とりあえずOpenAIのtext-embedding-3-smallで組んだまま放置」というケースが本当に多いです。それ自体は悪い選択ではありませんが、日本語中心のドキュメントを扱うなら、もっと適した選択肢が2026年時点では複数あります。逆に、コストとストレージを度外視して最高次元のモデルを選び、ベクトルDBの費用が跳ね上がって運用が回らなくなる、という反対側の失敗もよく見かけます。
この記事では、2026年6月時点で利用できる主要なEmbeddingモデル（OpenAI / Cohere / Voyage AI / Google / オープンソース）を、精度・次元数・日本語対応・コスト・API/セルフホスト・最大トークン長の6軸で整理します。さらに、モデルを呼び出してベクトル化し保存する実装コード、精度を底上げする工夫、モデル変更時の再インデックス運用まで、現場で使える形でまとめました。価格・スペックはすべて各社公式ドキュメントで確認した値を、参照日付きで掲載しています。
用途別おすすめ早見表（先に結論）
細かい比較に入る前に、典型的なユースケース別の「まず試す候補」を出しておきます。あくまで出発点であり、必ず自分のデータでオフライン評価（後述）をしてから本採用してください。
| ユースケース | まず試す候補 | 理由 |
|---|---|---|
| とにかく早く動かしたい（英語中心） | OpenAI text-embedding-3-small |
1,536次元・$0.02/100万トークンと安価。APIだけで完結 |
| 日本語の社内文書RAG（クラウドOK） | Google gemini-embedding-001 / Cohere embed-v4.0 |
多言語MTEB上位・100言語以上。次元を絞ってストレージ調整可能 |
| 検索精度を最優先（コスト許容） | Voyage AI voyage-4 系 |
retrieval特化で評価が高い。Matryoshkaと量子化でDBコストも抑制可能 |
| データを外に出せない／オフライン | OSS BGE-M3 / multilingual-e5-large / Ruri v3 |
セルフホストでAPIコストゼロ。日本語はRuri系が強い |
| コード検索・コードRAG | Voyage voyage-code-3 |
コード特化で学習。汎用モデルより検索精度が出やすい |
※スペック・価格の最終確認日: 2026-06-03（各社公式ドキュメント）。MTEB等のベンチマークはリーダーボードのバージョン更新で順位が入れ替わるため、本採用前にMTEBリーダーボードの最新版を必ず確認してください。
そもそもEmbeddingモデルとは？RAG精度への影響
Embedding（埋め込み）モデルは、テキストを「意味を表す数値ベクトル」に変換するモデルです。たとえば「契約を解約したい」という文と「サブスクをキャンセルする方法」という文は、表面的な単語は違っても意味が近いため、良いEmbeddingモデルならベクトル空間上で近い位置に配置されます。RAGはこの「ベクトルの近さ」で関連文書を引っ張ってくるので、Embeddingの質がそのまま検索ヒット率に直結します。
RAGのパイプラインは、ざっくり次の流れです。
- チャンク分割：ドキュメントを検索しやすい単位に切る
- ベクトル化（Embedding）：各チャンクをEmbeddingモデルでベクトルにする← ここがこの記事のテーマ
- 保存：ベクトルDB（Pinecone / Qdrant / pgvector等）に格納
- 検索：ユーザーの質問も同じモデルでベクトル化し、近いチャンクを取得
- 生成：取得したチャンクをコンテキストに入れてLLMが回答
ここで重要なのは、「質問のベクトル化」と「文書のベクトル化」は必ず同じモデルで行うという点です。異なるモデルで作ったベクトル同士は比較しても意味がありません。モデルを変えるなら、原則すべての文書を作り直す（再インデックス）必要があります。この前提があるからこそ、最初のモデル選定が後々の運用コストを大きく左右します。
事例区分: 自社検証
社内の問い合わせ対応RAGで、チャンク戦略やプロンプトを変えても改善しなかった検索精度が、Embeddingモデルを日本語に強い構成へ差し替えただけで体感的に大きく改善した、というのは検証でよく経験します。生成側のチューニングに行く前に、まず埋め込みを疑うのは費用対効果が高いです。
Embeddingモデル選定の6つの評価軸
「どれが一番いいか」ではなく「自分のユースケースにどれが合うか」で選ぶのが鉄則です。判断に使う軸は次の6つです。
1. 精度（MTEB / JMTEBスコア）
Embeddingモデルの精度比較で広く使われるのがMTEB（Massive Text Embedding Benchmark）です。検索・分類・クラスタリングなど多数のタスクの平均で評価します。日本語版としてはJMTEBがあります。ただし注意点として、MTEBは「SERP平均的な汎用タスク」での性能であり、あなたの実データでの検索精度を保証するものではありません。リーダーボードはあくまで一次スクリーニング、最終判断は自前データでの評価で行います。
2. 次元数とストレージコスト
出力ベクトルの次元数が大きいほど表現力は上がりますが、ベクトルDBのストレージ・メモリ・検索コストが線形に増えます。3,072次元は1,536次元の2倍、768次元の4倍のストレージを食います。100万チャンクを超えるような規模では、ここがランニングコストの主役になります。近年の主要モデルはMatryoshka表現学習を採用しており、APIで次元を短縮（256や512など）しても精度劣化を抑えられるのが大きなトレンドです。
3. 多言語・日本語対応
日本語RAGなら、英語ベンチマークの数字だけ見ても判断を誤ります。多言語モデルか、日本語特化モデルかを必ず確認してください。Google・Cohere・Voyageの最新モデルは100言語以上に対応し、日本語特化のOSS（Ruri等）はJMTEBで国産トップクラスの結果を出しています。
4. コスト（API課金 or セルフホストの計算資源）
APIモデルは100万トークンあたりの従量課金、セルフホストは課金ゼロですがGPU/CPUとMLOpsの手間がかかります。月間のベクトル化トークン量×単価で見積もり、検索クエリ側のトークンも忘れず加算します（質問も毎回ベクトル化されます）。
5. APIかセルフホストか
機密データを外部に出せない、オフライン要件がある、推論レイテンシをコントロールしたい——こうした要件があればセルフホスト（OSS）一択です。逆に、運用負荷を最小化したいならAPIが圧倒的に楽です。
6. 最大入力トークン長
1チャンクに入れられる最大トークン数です。長文をそのまま埋め込みたい場合に効いてきます。Voyageの4系は32,000トークン、Cohere embed-v4.0は128Kトークン、Googleのgemini-embedding-001は2,048トークンと、モデルによって大きく差があります。とはいえ、RAGでは「長く埋め込めるから良い」わけではなく、検索単位として適切なチャンクサイズに切る方が精度は出やすい、という点は押さえておきましょう。
主要Embeddingモデル比較（2026年6月版）
ここからは系統別に、公式ドキュメントで確認できた仕様を整理します。価格は変動が速いので、本採用前に必ず公式の最新値を確認してください。
OpenAI（text-embedding-3 系）
最も手軽に始められる定番。text-embedding-3-small（既定1,536次元）とtext-embedding-3-large（既定3,072次元）の2モデルで、いずれもdimensionsパラメータで次元を短縮できます（OpenAI公式によれば、largeを256次元に短縮しても旧ada-002の1,536次元を上回るとされています）。日本語にも一定対応しますが、日本語特化モデルほどではありません。「まず動かす」「英語中心」なら第一候補です。
- 次元: small=1,536 / large=3,072（
dimensionsで短縮可） - 価格: small=$0.02、large=$0.13（いずれも100万トークンあたり。Batch APIで半額。出典: OpenAI、参照日2026-06-03）
- 形態: APIのみ
Cohere（embed-v4.0 / Embed 4）
2025年4月リリースの第4世代。テキストと画像を同じAPIで埋め込めるマルチモーダルが特徴で、図表混在のドキュメント検索に強みがあります。出力次元は256/512/1,024/1,536（既定1,536）でMatryoshka対応、最大コンテキストは128Kトークン、100言語以上に対応します。クロスリンガル検索（日本語クエリで英語文書を引く等）を1つのインデックスで行いたい場合に有力です。
- 次元: 256/512/1,024/1,536（既定1,536）
- コンテキスト: 128Kトークン / マルチモーダル（テキスト＋画像）
- 価格: テキスト$0.12（100万トークンあたり。出典: Cohere、参照日2026-06-03）
- 形態: API（Bedrock / Azure等経由も可）
Voyage AI（voyage-4 系 / voyage-code-3）
retrieval（検索）に特化した評価で高い実績を持つシリーズ。2026年6月時点の現行はvoyage-4 系（voyage-4-large / voyage-4 / voyage-4-lite）で、いずれも既定1,024次元・256/512/2,048も選択可、最大32,000トークンです。Matryoshkaに加えてint8・バイナリ量子化に対応し、ベクトルDBのコストを大幅に下げられるのが実務上の魅力です。コードRAGにはvoyage-code-3が用意されています。
- 次元: 既定1,024 / 256・512・2,048も選択可（4系は相互互換）
- コンテキスト: 32,000トークン
- 価格: voyage-4 系などで最初の2億トークン無料枠あり（出典: Voyage AI docs、参照日2026-06-03）
- 形態: API（オープンウェイトの
voyage-4-nanoも提供）
Google（gemini-embedding-001）
Gemini APIとVertex AIで提供される多言語モデル。出力次元は128〜3,072で柔軟に指定でき（推奨は768/1,536/3,072）、Matryoshka対応です。最大入力は2,048トークン。MTEBの多言語リーダーボードで上位を維持しており、100言語以上に対応します。日本語社内RAGでクラウド前提なら、有力な候補です。
- 次元: 128〜3,072で可変（推奨768/1,536/3,072）
- 入力上限: 2,048トークン / 100言語以上
- 価格: $0.15（100万トークンあたり。Batchで半額、無料枠あり。出典: Google、参照日2026-06-03）
- 形態: API（Gemini API / Vertex AI）
オープンソース（BGE-M3 / multilingual-e5 / Ruri / Qwen3-Embedding）
セルフホスト前提なら、品質と運用性のバランスで定番なのがBGE-M3（BAAI、100言語以上・最大8Kトークン・密/疎/マルチベクトルのハイブリッド検索対応）とmultilingual-e5-large（intfloat、1,024次元の多言語モデル）です。日本語を最重要視するなら、JMTEBで国産トップクラスのRuri v3（310Mパラメータと軽量）が有力。MTEB多言語リーダーボードの上位にはQwen3-EmbeddingやNV-Embed-v2といった大型モデルも並びますが、その分GPUメモリを要します。APIコストゼロの代わりに、推論基盤の構築・運用が発生する点を見込んでおきましょう。
- BGE-M3: 1,024次元 / 8Kトークン / 100言語以上 / ハイブリッド検索対応
- multilingual-e5-large: 1,024次元 / 多言語
- Ruri v3: 日本語特化・JMTEB上位 / 310Mと軽量
- 形態: すべてセルフホスト（Hugging Face）。APIコストはゼロだが計算資源が必要
日本語RAGでのEmbeddingモデルの選び方
日本語ドキュメントを中心に扱うなら、英語MTEBの数字に引っ張られないことが何より大事です。判断の流れをシンプルにまとめます。
- データを外に出せるか？ 出せない／オフライン要件あり → OSS（Ruri v3 / BGE-M3）へ進む
- クラウドOKで運用を楽にしたい → API系（Google gemini-embedding-001 / Cohere embed-v4.0 / Voyage voyage-4）を候補に
- 日本語の検索精度を最重視 → 日本語特化のRuri系、または多言語上位のGoogle/Cohere/Voyageを自前データで比較
- コストとストレージを抑えたい → Matryoshka対応モデルで次元を512〜1,024に絞る、または量子化対応のVoyageを検討
そして最後は必ず、自分の実データ50〜100問程度で「Recall@k」を測って決める。リーダーボードの順位より、自分のドメインでの検索ヒット率のほうが100倍重要です。後述の評価コードを使えば、半日あれば比較できます。
実装：モデル呼び出し→ベクトル化→保存
ここから手を動かします。代表的なパターンを、APIモデル（OpenAI）とOSSモデル（BGE-M3）の2通りで示します。
動作環境: Python 3.11+ / openai>=1.30.0 / sentence-transformers>=3.0.0 / numpy
注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。APIキーはコードに直書きせず、環境変数または各種シークレットマネージャーで管理してください。
パターン1：OpenAI APIでベクトル化
まずはAPIで最短に動かす例です。文書チャンクをまとめて1リクエストで埋め込みます。
# 動作環境: Python 3.11+, openai>=1.30.0
# pip install openai numpy
import os
import numpy as np
from openai import OpenAI
# APIキーは環境変数から（ハードコード禁止）
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
MODEL = "text-embedding-3-small" # 既定1,536次元
DIM = 512 # dimensionsで短縮してストレージ節約（Matryoshka）
def embed(texts: list[str]) -> np.ndarray:
"""テキストのリストをベクトル化して返す。"""
resp = client.embeddings.create(
model=MODEL,
input=texts,
dimensions=DIM, # 省略すると既定次元（1,536）
)
# 入力順とレスポンス順を index で必ず突き合わせる
vecs = [d.embedding for d in sorted(resp.data, key=lambda x: x.index)]
return np.array(vecs, dtype=np.float32)
chunks = [
"契約の解約はマイページから手続きできます。",
"サブスクリプションのキャンセル方法について。",
]
vectors = embed(chunks)
print(vectors.shape) # (2, 512)
ポイント
dimensionsで次元を短縮できる。ストレージを節約したいときに有効（精度劣化は事前評価で確認する）- レスポンスは
indexで並びを必ず突き合わせる。順序がズレるとベクトルと元テキストの対応が壊れる - 大量チャンクは1リクエストあたりの入力数・トークン上限に注意してバッチ分割する
パターン2：OSS（BGE-M3）でセルフホスト・ベクトル化
データを外に出さない構成です。sentence-transformers経由でローカル実行します。
# 動作環境: Python 3.11+, sentence-transformers>=3.0.0
# pip install sentence-transformers
# 注意: 本番利用前にテスト環境で動作確認すること
from sentence_transformers import SentenceTransformer
# 初回はモデルをダウンロード（GPUがあれば device="cuda" を指定）
model = SentenceTransformer("BAAI/bge-m3")
chunks = [
"契約の解約はマイページから手続きできます。",
"サブスクリプションのキャンセル方法について。",
]
# normalize_embeddings=True でL2正規化（後述、コサイン類似度の前提）
vectors = model.encode(
chunks,
normalize_embeddings=True,
batch_size=16,
)
print(vectors.shape) # (2, 1024)
ポイント
- APIコストはゼロだが、初回ダウンロードとGPU/CPUリソースが必要
normalize_embeddings=Trueで正規化しておくと、内積＝コサイン類似度になり検索が安定する- クエリと文書を必ず同じモデル・同じ正規化設定でベクトル化する
保存：ベクトルDBへの格納
生成したベクトルは、元テキスト・メタデータと一緒にベクトルDBへ保存します。Qdrantを例にした最小構成です。
# 動作環境: qdrant-client>=1.9.0
# pip install qdrant-client
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
qc = QdrantClient(url="http://localhost:6333")
DIM = 1024 # 使用するEmbeddingモデルの次元に合わせる
qc.recreate_collection(
collection_name="docs",
vectors_config=VectorParams(size=DIM, distance=Distance.COSINE),
)
points = [
PointStruct(id=i, vector=v.tolist(), payload={"text": t})
for i, (v, t) in enumerate(zip(vectors, chunks))
]
qc.upsert(collection_name="docs", points=points)
ポイント
- コレクションの
sizeはEmbeddingモデルの次元と完全一致させる（不一致はエラー or 検索破綻の原因） - 距離関数は
COSINEが無難。正規化済みベクトルなら内積（DOT）も等価 - 元テキストやソースURLを
payloadに必ず残す（検索後にLLMへ渡す材料になる）
精度を上げる4つの工夫
モデルを選んだだけでは精度は頭打ちになります。実務で効く工夫を4つ挙げます。
1. ベクトルの正規化を揃える
コサイン類似度で検索するなら、ベクトルをL2正規化しておくのが基本です。正規化済み同士なら内積＝コサイン類似度になり、計算も安定します。文書側とクエリ側で正規化の有無がズレると検索結果が崩れるので、必ず統一してください。
2. チャンク設計を見直す
長すぎるチャンクは1ベクトルに情報を詰め込みすぎて意味がぼやけ、短すぎると文脈が切れます。日本語の解説文書なら、見出し単位＋数百トークン程度＋オーバーラップを起点に、自前データで調整するのが現実的です。「最大トークン長まで詰める」のは多くの場合逆効果です。
3. リランカー（Reranker）と組み合わせる
Embeddingで上位k件（例: 30件）を広めに取り、その後クロスエンコーダ型のリランカーで並べ替えてから上位数件をLLMに渡す——この2段構えは、Embedding単体より精度が出やすい鉄板パターンです。Embeddingは「広く速く」、リランカーは「狭く正確に」と役割分担すると効きます。
4. クエリと文書のプレフィックス（instruction）を確認する
multilingual-e5系など一部のOSSモデルは、クエリにquery:、文書にpassage:のようなプレフィックスを付けることを前提に学習されています。これを忘れると本来の性能が出ません。使うモデルのモデルカードの推奨手順を必ず読むのが、地味ですが最も効く一手です。
【要注意】Embeddingモデル選定でよくある失敗パターン
失敗1：英語MTEBのスコアだけで日本語RAGのモデルを決める
❌ 「英語MTEBで1位だからこれにしよう」
⭕ 日本語データならJMTEBや自前データで評価し、多言語/日本語特化を確認する
なぜ重要か：英語で強いモデルが日本語でも強いとは限りません。言語が変われば最適なモデルも変わります。
失敗2：クエリと文書を別々のモデル・設定でベクトル化する
❌ 文書はモデルAで、後からクエリをモデルBで埋め込む
⭕ 質問と文書は必ず同じモデル・同じ正規化・同じプレフィックス設定で
なぜ重要か：異なるモデルで作ったベクトル同士の距離には意味がありません。検索が静かに壊れて、気づきにくいのが厄介です。
失敗3：とにかく高次元にしてベクトルDBのコストが爆発する
❌ 「精度のため3,072次元」で100万チャンクを格納し、DB費用が想定外に膨らむ
⭕ Matryoshka対応モデルで512〜1,024次元から始め、精度とコストの折り合いを評価で探る
なぜ重要か：次元数はストレージ・メモリ・検索コストに線形に効きます。多くの実務では中次元で十分です。
失敗4：自前データで評価せず、ブログの「最強ランキング」を鵜呑みにする
❌ 記事の順位だけ見て本採用
⭕ 代表的な50〜100問で Recall@k を測ってから決める
なぜ重要か：ドメイン・文体・専門用語によって最適解は変わります。評価は半日で回せるので、必ず通しましょう。
移行・運用：モデルを変えるときの再インデックス
Embeddingモデルは「一度決めたら終わり」ではありません。新モデルが出たり、精度に不満が出たりして、移行が必要になることがあります。ここで必ず押さえるべきは、モデルを変えたら原則すべての文書を再ベクトル化（再インデックス）するという点です。旧モデルと新モデルのベクトルは互換性がないため、混在させると検索が壊れます。
安全な移行の進め方は次の通りです。
- 新コレクションを別に作る：旧インデックスは残したまま、新モデルで別コレクションを構築する
- オフライン評価で比較する：同じ評価セット（50〜100問）で旧/新の Recall@k を測る
- シャドー運用する：本番トラフィックの一部を新インデックスにも流し、結果を比較ログに残す
- 切り替え＆ロールバック準備：問題なければ切替。劣化したら旧コレクションへ即戻せるようにしておく
また、ベクトルDBのコレクション次元はモデル次元と一致している必要があるため、次元が変わる移行では新コレクションが必須です。「再インデックスのコストと時間」を見積もりに織り込んでおくのが、後で慌てないコツです。大規模なら、Batch APIや夜間バッチで再ベクトル化のコスト・時間を抑える設計も検討しましょう。
よくある質問（FAQ）
Q1. Embeddingモデルとは何ですか？
テキストを「意味を表す数値ベクトル」に変換するモデルです。RAGでは、文書も質問も同じEmbeddingモデルでベクトル化し、ベクトルの近さで関連文書を検索します。検索精度を左右する中核コンポーネントです。
Q2. RAGの精度が低いとき、まず何を見直すべきですか？
生成側のLLMやプロンプトより先に、Embeddingモデルとチャンク設計を疑うのが費用対効果が高いです。日本語データなら、多言語/日本語特化モデルへの変更が効くことが多く、加えてリランカーの追加も有効です。
Q3. OpenAIのEmbeddingで日本語RAGを組んでも大丈夫ですか？
動きますし、立ち上げには十分です。ただし日本語の検索精度を最重視するなら、Google・Cohere・Voyageの多言語モデルや、日本語特化OSS（Ruri等）を自前データで比較する価値があります。最終判断は必ずオフライン評価で行ってください。
Q4. 次元数は大きいほど良いのですか？
必ずしもそうではありません。次元が大きいほど表現力は上がりますが、ストレージ・メモリ・検索コストが線形に増えます。近年の主要モデルはMatryoshka表現学習で次元を短縮しても精度劣化を抑えられるため、512〜1,024次元から評価で詰めるのが実務的です。
Q5. APIモデルとオープンソースのセルフホスト、どちらを選ぶべきですか？
データを外部に出せない・オフライン要件がある・レイテンシを自前で制御したいならセルフホスト（OSS）。運用負荷を最小化したいならAPIが楽です。BGE-M3やRuriはセルフホストの定番で、APIコストはゼロですが計算資源とMLOpsの手間が発生します。
Q6. モデルを変更したら何が必要ですか？
原則として全文書の再ベクトル化（再インデックス）が必要です。旧/新モデルのベクトルは互換性がないため混在できません。新コレクションを別に作ってオフライン評価で比較し、問題なければ切り替える流れが安全です。
まとめ：今日から始める3つのアクション
- 今日やること：いま使っているEmbeddingモデルの「次元数・対応言語・最大トークン長・単価」を公式ドキュメントで確認し、自分のユースケース（日本語かどうか・データを外に出せるか）と照らし合わせる
- 今週中：代表的な50〜100問の評価セットを作り、現行モデルと候補1〜2モデルで Recall@k を測って比較する
- 今月中：勝ったモデルで新コレクションを構築し、シャドー運用→切り替え。次元短縮（Matryoshka）やリランカー追加でコスト・精度を最適化する
あわせて読みたい
- ベクトルDB徹底比較【2026年最新】 — Embeddingで作ったベクトルを「どこに保存するか」を選ぶ記事。本記事の次の一手に
- AIgent Lab 記事一覧 — RAG・AIエージェント構築の実装ガイドをまとめています
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント・RAG導入の研修・コンサルを行っています。お気軽にご相談ください。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
参考・出典
- Embeddings – OpenAI API Guide — OpenAI（参照日: 2026-06-03）
- text-embedding-3-large Model — OpenAI（参照日: 2026-06-03）
- Cohere’s Embed Models (embed-v4.0) — Cohere（参照日: 2026-06-03）
- Text Embeddings – Voyage AI — Voyage AI（参照日: 2026-06-03）
- Pricing – Voyage AI — Voyage AI（参照日: 2026-06-03）
- Gemini Embedding model (gemini-embedding-001) — Google（参照日: 2026-06-03）
- MTEB Leaderboard — Hugging Face / MTEB（参照日: 2026-06-03）
- BGE-M3 Model Card — BAAI / Hugging Face（参照日: 2026-06-03）
- multilingual-e5-large Model Card — intfloat / Hugging Face（参照日: 2026-06-03）
- Ruri v3 Model Card — cl-nagoya / Hugging Face（参照日: 2026-06-03）
