機密情報を扱うRAGでは、検索前の認証、検索時のACL、生成前後の回答制御を一続きの認可処理として設計します。利用者の所属・役職・案件・機密区分をIdPから取得し、文書やチャンクに付与したtenant_id、department_id、project_id、classification、valid_untilなどの属性と照合してください。ACL条件はアプリ側で検索結果を除外するのではなく、Vector Databaseへの検索要求へ必須フィルターとして組み込みます。コレクション分割だけに依存すると、異動や兼務、案件単位の権限変更に追随しにくいため、強い分離が必要なテナント境界と、柔軟な属性フィルターを併用するのが実務的です。取得文書が0件、根拠の信頼度が閾値未満、機密区分が生成モデルへ送信できない場合は回答を生成せず、権限不足または確認不能として処理します。
監査ログには利用者ID、認証主体、検索日時、対象コレクション、適用ACL、取得した文書ID、モデル、回答判定、管理操作を記録し、問い合わせ本文や回答全文は必要性を審査してマスキングまたは別保管します。通信はTLS、保存データは暗号化し、鍵の保管・ローテーション・失効を運用手順に含めます。原文、チャンク、ベクトル、キャッシュ、会話履歴、ログ、バックアップごとに保持期間と削除責任者を定め、原文削除時には派生データも追跡して消去できる台帳が必要です。閉域構成でも認証を省略せず、外部LLMや埋め込みAPIへの送信可否、リージョン、再学習利用、保持条件を確認します。日本語検索はベクトル検索だけでなく、固有名詞や文書番号を拾うキーワード検索とのハイブリッド構成も評価対象です。
この記事でわかること
- 利用者属性と文書属性を用いたACLフィルターの設計方法
- 検索、生成、管理操作を追跡できる監査ログの記録項目
- 通信・保存・鍵管理を含む暗号化と閉域化の確認点
- 原文からベクトル、ログ、バックアップまでの保持・削除設計
- 根拠不足や機密区分に応じて回答を拒否・制限する実装方針
定義と基本
機密RAGとは、認可済みの情報だけを検索・生成に使用し、その判断と操作を後から監査できる検索生成基盤です。
基本単位は「誰が、どの目的で、どのデータに、何をできるか」です。閲覧権限は取り込み時だけでなく検索の都度評価し、権限変更がインデックスへ反映されるまでの許容時間もSLAとして決めます。文書IDと派生チャンクの対応表を保持すれば、退職者データや期限切れ契約書をベクトル、キャッシュ、引用候補から一括削除しやすくなります。
回答制御はプロンプトだけに任せません。検索フィルター、取得件数、スコア閾値、許可された引用範囲、個人情報検出、出力先の機密区分を機械的に判定します。ログ閲覧権限は運用管理者から分離し、改ざん防止、時刻同期、保管期限、インシデント時の検索手順まで定義してください。
公式情報からわかる特徴
提示されたQdrant公式資料では、APIキー認証、読取専用キー、コレクション単位で権限を絞るGranular Access API Key、ネットワークバインド、TLS、監査ログがセキュリティ機能として案内されています。セルフホスト版は初期状態で認証がなく、全ネットワークインターフェースへ公開され得るため、本番投入前の明示設定が必要とされています。
Qdrantのフィルタリングは、payloadとIDに条件を設定し、AND、OR、NOTを組み合わせられます。したがってdepartment_idやclassificationをpayloadへ保持して検索ACLに使えますが、これは編集上の実装案であり、製品だけで社内の認可規則が完成するわけではありません。フィルター対象には取り込み前のpayload index作成が推奨されています。
Managed Cloudについては、保存ボリュームの暗号化、通信時TLS、IP範囲制限、アカウントRBACが公式資料に記載されています。一方、データ保持期間、派生データの削除、回答内容の制御は利用企業側で別途設計すべき領域です。厳格な閉域、既存IdPとの細かな統合、統合監査を優先する場合は、セルフホストやHybrid Cloudに加え、権限対応の企業向け知識基盤を案内するAzure AI Searchなども比較します。
公式情報確認日：2026年8月10日（指定日）。ただし当該日は執筆時点で未到来のため、本断片は提示された公式資料の抜粋に基づき、契約時には最新仕様と提供プランの再確認が必要です。
この記事の目次
比較と選定ポイント
機密情報を扱うRAGでは、検索性能だけでなく、権限を検索時に強制できるか、操作を追跡できるか、暗号化と削除を継続運用できるかで選定します。ベクトルDBの認証だけで回答漏えいは防げないため、検索フィルター、生成前後の検査、ログを一体で設計することが重要です。
| 候補 | 採用条件 | 向く用途 | 注意点 |
|---|---|---|---|
| Qdrant Managed Cloud | SaaS利用が許可され、リージョン、契約、データ移転条件を満たせる | 専任基盤要員を抑えつつ、TLS、保存時暗号化、IP制限、APIキー管理を利用したい構成 | 公式資料ではクラスタ分離、保存時暗号化、TLS、CloudアカウントのRBACを案内している。一方、文書単位ACLはpayloadフィルター等でアプリ側が実装・試験する。SSOや顧客管理鍵は契約条件を確認する |
| Qdrant Hybrid Cloud | データプレーンを自社環境に置き、管理プレーンとの接続を許容できる | 閉域要件や既存監視基盤を維持しながら、Cloudに近い運用体験を求める場合 | 基盤、ネットワーク、OS周辺の保護は利用企業の責任となる。完全なエアギャップが必須なら適合性を個別確認する |
| Qdrantセルフホスト | 認証、TLS、監査ログ、バックアップ、更新を自社で運用できる | 完全閉域、配置制約、独自の保持・消去手順が厳しい環境 | 公式資料上、初期状態は認証なしで全インターフェースに公開され得るため、本番利用前の明示設定が必須。運用負荷を過小評価しない |
| Azure AI Search | Azureを標準基盤とし、ベクトル検索とキーワード検索を同一サービスで統合したい | 日本語の固有語・型番を含むハイブリッド検索、Azure周辺サービスとの統合 | 公式資料ではベクトル、ハイブリッド、多言語検索を案内している。必要なACL連携、監査、閉域機能と対象SKUは別途公式資料・見積もりで確認する |
ACLと回答制御は製品比較から分離する
Qdrantのgranular access API keyはコレクション単位のread/write制御に利用できますが、利用者ごとの文書閲覧権限を自動継承する仕組みとは分けて考えます。文書にtenant_id、部署、機密区分、許可主体、失効日時を保持し、認証済み属性からサーバー側でフィルターを生成します。対象項目には取り込み前からpayload indexを設定し、クライアントが任意に条件を解除できないAPI境界にします。
回答生成では、権限内チャンクだけをLLMへ渡し、根拠が不足する場合は回答を拒否します。プロンプトによる「閲覧禁止」指示はACLの代替になりません。検索件数ゼロ、権限外候補の除外、引用元の再認可、個人情報・秘密情報の出力検査をテスト項目に含めます。
導入形態・料金・責任分界
閉域性を最優先するならセルフホスト、運用負荷を抑えるならManaged Cloud、その中間がHybrid Cloudです。ただし、どの形態でも元文書の権限同期、保持期限、回答制御、インシデント対応は利用企業側に残ります。
形態別の責任を稟議前に固定する
- Managed Cloud：事業者がクラスタ基盤、パッチ、保存領域の暗号化などを担う範囲が広い一方、APIキーの最小権限化・期限設定・ローテーション、投入データ、ACL条件、削除要求の実行は利用企業が管理します。
- Hybrid Cloud：データプレーンの基盤保護、ネットワーク、容量、バックアップ、障害対応の分担を契約書と運用手順で明文化します。
- セルフホスト：秘密情報管理、TLS証明書、監査ログ転送、脆弱性対応、復旧試験まで自社責任です。監査ログ自体へのアクセス制限と改ざん防止も必要です。
料金とデータ保持の確認項目
料金はクラスタ規模、ストレージ、レプリカ、通信量、バックアップ、サポート、SSOや顧客管理鍵などの契約条件で変動します。固定額を前提にせず、2026年8月10日時点の公式料金表と個別見積もりで確認してください。Azure AI Searchもリージョン、SKU、検索ユニット等の条件を公式料金計算で比較します。
保持期間はベクトルだけでなく、原文、チャンク、キャッシュ、会話履歴、監査ログ、バックアップを対象にします。削除依頼時に全複製先へ反映される期限、ログへ本文やプロンプトを残すか、復元媒体から消える時期を責任分界表と受入試験に記載します。
企業導入の設計・実装
機密情報を扱うRAGでは、認証、検索時の権限Filter、暗号化、監査ログ、回答制御を別々の層で実装します。Vector DatabaseのAPIキーだけで利用者単位のACLを代替せず、認証基盤から取得した権限を検索条件へ強制変換する構成が基本です。
権限情報をPayload／Metadataへ持たせる
チャンクごとに、tenant_id、document_id、department_ids、classification、valid_from、valid_until、source_versionを付与します。権限は文書単位で判定し、同じ文書から生成した全チャンクへ同一ACLを複製します。ACLのないチャンクは検索対象外とする「初期値拒否」にすると、付与漏れによる漏えいを抑えられます。
QdrantはPayloadとIDに対するFilter、AND・OR・NOT条件を提供し、頻繁に絞り込む項目には取り込み前のPayload Index作成を推奨しています。実装時は、利用者が送ったtenant_idや部署条件をそのまま信用せず、RAG APIがIDトークンや社内ディレクトリから条件を生成してください。コレクション単位のAPIキー権限と、チャンク単位のFilterを多層化します。
接続と回答にも防御線を置く
- Embedding APIへ送る前に、送信可否、保存有無、学習利用条件、処理リージョンを確認する。
- 検索結果は権限Filter適用後に再検証し、許可された引用だけを生成モデルへ渡す。
- 根拠不足、機密区分超過、権限判定失敗時は回答を拒否し、一般知識による補完を許可しない。
- プロンプトインジェクション対策として、取得文書内の命令をデータとして扱い、システム指示より優先させない。
公式資料上、Qdrantのセルフホスト版は初期状態で認証がなく、全ネットワークインターフェースへ公開され得るため、そのまま本番利用できません。APIキー、プライベートIPへのBind、TLS、監査ログを明示的に設定します。閉域要件が強く運用要員を確保できない場合はマネージド型、既存のMicrosoft認証・検索基盤との統合を優先する場合はAzure AI Searchなども比較対象です。
日本語検索・セキュリティの実務
日本語RAGはEmbeddingだけに依存せず、ベクトル検索とキーワード検索、権限Filterを組み合わせて評価します。人名、契約番号、製品型番、法令条文のような完全一致が重要な語は、意味類似だけでは取りこぼしや誤一致が起きるためです。
チャンクは権限境界をまたがせない
見出し、条項、表、箇条書きの境界を優先し、固定文字数だけで分割しないようにします。目安値は文書種別とEmbeddingモデルで変わるため、契約書、規程、FAQごとにRecall、誤引用率、検索時間を測定して決めます。異なる機密区分や閲覧部署の文章を一つのチャンクへ結合してはいけません。
全角・半角、旧字体、英数字の大小、表記揺れを正規化しつつ、原文は引用用に保持します。Embeddingには本文と見出しを入力し、文書番号や版数はMetadataとして完全一致検索できる形にします。Azure AI Searchは公式資料でベクトル検索とキーワード検索を同一リクエストで実行するハイブリッド検索を案内しています。Qdrantを採用する場合も、日本語の字句検索要件を別途検証し、必要なら疎ベクトルや外部検索エンジンとの併用を比較します。
ログへ本文を残しすぎない
監査用には利用者ID、テナント、検索日時、適用した権限条件、参照文書ID、モデル・索引の版、拒否理由、応答状態を記録します。一方、質問文、取得チャンク、生成回答を無条件に保存すると、ログ基盤が新たな機密情報庫になります。本文保存の必要性、マスキング、閲覧者、保持期間、削除手順を稟議時に定義し、アプリケーション監査ログとVector DatabaseのAPI操作ログを関連IDで追跡可能にします。
監視・更新・バックアップ
運用では、検索品質だけでなく、権限逸脱、設定変更、鍵の利用、削除反映、復旧可能性を継続監視します。障害復旧で古いACLや削除済み文書が復活しないよう、原本・Embedding・Payload・索引の世代を一体で管理することが重要です。
監視項目と保持方針
- 認証失敗、管理API操作、Filterなし検索、異常な大量取得、APIキー変更を検知する。
- 原本の削除・権限変更時は、派生チャンクとEmbeddingも追跡して削除または再索引する。
- 監査ログ、検索ログ、回答履歴ごとに保持期間と法的保全の例外を定める。
- APIキーには用途別の最小権限、有効期限、定期ローテーションを設定する。
Qdrant公式資料では監査ログ、読み取り専用キー、コレクションごとの粒度を持つアクセスキーが案内されています。Qdrant Cloudは転送時TLSと保存ボリュームの暗号化を掲げ、Premiumでは顧客管理鍵も選択肢です。セルフホストでは、保存時暗号化、鍵管理、基盤パッチ、ログ転送を利用企業側で設計する必要があります。
復旧は検索できることまで試験する
バックアップ方式や復旧単位は、採用エディションとバージョンの公式仕様を確認して決定します。四半期などの周期で別環境へ復元し、件数一致だけでなく、権限Filter、Payload Index、暗号鍵、削除済みデータの非復活、代表質問への検索結果まで確認します。目標復旧時点と目標復旧時間を満たせない、または閉域内でバックアップ媒体を安全に管理できない場合は、既存クラウドの検索サービスや社内標準データ基盤を選ぶ判断も合理的です。
導入手順
機密RAGは、検索前の認可から回答後の監査までを一つの制御系として設計します。ベクトルDBのフィルターだけに権限判定を任せないことが重要です。
-
情報資産と利用者を分類する
文書を「公開・社内・部門限定・個人情報・法規制対象」などに分け、利用者、サービスアカウント、管理者の権限表を作成します。原文だけでなく、分割チャンク、埋め込み、要約、会話履歴、バックアップも保護対象に含めます。
-
認証と認可の境界を決める
IdPで認証した利用者の所属、役職、案件、地域などをRAGゲートウェイで検証し、検索条件へ強制的に変換します。クライアントが送ったACL条件をそのまま信用せず、サーバー側で上書きしてください。
-
コレクションとメタデータを設計する
機密区分や管理主体が大きく異なる場合はコレクションを分離し、細かな権限は
tenant_id、department_id、allowed_groups、有効期限などのpayloadで表現します。QdrantはpayloadとIDへの条件指定、AND・OR・NOTの組み合わせに対応します。頻繁に絞り込む項目は投入前にpayload indexを作るのが公式推奨です。 -
通信・鍵・ネットワークを保護する
TLS、秘密管理基盤、鍵の有効期限とローテーション、閉域接続またはIP制限を設定します。Qdrant公式資料では、セルフホスト版は初期状態のまま本番利用できず、認証、監査ログ、private interfaceへのbind、TLSを明示設定する必要があります。管理用キーを検索アプリへ配布してはいけません。
-
監査ログと保持期限を定義する
利用者ID、検索時刻、対象コレクション、適用ACL、取得文書ID、モデル、回答判定、拒否理由を記録します。質問全文や取得本文は機密を増幅するため、ハッシュ化・マスキング・保存分離を検討します。インデックス、原文、ログ、キャッシュ、バックアップごとに削除期限と削除責任者を決めます。
-
回答制御を実装する
許可済みチャンクだけを生成モデルへ渡し、根拠表示、該当情報がない場合の回答拒否、個人番号などの出力検査を組み込みます。検索結果に権限外文書が混ざらないことを最優先とし、プロンプトによる「権限を無視せよ」という指示では解除できない構造にします。
-
権限テストと運用訓練を行う
退職者、異動直後、複数部署所属、期限切れ案件、ACL欠損文書を含む否定テストを実施します。誤回答率だけでなく、越権取得ゼロ、削除反映時間、鍵失効時間、監査追跡時間を受入基準にします。
向くケース・向かないケース
Qdrantは、アプリ側で認可を統制でき、コレクション単位の鍵とpayloadフィルターを組み合わせる構成に向きます。一方、既存IAMとの一体運用や文書単位ACLの自動継承を最優先する場合は、他製品も比較すべきです。
向くケース
- 閉域または自社基盤でデータプレーンを管理し、RAGゲートウェイを実装できる
- テナント、部署、案件などを明確なメタデータへ変換できる
- 日本語のベクトル検索とキーワード検索をアプリ側で組み合わせ、検索品質を調整したい
向かないケース
- エンドユーザーからベクトルDBへ直接接続させる構成
- 原本のACL変更を即時かつ自動で検索インデックスへ継承できない環境
- Microsoft Entra IDや既存検索基盤との統合を実装せず利用したい場合。この条件では、permission-awareな知識基盤を掲げるAzure AI Searchなども比較候補です
- 完全なエアギャップ、認証方式、監査証跡、暗号鍵管理について必須要件を満たす製品・契約プランを確認できない場合
導入前チェックリスト
稟議では機能の有無だけでなく、責任分界、設定方法、証跡の保管先まで確認します。
- 原文、チャンク、埋め込み、ログ、バックアップの機密区分を定義したか
- 認証主体とACLを結び付ける信頼済みゲートウェイがあるか
- ACL欠損時は許可ではなく拒否になるか
- 読み取り専用・コレクション限定・管理用の鍵を分離し、期限と交換手順を決めたか
- TLS、保存時暗号化、閉域化またはIP制限を確認したか
- 質問本文を保存しすぎずに、誰が何へアクセスしたか追跡できるか
- 原本削除や異動時にインデックス、キャッシュ、バックアップへ反映できるか
- 日本語の表記揺れ、固有名詞、略語を含む権限付き検索を評価したか
- 障害、鍵漏えい、越権検索を想定した停止・失効・報告手順があるか
よくある質問
payloadフィルターだけでACLを実現できますか？
条件表現には使えますが、それだけでは不十分です。認証済み属性からサーバー側で条件を生成し、検索、scroll、取得など全経路へ強制適用します。ACL変更の同期遅延と欠損時拒否も必要です。
埋め込みは原文でないため機密対象外ですか？
対象外とは断定できません。復元・推測・類似検索による情報露出を想定し、原文に準じたアクセス制御、暗号化、保持期限を設定するのが安全側の判断です。
Qdrant Cloudなら追加の設計は不要ですか？
不要ではありません。公式資料ではManaged Cloudの保存領域暗号化、TLS、クラスタ分離、IP制限、RBACなどが説明されていますが、文書ACL、回答制御、ログの保持方針は利用企業側の設計事項です。機能の提供条件は契約プランで確認してください。
監査ログに何を残すべきですか？
主体、時刻、操作、対象、適用権限、結果、相関IDを基本とします。質問・回答・本文の丸ごと保存は二次漏えい源になるため、目的に応じてマスキングや別保管を行います。
回答漏えいを完全に防げますか？
完全防止は保証できません。検索前認可、最小権限、出力検査、引用、回答拒否、監視を重ね、漏えい可能性と影響を下げます。高機密領域では生成回答を行わず、許可済み文書への案内だけに限定する選択もあります。
結論
機密RAGの要点は「許可された情報だけを検索し、必要最小限だけモデルへ渡し、後から追跡できること」です。QdrantにはAPIキー、コレクション単位の細粒度アクセス、フィルタリング、TLS、監査ログなどの公式機能がありますが、セルフホストでは明示設定が必要です。
製品選定では機能表だけで決めず、IAM連携、閉域要件、削除反映、ログ保護、回答拒否を実データで検証してください。以上の公式情報は2026年08月10日確認時点に基づき、具体的な提供範囲は利用形態、バージョン、契約条件で再確認が必要です。
一次情報・参考リンク
Vector Database・RAG基盤の導入を相談する
株式会社穣では、Qdrantを含むVector Databaseを活用したRAG・AI検索基盤の導入支援を検討・提供しています。
製品比較、適合診断、PoC、オンプレミス・閉域構築、日本語検索精度の改善、移行、運用・保守、法人研修までご相談いただけます。
