この記事で分かること／分からないこと
- 分かること: プロジェクト単位で期限つきの文書アクセス権限を設計する考え方
- 分かること: 権限を失効させても解決しない、回答内容側に残る課題
- 分からないこと: 自社でプロジェクト単位の期限つき権限を実装・運用した実績(未実装のため)
- 分からないこと: 特定のプロジェクト管理ツールとの連携方法
プロジェクト単位で権限を切るとは何をすることか
部署や役職を基準にした権限は比較的長く続く関係を前提にしているが、プロジェクトは開始と終了が明確に決まっている。プロジェクトに参加する人だけが、そのプロジェクトに関連する文書を、プロジェクトが続いている間だけ検索できるようにする、という設計がここでの基本形になる。文書に部署タグではなくプロジェクトIDを付与し、参加者一覧とプロジェクトの期間を突き合わせて、検索時にフィルタをかける。
期限を「切る」ことの難しさ
期限つき権限で難しいのは、付与よりも失効の方である。プロジェクトの開始時には参加者一覧が明確でも、終了時には「正式な終了日」と「実質的に活動が止まった日」がずれることが多く、誰かが権限を止め忘れたまま放置される状況が起きやすい。さらに、プロジェクトが延長されたり、一部のメンバーだけ後続の作業に残ったりすると、期限を一律に設定すること自体が難しくなる。期限つき権限は、付与する仕組みだけでなく、期限が来たらきちんと失効させる運用の仕組みとセットで設計する必要がある。
権限を止めても、過去の回答には残る
ここで見落とされやすいのが、文書へのアクセス権限を止めても、それ以前にそのプロジェクトの文書をもとに生成された回答やチャットの履歴は、別の場所に残り続けるという点である。権限を止めることは、これから先の検索を止めることであって、過去に生成済みの回答から情報を消すことではない。文書単位のアクセス制御(検索を止める)と、回答に含めてよい情報の制御(生成済みの回答をどう扱うか)は、ここでも別の問題として扱う必要がある。期限つき権限を設計する際は、権限の失効とあわせて、過去の回答やログの保持期間をどう扱うかも決めておく必要がある。
社外の参加者が混ざる場合はさらに難しくなる
プロジェクトには社内の人だけでなく、社外の協力者が参加することもある。この場合、プロジェクト単位の期限つき権限に加えて、社外の人にどこまでの範囲を見せてよいかという別の制約が重なる。委託先など社外の関係者に見せる範囲をどう切るかという論点は、プロジェクト単位の期限とは別に検討する必要がある。
自社の実装との違い
自社の実装は、契約先(テナント)ごとに索引を分離する構成であり、確定配信で実行時に参照する索引はD1に置き、テナントIDで分けて引く。テナントという単位は契約が続く限り基本的に固定されており、プロジェクトのように開始・終了が頻繁に切り替わる単位とは性質が異なる。自社に社内文書RAGの実測は無く、テナント分離までしか実装しておらず、プロジェクト単位の期限つき権限を運用した実績は無い。
よくある質問
Q1. プロジェクト単位の権限で難しいのは付与と失効のどちらか
失効の方が難しい。開始時の参加者一覧は明確でも、終了時期があいまいになりやすく、権限を止め忘れる状況が起きやすい。
Q2. 権限を失効させれば、それ以前の回答内容も安全になるか
ならない。権限の失効は今後の検索を止めるだけで、過去に生成済みの回答やログに残った内容は別に扱う必要がある。
Q3. プロジェクトが延長された場合、期限はどう扱うべきか
一律の期限では対応しきれない。延長や一部メンバーの継続を想定し、期限を見直す運用を先に決めておく必要がある。
Q4. 自社ではプロジェクト単位の期限つき権限を運用しているか
運用していない。自社の実装はテナント単位の索引分離までで、プロジェクト単位の期限つき権限は実装しておらず、運用実績も無い。
期限が来た後の扱いは、退職や異動で権限を止める場合とも共通する。索引に残り続ける問題は退職者・異動者の扱いの記事で扱っている。社外の関係者に見せる範囲の切り方は委託先に見せる範囲の記事にまとめた。生成された回答を人がどこで確認するかはRAGの人間ゲートの記事で扱っている。社内文書RAGの権限設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの人間ゲートはどこに置くか
- 関連記事: 退職者・異動者の扱い
- 関連記事: 委託先に見せる範囲