社内AI検索の根拠と閲覧権限は、回答画面の追加機能ではなく、検索全体の前提です。答えに文書名が付いていても、利用者が読めない文書から内容を取り出していれば情報は漏れています。引用の見た目と、検索・生成・履歴表示の各段階で守るべき範囲を分けて確認する必要があります。
架空の保守サービス会社が、手順書と顧客別の契約資料を社内検索へ取り込む例を考えます。一般の担当者は共通の手順書を読み、特定顧客の担当者だけが契約条件を見られます。これはBrainbaby Labsの顧客成果ではなく、権限を含む検索仕様を検討するための例です。
文書の所有者と権限を検索まで引き継ぐ
取り込み時に本文だけを集めると、元のフォルダーや顧客単位の制限が失われる場合があります。文書の識別子、版、所有者、閲覧条件を管理し、検索時には認証された利用者の現在の権限を適用します。画面で文書名を隠すだけでは、回答に含まれた情報を取り消せません。
外部の文書サービスを使う場合は、権限変更が分かる仕組みと反映までの扱いを確認します。更新が失敗したときに古い権限で検索を続けるのか、対象文書を一時的に検索から外すのかを決めます。許可の判定をモデルへの指示文だけに任せず、アプリケーション側でアクセス範囲を制御してください。
引用は答えを確かめるために使う
回答には、根拠となった文書と該当箇所へ進める導線を用意します。利用者が文書を開いた際にもアクセスを再確認し、現在版と回答に使用した版が異なる場合は分かるようにします。引用が存在することだけで、回答のすべてが裏付けられているとは限らないため、評価では内容との対応を確認します。
根拠が一部しかない質問には、分かる範囲と不足を区別して返す方針が必要です。たとえば共通手順書にない顧客固有の条件を、一般論から作り足さないことを確認します。利用者には原文確認や担当部署への問い合わせという次の手段を示し、もっともらしい断定だけを残さないようにします。
更新・削除・履歴を一つの問題として扱う
文書を削除しても、検索索引、生成済み回答のキャッシュ、会話履歴に内容が残る可能性があります。どの複製を持つのかを把握し、更新と削除の処理に含めます。保管する必要がある履歴についても、誰が読めるか、権限失効後にどう表示するかを運用側と合意してください。
障害の調査用ログへ質問と文書本文を丸ごと保存すると、新たな閲覧経路を作ります。必要な識別子や処理結果を中心にし、詳細な内容を保存する場合は目的、期間、閲覧者を限定します。使用するAIサービスへのデータ送信や保存条件は別途確認し、単に社内画面にあるという理由で内部だけの処理だと考えないようにします。
権限の異なる利用者で同じ質問をする
受入テストでは、共通文書だけを読める人、顧客担当者、権限を失った元担当者で同じ質問を試します。検索候補、回答、引用リンク、履歴、出力ファイルの各段階を確認してください。文書の変更・削除後にも再試行し、取得不能なときに不足を示せるかを評価します。
Brainbaby Labsへの相談には、文書の種類、権限構造、更新頻度、答えを原文で確認したい代表的な質問を添えてください。回答の便利さと情報の境界を同時に検証しながら、社内AI検索の開発範囲を具体化できます。