【2026年最新】Qdrant Cloudの料金と構成｜見積もり前の確認事項

定義と基本

Qdrant Cloudは、ベクトル検索エンジンQdrantのクラスタを、運用機能とともに利用するクラウドサービスです。

Qdrantは、埋め込みモデルで生成したdense vectorの類似度検索を中心に、payload条件による絞り込み、sparse vector、全文検索、複数検索の融合や再ランキングを扱えます。RAGでは、文書を分割してベクトルとメタデータを登録し、質問に近いTop-Kの断片をLLMへ渡す検索基盤として利用します。

見積もり用の入力表には、文書数ではなく、チャンク化後のベクトル総数、次元数、1件当たりpayload量、索引対象項目、月間増加量を記載します。検索負荷についても、平均・ピークQPS、同時更新、Top-K、フィルタ条件、目標応答時間を測定します。量子化やディスク配置は費用削減の候補ですが、検索品質や遅延への影響をベンチマークせず採用すべきではありません。

公式情報からわかる特徴

公式資料で確認できるのは、Managed CloudがAWS、GCP、Azureで提供され、水平・垂直スケーリング、自動シャード再配置、リシャーディング、バックアップと災害復旧、監視・ログ・アラート、監査ログ、高可用構成の自動フェイルオーバーに対応する点です。接続にはAPIキーを使用し、HTTPとgRPCのインターフェース、複数言語の公式クライアントが用意されています。

また、Qdrant Cloudではサーバー側のCloud Inferenceを選択でき、クライアント側で埋め込みを生成する構成も可能です。ただし、推論料金やモデル条件をデータベース料金と同一視せず、最新の料金表示で別途確認してください。自社インフラを接続するHybrid Cloudや、クラウド接続を避けるPrivate Cloud構成も公式の選択肢です。

一方、公式資料に機能名があることは、自社の閉域要件や監査基準への適合を保証しません。編集上の判断として、見積もり前にネットワーク方式、暗号化、権限粒度、監査ログの対象・保持・外部転送、障害時RTO／RPOを質問票で確認すべきです。小規模でキーワード検索が中心、または既存DBのベクトル機能で要件を満たせる場合は、専用クラスタを増やさない構成のほうが安価で運用も単純になる可能性があります。

比較と選定ポイント

結論として、運用負荷を抑えるならQdrant Managed Cloud、データ配置やネットワーク統制を優先するならHybrid Cloudまたは閉域内の自己運用が候補です。ただし、既存の検索・DB基盤で要件を満たせる場合は、OpenSearch系やpgvectorも含めて比較すべきです。

検索品質は日本語の評価セットで決める

公式資料で確認できるQdrantの機能には、類似検索、payloadによる絞り込み、dense・sparseのハイブリッド検索、全文検索、再ランキングがあります。一方、「日本語なら自動的に高精度」という意味ではありません。埋め込みモデル、分割単位、固有名詞・型番への対処、Top-K、メタデータ品質が結果を左右します。

編集上の推奨は、社内質問50～200件程度に正解文書と閲覧権限を付け、再現率、上位精度、応答時間、権限漏えい件数を候補ごとに測ることです。部署・案件・機密区分をpayload filterで絞れても、認証情報から条件を生成する処理はアプリケーション側の設計事項です。LLMへ渡す前にも権限を再検査し、検索ログには質問文や本文が残り得る点を監査部門と確認します。

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

Qdrant Cloudの見積もりは、ベクトル件数だけでは確定しません。CPU、メモリ、ベクトル次元、payloadとその索引、ストレージ、レプリケーション、量子化、バックアップ、リージョン、通信量、推論機能、サポート条件を整理し、最新の公式料金画面と契約見積もりで確認してください。固定月額は構成や料金改定で変わるため、ここでは断定しません。

見積もり前に渡す数値

平均・最大のベクトル件数、次元数、1件当たりpayload容量、索引対象項目、月間追加・削除量、ピークQPS、許容p95遅延、レプリカ数、保存期間を提示します。公式Cloud Pricing Calculatorは概算に使えますが、公式資料上、payloadや索引データを含まない計算である点に注意が必要です。Cloud Inferenceを使う場合も、対象モデル、処理量、データ送信条件、最新課金を別途確認します。

自己運用ではライセンス費だけでなく、三つの通信ポート、POSIX互換のブロックストレージ、SSD／NVMe、監視要員、夜間障害対応まで含めて比較します。NFSやS3を永続ストレージとして直接使う前提は公式要件と合いません。PoC価格ではなく、冗長化した本番、検証、災害復旧環境を含む3年間の総保有コストで稟議するのが安全です。

企業導入の設計・実装

見積もり前に固定すべき項目は、ベクトル件数・次元数、Payloadとそのインデックス、レプリケーション、保存方式、量子化、ピーク時の検索・更新負荷です。公式資料では、CPU・メモリ要件がこれらの条件で変わると説明されています。Cloud Pricing Calculatorの試算にはPayloadやインデックスのデータ量が含まれないため、計算結果をそのまま予算額にしないでください。

件数は文書数ではなくチャンク数で見積もる

1万文書でも、平均20チャンクなら最低20万ポイントです。さらに本文、タイトル、権限、版番号などのPayload、dense・sparseの複数ベクトル、複製分が加わります。稟議では「文書数×平均チャンク数×年間増加率×保持年数」を示し、再取り込み中の一時的な二重保有も容量に含めます。

編集上の推奨は、日本語の社内規程なら見出し単位を優先し、初期値として本文400〜800文字程度、前後10〜20％の重複から評価する方法です。ただし表、FAQ、契約条項を一律に分割すると意味が崩れます。固定長だけで決めず、回答根拠の欠落率と検索上位件数を検証してください。

Embedding変更を前提にCollectionを分ける

Embeddingモデル、次元数、正規化方法、距離指標は登録時と検索時で一致させます。Qdrant Cloudではサーバー側のCloud Inference、クライアント側ではFastEmbedなどを利用できますが、推論料金、利用可能リージョン、データの送信範囲は契約前に個別確認が必要です。モデル更新時は既存Collectionを直接置換せず、新Collectionへ再Embeddingし、評価後に参照先を切り替える設計が安全です。

各ポイントのPayloadには、document_id、chunk_id、tenant_id、department_id、classification、source_updated_at、embedding_versionを持たせます。絞り込みに使う項目だけをインデックス対象にし、Payload増加後の実測メモリも見積もります。小規模・完全一致中心なら、全文検索エンジンやRDBの検索機能の方が安価で単純な場合があります。

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

日本語RAGではdense検索だけに依存せず、固有名詞、型番、法令番号、略語を拾う語彙検索を組み合わせます。公式資料では、denseとsparseのHybrid Retrieval、全文検索、Payload条件によるFilterが提供されています。どの構成が最適かは日本語コーパスで評価し、Top-K、融合方法、再ランキングを決めます。

検索品質は業務別の正解集合で測る

「有給」「年休」のような言い換えと、「AB-120」「第36条」のような完全一致を混在させた質問を用意し、Recall@K、上位結果の正答率、回答根拠の一致率を測定します。形態素解析やsparseモデルの日本語適合性は構成ごとに異なるため、対応を推測で断定せず、実データで確認します。

権限Filterは検索要求ごとに強制する

部署、テナント、機密区分、案件IDをPayloadへ保存し、利用者の認可情報からFilterをサーバー側で生成します。LLMが作ったFilterやブラウザーから渡された部署IDを信用してはいけません。Filterなし検索を禁止する共通API層を設け、退職・異動・文書公開範囲変更時にはPayloadを更新します。Payload Filterは検索の絞り込み機能であり、それだけで認証・認可全体が完成するわけではありません。

Managed Cloudは各リクエストにAPIキーを使用し、監査ログ機能を備えると公式資料に記載されています。一方、キー単位の権限粒度、ログの保存期間、国内法務要件への適合、通信経路、暗号鍵管理は契約条件を確認してください。インターネット経由を許容できない機密環境では、Hybrid Cloudや自社基盤上のPrivate Cloudを比較対象にし、完全閉域の要件を満たせない場合は別製品も検討します。

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

運用設計では、検索APIだけでなく、取り込み遅延、権限更新、モデル更新、復旧手順まで監視対象にします。Managed Cloudには監視・ログ・アラート、監査ログ、スケーリング、自動シャード再配置、バックアップと災害復旧があると公式資料で案内されています。ただし保持世代、復元単位、RPO・RTOが自社要件を満たすかは別途確認が必要です。

容量と品質を同時に監視する

• 検索レイテンシのp50・p95・p99、エラー率、タイムアウト率
• ポイント数、ディスク・メモリ使用量、レプリカとシャードの状態
• 取り込み待ち件数、失敗チャンク、原文更新から反映までの時間
• Filter適用率、検索結果ゼロ率、権限外データの混入テスト
• Embedding版別のRecall@K、回答根拠一致率、推論コスト

更新処理には原文ハッシュと版番号を持たせ、差分Upsert、削除、再試行を冪等にします。Embeddingモデルやチャンク方式の変更は、新旧Collectionを並行稼働させ、評価と切り戻しができるようにします。大量再Embeddingによる一時容量、推論費、書き込み負荷も見積もりに追加してください。

バックアップは「存在」ではなく「復元できること」を確認します。四半期ごとに別環境へ復元し、ポイント数、Payload、権限Filter、代表クエリの結果を照合します。原文保管庫、Embedding設定、チャンク処理コードも復旧対象です。ベクトルDBだけを戻しても再現できないため、障害別の復旧順序、責任者、連絡経路をRunbookへ記載します。以上は2026年8月31日時点の公式情報を基にした確認事項であり、料金と提供条件は見積もり時に再確認が必要です。

導入手順

見積もりはベクトル数だけでなく、次元数、payload、索引、レプリケーション、バックアップ、検索負荷まで含めて進めます。公式情報は2026年8月31日時点で確認していますが、単価や提供条件は契約前にQdrant Cloud上で再確認してください。

1. データ量と増加率を算定する

   初期文書数、チャンク数、1文書当たりのチャンク数、ベクトル次元、月間増加率、保持期間を整理します。本文・権限・部署・更新日時など、payloadに保存する項目も容量へ影響します。

2. 検索方式を決める

   日本語RAGではdense検索だけで判断せず、製品番号や法令名を拾うsparse検索、全文検索、payload filter、再ランキングを比較します。Qdrantはdenseとsparseを組み合わせたHybrid Retrievalやフィルタリングを提供しています。

3. 概算リソースを計算する

   公式Cloud Pricing CalculatorでCPU、メモリ、ストレージの目安を確認します。ただし公式資料では、計算結果にpayloadや索引データが含まれないと説明されています。検証環境で実データを投入し、余裕率を加えてください。

4. 可用性と配置を設計する

   停止許容時間、復旧目標、レプリカ数、バックアップ、リージョン、データ越境条件を決めます。Managed Cloudは高可用クラスター、自動フェイルオーバー、スケーリング、バックアップと災害復旧を提供しますが、各機能の料金・保持期間・対象プランは個別確認が必要です。

5. 接続・権限・監査を確認する

   APIキーの保管とローテーション、開発・本番の分離、接続元制限、通信経路、操作ログの閲覧者を定義します。公式にはAPIキー認証と監査ログが案内されていますが、必要な権限粒度やログ保管期間を満たすかは契約前に照合します。

6. PoCで品質と費用を同時測定する

   代表的な日本語質問、正解文書、権限条件を用意し、Recall@K、回答正確性、P95遅延、同時実行数、日次更新時間を測ります。埋め込み生成費、再ランキング費、LLM費、ネットワーク転送費も総額へ含めます。

7. 本番見積もりと運用条件を確定する

   通常時と繁忙時の構成、増設基準、障害対応窓口、バージョン更新、解約時のデータ搬出方法を稟議資料へ記載します。月額だけでなく、3年間の増加量を置いたTCOでManaged Cloud、Hybrid Cloud、自己運用を比較します。

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

Qdrant Cloudは、ベクトル検索を自社運用せず、検索機能の実装と評価へ集中したい組織に向きます。一方、厳格な閉域要件や小規模な検索では別構成が合理的な場合があります。

向くケース

• dense・sparse・全文検索・payload filterを組み合わせ、日本語RAGの検索品質を調整したい
• 水平・垂直スケーリング、監視、ログ、バックアップ、フェイルオーバーの運用負荷を抑えたい
• 文書ごとの部署、契約、機密区分をpayloadに持たせ、検索時に絞り込みたい
• HTTPまたはgRPCと公式クライアントを使い、既存アプリへ組み込みたい

向かない、または追加検討が必要なケース

• 外部クラウドへのデータ保存・接続が禁止される場合。自社基盤でのHybrid CloudやPrivate Cloud、他製品を比較する
• 数千件程度の小規模データで、既存RDBの全文検索やベクトル拡張で要件を満たせる場合
• 細かな行単位権限をDB任せにしたい場合。アプリ側認可とfilterの強制方法を別途設計する
• 運用担当者がおらず、検索評価、埋め込み更新、誤検索分析までサービス側へ一任したい場合

導入前チェックリスト

次の項目を数値または文書で回答できれば、見積もりの過不足と稟議後の手戻りを減らせます。

1. 初期・1年後・3年後のベクトル数、次元数、payload容量を算出したか
2. ピークQPS、同時接続数、Top-K、P95遅延の目標を定めたか
3. 日本語の略語、固有名詞、型番を含む評価データを用意したか
4. dense単独とHybrid Retrieval、再ランキングの品質・費用を比較したか
5. リージョン、データ越境、閉域接続、保存時・通信時暗号化の要件を確認したか
6. APIキーの発行、保管、失効、ローテーションの責任者を決めたか
7. テナント・部署・文書単位の認可条件をpayload filterへ確実に適用できるか
8. 監査ログの対象操作、閲覧権限、保管期間、SIEM連携要否を確認したか
9. バックアップ頻度、復旧目標、削除データの反映、データ搬出手順を検証したか
10. DB料金以外の埋め込み、LLM、転送、監視、開発・運用人件費をTCOへ含めたか

結論

Qdrant Cloudの導入判断では、表示月額よりも「実データで必要になる構成」と「周辺費用を含むTCO」が重要です。Hybrid Retrieval、filter、運用機能は有力ですが、閉域性、認可粒度、監査条件を自動的に満たすとは限りません。Calculatorで概算し、権限付き日本語データのPoCを行い、高可用構成と代替案を同じ条件で比較してから稟議へ進めるのが堅実です。

一次情報・参考リンク

• Qdrant Documentation – Overview
• Qdrant Search
• Qdrant Managed Cloud
• Qdrant Deployment Options