エンベディングとは何か｜ベクトル検索の仕組みをRAGの内側から理解する

「社内文書をAIに答えさせたい」と考えてRAGを調べると、必ず出てくるのがエンベディング(embedding、埋め込み)とベクトル検索という言葉です。これはRAGだけでなく、意味検索やレコメンド、重複検出など幅広い仕組みを支える普遍的な基礎技術です。この記事では、エンベディングが何をしているのかを数式に頼らず説明したうえで、ベクトル検索の仕組み、RAGの内側での使われ方、実務での勘所と向かない場面までを整理します。

エンベディングとは：意味を座標に変える#

エンベディングとは、テキスト(や画像・音声など)を、意味を反映した数値の並び=ベクトルへ変換する技術です。たとえば「猫」という単語を[0.021, -0.135, 0.088, ...]のような数百から数千個の数値の並びに置き換えます。この変換は専用のエンベディングモデルが行い、意味が近い言葉や文ほど、ベクトルとしても近い位置に配置されるように学習されています。

イメージとしては、あらゆる文の意味を巨大な地図の上の座標に置く作業です。「経費精算の締切」と「精算はいつまでに出せばよいか」は、表現は違っても意味が近いので地図上でも近くに置かれます。逆に「経費精算」と「社員旅行」は離れた場所に置かれます。この「意味の近さが位置の近さになる」という性質が、後述するベクトル検索の土台になります。

なぜ数値化する必要があるのか#

コンピュータは「意味が近いかどうか」を文字列のままでは判断できません。文字列同士は一致するかしないかしか比べられないためです。そこで意味を数値ベクトルに変換しておくと、ベクトル同士の距離という形で「どのくらい意味が近いか」を計算できるようになります。この一手間が、キーワードの表記ゆれや言い換えに強い検索を可能にします。

ベクトル検索(意味検索)の仕組み#

ベクトル検索は、エンベディングを使って「意味的に近い文書」を探す検索方式です。手順にすると次のようになります。

距離の測り方としてよく使われるのがコサイン類似度です。これは2つのベクトルが向いている方向がどれだけ揃っているかを見る指標で、値が大きいほど意味が近いと解釈します。ほかにドット積(内積)やユークリッド距離も使われます。エンベディングを長さ1に正規化してある場合、コサイン類似度とドット積は同じ結果になるため、計算が速いドット積を使う実装も一般的です。

文書量が多いと全件との距離をまじめに計算するのは重いため、実務では近似最近傍探索(ANN)という、多少の誤差を許して高速に近いベクトルを見つける手法を使います。多くのベクトルデータベースがこの仕組みを備えています。

キーワード検索との違い#

従来の全文検索(キーワード検索)は、入力した単語が文書に含まれているかを軸に探します。速くて挙動が分かりやすく、型番や氏名のような固有の文字列にはとても強い一方、言い換えや表記ゆれには弱いのが特徴です。「PC」で検索して「パソコン」としか書かれていない文書が引っかからない、といったことが起きます。

ベクトル検索(意味検索)はこの逆で、単語が一致しなくても意味が近ければ拾えます。ただし固有名詞や型番のような「まさにこの文字列」を厳密に当てる用途は苦手で、似た別のものを近いと判断してしまうことがあります。

どちらか一方が優れているわけではなく、両方を組み合わせるハイブリッド検索が実務では有力な選択肢になります。キーワード検索で拾える厳密な一致と、ベクトル検索で拾える意味的な近さを、両取りする発想です。

RAGの内側でどう使われるか#

RAG(検索拡張生成)は、質問に関連する文書を検索してからLLMに渡し、その内容に基づいて回答させる仕組みです。この「検索」の中核を担うのがエンベディングとベクトル検索です。

【事前準備(インデックス作成)】
  文書を適切な長さに分割(チャンク分割)
    -> 各チャンクをエンベディングでベクトル化
    -> メタデータ(部署・日付など)と一緒にベクトルDBへ保存

【質問時(検索と生成)】
  利用者の質問をベクトル化
    -> ベクトルDBで近いチャンクを取得
    -> (必要ならRerankerで並べ替え)
    -> 質問と取得チャンクをプロンプトに入れてLLMが回答

RAGの回答品質は、LLMの賢さよりも「正しいチャンクを検索で引き当てられるか」に大きく左右されます。つまりエンベディングとベクトル検索の設計が、RAG全体の精度を握っていると言っても言い過ぎではありません。RAG全体の仕組みや向き不向きは別記事で扱っているので、あわせて読むと全体像がつかめます。

2段構成：ベクトル検索とRerankerの組み合わせ#

実務でよく使われるのが2段構成です。まずベクトル検索で候補を広めに取得し(1段目)、次にRerankerと呼ばれるモデルで質問との関連度を精査して並べ替えます(2段目)。ベクトル検索は速く大量の候補をふるいにかけるのが得意な一方、本当に関連の高いチャンクが上位に来るとは限らないためです。

Rerankerは質問と文書をペアで見て関連度を出すため、ベクトル検索だけよりも上位の精度が上がりやすいとされています。その代わり1件ずつ丁寧に見るぶん処理は重いので、ベクトル検索で数十件に絞ってからRerankerにかける、という役割分担が現実的です。

実務の勘所#

エンベディングを使った検索を実運用に乗せるとき、効いてくるポイントを整理します。

• チャンク設計:文書をどの長さで区切るかは精度に直結します。長すぎると1つのベクトルに複数の話題が混ざってぼやけ、短すぎると文脈が失われます。見出しや段落など意味の区切りに沿って分割し、想定質問で当たり具合を見ながら調整します。
• エンベディングモデル選び:日本語を含む多言語への対応、次元数、コスト、更新頻度への追従を軸に選びます。代表的な提供元にはOpenAI(text-embedding-3系)や、Anthropicが公式に推奨するVoyage AI(多言語・ドメイン特化モデルなどを提供)があり、いずれも複数言語に対応します。次元数を落とせるモデルもあり、精度と保存・計算コストのトレードオフを調整できます(たとえば大きな次元を先頭から一部だけ使う方式)。
• メタデータフィルタ:部署・文書種別・日付などをメタデータとして持たせ、ベクトル検索の前後で絞り込むと、無関係な文書の混入を減らせます。「自部署の最新版だけ」といった条件は意味の近さだけでは表現しにくいので、メタデータで補います。
• 評価する:体感ではなく、想定質問を集めて正答率や適合率を測ります。エンベディングモデルやチャンク設計を変えたときに良くなったか悪くなったかは、数字で比べないと判断できません。

エンベディングモデルの選定やチャンク設計は、追加学習でモデル自体をいじるファインチューニングとは別の話です。知識を足したいのか、応答の形式を整えたいのかで打ち手が変わるため、両者の使い分けもあわせて押さえておくと設計に迷いにくくなります。

向かない場面#

エンベディングとベクトル検索は万能ではありません。次のような場面では、別の手段のほうが適しています。

• 厳密な完全一致が要る:型番・製品コード・氏名などを取り違えなく当てたい場合は、キーワード検索やデータベースの完全一致のほうが確実です。
• 最新性が命の情報:在庫数や当日の価格のように刻々と変わる値は、ベクトルDBに貯めた時点で古くなります。こうした情報はAPIやデータベースへ都度問い合わせる仕組みにすべきです。
• 文書がごく少数:数件から数十件程度なら、わざわざベクトル化せずに文書をそのままLLMのプロンプトへ渡す(ロングコンテキスト活用)ほうが簡単で精度も出やすいことがあります。
• 全体の集計や網羅列挙:「該当する契約をすべて数えて」のように文書全体を漏れなく見る必要がある要件は、関連の強い一部を返すベクトル検索とは原理的に相性が悪く、従来型のデータ処理が向きます。

要は「意味の近さで一部を取り出す」という性質が活きる場面かどうかで判断します。取り出したチャンクをLLMへどう渡すかという文脈設計の考え方は、コンテキストエンジニアリングの観点もあわせて見ておくと精度改善の引き出しが増えます。

本記事の次元数の具体値(1536/3072)はOpenAI公式ドキュメント記載の値で、モデルにより異なり今後変わり得ます。なお、Anthropicは自社のエンベディングモデルを提供しておらず、公式ドキュメントではVoyage AIのモデルを推奨しています(input_typeなどの呼び出し方の裏付けとして参照しています)。特定モデルの優劣や価格の断定は避け、選定時は各提供元の最新ドキュメントを確認してください。2段構成(検索とReranker)の解説はPineconeの技術記事を参照しています。

よくある質問#

まとめ#

エンベディングとベクトル検索は、RAGや意味検索を内側で支える地味だが要となる技術です。派手な性能競争の話題になりにくい部分ですが、ここの設計が検索精度、ひいてはRAG全体の使い勝手を大きく左右します。まずは小さな文書セットと想定質問で、検索結果を自分の目で確かめるところから始めるのが、遠回りに見えて確実な進め方です。取り出した情報をLLMへどう渡すかという次の論点も、あわせて押さえておくとよいでしょう。