【2026年最新】社内文書検索システムの構築方法｜RAG・権限管理・評価の進め方

定義と基本

社内文書検索RAGとは、権限内の文書を検索し、その根拠を生成AIへ渡して引用付き回答を作る仕組みです。

基本構成は、データソース、収集・解析処理、検索インデックス、権限判定、検索・再ランキング、生成モデル、利用画面、評価・監視です。回答生成が不要な規程番号やファイル探索では、全文検索だけのほうが安価で説明しやすい場合があります。RAGは複数文書の要約や問い合わせ対応に有効ですが、原文の正しさや最新性を保証する機能ではありません。

実装前には、質問、期待する文書、模範回答、閲覧可能な利用者を組にした評価データを用意します。日本語では表記揺れ、複合語、社内略語、OCR誤りを含めて試験し、チャンクサイズや埋め込みモデルだけでなく、全文検索との併用、メタデータ絞り込み、再ランキングの効果を比較します。削除済み文書がインデックスやキャッシュに残らない運用も必須です。

公式情報からわかる特徴

2026年8月16日確認の公式資料では、Qdrantはベクトル類似検索に加え、payloadによる絞り込み、全文検索、dense・sparseを組み合わせるハイブリッドクエリ、再ランキング関連機能を案内しています。これは検索候補の制御に有用ですが、社内認証基盤や文書ACLとの同期まで自動的に完成することを意味しません。

Qdrantのフィルタリングと権限設計

Qdrant Filteringの公式資料では、payloadとpoint IDに条件を設定でき、must、OR相当、NOT相当の条件を入れ子にできると説明されています。また、性能が必要なフィールドは取り込み前にpayload indexを作成することが推奨されています。部署、機密区分、文書IDなどを検索条件にできますが、編集上は、利用者が任意の権限値を送れないようアプリケーション側で条件を生成し、拒否試験を行うべきだと判断します。

セキュリティと代替案

Qdrant Securityの公式資料では、APIキー、読み取り専用キー、コレクション単位の詳細キー、TLS、ネットワークバインド、監査ログが案内されています。セルフホスト版は既定で安全ではなく、本番前の明示設定が必要です。閉域で細かな文書ACL、既存クラウド監査、運用省力化を優先する場合は、Qdrantに限定せず、Amazon Bedrock Knowledge BasesなどのマネージドRAGや既存検索基盤も比較対象です。Bedrock公式資料は対応コネクターで取得時の文書ACLフィルタリングを示していますが、Web Crawlerは例外とされるため、データソース別の適用可否を確認する必要があります。

比較と選定ポイント

選定では、検索精度だけでなく、既存の文書基盤、文書単位の権限継承、閉域接続、監査証跡、運用担当者のスキルを同じ重みで確認します。日本語RAGは製品名だけで決まらないため、実データを用いて分割方法、埋め込みモデル、キーワード検索との併用、再ランキングまで比較してください。

Qdrant公式資料では、ペイロードやIDに対する条件をAND・OR・NOTで組み合わせられ、頻繁に絞り込む項目には取り込み前のペイロードインデックス作成が推奨されています。したがって、tenant_id、department_id、document_id、機密区分、有効期限などを検索条件にできます。ただし、これは権限判定そのものではありません。認証済み利用者の所属・ロールから許可条件をサーバー側で生成し、検索時に必ず適用する設計が必要です。

比較検証では、部署別に閲覧可能・禁止文書を含む質問セットを作り、Recall@kやnDCGだけでなく、回答根拠の正しさ、回答不能率、権限外文書の取得件数、P95応答時間を測ります。略語、表記揺れ、製品番号、完全一致が多い日本語文書では、ベクトル単独とハイブリッド検索を比較するのが実務的です。

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

閉域・機密情報を扱うなら、SaaSかセルフホストかではなく、データ保存場所、外部通信、暗号鍵、ログ保管、障害対応の責任主体まで決めて選びます。料金はデータ量、レプリカ、計算資源、埋め込み・生成モデルの利用量、転送量で変動するため、固定額を前提にせず、公式料金表と見積もりを稟議時点で確認してください。

Qdrant公式資料では、Cloudはセキュリティ機能が既定で有効とされる一方、オープンソース版のセルフホストは既定状態のまま本番利用できず、APIキー認証、ネットワークバインド、TLS、監査ログを明示的に設定する必要があります。コレクション単位のキーだけで利用者ごとの文書ACLを代替せず、アプリケーション層で認可し、権限変更時の再同期、削除、キャッシュ失効まで試験してください。

公式情報確認日：2026年8月16日。機能、提供リージョン、価格、SLA、監査ログの提供条件は変更され得るため、契約前に各社の公式資料で再確認してください。

企業導入の設計・実装

社内文書検索は、対象業務と閲覧権限を先に定義し、収集、分割、Embedding、検索、回答生成を分離して設計します。最初から全社展開せず、「規程の照会」「技術資料の横断検索」など、正解と利用者を特定できる業務で検証するのが現実的です。

収集から回答までの構成

1. SharePoint、ファイルサーバー、S3などから本文とACLを取得し、文書ID、版、更新日時、所有部門、機密区分を付与する。
2. 見出し、段落、表を考慮してチャンク化する。初期値は本文400〜800トークン、重複10〜20％程度とし、就業規則や手順書では条・章をまたがないよう調整する。
3. 日本語対応Embeddingでベクトル化し、モデル名、次元数、前処理バージョンを記録する。モデル変更時は旧インデックスを残して再生成し、一括上書きを避ける。
4. 検索結果へ文書名、該当箇所、更新日を添えてLLMに渡し、根拠が不足する場合は回答を保留させる。

QdrantではベクトルにPayloadを付け、検索時に条件を組み合わせられます。公式資料では、PayloadやポイントIDへの条件指定、AND相当のmust、OR、NOTの組み合わせが案内されています。また、頻繁に絞り込むPayload項目は、投入前にインデックスを作成することが推奨されています。

編集上の推奨：評価用に、質問、期待する根拠文書、回答可否、利用者属性を50〜200件程度用意し、検索再現率、上位件数内の正解率、引用整合性、権限漏えい件数、応答時間を比較します。運用を全面的にマネージド化したい場合は、文書単位ACLフィルタリングを提供するAmazon Bedrock Knowledge Basesなども候補です。細かな検索制御より運用負担の削減を優先する組織では、Qdrantの自己運用が最適とは限りません。

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

日本語ではEmbedding検索だけに依存せず、表記揺れ、略語、型番、人名を拾うキーワード検索と組み合わせます。セキュリティでは、検索後ではなく検索クエリの段階で権限Filterを適用し、許可情報を取得できない場合は失敗側に倒す設計が必要です。

日本語検索の調整

「生成AI／生成ＡＩ」「有休／年休」などの同義語辞書、全半角・Unicode正規化、英数字の大文字小文字、長音、社内略語を前処理として管理します。Qdrant公式資料では、ベクトル検索、全文検索、dense・sparse検索を組み合わせるハイブリッドクエリ、再ランキングが案内されています。ただし、日本語の分かち書きや辞書適合性は採用するEmbedding、Sparseモデル、Tokenizerごとに実データで確認すべきです。

権限を検索条件へ変換する

認証基盤から利用者ID、所属、グループ、役職を取得し、tenant_id、allowed_groups、classificationをAND条件で絞り込みます。退職・異動・文書共有変更を反映できるよう、ACL同期時刻と同期失敗を監視します。LLMへの指示だけで閲覧制御する方法や、取得後にアプリケーションで除外する方法は、漏えい防止策として不十分です。

公式資料で確認できること（2026年8月16日確認）：QdrantはAPIキー、読み取り専用キー、コレクション単位の細粒度キー、TLS、ネットワークバインド、監査ログを案内しています。一方、セルフホスト版は既定で認証されず、到達可能なインターフェースに公開され得るため、本番前の明示設定が必要です。閉域配置ではプライベートIPへのバインド、TLS、秘密情報管理、管理APIと検索APIの分離を稟議要件に含めます。

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

運用では、検索品質、権限同期、データ鮮度、生成回答、基盤障害を別々に監視します。バックアップの取得だけで完了とせず、文書、Payload、ベクトル生成条件、アプリ設定を同じ時点へ戻せる復旧手順を整備します。

残すログと指標

• 検索語のハッシュまたはマスキング値、適用Filter、取得文書ID、スコア、再ランキング結果
• 回答の引用元、回答保留、利用者評価、誤回答・権限違反の報告
• 投入件数、解析失敗、Embedding失敗、ACL同期遅延、検索レイテンシ、エラー率
• API操作の監査ログ、設定変更者、キー発行・失効、管理操作の成否

質問本文や生成回答には個人情報・営業秘密が含まれ得ます。ログの閲覧権限、保存期間、マスキング、国外転送の有無を定め、監査ログと品質改善ログを分離します。

更新と復旧

文書更新はdocument_idと版で差分管理し、新版の投入完了後に旧版を検索対象外へ切り替えます。削除文書と失効ACLもキューで追跡し、再試行不能なデータを隔離します。Embeddingモデルやチャンク規則の変更時は別コレクションで再構築し、評価後に切り替える方法が安全です。

編集上の推奨：原本文書、ACL、投入マニフェスト、設定、秘密情報の参照先、ベクトルDBのスナップショットまたはエクスポートを保全し、RPO・RTOを定義します。四半期など定期的に別環境へ復元し、件数、代表クエリ、権限Filter、引用元まで確認してください。利用可能なバックアップ機能と整合性条件は、採用するQdrant Cloudまたはセルフホスト版の契約・バージョンごとに公式資料で再確認が必要です。

導入手順

社内文書検索は、製品選定より先に利用目的、閲覧権限、正解条件を定義します。以下の順序で小規模に検証し、検索品質と情報漏えい対策の両方を確認します。

1. 業務要件と対象範囲を決める

   「規程の根拠箇所を探す」「過去案件から類似事例を得る」など、利用者、質問、期待する回答、許容時間を明文化します。人事評価や法務判断のように誤答の影響が大きい業務は、回答を意思決定に直結させず、原文確認を必須にします。

2. 文書と権限情報を収集する

   SharePoint、ファイルサーバー、S3などの所在、形式、更新頻度、文書責任者を棚卸しします。本文だけでなく、文書ID、版、部署、機密区分、閲覧可能なユーザー・グループ、失効日をメタデータとして取得します。権限を取得できない文書は、原則として投入対象から外します。

3. 解析・分割・索引を設計する

   PDFやOffice文書から見出し、表、ページ番号を保持して抽出し、日本語の章・条・箇条書きを壊さない単位で分割します。略語、製品番号、氏名では意味検索だけでは不足するため、キーワード検索とベクトル検索を組み合わせ、必要に応じて再ランキングします。

4. 検索時の権限制御を実装する

   認証基盤から利用者の所属とグループを取得し、検索クエリへ必須フィルターとして付与します。Qdrant公式資料では、payloadやIDへの条件指定、AND・OR・NOTの組み合わせ、フィルター対象フィールドのpayload index作成が案内されています。ただし、これは社内ID基盤との連携を自動化するものではなく、権限同期とフィルター生成はアプリケーション側の設計事項です。

5. 根拠付き回答を構成する

   LLMには許可済み検索結果だけを渡し、回答、引用箇所、文書名、版、更新日を表示します。根拠が弱い場合は推測させず「該当資料を確認できない」と返し、原文へ遷移できるUIにします。プロンプト対策だけを権限制御として扱ってはいけません。

6. 評価して段階展開する

   実際の質問と正解文書で評価セットを作り、Recall@k、順位、引用整合性、回答不能判定、権限外文書の混入件数、応答時間を測ります。部門限定で開始し、分割幅、検索方式、フィルター、再ランキングを変更した際は同じセットで回帰評価します。

7. 更新・監査・障害対応を運用する

   追加、改訂、削除、権限変更を差分同期し、退職・異動時の反映期限を定めます。質問、検索条件、参照文書、回答、モデル・索引版を、機密情報を過剰保存しない形で記録します。索引遅延、検索品質低下、生成API停止に備え、検索のみへの切替や原文検索への退避も用意します。

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

RAGが向くのは、文書量が多く、利用者が表現の異なる質問から関連箇所を探し、最終的に原文を確認できる業務です。規程、製品仕様、FAQ、議事録、保守記録の横断検索や、部署・案件単位で検索範囲を絞れる用途が該当します。

一方、数値の完全一致や最新残高を保証する照会、厳密な計算、承認判断の自動化には、業務DBやルールエンジンを優先します。文書の版管理がなく、ACLを取得できず、正解データも作れない場合はRAG導入前の情報整備が必要です。

Qdrantは細かなpayload filteringやハイブリッド検索を自主管理したい場合の候補です。閉域でのセルフホストには選択余地がありますが、公式資料上、セルフホスト版は初期状態のまま本番利用できる安全設定ではなく、APIキー、監査ログ、プライベートネットワークへのbind、TLSを明示的に構成する必要があります。運用人員が限られる場合は、ACL連携を含むマネージドRAGや既存検索製品も比較します。Amazon Bedrock Knowledge Basesについては、公式資料で一部コネクターの文書ACLによる検索時フィルタリングが案内されていますが、対象コネクターや要件への適合は個別確認が必要です。

導入前チェックリスト

稟議では精度だけでなく、権限事故、更新停止、運用費を含めて可否を判断します。

1. 対象業務、利用者、対象外業務、期待効果を数値で定義したか
2. 文書責任者、正本、版、保存期限、削除ルールを特定したか
3. ユーザー・グループACLを取得し、異動時に同期できるか
4. 日本語の略語、表記揺れ、固有名詞、表やスキャンPDFを含む評価データがあるか
5. 権限フィルターを検索前に強制し、生成モデルへ権限外本文を渡さない設計か
6. 引用元、ページ、更新日を表示し、回答不能を許容するか
7. 通信・保存時暗号化、鍵管理、閉域接続、監査ログの要件を満たすか
8. 再索引、バックアップ、障害復旧、モデル変更時の回帰評価の担当者がいるか
9. 埋め込み・生成・ストレージ・監視・運用工数を含む総費用を比較したか

結論

社内文書検索の成否は、ベクトルDBの性能だけでなく、正本文書、ACL、根拠表示、評価セット、更新運用を一体で設計できるかで決まります。小規模な実データ検証で検索品質と権限境界を測り、Qdrant、マネージドRAG、既存検索を同じ要件で比較してください。上記の製品機能に関する記述は、公式情報を2026年8月16日に確認した内容に基づきます。

一次情報・参考リンク

• Qdrant Filtering
• Qdrant Search
• Qdrant Security
• Amazon Bedrock Knowledge Bases