RAG（検索拡張生成）の中身を理解するには、その手前にある二つの技術——埋め込み（embedding）とベクトル検索——を押さえておくと一気に見通しが良くなります。ざっくり言えば、文章を「意味を表す数値の列」に変換し（埋め込み）、その数値の近さで似た文章を探す（ベクトル検索）。本記事は、この二つを具体例と図で、初めての人でも読めるように整理します。
01埋め込みとは「文章を座標に置く」こと
埋め込みとは、文章や単語を数百〜数千個の数値が並んだベクトルに変換する技術です。鍵になる性質は一つだけ。意味が近い文章どうしは、変換後のベクトルも近い場所に来る——これだけです。
イメージしやすいよう、まず 3 つの数値（3 次元）に縮めた例で説明します。各単語が空間上の一点（座標）になると考えてください。
| 単語 | ベクトル（3次元の例） |
|---|---|
| 犬 | [0.8, 0.1, -0.5] |
| 猫 | [0.7, 0.2, -0.4] ← 犬に近い |
| 自動車 | [-0.3, 0.6, 0.9] ← 犬から遠い |
「犬」と「猫」は座標が近く、「自動車」は離れています。実際の埋め込みモデルが作るベクトルは 3 次元ではなく、1024〜3072 次元といった高次元です。たとえば OpenAI の text-embedding-3-small は 1536 次元、text-embedding-3-large は 3072 次元のベクトルを返します。人間には絵に描けない次元数ですが、「意味が近ければ座標も近い」という原理は 3 次元の例とまったく同じです。
FIG.1 埋め込みモデルが文章を高次元ベクトル＝意味空間の一点に変換する。意味が近い語は近くに集まる
02キーワード検索とどう違うのか
従来のキーワード検索は文字が一致するかを見ます。一方ベクトル検索は意味が近いかを見ます。この違いが、検索の取りこぼしを大きく左右します。
| 検索方式 | 質問「車を買いたい」で拾えるもの |
|---|---|
| キーワード検索 | 「車」「買」という文字を含む文書だけ |
| ベクトル検索 | 「自動車の購入」「クルマが欲しい」など言い換えも拾える |
ベクトル検索は表記ゆれ・同義語・言い換えに強いのが持ち味です。ただし万能ではありません。製品コード（例：型番 XR-200）、人名、条文番号のように一字一句の一致が重要な情報では、むしろキーワード検索のほうが確実です。実務ではこの二つを組み合わせる「ハイブリッド検索」が定番になっています（後述）。
03「近さ」をどう測るか — 類似度の計算
ベクトル検索の心臓部は、二つのベクトルがどれくらい近いかを数値で測ることです。代表的な測り方は三つあります。
コサイン類似度
ベクトルの「向き」の近さを測る。-1〜1 の範囲で、1 に近いほど似ている。テキスト検索の標準。
内積（ドット積）
向きに加えて「大きさ」も考慮する。多くのベクトル DB で高速に計算できる既定の指標。
ユークリッド距離
2 点間の直線距離。0 が完全一致で、値が小さいほど近い。
初学者がつまずきやすいのは「どれを選べばいいのか」ですが、実は気にしすぎる必要はありません。多くの埋め込みモデルはベクトルの長さを 1 に揃える（L2 正規化する）ように作られており、正規化されたベクトルではコサイン類似度・内積・ユークリッド距離が同じ順位を返すからです。順位が同じなら、検索結果の並びも同じになります。実装上は、向きだけを見るコサイン類似度（＝正規化後は内積と一致）が最も広く使われています。
意味の似ているテキストは、ベクトル空間で同じ方向を向く。だから「向きの近さ」を測るコサイン類似度が標準になる。
目安として、コサイン類似度が 0.8 以上なら「かなり似ている」、0.9 以上なら「ほぼ同じ話題」と捉えると感覚がつかめます。ただしこのしきい値はモデルや文書の種類で変わるため、自分のデータで実際に値を見て調整するのが正解です。
FIG.2 質問もベクトル化し、意味空間で近い点（＝似た文章）だけを上位として拾う
04埋め込みモデルの選び方（2026年の実情）
埋め込みを作るのは「埋め込みモデル」と呼ばれる専用モデルです。選択肢は API 型（手軽）と OSS 型（自前運用・無料）に大きく分かれます。2026 年時点でよく使われるものを整理します。
| モデル | 次元 / 特徴 |
|---|---|
| OpenAI text-embedding-3-small | 1536 次元。安価で標準的な第一候補 |
| OpenAI text-embedding-3-large | 最大 3072 次元。次元を縮めて使うことも可能（精度と容量のトレードオフ） |
| Google Gemini Embedding 001 | 3072 次元。テキスト・画像・音声などを同じ空間に埋め込む多モーダル型。総合ベンチ（MTEB）で上位 |
| Cohere Embed v4 | 多言語・長文に強い API 型 |
| Voyage AI voyage-3.5 / voyage-4 系 | Anthropic が推奨する API 型。コスト対精度のバランスが良い |
| Qwen3-Embedding（8B 等） | OSS（Apache 2.0）。自前ホスト可能で多言語に強い、OSS の代表格 |
| BGE-M3 / multilingual-e5-large | 1024 次元の OSS。無料セルフホスト、日英横断に対応 |
モデルの優劣は MTEB という公開ベンチマークでよく比較されますが、ランキングは数か月単位で入れ替わります。「いま一番」を固定で覚えるより、自分の文書で小さく試して比べるのが結局いちばん確実です。なお、次元数が大きいほど一般に精度は上がりやすい一方、保存容量と検索コストも増えます。多くの用途では 1024〜1536 次元あたりが扱いやすい落としどころです。
05大量のベクトルを高速に探す — ベクトルデータベース
文書が数万・数百万件になると、毎回すべてのベクトルと総当たりで類似度を計算するのは現実的ではありません。そこで、近いベクトルを高速に絞り込む索引（代表的なアルゴリズムが HNSW＝近傍をたどって探すグラフ索引）を備えたベクトルデータベースを使います。2026 年の主要な選択肢は次の通りです。
| ベクトル DB | 特徴・向いている場面 |
|---|---|
| pgvector | PostgreSQL の拡張。既存の Postgres にそのまま追加でき、~1000万ベクトル規模までの多くの用途で第一候補 |
| Pinecone | フルマネージド。運用を任せたいチーム向けの定番 |
| Qdrant | Rust 製の OSS。速度に定評があり、公開ベンチで上位 |
| Weaviate | OSS＋クラウド。ハイブリッド検索（後述）に最も強い |
| Milvus | 大規模・本格運用向けの OSS |
| Chroma | 軽量で導入が容易。試作・開発に向く |
導入のハードルが最も低いのは pgvector です。すでに PostgreSQL を使っているなら、新しいインフラを増やさずに拡張機能を入れるだけでベクトル検索を始められます。規模が大きくなり、超低遅延や運用コストの最適化が必要になった段階で、Qdrant や Pinecone などの専用 DB へ移行する——という進め方が現実的です。重要な注意点として、索引を作るときの類似度指標と検索時の指標は必ず揃えること（例：コサインで索引を作ったのに内積で検索すると結果がずれる）。
06埋め込みとベクトル検索が RAG につながる
ここまでの部品（埋め込み・類似度・ベクトル DB）が分かると、RAG の流れがそのまま読めます。RAG は大きく「準備（取り込み）」と「実行（質問応答）」の二段で動きます。
文書をチャンクに分ける
長い文書は 100〜500 トークン程度の断片（チャンク）に分割する。長文を丸ごと埋め込むと意味がぼやけるため、分割は必須。
各チャンクをベクトル化して保存
チャンクを埋め込みモデルに通してベクトルにし、ベクトル DB に格納する。ここまでが事前準備。
質問もベクトル化する
ユーザーの質問を、文書と同じ埋め込みモデルでベクトルに変換する。
近いチャンクを上位 K 件取得
質問ベクトルに近い順に、関連しそうなチャンクを数件（例：上位 5 件）取り出す。
取得文書＋質問を LLM に渡す
取り出したチャンクを「根拠」として質問と一緒に LLM に渡し、根拠に基づいた回答を生成させる。
つまり RAG とは、埋め込みで意味を数値化し、ベクトル検索で根拠を引き当て、それを LLM に読ませて答えさせる仕組みです。本記事の前提知識がそのまま RAG の骨格になっています。
07一歩進んだ二つの工夫
基本のベクトル検索だけでは精度が頭打ちになる場面があります。実務でよく使われる二つの補強策を知っておくと役立ちます。
ハイブリッド検索
キーワード検索（BM25 という古典的な手法）とベクトル検索を組み合わせます。型番・人名・条文番号のような一致が重要な情報はキーワード側が、言い換えや概念マッチはベクトル側が拾うため、両者の弱点を補い合えます。Weaviate、Elasticsearch、OpenSearch などがネイティブ対応しています。
クロスリンガル（多言語横断）検索
多言語対応の埋め込みモデルを使うと、英語の質問で日本語の文書を引き当てるといった言語をまたいだ検索ができます。複数言語のマニュアルを一括で検索したい、翻訳前の原文も含めて探したい、といった業務で力を発揮します。
08埋め込みを使うときの注意点
- 長文はそのまま埋め込まない：長い文章を一つのベクトルに押し込むと意味が薄まり、検索精度が落ちる。チャンク分割が前提。
- モデルを乗り換えると再埋め込みが必要：別の埋め込みモデルが作るベクトルは互換性がない。質問側と文書側は必ず同じモデルで揃える。
- 専門用語に弱い場合がある：社内独自の用語・略語は汎用モデルだと意味を取りこぼすことがある。ハイブリッド検索や用語辞書で補う。
- 多言語モデルにも得意・不得意がある：対応言語をうたっていても、言語ごとに精度の偏りがある。自分が使う言語で実測して確認する。
09まとめ
埋め込みは、LLM が「意味を数値として扱う」ための核となる技術です。文章を意味空間の座標に置き換え、その近さで関連文書を探す——この発想は RAG だけでなく、おすすめ提示（推薦）、文書の自動グループ分け（クラスタリング）、異常検知など幅広く応用されています。まず手を動かして試すなら、すでにある PostgreSQL に pgvector を追加し、OpenAI の text-embedding-3-small などで小さなコレクションを作ってみるのが、いちばんハードルの低い入り口です。ここまで理解できていれば、RAG の解説記事はもう難しくないはずです。
