RAG（検索拡張生成）の心臓は、埋め込み（embedding）とベクトル検索です。文章を「意味を表す数のならび（ベクトル）」に変換し、質問のベクトルに近いものを高速に探し出す——この2段で「自社データに基づいて答えるAI」が成り立ちます。本稿は開発者向けに、仕組み・実装の勘所・2026年時点の選択肢を、図とともに具体的に整理します。
FIG.1 文章 →（埋め込みモデル）→ ベクトル → 近いベクトルを探す、という2段構え
01埋め込みとは「意味を座標にする」こと
埋め込みモデルは、入力テキストを固定長の数値ベクトル（例: 1536次元）に変換します。学習の結果、意味が近い文ほど近い場所に配置されるのが核心です。たとえば「経費精算のやり方」と「立替金の申請手順」は語が違っても近くに置かれ、「来期の売上目標」は遠くに置かれます。
キーワード検索が「文字の一致」で探すのに対し、ベクトル検索は「意味の近さ」で探す——この違いが、表記ゆれや言い換えに強い理由です。「近さ」の物差しには、ベクトルの向きの一致度を見るコサイン類似度がよく使われます（多くの埋め込みモデルが正規化済みベクトルを返すため、内積でも実質同じになります）。
FIG.2 質問ベクトルの周囲（破線円）にある文書を「近い順」に取り出す
02埋め込みモデルの選び方（2026年時点）
埋め込みモデルは用途・言語・次元数・コスト・運用形態（API か自前ホスト）で選びます。2026年時点でよく使われる代表的な選択肢は次の通りです（性能・価格は更新が早いので、採用前に必ず公式の最新情報を確認してください）。
| API 型（手軽・運用不要） | 自前ホスト型（コスト・機密制御） |
|---|---|
| OpenAI text-embedding-3-small（1536次元）/ -large（3072次元） | BGE、Jina embeddings v3、E5 系などのオープンモデル |
| Cohere embed-v4（多言語・検索特化、rerank と相性良） | GPU/CPU を自社で用意。データを外部に出さずに済む |
| Voyage AI voyage-4 系（2026年1月に MoE 構成を投入し検索精度を強化） | Ollama 等でローカル実行も可能。小〜中規模に有効 |
選定の実務ポイントは3つです。まず日本語を含む多言語性能（日本語が弱いモデルだと和文の意味検索が崩れる）。次に次元数とコストのバランス——次元が大きいほど表現力は上がりますが、保存容量と検索負荷も増えます。OpenAI の text-embedding-3-large は Matryoshka 表現に対応し、3072次元を 256 次元まで縮めても品質劣化を抑えられるため、精度とコストを後から調整できます。最後に検索用と文書用で書き分けられるか（query/passage を区別できるモデルは精度が上がりやすい）。
「とりあえず最新の大きいモデル」ではなく、自社の言語・規模・コストに合わせて選ぶ。
03ベクトルDBと近傍検索の仕組み
埋め込んだベクトルはベクトルDBに格納し、質問ベクトルに近いものを高速に取り出します。数百万〜数億件を総当たりで比較するのは非現実的なので、実運用ではANN（近似最近傍探索）を使います。多少の取りこぼしを許容する代わりに、桁違いの速さを得る仕組みです。
2026年時点で事実上の標準となっているインデックスが HNSW（階層的に近傍グラフをたどる方式）です。粗い層から細かい層へ降りながら近いノードを探すため、件数が増えても検索時間の伸びがゆるやか（おおむね対数的）で、数億件規模でも実用的に動きます。
FIG.3 HNSW＝上の粗い層でおおまかに近づき、下の密な層で最近傍に着地する
製品としては、PostgreSQL 拡張の pgvector（0.9 系で性能・機能が進化。小〜中規模なら既存DBにそのまま載せられて運用が楽）、専用エンジンの Pinecone・Qdrant・Weaviate・Milvus などが代表格です。数百万件までなら pgvector で十分戦えることが多く、規模やマルチテナント要件が増えたら専用DBへ移行する、という流れが定番です。なお HNSW は m（接続数）や ef_search（探索幅）といったパラメータで速度と再現率（recall）のトレードオフを調整します。大規模では既定値のままだと取りこぼすことがあるため、評価セットでの調整が要ります。
04チャンク設計：精度を左右する地味な要所
長い文書はそのまま埋め込まず、チャンク（断片）に分割してから埋め込みます。1つのベクトルに詰め込む情報が多すぎると意味がぼやけ、少なすぎると文脈が切れる——この切り方が検索精度を大きく左右します。出発点の目安は次の通りです。
- 分割単位：機械的な文字数区切りより、見出し・条項・段落など意味のまとまりで切るほうが強い
- オーバーラップ（重なり）：隣接チャンクを少し重ねて、段落をまたぐ参照の取りこぼしを防ぐ
- サイズ：用途次第だが、QAでは数百トークン規模が扱いやすい。長すぎる1チャンクは要注意
FIG.4 意味のまとまりで区切り、境界を少し重ねて文脈を保つ
2026年はセマンティック・チャンキングも実用域に入りました。隣り合う文どうしのコサイン類似度を計算し、意味が大きく切り替わる箇所を境界にする方式です。機械的な文字数区切りよりまとまりが自然になりますが、計算コストは増えます。まずは「見出し＋固定長＋少しの重なり」で動かし、精度が頭打ちになったらセマンティック分割を検討するのが現実的です。
もう一つ重要なのがメタデータの同梱です。各チャンクに出典・更新日・部署・文書種別・アクセス権限を持たせておくと、後段で「2026年版だけ」「自部署が見てよいものだけ」と絞り込めて、検索が一気に賢く・安全になります。
05ベクトル検索だけでは足りない
ベクトル検索は意味の近さに強い一方、型番・条文番号・固有名詞の完全一致のような「文字そのもの」が重要な検索は苦手です。たとえば「型番 ABC-12345 の仕様」は、意味より一致が効きます。そこでキーワード検索（全文検索）を併用するハイブリッド検索が定番になっています。
| ベクトル検索 | キーワード検索 |
|---|---|
| 言い換え・表記ゆれに強い | 型番・条文番号など一致が効く情報に強い |
| 意味の近さで広く拾う | 完全一致で確実に拾う |
Weaviate・Milvus・Qdrant・Pinecone など主要なベクトルDBは、2026年時点でハイブリッド検索をネイティブにサポートしています。広く拾ったあとに再ランキング（reranker）で関連度を厳しく採点し直し、本当に効く数件だけをLLMへ渡すと、回答品質が安定します。
「広く拾って、厳しく絞る」——これが検索品質の基本動作。
06実装の勘所とつまずきの処方箋
取り込みと検索で前処理を揃える
同じ埋め込みモデル・同じ正規化を、文書側と質問側の両方に適用する。片方だけ大文字小文字を整えるなどの食い違いは、地味に精度を落とす。
更新フローを最初から設計する
文書が変わったら該当チャンクだけ再埋め込み・再格納する差分更新を用意する。「全件入れ直し」しかないと運用が破綻する。更新日メタデータで古い版を除外できるようにしておく。
モデルを変えたら全件を入れ直す
埋め込みモデルやバージョンを変えるとベクトル空間が別物になり、新旧を混在させると検索が壊れる。モデル変更＝インデックス再構築、と決めておく。
機密データの保存先と権限を確認する
API型モデルに何を送ってよいか、ベクトルDBに誰がアクセスできるかを取り込み前に確認する。検索時はユーザー権限で対象を絞る（最小権限・要承認）。「埋め込んだら誰でも読める」設計は事故のもと。
コストや速度が問題になったら、ベクトルを int8 や バイナリへ量子化して保存・検索を軽くする手もあります（多少の精度低下と引き換えに容量・速度を大きく改善）。まずは素直な構成で動かし、必要になってから最適化するのが順序です。
Pitfalls
「意味は近いのに答えが外れる」の正体
ベクトル検索が拾うのは「意味的に近い」候補であって、「質問の答え」そのものではありません。近い文書を渡してもLLMが補完で外す場合は、検索ではなくプロンプト側（根拠以外で断定させない・引用を必須にする）も疑います。また、生成AIはもっともらしい誤り（ハルシネーション）を出すため、回答は必ず渡した根拠（一次情報）と突き合わせて検証できる形にしておきます。
FIG.5 「近い候補」を再ランキングで絞り、根拠と突き合わせて検証する
07まとめ
RAGの精度は、生成モデルよりも「検索側の作り込み」で決まります。鍵は3つ——埋め込みの質（モデル選定）、チャンク設計、検索（ハイブリッド＋再ランキング＋権限フィルタ）。まずは pgvector など手近な構成で「質問→近い文書→引用つき回答」を動かし、評価セットで弱点を測りながら、量子化やセマンティック分割といった最適化を順に足していきましょう。次章では、ベクトルとキーワードを束ねるハイブリッド検索をさらに掘り下げます。
