埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】

社内文書を検索するチャットボットを作るとき、コードを書く前に決めるのが埋め込みモデルです。文章を768次元や3072次元の数値ベクトルへ変換し、意味の近さを距離として計算できる形に直す部品を指します。本記事では定義と内部の処理から始めて、商用APIとオープンウェイトの仕様差、日本語での精度をJMTEBスコアから読む手順、実装とベクトルデータベースへの投入、そして途中でモデルを乗り換えるべきかの判断基準までを実装者の目線で整理しました。

まとめ：埋め込みモデルの選定基準と、商用APIと日本語特化モデルの分かれ目

先に結論を置きます。埋め込みモデルは、入力したテキストに対して固定長の実数ベクトルを1本返すモデルです。返るのは意味を座標へ置き換えた数字の並びだけで、座標同士の角度を測ると、単語が一致しない文章でも近さを判定できます。

選定を決める軸は3つ、日本語での精度と、入力できるトークン数の上限と、モデルの重みを自社環境へ持ち込めるかどうかです。本文を社外へ送れる案件なら text-embedding-3-small（1536次元・入力上限8192トークン）から始め、精度が足りなければ 3-large（3072次元）へ上げる進め方が最短。送れない案件では、Apache-2.0で配布される日本語特化のRuri v3系や、MITのmultilingual-e5・BGE-M3が候補になります。

逆に、モデル変更へ着手すべきでない場面もはっきりしています。検索が当たらない原因の多くは、モデルではなくチャンクの切り方と検索設計にあるからです。1文書を丸ごと1ベクトルにしている状態でモデルだけ差し替えても、再ベクトル化のコストを払って結果は変わりません。

埋め込みモデルの定義と、テキストをベクトルへ変換する処理の内部構造

埋め込みモデルの定義と、テキスト生成モデルとの入出力・用途の違い

埋め込みモデル（Embedding Model）とは、テキストを入力すると固定長の数値ベクトルを返すモデルを指します。text-embedding-3-small なら、10文字の質問でも4,000文字の議事録でも、返るのは同じ1536個の実数。長さが揃うからこそ、データベースへ格納して距離計算にかけられます。

生成モデルとの違いは出力の型に集約されます。GPT系やGemini系はトークンを順に予測して文章を返しますが、埋め込みモデルは文章を返しません。用途も検索・分類・重複検出といった「比べる」処理に寄ります。検索した文書を読ませて回答を作る部分は生成モデルの担当で、両者を組み合わせた構成がRAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説で扱った検索拡張生成にあたります。

次元数が表すものと、768次元と3072次元で変わる精度と保存量

次元数は、1つのテキストを何個の数値で表すかを示します。Ruri v3-310mは768次元、multilingual-e5-largeとBGE-M3は1024次元、text-embedding-3-largeは3072次元。数値が多いほど細かい意味の差を表現できる一方、保存量と計算量は比例して増えます。

保存量は概算できます。float32で持つなら1ベクトルあたり「次元数×4バイト」で、768次元は約3KB、3072次元は約12KB。10万チャンクなら約300MBと約1.2GBの差です。次元は後から短縮もできて、OpenAIのv3系2モデルとGeminiの埋め込みモデルは Matryoshka Representation Learning により、末尾を切り落としても意味的な性質が保たれるよう学習されています。gemini-embedding-2 の指定範囲は128から3072、公式の推奨値は768・1536・3072。

コサイン類似度で近さを測る仕組みと、正規化後の内積との等価性

ベクトル同士の近さは、ほとんどの実装でコサイン類似度で測ります。2本がなす角度の余弦で、同じ向きなら1、直交なら0。ベクトルの長さ（文章の長短に引きずられる成分）を無視できるため、テキスト検索と相性の良い指標です。

実装ではL2正規化を先に済ませておくと、コサイン類似度と内積が一致します。正規化していないベクトルを入れて距離関数に内積を選ぶと、長い文書ばかりが上位に来る挙動になり、設定を1つ違えるだけで検索結果が壊れます。

主要な埋め込みモデルの仕様比較と、次元・入力上限・ライセンスの実測値

商用APIの次元可変仕様と、OpenAIとGeminiで異なる入力上限

OpenAIの公式ドキュメントに載る埋め込みモデルは3つです。text-embedding-3-small が既定1536次元、text-embedding-3-large が既定3072次元、旧世代の text-embedding-ada-002 が1536次元。入力上限はいずれも8192トークンで、v3系の2モデルは dimensions パラメータによる次元短縮に対応します。

Google側は世代差が大きい。gemini-embedding-2 の入力上限は8,192トークンですが、旧版の gemini-embedding-001 は2,048トークンにとどまります。さらに 2 では task_type パラメータが廃止され、検索用途か分類用途かの指示をプロンプト本文へ直接書く方式へ変わりました。001 にあった RETRIEVAL_QUERY など8種類の指定は使えず、移行時にコードの修正が要ります。料金と日本語での挙動はGemini Embedding 2とは？料金・仕様・OpenAI比較とマルチモーダルRAG実装を解説で個別に扱いました。

オープンウェイト勢の仕様と、Apache-2.0とMITで分かれる配布条件

自社サーバーやVPC内で動かす選択肢では、ライセンスが最初の足切りになります。intfloat の multilingual-e5-large と BAAI の bge-m3 はMIT、cl-nagoya の ruri-v3-310m と Preferred Networks の plamo-embedding-1b はApache-2.0で、いずれも商用利用を許可する条件です。Hugging Face APIで直近30日のダウンロード数を見ると、bge-m3 が約3,538万、multilingual-e5-large が約772万、ruri-v3-310m が約69万（2026年8月2日実測）。

仕様面では bge-m3 が異色で、密ベクトルに加えて語彙単位のスパース表現とColBERT式のマルチベクトル表現を同時に出せます。対応は100言語超、入力上限は8192トークン。密検索と疎検索を1モデルで賄う構成なら第一候補です。ColBERT式のマルチベクトル表現そのものの仕組みと索引コストはColBERTの仕組みと採用条件の解説にまとめています。

6モデルの仕様比較表と、案件条件から候補を2つへ絞り込む読み方

主要6モデルの仕様を実測値で並べます。料金欄のページ換算は、OpenAI公式ドキュメントの記載をそのまま引きました。

読み方の順序を決めておくと迷いません。まず「本文を社外APIへ送れるか」で表を上下2つに割ります。送れるなら商用API3行だけを見て、コスト重視なら text-embedding-3-small、精度優先なら 3-large。送れないなら日本語文書が中心の案件で ruri-v3-310m、多言語や長文が混在するなら bge-m3。multilingual-e5-large は入力上限512トークンの制約が重く、既存資産がある場合を除いて新規案件の第一候補にはしません。

日本語テキストでの精度差と、JMTEBスコアから読む選定の勘所

JMTEB平均77.24が示すものと、タスク別スコアの読み分け

日本語の埋め込み性能を比べる指標がJMTEB（Japanese Massive Text Embedding Benchmark）です。cl-nagoya/ruri-v3-310m のモデルカードに載る実測値は平均77.24で、内訳は Retrieval 81.89、STS 81.22、Classification 78.66、Reranking 93.43、Clustering 55.69、Pair Classification 62.60。

平均だけを見て選ぶと外します。RAGの検索で効くのは Retrieval と Reranking の2つで、Clustering の55.69が低いことは文書検索用途に響きません。問い合わせメールの自動分類なら Classification、重複検出なら Pair Classification を見る。用途とタスク名を対応づけてから数字を読む、この順序で選定の精度が変わります。

プレフィックス設計の違いと、付け忘れで検索精度が落ちる実害と対処

オープンウェイトの日本語・多言語モデルには、入力の先頭へ用途を示す接頭辞を付ける約束があります。multilingual-e5-large は検索クエリに query: 、検索対象の文書に passage: 。Ruri v3系は1+3方式で、意味エンコードは接頭辞なし、分類は「トピック: 」、検索側は「検索クエリ: 」と「検索文書: 」を付けます。

付け忘れてもエラーは出ません。multilingual-e5 のFAQは、接頭辞を除くと性能が劣化すると明記しています。学習時にその形で訓練されているためで、数値は返り検索も動き、順位だけが静かに崩れる。対処は、埋め込み生成をクエリ用と文書用の2関数に分けて1箇所へ集約することです。呼び出し側から生の文字列を渡せなくしておけば、人が増えても設計は崩れません。OpenAI系のAPIに接頭辞の規約はないため、この対処はローカルモデル案件に限った話です。

512トークン上限がチャンク設計に課す制約と8192系との使い分け

multilingual-e5-large の入力上限は512トークンで、超過分は切り捨てられます。日本語では1トークンがおおむね1文字前後のため、3,000文字のマニュアル1節をそのまま渡しても、後半はベクトルへ反映されません。この1トークンあたりの文字数がどう決まるかはトークナイザーの仕組みと日本語のトークン消費で扱っています。

この上限は、そのままチャンク設計の上限になります。512トークン系なら分割を小さく抑える必要があり、チャンク数とベクトル件数が増える。8192トークン系（bge-m3、Ruri v3、OpenAI v3系）は節や章の単位で切れて、文脈が途切れにくくなります。どこで切るかの具体はチャンク分割の手法とチャンクサイズの決め方に整理しました。入力上限は後から広げられないため、8192トークン系を前提に設計するほうが手戻りが出ません。

埋め込み生成の実装手順と、APIとローカル実行で変わる設計判断

OpenAI APIでの埋め込み生成と、dimensions指定での次元短縮

商用APIでの生成は、モデル名と入力テキストを渡すだけで完了します。手順は4段階です。

1. 入力テキストを8192トークン以内に収まる単位へ分割する
2. モデル名と入力配列を指定して埋め込みエンドポイントを呼ぶ
3. 保存量を削るなら短縮後の次元を dimensions に指定する
4. 返ったベクトルをL2正規化してから保存する

複数テキストを1リクエストへまとめられる点は、料金ではなく所要時間に効きます。数万件の初期投入では逐次とバッチで桁が変わるため、最初からまとめて送る実装にしておく。次元をどこまで落とすかは、検索精度を測ってから決めます。

sentence-transformersでローカル実行する手順とバッチ設計

オープンウェイトのモデルは sentence-transformers 経由で動かすのが定番です。モデルIDを指定して読み込み、encode にテキストの配列を渡すとベクトル配列が返ります。正規化は normalize_embeddings を有効にすれば済む。API方式と並べた実装例はPythonでembedding（ベクトル化）を生成する方法にまとめています。

設計で詰まるのはバッチサイズとハードウェアです。ruri-v3-310m は315Mパラメータ（埋め込み層を除くと236M）で、GPUがなくても動く規模。ただし数万チャンクを処理するなら、1,000件で所要時間を測って全件へ線形に伸ばします。この確認を省くと、本番投入が数日単位で止まります。

ベクトルDBへ投入する際の次元設定と、距離関数の整合の取り方

ベクトルデータベース側は、コレクション作成時に次元数と距離関数を固定します。宣言した次元と投入するベクトルの次元が食い違えばエラー。次元短縮を使う構成では、短縮後の値を宣言します。距離関数はL2正規化済みなら内積、していなければコサイン類似度を選び、混在させないことが要点です。初期投入では正規化していたのに追加バッチで抜けていると、後から入れたデータだけ検索に出てきません。インデックス構造の違いが検索結果へどう効くかはベクトル化とインデックス構造から理解するベクトルデータベースの仕組みで扱いました。

文書ID・出典URL・更新日といったメタデータも、同じタイミングで設計します。省くと1文書の差し替えごとに全件を入れ直すことになります。

埋め込みの運用コストと、モデル差し替え時に生じる再ベクトル化の負担

公式のpages-per-dollarから逆算した100万トークンの費用感

OpenAIの公式ドキュメントは、1ドルあたりの処理ページ数で目安を示しています。text-embedding-3-small が62,500ページ、3-large が9,615ページ、ada-002 が12,500ページ。1ページ約800トークンの換算です。

100万トークン単位へ直すと、small は概算0.02ドル、large は概算0.13ドルで、差は約6.5倍。日本語50万文字を一度ベクトル化する程度なら、どちらでも数十円から数百円に収まります。費用が効いてくるのは初期投入ではなく、検索クエリ側の継続コストです。1日1万クエリを1年回せば3,650万トークン規模になり、ここで6.5倍の差が効いてきます。

モデル変更が全件再ベクトル化になる理由と切り替え費用の見積り

埋め込みモデルを変えると、既存のベクトルはすべて捨てることになります。モデルごとに座標系が違うため、text-embedding-3-small で作ったベクトルと ruri-v3-310m のベクトルを同じインデックスへ混ぜても、距離が意味を持ちません。次元数が同じ1024のモデル同士でも同様です。

見積りに入れる費用は3つ。再生成のAPI料金または計算リソース、投入し直す時間、切り替え期間の品質担保にかかる運用工数です。10万チャンク規模なら生成自体は数百円と数時間で済む一方、本番稼働中は新旧インデックスの並行運用が要り、そちらが重くなります。乗り換えの計画は、この工数で崩れます。

埋め込みモデルを乗り換える条件と、切り替えを見送るべき3つの場面

商用APIを選ぶ条件と、ローカルモデルへ倒す分岐点の実務基準

商用APIとローカルの選択は、制約で決まります。分岐点は次の3つ。

• 文書本文を社外へ送出できるか（契約・規程・個人情報の有無）
• 推論用のGPUまたはCPUリソースを継続的に確保できるか
• モデルの版を自社で固定し続ける必要があるか

1つ目が「送れない」なら、その時点でローカル一択です。2つ目と3つ目は程度問題で、月数万クエリ規模までは商用APIが総コストで有利になります。GPUインスタンスの維持費は、100万トークン0.02ドルの埋め込み料金よりはるかに高いからです。逆に数千万件規模のバッチを定期実行する構成や、外部サービスの仕様変更で挙動が変わるリスクを取れない用途なら、Apache-2.0のRuri v3系をローカルで固定する判断に合理性があります。

モデル変更では直らない失敗パターンと、先に見直すべき検索設計

検索が当たらないときにモデルを疑うのは、たいてい順番が違います。先に潰すべき失敗パターンを頻度の高い順に3つ挙げます。

最多はチャンクが大きすぎて1ベクトルに複数の話題が混ざっている状態で、3,000文字の節を1本にすると意味が平均化され、どの質問にも中程度にしか反応しません。話題の切れ目で分ける手法とその採否条件はセマンティックチャンキングとは？意味の切れ目で分ける仕組みと実装・採否判断【2026年版】で整理しました。次がクエリ側と文書側で前処理を揃えていないケース。3番目は、型番・法令番号・固有の略語のように完全一致が要る検索を、意味検索へ投げている構成です。

3番目は設計で解きます。キーワード検索と併用するハイブリッド検索の考え方か、上位候補を並べ替えるリランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方で扱った後段処理を足すほうが、埋め込みモデルを1段上げるより効きます。この3つを潰す前にモデルを差し替える判断は採用しません。再ベクトル化のコストを払って、原因が残るからです。

受託開発で最初に固定すべき設計項目と、PoCから本番までの進め方

着手時に固定するのは、埋め込みモデル・次元数・チャンク分割の粒度・距離関数の4項目です。後から変えると全件やり直しになるため、PoCの初日に決めて文書へ残します。検索件数やプロンプト、リランクの有無は稼働後も調整できるので、PoC段階では作り込みません。

進め方の型としては、評価用の質問を50件用意する作業を最初に置きます。問い合わせ履歴から抜き出し、正解となる文書を人手で紐づける。この評価セットがないまま複数モデルを比べても、感想以上の判断になりません。セットさえあれば、モデル2つと次元2水準の計4パターンを1日で比較できます。文書量が多い案件や既存システムとの接続を含む構成では、一創のRAG構築支援で、モデル選定と評価セットの整備から本番運用への移行までを受託しています。

よくある質問

埋め込みモデルの選定と実装で、着手時に相談の多い5点へ回答します。

埋め込みモデルと生成AIモデルは何が違いますか？

出力の型が違います。埋め込みモデルは入力テキストに対して固定長の数値ベクトル（text-embedding-3-small なら1536個の実数）を返すだけで、文章は生成しません。生成モデルはトークンを順に予測して文章を返します。用途も分かれ、埋め込みは検索・分類・重複検出の土台、生成は回答文の作成が担当です。

日本語のRAGではどのモデルを最初に試すべきですか？

文書を社外APIへ送れる案件なら text-embedding-3-small が出発点です。1536次元・入力上限8192トークンで100万トークンあたり概算0.02ドルと安く、精度が足りなければ 3-large へ上げられます。送れない案件では、Apache-2.0の cl-nagoya/ruri-v3-310m（768次元・JMTEB平均77.24）を先に試してください。

次元数は多いほど検索精度が上がりますか？

傾向としては上がりますが、比例はしません。3072次元の text-embedding-3-large は1536次元の small より高い精度を示す一方、保存量は2倍、料金は約6.5倍。OpenAIとGeminiの埋め込みモデルは次元を切り詰めても意味的性質が保たれる設計のため、3072次元を1536次元へ落としても実用上の差が出ない案件は珍しくありません。どこまで落とせるかは、実案件の質問セットで Recall@5 を測って決めます。

埋め込みモデルを変更したら既存のベクトルは使えますか？

使えません。モデルごとにベクトル空間の座標系が異なるため、別モデルで生成したベクトルを同じインデックスへ混ぜると距離計算が意味を失います。次元数が偶然一致していても同じです。変更する場合は全件を再ベクトル化し、インデックスを作り直します。10万チャンク規模なら生成費用は数百円・時間は数時間で済む一方、本番稼働中は並行運用と切り替えの段取りが要ります。

埋め込みだけで検索精度が足りない場合は何を足しますか？

まずチャンク分割の粒度と、クエリ側・文書側の前処理の揃い方を確認します。それでも足りない場合の打ち手は2つ。1つはキーワード検索と組み合わせるハイブリッド検索で、型番や法令番号のような完全一致が要る検索に効きます。もう1つは上位候補をリランクモデルで並べ替える構成。どちらも既存ベクトルを作り直さずに追加できるため、モデル差し替えより先に試してください。

関連記事

• Gemini Embedding 2とは？料金・仕様・OpenAI比較とマルチモーダルRAG実装を解説：Google側の仕様と料金の個別解説です
• Amazon Nova Multimodal Embeddingsとは何か？ 最先端のマルチモーダル埋め込みモデルの全体像：画像や動画も同じ空間へ載せる派生系です
• 深い思考を実現する埋め込みモデル「O1 Embedder」の特徴：検索時に推論を挟む研究寄りの手法です
• グラフ埋め込み（Graph Embedding）とは？手法比較・GNNとの関係・Python実装まで：グラフ構造をベクトル化する別系統です
• ベクトル化とインデックス構造から理解するベクトルデータベースの仕組み：生成したベクトルを格納する側の解説です