結論：社内AIの権限管理は、「会社ごとに環境を分ける」だけでは足りません。同じ会社の中でも、全社員向け・人事・経営などの閲覧範囲を分け、利用者には必要な範囲だけ見せる設計が必要です。
まず分けるべきは「会社間」と「会社内」の2つ
社内AIのセキュリティを考えるとき、「他社のデータと混ざらないか」と「自社の社員なら何でも見えてよいのか」を同じ話にしないことが重要です。
会社間の分離
Nexfila AIでは、顧客ごとに分離されたワークスペースを利用します。利用者・資料・検索対象はワークスペース、RBAC、データスコープの境界で管理し、他社のワークスペースに所属しない利用者がその資料を検索する前提にはしません。
ただし、会社間を分離しても、同じ会社の全社員に同じ資料を見せてよいとは限りません。会社内の閲覧範囲は別に設計します。
会社内の分離
原則は1顧客1ワークスペースです。同じ会社でも、全社員向け資料と、人事・経営など閲覧者が大きく異なる資料を同じ検索範囲へ入れたくない場合は、限定ワークスペースを分け、必要な利用者だけを所属させる方法を取ります。
細かな部署・役職・文書単位ACLを大量に設計するより、「全社共通」と「限定領域」のように大きな境界で分けるのが標準的な考え方です。
アカウント作成と、顧客ワークスペースへの参加は別
アカウントを作成できることと、特定企業のワークスペースへ参加できることは別です。顧客ワークスペースはOwner / Admin側から招待・所属管理を行い、URLを知っているだけで他社や別部門の資料を検索できる設計にはしません。
退職・異動・担当変更があった場合は、ユーザーの所属や権限を見直します。「ログインできる人」と「どの領域を見られるか」の両方を管理する必要があります。
Owner / Admin / Contributor / Viewer の4段階
採用基盤のWeKnora v0.8.2には、ワークスペース内の操作を分けるRBAC（Role-Based Access Control）があり、Owner / Admin / Contributor / Viewer の4段階で役割を分けられます。
Owner
ワークスペースの所有・管理を担う最上位の役割です。削除など影響の大きい操作を含むため、日常利用者へ広く付与する役割ではありません。
Admin
ワークスペース内の管理・設定を担う役割です。一般社員ではなく、管理側の利用者を想定します。
Contributor
資料やナレッジを追加・更新する担当者向けの役割です。標準Pilotでは、資料メンテナンスが必要な担当者へ限定して使います。
Viewer
閲覧・質問を中心に利用する役割です。一般社員はViewerを基本とし、必要以上の変更権限を持たせない方針です。
WeKnora公式ドキュメントでも、Viewerは読み取り・質問、Contributorは自身のリソース作成・変更、Admin / Ownerはより広い管理権限を持つ設計が説明されています。Nexfila AIでは、この基盤をそのまま自由設定で提供するのではなく、Pilot向けに利用範囲を絞って運用します。
WorkspaceとKnowledge Base（KB）は役割が違う
ワークスペースは「誰が参加できるか・どの利用範囲へ入れるか」を分ける大きな境界です。一方、Knowledge Base（KB）は、同じワークスペース内で資料を用途別にまとめるための箱として使います。
標準Pilotでは、KBだけを細かな部署・役職別のセキュリティ境界として扱うことは前提にしません。閲覧範囲が大きく異なる情報は、必要に応じてワークスペース自体を分けます。
全社・人事・経営をどう分けるか
最初から細かな文書単位ACLを大量に作ると、異動や資料追加のたびに管理作業が増えます。まずは情報の利用範囲が明確に違う単位で、大きく分ける方法が現実的です。
例1｜全社共通
就業ルール・申請手順・商品マニュアル・一般FAQ
全社員が質問・参照してよい資料をまとめます。一般社員はViewerとして利用する構成が基本です。
例2｜人事・管理部門
人事担当者だけが参照する手順・運用資料
全社共通の検索範囲と分ける必要がある場合は、限定ワークスペースを作り、必要な担当者だけを所属させます。
例3｜経営・管理職
管理職・経営側だけが扱う内部資料
一般社員から検索できない領域として分けます。実際に登録してよい資料かは、会社側の情報管理ルール・法令・契約に基づいて判断します。
「資料を登録してよいか」と「誰が見られるか」は別の判断
アクセス権限を設定できても、その資料を社内AIへ登録してよいかの判断まで自動的に決まるわけではありません。
Nexfila AIでは、社内限定・社外秘・個人情報という区分だけで一律に登録禁止にはしません。一方で、どの資料を登録するかは利用企業が自社の情報管理ルール、法令、契約、利用権限に基づいて判断します。パスワードやAPIキー等の認証秘密、決済認証情報、マイナンバー、必要な権利・許諾を持たない資料は標準Pilotの登録対象外です。
データ保存場所、外部AIへ送る範囲、バックアップ、保持期間、Nexfila側の管理アクセスについては、セキュリティ・データ取扱いで公開しています。
標準Pilotでやらない権限設計
Nexfila AIは、大企業向けIAM製品や個社専用の権限管理システムを作るサービスではありません。次のような要件は標準Pilotの範囲外です。
- 部署・役職・プロジェクトを何階層にも組み合わせた複雑な権限設計
- 文書1件ごとに顧客固有ルールで変わる独自ACL
- 大規模なIdPとの個別同期や高度SSO
- 顧客ごとに異なる権限ロジックのカスタム開発
こうした要件が必須なら、Pilot契約前に適合性を確認します。標準化できない個別運用を安易に受けると、権限管理そのものが新しい属人業務になるためです。
導入前に確認したい7項目
- 全社員が見てよい資料は何か
- 人事・経営など、閲覧者を限定したい資料があるか
- 一般社員は質問・参照だけでよいか
- 資料を追加・差し替えする担当者は誰か
- 退職・異動時にユーザーや所属を更新する担当者は誰か
- 高度SSOや既存IdPとの同期が本当に必須か
- そもそも社内AIへ登録しない資料は何か
最初から「完璧な権限表」を作るより、全社共通と限定領域を明確に分け、必要な人だけ参加させる方が運用しやすい会社もあります。
参考にした一次情報・Nexfila公開情報
- Tencent WeKnora「Workspace RBAC」公式ドキュメント
- Tencent WeKnora CHANGELOG（RBAC / invite-only / workspace機能）
- Nexfila AI セキュリティ・データ取扱い
- Nexfila AI 先行導入の料金・契約条件