この記事で分かること／分からないこと
- 分かること: 主要なベクトルDBがマルチテナントをどう実現しているか(公式ドキュメントで確認できた範囲)
- 分かること: 「テナントごとに完全に分ける」方式が、公式ドキュメント上どう位置づけられているか
- 分かること: 自社がテナント単位で索引を分けている構成と、それがベクトルDBの方式とどう違うか
- 分からないこと: 自社のテナント数・テナントあたりのデータ量で、どの方式の総コストが低いか
自社の構成: テナントIDで索引を分けている
編集部の自社RAG基盤は、実行時に触るのが確定配信用の索引(D1の faqs テーブル)だけで、その索引をテナントIDで分けている(出所: /home/sol/convai-platform/docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。原本と生成物はテナント別のパスでR2に置く。テナント間の分離は、最初から別の索引を引くことで担保している。
ただしこれはベクトルDBではない。有界ドメインのため索引による確定配信で足りているという前提があり(そもそもベクトルDBが要らない場合参照)、ベクトル検索でのテナント分離について自社の実測は持っていない。以下はベクトルDB各社の公式ドキュメントで確認できた方式の整理である。
方式1: テナントごとに物理的に分ける
Weaviateのマルチテナントのドキュメントは、各テナントが別々のシャードに保存され、あるテナントに保存されたデータは別のテナントからは見えない、と説明している。多数の利用者にサービスを提供する場合に向く方式として位置づけられている。テナントの自動作成はバッチ投入時のみ利用でき、名前の表記ゆれがあると意図せず別テナントが作られうるため注意が要る、という趣旨の記述もある。テナントには活動状態(activity status)を指定でき、使っていないテナントを休止させる仕組みがある(出所: https://weaviate.io/developers/weaviate/manage-collections/multi-tenancy 、確認日2026-09-06)。
物理的に分ける方式は、分離の保証が分かりやすい一方で、テナント数が増えたときの管理単位がそのまま増える。
方式2: 1つの入れ物に入れて、属性で仕切る
Qdrantのマルチテナントに関するガイドは、テナントごとにコレクションを作るのは効率的でないことが多いと明言している。理由は、各コレクションが資源のオーバーヘッドを持つため、多数のコレクションを作るとすぐに高くつくからである。代わりに、1つのコレクションに複数テナントを入れ、いくつかの方式で分離することを勧め、コレクションを分けるのは「厳密な分離が必要なテナントが少数の場合」に限る、と位置づけている(出所: https://qdrant.tech/documentation/guides/multiple-partitions/ 、確認日2026-09-06)。
Milvusは Partition Key という仕組みで、特定の属性をキーにしてデータをパーティションに分け、検索時にそのキーで探索範囲を狭める(出所: https://milvus.io/docs/use-partition-key.md 、確認日2026-09-06)。Pineconeは名前空間(namespace)を持ち、投入時に自動で作られる(出所: https://docs.pinecone.io/guides/index-data/indexing-overview 、確認日2026-09-06)。
いずれも「1つの入れ物の中で仕切る」方式で、テナント数が増えても管理単位は増えにくい。代わりに、仕切りの実装がアプリケーション側の責任になる部分が出てくる。
どちらを選ぶかは、テナント数と分離の強さで決まる
公式ドキュメントの位置づけを並べると、判断軸は2つに絞れる。1つはテナント数で、少数なら物理的に分けても管理できるが、多数になると Qdrant のガイドが言うように固定費が効いてくる。もう1つは分離の強さで、規制や契約で「別の入れ物であること」自体が要求されるなら、属性で仕切る方式では説明が難しい。
自社の構成は、テナント数が100を超える規模で索引をテナントIDで分けている(F2b: 有界ドメインの107テナント、出所: services/verifier/out/ucaro-verification.json、確認日2026-09-06)。これはベクトルDBの「1つに入れて属性で仕切る」方式に近い発想だが、ベクトル索引ではなく確定配信用の索引である点で仕組みが異なる。なお107という数は自社で構築したテナント数であり、顧客数を示すものではない。
分ける単位を増やしたときの固定費は規模で何が変わるかで、仕切りの絞り込みが検索の速さに与える影響はレイテンシ要件から決めるで扱う。
よくある質問
Q1. テナントごとにコレクションを分けるのが一番安全ではないのか
分離の保証は分かりやすいが、Qdrantのガイドは、各コレクションが資源のオーバーヘッドを持つため多数作ると高くつくとして、この方式を効率的でないことが多いと位置づけている。厳密な分離が必要なテナントが少数の場合に限る、というのが公式の見解である。
Q2. 1つに入れて仕切る方式で、他のテナントのデータが混ざる心配はないか
仕切りの実装がアプリケーション側の責任になる部分がある。Weaviateのように各テナントを別シャードに置く方式は、あるテナントのデータが別のテナントから見えないことをデータベース側が担保する。どちらの方式でも、テナントの指定漏れが起きない設計をアプリケーション側で持つ必要がある。
Q3. テナント数が増えたら方式を変える必要があるか
公式ドキュメントの位置づけから読む限り、少数なら物理的に分けても管理でき、多数になると1つに入れて仕切る方式の方が固定費で有利になる。ただしどこが境目かは自社のテナントあたりのデータ量と運用体制で変わる。
Q4. 自社ではどう分離しているのか
編集部の自社RAG基盤は、確定配信用の索引をテナントIDで分け、原本と生成物もテナント別のパスに置いている。ただしベクトルDBではなく、有界ドメインだから索引で足りている構成である。ベクトル検索でのテナント分離について自社の実測は持っていない。
テナント分離は後から変えにくい設計判断である。自社のテナント数と要件でどの方式が合うか相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシをどこで測るか
- 関連記事: レイテンシ要件から決める
- 関連記事: 規模で何が変わるか
- 関連記事: そもそもベクトルDBが要らない場合