ベクトルデータベースの選び方｜RAGで比較する8要件

ベクトルデータベースの選び方は、公開ベンチマークの順位ではなく、自社の質問、権限条件、更新頻度を同時に満たすかで決まります。RAG向け選定の最終成果物は製品一覧ではありません。240問の評価セットを各候補へ同じ条件で流し、検索品質、絞り込み後の件数、応答時間、削除反映、復旧、3年間の総費用を記録した採否表です。既存のPostgreSQLへ拡張を加える案、検索基盤へベクトル機能を加える案、専用サービスを採用する案を、共通の受入条件で比べます。

ベクトルデータベースは運用責任で三系統から選ぶ

最初の分岐は「どの製品が最速か」ではなく、「どの運用責任を増やせるか」です。既存のPostgreSQLで文書、権限、業務データを管理しており、数百万チャンク規模から段階的に始めるなら、SQLとトランザクションを維持できる拡張型が第一候補になります。すでに全文検索基盤、形態素解析、同義語辞書、ログ分析を運用している会社では、検索エンジン拡張型にベクトル検索を足す方が、二重管理を減らせます。複数チームが数千万以上のベクトルを共有し、水平拡張、専用の量子化、複数ベクトル、テナント分離を必要とする場合は、専用型を評価対象に入れます。

この三分類は性能の優劣ではありません。HNSWは階層化した近傍グラフを使い、高い再現率と検索速度の両立を狙う近似近傍探索です。原著論文は、パラメーターによって品質と計算量が変わることを示しています^[1]。したがって「HNSW対応」という機能表だけでは候補を順位付けできません。同じアルゴリズム名でも、フィルターの適用位置、インデックス構築方法、更新時の挙動、メモリ配置が異なります。

採用判断は、要件を満たす最小の運用面積を選ぶことです。将来の最大件数だけを根拠に複雑な分散構成を先取りすると、障害点と待機費用が先に増えます。

専用のベクトルデータベースが向かない例は、原本が5万件、同時検索が毎秒2件、更新が1日1回で、既存DBのバックアップ・監査・行単位制御をそのまま使える業務です。逆に、共有DB上で負荷の大きい近似探索を許可できず、検索ノードを独立して伸縮させたいなら、拡張型だけに絞るべきではありません。候補系統を決める入口は、件数、検索ピーク、鮮度SLA、権限境界、運用要員の五つです。

比較前に固定する8要件

RFPやPoC依頼書には、機能名ではなく合格値を書きます。「フィルター対応」では、候補が権限条件を満たすか判断できません。「部署IDと機密区分をAND条件にし、通過率0.5%の検索でも権限外0件、要求した上位10件を返し、p95が700ミリ秒以内」とすれば、各社が共通の試験へ回答できます。

OpenSearchの公式資料は、ベクトル検索のフィルターを検索中、検索後、完全一致の事前絞り込みなどに分け、データ件数、フィルター通過率、返却件数によって品質と遅延の選択が変わると説明しています^[4]。したがって、要件には「フィルターの有無」ではなく、絞り込み条件と合格値を組にして記載します。以下の値は架空の製造業ナレッジ検索を想定した設計例であり、自社の実測ベースラインがある場合は置き換えてください。

必須条件と加点条件は混ぜません。権限外の文書が1件でも返る、削除済み文書がSLAを超えて残る、バックアップから復旧できない、の三項目は総合点に関係なく失格です。一方、p95が目標より50ミリ秒速い、管理画面が使いやすい、といった差は加点に置けます。重大条件を重み付き平均へ入れると、安価さや速度の得点で情報漏えいを相殺する誤った採択が起きます。

240問の評価データを用意する

候補製品へ投入する文書と質問は全社で共通にします。公開ベンチマークはアルゴリズムの傾向を知る材料ですが、自社の日本語、型番、表、古い版、権限フィルターを再現しません。ANN-Benchmarksの原著は、複数データセットとパラメーターを用いて品質と性能の交換関係を測る枠組みを提示しています^[2]。調達PoCでも、単一のQPSや平均遅延ではなく、設定を振った品質曲線を残す考え方が有効です。

想定例では、実際の問い合わせログから個人情報を除去した160問、業務担当者が作る境界・例外質問40問、権限負例24問、答えが原本にない質問16問の計240問を使います。問い合わせを、型番・文書番号の完全一致60問、言い換え80問、複数条件40問、表内数値24問、版指定20問、回答不能16問に分けます。一つの質問へ、正解文書ID、正解チャンクID、根拠範囲、許可主体、関連度0〜3、回答不能フラグを付けます。少なくとも二人が独立に採点し、不一致は業務責任者が確定します。

{
  "query_id": "Q-0174",
  "query": "MX-410の保守契約を途中解約できる条件は何か",
  "principal": ["employee:2841", "group:service-east"],
  "as_of": "2026-06-30T09:00:00+09:00",
  "relevant_chunks": [
    {"chunk_id": "contract-88#sec-12", "grade": 3, "revision": "2026-04-01"}
  ],
  "must_not_return": ["contract-91#price", "hr-12#memo"],
  "answerable": true
}

評価集合は検証用80%、調整用20%に分けます。240問なら192問を採否判定へ固定し、48問だけで検索パラメーターを調整する想定です。同じ240問を見ながら重みやHNSW設定を繰り返し変えると、PoC専用の過学習が起きます。公開直前には、直近1か月の新しい質問を30問追加してブラインド確認し、主要区分のRecall@10が事前合格値を下回らないことを確かめます。

検索方式と権限フィルターを同時に測る

最初にExact検索を実行し、近似検索の正解近傍を作ります。次にHNSWやIVF系の候補で探索幅、リスト数、量子化、シャード数を変え、Recall@10、QPS、p50・p95・p99、メモリ、索引時間を記録します。Recall@10は「Exact検索の上位10件のうち、近似検索でも取得できた件数÷10」です。240問で9件ずつ一致したなら、延べ一致2,160件÷延べ正解2,400件=0.90となり、0.95の合格値には届きません。

フィルターは検索の後段だけで削らないことが重要です。OpenSearchの現行公式資料は、効率的k-NNフィルター、後置フィルター、Exact検索を伴う事前絞り込みを区別し、後置フィルターでは制約が強いと要求数より大幅に少ない結果になり得ると説明しています^[4]。製品ごとの名称に惑わされず、権限条件が近傍探索中に効くのか、候補取得後に落とすのか、条件通過後にExact検索するのかを確認します。

負荷の掛け方も統一します。想定ピーク300 QPSなら、30、150、300、450 QPSを各15分流し、最初の5分をウォームアップ、後半10分を採点区間にします。質問は240問から無作為抽出しつつ、権限選択率0.1%の要求を20%、更新と検索の競合を10%混ぜます。各候補へ同じクライアント、ネットワーク経路、payload返却量を使い、エラーを除外せずタイムアウトも最遅値として集計します。平均が合格しても、450 QPSでエラー率1%超、300 QPSでp99 1.2秒超なら容量不足と判定します。

pgvectorの公式READMEは、近似インデックスでフィルターが走査後に適用される場合、たとえば条件一致率10%で探索候補40件なら平均4件しか残らないと説明し、0.8.0以降の反復走査を対策として挙げています^[3]。2026年7月29日公開の変更履歴では最新版が0.8.6です^[7]。これは一製品の事実であり、全候補が同じ挙動だという意味ではありません。採用版を固定し、同じ負荷試験をアップグレード後にも再実行します。

三つの構成案を同じ証拠で比べる

機能比較表には「あり・なし」ではなく、利用可能な構成と責任範囲を書きます。Qdrantの公式フィルター資料は、埋め込みだけで表せない在庫、場所、価格などをpayload条件で絞り、よく使う条件には取り込み前のpayload index作成を勧めています^[5]。Milvusの現行アーキテクチャ資料は、アクセス、調整、処理、保存を分離し、メタデータ、オブジェクト、WALに異なる役割を持たせています^[6]。どちらも専用型の一例ですが、運用単位や復旧方法まで同じとは限りません。

同じデータ件数でも、更新比率が構成を変えます。毎晩全量を入れ替える100万チャンクと、毎分1万件を更新する100万チャンクでは、索引構築・削除・WAL・セグメント統合の負荷が異なります。さらに、部署別検索で対象割合が0.1%まで落ちるなら、無条件のベクトル検索が速い候補より、制約付き検索で品質を維持する候補を優先します。デモ用英語FAQではなく、自社の長い日本語、同名製品、旧版、権限の偏りを投入しなければ、この差は見えません。

既存DBへ同居できるかは、PoCで測ったCPU時間から判定します。想定例で検索1件が平均0.018 CPU秒、ピークが300 QPSなら、検索に必要なCPUは`300×0.018=5.4コア`です。16 vCPUの既存基盤で通常業務が6コアを使い、障害時の余力として40%を空ける場合、許容上限は`16×0.60=9.6コア`です。`6+5.4=11.4コア`は上限を超えるため、検索ノードを分ける案または専用型を比較へ残します。この式は平均CPUの容量目安にすぎず、メモリ不足、ストレージI/O、テナント偏り、瞬間的な集中を説明しません。式だけで製品を決めず、分離後も300 QPSでp95と更新遅延を実測します。

候補を二つまで絞る判定基準は、必須8要件をすべて満たし、運用担当が障害から復旧できることです。速度が最上位でも、設定変更をベンダーだけが実行でき、復旧目標を契約へ書けない候補は次段へ進めません。反対に、将来機能が少なくても、現行要件を満たし、既存チームが保守でき、標準形式で書き出せる候補には合理性があります。

障害試験では、検索ノード停止、保存先の一時遅延、埋め込み投入の重複、ネットワーク分断、容量上限の五つを順に起こします。単にAPIが200を返すかではなく、停止中に古い複製から権限変更前の結果を返さないか、復旧後に二重登録が残らないか、未反映イベントを再送できるかを確認します。RPO 15分なら、障害直前15分の変更が失われる可能性を業務所有者が許容できるかも決裁事項です。復旧手順を候補提供者の担当者ではなく、自社の当番がRunbookだけで実行し、開始から検索再開までをRTOへ含めます。

更新・削除・再索引を受入試験に含める

RAGでは検索開始時の速さだけでなく、正しい版へ切り替わる時間を測ります。文書を改訂したら、旧チャンクを消して新チャンクを登録し、検索結果と引用先が同じ版になるまでの経過を記録します。想定SLAを「更新15分、削除5分」とするなら、原本の更新時刻、抽出完了、埋め込み完了、索引反映、検索確認を別々のタイムスタンプで保存します。単一の「処理完了」では遅延箇所を特定できません。

pgvectorの公式READMEは、PostgreSQL上のベクトルをSQLで更新・削除できることを示しています^[3]。ただし、DB操作が成功しても、文書抽出、埋め込み生成、キャッシュ、引用表示まで反映したとは限りません。製品機能の確認とRAG全体の鮮度試験を分けることで、「削除APIは成功したが回答には旧版が残る」という不合格を見逃しにくくなります。

全量再索引が必要になる代表条件は、埋め込みモデルまたは次元数の変更、距離関数の変更、チャンク境界アルゴリズムの変更、正規化方式の変更、検索対象テキストの抽出器変更です。フィルター項目を追加しただけでも、過去チャンクへ値が存在しなければバックフィルが必要です。HNSWの構築パラメーターや量子化方式を変える場合も、製品がバックグラウンド再構築に対応するか、二重索引が必要かを版ごとに確かめます。

切替は旧索引を上書きせず、`knowledge-v3`のような新しい物理索引を作り、評価後に読取aliasを切り替える方式が扱いやすいです。索引二重化の容量を見積もれない場合は全量変更を開始しません。再索引中に空き容量が30%を下回る、更新遅延がSLAの2倍を超える、権限メタデータ欠損が1件でも出る、のいずれかを停止条件にします。

権限と引用を保つデータ契約を決める

ベクトルと本文だけを移せても、業務RAGの移行性は確保できません。最低限、`document_id`、`chunk_id`、`source_uri`、`source_revision`、`heading_path`、`char_start`、`char_end`を保存します。さらに、`valid_from`、`valid_to`、`acl_version`、`allowed_principals`、`embedding_model`、`splitter_version`を同じ出力へ含めます。回答画面の引用は、検索時の本文断片から元文書の版と位置へ戻れることが条件です。ページ番号だけでは、HTMLや表計算のようにページ概念を持たない原本を扱えません。

権限境界はコレクション単位だけでなく、文書またはチャンク単位で試します。親文書のACLを子チャンクへ投影し、検索要求に利用者・グループ・テナント・機密区分を渡します。ACLのないチャンクを「全員公開」と解釈すると、取り込み不良が漏えいへ直結します。欠損時の規定値は拒否とし、隔離キューへ送ります。権限付き240問のうち24問は、意味的には最も近いが閲覧不可のチャンクを正解候補の近くへ置き、取得0件を確認します。

required_metadata:
  - document_id
  - chunk_id
  - source_revision
  - acl_version
  - allowed_principals
on_missing_acl: quarantine
delete_key: [document_id, source_revision]
citation_key: [document_id, source_revision, char_start, char_end]
export_format: jsonl

データ契約は製品契約より先に確定します。候補が独自の内部IDしか返さない、スコアの意味を説明できない、ACL情報をエクスポートできない、削除証跡を取得できない場合は、将来の再現試験ができません。引用可能性は回答UIの飾りではなく、検索結果がどの原本・版・範囲に依存したかを追跡する監査要件です。採用製品のAPIから上記項目を一括取得できることを、契約前に1,000件の書き出しで実演します。

3年TCOと契約条件を計算する

ストレージ見積もりは原本サイズから作りません。想定例として1,000万チャンク、1チャンク1,536次元、各要素4バイトのfloat32なら、生ベクトルだけで`10,000,000×1,536×4=61,440,000,000バイト`、十進表記で約61.4GBです。ここへ近似索引、本文、payload、複製、バックアップ、更新中の二重索引が加わります。61.4GBを本番容量と誤認せず、候補ごとの実測係数をPoCで取得します。三重複製と新旧索引の同時保持を単純に掛けるだけでも、生ベクトル相当は約368.6GBになりますが、これは索引等を含まない下限試算です。

月額には、常時ノード、検索・書込ユニット、保存容量、バックアップ、別リージョン複製、データ転送、監視、サポート、埋め込み再生成を含めます。自己運用案には、パッチ、オンコール、障害演習、容量計画の人件費を加えます。想定例で基盤担当0.3人月、1人月120万円なら月36万円、3年で1,296万円です。マネージド料金が月25万円高くても、自己運用が0.3人月から0.05人月へ下がるなら、人件費差30万円/月が上回る可能性があります。これも実績ではなく、社内単価と作業記録で置き換える比較式です。

価格表の最小構成だけで決める調達には、この選定方法は向きません。検索量が予測できない場合は、通常月、繁忙月、全量再索引月の三シナリオを見積もり、上限アラートと強制停止策を確認します。契約上の保存地域や委託先監督が必要なデータを扱うときは、法務・情報セキュリティへ引き継ぎ、技術PoCの合格だけで発注しません。

停止・撤退条件を含む採否表で決裁する

最終表は100点満点だけにしません。まず失格条件を確認し、その後に加点評価を行います。想定配点は検索品質25点、権限・監査20点、鮮度・削除15点、可用性10点、運用性10点、3年TCO10点、移行性10点です。各項目を0〜5で採点し、`項目点÷5×配点`で換算します。たとえば検索品質4、権限5、鮮度3、可用性4、運用性3、TCO4、移行性4なら、20+20+9+8+6+8+8=79点です。ただし権限外1件なら、79点ではなく失格です。

運用開始後の撤退トリガーも同じ表に置きます。品質・運用面では、固定評価192問でRecall@10が0.95未満の状態が二回続く、削除SLA違反が月3件を超える、p95が目標の2倍を5営業日超える、のいずれかで是正計画を開始します。契約面では、3年TCO予測が承認額を20%上回る、重要機能の廃止通知へ移行期限が間に合わない、のどちらかを同じトリガーにします。権限外取得が一度でも起きた場合と復旧不能は即時停止し、それ以外は原因と影響範囲を確認して段階縮小します。

決裁添付には総合点のほか、質問単位の取得結果、負荷区間ごとのpercentile、失敗した要求の生ログ、索引構成、復旧動画、見積前提を含めます。各数値へ`run_id`を付け、再現に必要な製品版、インスタンス型、レプリカ数、データ件数、ベクトル次元、HNSW等の設定を結びます。「デモでは速かった」という記述は証拠にせず、設定を再現できない結果も採点対象外にします。最終候補間の差が3点以内なら、点数の小差ではなく、重大障害からの復旧成功と移行演習の完了を優先します。

乗り換え演習は本番契約の前と年1回に行います。1%の代表データを別環境へ出し、埋め込み、本文、権限、引用位置、削除状態を再構成します。48時間以内という要件なら、ダウンロード時間だけでなく、検証、再索引、alias切替までを含めます。移行できると文書に書いてあることと、担当者が復元できることは別です。復元手順が特定ベンダーの支援なしに完了しない場合は、その依存を費用とリードタイムへ計上します。

選定を始める最初の作業

候補名を集める前に、過去の問い合わせから40問だけを抽出し、正解チャンク、閲覧主体、旧版、回答不能を付けてください。次に、原本件数、想定チャンク数、ピークQPS、更新・削除SLA、RPO/RTOを一枚へ記載します。この40問でExact検索、権限通過率1%、p95、削除反映を計測できない候補は、240問の本PoCへ進めません。小さな予備試験で測定不能な製品を落とすと、比較工程を短縮できます。

参考文献・出典

1. Yu. A. Malkov, D. A. Yashunin「Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs」[原著論文] arXiv:1603.09320、初稿2016年3月30日（参照日: 2026年7月30日）
2. Martin Aumüller, Erik Bernhardsson, Alexander Faithfull「ANN-Benchmarks: A Benchmarking Tool for Approximate Nearest Neighbor Algorithms」[原著論文] 近似近傍探索を品質と性能の交換関係で評価する基準、arXiv:1807.05614、初稿2018年7月15日（参照日: 2026年7月30日）
3. pgvector「README.md」[公式ドキュメント] PostgreSQL上のベクトルデータベース機能、更新・削除、フィルター付き近似検索、反復走査の仕様、master（参照日: 2026年7月30日）
4. OpenSearch Project「Filtering vector search results」[公式ドキュメント] ベクトル検索におけるフィルター方式と、品質・遅延に応じた選択条件、latest、版表記なし（参照日: 2026年7月30日）
5. Qdrant「Filtering」[公式ドキュメント] 版表記なし（参照日: 2026年7月30日）
6. Milvus「Milvus Architecture Overview」[公式ドキュメント] 現行版、版表記なし（参照日: 2026年7月30日）
7. pgvector「CHANGELOG.md」[公式変更履歴] Version 0.8.6、2026年7月29日公開（参照日: 2026年7月30日）