この記事で分かること／分からないこと
- 分かること: 退職者・異動者の文書アクセス権限を止める設計の基本的な考え方
- 分かること: 権限を止めても索引や過去の回答に情報が残り続ける理由
- 分からないこと: 自社で退職者・異動者向けの権限失効を実装・運用した実績(未実装のため)
- 分からないこと: 人事システムとの連携をどこまで自動化できるか
退職・異動で止めるべきものは何か
社員が退職したり部署を異動したりすると、それまで見られていた文書の一部は見られなくなるべきである。基本的な設計は、退職・異動のタイミングをきっかけに、その人に紐づく検索権限を止める、というものである。ここで止める対象は、本人がRAGに対して新しく検索をかける権限であり、これまでに生成された回答や、本人が作成した文書そのものではない。この区別を最初に明確にしておかないと、「権限を止めた」という言葉が指す範囲が人によってずれる。
権限を止めても、索引にはラグがある
検索権限を止める設定を変えたとしても、その変更が索引側に反映されるまでにはラグが生じうる。索引の更新が定期的なバッチで行われる構成であれば、退職・異動の直後から次の更新までの間、古い権限のままの状態が残る可能性がある。索引を毎回全部作り直すのではなく差分だけを更新する構成を取っている場合、この差分反映の頻度が、実質的な権限の反映速度を決めることになる。権限を止める設定と、索引が実際にその設定を反映するタイミングは、別のものとして扱う必要がある。
退職者が作った文書は誰のものとして扱うか
退職者・異動者本人が作成した文書は、退職・異動後も社内に残り続ける。これを「作成者の権限」に紐づけて管理していると、作成者がいなくなった時点でその文書の扱いがあいまいになる。文書の権限は、作成者個人ではなく、部署やプロジェクトといった継続する単位に紐づけて管理する方が、退職・異動が起きても扱いが変わらずに済む。
索引からの削除と、権限の失効は別の操作
退職・異動によって「もう見せたくない」文書があった場合、権限を止める操作と、その文書を索引から完全に取り除く操作は別の操作である。権限を止めるだけでは、別の経路(例えば別の権限を持つ人からの質問)でその文書の内容が回答に反映される可能性は残る。逆に索引から取り除くと、正当な権限を持つ人からもその文書が検索できなくなる。どちらの操作が必要かは、退職・異動が理由なのか、文書自体の扱いを変えたいのかによって変わるため、混同しないことが重要である。
自社の実装との違い
自社の実装は、契約先(テナント)ごとに索引を分離する構成であり、確定配信で実行時に参照する索引はD1に置き、テナントIDで分けて引く。索引のビルドは一度行った後、差分の再生成で更新する構成になっている。これは契約単位でテナントを追加・削除する場面を想定した設計であり、同じテナントの中で個人の退職・異動に応じて権限を細かく止めるという問題とは、対象にしている単位が異なる。自社に社内文書RAGの実測は無く、テナント分離までしか実装しておらず、退職者・異動者向けの権限失効を運用した実績は無い。
よくある質問
Q1. 退職・異動時に止めるべきものは何か
その人が新しく検索をかける権限を止めることが基本になる。これまでに生成済みの回答や、本人が作成した文書そのものを消す操作とは分けて考える必要がある。
Q2. 権限を止める設定を変えれば、すぐに反映されるか
そうとは限らない。索引の更新が定期的なバッチや差分反映で行われる構成では、設定変更から実際の反映までにラグが生じうる。
Q3. 退職者が作成した文書はどう扱うべきか
作成者個人ではなく、部署やプロジェクトといった継続する単位に権限を紐づけて管理する方が、退職・異動が起きても扱いが変わらずに済む。
Q4. 自社では退職者・異動者向けの権限失効を運用しているか
運用していない。自社の実装はテナント単位の索引分離までで、個人単位の権限失効は実装しておらず、運用実績も無い。
権限を個人に紐づけず、部署のような継続する単位で管理するという考え方は、部署ごとに見える文書を分ける記事とも関係する。委託先など社外の関係者に見せる範囲の切り方は委託先に見せる範囲の記事にまとめた。生成された回答を人がどこで確認するかはRAGの人間ゲートの記事で扱っている。社内文書RAGの権限設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの人間ゲートはどこに置くか
- 関連記事: 委託先に見せる範囲
- 関連記事: 部署ごとに見える文書を分ける