ベクトルデータベースとは？RAGで必要になる理由と選び方

ベクトルデータベースは、文章や画像を数値の並びに変換したvector embedding（ベクトル埋め込み）を保存し、意味が近いデータを探すためのデータベースです。RAGでは質問に関係する根拠文書をLLMへ渡す前段を担当します。ただし、RAGなら必ず専用製品が必要なわけではありません。

小規模な検証ならexact search（完全検索）、既存PostgreSQLを活用するならpgvector、ベクトル検索固有の負荷が大きいなら専用DB、運用を減らしたいならmanaged service（マネージドサービス）が候補です。製品名だけで決めず、件数、絞り込み、更新頻度、検索品質、運用責任で選びます。

この記事ではEmbeddingの作り方や回答生成を繰り返さず、ベクトルの保存、索引、metadata filter（付帯情報による絞り込み）、更新・削除、権限、バックアップに範囲を絞ります。

情報確認日：2026年7月20日（日本時間）

結論：最初に運用条件を決め、同じデータで検索品質を測る

ベクトルDBを選ぶ前に、Embeddingとは何かとRAGの仕組みを理解しておくと、検索部分と回答生成部分を混同しにくくなります。

ベクトルデータベースとは

通常のデータベースは、ID、日付、金額、完全一致する文字列などを条件に行を探すのが得意です。ベクトルデータベースは、数百から数千個程度の数値で表した特徴を使い、query vector（質問ベクトル）に近いvectorを上位から返します。

原文
  ↓ embedding modelで数値化
vector + 原文ID + metadataを保存

質問
  ↓ 同じembedding modelで数値化
query vector
  ↓ similarity search
近い文書のIDとscore
  ↓ 原文を取得
LLMへ根拠として渡す

データベースが返すのは「答え」ではなく、質問に近い候補です。最終回答の生成、引用表示、根拠の検証はアプリケーションとLLM側の責任です。

通常のDB・vector index・vector DBの違い

Relational DB（リレーショナルデータベース）は表と関係でデータを管理します。Vector index（ベクトル索引）は検索を速くするデータ構造です。Vector database（ベクトルデータベース）は索引だけでなく、追加・更新・削除、永続化、metadata、APIなどを含む管理基盤です。

pgvectorのように既存のrelational DBへvector型と検索索引を追加する方式もあります。「通常DBかvector DBか」の二択ではなく、通常DBの強みとvector検索を同居させる選択肢です。

RAGでベクトルDBが必要になる理由

意味が近い文章を表記ゆれごと探せる

キーワード検索は製品名や型番の完全一致に強い一方、「有給の残日数」と「年次休暇の未消化分」のような言い換えを拾いにくいことがあります。Embeddingは意味の特徴を数値化するため、表記が違っても近い候補を探せます。

文書が増えても上位候補を短時間で絞れる

すべてのvectorとの距離を毎回計算するexact searchは基準として重要ですが、件数やquery数が増えると計算量が大きくなります。ANN indexを使うと、一部の候補を探索して高速化できます。

組織・権限・日付で検索範囲を制限できる

類似度だけでは「この利用者が読んでよい文書か」を判断できません。tenant_id、department、language、published_at、access_level などのmetadataを保存し、vector検索と同時に絞ります。

1件のデータに保存するもの

Dimension（次元数）はvectorに含まれる数値の個数、content hash（コンテンツハッシュ）は原文が変わったかを検出する要約値です。異なるEmbedding modelや次元数を同じ索引へ無計画に混ぜてはいけません。

原文をvectorだけにして捨てることも避けます。vectorから原文を復元するのではなく、検索結果のIDで正本の文書へ戻れるようにします。

類似度の測り方

DB側で好きな指標を選べても、Embedding modelが推奨する指標と揃えるのが基本です。また、製品によって返り値がsimilarity（類似度）かdistance（距離）か異なります。「scoreが高いほど良い」と固定せず、公式仕様を確認します。

exact searchとANN・HNSWの違い

ANN（Approximate Nearest Neighbor）は「近似最近傍検索」、HNSW（Hierarchical Navigable Small World）は「階層化された近傍graphをたどる索引」です。Recall（再現率）は、本来見つけたい正解候補をどれだけ回収できたかを表します。

pgvectorは既定でexact nearest neighbor searchを行い、HNSWまたはIVFFlat索引を追加するとANNへ移れます。HNSWは検索時の候補範囲を広げるほどrecallが上がりやすい一方、検索時間も増えます。最初から値を勘で調整せず、exact結果を正解にして比較します。

pgvectorの最小構成で仕組みを見る

次は1536次元を例にした概念コードです。実際のdimensionは利用するEmbedding modelに合わせます。

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_chunks (
  id uuid PRIMARY KEY,
  tenant_id uuid NOT NULL,
  document_id uuid NOT NULL,
  content text NOT NULL,
  embedding vector(1536) NOT NULL,
  embedding_model text NOT NULL,
  content_hash text NOT NULL,
  updated_at timestamptz NOT NULL
);

まず索引なしでexact searchを行い、期待する文書が上位に来るか確認します。<=> はpgvectorのcosine distance演算子です。

SELECT
  id,
  document_id,
  content,
  embedding <=> $1 AS distance
FROM document_chunks
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

規模と測定結果から必要になった時点で、vector索引とfilter列の索引を検討します。

CREATE INDEX document_chunks_embedding_hnsw
ON document_chunks
USING hnsw (embedding vector_cosine_ops);

CREATE INDEX document_chunks_tenant_id
ON document_chunks (tenant_id);

pgvectorの公式READMEでは、ANN indexを使うfilter付き検索では、候補を走査した後にfilterが適用されて件数が不足する場合があると説明されています。iterative scan、partial index、partitioningなどの選択肢がありますが、tenant数と偏りを再現したデータで確認します。

metadata filterが検索品質と安全性を左右する

RAGの検索条件は「意味が近い」だけでは不十分です。次のように、アクセス可能な範囲を先に決めます。

must:
  tenant_id = 利用者のtenant
  access_level in 利用者の権限
  deleted_at is null

optional:
  language = ja
  published_at <= 現在時刻
  product_id = 選択中の商品

Qdrantではvectorに付けるJSON情報をpayloadと呼び、filterに使うfieldへpayload indexを作れます。公式ドキュメントは、filterable HNSWを有効に生かすため、データ投入前にpayload indexを作ることを推奨しています。

PostgreSQLを使う場合はB-treeなど通常索引と組み合わせ、必要に応じてRow-Level Securityも検討できます。ただしtable ownerや BYPASSRLS roleの扱いを理解し、アプリの認可テストも別に行います。

pgvector・専用DB・managedを比較する

Managed（マネージド）は基盤の管理をservice providerへ任せる形、cluster（クラスタ）は複数nodeで処理やデータを分担する構成、vendor lock-in（ベンダーロックイン）は特定serviceから移りにくくなる状態です。

この表は製品順位ではありません。自社が負担する運用と、外部serviceへ移す運用を整理するための表です。managedでもschema設計、検索品質、access control、原文同期は利用者側に残ります。

12項目の要件表で選ぶ

QPSは1秒あたりのquery数、p95 latencyは95%のrequestが収まる応答時間、RTOは復旧までの目標時間、RPOはどこまでのデータ損失を許容するかです。recall@kは上位k件で正解を回収できた割合です。

選定ベンチマークの手順

1. 実データに近い文書と権限・tenant分布を用意する
2. 質問ごとに「取得されるべき文書」を人が付ける
3. 同じEmbedding model、同じchunk、同じtop-kを使う
4. exact searchの結果と応答時間を基準として保存する
5. 各候補でANNとfilter付き検索を実行する
6. recall@k、p50・p95 latency、index build時間を測る
7. 追加・更新・削除後の反映時間を測る
8. 1か月のstorage、read、write、backup、network費を見積もる
9. backupから別環境へ復元し、検索結果まで確認する

100件の架空データで速かった製品が、tenant filterの偏りを持つ本番データでも速いとは限りません。平均値だけでなく、peak時のp95・p99と、filter適用後のrecallを残します。

比較結果の記録テンプレート

候補:
dataset:
vector count:
dimension:
filter:
top-k:

exact recall@10: 1.00
ANN recall@10:
p50 latency:
p95 latency:
index build:
freshness:
monthly cost estimate:
backup restore result:
security/region notes:
採用・保留理由:

ベクトルDBでできること・できないこと

ベクトルDBを導入しても、誤回答、古い文書、権限漏れが自動で解決するわけではありません。検索結果に文書ID、更新日、scoreを残し、最終回答から引用元へ戻れるようにします。

検索品質が悪いときの切り分け順

1. 原文そのものに正解が含まれるか
2. 更新・削除漏れで古いchunkが残っていないか
3. 質問と文書で同じEmbedding model・前処理を使っているか
4. dimensionとdistance metricが一致しているか
5. metadata filterが正解文書を除外していないか
6. exact searchでは正解が上位に来るか
7. ANNの候補幅を広げるとrecallが戻るか
8. keyword検索やrerankを加える価値があるか
9. 最後にLLMの指示と回答生成を確認する

exact searchでも正解が出ないなら、索引の速度調整より、Embedding、chunk、query、原文を見直すべきです。exactでは出るのにANNで消える場合は、HNSWなどの検索parameterとfilter戦略を調整します。

小規模ならベクトルDBなしでもよい

次の条件なら、専用DBを増やさずに始められます。

• 検証用でvector件数が少ない
• 同時queryが少なく、応答時間の制約が緩い
• ファイル更新が少なく、再indexの運用が単純
• managed File Searchなど、検索基盤込みのAPIを使う
• 既存PostgreSQLのexact searchで要件を満たす

逆に、手元の配列や単体indexを使い続けると、更新・削除、backup、権限、複数instance間の同期が課題になります。検索速度ではなく、データ管理が複雑になった時点も移行の判断材料です。

安全に移行できるデータ設計

• 原文をobject storageや通常DBに正本として残す
• vector DBには安定したdocument IDとchunk IDを入れる
• Embedding model・dimension・versionを記録する
• content hashで差分更新と重複を検出する
• 全件exportと再indexの手順を自動化する
• 削除要求が原文、vector、cache、backupへ反映される期限を決める
• 新旧indexへ二重書きし、同じqueryで結果を比較して切り替える

DB料金だけでなく、Embeddingの再生成、再index、network転送、backup、監視、人の運用時間も総費用へ含めます。API全体の予算設計はAI APIのコスト管理も参考になります。

RAGとコンテキスト設計を体系的に学びたい人へ

この記事はvector DBの選定に範囲を絞りました。Embedding、検索、RAG、AIエージェントへ渡すcontextを一冊の流れで学び直したい場合の補助教材です。APIや製品仕様は刊行後も変わるため、実装時は本記事の参照元と各製品の公式ドキュメントをあわせて確認してください。

価格・在庫・送料条件は変わるため、リンク先で最新情報をご確認ください。

よくある質問

ベクトルDBはRAGに必須ですか？

専用vector DBは必須ではありません。小規模ならexact search、既存PostgreSQL + pgvector、検索基盤込みのmanaged APIでも構築できます。必要なのは、正しい範囲から関連文書を安定して取得・更新・削除できる仕組みです。

pgvectorは何件まで使えますか？

件数だけでは決められません。dimension、query量、filterの選択率、更新頻度、使えるmemory、latency目標で変わります。将来件数を再現したbenchmarkでp95 latencyとrecallを測って判断します。

HNSWを使えば常に速くなりますか？

いいえ。小規模ではindexの管理コストが上回ることがあり、厳しいfilterでは候補不足も起こります。exact searchを基準に、index build、memory、更新性能、filter後のrecallを含めて比較します。

ベクトルDBに機密文書を保存しても安全ですか？

製品名だけでは判断できません。保存region、暗号化、network境界、認証・認可、operator access、log、backup、削除、委託契約を確認します。vectorだけでなくmetadataや原文にも機密情報が含まれ得ます。

まとめ

ベクトルデータベースは、Embeddingと原文参照・metadataを管理し、類似検索でRAGの根拠候補を取り出す基盤です。exact searchで品質基準を作り、規模や応答時間に応じてHNSWなどのANNを検討します。

選定ではpgvector、専用DB、managedを機能数だけで比べず、vector件数、filter、更新、recall、latency、tenant分離、backup、region、総費用、運用体制を同じ要件表へ入れてください。最終的な正解は、実データと正解質問を使った測定で決まります。