【2026年最新】QdrantをDockerで構築する方法｜本番運用前の設定も解説

定義と基本

Qdrantは、ベクトルと付随する属性を保存し、類似検索や条件付き検索を提供するベクトルデータベースです。

Docker構築では、コンテナを消してもデータが残るように/qdrant/storageを永続ボリュームへ割り当てます。HTTP APIは6333番、gRPC APIは6334番、分散構成のノード間通信には6335番を使用します。単一ノード検証で6335番をホストへ公開する必要はありません。

RAG用途では、Qdrant自体が日本語の意味を理解するわけではありません。検索品質は埋め込みモデル、正規化、チャンク分割、検索件数、再ランキングに左右されます。社内文書で正解集合を作り、部署・機密区分・公開期間などのペイロード条件が確実に適用されるかもテストします。

公式情報からわかる特徴

公式資料から確認できる結論は、Dockerコンテナが主にテスト・開発向けの導入手段であり、セルフホスト環境は初期状態のまま本番投入できないという点です。

公式Installationでは64ビットのx86_64/amd64とAArch64/arm64をサポートし、永続領域にはPOSIX互換ファイルシステムへのブロックレベルアクセスが必要とされています。NFSなどのネットワークファイルシステムやS3などのオブジェクトストレージはデータ領域として利用できません。WindowsのDockerまたはWSLでのマウントには、データ損失につながる既知のファイルシステム問題があるため、本番候補から外す判断が安全です。

Securityでは、セルフホスト版にAPIキー認証、ネットワークバインド、TLS、監査ログを明示設定するよう推奨しています。管理用、全体の読み取り専用、コレクション単位で読み書きを制限するキーが示されているため、RAGアプリへ管理キーを渡さない設計が可能です。設定可否だけでなく、キーの保管・失効・ローテーションと監査ログの集中保管を運用手順に落とし込みます。

Snapshotsによるコレクション単位のアーカイブには、データ、設定、ポイント、ペイロードが含まれますが、コレクションエイリアスは含まれません。分散構成ではノードごとに作成が必要です。したがって、スナップショット取得をバックアップ完了とみなさず、エイリアスなどの周辺設定も別途記録し、障害時に所定時間内で復元できるか検証する必要があります。以上は2026年8月12日確認の提示公式資料に基づき、具体的な可用性水準や採用判断は各社要件に応じた編集上の評価です。

比較と選定ポイント

Docker単体は検証や小規模な閉域環境に適しますが、可用性、監査、バックアップまで求める本番環境では、KubernetesまたはQdrant Cloudを含めて比較すべきです。選定時はベクトル件数だけでなく、次元数、Payloadとそのインデックス、レプリケーション、量子化、障害復旧目標を条件にします。

公式資料上、永続ストレージにはブロックレベルでアクセスできるPOSIX互換ファイルシステムが必要です。NFSなどのネットワークファイルシステムやS3などのオブジェクトストレージはデータ領域に使えません。ディスクへベクトルを退避する構成ではSSDまたはNVMeが推奨され、Windows上のDocker／WSLのマウントにはデータ損失につながる既知の問題があるため、本番候補からは外す判断が安全です。

日本語RAGでは、ベクトルDBだけで検索品質は決まりません。日本語対応の埋め込みモデル、文書分割、表記揺れ、メタデータ絞り込み、再ランキングを同一データセットで評価します。厳密なキーワード一致や複雑な全文検索が中心ならOpenSearch等との併用も候補です。部門別閲覧制御は、Qdrantのコレクション単位・読み書き範囲を持つAPIキーだけで要件を満たせるか、アプリケーション側の認可と併せて設計してください。

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

Docker版は利用開始が容易でも、無償で運用できることを意味しません。サーバー、SSD、バックアップ保管先、監視、証明書、障害対応工数を含む総保有コストで、CloudやKubernetes構成と比較します。料金や提供機能は変更されるため、2026年8月12日時点の公式料金計算ツール、契約資料、見積書で確認し、固定額を前提に稟議しないことが重要です。

セルフホスト版は初期状態で全ネットワークインターフェースに公開され、認証も設定されないため、そのまま本番投入できません。開発時は127.0.0.1、運用時はプライベートIPへバインドし、6333のHTTP、6334のgRPC、分散構成で使う6335の到達範囲を最小化します。管理用、参照専用、コレクション別の鍵を分離し、秘密情報管理基盤でローテーションします。

スナップショットは特定時点のコレクションデータと設定を含みますが、分散構成ではノードごとに取得が必要で、コレクションエイリアスは含まれません。したがって、取得成功だけでなく、別環境への復元、エイリアス再作成、RPO・RTOの達成を定期試験します。機密文書を扱う場合は、バックアップの暗号化、保管国、削除期限、操作ログまで責任分界表に明記してください。

企業導入の設計・実装

Dockerは検証環境を短時間で作る用途に適しますが、本番化では永続ストレージ、ネットワーク分離、認証、TLS、復旧手順までを一体で設計します。公式資料では、コンテナ実行は主にテスト・開発向けとされ、自己管理の本番環境にはKubernetesとPrivate Cloud Enterprise Operator、またはマネージドサービスが案内されています。

検証環境から本番へ移す条件

Qdrantのデータディレクトリである/qdrant/storageをDockerの名前付きボリュームまたはホストのブロックストレージへ永続化し、コンテナ削除後もコレクションが残ることを確認します。公式要件ではPOSIX互換ファイルシステムへのブロックレベルアクセスが必要で、NFSやS3を直接データ領域にはできません。Windows上のDocker／WSLによるマウントはデータ損失につながる既知の問題があるため、企業検証でもLinux VMを優先するのが安全です。

• ポート：HTTP・監視用の6333、gRPC用の6334だけを利用元から許可する。6335は分散構成のノード間通信に限定する。
• 容量：ベクトル件数、次元数、Payload索引、レプリケーション、量子化を含めて見積もる。ディスク退避を使う場合はSSDまたはNVMeを候補とする。
• 構成管理：イメージのタグまたはダイジェストを固定し、設定ファイル、Compose定義、コレクション定義をGitで版管理する。秘密鍵やAPIキーは登録しない。

編集上の判断として、単一ホストのDocker Composeは障害点が集中するため、小規模な社内検索や性能検証までに留めるのが妥当です。既存のRDBと一体で管理したい小規模案件ならpgvector、キーワード検索やログ分析を主軸にするならOpenSearch系も比較対象になります。

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

日本語RAGの品質はQdrant単体では決まらず、Embeddingモデル、チャンク境界、Payload設計、権限Filterを同じ評価データで検証します。機密文書では「検索できること」より先に「権限外の候補を取得しないこと」を受入条件にします。

Embeddingとチャンクの基準

日本語対応を明示したEmbeddingモデルを選び、社内略語、製品型番、漢字表記揺れ、英数字混在の質問でRecall@kなどを比較します。チャンクは見出しや段落を壊さず、編集上の初期値として400〜800トークン程度から評価し、表や規程条文は意味単位を優先します。モデル変更時はベクトル次元や意味空間が変わるため、同一コレクションへの混在を避け、別コレクションを作って切り替えます。

Payloadにはdocument_id、chunk_id、版、言語、部署、機密区分、tenant_id、閲覧可能グループ、原文更新日時を保持します。Filter対象の項目だけに索引を付け、本文、個人番号、認証情報など不要な機密データは格納しません。

認証と権限境界

公式資料によると、自己ホスト版は既定で全ネットワークインターフェースから到達でき、認証も有効ではありません。本番前にプライベートIPへバインドし、APIキー、TLS、監査ログを明示的に設定します。参照専用サービスにはread-onlyキー、更新処理には対象コレクションを限定したgranular access API keyを割り当て、管理キーをアプリへ配布しない構成にします。

コレクション単位のキーだけでは文書単位の社内権限を代替できません。アプリまたは検索ゲートウェイで利用者の所属を認証し、tenant_idと閲覧グループのFilterを全検索へ強制します。クライアント任意のFilterに任せず、権限なし検索、退職者、部署異動、キャッシュ経由を含むテストを実施します。

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

運用では、Qdrantの死活だけでなく検索遅延、失敗率、ディスク残量、索引作成、取り込み遅延、認可拒否を監視し、スナップショットからの復旧を定期的に実演します。6333にはヘルスチェックとメトリクスのエンドポイントも含まれるため、監視基盤だけから到達可能にします。

ログと更新

Qdrantの監査ログにはAPI操作を記録し、リバースプロキシでは接続元、応答コード、所要時間、リクエストIDを残します。質問文、検索結果本文、Payloadを無条件に出力すると機密情報が複製されるため、本文はマスキングし、利用者IDは追跡可能な仮名化値とします。ログの保存期間、閲覧権限、改ざん検知、SIEM転送も監査要件に合わせます。

更新時はリリースノートと互換性を確認し、イメージを段階的に更新します。検証環境で既存スナップショットの復元、代表検索、Payload Filter、Embedding投入を再実行し、本番更新直前に追加バックアップを取得します。単一ホストでは停止時間とロールバック条件を稟議時に明記します。

復旧可能なバックアップ

公式のコレクションスナップショットは、特定時点のデータ、コレクション設定、ポイント、Payloadを含むtarアーカイブです。ただしエイリアスは含まれません。分散構成では各ノードが保持するデータだけが対象となるため、コレクションごと・ノードごとに取得し、対応関係を台帳化します。

スナップショットはコンテナと別の障害ドメインへ暗号化して保管し、世代管理とハッシュ検証を行います。ボリュームの稼働中コピーだけをバックアップとみなさず、RPOに応じて原文、Embeddingモデル名、投入ジョブの再実行情報も保存します。四半期など定期的に空の環境へ復元し、件数、Filter、エイリアス再設定、代表検索まで確認して初めて「復旧可能」と判定します。

導入手順

まずDockerで検証環境を作り、検索品質を確認してから、永続化・認証・TLS・監査・バックアップを段階的に追加します。以下は公式情報を2026年8月12日に確認した手順です。

1. 要件と保存先を確認する

   64bitのx86_64/amd64またはarm64環境を用意します。永続領域にはPOSIX互換ファイルシステムを持つブロックストレージが必要です。公式資料ではNFSやS3などをQdrantの直接の保存先にできません。性能を重視する場合はSSDまたはNVMeを選びます。

2. ローカル限定でコンテナを起動する

   検証時も外部公開を避け、ホスト側を127.0.0.1へバインドします。イメージタグはlatestで固定せず、評価済みバージョンへ置き換えてください。

   docker run -d --name qdrant 
     -p 127.0.0.1:6333:6333 
     -p 127.0.0.1:6334:6334 
     -v qdrant_storage:/qdrant/storage 
     qdrant/qdrant:<検証済みバージョン>

   6333はHTTP API、ヘルスチェック、メトリクス、6334はgRPCです。分散構成で利用する6335を単一ノード検証で公開する必要はありません。

3. 永続化と再起動を検証する

   コレクションと少量の日本語文書を登録し、コンテナ再起動後も検索できることを確認します。Windows上のDockerまたはWSLのマウントにはデータ損失につながる既知のファイルシステム問題があるため、本番保存先として採用する場合は個別検証が必要です。

4. RAGの検索品質を測る

   埋め込みモデルの次元数とコレクション設定を一致させ、社内略語、表記揺れ、長文、アクセス禁止文書を含む評価質問を作ります。Qdrantの導入だけで日本語精度が決まるわけではなく、分割方法、埋め込みモデル、フィルタ、再ランキングも比較します。

5. 認証と権限を設定する

   セルフホスト版は初期状態で認証がなく、到達可能な利用者から操作され得ます。本番前にAPIキーを有効化し、管理用、参照専用、コレクション単位の権限を用途別に分けます。キーはComposeファイルやGitへ直書きせず、シークレット管理基盤から注入します。

6. 閉域化、TLS、監査を追加する

   接続元をRAG APIや運用端末に限定し、プライベートIPへのバインド、ファイアウォール、TLSを設定します。TLS終端をQdrant本体とリバースプロキシのどちらで行うかは責任分界を明確にします。監査ログはAPI操作、時刻、主体、結果を追跡できるか確認し、保管期間と閲覧権限も定めます。

7. スナップショットと復元を試す

   コレクション単位のスナップショットを定期取得し、別ストレージへ退避します。分散構成ではノードごとに作成が必要で、コレクションエイリアスは含まれません。取得成功だけでなく、隔離環境への復元、RPO・RTO、暗号化、削除手順までテストします。

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

Docker構成は、RAGの技術検証、小規模な部門環境、既存のコンテナ運用基盤へ組み込む場合に向きます。メタデータによる絞り込みを使い、文書区分や部署権限を検索時に適用したい案件でも候補になります。

一方、単一コンテナのまま高可用性、無停止更新、厳格な監査を求める本番には向きません。運用人員が少ない場合はQdrant Cloudなどのマネージドサービス、閉域かつ大規模な自己運用ではKubernetes向け構成も比較します。全文検索中心ならOpenSearch、既存RDBとの統合を優先するならpgvectorも含め、精度、費用、障害対応負荷で判断すべきです。

導入前チェックリスト

1. ベクトル件数、次元数、payload、索引、レプリケーションを基にCPU・メモリ・容量を見積もったか
2. 永続領域がPOSIX互換のブロックストレージで、容量監視とI/O性能試験を行えるか
3. 6333・6334・6335のうち必要なポートだけを許可しているか
4. 管理、登録、検索のAPIキーとコレクション権限を分離したか
5. 機密文書の分類、保持期限、削除、個人情報マスキングを設計したか
6. TLS証明書の発行、更新、失効とシークレットのローテーション担当が決まっているか
7. 監査ログの送信先、改ざん防止、保存期間、アラート条件を定めたか
8. スナップショット、エイリアス、アプリ設定を含む復旧手順を実地確認したか
9. 日本語評価データで再現率、応答時間、誤検索、権限漏れを測定したか

結論

QdrantのDocker導入は、ローカル限定公開と永続ボリュームから始めればRAG検証を素早く進められます。ただし本番化の判断基準は起動可否ではなく、認証、最小権限、閉域化、TLS、監査、復元試験を継続運用できるかです。日本語検索品質と権限漏れを実データに近い評価セットで測り、自己運用の負荷が見合わなければCloud、Kubernetes、他製品も比較してください。

一次情報・参考リンク

• Qdrant Installation
• Qdrant Security
• Qdrant Snapshots