「規程やマニュアルをAIに聞けるようにしたい。ただし、検索した瞬間に他部門の案件資料や人事情報まで出てくるなら、入れられない」。総務・情報システム・法務・各部門のあいだで、社内AI検索の話がこの一点で止まっている会社は少なくありません。この記事は、社内文書をAI検索の対象にしても、いまの閲覧権限が崩れない状態をどう作るか——検索対象の分割、ID・グループとアクセス制御リストの同期、継承と例外、異動・退職・案件終了に伴う失効、引用元の表示、権限変更時の再確認——を、AIに任せる範囲と人が確定する範囲の線引きとあわせて整理します。
社内AI検索の要望は、たいてい具体的な困りごとから出てきます。出張旅費の規程がどこに書いてあるか分からない、設備の操作手順が部門ごとに別のファイルサーバーに散らばっている、過去の類似案件でどう回答したかを探すのに半日かかる。文書を探す時間を減らしたい、という動機ははっきりしています。
ところが検討を進めると、多くの会社で同じ場所に突き当たります。いま探したい文書と、探させたくない文書が、同じ置き場に混ざっているという現実です。共有フォルダには規程と手順書だけでなく、案件ごとの見積や議事録、取引先から預かった仕様書、人事評価や健康情報に関する資料、客先名の入った不適合報告が同居しています。ここに横断検索をかけると、「規程を探しただけなのに、権限のない資料が候補に出る」状態が起こり得ます。だから止まる。止まる理由としては、まったく正当です。
このときに起こりがちなのが、二つの極端です。一方は「権限の整理が終わってから」と言って着手を無期限に先送りすること。もう一方は「まず全文書を入れて、危なそうなものを後から除く」こと。前者は、権限の整理が完了する日は来ないという意味で止まったままですし、後者は、除き漏れが起きたときに元へ戻せません。検索は、これまで別々の場所にあって事実上結合されていなかった情報を、一つの質問で束ねられるようにする仕組みだからです。
この記事が扱うのは、その中間にある実務です。すなわち、いまある閲覧権限を前提として、それを崩さずに検索を成立させるための設計項目——検索対象の分割、権限の同期、継承・例外・失効、引用元の表示、権限変更時の再確認、そしてログ——を、始める前に決めることです。
なお、社内文書を検索して答えさせる仕組み（RAG）そのものの構造、文書の整え方、誤答への備えは社内文書をAIに答えさせる仕組み（RAG）とはで扱っています。また、AIが社内システムを操作するときの実行権限・承認・監査はAIエージェントの権限設計の担当です。本記事はその二つの間にある、検索する瞬間に「誰にどの文書が見えるか」だけに絞ります。
閲覧権限が崩れる、という言い方は曖昧なので、先に具体化しておきます。AI検索において、権限外の情報が利用者に届く経路は、大きく四つあります。設計の議論は、この四つを別々に扱うと噛み合いやすくなります。
もう一つ、単体の文書区分では説明できない論点があります。組み合わせによる推測です。組織図と案件名と見積の存在、稟議の件名と設備投資の時期——それぞれは所属部門で見てよい情報でも、横断検索で束ねると別の意味を持つことがあります。区分の確認を「ファイル単位で機密か否か」で終わらせず、「何と何が同じ検索範囲に入るか」まで見る必要があるのは、このためです。
最初の設計項目は、文書区分の切り分けです。「社内文書を全部対象にする」から始めると、権限の設計もログの設計も後追いになります。対象候補を区分ごとに書き出し、それぞれについて検索対象にするか・誰まで見せるか・そもそも同じ基盤に載せるかを決めます。下表は出発点として使える区分の例です。自社の文書管理の実態に合わせて足し引きしてください。
| 文書区分 | 含まれやすい情報の例 | 検索対象の初期設定（例） | 対象にする前に決めること |
|---|---|---|---|
| 全社規程・就業規則・社内ルール | 服務規律、経費精算、情報の取扱、稟議・決裁の基準 | 対象（全社） | どれが有効版か。廃止版・改訂中の草案を同じ範囲に入れない切り分け |
| 業務手順書・作業標準・マニュアル | 工程手順、設備操作、検査基準、システム操作 | 対象（部門または職種で限定） | 部門固有の手順を他部門の検索結果に出してよいか。旧版・現場控えの扱い |
| 案件資料（提案・見積・議事録・稟議） | 客先名、価格、取引条件、担当者のやり取り、社内の検討経緯 | 原則対象外（案件の担当者に限定） | 案件単位のグループで区切れるか。案件終了後に誰まで見てよいか |
| 取引先から預かった図面・仕様書・規格書 | 形状・公差・受入基準・要求事項、取引先名と図番 | 原則対象外（別基盤・別権限で扱う） | 契約で許される処理の範囲。社内の閲覧者の限定と記録（外部AIに送れない資料の設計を参照） |
| 人事・個人情報（評価、処遇、健康、応募者） | 氏名と評価・処遇・健康状態・家族情報の組み合わせ | 対象外 | 同じ検索基盤に載せない判断を先に置く。載せる場合の法令・社内規程上の根拠と範囲 |
| 品質記録・不適合・クレーム対応 | 不適合の内容、客先名、是正処置、原因調査の経緯 | 条件付き（客先が特定できる記述の扱いを決めたうえで、品質部門に限定など） | 客先名をどう扱うか。監査・法令上の保存要件との整合 |
| 組み合わせで推測可能になる情報 | 組織図＋案件名＋見積の存在、稟議の件名＋設備投資の時期 | 個別判断 | 単体では区分内でも、横断検索で束ねると推測できる組み合わせがないか |
この表を作る作業の副産物として、たいてい「置き場が間違っている文書」が見つかります。全社共有フォルダに案件の見積が置かれている、部門フォルダに人事資料が紛れている、といった類です。AI検索を入れるかどうかにかかわらず、そこは現状でも権限が緩い場所です。検索対象を決める作業は、この意味で既存の権限の棚卸しと同じ作業になります。文書そのものの整い方（版の混在、重複、古い記載）が回答の質を決める点はRAGの基本とナレッジベースの鮮度維持で扱っています。
区分を決めたら、次はそれを検索の実装側でどう保つかです。以下は、導入前および構成の検討時に一つずつ埋めていく確認項目です。「崩れたときに起こること」の欄は、なぜその項目を確認するのかを社内で説明するときにも使えます。
| 確認項目 | 何を確認するか | 崩れたときに起こること |
|---|---|---|
| 文書源（どこから取り込むか） | ファイルサーバー、文書管理システム、社内Wiki、メール、チャットなど取込元ごとに、元の文書へどんな権限が付いているか。その権限は実態と合っているか | 元の権限が実態より緩い置き場から取り込むと、その緩さがそのまま検索範囲になる |
| ID・グループ（誰が誰か） | 利用者IDが所属部門・職位・案件アサインとどう紐づくか。共有アカウント・退職者ID・外部委託者IDの有無 | 共有アカウント経由だと、誰の権限で検索したのかを後から説明できない |
| ACLの同期（権限の反映） | 元の文書のアクセス制御リストを検索インデックスへどう写すか。同期の頻度、失敗の検知方法、失敗時の既定の扱い | 同期が遅れた・失敗した間、権限外の文書が候補に出る。既定が「見せる」側だと影響が大きい |
| 継承（フォルダ・案件・組織の階層） | 上位フォルダ・案件・部門から権限をどう継承するか。継承が途中で切れている箇所をどう洗い出すか | 階層の途中で継承が切れ、意図せず広い範囲に見える文書が生まれる |
| 例外アクセス（特例の付与） | 期限付きの一時付与ができるか。誰が申請し、誰が承認し、いつ自動で切れるか。記録は残るか | 「一時的に」付けた権限が残り続け、次の棚卸しまで誰も気づかない |
| 失効（異動・退職・案件終了・契約終了） | 権限が落ちるきっかけを人事・案件の手続きと結びつけられるか。落とし忘れを見つける仕組みがあるか | 異動後も前部署の文書が検索できる。退職者IDや終了案件のグループが生き続ける |
| 引用元の表示 | 回答に文書名・版・章番号・保存場所を出すとき、その表示自体が権限外情報になっていないか。件数や「権限がありません」の表示も含む | 本文は出ないのに、文書名・存在・件数から内容が推測できる |
| 権限変更時の再確認 | 権限が変わったとき、検索インデックス、キャッシュ、会話履歴、保存済み回答をどう扱うか。再インデックスの契機と所要 | 権限を落とした後も、キャッシュや過去の会話から読めてしまう |
| ログ | 誰がいつ何を検索し、どの文書が候補に出て、何を参照したかを追えるか。ログ自体の閲覧権限・保存期間・廃棄 | 想定外の参照が起きても経緯を説明できない。逆に、ログが機密の複製になり第二の漏えい経路になる |
この表の使い方は二通りあります。一つは自社の現状を埋めること。もう一つは、埋まらない欄をそのままベンダーや情報システム部門への質問リストにすることです。とくに「同期の失敗時の既定」「引用元表示の抑止」「権限変更後の再インデックス」の三つは、製品説明では触れられないことが多いのに、実際の事故の起点になりやすい箇所です。
アクセス制御の確認観点をより体系的に照らしたい場合は、NISTのSP 800-53 Rev.5のアクセス制御・監査関連の管理策や、AI Risk Management Framework 1.0が、抜けの点検に使えます。いずれも本記事はこれらへの準拠や認証、安全性の保証を主張するものではなく、自社の確認項目に漏れがないかを照らす観点として参照しています。情報システム部門の審査に向けて資料を整理する段階の視点はオンプレAIの情シス審査準備で扱っています。
実装の形はいくつかありますが、考え方としては、検索範囲を「利用者の属性」と「文書の属性」の突き合わせで決めるのが基本です。実務では次の三層で整理すると設計しやすくなります。
注意したいのは、部署と案件は掛け合わせで効くということです。同じ部署でも担当案件が違えば見える範囲は違い、逆に部署をまたいでも同じ案件のメンバーなら見える、という構造になります。「部署で分ければ足りる」と単純化すると、案件層の権限が部門全体に広がります。逆に案件だけで分けると、部門共通の手順書が誰にも見えなくなります。両方を持たせる前提で設計してください。
もう一点。検索範囲の分割は、文書を物理的に分けることと同じではありません。同じ基盤の中で論理的に分ける方法もありますし、人事情報や取引先の預かり資料のように、そもそも別の基盤・別の権限で扱うと決めたほうが説明しやすい区分もあります。どちらを選ぶかは、事故が起きたときに影響を止めやすいのはどちらか、監査で説明しやすいのはどちらか、で判断すると決めやすくなります。
権限設計でいちばん手間がかかるのは、初期設定ではなく、その後の変化です。組織は変わり、人は異動し、案件は終わり、特例は付与されます。ここを運用に乗せられるかどうかが、導入後半年で「結局みんな使わなくなった」か「権限が緩みっぱなし」かの分かれ目になります。
フォルダ階層や案件の階層から権限を継承する構成では、どこかで継承が切られていることがあります。過去に「この人にも見せたい」と個別設定した名残、移動やコピーで権限が付け替わった箇所、統廃合された部門のフォルダなど、理由はさまざまです。検索対象に取り込む前に、継承が切れている箇所を一覧化して、意図した設定かどうかを確認します。ここは、AIに一覧を作らせて人が判断する分担が向いている作業です。
「今回の監査対応のあいだだけ」「引き継ぎが終わるまで」という一時的な付与は、業務上どうしても発生します。問題は、それが自動で切れない場合です。設計としては、例外アクセスには付与の申請・承認・理由・期限・自動失効を一組で持たせます。期限を入力しないと付与できない仕組みにしておくと、運用の負荷がいちばん小さくなります。承認をどこに挟むかの一般的な考え方は任せる範囲と承認ポイントの設計を参照してください。
異動・退職・案件終了・委託契約終了は、いずれも別の部署が管理する手続きです。権限の失効をその手続きの一部として組み込めるか（申請フローの中に権限の変更が入っているか）を確認します。組み込めない場合は、部門長・案件責任者が定期的に自部門の権限一覧を確認する棚卸しで補います。あわせて、退職者IDや終了案件のグループで検索が実行されていないかをログで点検する仕組みを持つと、落とし忘れに気づけます。
見落とされやすいのがここです。権限を落としても、検索インデックス、キャッシュ、過去の会話履歴、保存済みの回答、エクスポートしたファイルに内容が残っていれば、そこから読めてしまいます。権限変更を検知して再インデックスが走るのか、走るとしてどれくらいで反映されるのか、その間の扱いはどうなるのか。会話履歴に含まれた文書の断片は、権限変更時にどう扱われるのか。これらは製品ごとに挙動が違うので、必ず個別に確認します。監査に耐える記録の残し方はAIエージェントの監査証跡で扱っています。
構成の選択肢として、ローカルPC、社内ネットワーク上のサーバー、オンプレミス、閉域、クラウドとの併用（ハイブリッド）は、要件を確認したうえで選べます。取り扱う文書区分、契約や社内規程の制約、既存のネットワークとサーバーの構成、運用できる人員によって妥当な構成は変わるので、先に構成を決めてから文書を合わせるのではなく、区分と制約を書き出したうえでその中から選ぶ順序が現実的です。構成ごとの費用や更新の違いはローカルLLMとクラウドLLMの比較で整理しています。
そのうえで、本記事の主題との関係をはっきりさせておきます。ローカルや閉域が扱うのは「社外へ出るか」という軸であり、閲覧権限は「社内の誰に見えるか」という別の軸です。前者を閉じても後者は自動的には解決しません。むしろ社内で完結する構成では、次のリスクが自社側に残ります。
機密性の高い現場データを前提としたAI構成の考え方の全体像はバーティカルAI×セキュリティで扱っています。本記事はその中の、社内での見え方の設計に絞った位置づけです。対象が社内文書ではなく、社外の相手から預かったデータである場合——たとえば物流・3PLで荷主から預かった出荷指示・在庫・届け先データ——は、閲覧権限の手前に契約上の許可範囲の確認と荷主別の分離が加わります。その設計は荷主データを外部AIに送れない場合の設計が扱っています。
権限設計とログ設計の前提として、仕組みが担う範囲を先に確定しておきます。ここが曖昧なまま始めると、「AIがそう言ったから」で運用され、権限の設計思想が現場で薄れていきます。
| 工程 | AIに任せられると考えられる範囲 | 人が確定する範囲 |
|---|---|---|
| 探す | 利用者の権限の範囲内で、条件に合う規程・手順書・記録の候補を挙げる | どの文書区分を検索対象にするかの決定（03節） |
| 示す | 回答に引用元（文書名・版・章番号・該当箇所）を添えて表示する | その引用元が今回の場面に適用されるかの判断 |
| 欠落を挙げる | 該当する記載が見つからない、版が複数ある、根拠が古いといった欠落・矛盾の指摘 | どの版が有効版かの確定、廃止・改訂の判断 |
| 下書き | 回答文、取引先・他部門への確認依頼、手順書の改訂案、権限棚卸しリストの下書き | 社外・他部門へ回答してよいかの公開可否と、最終承認 |
| 権限の扱い | 設定された範囲に従い、権限外の候補を結果・要約・引用元から除く | 例外アクセスの付与・承認・期限の設定、権限設計そのものの変更 |
| 記録 | 検索・参照・提示の記録を残す | ログの保存期間、閲覧できる人の範囲、廃棄の決定 |
| 判断 | 担わない（材料の提示にとどめる） | 法務・品質・安全・人事・顧客回答に関わる判断と、その責任 |
この表で押さえたいのは、いちばん下の行です。AIの出力は探索の起点と下書きであって、権限や有効版の根拠ではありません。「AIが候補に出さなかったから該当なし」と扱うと、権限の絞り込みが強すぎて必要な文書に届いていない場合でも気づけません。逆に「AIが出したから見てよい文書だ」と扱うと、権限の設定漏れがそのまま運用に流れます。どちらの向きにも、人が確かめる工程を残します。
ここまでの設計項目を全部揃えてから着手する、という進め方は現実的ではありません。次の順で、確かめながら広げるのが実務的です。
検索・照合の先にある業務——問い合わせ対応、規程改訂の準備、案件資料の整理——へ広げていく際の全体像はAI業務コーディネーターで紹介しています。
「そのまま反映される」と考えて始めるのは危険です。AI検索の側は、取り込んだ文書に付いていたアクセス制御リストを検索インデックスへ写して利用者の権限と突き合わせる構造になりますが、写す処理には頻度があり、失敗もします。確認すべきなのは、同期の頻度、同期が失敗したときの既定の扱い（既定が「見せる」側に倒れていないか）、元の置き場の権限がそもそも実態と合っているか、共有アカウントや退職者IDが残っていないか、の四点です。とくに元の権限が実態より緩い共有フォルダから取り込むと、その緩さがそのまま検索範囲になります。権限の同期は仕組みの設定作業であると同時に、既存の権限の棚卸し作業でもある、という前提で計画してください。
文書区分を先に書き出し、区分ごとに検索対象・対象外・条件付きを決めるところからです。全社規程や就業規則のように全社員が見てよい文書と、案件資料や部門固有の手順書のように範囲を絞る文書と、人事情報のようにそもそも同じ検索基盤に載せない文書を分けます。そのうえで、部署別は既存の組織・グループに、案件別は案件単位のグループに検索範囲を対応させます。実務で詰まりやすいのは案件別のほうで、案件のアサインが台帳として管理されていないと権限の根拠が作れません。また、部署と案件は掛け合わせで効きます（同じ部署でも担当案件が違えば見える範囲は違う）。まず一つの部門と一つの案件で、権限どおりに候補が絞られるかを確かめてから広げるのが現実的です。
なくなりません。ローカルや閉域の構成が扱うのは「社外へ出るか」という軸で、閲覧権限は「社内の誰に見えるか」という別の軸です。外部送信を止めても、社内の誰もが人事資料や他部門の案件資料を検索できる状態は残ります。むしろ社内完結の構成では、過大な権限で動くサービスアカウント、権限同期の漏れ、期限を切らずに付けた例外アクセス、ログへの機密の複製、モデルや検索インデックスの更新、バックアップの取り扱い、外部から受け取ったファイル由来の指示の混入、出力の持ち出し、障害時の縮退といったリスクが自社側に残ります。ローカル・社内サーバー・オンプレ・閉域・ハイブリッドは、要件を確認したうえで選ぶ構成の候補であって、それ自体が権限設計の答えにはなりません。
落とし忘れをゼロにする方法はない前提で、落ちるきっかけと、落ちていないことに気づく仕組みを二重に用意します。きっかけの側は、人事の異動・退職の手続きや案件の終了処理と、権限の失効を同じ流れに載せることです。仕組みの側は、例外アクセスに期限を必ず設定して自動で切れるようにすること、部門長・案件責任者が定期的に自部門の権限一覧を見る棚卸しを回すこと、退職者IDや共有アカウントで検索が実行されていないかをログで確認することです。あわせて、権限を落とした後の後始末も決めておきます。検索インデックス、キャッシュ、過去の会話履歴、保存済みの回答に、落とす前の内容が残っていれば、そこから読めてしまいます。権限変更は「付け替えて終わり」ではなく、再インデックスと履歴の扱いまでが一組です。
本文の閲覧だけを止めて、候補の一覧や引用元の表示を止めていない場合に起こります。AI検索は回答に根拠を添えるため、文書名・版・章番号・保存場所といった情報を引用元として提示します。このとき、文書名そのものが機微な情報を含んでいることがあります（客先名や交渉内容がファイル名に入っている、案件のコード名で開発中の製品が推測できる、など）。同じことは「該当する文書はありますが権限がありません」という表示でも起こり、存在の有無が漏れます。対策は、権限外の文書を検索結果・要約・引用元・件数のいずれにも現れないように扱うことと、文書名やフォルダ名に機微な情報を書かない運用ルールを併せて決めることです。単体では区分内の情報でも、横断検索で束ねると推測できる組み合わせが生まれる点も同じ理由で確認します。
AIに任せやすいのは、利用者の権限の範囲内で条件に合う文書の候補を挙げること、回答に引用元（文書名・版・章番号・該当箇所）を添えて示すこと、該当する記載が見つからない・版が複数ある・根拠が古いといった欠落や矛盾を指摘すること、回答文や確認依頼や棚卸しリストの下書きを作ることまでです。人が確定する範囲として残すのは、どの文書区分を検索対象にするかの決定、どの版が有効版かの確定、社外・他部門へ回答してよいかの公開可否、例外アクセスの付与と承認と期限、法務・品質・安全・人事・顧客回答に関わる判断、そして最終承認です。権限設計そのものの変更をAIに任せないことも、この線引きに含めます。AIの出力は探索の起点と下書きであって、権限や有効版の根拠ではありません。
仕組みの話をする前に、対象にしたい文書のデータ区分、いま付いている閲覧権限、検索対象にする範囲、引用元をどこまで見せるか、承認とログの残し方——この五つを一緒に棚卸しするところから始められます。埋まらない欄は、そのまま情報システム部門やベンダーへの質問リストになります。区分や権限の実態から、社内AI検索が時期尚早と判断した場合は、そのように申し上げます。
文書区分・権限・検索対象の棚卸しを相談する