メインコンテンツへスキップ

社内文書RAGの権限設計|部署ごとに見える文書を分ける考え方

文書単位のアクセス制御と、回答に含めてよい情報の制御は別の問題である。部署別権限の基本と落とし穴を整理する。

この記事で分かること/分からないこと

  • 分かること: 部署ごとに文書の閲覧範囲を分ける、という設計の基本的な考え方
  • 分かること: 検索結果を絞るだけでは権限設計として不十分な理由
  • 分からないこと: 自社で部署別アクセス制御を実装・運用した実績(未実装のため)
  • 分からないこと: 特定の検索基盤・SaaS製品でこの設計をどう実装するか

部署で文書を分けるとは、何をすることか

社内文書RAGで最初に検討される権限設計は、文書に部署のタグを付け、検索(retrieval)の段階でユーザーの所属部署に一致する文書だけを対象にする、という方式である。索引の中に文書本体だけでなく「どの部署が見てよいか」という属性を持たせ、質問が来るたびにその属性でフィルタしてから検索をかける。仕組みとしては単純で、既存の検索基盤にメタデータフィルタの機能があれば実装できる範囲に収まる。ここまでが、権限設計の入り口として最初に手を付けられる部分である。

検索結果を隠すだけでは足りない理由

ただし、検索結果を部署で絞ることと、権限を正しく設計できていることは同じではない。RAGは検索でヒットした文書をそのまま返すのではなく、要約したり言い換えたりして回答を生成する。この生成の過程を通ると、元の文書そのものをユーザーに見せていなくても、文書に書かれていた情報が回答の文面に出てくることがある。たとえば部署Aの文書だけを検索対象にしていても、その文書の中に部署Bに関する記述が含まれていれば、要約の過程でその記述が答えに反映されうる。さらに、個々には問題のない複数の許可済み文書を横断して要約すると、単独の文書からは読み取れない全体の傾向が浮かび上がることもある。つまり「どの文書を検索対象にするか」という文書単位のアクセス制御と、「生成された回答に何を書いてよいか」という回答内容の制御は、別のレイヤーの問題として別々に設計する必要がある。前者だけを作って権限設計が完了したと考えるのが、最も起きやすい見落としである。

部署をまたぐ文書がある場合の難しさ

実際の社内文書には、複数の部署が共同で使う文書や、部署間の受け渡しのために作られた文書、組織変更で所属部署そのものが変わる文書が存在する。1つの文書に1つの部署タグを割り当てるという単純な設計では、こうしたケースを表現しきれない。誰が文書にタグを付け、誰がそのタグを見直すのかという運用上の役割を先に決めておかないと、タグ付けが更新されないまま実態と乖離していく。

自社の実装との違い

自社の実装は、複数の契約先(テナント)のデータを混在させないために、索引をテナント単位で分離する構成をとっている。確定配信で実行時に参照する索引はD1に置き、テナントIDで分けて引く設計である。これは契約単位でデータを隔てるための分離であり、1つの組織の中で部署ごとに文書を分けるという問題とは、そもそも分けようとしている粒度が違う。したがって、この構成をそのまま部署別権限の答えとして流用することはできない。自社に社内文書RAGの実測は無く、テナント分離までしか実装しておらず、部署別権限の運用実績は無い。

導入前に決めておくべきこと

部署別の文書アクセス制御を検討する際は、次を先に決めておく必要がある。タグ付けの運用フロー(誰が付け、誰が見直すか)、組織変更や異動が起きたときに索引側の反映がどれだけ遅れうるか、そして検索結果のフィルタだけでは防げない回答内容の漏れをどこで確認するかである。最後の点については、生成された回答を公開する前に人が確認するという設計も選択肢になる。

よくある質問

Q1. 部署ごとに検索結果を絞れば、権限設計としては十分か

十分ではない。検索対象を絞ることは文書単位のアクセス制御であり、要約や言い換えを通じて情報が漏れることを防ぐには、回答に含めてよい内容を別に制御する必要がある。

Q2. 複数部署にまたがる文書はどう扱うべきか

1文書1タグでは表現できないため、共同利用文書や受け渡し文書を特別扱いする運用ルールと、タグを見直す担当を先に決めておく必要がある。

Q3. 自社ではこの部署別権限の設計を運用しているか

運用していない。自社の実装はテナント単位の索引分離までで、部署別のアクセス制御は実装しておらず、運用実績も無い。

Q4. テナント単位の分離をそのまま部署別権限に転用できるか

できない。テナント分離は契約先ごとにデータを隔てるための粒度であり、1つの組織内の部署分けとは粒度が異なる。

部署をまたぐ文書の扱いは、役職や職責を軸にした権限設計とも関係する。役職ベースで分ける場合の難しさは役職・職責で分ける記事で扱っている。一時的な権限をどう設計するかはプロジェクト単位の期限つき権限の記事にまとめた。回答内容の制御を人がどこで確認するかはRAGの人間ゲートの記事で扱っている。社内文書RAGの権限設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。

関連する取り組み

CONNECTED SERIES
AIで投資の壁を越える
18 本の実装記録。AI 投資の「予測不能」と言われる 9 つの壁を、コードと実データで検証した連載。
note で読む →
B2B API
Persona API
行動データから再構成した 2,245 体のペルソナを LLM 推論に注入。AI 出力の文脈リッチ化、顧客 segmentation に。
詳細を見る →

AI導入のご相談を承っています

AI導入支援の実務経験を活かし、お手伝いしています。お気軽にご相談ください。

他のカテゴリも読む

AI最新ニュース AI業界の最新ニュースと企業動向 AI導入戦略 AI投資判断・ROI分析・導入ロードマップ 業界別AI活用 製造・金融・小売など業界別のAI活用動向 導入事例 企業のAI実装プロジェクト事例とコンサルティング知見 研究論文 NeurIPS、ICMLなどの注目論文レビュー