この記事で分かること／分からないこと
- 分かること: 主要なベクトルDBが提供している絞り込みの仕組み(公式ドキュメントで確認できた範囲)
- 分かること: 絞り込みを強くするほど検索結果の件数が減る構造と、その対策
- 分からないこと: 自社のデータで、どの程度の絞り込みまで実用的な件数が返るか(索引の設定と分布に依存する)
- 分からないこと: 各サービスの絞り込み処理の内部実装の細部
編集部の自社RAG基盤は、ベクトル検索ではなく索引による確定配信で、テナントIDで索引を分けている(出所: /home/sol/convai-platform/docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。これは「絞り込み」というより最初から別の索引を引く構成であり、本稿で扱うベクトル検索の絞り込みとは仕組みが違う。ベクトルDBの絞り込みについて自社の実測は持っていない。
絞り込みは「条件式」として書く
主要なベクトルDBは、ベクトルの類似度検索にメタデータの条件を重ねる機能を持つ。Pineconeの公式ドキュメントは、クエリにメタデータのフィルタ式を付ける方法を示しており、等値($eq)などの演算子を組み合わせて条件を書く(出所: https://docs.pinecone.io/guides/search/filter-by-metadata 、確認日2026-09-06)。
Weaviateのフィルタのドキュメントは、条件で結果集合にオブジェクトを含めたり除外したりできること、Filter.and() Filter.or() Filter.not() で条件を組み合わせられることを説明している(出所: https://weaviate.io/developers/weaviate/search/filters 、確認日2026-09-06)。
Qdrantのフィルタリングのドキュメントは、ペイロード(メタデータ)に対する条件を扱い、配列の中の各要素を独立に評価するネストしたフィルタや、値が欠けているレコードを除外する条件についても記述している(出所: https://qdrant.tech/documentation/concepts/filtering/ 、確認日2026-09-06)。
書き方はサービスごとに違うが、「ベクトルの近さ」と「属性の一致」を同時に指定する、という点は共通している。
絞り込むほど、返ってくる件数が減る
ここが選定で見落とされやすい。pgvectorのREADMEは、HNSW索引で取得できる結果の件数が ef_search(既定値40)に制限されること、そしてクエリの絞り込み条件によって、結果がさらに少なくなりうることを明記している。対策として iterative index scans を有効にすると、必要に応じて索引を追加で走査する、と書かれている(出所: https://raw.githubusercontent.com/pgvector/pgvector/master/README.md 、確認日2026-09-06)。
理由は単純で、索引はまず「近いベクトル」を上位から取り、その後に絞り込み条件で落とすと、条件に合うものが上位に少なければ結果が足りなくなる。絞り込み条件が厳しいほど、この現象は起きやすい。「部署Aの文書だけから上位10件」を頼んだのに3件しか返らない、という症状の原因はこれである。
絞り込みを速くするには、絞り込み用の索引が別に要る
Qdrantの索引のドキュメントは、ペイロード索引が絞り込みを速くすること、ペイロード索引は従来の文書指向データベースの索引に似ていることを述べている(出所: https://qdrant.tech/documentation/concepts/indexing/ 、確認日2026-09-06)。つまりベクトル索引とは別に、メタデータ側にも索引を持つ設計になっている。
Milvusは別のアプローチとして、特定のスカラー属性を Partition Key に指定し、検索時に絞り込み条件を与えると探索範囲がいくつかのパーティションに狭まる、という仕組みを提供している(出所: https://milvus.io/docs/use-partition-key.md 、確認日2026-09-06)。絞り込みを「後で落とす」のではなく「最初から探す範囲を狭める」方式である。
どちらの方式でも、絞り込みに使う属性を事前に決めておく必要がある。後から「この属性でも絞りたい」となると、索引の追加やパーティションの切り直しが要る。
絞り込みの設計で避けたいこと
Weaviateのドキュメントは、相互参照(cross-reference)先のプロパティで絞り込むときの書き方を示しつつ、相互参照はできるだけ避けるようにデータのスキーマを見直した方がよい、という趣旨の注意を添えている(出所: https://weaviate.io/developers/weaviate/search/filters 、確認日2026-09-06)。絞り込み条件が別のオブジェクトをまたぐと、性能と複雑さの両方で不利になる。
絞り込みが要るかどうかを判断する順序としては、まず「絞り込まずに全体から探して、結果を後で分ける」で済むかを考える。次に、絞り込みが要るなら、その属性は少数で固定できるかを確認する。固定できるなら Partition Key やテナント分離のように「探す範囲を先に狭める」方式が向く。属性が多く変わるなら、ペイロード索引を持てるサービスの方が扱いやすい。テナント単位の分離はマルチテナントの分け方で扱う。絞り込みが検索の速さに与える影響はレイテンシ要件から決めるで扱う。
よくある質問
Q1. メタデータで絞り込むと検索結果が少なくなるのはなぜか
索引がまず近いベクトルを上位から取り、その後に条件で落とす構造だからである。pgvectorのREADMEは、HNSW索引の結果件数が ef_search(既定値40)に制限され、絞り込み条件でさらに減りうると明記し、対策として iterative index scans を挙げている。
Q2. 絞り込みを速くするにはどうすればよいか
Qdrantのようにメタデータ側にペイロード索引を持つ方式と、Milvusの Partition Key のように探す範囲を最初から狭める方式がある。どちらも、絞り込みに使う属性を事前に決めておく必要がある。
Q3. どのサービスでも同じように絞り込めるのか
書き方は違う。Pineconeは演算子付きのフィルタ式、Weaviateは and / or / not で組み合わせるフィルタ、Qdrantはネストや欠損値の扱いまで含むペイロードフィルタを提供している。共通しているのは、ベクトルの近さと属性の一致を同時に指定する点である。
Q4. 自社ではどう絞り込んでいるのか
編集部の自社RAG基盤はベクトル検索ではなく、テナントIDで分けた索引を直接引く確定配信である。絞り込みというより最初から別の索引を引く構成で、ベクトルDBの絞り込みについて自社の実測は持っていない。
絞り込みの要否は、データを入れてから気づくと索引の作り直しになる。自社の要件でどう設計すべきか相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシをどこで測るか
- 関連記事: マルチテナントの分け方
- 関連記事: レイテンシ要件から決める
- 関連記事: そもそもベクトルDBが要らない場合