ベクトルデータベース(Vector Database)

1. 概要

ベクトルデータベースとは、テキスト・画像・音声などの非構造化データを埋め込み(Embedding)モデルで変換した高次元ベクトルを格納し、クエリベクトルとの意味的類似度(Similarity) を近似最近傍(ANN, Approximate Nearest Neighbor)探索によって高速に見つけて返すデータ管理システムである。

従来のリレーショナルデータベースは、値の完全一致(Exact Match) や範囲条件に最適化されており、「この文と意味が似ている文書を探せ」といったクエリを処理できない。しかし生成AIと検索拡張生成(RAG)が普及するにつれ、自然言語の質問の意味に近い知識をリアルタイムに検索し、LLMのプロンプトに注入する必要性が急増した。このとき文書・画像を数百〜数千次元のベクトルで表現すれば、「意味が近いもの」がそのまま「ベクトル空間上で距離が近いもの」となるため、大規模ベクトルに対する高速な類似度検索エンジンが必要になった。ベクトルデータベースは、まさにこの空白を埋めるために登場した。

ベクトルデータベースの中核的な価値は3つある。第一に、意味ベースの検索により、キーワードが完全に一致しなくても文脈的に関連する結果を見つける。第二に、数億件規模のベクトルでもミリ秒単位で応答できるよう、ANNインデックスによって精度とレイテンシのバランスを調整する。第三に、RAG・レコメンデーション・異常検知・重複排除など、多様なAIパイプラインの知識ストア(Knowledge Store) としての役割を果たす。

2. 動作原理および全体構造

ベクトルデータベースは、元データを埋め込みに変換する取り込み(Ingestion) 経路と、クエリをベクトル化して類似ベクトルを探す検索(Query) 経路に分かれる。取り込み段階では、文書を適切なサイズに分割(Chunking)した後に埋め込みモデルでベクトル化し、ベクトルと原文・メタデータを併せてインデックスに格納する。検索段階では、ユーザーのクエリを同じ埋め込みモデルでベクトル化し、ANNインデックスを探索して上位K個(Top-K)の類似ベクトルを取得する。

flowchart LR
  subgraph Ingestion["取り込み経路"]
    D["元データ(文書/画像)"] --> C["チャンキング(Chunking)"]
    C --> E1["埋め込みモデル"]
    E1 --> V1["ベクトル + メタデータ"]
    V1 --> IDX["ANNインデックス格納"]
  end
  subgraph Query["検索経路"]
    Q["ユーザークエリ"] --> E2["埋め込みモデル"]
    E2 --> V2["クエリベクトル"]
    V2 --> SR["類似度検索(Top-K)"]
    IDX --> SR
    SR --> R["結果 + メタフィルタ"]
  end
  R --> LLM["LLMプロンプト注入(RAG)"]

ここで重要な原理は、取り込みと検索で同一の埋め込みモデルを使用しなければならないという点である。異なるモデルで作ったベクトルは座標系が異なり、距離の比較が無意味になるためである。したがって埋め込みモデルを交換すると、格納済みのベクトル全体を再計算(Re-indexing)する必要があり、これは運用上の大きなコスト要因となる。

A. 類似度の測定方式

類似度はベクトル間の距離として定義される。代表的なものとして、2つのベクトルがなす角度のコサインを見るコサイン類似度、ベクトルの内積をそのまま用いる内積(Dot Product)、座標間の直線距離を見るユークリッド距離(L2) がある。文書検索のようにベクトルの方向(意味)が重要で、大きさ(文書の長さ)の影響を減らしたい場合には、コサイン類似度が広く用いられる。埋め込みを正規化すればコサイン類似度と内積は事実上同一になるため、大規模サービスでは計算が単純な内積が好まれることもある。

B. ANNインデックスアルゴリズム

数億個のベクトルをすべて比較する全探索(Brute-force)は正確だが遅い。そこで、わずかな精度を犠牲にする代わりに速度を劇的に高めるANNインデックスを用いる。代表的なアルゴリズムは、グラフベースのHNSW(Hierarchical Navigable Small World)、クラスタ分割ベースのIVF(Inverted File)、ベクトルを圧縮してメモリを節約するPQ(Product Quantization) である。HNSWは階層的なグラフをたどって近傍を探索し、高い再現率と低いレイテンシを同時に達成するため事実上の業界標準となったが、メモリ使用量が大きいという欠点がある。IVFはベクトル空間を複数のセルに分割し、クエリに近い一部のセルのみを探索するため大容量に有利であり、PQと組み合わせる(IVF-PQ)とメモリを大幅に削減できるため、超大規模サービスで好まれる。

flowchart TB
  Q["クエリベクトル"] --> ENTRY["エントリポイント(上位層)"]
  ENTRY --> L2["中間層のグラフ探索"]
  L2 --> L1["下位層の精密探索"]
  L1 --> TOPK["近傍Top-K候補"]
  TOPK --> RERANK["精密リランキング(Re-rank)"]
  RERANK --> OUT["最終結果を返却"]

このとき、精度(再現率)と速度・メモリはトレードオフの関係にある。HNSWのef_search(探索幅)を大きくすれば再現率は上がるがレイテンシが増え、IVFの探索セル数(nprobe)を増やしても同様である。実務では目標SLA(例: p99 50ms、再現率95%)を定めたうえでパラメータをチューニングする。

C. メタデータフィルタリングとハイブリッド検索

実際のサービスでは、「2024年以降に作成された、セキュリティカテゴリの文書のうち意味が類似するもの」のように、ベクトル類似度と構造化条件を併せて指定する必要がある。そのため、ベクトルとともに格納したメタデータによって事前/事後フィルタリング(Pre/Post-filtering) を行う。さらに、キーワードの完全一致に強いスパース検索(BM25など) と、意味検索に強い密ベクトル検索を組み合わせたハイブリッド検索が最近の標準として定着しつつある。固有名詞・コード・数値のように埋め込みが苦手とする部分を、キーワード検索が補完するためである。

3. 構築タイプの比較

ベクトル検索は、専用エンジンとして構築することも、既存データベースの拡張機能として実装することもできる。専用ベクトルDB(例: Pinecone, Milvus, Weaviate, Qdrant)は大規模処理と多様なインデックス・フィルタ機能に強みがあるが、システムが1つ増えるため運用の複雑さが増す。逆にリレーショナルDBの拡張(PostgreSQLのpgvectorなど)は、既存データとトランザクション・結合を併用できるため導入の障壁が低いが、超大規模・超低レイテンシの要求では専用エンジンに劣る場合がある。したがって、データ規模、既存スタック、チームの能力を総合的に考慮して選択しなければならない。

例えば社内規程文書数万件を対象とするRAGチャットボットであれば、pgvectorから始めて運用を単純化する方が合理的であるが、数億件の商品・レビューを扱うコマースのレコメンデーションであれば、IVF-PQベースの専用エンジンでメモリとレイテンシを制御する方がよい。

4. 深掘り — RAG品質と最新動向

ベクトルデータベースの成否は、そのままRAGの回答品質に直結する。検索が不十分であればLLMが根拠のない回答を生成(ハルシネーション)するため、チャンキング戦略(段落・意味単位の分割)、埋め込みモデルの選択(ドメイン適合性)、Top-Kの件数、そして取得した候補を並べ直すリランキング(Re-ranking) モデルの組み合わせが重要である。最近では、複数の文を圧縮した単一ベクトルが情報を失う問題を補うため、トークン単位の複数ベクトルで精度を高めるColBERT型の後期相互作用(Late Interaction) 手法や、要約で検索して原文を返す多段階検索戦略が注目されている。また、埋め込み次元を状況に応じて切り詰めて使うMatryoshka埋め込みは、格納コストと精度を柔軟に調整する手段として広がりつつある。標準化の面では、pgvectorが事実上のオープン標準として定着し、主要クラウドのマネージドDBに幅広く搭載される流れが鮮明である。

5. 考慮事項および示唆

技術士の観点では、ベクトルデータベースの導入は単なるストレージの選択ではなく、AIサービスアーキテクチャ全体のトレードオフを調整する意思決定である。

• 精度-性能-コストの三角トレードオフ: HNSW/IVFのパラメータ、ベクトル次元、量子化レベルは、再現率・レイテンシ・メモリを同時に左右する。目標SLAと予算をまず定義し、ベンチマークから逆算するのが望ましい。
• 埋め込みモデルへの依存と再インデックス戦略: モデルの交換は全ベクトルの再計算を引き起こすため、無停止の再インデックス(Blue-Green Index)とバージョン管理体系を事前に設計しなければならない。
• データガバナンス・セキュリティ: 原文と埋め込みに個人情報が含まれる可能性があり、埋め込み逆推定(Embedding Inversion)によって原文が一部復元される危険もあるため、アクセス制御・暗号化・マスキングをベクトル層まで拡張しなければならない。
• ハイブリッド・リランキングの併用: 純粋なベクトル検索だけでは固有名詞・数値に弱いため、キーワード検索とリランキングモデルを組み合わせてRAG品質を確保する。
• 運用の可観測性: 再現率・レイテンシ・インデックスの鮮度(Freshness)を指標化してオブザーバビリティ体系で常時監視し、データ増加に備えたシャーディング・水平スケール戦略を併せて用意しなければならない。

今後、ベクトル検索はRDB・検索エンジンに基本機能として吸収され、「特殊なシステム」から「普遍的な機能」へと成熟する見通しであり、マルチモーダル埋め込みとエージェント型検索の普及によって、その重要性はさらに高まるであろう。

参考資料

• pgvector プロジェクト, https://github.com/pgvector/pgvector
• Malkov & Yashunin, "Efficient and robust approximate nearest neighbor search using HNSW", https://arxiv.org/abs/1603.09320

一言まとめ: ベクトルデータベースは、埋め込まれた高次元ベクトルをANNインデックスで高速に類似度検索し、RAG・レコメンデーション・異常検知の意味ベースの知識ストアとして機能するものであり、精度・性能・コストのトレードオフ調整が核心である。