ベクトルデータベースとは何か？――RAG検索の仕組みからQdrant・pgvector・FAISSの選び方まで

はじめに：ベクトルデータベースが分からないとRAG構築ができない理由

「RAGを構築したい――そう調べたページの先で、必ず『ベクトルデータベース』という言葉に出くわす」。AIアプリ開発を始めたばかりのエンジニアや、技術選定を任されたアーキテクトなら、一度はこう感じたことがあるのではないでしょうか。

ベクトルデータベース（ベクトルDB）は、RAG（Retrieval-Augmented Generation、検索拡張生成）において、社内文書やWebページといった外部知識を「意味の近さ」で検索できる形に変換して貯めておく、いわばAIの記憶装置です。AWSの解説でも、RAGは外部データを埋め込みモデルで数値表現に変換してベクトルデータベースに保存し、質問時にはその類似度で関連情報を引き出す仕組みとして説明されています。ベクトル検索を前提とするRAG構築では、この部分の理解が全体像を把握する鍵になります。

ところが、いざ学ぼうとすると2つの壁が立ちはだかります。1つ目は、埋め込みや類似度検索といった基礎概念の解説が断片的で、全体像が掴みにくいこと。2つ目は、Qdrant・pgvector・FAISS・Chromaと主要な実装だけでも4つあり、それぞれ特徴が異なるため「どれを選べばいいのか分からない」という選定の壁です。

本記事では、まず埋め込みと類似度検索という基礎から始め、RAGでなぜベクトルDBが必要になるのかを整理します。そのうえで、高速検索を支えるANN（近似最近傍探索）の仕組みを解説し、主要4実装を特徴・ライセンス・適する用途で徹底比較します。最後に、読者自身のユースケースにそのまま使える選定チェックリストを用意しました。

読み終える頃には、「ベクトルDBとは何か」を説明できるだけでなく、自分のプロジェクトに合った1つを自信を持って選べるようになっています。それでは、見ていきましょう。

ベクトルデータベースの基本概念：埋め込みと類似度検索の仕組み

ベクトルデータベースの土台にあるのが「埋め込み（embedding）」と「類似度検索」です。

埋め込み：オブジェクトを数値ベクトルに変換する

埋め込みとは、テキスト・画像・音声などのオブジェクトを、ニューラルネットワークで固定サイズの数値ベクトルに変換する仕組みです（Qdrant公式Docs）。モデルは類似・非類似オブジェクトのペアやトリプレットで訓練され、特定の類似性を認識するよう学習済みです。ベクトル空間で2つのベクトルが近ければ元のオブジェクトも類似と判断でき、画像なら「似た画像」、文書なら「意味の近い文書」を距離計算だけで見つけられます。

ベクトルは主に2種類です。大多数のモデルが出力するdenseベクトルは固定長の浮動小数点数リストで、そのままベクトルDBで使えます。一方のsparseベクトルは要素の多くがゼロの特殊なベクトルで、非ゼロ要素のインデックスと値だけで効率的に保存します。denseは意味的な近さ、sparseは単語の一致など明示的な手がかりに向きます。

距離関数：類似度を測るものさし

ベクトル同士の近さは距離関数で測ります。代表は次の3つです。

• L2距離（ユークリッド距離）: 2点間の直線距離。小さいほど類似
• 内積: 大きいほど方向が一致
• コサイン距離: ベクトルのなす角に着目し、長さの影響を受けない

pgvectorは6種類の演算子を備え、<->がL2距離、<#>が内積（負の内積）、<=>がコサイン距離、<+>がL1距離、<~>と<%>がバイナリベクトル用のハミング・ジャッカード距離です。コサインは距離で定義されるため、SELECT 1 - (embedding <=> '[3,1,2]')のように「1 − 距離」で類似度に戻せます。

FAISSはL2距離と内積をネイティブにサポートしますが、コサイン類似度は明示実装がありません。これは正規化したベクトルの内積がコサイン類似度と等しくなるためで、実運用ではベクトルを事前に正規化して内積インデックスに投入するのが定石です。

検索では、クエリを同じモデルでベクトル化し、保存済みベクトルとの距離が近い順に上位k件を返します。

graph TD
    A[テキスト・画像・音声等のオブジェクト] -->|埋め込みモデル<br/>ニューラルネットワーク| B[固定サイズの数値ベクトル<br/>例: -0.013, 0.020, -0.007 ...]
    B --> C[(ベクトルデータベース)]
    D[類似オブジェクトのペアや<br/>トリプレットでの訓練] --> A
    C -->|距離関数<br/>L2・内積・コサイン等| E[類似度の高い順に検索]
    E --> F[似ているオブジェクトを上位k件取得]

埋め込みで数値化し、距離関数で比べる——これがベクトルデータベースの基本原理です。ただし件数が増えると全件比較は実用にならず、これを解決するANN（近似最近傍探索）の仕組みは次章以降で解説します。

なぜRAGにベクトルデータベースが必要なのか

RAG（Retrieval-Augmented Generation）は、LLMのプロンプトに外部の知識を検索して文脈として与え、根拠に基づいた回答を生成させる手法です。AWSの解説では、RAGのプロセスを4つのステップとして整理しています。まず「外部データ作成」では、文書をチャンク（断片）に分割し、埋め込みモデルでベクトル化してデータベースに保存します。次に「関連情報検索」では、ユーザーの質問も同じモデルでベクトル化し、保存済みのベクトルと意味的な近さで比較して、関連の高い情報を取得します。続く「プロンプト拡張」では、取得した文書を質問に添えてプロンプトを組み立てます。最後の「データ更新」では、最新の文書を追加・差し替えることで、モデルの再学習なしに知識を更新できます。

このワークフロー全体を図にすると、次のようになります。

graph TD
    A[ドキュメント] --> B[チャンク分割]
    B --> C[埋め込み化]
    C --> D[(ベクトルDB)]
    E[ユーザーの質問] --> F[質問の埋め込み化]
    F --> G[類似検索で上位k件を取得]
    D --> G
    G --> H[プロンプトに文脈として付与]
    H --> I[LLMが回答生成]
    I --> J[回答と引用を出力]

この流れの中心にあるのがベクトルデータベースです。テキストを数値ベクトル（埋め込み）として扱うため、キーワードの完全一致では見つけられない「意味が近い文書」を検索できます。そのためにベクトルDBは、①埋め込みを原文やメタデータと一緒に効率よく保存すること、②数百万件規模のデータからも類似ベクトルを高速に取り出す近似最近傍（ANN）探索を提供すること、という2つの役割を担います。

似た目的の技術としてfine-tuningがありますが、両者は役割が異なります。fine-tuningはモデル自体を追加学習させるため、文体やフォーマットの習得には得意ですが、知識の更新には再学習が必要で、出処を示すのも困難です。一方RAGは、文書の追加・削除だけで知識を更新でき、回答の根拠（引用）を示せます。学習コストが低いとされる点も利点ですが、定量的な比較は測定条件に左右されるため、ここでは断定を避けます。実際には、スタイル調整をfine-tuning、事実知識の参照をRAGが担うという併用が一般的です。知識を頻繁に更新するRAGの要件に対して、埋め込みの保存と類似検索の土台となるのがベクトルDBなのです。

ANN（近似最近傍探索）の仕組み：HNSW・IVF・PQを理解すれば選び方が変わる

ベクトル検索を本番で使う前に、必ず壁になるのが検索速度です。全件を素朴に比較する完全検索（フラット検索）はリコール100%と高い精度を持つ一方、計算量がデータ件数Nに比例して増えるため、数百万件を超えるとリアルタイム応答が困難になります。そこで登場するのがANN（Approximate Nearest Neighbor、近似最近傍探索）です。「わずかに取りこぼしてもいいから、桁違いに速く」という発想で、精度と速度のトレードオフを引き受けます。主要な方式は「グラフベース」「クラスタリングベース」「量子化ベース」の3系統に整理できます。

graph TD
    A[ANN（近似最近傍探索）] --> B[グラフベース<br>HNSW]
    A --> C[クラスタリングベース<br>IVF・IVFFlat]
    A --> D[量子化ベース<br>PQ・SQ]
    B --> B1[多層グラフを辿って探索<br>高精度・高速<br>メモリ消費は大きめ]
    C --> C1[k-meansで空間を分割し<br>近いクラスタだけ探索<br>メモリ効率が良い]
    D --> D1[ベクトルを圧縮表現に置換<br>メモリを大幅に削減]

まずHNSW（Hierarchical Navigable Small World）です。グラフを複数層に重ね、上層でざっくり遠くまで移動し、下層で精密に絞り込む「高速道路と一般道」のような探索を行います。探索は経験的にデータ件数に対して対数オーダーに近いスケールで済むとされます（理論保証ではなく、実装やデータ分布に依存する傾向です）。事前の訓練プロセスは不要です。pgvectorの公式ドキュメントでは、作成時の目安としてm=16、ef_construction=64、検索時はef_search=40が示されており、精度と速度のバランスはこの3つのパラメータで調整します。

次にIVFです。事前にクラスタリング（多くの実装ではk-means系）でベクトル空間をnlist個のクラスタに分割しておき、検索時にはクエリに近いクラスタだけをnprobe個探索します。pgvector（IVFFlat）の目安は、100万件まではlists=行数÷1000、それ以上は√行数、probesはlists÷10から様子を見るというものです。構築が速くメモリに優しい一方、クラスタ境界付近で精度が落ちやすいため、pgvector公式はHNSWを推奨しています。使い分けは「精度最優先・更新が多いならHNSW、メモリや構築時間を抑えたいならIVF」が基本です。

最後に量子化です。PQ（Product Quantization）はベクトルをm個の部分ベクトルに分割し、それぞれを代表点の番号に置き換えます。768次元のfloat32ベクトル（約3KB）が数十バイトになるなど、SQ（スカラー量子化、int8化で約1/4）からPQまで4〜64倍の圧縮でメモリを大幅に削減できます。「IVFで探索範囲を絞り、PQでメモリを圧縮」の組み合わせは、大規模データでの定番構成です。

実務の目安としては、小規模なデータなら完全検索（Flat）でも実用になる速度が出やすく、件数が増えるにつれてHNSWやIVFといったANNインデックス、さらに大規模では量子化によるメモリ削減やGPU活用が選択肢に入ります。どの方式・パラメータが適するかは次元数・ハードウェア・求める再現率とレイテンシの条件で変わるため、固定の件数基準ではなく実際のデータでの測定が重要です。そのうえで、ef_searchやnprobeといったパラメータ1つで精度と速度のバランスを実行時に調整できるのがANNの実用性です。

主要4実装の徹底比較：Qdrant・pgvector・FAISS・Chromaの特徴と違い

RAGでよく使われる4つの主要実装を、分類から検索機能まで一挙に比較します。

Qdrant：フィルタリングとハイブリッド検索に強い専用DB

Rust製の専用ベクトルDBサーバーです。Filterable HNSWにより、ペイロード（メタデータ）での絞り込みとベクトル検索を同時に高速実行できるのが最大の強みです。マルチテナンシーは「テナントごとのコレクション分割」「ペイロードフィルタ」「単一コレクション＋グループ化」の3方式から選べます。DenseベクトルとSparseベクトルの同時検索をネイティブサポートし、RRFやDBSFでスコアを融合するハイブリッド検索も標準機能です。量子化もスカラー・Product Quantization・バイナリの3種を備え、メモリ削減の選択肢が豊富です。フィルタリングとハイブリッド検索を重視する本番RAGでの採用が多い選択肢です。

pgvector：既存PostgreSQLに追加する選択肢

PostgreSQLの拡張として動作し、CREATE EXTENSION vectorだけで導入できます。ベクトル列を他のデータと同じテーブルに保存できるため、JOIN・集計・トランザクション（ACID）と組み合わせられるのが最大の利点で、バックアップや権限管理などの運用資産もそのまま活かせます。ANNインデックスはHNSWとIVFFlatの両方に対応し、データ特性に応じて使い分けられます。近年のバージョンでは半精度のhalfvecや疎ベクトルのsparsevecの追加も進んでいます（要出典）。「Postgresを使っているなら、まずこれ」の立ち位置です。

FAISS：数十億規模とGPUを征するライブラリ

Meta AI Researchが開発するC++製のベクトル検索ライブラリです。Flat・IVF・PQ・HNSW・LSHなどインデックス型が非常に豊富で、公式資料では数十億規模のベクトルを扱う圧縮構成も紹介されています（参考23）。CUDA対応のGPU実装が用意されており、GPUでのインデックス構築・検索にも対応しています。一方でライブラリ（インプロセス）であるため、サーバー化・永続化・メタデータ管理・フィルタリングは自前で用意する必要があり、別のDBとの併用が前提になります。研究・実験や、特殊なインデックス構成を追求したい上級者向けの選択肢です。

Chroma：4つの基本操作で動く手軽さが武器

Pythonから4つの基本操作（add・query・get・delete）だけでベクトルを扱える手軽さが特徴の組み込みベクトルDBです。デフォルトの埋め込み関数によるテキストの自動ベクトル化や、ドキュメントとメタデータの一括管理が標準で備わり、数行のコードでRAGの原型が完成します。組み込み以外にサーバーモード・Chroma Cloudも用意されており、プロトタイプから小規模サービスへの段階的な拡張に向いています。なおAPIの詳細はバージョンによって変わるため、利用時は公式ドキュメントの該当バージョンを確認してください。

ユースケース別の選び方：選定チェックリストとケーススタディ

選定で失敗しないコツは「どれが最強か」ではなく、環境・規模・運用負荷から逆算することです。まず次の8項目を順に自問してみてください。

• 既存Postgresを使っているか → まずpgvector。SQL・バックアップ・権限管理をそのまま流用できます
• インフラを増やしたくないか → サーバー追加が不要なpgvectorか、組み込み型のChroma
• 数十億件規模・GPUを活用したいか → CUDA対応が充実したFAISS
• メタデータフィルタを多用するか → Filterable HNSWのQdrant、WHERE句で絞れるpgvector
• マルチテナントSaaSか → テナントIDのペイロードフィルタに強いQdrant、行レベルセキュリティ（RLS）と組めるpgvector
• ハイブリッド検索が必要か → Dense+Sparseを1クエリで融合（RRF）できるQdrantが第一候補
• PoC・学習が目的か → pipだけで動くChromaが最速
• ライセンス要件はあるか → Qdrant・ChromaはApache-2.0、FAISSはMIT、pgvectorはPostgreSQL Licenseです。商用利用では各ライセンス本文と依存ライブラリを個別に確認してください

要件が整理できたら、次のフローチャートで大枠を決めましょう。

graph TD
    S[選定開始] --> A{既存Postgresを<br>使っているか}
    A -- はい --> PG[pgvector]
    A -- いいえ --> B{数十億件規模か<br>GPUで実験するか}
    B -- はい --> FA[FAISS]
    B -- いいえ --> C{本番でフィルタ・<br>スケールが必要か}
    C -- はい --> QD[Qdrant]
    C -- いいえ --> D{まず手早く試したいか}
    D -- はい --> CH[Chroma]
    D -- いいえ --> QD

次に、実際の選択をイメージできる4つのケーススタディです。

• 既存PostgresアプリのECサイトがレビュー検索をRAG化したい → pgvector。拡張を1行で有効化でき、商品情報と同じDB・トランザクションで完結します
• ドキュメント絞り込みが多いB2B SaaS → Qdrant。テナントIDなどのフィルタとHNSW検索を同時に高速実行できます
• 数千万件の埋め込みをGPUで実験する研究チーム → FAISS。インデックス構築・検索をGPUで高速化し、メタデータは別DBで管理します
• 週末に個人でPoCを作りたいエンジニア → Chroma。数行のPythonでRAGの雛形が完成します

最後に、各実装の最小構成の導入手順を示します（いずれも公式ドキュメント準拠）。

Qdrant — Dockerでサーバーを起動し、Pythonクライアントから利用します。

docker run -p 6333:6333 qdrant/qdrant
pip install qdrant-client

from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
client.create_collection("docs",
    vectors_config=models.VectorParams(size=1536, distance=models.Distance.COSINE))
hits = client.query_points("docs", query=qvec, limit=3).points

pgvector — 既存のPostgresで拡張を有効化するだけで使えます。

CREATE EXTENSION vector;
CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(1536));
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);
SELECT id FROM items ORDER BY embedding <=> '[0.1,0.2,0.3]' LIMIT 3;

FAISS — pipでインストールし、ベクトルはfloat32のNumPy配列で渡します。

import faiss, numpy as np
xb = np.random.random((10000, 64)).astype("float32")  # float32が必須
index = faiss.IndexFlatL2(64)
index.add(xb)
print(index.search(xb[:1], 3))  # 上位3件の距離とID

Chroma — クライアント作成・コレクション作成・add・queryの4関数だけで動きます（APIはバージョンにより変わる場合があります）。

import chromadb
col = chromadb.Client().create_collection("docs")
col.add(ids=["1"], documents=["本文"], embeddings=[[0.1, 0.2]])
print(col.query(query_embeddings=[[0.1, 0.2]], n_results=1))

それでも迷うときは、pgvectorかChromaで小さく始め、規模やフィルタ要件が伸びたらQdrantへ移行するのが現実的な進め方です。

よくある質問（FAQ）

最後に、ベクトルDBとRAGについて読者からよく寄せられる疑問に答えます。技術選定の際に迷いやすいポイントを中心に、5つの質問を取り上げます。

Q: ベクトルデータベースは、通常のRDBMSと何が違うのですか？

RDBMSはWHERE句や完全一致・キーワードの条件で行を検索するのに対し、ベクトルDBはデータを高次元の埋め込みベクトルとして保存し、ベクトル同士の距離やコサイン類似度で「意味が近い」データを検索します。そのため、「車の調子が悪い」という質問に対して、キーワードが一切一致しない「エンジンの異音」という文書をヒットさせられるのが大きな違いです。また、RDBMSがB-treeなどで正確な検索を提供するのに対し、ベクトルDBはHNSWやIVFといったANN（近似最近傍探索）インデックスで速度と精度のトレードオフを調整する点も特徴的です。

Q: RAGの構築には、ベクトルDBは必須ですか？

小規模なデータであれば必須ではありません。数百〜数万件程度ならNumPyの配列やSQLiteで全件探索（Flat検索）しても十分実用的な速度が得られます。ただし件数が増えると計算量がデータ数に比例して増える全件探索では追いつかなくなり、メタデータフィルタリングや更新・運用の観点でも、ある程度の規模からは専用のベクトルDBが有効になります。

Q: Qdrant・pgvector・FAISS・Chromaのどれを選べばよいですか？

基本は「既存インフラ・データ規模・目的」から逆算して選びます。PostgreSQLをすでに運用しているならpgvectorが最短ルートで、大規模な本番RAGやフィルタリングを多用するならQdrant、プロトタイプを素早く立ち上げたいならChroma、研究やGPUを活用した大量データ処理にはFAISSが向いています。迷ったらまず手元の規模でpgvectorかChromaを試し、ボトルネックが出てから専用DBへの移行を検討するのが現実的な進め方です。

Q: HNSWとIVFFlat（IVF）は、どう使い分けるのですか？

HNSWは多層グラフをたどって探索する方式で、高い検索精度と高速性を両立できる一方、インデックスをメモリに載せる必要があるためメモリ消費が大きくなります。IVFFlatはk-means等のクラスタリングでベクトルをセルに振り分け、クエリに近いクラスタだけを探索する方式で、構造がシンプルでメモリ効率に優れるものの、探索するクラスタ数（nprobe）の設定次第で精度が変わりやすい点に注意が必要です。pgvectorではどちらのインデックスも選択できるので、迷ったらまずHNSWから始め、メモリが厳しい場合にIVFFlatやPQとの組み合わせを検討するのが目安です。

Q: FAISSはライブラリですが、それでも選ぶ理由はありますか？

あります。FAISSはDBサーバーではなくインプロセスのライブラリで、永続化やメタデータ管理の機能は薄いものの、CUDAによるGPUでの高速なインデックス構築・検索や、Flat・IVF・PQ・HNSWなど豊富なインデックスタイプが大きな強みです。研究や実験での採用実績も豊富で、数千万件以上の大規模データをGPUで捌きたいケースでは依然として有力な選択肢です。運用形態まで整えた本番サービスならQdrantなどのDBサーバー型、というように用途で使い分けるのが良いでしょう。

まとめ：次のアクション3つ

本記事では、埋め込みと類似度検索というベクトルデータベースの基礎から出発し、RAG（検索拡張生成）がなぜ外部知識の検索にベクトルDBを必要とするのかを、ファインチューニングとの役割の違いと併せて整理しました。続いて、HNSWやIVFといったANN（近似最近傍探索）の仕組みを押さえ、Qdrant・pgvector・FAISS・Chromaの主要4実装を、フィルタリングやマルチテナンシー、運用負荷の観点から比較し、ユースケース別の選び方を示しました。

重要なのは「どれが最強か」ではなく「自分の要件に何が合うか」を見極めることです。今日から動き出せるアクションを3つに絞りました。

1. まず最小構成でRAGを体験する — Chromaなら pip install chromadb、PostgreSQL運用なら CREATE EXTENSION vector; だけで開始できます。自分のドキュメントを埋め込んで類似検索を試し、感覚をつかみましょう。
2. 要件をチェックリストで言語化する — 既存DB・スケール・フィルタリング・マルチテナンシー・ハイブリッド検索・開発速度の6観点で要件を書き出し、候補を2つに絞り込みます。
3. 実際のデータ規模で評価する — 本番想定の件数・次元数で再現率とレイテンシを測定します。ANNベンチマークは「同じ精度閾値での比較」が重要です。公開結果も参考にしつつ、必ず自分のデータで検証してください。

手を動かし、要件を言葉にし、自分のデータで測る。この3ステップで選定は「調査」から「設計」へ変わります。まずは小さく始めて、RAGの検索品質を自分の目で確かめてみてください。

参考文献

1. Qdrant Documentation: https://qdrant.tech/documentation/
2. Qdrant GitHub: https://github.com/qdrant/qdrant
3. Qdrant LICENSE（Apache 2.0）: https://github.com/qdrant/qdrant/blob/master/LICENSE
4. Qdrant Quickstart: https://qdrant.tech/documentation/quickstart/
5. Qdrant Vectors: https://qdrant.tech/documentation/manage-data/vectors/
6. Qdrant Indexing: https://qdrant.tech/documentation/manage-data/indexing/
7. Qdrant Filtering: https://qdrant.tech/documentation/search/filtering/
8. Qdrant Hybrid Queries: https://qdrant.tech/documentation/search/hybrid-queries/
9. Qdrant Multitenancy: https://qdrant.tech/documentation/manage-data/multitenancy/
10. Qdrant Product Quantization Demystified: https://qdrant.tech/articles/product-quantization/
11. Qdrant Benchmarks: https://qdrant.tech/benchmarks/
12. pgvector GitHub: https://github.com/pgvector/pgvector
13. pgvector README: https://github.com/pgvector/pgvector/blob/master/README.md
14. pgvector LICENSE（PostgreSQL License）: https://github.com/pgvector/pgvector/blob/master/LICENSE
15. FAISS GitHub: https://github.com/facebookresearch/faiss
16. FAISS wiki - Faiss Indexes: https://github.com/facebookresearch/faiss/wiki/Faiss-indexes
17. FAISS wiki - Getting Started: https://github.com/facebookresearch/faiss/wiki/Getting-started
18. FAISS LICENSE（MIT）: https://github.com/facebookresearch/faiss/blob/main/LICENSE
19. Chroma GitHub: https://github.com/chroma-core/chroma
20. Chroma Documentation: https://docs.trychroma.com/docs/overview/introduction.md
21. Chroma GitHub言語統計: https://api.github.com/repos/chroma-core/chroma/languages
22. Malkov & Yashunin. Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (arXiv:1603.09320): https://arxiv.org/abs/1603.09320
23. Johnson, Douze & Jégou. Billion-scale similarity search with GPUs (arXiv:1702.08734): https://arxiv.org/abs/1702.08734
24. AWS - What is Retrieval-Augmented Generation: https://aws.amazon.com/what-is/retrieval-augmented-generation/
25. Qdrant vector-db-benchmark: https://github.com/qdrant/vector-db-benchmark

関連記事

• ベクトルデータベースはどう動くのか――HNSW近似最近傍探索の仕組みからpgvector・Qdrant・Milvusの選び方まで
• RAGは"似ている問題"を探すだけではダメだった──類推推論を強化するRA-RFTの衝撃