生成AIを社内に導入すると、守るべき境界の数が一気に増えます。従来は「フォルダを開けるか」だけで判断していたアクセス判定が、「その文書を検索条件に含めてよいか」「その回答を社外へ持ち出せるか」まで範囲が広がります。権限が文書単位でしか制御できない構成では、チャンク単位の検索と組み合わさった段階で境界が破られます。本稿は、権限管理システムを初めて導入する情報システム責任者向けに、ロール設計、権限棚卸し、アクセスレビュー、特権ID分離という4つの統制手順を、実装判断に使える形に整理します。
権限管理の単位は3つの層に分けて扱う
権限管理の設計で最初に決めるべきことは、権限を与える単位です。社内AIでは次の3層を分けて扱う必要があります。
ひとつ目は機能権限で、どの画面を操作できるか、どの設定を変更できるかを管理します。業務システムの権限設定に近い層で、基盤の運用そのものを扱います。
ふたつ目がデータ権限で、どの文書・どの部署の情報を参照できるかを管理します。RAG（検索拡張生成）では文書がチャンクに分割されて検索されるため、ここが効いていないと、閲覧できない文書の断片が回答の根拠として引用されます。
みっつめは操作権限で、回答を社外へ持ち出せるか、ログをエクスポートできるか、権限設定を変更できるかを管理します。ここが弱いと、組織として許していない操作が技術的には可能という状態になります。
3層を1つの管理画面に同居させると、どの層で制限が効いているか見えにくくなります。層ごとに判定の単位を明示し、監査のときに「誰が何をどこまでできたか」を1文で説明できる状態にしてください。
| 権限の層 | 管理する対象 | 典型的な失敗 |
|---|---|---|
| 機能権限 | 画面の操作と設定変更 | 設定変更が管理者以外の手段で可能になる |
| データ権限 | 文書と部署の参照範囲 | チャンク分割で文書単位の制限が外れる |
| 操作権限 | 出力・エクスポート・権限変更 | 管理者権限が担当者にそのまま配布される |
ステップ1：ロール設計は業務役割から逆算する
ロールは「操作が便利になること」ではなく「アカウントが盗まれたときの被害範囲」を基準に設計します。手順は4つです。
- 業務上の役割を書き出す。営業、経理、開発、管理など、部署名ではなく役割で並べます。
- その役割で実行する操作だけを列挙する。1日の業務で実際に触る画面と操作を洗い出します。
- 必要な範囲より広い操作は別のロールへ分ける。文書の登録と文書の公開を分けるような切り方です。
- 名前の付け方を統一する。「対象_役割_区分」の形に固定すると、棚卸し記録の読み違いを防げます。
役割ごとに必要な権限だけを足し合わせると、人事異動のたびに消えない「幽霊権限」が生まれます。命名規則を固定し、画面上の表示名と権限の定義を1対1で対応させてください。
| ロール名 | 想定する役割 | 主な権限 | 管理者 |
|---|---|---|---|
| 一般利用者 | 全員の日常利用 | 公開ナレッジの閲覧と質問 | 部門長 |
| 業務担当 | 特定の部署で文書を扱う | 部署内の文書登録と回答の再生成 | 部署の責任者 |
| ナレッジ管理 | 文書の品質を管理する | 文書の追加、編集、公開停止 | 情報システム部門 |
| システム管理 | 基盤と権限を操作する | ユーザー管理と権限設定 | 部門長 |
ステップ2：権限棚卸しは初回と定期で分けて運用する
権限の棚卸しは一度きりの作業ではなく、2つの種類に分けて回します。
初回の棚卸しは、移行時に既存システムの権限を1件ずつ確認する工程です。移行前の権限一覧を出力し、1行ずつ「現在も必要か」を判断します。ここで即答を確定させず、「保留」を置けるようにしておくと、業務側の確認時間を確保できます。
定期の棚卸しは、半年から1年の周期で事前に告知して行います。目的は追加ではなく削除の検出です。対象として挙がるのは、3か月以上ログインしていないアカウント、退職・異動した社員のアカウント、業務委託の契約終了後に残ったアカウントの3つです。
棚卸しの結果は台帳に残します。誰の判断で、どの権限を、何の根拠で削除したのかが追えないと、内部監査では「統制が運用されていない」と判定されます。台帳の様式を先に決め、担当者と承認者の2名体制で運用してください。
ステップ3：アクセスレビューは四半期周期で記録を残す
アクセスレビューは「このままでよいですか」という同意取得ではなく、権限の妥当性を判断する作業です。判断の単位は人ではなく、アカウントと権限の組み合わせです。1人の利用者が複数のロールを持っていても、組み合わせごとに妥当性を確認します。
レビューで判断する項目は4つです。その権限は今も業務上必要か、その権限は利用者個人にとって必要最小限か、その権限付与の記録が監査で説明できるか、権限を付与した責任者が明示されているか。この4つを1件ずつ確認し、「継続」「削除」「変更」の3区分で結果を記録します。
記録を残さないレビューは、会議が終われば何も残りません。判断結果と根拠をその場で保存する運用を先に決めておく必要があります。削除と判定した権限は、実行画面から即座に外れる状態にしてください。
| 確認項目 | 判定の目安 | 対応 |
|---|---|---|
| 最終利用日 | 3か月以上の利用実績がない | 停止し、仮復旧での再申請にする |
| 権限の過剰 | 日常業務で使わない操作を含む | 操作単位を取り除く |
| 特権の分散 | 管理権限が複数人に分かれている | 担当を1名に集約する |
| 記録の完全性 | 付与・変更・削除の記録が揃っている | 不足分は遡って補完する |
ステップ4：特権IDは分離して貸出と返却を記録する
特権アカウントは、日常利用のアカウントと分けて管理します。推奨は3分割です。基盤の設定を行う管理者アカウント、業務を実行する実行アカウント、操作の記録だけを見られる監査アカウント。この3つを分離すれば、誰が何を操作したかが記録と1対1で結びつきます。
貸出型の運用にするなら、手順は次の通りです。利用者が申請し、承認者が確認し、必要な時間だけ特権IDを貸出し、操作を終えたら返却する。貸出と返却の記録は自動で残します。
「緊急のときは記録しない」という運用は、統制の例外ではなく統制の停止です。緊急時は事後に2営業日以内に記録を補完する、と事前に定義しておきます。既存の認証基盤との接続方式は、オンプレミスActive Directoryとはで3つの共存設計パターンとして整理しています。
権限管理システムを選ぶときの6つの評価観点
製品の比較表だけで判断せず、運用したあとの状態がどう変わるかを基準に評価します。次の6つの観点で、実際の画面と設定項目を確認します。
| 評価観点 | 確認する内容 | 満たしていない場合のリスク |
|---|---|---|
| 認証方式 | 社内認証基盤との連携と多要素認証 | 認証情報の窃取で特権がまとめて落ちる |
| 権限の粒度 | 文書・部署・チャンク単位の指定可否 | 境界が外れ、他部署の情報が見えてしまう |
| 棚卸しの補助 | 一括付与・削除と最終利用日の一覧表示 | 手作業の更新で工数が積み上がる |
| 監査証跡 | 操作ログの自動記録と差分の保存 | 統制の実効性を説明できない |
| 運用負荷 | 管理者の工数と学習コスト | 統制が形骸化して運用が黙る |
| 閉域性 | 外部APIへの依存の有無 | 社内の情報が社外へ出る |
6つのうち、認証方式と閉域性だけは代替手段が利きません。他の項目は運用で追いつける範囲ですが、この2つは後から付け替えにくい性質です。導入前に確認する優先度はここを上位に置きます。
閉域構成で実装するときの5つの要件
権限管理を実効的にするには、基盤そのものが社内完結していることが前提になります。実装判断に使う5つの要件を挙げます。
- 認証と多要素認証の閉域化 — 認証情報の検証と認証コードの発行が社内で行われ、社外の認証サービスを経由しないこと
- 取込時の権限タグの自動付与 — 文書の属性から権限情報を自動で付け、手作業での付け替えが発生しないこと
- 操作ログの自動記録 — 誰が・いつ・何をしたかを変更前後の差分とともに自動で残すこと
- 設定変更と日常利用の分離 — 権限を変更する権限と、その変更を実際に使う権限を分けること
- 外部API非依存 — 推論も検索も文書参照も、すべて社内ネットワーク内で完結すること
5番目を守れば、権限情報が社外に出る経路自体が存在しなくなります。GBase OnPremは、この5要件を標準の構成要素として組み合わせて運用できます。ローカルJWT認証とメールMFAで認証を閉域に保ち、ミドルウェアが全操作を自動記録して変更の前後差分と認証イベントを保存し、MCP連携で基幹DBを社内ネットワークのMCPサーバー経由で参照します。
RAGを運用する前提条件として、構成の全体像は生成AI オンプレミスで運用にまとめています。
GBase OnPremなら、最小権限の統制を閉域で実装できます
よくある質問
Q1: 最小権限の理想と現実の落差はどう埋めますか？
理想論だけ追求すると運用が回りなくなります。現実的な進め方は、例外枠を制度として用意することです。「必要だが、記録して後で消す」枠を置き、一定期間だけ広めの権限を付与し、例外台帳に理由と期限を書いて期限に削除する運用を前提にすれば、理想との落差を例外の明示で管理できます。
Q2: アクセスレビューは何周期が適切ですか？
権限の変動が激しい組織では四半期、安定した組織では半年が目安です。重要なのは頻度よりも、判定結果を残し、出力できる状態を維持すること。結果を出力できないレビューは、実運用と監査の双方で形骸化として扱われます。
Q3: 特権IDは貸出型にすべきか、常時保有型にすべきか？
権限の分離と記録の運用が整備されていれば貸出型が望ましいです。ただし障害対応の要に常時保持が必要な管理者も残します。判断の分かれ目は、緊急時に「誰が操作したか」を説明できるかどうかです。説明できない状態なら、どちらの形式でも統制は成立しません。
Q4: 既存のActive Directoryと連携できますか？
社内の認証基盤と連動し、ログオンユーザーの認証情報をそのまま権限判定に渡す構成は実務上の望みです。連携の方式は3パターンあり、既存環境の制約で選択が変わります。構成と運用に関する詳細はオンプレミスの運用・保守ガイドにまとめています。
Q5: 権限管理を導入すると運用コストはどのくらい増えますか？
初回の棚卸しと権限設計に工数が集中します。日常運用で増えるコストは、1) レビュー対象が増える 2) 記録の保存先が増える 3) 例外申請の件数、の3点から見積もれます。3番の例外申請を「事前申請 → 期限付き付与 → 自動削除」の型に固定すると、工数は大きく抑えられます。
まとめ
権限管理システムの導入でいちばん効くのは、制御の一覧を揃えることではなく、「誰が何をどこまでできたか」を1文で説明できる状態にしておくことです。ロール設計で粒度を定め、棚卸しで削除を検出し、四半期レビューで妥当性を確認し、特権IDを分離して貸出を記録する。この4手順を回す前提となるのは、基盤の閉域化です。社内AIのオンプレミス導入ガイドで全体の導入手順を確認したうえで、オンプレミスのセキュリティ対策5選と合わせて経営判断の材料にしてください。
