ベクトルデータベースとは何か？RAG作成に不可欠な仕組みを解説（データ構造・歴史から注意点）

生成AI（LLM）のビジネス活用が進む中、自社独自のドキュメントや最新情報をAIに組み込んで正確な回答を出力させる技術RAG（Retrieval-Augmented Generation：検索拡張生成）が注目を集めています。

そのRAGシステムを構築する上で「心臓部」とも言える重要な役割を担うのがベクトルデータベース（Vector Database）です。

「名前は聞いたことがあるけれど、通常のデータベースと何が違うのか？」
「なぜAIにはベクトルデータベースが必要なのか？」
「どのような仕組みやデータ構造で動いているのか？」

本記事では、プログラミング初心者やAI活用を検討している非エンジニア〜初学者の方に向けて、ベクトルデータベースの基本概念から、内部で動く先進的なデータ構造・アルゴリズム、歴史的経緯、構築時の注意点まで、分かりやすく解説します。

RAGとベクトルデータベースの基本概念
1. RAG（検索拡張生成）とは？
ベクトルと埋め込み（Embedding）
1. 意味を「数値の配列」に変換する「埋め込み」
2. 多次元空間における「距離」と「意味の近さ」
従来のデータベース（RDB/NoSQL）とベクトルDBの決定的な違い
1. 完全一致検索の限界と類似度検索の強み
ベクトルデータベースの歴史と進化の系譜
ベクトル検索を支えるコアな「データ構造」と「アルゴリズム」
類似度計算の数学的基礎（コサイン類似度・ユークリッド距離・内積）
代表的なベクトルデータベース・ライブラリ徹底比較
RAG構築時におけるベクトルデータベースの注意点と落とし穴
まとめ：ベクトルデータベースの選び方とこれからの展望
1. 導入ステップのロードマップ
2. 今後のトレンド

RAGとベクトルデータベースの基本概念

RAG（検索拡張生成）とは？

RAG（Retrieval-Augmented Generation）を一言で表すと、「LLM（大規模言語モデル）に自社専門の『検索エンジン』を接続して、嘘（ハルシネーション）のない回答を作らせる仕組み」です。

ChatGPTなどのLLMは強力ですが、主に以下の弱点を持っています。

学習データに含まれていない社内マニュアルや顧客データを扱えない
情報が更新された最新ニュースに対応できない
知らないことを知っているかのように嘘の回答を作り出してしまう（ハルシネーション）

この問題を解決するために、ユーザーからの問合せに対して「関連する社内ドキュメントを検索して抽出し（Retrieval）」、「その文書と一緒にLLMへプロンプトを渡して回答させる（Generation）」というアプローチがRAGです。

【ユーザーの質問】
   │
   ▼
【1. 検索（Retrieval）】 ➔ ベクトルデータベースから関連度の高い文書を探す
   │
   ▼
【2. 拡張（Augmentation）】 ➔ 取得した文書を背景情報としてプロンプトに組み込む
   │
   ▼
【3. 生成（Generation）】 ➔ LLMが正確な根拠に基づいて回答を生成する

この「関連度の高い文書を瞬時に見つけ出してくる」部分を担当するのが、ベクトルデータベースです。

ベクトルと埋め込み（Embedding）

ベクトルデータベースを理解するためには、まずデータがどのように表現されているかを知る必要があります。

意味を「数値の配列」に変換する「埋め込み」

コンピュータは「人間が使う言葉の意味」をそのままでは理解できません。

そこで、テキストや画像、音声といったデータを、数十〜千数千次元の「数値の配列（ベクトル）」に変換します。

この変換プロセスを埋め込み（Embedding）と呼びます。

例えば、AIのエンベディングモデルを通すと、単語や文章は次のような数値配列になります。

「リンゴ」 → [0.12, -0.45, 0.88, 0.23, …]
「バナナ」 → [0.15, -0.41, 0.82, 0.19, …]
「自動車」 → [-0.85, 0.72, -0.11, 0.94, …]

ここで注目すべきは、「リンゴ」と「バナナ」の数値の並びが非常に似ている点です。一方、「自動車」の数値は全く異なります。

多次元空間における「距離」と「意味の近さ」

これを概念的に理解するために、2次元のグラフ（空間）をイメージしてみましょう。

X軸：果物っぽさ（1.0に近いほど果物）
Y軸：乗り物っぽさ（1.0に近いほど乗り物）

Y軸 (乗り物)
 ^
 |
 |       ● 自動車 (0.1, 0.9)
 |
 |
 |
 |              ● リンゴ (0.8, 0.1)
 |              ● バナナ (0.85, 0.12)
 +-------------------------------------> X軸 (果物)

この空間上では、「リンゴ」と「バナナ」は非常に近い位置にプロットされ、「自動車」は遠く離れた位置にプロットされます。

実際のAIモデル（例：OpenAIの text-embedding-3-small）では、このような軸が2次元ではなく1,536次元といった超高次元空間に広がっています。

人間には視覚化できませんが、数学的には「多次元空間上に置かれた点の位置」として表現され、「距離が近い＝意味が似ている」というルールが成り立ちます。

従来のデータベース（RDB/NoSQL）とベクトルDBの決定的な違い

なぜ、MySQLやPostgreSQLといった既存のリレーショナルデータベース（RDB）やドキュメント型DB（MongoDB等）ではRAGをスムーズに作れないのでしょうか？

最大の理由は、検索の仕組み（アルゴリズム）が本質的に異なるからです。

比較項目	従来型データベース（RDB / NoSQL）	ベクトルデータベース
主な検索対象	構造化データ（数値、文字列、日付など）	非構造化データ（テキスト、画像、音声）
検索手法	完全一致検索（Exact Match）、範囲検索	類似度検索（Similarity Search / 近傍検索）
クエリの例	`WHERE price < 1000 AND status = 'active'`	「この質問の意味に最も近い社内規定を探せ」
言葉の表記揺れ	「パソコン」と「PC」は別物とみなされる	「パソコン」と「PC」をほぼ同じ概念として検索可能
インデックス構造	B-Tree, Hash Indexなど	HNSW, IVF, PQなど

完全一致検索の限界と類似度検索の強み

従来のデータベースで「パソコンが故障した時の対処法」を探す場合、クエリに「パソコン」「故障」というキーワードが含まれている必要があります。

もし社内マニュアルに「PCが動かなくなった場合」としか書かれていなかった場合、従来のキーワード検索（完全一致検索）ではヒットしないか、スコアが低くなってしまいます。

一方、ベクトルデータベースは言葉の意味（文脈）を数値化して検索するため、「パソコンが故障した」と「PCが動かない」が空間上で非常に近い場所にあることを認識し、キーワードが一致していなくても正しい文書を引き当てることができます。

ベクトルデータベースの歴史と進化の系譜

ベクトルデータベースは、突如として生まれたわけではありません。検索技術とAI技術の進歩に伴って進化してきました。

【第1世代】形態素解析・キーワード検索 (1990年代〜)
  └─ Grep, Relational DB, Full-text Search (Elasticsearch, Solr)
       │
【第2世代】単語ベクトル時代の到来 (2010年代半ば)
  └─ Word2vec, FastText, 近傍検索ライブラリ (FLANN, Annoy)
       │
【第3世代】Transformer・高次元Embedding & ライブラリ化 (2018年〜2020年)
  └─ BERT, FAISS (Facebook AI Similarity Search)
       │
【第4世代】AI専用クラウド・分散型ベクトルDB時代 (2021年〜現在)
  └─ Pinecone, Milvus, Qdrant, Chroma, pgvector

第1世代：キーワード完全一致と全文検索（1990年代〜）

文字の並びを直接比較する時代です。

B-Treeインデックスや転置インデックス（Inverted Index）を利用し、「指定した単語が含まれているか」を判定していました。SolrやElasticsearch（BM25アルゴリズム）が代表例です。

第2世代：単語ベクトル（Word2vec）の登場（2010年代半ば）

2013年、Googleが発表した「Word2vec」により、単語を数ベクトルの世界へ変換する技術が一躍有名になりました。

「王様 – 男性 + 女性 = 女王」といった単語同士の足し引きができることが話題となり、単語の類似度検索が盛んに行われるようになりました。

第3世代：高次元Embeddingとライブラリ時代（2018年〜2020年）

Transformerモデル（BERTなど）が登場し、単語単位だけでなく「文脈全体を考慮した文章全体のベクトル化」が可能になりました。

この頃、大量の高次元ベクトルから高速に似たものを探すためのライブラリとして、Meta（旧Facebook）が開発したFAISS（Facebook AI Similarity Search）や、Spotifyが開発したAnnoyが登場します。しかしこれらはあくまで「メモリ上で動く検索ライブラリ」であり、データの永続化や動的なCRUD（追加・更新・削除）操作、ユーザー管理などのデータベースとしての機能は不足していました。

第4世代：AI専用ベクトルデータベースの爆発的普及（2021年〜現在）

大規模言語モデル（LLM）の台頭とRAGの普及に伴い、ライブラリではなく「完全なデータベース」としての要求が高まりました。

リアルタイムでのデータ追加・削除
分散処理によるペタバイト規模への拡張性
メタデータ（作成日やカテゴリなど）によるフィルタリング機能
厳格なセキュリティとアクセス制御

これらを備えたPinecone、Milvus、Qdrant、Chromaなどの専用ベクトルデータベースが誕生し、RAG開発に欠かせないインフラとなっています。

ベクトル検索を支えるコアな「データ構造」と「アルゴリズム」

何百万、何千万もの高次元ベクトルの中から、ユーザーの質問に最も近いベクトルを探し出すにはどうすればよいでしょうか？

すべてのベクトルと順番に距離を計算していく方法をk-NN（k-Nearest Neighbors：k近傍法）または全探索（Brute-force）と呼びます。

しかし、1,000万件の1,536次元データに対して毎回全探索を行うと、1回の検索に数秒〜数分かかってしまい、実用になりません。

そこでベクトルデータベースでは、精度をわずかに犠牲にする代わりに検索速度を劇的に高めるANN（Approximate Nearest Neighbor：近似最近傍探索）という技術と、それを支えるデータ構造を使用しています。

Firestoreをベクトルデータベースとして使う場合は、データ検索はシステム側で自動で行われます。

主要なデータ構造・アルゴリズムを4つ解説します。

① HNSW（Hierarchical Navigable Small World）

現在、最も広く使われている非常に高性能なグラフベースのデータ構造です。

仕組みの比喩：特急電車と各駅停車

HNSWは、多次元空間内に作られた「多層構造のグラフ（ネットワーク）」です。

例えるなら「路線図」です。

【第2層：高速レイヤー（新幹線）】   [駅A] ------------------------> [駅Z]
                                     │                               │
【第1層：中速レイヤー（快速）】     [駅A] ---------> [駅M] ---------> [駅Z]
                                     │                │              │
【第0層：低速レイヤー（各駅）】     [駅A] -> [駅B] -> [駅M] -> [駅K] -> [駅Z]

最上層（スキップリスト）: 非常に大雑把で遠くへ一気にジャンプできるノード（駅）だけが存在します。ここで目的地のおおよその方角へ一気に移動します。
中間層: 少しずつノードが密になり、目的地へ近づきます。
最下層: すべてのデータが存在する密度の高いグラフです。最終的に目的に最も近いノードへ到達します。

メリット・デメリット

メリット: 検索速度が極めて速く、高い検索精度（Recall）を維持できる。
デメリット: グラフ構造をメモリ（RAM）上に保持するため、メモリ消費量が非常に大きい。

② IVF（Inverted File Index：転置ファイルインデックス）

空間をあらかじめいくつかのグループ（クラスタ）に分割しておく方法です。

仕組みの比喩：図書館のジャンル別棚分け

多次元空間内にいくつかの「代表点（重心）」を置き、すべてのベクトルを一番近い代表点のグループ（セル/クラスタ）に分類しておきます（k-meansクラスタリングなどを利用）。

 +-----------------------------------+
 |   クラスタA     |    クラスタB    |
 |     ●   ●       |      ▲   ▲      |
 |   ●   (重心1)   |    ▲   (重心2)  |
 |-----------------+-----------------|
 |   クラスタC     |    クラスタD    |
 |     ■   ■       |      ★   ★      |
 |   ■   (重心3)   |    ★   (重心4)  |
 +-----------------------------------+

検索時は、まず「クエリ（質問）がどの重心に一番近いか」を判定します。

仮に「クラスタBの重心」に一番近ければ、クラスタA, C, Dに存在するすべてのデータを検索対象から除外し、クラスタBの中だけを詳しく探します。

メリット・デメリット

メリット: 比較対象を全体の一部（例：全体の5%）に絞り込めるため、計算量を激減できる。
デメリット: 境界付近にあるデータを見落とす可能性があり、精度がやや落ちる。

③ PQ（Product Quantization：プロダクト量子化）

高次元ベクトルそのものを「圧縮」してメモリ使用量を抑える技術です。

仕組みの比喩：画像の画質を落としてファイルサイズを小さくする

1,536次元の浮動小数点数データは、そのまま持つと膨大なメモリを消費します。PQでは、この巨大なベクトルをいくつかの短いサブベクトルに分割し、それぞれのパターンを代表値（コードブック）に置き換えてID化します。

例えば、128バイトあるデータを数バイトのIDの組み合わせに圧縮します。

メリット・デメリット

メリット: メモリ使用量を1/10〜1/100程度まで削減でき、大量のデータを安価に扱える。
デメリット: データを圧縮するため、元の距離計算の正確性が損なわれる（精度低下）。

④ LSH（Locality Sensitive Hashing：位置に敏感なハッシュ）

似たベクトル同士が「同じハッシュバケット（箱）」に入りやすくなるように設計されたハッシュ関数を用いる手法です。

通常のハッシュ関数（SHA-256など）は、1文字でもデータが違うと全く異なるハッシュ値を返します。しかしLSHは逆に「元のデータが近ければ近いほど、同じハッシュ値になりやすい」という特殊な性質を持ちます。

これによって、ハッシュ値が一致する箱の中だけを探せばよいため、高速な検索が可能になります。

類似度計算の数学的基礎（コサイン類似度・ユークリッド距離・内積）

ベクトルデータベースが2つのベクトルA とB の「近さ」を判定するための数学的計算方法があります。

   ベクトルA ↗
            / 
           /  θ (角度)
          +------------> ベクトルB

Firestoreでは距離尺度（Distance Measure）を選択する

Firestoreのベクトル検索では、クエリ実行時に近さ判定の方法を以下3つから指定します。

COSINE（コサイン距離 / 推奨）
- 用途: OpenAI（text-embedding-3-small等）などのEmbeddingモデルを使ったテキスト検索・RAG。
- 理由: 文章の長さに左右されず、意味の類似度を正確に測れるため。
DOT_PRODUCT（内積）
- 用途: 事前に正規化（長さ1に補正）されたベクトルを扱う場合。
- 理由: コサイン距離と数学的に同等で、より高速に計算可能。
EUCLIDEAN（ユークリッド距離）
- 用途: 画像特徴量や物理的な位置関係など、ベクトルの絶対値の大きさが意味を持つ場合。

① コサイン類似度（Cosine Similarity）

2つのベクトルの「向き（角度 $\theta$）」の近さを測る指標です。ベクトルの長さ（大きさ）を無視して、同じ方向を向いているかどうかだけを判定します。

値の範囲: -1.0 ～ 1.0（1.0に近いほど完全に同じ向き、0は無関係、-1は真逆）
適した用途: テキストの類似度検索（RAGの標準）。文章の長さ（単語数）による影響を受けずに、内容の意味的な共通性を比較できるため。

② ユークリッド距離（Euclidean Distance / L2 Distance）

多次元空間における2点間の「まっすぐな直線距離」を測定します。

値の範囲: 0 ～ ∞（0に近いほど距離が近く、似ている）
適した用途: ベクトルの大きさ（長さ）自体に重要な意味があるデータ（例：画像の幾何学的特徴や物理量データ）。

③ 内積・ドット積（Dot Product / IP: Inner Product）

2つのベクトルの要素同士を掛け合わせて足し合わせたものです。

値の範囲: -∞～+∞
適した用途: ベクトルの長さ（ノルム）がすべて「1」に正規化されている場合、内積の計算結果はコサイン類似度と完全一致します。平方根などの複雑な計算を省けるため、最も高速に処理できます。推薦システム（レコメンデーション）などでよく使われます。

代表的なベクトルデータベース・ライブラリ徹底比較

現在、市場には多くのベクトルデータベースが存在します。それぞれの特徴と使い分けをまとめました。

サービス / ライブラリ名	種別	特長・強み	推奨ユースケース
Pinecone	フルマネージドSaaS	サーバーレスで運用が超簡単。全自動スケーリング。	インフラ管理を完全に任せたい企業、最速でプロダクション導入したい場合
Milvus	オープンソース / 分散型DB	大規模（数億〜数十億件）データに対応。高機能。	大企業、オンプレミス環境、超大規模な検索インフラ
Qdrant	オープンソース (Rust製)	高速、メモリ効率が良い、強力なメタデータフィルタ	自社サーバーで運用したい、フィルタリング条件が複雑な場合
Chroma	オープンソース (Python製)	設定ゼロで動く。軽量・シンプル。	ローカル開発、RAGのPoC（概念実証）、プロトタイプ作成
pgvector	PostgreSQL拡張機能	既存のPostgresにベクトル検索機能を追加	既にPostgreSQLを使っており、インフラを追加したくない場合
FAISS	ライブラリ (C++/Python)	Meta製。検索アルゴリズム自体は最速クラス。	DB機能（CRUDや永続化）が不要で、メモリ上での高速処理のみ求む場合

RAG構築時におけるベクトルデータベースの注意点と落とし穴

ベクトルデータベースを導入してRAGを構築する際、初心者がハマりがちな5つの注意点を解説します。

① チャンク分割（Chunking）戦略の難しさ

長文のPDFやWebページをそのままベクトル化しても、良い検索結果は得られません。

文書を適切な大きさ（例：300〜1,000文字程度）の「チャンク（断片）」に分割して保存する必要があります。

チャンクが大きすぎる場合
ノイズ（無関係な文脈）が多く含まれ、ベクトルが「平均化」されて意味がボやけてしまう。
チャンクが小さすぎる場合
前後の文脈が切れ、単語の断片しか残らないため正しく意味を捉えられない。

最適なチャンクサイズと、少しずつ文頭・文末を重ね合わせる「オーバーラップ（Overlap）」の設定が精度を決定づけます。

② 「メタデータ・フィルタリング」の重要性

ベクトル検索（意味の検索）だけに頼ると、「2024年の売上」を聞いているのに「2021年の売上」の文書を「意味が似ているから」という理由で引っ張ってきてしまうことがあります。

これを防ぐのがメタデータ（属性情報）です。

ドキュメントを保存する際、テキストと一緒に以下の情報を付与しておきます。

作成年月日（date: 2024-04-01）
部署名（department: hr）
文書種別（category: manual）

検索時に「department == 'hr' かつ date >= 2024-01-01 のデータの中からベクトル検索を行う」というハイブリッドな絞り込みを行うことが実運用では必須となります。

③ 精度（Recall）と検索速度（Latency）のトレードオフ

HNSWやIVFなどのANN（近似最近傍探索）アルゴリズムは、パラメータ調整が必要です。

精度を高く設定する
より正確な結果が得られるが、検索に時間がかかりメモリ消費も増える。
速度を優先する
瞬時に結果が返ってくるが、稀に最も適切な文書を見落とす（漏れが生じる）。

システムの要件（リアルタイム性重視か、正確性絶対重視か）に合わせて設定値を調整する必要があります。

④ メモリ（RAM）コストの増大

特にHNSWなどのグラフ構造インデックスを採用している場合、インデックス全体を高速なRAM上に常駐させる必要があります。

データ量が数百万〜数千万件に増えると、必要なRAMの量が数百GBに膨れ上がり、クラウドのインフラ費用（サーバー代）が急増するというリスクがあります。

Quantization（PQなど）やディスクベースのインデックス（DiskANNなど）の検討が必要です。

⑤ 単一のベクトル検索の限界（ハイブリッド検索の推奨）

ベクトル検索は「概念・意味」の検索が得意ですが、以下のような検索には弱いです。

型番や固有名詞: 「型番 X-9982-AB の仕様書を出して」
人名やコード: 「佐藤さんの電話番号」

これらは完全一致検索（キーワード検索）が得意とする領域です。

そのため、現在の高度なRAGシステムでは、「キーワード検索（BM25等）＋ベクトル検索（Embedding）」の双方を実行し、その結果を再順位付け（Rerank）して統合する「ハイブリッド検索（Hybrid Search）」が標準的な構成となっています。

まとめ：ベクトルデータベースの選び方とこれからの展望

RAGにおけるベクトルデータベースの役割と重要性について解説してきました。最後に、導入に向けたロードマップを整理します。

導入ステップのロードマップ

【Step 1: プロトタイプ・PoC作成】
  └─ Chroma や FAISS を使い、ローカル環境で小さなRAGを組んでみる。
       │
【Step 2: 既存インフラとの統合】
  └─ すでに PostgreSQL を運用中なら、pgvector を試してみる。
       │
【Step 3: 本番運用・スケールアウト】
  └─ 運用コストを抑えたい ➔ Pinecone (マネージドSaaS)
  └─ オンプレミス / データセキュリティ厳守 ➔ Qdrant や Milvus