社内AI検索の閲覧権限をどう守るか｜部署ごとのアクセス権を保ったまま社内文書を横断検索する設計

横断検索を止めるのは、精度ではなく「見えてはいけない文書」

社内の文書をまとめて検索できるようにする取り組みは、動くところまでは比較的早く進みます。止まるのはたいてい公開の直前で、理由も同じところに集まります。人事評価の記録、与信や取引条件の資料、係争中の案件のやり取り、給与や個人の事情に触れる文書。これらが誰の質問にも答える形で検索できてしまうと、便利さの話ではなく事故の話になります。

厄介なのは、この失敗が静かに起きることです。誤った回答なら読んだ人が気づいて報告しますが、本来見えない文書が正しく要約されて返ってきた場合、質問した側は不審に思いません。「よく調べてくれた」で終わり、漏れたことは誰も知らないままになります。気づくのは、たまたま自部署の情報が他部署の口から出たときで、その時点では既にどれだけ見えていたかを追えなくなっていることが多いものです。

そのため、権限は精度の改善と同じ列に並べて扱えません。精度は公開してから直せますが、権限は公開する前に決まっていなければならず、後から足すと取り込みの仕組みごと作り直しになります。取り込む資料の選び方や更新への追随を含めた全体の設計は「社内文書検索をAIで横断する」にまとめています。この記事では、そのうち権限の部分だけを詳しく見ていきます。

既存の権限をそのまま使えるところと、使えないところ

最初に確かめるのは、いま使っているファイルサーバーやクラウドストレージの権限設定を、どこまでそのまま持ち込めるかです。権限を一から設計し直す必要はほとんどありません。ただし、既存の設定には検索側へ持ち込めない形のものが混ざっています。

既存の権限の付き方	検索側へ持ち込めるか	公開前にすること
部署や役職のグループに付いている	そのまま使える	グループの入れ子を展開して保存できるか確認する
個人名で1件ずつ付いている	追随できない	グループへ寄せる。寄せられない文書は対象から外す
入れ子のグループ（部の下に課がある）	展開すれば使える	何段までたどるかを決める。途中で止めると見えるはずの文書が出ない
リンクを知っていれば閲覧可の共有設定	グループとして表現できない	対象にするか外すかを先に決める。既定は外す
フォルダから継承された権限	使えるが変化に弱い	継承元が変わったときに再取得する経路を用意する
権限の設定が無く、事実上全員が見られる	そのまま使うと全社公開になる	内容を確認し、限定すべきものに権限を付けてから取り込む

上から3つは仕組みの話ですが、下の3つは公開前の作業が発生します。とくに手前で詰まりやすいのが、個人名で付いた権限です。「担当者だけが見られればよい」という運用で作られた文書は、その人が異動しても設定が残り、後任には見えません。この状態のまま索引へ取り込むと、検索側は「本人にしか見えない文書」として持ち続けます。害はありませんが、後任が探しても出てこないため、権限のせいだと気づかれずに「検索が使えない」という評価になります。

権限が無いまま置かれている文書も同様に扱いが要ります。共有ドライブの奥に置いてあるから見られていない、という状態は権限ではありません。検索できるようにした瞬間に、全員から到達できる文書になります。取り込みの対象を決めるときは、置き場の深さではなく設定を見ます。役割やグループへ権限を付け直す進め方は「社内の文書管理をAIエージェントで回す」にあります。

検索の前で絞るか、回答の後で伏せるか

権限を効かせる場所は、大きく2つに分かれます。検索する前に、質問した人が見てよい文書だけへ対象を絞る方式と、全体から検索して回答を作り、そのあとで見せてはいけない部分を伏せる方式です。

見るところ	検索の前で絞る	回答の後で伏せる
権限を判定する時点	検索の実行前	回答の生成後
索引に持つもの	本文と、閲覧できるグループの一覧	本文のみ
見えない文書の扱い	候補にすら入らない	いったん読まれてから除かれる
漏れが起きる箇所	権限情報の取り込み漏れ、グループ展開の不足	伏せ忘れ、要約への混入
権限変更への追随	索引の更新が要る	判定のたびに最新を見られる
回答が返るまでの速さ	件数が増えても大きく変わらない	候補ごとに判定が要り、遅くなりやすい
既定として選びやすいか	選びやすい	単独では選びにくい

原則として、検索の前で絞る方式を土台にします。 理由は漏れ方の性質が違うからです。前で絞る方式で失敗すると、見えるはずの文書が出てこない、という形で表に出ます。利用者から「あるはずの規程が出ない」と報告が来るため、気づけます。一方、後で伏せる方式の失敗は、見えてはいけない文書が出る形で表れ、報告されません。同じ確率で間違えるとしても、後から気づけるかどうかが違います。

後で伏せる方式には、それ単独では埋まらない穴もあります。回答を作る段階でモデルが見えない文書を読んでいるため、文中の固有名詞を伏せても、要約された内容そのものは残ります。「該当する評価は今期の分だけです」といった言い方は、伏せる対象の語を含まないまま情報を伝えます。伏せる処理は、名前や番号のような形の決まった値には効きますが、要約には効きません。

とはいえ、前で絞る方式にも遅れの問題があります。索引に持った権限は取り込み時点の状態なので、その後の変更が反映されるまで古いままです。ここを補う形として、前で絞ったうえで、回答に使う文書だけ置き場へ最新の可否を問い合わせる組み合わせがあります。候補を数件まで絞ったあとの確認なので、全件を問い合わせる場合ほど遅くなりません。権限がよく変わる文書を含むなら、この一段を足す価値があります。

質問者の所属を入れ子まで展開して対象を絞り、回答に使う文書だけ置き場へ最新の閲覧可否を確認する。
候補が残らないときは件数も示さない。

漏れは本文以外の経路から起きる

本文を返さない作りにしていても、情報が伝わる経路は残ります。設計のときに見落としやすいものを挙げます。

検索結果の件数「該当が3件見つかりました」という表示は、見えない文書を数に含めていると、そこに何かがあることを伝えます。権限で外した文書は件数からも除きます
ファイル名と冒頭の抜粋一覧に出るタイトルだけでも、「〇〇社との取引条件見直し」のように中身が推測できます。本文と同じ権限で絞ります
要約や再利用のための中間データ取り込みの過程で作った要約や、よくある質問への回答を作り置きしている場合、その中間データにも元の文書の権限を引き継がせます。ここを素通しにすると、権限を持たない人が要約経由で内容へ到達します
会話の履歴前の質問への回答を後続の質問で参照する作りだと、権限のある人が引き出した内容が、共有された会話の中に残ります。会話の共有機能を出すなら、共有先の権限で見えるかを再判定します
利用状況の分析画面検索された語や返された文書名を集計して見せる画面は、それ自体が見えない文書の存在を伝えます。閲覧できる人を限ります
問い合わせ元の取り違え社内チャットのボットのような形で受ける場合、質問した本人ではなくボットの権限で検索してしまう作りになりがちです。権限は必ず質問した人のもので判定します

最後の項目は、実装の都合で起きやすい失敗です。置き場へ接続するための共通のアカウントを1つ用意し、それで全文書を読める状態にしてから索引を作る、というのは取り込み側では自然な作りです。その同じアカウントで検索まで実行してしまうと、質問者が誰であっても全文書が対象になります。取り込みと検索で使う権限を分けて考えることが、この作りを避ける前提になります。

検索結果が返らないときに何を出すかも決めておきます。「権限がないため表示できません」と返すと、そこに文書があること自体は伝わります。存在を知られてよい種類の文書なら申請の導線として有効ですが、案件の存在そのものが機微な場合は、該当なしと同じ返し方にします。この線引きは文書の種類ごとに決めるもので、一律にはできません。

運用で崩れるのは、作ったあとの人の動き

権限設計が公開時点で正しくても、そのままの状態は続きません。崩れ方はいくつかの型に分かれます。

起きること	どう崩れるか	対応
部署異動	前の部署の文書が見え続ける、または新しい部署の文書が見えない	人事情報の更新を権限へ反映する経路を持ち、反映までの許容時間を決める
退職	個人名で権限が付いた文書が誰からも見えなくなる	退職の処理に、その人が権限を持つ文書の引き継ぎ確認を入れる
兼務・出向	複数の所属を持つ人の範囲が広がりすぎる	兼務は権限の足し算になる前提で、機微な文書は兼務者を含むかを個別に決める
組織変更	権限を持つグループが消え、誰も見られない文書が残る	廃止するグループに紐づく文書を、廃止の前に一覧化する
業務委託・派遣の終了	契約終了後もアカウントと権限が残る	契約の期限とアカウントの期限を揃え、期限を過ぎたら検索の対象からも外す
案件やプロジェクトの終了	一時的に広げた権限が戻らない	期限付きで権限を付け、期限が来たら自動で戻す。戻せない場合は棚卸しの対象にする

このうち、退職者の文書は扱いを決めておかないと後から動けなくなります。個人名の権限が残ったまま本人のアカウントが消えると、権限を持つ主体が存在しない文書になります。索引の上では「誰にも見えない文書」として残り続け、検索しても出てきません。かといって管理者の判断で全社公開へ変えると、中身によっては見せてはいけないものが混ざります。退職の手続きの中で、その人が単独の権限を持つ文書を一覧にし、引き継ぐ人か部署のグループへ付け替える工程を入れておくのが現実的です。

反映までの遅れをどこまで許すかも、種類ごとに決めます。異動が翌営業日に反映されれば足りる文書と、当日中に見えなくならないと困る文書は違います。全体を同じ間隔で回すより、機微な種類だけ短い間隔で見直すほうが負荷は抑えられます。ここで決めた許容時間は、そのまま「反映が止まったときにどれくらいで気づく必要があるか」の基準にもなります。

誰がいつ確認するかを、担当と周期で決める

権限は一度設計すれば終わるものではなく、確認の担当と周期を決めて初めて保たれます。確認する人を情シスだけにすると、文書の中身が分からないため「この権限が正しいか」を判断できません。中身を知っているのは持ち主の部署です。

確認すること	誰が	どれくらいの周期で
権限情報の同期が止まっていないか	仕組みの運用担当	毎日。最後に同期した時刻を記録し、止まったら通知する
見えない文書が回答に混ざっていないか	仕組みの運用担当	抜き取りで毎月。機微な種類の文書を指定して質問し、返らないことを確かめる
個人名で権限が付いた文書が増えていないか	情シス	毎月。件数の推移で見て、増えていれば発生源の部署を確認する
部署の文書の権限が実態と合っているか	文書を持つ部署の責任者	四半期ごと。一覧を渡して確認してもらう
一時的に広げた権限が戻っているか	情シス	四半期ごと。期限切れの権限を一覧にする
対象にする置き場と種類の線引き	情シスと各部署の責任者	半年ごと、または組織変更のとき

2つ目の抜き取り確認は、仕組みが正しく動いているかを外側から見る唯一の手段になります。設定を1件ずつ点検しても、実装の不備で権限が効いていない場合は見つかりません。権限を持たないアカウントから、見えないはずの文書にしか書かれていない内容を質問し、返らないことを確かめます。この確認用の質問をいくつか用意しておくと、仕組みを変更したあとの回帰確認としてそのまま使えます。

確認の記録は残します。いつ誰が何を確認し、何件の指摘が出て、いつ直したか。監査で聞かれたときに答えられるようにするためでもありますが、指摘の傾向から、権限の付け方そのものを直すべき部署が見えてきます。情シスが生成AIサービスを審査する際の観点は「生成AIのセキュリティ審査チェックリスト」にまとめており、権限と記録の扱いはそこでも確認項目に入ります。

公開してよいかを、権限の観点で判断する

自社の社内AI検索を公開してよいかどうかは、次の項目が埋まっているかで判断できます。埋まっていない項目があるなら、その項目に関わる文書の種類を対象から外して範囲を狭めれば、公開は進められます。全部を待つ必要はありません。

対象にする置き場ごとに、権限がグループに付いているかを確認した
個人名の権限が残る文書を、寄せるか対象外にするかを決めた
グループの入れ子を何段まで展開するかを決め、そのとおりに動くことを確かめた
権限で外した文書が、件数にもファイル名にも出ないことを確かめた
取り込み用のアカウントと、検索時に使う権限が分かれている
権限の変更が索引へ反映されるまでの許容時間を、文書の種類ごとに決めた
同期が止まったときに通知が届く先を決めた
退職と異動の手続きに、権限の引き継ぎ確認が入っている
誰が何を検索し、何が返ったかの記録を残している
部署の責任者が権限を確認する周期と、確認する一覧の形を決めた

範囲を狭めて始める場合、最初に外しやすいのは人事と経理の一部、案件ごとの取引条件、係争に関わる文書です。これらは権限の判断が難しいだけでなく、誤ったときの影響も大きいため、仕組みが安定してから足すほうが進めやすくなります。どこまでを自社で持ち、どこから外部に頼るかを含めた全体の考え方は「生成AI・AIエージェントの内製化とは」を参照してください。検索の当たり外れそのものが原因で答えが出ないケースとの切り分けは「社内RAGの回答精度が上がらないときに見る順番」にあります。権限で外れているのか検索が当たっていないのかは、利用者からは同じ「出てこない」に見えるため、切り分けの手順を先に決めておくと問い合わせの対応が短くなります。

まとめ：社内AI検索の権限設計で押さえる要点

権限の失敗は、誤った回答と違って報告されない。公開してから直す前提では設計できない
既存の権限のうち、グループに付いているものはそのまま使える。個人名で付いたものと、リンクを知っていれば見られる設定は持ち込めない
土台は検索の前で絞る方式にする。回答の後で伏せる方式は、失敗が見えない形で表れるうえ、要約に残った内容までは消せない
権限がよく変わる文書があるなら、回答に使う数件だけ置き場へ最新の可否を問い合わせる一段を足す
本文以外に、件数・ファイル名・要約の中間データ・会話の履歴・分析画面という経路がある。すべてに同じ権限をかける
質問した人の権限で判定する。取り込み用のアカウントで検索すると、全文書が対象になる
崩れるのは異動・退職・組織変更・契約終了といった人の動きの側。反映の経路と許容時間を種類ごとに決める
確認は情シスだけでは終わらない。中身を知る部署の責任者が四半期ごとに見る形まで含めて設計する

Augueでは、社内文書を横断して検索できるようにするAIエージェントの開発に対応しており、既存の権限をどこまで引き継げるかの確認から、公開してよい範囲の線引きまで一緒に設計できます。自社の社内AI検索を権限の観点でどう進めるか整理したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

クラウドストレージに付属するAI検索を使えば、権限設計は自前でしなくてよいですか？

対象がそのサービス内の文書だけで完結するなら、権限はサービス側の設定がそのまま効くため、自前で持つ部分は小さくなります。自前の設計が必要になるのは、別の置き場や社内システムの中身を一緒に検索できるようにした時点です。取り込み側で権限を持つ必要が出るため、対象を広げる前にどこまでを1つのサービス内に寄せられるかを先に見ます。

権限を保った形で作るには、どれくらいの期間がかかりますか？

対象の広さで変わるため一律の目安は出せません。見積もる前に測るのは、対象にする置き場の数、権限がグループではなく個人名で付いている文書の件数、入れ子になっているグループの深さの3つです。個人名の権限が多いほど、仕組みを作る前に権限そのものを整える作業が増え、そちらが期間を決めます。

誰が何を検索したかの記録は、どれくらい残せばよいですか？

自社の情報管理規程で定めた保存期間に合わせるのが基本ですが、それとは別に、権限の点検の周期を1回はまたぐ長さを確保します。点検で設定の誤りが見つかったとき、その設定がいつから続き、その間に誰が該当の文書へ到達したかをたどるためです。周期が四半期なら、記録も四半期を超えて残っている必要があります。

全員が見てよい文書だけに絞って始めると、何に答えられなくなりますか？

全社共通の規程や手順、社内の連絡先といった問い合わせは、その範囲でおおむね答えられます。答えられなくなるのは、部署の中だけで共有している運用の細部と、案件ごとの経緯です。この2つは問い合わせの件数が多い領域でもあるため、限定して始める場合は、答えられなかった質問を記録して、次に広げる範囲を決める材料にします。