社内の手順書をAIで検索できるようにしたい。ただし、部署限定の資料や個別案件の情報まで、全社員へ見せるわけにはいかない。社内検索AIを導入するなら、回答の正しさと合わせて、誰がどの資料を使えるかを検証します。
最初のPoCでは、対象業務と資料の保管先を一つに絞れます。閲覧できる資料からは根拠付きで回答し、権限がない資料は検索候補や回答へ出さない。この二つを、利用者の権限を変えて確認します。
AIへの指示文だけに閲覧制限を任せない
非公開資料を見せないようAIへ指示するだけでは、アクセス権限の仕組みとして扱えません。利用者を確認し、その人が読める資料に検索対象を絞ったうえで、回答を作る流れにします。
たとえばMicrosoftのAzure AI Searchの公式説明では、利用者やグループを表す値で検索結果を絞る方法を紹介しています。同時に、このフィルター自体には本人確認の機能がないと説明しています。ログインした利用者の確認と、資料を選ぶ処理の両方が必要です。
開発会社には、画面でログインできることだけでなく、その利用者の権限を検索処理へどう渡すかを確認してください。質問文に書かれた部署名や、利用者が任意に指定した役割を、そのまま権限として扱わない設計にします。
資料ごとの閲覧範囲を先に決める
依頼前に、資料の管理者と利用部門で閲覧範囲を確認します。全社共有、部署限定、案件の担当者限定など、現在の共有ルールを一覧にします。誰が読めるか分からない資料は、確認できるまで取り込み対象から外します。
| 準備するもの | 確認する内容 |
|---|---|
| 資料と保管先 | どの資料を、どこから取り込むか |
| 閲覧範囲 | 読める部署・担当者と、判断する管理者 |
| 利用者の情報 | ログイン方法、所属変更を管理する場所 |
| 更新の流れ | 資料の追加・削除、権限変更を反映する方法 |
| 検証用の組み合わせ | 読める人と読めない人、それぞれの期待結果 |
一つのファイルに公開範囲の異なる内容が混在している場合は、そのまま取り込む前に分け方を決めます。検索用に資料を段落へ分割するときも、元の資料の閲覧範囲を各断片へ引き継ぐ設計が必要です。
回答文と引用元の両方を検査する
確認するのは回答本文だけではありません。引用元のタイトル、短い抜粋、関連資料の候補、過去の会話にも、閲覧できない情報が出ていないかを調べます。ファイル名だけでも内容が推測できる資料は、タイトルも検査対象にします。
資料が見つからない場合は、閲覧可能な情報では回答できないことを伝え、社内で決めた問い合わせ先へ案内します。アクセスできない特定の資料名を挙げて、存在を知らせる設計にはしません。
仮例:全社向け手順書と部署限定の補足資料
架空の会社で、全社員向けの申請手順書と、担当部署だけが読める補足資料を使うとします。同じ質問に対しても、一般社員には手順書の範囲で答え、担当部署には許可された補足資料も使って答える設計です。
一般社員の回答に補足資料の記述が混ざらないか、引用一覧へ補足資料が出ないかを確認します。一般社員が読める手順書まで除外されてしまうと、検索として役に立ちません。出してはいけない情報と、出すべき情報を両方検査します。
権限変更と取得失敗の後も試す
初期状態で正しく動くだけでは、運用時の検証が足りません。部署異動、担当交代、共有解除、資料削除を想定し、変更が反映されるまでの扱いを確認します。
利用者の所属や資料の権限を取得できないときは、保護対象の検索を止める設計にします。権限不明のまま検索対象を広げて回答する処理を入れないようにします。全社公開資料だけで続けられる場合は、その範囲を事前に決めます。
前の回答を再利用する場合も権限を確認する
同じ質問への回答を保存して再利用する仕組みでは、別の利用者へ同じ結果を返してよいかを確認します。権限変更前の回答や、共有された会話リンクの扱いも検証項目に含めます。
一度表示・保存された情報は、後から権限を変えても回収できない場面があります。過去の出力の保管先と共有範囲を決め、現在の検索権限だけですべて解決したと考えないようにします。
成功条件は許可・拒否・変更後に分ける
検証には、権限別のテスト用アカウントと、機密を含まない模擬資料を使えます。利用者と資料の組み合わせごとに、回答できる範囲、引用してよい資料、回答を控える条件を先に記録します。
許可された情報を正しく探せるか、禁止した情報が出ないか、権限変更後に期待どおり切り替わるかを分けて評価します。通常の検索、検索結果がない状態、権限情報を取得できない状態も試してください。
合格した組み合わせと未検証の組み合わせを残します。限られたPoCで問題が出なかったことを、情報漏えいが絶対に起きない保証へ広げないようにします。確認時間や回答速度も測りますが、権限違反を速度の改善で相殺する評価にはしません。
費用と運用は権限の連携範囲で確認する
費用を相談するときは、資料の数だけでなく、保管先、ログイン方法、権限の管理元、変更を反映したい時間を伝えます。複数の保管先をまたぐ場合や、資料ごとに例外が多い場合は、その確認と連携を含めた見積もりが必要です。
AiPHAのPoC開発サービスは、開発・検証20万円〜、10日でAIエージェントを納品する案内です。金額は対象業務と開発範囲による見積もりです。社内認証との連携や複数の保管先への対応がすべて含まれると決めず、最初に試す範囲と納期を確認してください。AIサービス利用料などの別途費用も確認します。
稼働後は、権限の例外を承認する人、同期失敗を確認する人、資料追加時に再検証する人を決めます。検索や回答の記録にも機密情報が含まれるため、記録を読める担当者と保存期間を決めます。継続保守や追加開発は別途の範囲・費用です。
専用開発の前に資料管理を直したい条件
既存の検索サービスが現在の権限を引き継ぎ、必要な資料を探せるなら、まずその機能で業務が足りるかを試します。専用の回答生成を加えることで減らせる作業を説明できなければ、開発を急ぐ必要はありません。
誰が資料の閲覧範囲を決めるか不明な場合や、所属情報を更新する担当者がいない場合は、その管理を先に整えます。最初から全社の資料を取り込まず、閲覧範囲を確認できる一業務で試す方が検証しやすくなります。
AiPHAの30分の無料相談では、検索したい資料の種類、保管先、利用する部署をもとにPoCの範囲を検討できます。機密資料そのものの共有は、使用するデータと共有方法を確認してから進めます。
