RAG構築で最初にぶつかる選定判断が「どのベクトルデータベースを使うか」です。結論から申し上げますと、ベクトルDB選定はデータ規模と運用リソースの2軸で決まり、小規模ならpgvectorやChroma、中〜大規模ならQdrantやWeaviate、大規模フルマネージドならPineconeが定番となっています。本記事では、主要5製品の特徴と選定基準、そして実装コード例までを整理して解説します。
ベクトルデータベースとは何か
ベクトルデータベースとは、高次元ベクトルデータの保存と類似度検索に特化したデータベースのことです。従来のRDBやNoSQLが「完全一致」「範囲検索」を中心とするのに対し、ベクトルDBは「意味的に近い」データを高速に探すための近似最近傍探索(ANN: Approximate Nearest Neighbor)を標準装備しています。
ANNには複数のアルゴリズムが存在します。HNSW(階層的小世界グラフ)が最もポピュラーで、精度と速度のバランスが良く主要DBの多くが採用しています。IVF(倒立インデックス)、PQ(積量子化)なども用途によって使われます。重要なのは、これらの内部実装の違いを意識しなくても使えるインターフェースが提供されている点です。
【ベクトルDBの検索メカニズム】
[ユーザークエリ] 例: 「返品の方法を教えてください」
|
v
[エンベディング化] text-embedding-3-small等で1536次元ベクトルに
|
v
[ベクトルDB検索] ANN探索(HNSW等)で上位k件を高速抽出
| ※k=5 程度が一般的
v
[メタデータフィルタ] カテゴリ・日付・権限でさらに絞り込み
|
v
[類似文書リスト] スコア付きで返却
|
v
[後処理] re-ranker で精度向上、LLMに渡す
※全件線形探索ではなく近似探索で O(log n) 相当の高速化。
主要ベクトルデータベースの比較
Pinecone(フルマネージド)
Pineconeは業界リーダー的存在のフルマネージドベクトルDBです。SaaSとして提供され、インフラ管理が一切不要で、数十億ベクトル規模でも線形にスケールします。RAGプロジェクトで「運用に手間をかけたくない」「本番SLAを保証したい」場合の第一候補です。料金は使用量に応じた従量課金で、小規模の無料枠もあります。
Weaviate(オープンソース + マネージド)
WeaviateはOSSとSaaSの両方を提供する柔軟なベクトルDBです。GraphQL APIと豊富なメタデータ機能、エンベディング生成の内蔵モジュールが特徴で、「検索 + 構造化フィルタ」の複雑なクエリに強みがあります。OSS版はセルフホストでき、データ主権を守りたい企業に向いています。
Qdrant(オープンソース、Rust製高速)
QdrantはRustで実装された高速ベクトルDBで、パフォーマンス重視のプロジェクトに向いています。フィルタリング付きANN検索の精度と速度が秀逸で、メタデータに基づく絞り込みが多い用途で強みを発揮します。Docker一発で立ち上がる運用性の良さも魅力です。
Chroma(軽量、プロトタイプ向け)
Chromaは「RAGの最初の1歩」に最適な軽量ベクトルDBです。Pythonのpipだけでインストールでき、ファイルベースで動作するためプロトタイピングが極めて高速です。ただし大規模運用や高可用性が求められる本番環境には他の選択肢を検討すべきです。
pgvector(PostgreSQL拡張)
pgvectorはPostgreSQLの拡張モジュールで、既存のRDBにベクトル検索を追加できます。専用DBを増やさず、SQLで構造化データとベクトル検索を統合的に扱える点が最大の魅力です。数百万件規模までなら性能面でも十分通用します。
| DB名 | 提供形態 | ライセンス | スケーラビリティ | フィルタリング | 日本語対応 | 料金体系 | 適した規模 |
|---|---|---|---|---|---|---|---|
| Pinecone | マネージド | 商用 | 非常に高い | 対応 | 対応 | 従量課金 | 中〜超大規模 |
| Weaviate | OSS+マネージド | BSD-3 | 高い | 高度な対応 | 対応 | OSS無料/SaaS従量 | 中〜大規模 |
| Qdrant | OSS+マネージド | Apache 2.0 | 高い | 高度な対応 | 対応 | OSS無料/SaaS従量 | 中〜大規模 |
| Chroma | OSS | Apache 2.0 | 低〜中 | 基本対応 | 対応 | 無料 | 小規模・プロト |
| pgvector | PostgreSQL拡張 | PostgreSQL License | 中 | SQLで自由 | 対応 | PostgreSQL次第 | 小〜中規模 |
ベクトルDBの選定基準
選定基準は「データ量」「運用リソース」「既存インフラ」「コスト許容度」の4軸が中心です。以下のフローチャートで大まかな方向性を決められます。
Q1. データ量は数万件以下ですか?
├── Yes --> Chroma / pgvector (最速立ち上げ)
└── No
|
v
Q2. 既存にPostgreSQLがありますか?
├── Yes --> Q3. データ量は数百万件以下?
│ ├── Yes --> pgvector (SQLで統合運用)
│ └── No --> 専用DBへ
└── No
|
v
Q4. 運用リソースを割けますか?
├── No --> Pinecone / Weaviate Cloud (マネージド)
└── Yes --> Qdrant / Weaviate OSS (自社運用)
| ユースケース | データ量 | 推奨DB | 理由 |
|---|---|---|---|
| プロトタイピング | 数千件 | Chroma | pipのみで即起動 |
| 社内FAQボット | 数万件 | pgvector / Chroma | 既存RDB活用 |
| 社内ドキュメントRAG | 数十万件 | Qdrant / Weaviate | メタデータ豊富 |
| 顧客対応大規模RAG | 数百万件以上 | Pinecone / Qdrant Cloud | SLAとスケール |
| EC商品レコメンド | 数千万件 | Pinecone | 超大規模対応 |
ベクトルDBの実装入門
まずはChromaでベクトルを保存・検索する最小実装例です。ローカルのJupyter Notebookからも数分で動かせます。
import chromadb
from openai import OpenAI
client = OpenAI()
chroma_client = chromadb.PersistentClient(path="./chroma_db")
collection = chroma_client.get_or_create_collection("documents")
def embed(text: str) -> list:
return client.embeddings.create(
input=text, model="text-embedding-3-small"
).data[0].embedding
docs = ["RAGとは検索拡張生成のことです", "ベクトルDBは類似度検索に使います"]
collection.add(
documents=docs,
embeddings=[embed(d) for d in docs],
ids=[f"doc_{i}" for i in range(len(docs))],
)
results = collection.query(
query_embeddings=[embed("検索拡張生成について教えて")],
n_results=2,
)
print(results["documents"])
次にQdrantでの実装例です。Dockerで立ち上げた後、Python SDKから操作します。
from qdrant_client import QdrantClient
from qdrant_client.http.models import Distance, VectorParams, PointStruct
qdrant = QdrantClient(host="localhost", port=6333)
qdrant.recreate_collection(
collection_name="documents",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
qdrant.upsert(
collection_name="documents",
points=[
PointStruct(id=i, vector=embed(d),
payload={"text": d, "category": "ai-ops"})
for i, d in enumerate(docs)
],
)
hits = qdrant.search(
collection_name="documents",
query_vector=embed("RAGとは何ですか"),
limit=2,
)
ベクトルDBの運用上の注意点
ベクトルDBの運用で押さえておくべきは、インデックスの再構築タイミング、バックアップ戦略、そしてモニタリングの3点です。インデックスは大量追加後にパフォーマンスが劣化することがあり、定期的な再構築が必要な場合があります。バックアップは従来のRDBと同じく重要で、特にエンベディング生成には大きな計算コストがかかるため、失えば再生成に膨大な時間がかかります。
さらに重要なのが、エンベディングモデル変更時の再インデックス戦略です。モデルを更新するたびに全文書をベクトル化し直す必要があり、この移行計画を事前に設計しておかないと本番中断につながります。
まとめ――ベクトルDBはAIアプリの「記憶装置」
- ベクトルDBは高次元ベクトルの類似度検索に特化したデータベース
- Pinecone、Weaviate、Qdrant、Chroma、pgvectorが主要5製品
- 選定はデータ量と運用リソースの2軸が中心
- 運用ではインデックス再構築とモデル変更時の移行計画が重要
DE-STKでは、RAG基盤のベクトルDB選定から構築、運用改善まで一貫して支援しています。どのベクトルDBを採用すべきか迷われている方、既存RAGの性能改善を検討されている方は、お気軽にご相談ください。
よくある質問
Q. ベクトルデータベースとは何ですか?
高次元ベクトルデータの保存と類似度検索に特化したデータベースです。テキストや画像をエンベディング(数値ベクトル)に変換して保存し、「意味的に近い」データを高速に検索できます。RAGやセマンティック検索の基盤技術です。
Q. ベクトルDBとRDBの違いは何ですか?
RDBはSQLによる完全一致・条件検索が中心ですが、ベクトルDBはANN(近似最近傍探索)による類似度検索に最適化されています。「この文書に意味的に近い文書を探す」といった曖昧な検索が高速に実行できる点が最大の違いです。
Q. pgvectorで十分ですか?専用ベクトルDBは必要ですか?
数万件規模の小〜中規模データであればpgvectorで十分対応できます。既存のPostgreSQL環境を活かせるメリットも大きいです。数百万件以上のデータや高いスループットが必要な場合は、専用ベクトルDB(Pinecone、Qdrant等)の方が性能面で有利です。