ベクトルデータベースの選定——用途で決める4つの軸

「RAGを構築するから、ベクトルデータベースを選定してほしい」——この相談は、2023年から2025年にかけて特に頻繁に受けた。ベンダーの数は爆発的に増え、比較記事は氾濫している。どこから見ればよいかを迷うのは自然だ。

この記事では、編集部が観測してきた選定プロセスの実務的な傾向を、製品名ではなく判断軸で整理する。

選定軸を7つに絞る

ベクトルDBの選定でよく問われる軸を、実運用でウェイトを持つ順に並べると次のようになる。

• スケール：想定ベクトル数、増加率、次元数。
• レイテンシ：クエリのP99、負荷時の安定性。
• フィルタリング：メタデータでの絞り込み（ユーザーID・時刻・タグ）。
• ハイブリッド検索：BM25等のキーワード検索との併用可否。
• 既存インフラとの統合：既存DB・データパイプライン・監視ツールとの相性。
• 運用コスト：単純な月額単価ではなく、運用担当者の学習コストも含む。
• データ保持と削除：GDPR / APPI対応、リージョン、暗号化。

小〜中規模なら、既存DBの拡張で足りることが多い

「専用ベクトルDBを最初から入れるべき」という主張は根強いが、編集部の観測では、100万ベクトル程度までは既存のリレーショナルDBの拡張で十分実運用に耐えている。PostgreSQLならpgvector、SQLiteならsqlite-vec、MySQLも近年ベクトル型を追加した。

この選択の利点は運用面に集中する。バックアップ・監視・アクセス制御の既存の仕組みが再利用できる。SQLでメタデータフィルタとベクトル検索を同時に書ける。運用担当者の学習コストが小さい。特別な理由がなければ、まずここから始めることを勧めたい。

大規模になると、専用DBの優位が出る

ベクトル数が数千万を超え、レイテンシ要件が数十msを切る領域では、専用DB（Milvus、Weaviate、Qdrant、Pinecone等）の優位が明確になる。HNSWやIVF等のインデックス構造への最適化、シャーディング、GPU活用など、既存DBでは追いつかない領域だ。

ただし、この規模に到達する前に、「そもそもチャンク数を減らせないか」を再検討する価値もある。より粗い粒度でチャンク化する、階層検索（粗い検索→細かい検索）を導入する、古いチャンクをアーカイブする——ベクトル数を1桁減らせれば、選定の緊急度も下がる。

フルマネージドは、開発初速と運用コストのトレードオフ

フルマネージドサービス（Pineconeなど）は、開発初速を稼げる代わりに、データ量が増えると単価が急速に上がる。編集部が観測した運用チームの一部は、開発期はマネージドで走らせ、本番運用が固まった段階でセルフホストへ移行していた。

ただし移行コストは無視できない。データフォーマット、クエリインターフェイス、メタデータのスキーマは製品ごとに違う。「切り替える前提」で設計するなら、自前の抽象レイヤーを最初から用意しておく必要がある。

ベンダー公表のベンチマークは、参考にとどめる

各ベンダーは、しばしば有利な条件でのベンチマーク結果を公表する。特定のデータセット・特定のクエリパターン・特定のインデックス設定——自組織の運用条件と一致することは稀だ。

編集部が推奨するのは、選定の後半で候補を2〜3に絞ってから、実データ（少なくともサブセット）でPoCを走らせることだ。1週間の実運用相当の負荷をかけ、レイテンシP99・エラー率・運用の詰まりを観測する。ここで初めて、公表ベンチマークとの乖離が見える。

もっとも、ベクトルDBがすべてを決めるわけではない

ただし、RAG全体の品質を左右するのはベクトルDBの性能だけではない。RAG全体の設計に関する記事で扱ったように、チャンク分割、埋め込みモデル、リランキング、プロンプト設計のほうが最終品質への寄与が大きいケースは多い。ベクトルDBの選定に3ヶ月かけるより、これらを詰めることを優先したほうがROIが高いことが多い。

参考にした一次資料

• Malkov, Y., Yashunin, D. “Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs.” arXiv:1603.09320.
• ANN-Benchmarks Project. ann-benchmarks.com（独立系のベンチマーク集）.