【2026年最新】オンプレミス対応のVector Database比較｜閉域・機密環境での選び方

定義と基本

オンプレミス対応のVector Databaseとは、組織管理下の計算・保存・ネットワーク基盤で、ベクトルの登録と近傍検索を継続運用できる製品です。

「インストール可能」と「機密環境で本番運用可能」は別です。比較表には、外向き通信、依存レジストリ、暗号化、認証連携、データ単位の認可、操作ログ、バックアップ、復旧目標、無停止更新、保守窓口を記載します。DBに細粒度の認可機能が不足する場合は、RAG API側で利用者属性と文書ACLを検証し、検索結果を生成AIへ渡す前に再判定します。

また、ベクトル自体も原文の特徴を含む機密データとして扱います。原文、チャンク、メタデータ、ベクトル、問い合わせ履歴の保存期間と削除経路をそろえ、退職・異動・案件終了時に権限変更が検索結果へ反映されるかを試験します。

公式情報からわかる特徴

2026年8月8日に確認した公式資料では、各候補は導入形態と前提基盤が異なります。以下は公式記載と、そこから導く編集上の判断を分けた整理です。

Qdrant

公式情報：64bitのx86_64／arm64をサポートし、永続化にはPOSIX互換ファイルシステムへのブロックレベルアクセスが必要です。NFSとS3などのオブジェクトストレージは非対応とされ、HTTP、gRPC、分散通信用ポートも明示されています。Private Cloudは準拠Kubernetes、CSIブロックストレージ、導入時のcluster-admin権限を要求し、イメージとHelm chartは閉域内レジストリへミラーできます。

編集上の判断：完全閉域へ搬入する道筋は示されていますが、Operator導入権限、レジストリ同期、CSIスナップショット、証明書、監視を自社で管理できることが前提です。小規模環境やKubernetes非採用組織では、pgvectorの方が運用負担を抑えられる場合があります。

Milvus・pgvector・OpenSearch

公式情報：Milvusは分散・Kubernetesネイティブ構成と単一マシン用Standaloneを提供します。pgvectorはPostgreSQL 13以降の拡張で、近似・完全近傍検索に加え、ACID、PITR、JOINなどPostgreSQLの機能を利用できます。OpenSearchは既存データとベクトルを同居させ、セマンティック検索やRAGを構成できます。

編集上の判断：Milvusは大規模化に強い一方、構成要素と運用範囲を精査すべきです。pgvectorは既存DB統制へ載せやすい反面、巨大規模では性能検証が欠かせません。OpenSearchは全文・日本語検索との統合に適しますが、クラスタ運用経験とリソース設計が必要です。最終選定は、自社データを用いた権限漏れ試験、障害復旧試験、検索品質評価で確定します。

比較と選定ポイント

閉域・機密環境では、検索性能だけでなく、外部通信の遮断可否、認証・認可、監査ログ、バックアップ、障害対応を誰が担うかで選定します。日本語RAGではベクトル検索の精度に加え、形態素解析、キーワード検索、メタデータ絞り込みを組み合わせた検証が必要です。

公式資料上、QdrantはHTTP・監視用の6333、gRPC用の6334、分散通信用の6335番ポートを使用します。完全閉域では、Private CloudのイメージとHelmチャートを内部レジストリへミラーできる一方、搬入、署名・脆弱性確認、更新手順を自社側で整備しなければなりません。Windows上のDocker／WSLマウントにはデータ損失につながる既知のファイルシステム問題があるため、本番候補から外すのが安全です。

稟議前に共通条件で検証する項目

• 日本語の固有名詞、略語、表記揺れを含む質問セットで、ベクトル単独とハイブリッド検索の再現率を比較する
• 部署・案件・機密区分をメタデータとして付与し、検索前後のどちらでアクセス制御を強制するか決める
• 検索API、管理操作、バックアップ取得、権限変更を監査証跡として保存できるか確認する
• 埋め込みモデルやリランキングモデルも閉域配置し、外部APIへ本文・ログが送信されないことを通信試験で確認する

以上から、Kubernetes運用と専用DB化を許容できればQdrant、超大規模な分散処理ならMilvus、PostgreSQLへ統合したいならpgvector、全文検索資産を生かすならOpenSearchが候補です。これは編集上の選定目安であり、製品機能の優劣を断定するものではありません。

導入形態・料金・責任分界

完全閉域ではセルフホストのOSS版またはオンプレミス向け商用構成が中心となり、ライセンス料だけでなく、基盤運用、セキュリティ更新、バックアップ、夜間対応を含む総保有コストで比較します。

料金はノード数、CPU・メモリ、ベクトル件数と次元、レプリカ、量子化、サポート水準で変動します。固定額は置かず、2026年8月8日時点の公式料金表または見積もりで確認してください。特にQdrant Private Cloudのような商用構成は、レジストリ利用、アップグレード支援、障害解析の責任範囲を契約書と運用設計書の双方に明記する必要があります。

最終的な責任分界表には、障害検知、一次切り分け、復旧判断、鍵管理、証明書更新、監査ログ保全、バックアップの復元試験を記載します。「導入できる」ことと「機密環境で継続運用できる」ことを分けて稟議するのが実務上の要点です。

企業導入の設計・実装

閉域・機密環境では、検索性能だけでなく、Embedding生成から検索結果の提示まで通信を境界内に収められるか、誰が基盤を保守するかで候補を絞ります。公式情報確認日：2026年08月08日。

候補の使い分け

• Qdrant：自社インフラでクラウド接続なしの運用が可能です。公式資料は本番用途にKubernetesとPrivate Cloud Enterprise Operatorを推奨し、永続領域にはPOSIX互換のブロックストレージを要求しています。NFSやS3を直接の永続領域にはできないため、既存ストレージ標準との不一致は稟議前に確認します。
• Milvus：分散・Kubernetesネイティブで、大規模な水平拡張を重視する候補です。Standaloneもありますが、分散構成では構成要素と障害点が増えるため、専任の基盤チームを置けない環境では運用負荷を検証します。
• pgvector：ベクトルを既存のPostgreSQLデータと一緒に管理でき、ACID、JOIN、ポイントインタイムリカバリを利用できます。既存DBの権限・監査・バックアップ手順を流用したい中小規模案件では有力ですが、検索負荷が基幹トランザクションを圧迫しないよう分離設計が必要です。
• OpenSearch：Embeddingと既存文書フィールドを同じ索引で扱えます。キーワード検索、絞り込み、運用監視をOpenSearchへ集約済みの企業に適します。一方、Vector Databaseだけを小さく導入したい場合は基盤が過大になり得ます。

データモデルと閉域実装

Embeddingモデル、次元数、正規化方法、距離関数をコレクション単位で固定し、embedding_model_versionをMetadataへ保存します。モデル更新時は同一領域へ新旧ベクトルを混在させず、別コレクションまたは別列へ再生成し、評価後に切り替えます。閉域ではモデル重み、Tokenizer、コンテナイメージ、依存パッケージの持込・署名確認・脆弱性検査まで供給手順に含めます。

チャンクにはdocument_id、chunk_id、版番号、部署、機密区分、公開開始・終了日時、原文位置を付与します。本文だけを細切れにすると規程の例外条件や表題が失われるため、見出しを継承し、表・箇条書き・条文単位を壊さない分割を優先します。サイズは固定値で決めず、日本語の再現率、引用の完全性、応答時間を評価セットで比較します。

日本語検索・セキュリティの実務

日本語RAGでは、ベクトル検索だけに依存せず、日本語対応Embeddingとキーワード検索、権限Filterを組み合わせるのが実務的です。Vector Databaseを認可の最終境界とはせず、アプリケーション、ID基盤、検索基盤の各層で拒否を徹底します。

日本語の検索品質

社内略語、製品型番、人名表記、全半角、旧字体、英数字の大小、複合語を含む質問セットを作り、Recall@kだけでなく「正しい版を引用したか」「権限外文書が候補に入らないか」を測定します。固有名詞や条文番号はベクトルで取りこぼしやすいため、OpenSearchなどの全文検索とのハイブリッド、または検索前の表記正規化を比較します。Embeddingの日本語性能は製品名だけでは判断できないため、自社文書での評価を編集上の選定条件とします。

Payload／Metadataと権限

検索要求には利用者の所属、役職、案件、テナント、機密区分をID基盤から渡し、Payload／Metadataの条件を近傍検索と同時に適用します。検索後にアプリ側で除外する方式は、候補件数、スコア、ログへ権限外情報が残る危険があるため避けます。Filter漏れを防ぐため、無条件検索を許可するサービスアカウントを限定し、未設定時は拒否する設計にします。

Qdrantの既定構成は全環境に十分安全とは限らないと公式資料にも明記されています。HTTP用の6333、gRPC用の6334、分散通信用の6335を用途別に制限し、外部公開しません。認証、暗号化、証明書、秘密情報管理の具体的な対応可否は採用バージョンの公式セキュリティ資料と実機で確認し、ネットワーク隔離だけで代替しないことが重要です。

監視・更新・バックアップ

オンプレミスでは、可用性、パッチ適用、容量管理、監査ログ、復旧試験の責任が利用企業側に残ります。製品比較表には機能の有無だけでなく、担当部署、作業頻度、目標復旧時間、ベンダー支援範囲を記載します。

監視と監査ログ

CPU、メモリ、ディスク使用量、検索レイテンシ、エラー率、レプリカ状態に加え、ベクトル件数、索引作成時間、Filter後の候補不足、Embedding失敗を監視します。Qdrantは6333でヘルス・メトリクスのエンドポイントを提供すると公式資料にありますが、監査要件を満たす操作履歴の範囲は別途確認が必要です。検索者、時刻、文書ID、適用した権限条件、モデル版、回答の引用元を改ざん耐性のあるログ基盤へ送り、質問本文や検索結果を無条件に保存しない方針も定めます。

更新と復旧

更新は検証環境でスキーマ、索引、クライアント互換性、検索品質を確認し、ロールバック条件を決めてから実施します。Qdrant Private CloudではイメージとHelm Chartを内部レジストリへミラーできます。完全閉域では取得端末、マルウェア検査、承認、搬入、ハッシュ照合まで手順化し、Operator導入に必要なcluster-admin権限は常設しない運用を検討します。

バックアップはベクトルだけでなく、Payload、索引設定、モデル、チャンク生成コード、原文との対応表を同じ復旧単位で管理します。Qdrant Private Cloudのバックアップ／復元にはCSIスナップショット対応ストレージが必要です。レプリケーションは誤削除や破損へのバックアップではありません。隔離先から定期的に復元し、RTO・RPO、権限Filter、件数、代表クエリの結果まで確認します。既存PostgreSQLのPITRと監査手順を重視するならpgvectorも比較対象とし、巨大分散検索を優先する場合はMilvus、全文検索運用を統合する場合はOpenSearchを含めて総運用費で判断します。

導入手順

閉域導入では、製品選定より先にデータ境界と運用責任を確定します。以下は稟議から本番運用までの標準的な進め方です。

1. 機密区分と通信境界を定義する
   原文、分割テキスト、ベクトル、検索ログ、バックアップを分類し、外部送信禁止範囲を明記します。埋め込みモデルやLLMも含め、DNS、プロキシ、更新経路まで通信許可表を作成します。
2. 既存基盤から候補を絞る
   PostgreSQLを標準運用しており、業務データとのJOINやPITRを重視するならpgvectorが候補です。OpenSearch運用チームがあるなら、キーワード検索とベクトル検索を同一基盤で扱う案を検討します。大規模な分散検索ではMilvus、専用Vector Databaseを比較的明確な構成で運用したい場合はQdrantを候補にします。
3. 閉域で取得可能な成果物を確認する
   コンテナ、Helm chart、依存パッケージ、モデルを承認済みレジストリへミラーし、ハッシュとSBOMを管理します。Qdrant Private Cloudの公式資料では、標準準拠Kubernetes、Helm、Operator導入時のcluster-admin権限が必要で、公式レジストリのイメージとchartは自組織レジストリへミラー可能とされています。
4. 日本語RAGの評価セットを作る
   社内略語、表記揺れ、製品番号、日付を含む質問と正解文書を用意します。ベクトル検索だけでなく、キーワード検索、メタデータ絞り込み、ハイブリッド検索をRecall、誤回答率、応答時間で比較します。日本語精度はDB単体ではなく、埋め込みモデルと分割方法にも左右されます。
5. 認証・認可と監査を設計する
   利用者から検索APIへ直接接続させず、RAGアプリ側で部署・案件・機密区分を検証し、同じ条件を検索フィルターへ強制適用します。管理操作、検索条件、参照文書ID、設定変更を監査対象にし、本文や質問をログへ残す場合はマスキング方針を決めます。
6. 障害・性能試験を行う
   想定件数、次元数、payload、複製数、量子化を反映して測定します。Qdrantは公式上、永続化にPOSIX互換のブロックストレージを必要とし、NFSやS3は非対応です。HTTP用6333、gRPC用6334、分散構成用6335の通信も必要最小限に制限します。
7. 復旧可能性を確認して本番化する
   バックアップ取得だけでなく、別環境への復元、インデックス再構築、モデル更新時の再埋め込みを試験します。RPO・RTO、脆弱性対応期限、容量増設、証明書更新、障害時の製品ベンダーと自社の分担を運用手順書へ記載します。

向くケース・向かないケース

最適解は検索性能だけでなく、既存の運用能力と閉域制約で変わります。

向くケース

• Qdrant：Kubernetes上で専用Vector Databaseを運用でき、ブロックストレージを確保できる環境。完全な自社基盤向けには公式がPrivate Cloud Enterprise Operatorを案内しています。
• Milvus：多数ベクトルを水平分散し、Kubernetesを含む複数コンポーネントの監視・復旧を担える組織。公式リポジトリでは分散構成と単一マシン向けStandaloneの双方が示されています。
• pgvector／OpenSearch：既存PostgreSQLのACID、JOIN、PITRを生かす場合はpgvector、既存の全文検索やフィルターと統合する場合はOpenSearchが有力です。

向かないケース

• Qdrantは、永続領域がNFSまたはオブジェクトストレージに限定される環境には適しません。KubernetesやOperatorを維持できない場合も、Private Cloudよりpgvectorなど既存基盤への統合を優先します。
• 小規模RAGで専任運用者がいない場合、分散構成は過剰になり得ます。逆に十億件級などの要件では、単一ノード前提の簡易構成だけで判断せず実測が必要です。

導入前チェックリスト

一つでも未決定なら、製品契約や本番データ投入の前に責任者を設定します。

1. 原文、ベクトル、ログ、バックアップの機密区分と保管期限が決まっている
2. 埋め込みモデル、LLM、ライブラリが外部通信せず閉域内で動作する
3. 部署・案件単位のアクセス条件を検索時に強制でき、迂回経路を試験した
4. SSO、サービスアカウント、秘密情報の保管・ローテーション方法が決まっている
5. 管理操作、検索、設定変更を監査し、時刻同期とログ改ざん対策を行える
6. 対応CPU、メモリ、ブロックストレージ、必要ポートを公式要件と照合した
7. 更新用イメージ、chart、モデルの搬入・署名検証・脆弱性検査手順がある
8. 復元試験、容量監視、再埋め込み、障害連絡を担当する部署が明確である

結論

閉域・機密環境では、Vector Databaseの機能差より、ストレージ制約、成果物の搬入、権限分離、監査、復旧を自社が継続して担えるかが重要です。Qdrantは有力候補ですが、NFS前提やKubernetes運用が困難な環境には不向きです。pgvector、OpenSearch、Milvusを既存基盤と規模に応じて比較し、日本語の実データで判断してください。

公式情報確認日：2026年08月08日。製品要件や提供条件は変更され得るため、導入時点の公式資料と契約条件を再確認してください。

一次情報・参考リンク

• Qdrant Installation
• Qdrant Private Cloud
• Milvus Documentation
• pgvector GitHub
• OpenSearch Vector Search