この記事で分かること／分からないこと
- 分かること: 役職・職責を軸にした権限設計が、部署別の設計より難しくなりやすい理由
- 分かること: 検索結果を絞るだけでは足りず、回答内容の制御が別に必要な理由
- 分からないこと: 自社で役職別アクセス制御を実装・運用した実績(未実装のため)
- 分からないこと: 特定の人事システムや検索基盤における実装方法
役職で分けるとは、部署で分けるのとどう違うか
部署別の権限設計は、所属という比較的固定された属性を基準にする。これに対して役職・職責を基準にする設計は、「マネージャー以上は閲覧可」「特定の職責を持つ人だけ閲覧可」といった条件を文書に付与する。部署より細かい粒度で権限を絞れる利点がある一方、役職や職責は部署の所属より変化の頻度が高く、昇格・異動・兼務によって条件を満たす人の集合が頻繁に入れ替わる。この変化の速さが、役職ベースの設計を部署別より難しくしている最大の要因である。
役職名だけでは職責が決まらない
同じ役職名を持つ人でも、実際に担っている職責は部署やチームによって異なることが多い。逆に、役職としては一般社員でも、特定のプロジェクトや委員会での職責によって、通常より広い範囲の文書を見る必要が生じる場合もある。役職名を権限のキーにしてしまうと、こうした職責の実態とのずれが生じやすく、結果として「役職は足りているが職責上は見せるべきでない」「役職は足りないが職責上は見せるべき」という例外が積み上がっていく。
条件の組み合わせが増えるほど複雑になる
役職・職責・部署・プロジェクトを組み合わせて条件を作ろうとすると、条件の数が掛け算的に増えていく。1つの文書に対して「この役職以上、かつこの部署、かつこの職責」といった条件を積み重ねるほど、誰が実際に見られるのかを人が把握しづらくなる。条件が複雑になるほど、権限の設定ミスが起きても気づきにくくなるという副作用もある。
検索結果の絞り込みと、回答内容の制御は別問題
役職ベースの権限設計でも、部署別の設計と同じ注意点が当てはまる。検索(retrieval)の段階で役職条件に合う文書だけに絞ったとしても、それは文書単位のアクセス制御でしかない。生成された回答が、許可された文書の内容を要約・言い換えする過程で、本来その役職には見せるべきでない含意を含んだ文面になる可能性は残る。文書へのアクセスを役職で絞ることと、生成される回答の文面に何を書いてよいかを制御することは、別のレイヤーの設計として扱う必要がある。
自社の実装との違い
自社の実装は、契約先(テナント)ごとに索引を分離する構成であり、確定配信で実行時に参照する索引はD1に置き、テナントIDで分けて引く。これは契約単位の分離であり、1つの組織の中で役職や職責によって文書を分けるという問題とは粒度が異なる。役職・職責という属性は人事上の情報であり、テナントという契約上の単位とは扱う軸そのものが違う。自社に社内文書RAGの実測は無く、テナント分離までしか実装しておらず、役職・職責別の権限設計を運用した実績は無い。
よくある質問
Q1. 役職を基準にした権限設計は、部署別より優れているか
一概には言えない。より細かい粒度で絞れる利点はあるが、役職・職責は変化が速く、条件が複雑になりやすいため、運用の負荷は部署別より高くなりやすい。
Q2. 役職名を権限のキーにすればよいか
役職名だけでは実際の職責を正確に表せないことが多く、例外が積み上がりやすい。役職名と職責を分けて扱う設計を検討する必要がある。
Q3. 条件を組み合わせるほど権限設計は安全になるか
そうとは限らない。条件が複雑になるほど、誰が実際に見られるのかを人が把握しづらくなり、設定ミスにも気づきにくくなる。
Q4. 自社では役職ベースの権限設計を運用しているか
運用していない。自社の実装はテナント単位の索引分離までで、役職・職責別のアクセス制御は実装しておらず、運用実績も無い。
役職・職責の条件は、プロジェクト単位で一時的に付与される権限とも重なりやすい。期限つきの権限設計はプロジェクト単位の期限つき権限の記事で扱っている。役職が変わった人、つまり異動・退職した人の権限をどう止めるかは退職者・異動者の扱いの記事にまとめた。生成された回答の内容を人がどこで確認するかはRAGの人間ゲートの記事で扱っている。社内文書RAGの権限設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの人間ゲートはどこに置くか
- 関連記事: プロジェクト単位の期限つき権限
- 関連記事: 退職者・異動者の扱い