業務AIを使い始めると、誰がどの資料を見られるのか、下書きだけなのか、外部送信や更新まで許すのかが曖昧になりやすくなります。特に広告制作や運用のように、商品資料、素材、予算、承認が同じ作業に並ぶ業務では、部署名だけで権限を決めると判断が粗くなります。生成AIの権限管理は、利用者、参照対象、操作権限を別々に決める設計です。
社内資料を渡す前の一般確認だけでは、運用中の権限変更や異動退職時の見直しまで扱いきれません。利用者別に、読める資料、できる操作、確認者を表にすると、制作担当、責任者、外部協力者、システム担当の違いを業務単位で判断できます。
生成AIの権限管理は三つに分ける
生成AIの権限管理は、誰に使わせるか、何を参照させるか、何を実行させるかを同じ欄に混ぜないことから始めます。生成AIの権限管理とは、業務AIが参照できる資料と、下書き作成や承認や更新などの操作権限を、利用者ごとに分けて管理することです。参照対象はAIが回答や下書きの根拠にできる資料の範囲で、操作権限はAIや連携機能を通じて実行できる業務上の動きです。
利用者は部署名だけで決めない
利用者は、営業部や制作部のような部署名だけで一律に決めるより、担当業務で分けます。Microsoftの組織向けCopilot資料を2026年10月12日に確認しました。資料ではMicrosoft 365 CopilotからMicrosoft Copilotへの名称変更が案内され、Microsoft Copilotは利用者がアクセス権を持つ組織データをもとに回答すると説明されています。Microsoft Copilotのデータ保護と権限これはその製品の権限モデルの説明であり、すべての生成AI製品で同じ動きが自動的に保証されるという意味ではありません。
架空の広告チームなら、制作担当、責任者、外部協力者、システム担当を別の利用者として置きます。制作担当は承認済みの商品資料を参照して台本下書きを作る人、責任者は完成物を承認する人、外部協力者は共有された素材だけを見る人です。システム担当が広い管理権限を持つことと、日常のAI作業で常時その権限を使うことは分けて考えます。
参照対象と操作は別の欄にする
参照対象と操作権限は、同じ人に対しても別の欄にします。承認済みの商品資料を読めることは、配信予算を変更できることとは別です。生成AIが資料を読んで台本下書きを作る範囲と、広告予算を更新する範囲を同じ許可にまとめると、確認者がどこで止めるべきか見えにくくなります。
横にスクロールして比較できます
| 利用者 | 参照対象 | できる操作 | 確認者 |
|---|---|---|---|
| 制作担当 | 承認済み商品資料 | 台本下書き作成 | 制作責任者 |
| 責任者 | 完成物と変更申請 | 完成物の承認 | 業務責任者 |
| 外部協力者 | 共有対象の素材 | 素材確認と制作補助 | 社内担当者 |
| システム担当 | 管理に必要な設定 | 権限設定の変更と接続確認 | 管理責任者 |
この表は編集部が提案する架空の広告チームの記入例であり、実施済みの権限試験ではありません。制作担当は承認済み商品資料を参照し台本下書きを作れるが、配信予算変更はできないという線を置きます。責任者は完成物を承認できても請求管理者とは限らず、外部協力者は共有対象の素材だけを参照する設計にします。
確認者の欄を置くと、AIの出力を誰が見てよいかだけでなく、操作に進んでよいかを誰が止めるかも決められます。一般担当のテストアカウントで、対象外資料が検索、引用、派生出力に現れないかを見る方法は、権限変更前後の確認案として使えます。実行結果を示すものではなく、自社で試す時の確認手順として扱います。
資料を渡す前に確認すること
社内資料をAIへ渡す前の一般確認は、公開情報、社内手順、顧客を含む記録を分け、利用環境ごとの権限と保存条件を見る作業です。SynClipの社内データ確認の記事では、学習に使われないことと保存されないことを分け、資料の種類、利用環境、必要部分、更新と削除の担当を整理しています。（SynClip company-data）運用中の権限管理では、その前提の上で、利用者ごとの参照範囲と操作権限を見直します。
社内資料AIの誤参照を防ぐ設計では、商品ID、資料の版、承認状態、適用範囲でAIに渡す情報を選ぶ考え方が役立ちます。SynClipのコンテキスト設計の記事では、古い版や別商品の混入を避けるために、AIへ渡す資料の版や採否を設計する考え方を示しています。（SynClip context-engi）権限管理では、その資料選択を利用者別の表へつなげ、誰がどの資料を参照し、どの操作までできるかを運用中に見直します。
社内資料をAIへ渡す前の確認項目 関連記事を読む
参照範囲と操作権限がずれる時
資料を読める範囲と業務を変えられる範囲が同じだと、生成AIの権限管理は急に見えにくくなります。承認済み商品資料を参照して台本下書きを作る人と、広告予算や顧客管理の状態を変える人は、同じ担当者でも別の権限として扱います。
閲覧だけなら起きにくい問題
外部送信やデータ更新を含むと、AIが作った案を読むだけの権限とは別に、業務システムへ変更を反映する権限が必要になります。MCPのツール仕様2025-11-25版と、最新版のアーキテクチャ資料2026-07-28版を2026年10月12日に確認しました。MCPはAIアプリケーションが外部のツールや資料へ接続するための方式の一つで、ツールには名称や入力条件などの情報を持たせられます。MCP Tools仕様すべての連携にMCPが必須という扱いにはせず、接続先ごとに、読むだけか、下書きを作るだけか、外部へ送るか、記録を更新するかを分けて設計します。
接続アカウントとは、AIが外部の資料や業務システムへ接続する時に使う利用者やサービス用のアカウントです。日常の下書き作成で使う接続アカウントに、外部送信や予算変更まで含めると、利用者が意図した範囲を超えて操作できる状態になります。問い合わせ業務の連携設計例でも、初期範囲は返信案作成までで、外部送信と状態変更は含めない形にしています。
実行前の確認を置く場所
実行前承認とは、AIが作った変更案を、そのまま実行せず、人が対象、変更内容、期限、戻し方を見てから許可する設計です。MCPのツール仕様2025-11-25版は、信頼と安全のために、人がツール実行を拒否できる確認を置くべきだと説明しています。MCP Tools仕様AI案、申請、承認、実行、履歴を分けると、どの時点で人の判断が入り、どこからシステム上の変更になるかを確認できます。広告予算の変更票なら、キャンペーンの対象、変更前の値、変更後の値、理由、集計期間、取得時刻、戻す値、有効期限を承認前にそろえます。
編集部の架空例では、キャンペーンの一日予算を変更する案は媒体の推奨ではなく、承認対象を説明するための記入例です。承認時に見た変更後の値と、実行直前の値が変わっていれば、元の承認の範囲を超えるため再確認します。返答がない状態を承認と扱わず、期限切れや元データ更新時の再確認条件も先に決めておきます。
内容の承認は、システム上の実行権限を付与する操作とは別です。実行時点でも接続先の権限と対象範囲を確かめ、実行後は結果と現在値を照合します。承認済みでも通信や権限の問題で失敗することがあるため、承認記録だけを成功の証拠にしません。
管理権限を日常利用に持ち込まない
広い管理権限を持つ人が必要な場面と、日常のAI作業で常時その権限を使う場面は分けます。システム担当が権限設定を管理できることは、制作担当の台本作成や責任者の完成物承認と同じ権限で動くことを意味しません。編集部の架空広告チーム例では、システム担当の管理権限は権限設定や接続確認のために置き、日常の下書き作成や承認の操作とは別に扱います。
Microsoft Purviewの権限資料を2026年10月12日に確認しました。同資料では、利用者に明示的に付与した特定のタスクだけを実行できるように管理でき、最小権限でアクセスを管理することが推奨されています。Microsoft Purviewの権限これは該当製品の管理推奨であり、すべての生成AI利用にそのまま当てはまる法的義務としては扱いません。日常利用の接続アカウントは、必要な資料を読める範囲、下書きを作れる範囲、承認後に実行できる範囲を分けて、管理者権限を作業の近道にしないことが重要です。
生成AIの権限管理を見直す時点
権限棚卸しは、利用者、参照対象、できる操作、確認者を定期的に見直し、不要になった閲覧権限や接続を外す作業です。元資料のアクセスを止めても、AIが作った下書きや要約が別の場所に残っている場合があるため、保存済み出力も確認対象に含めます。
月次で見るもの
月次の確認では、共有リンク、グループ所属、サービス接続、保存済み出力を分けて見ます。共有リンクは外部協力者や一時参加者へ残っていないか、グループ所属は担当業務から外れた人が資料を検索できる状態になっていないかを確認します。サービス接続は、AIから参照する外部ツールや保存先が増えた時に、日常業務で必要な範囲に収まっているかを見ます。
NISTのAIリスク管理フレームワークを2026年10月12日に確認しました。確認時点でAI RMF 1.0は改訂作業中と案内されており、同資料はAIのライフサイクルを通じて継続的にリスクを管理する考え方を示しています。NIST AI RMF Core月次という頻度や記録項目は編集部の運用案です。入力と応答、参照資料、対象から外した資料、停止理由を業務に必要な範囲で追えるようにし、記録自体の閲覧権限と保存期間も決めます。
- 共有リンクが一時共有のまま残っていないかを見る
- グループ所属が現在の担当業務と合っているかを見る
- サービス接続が日常作業に必要な範囲かを見る
- 保存済み出力に対象外資料の引用や派生表現が残っていないかを見る
- AI利用状況や履歴を後から追える記録として残す
資料更新で見るもの
商品資料や承認済み資料が更新された時は、旧版や未承認版が検索や引用や派生出力に出ないかを確認します。Microsoftの組織向けCopilot資料を2026年10月12日に確認しました。資料ではMicrosoft 365 CopilotからMicrosoft Copilotへの名称変更が案内され、組織データは利用者の閲覧権限に従って扱われ、個々の利用者が少なくとも閲覧権限を持つ組織データだけを表示すると説明されています。Microsoft Copilotのデータ保護と権限この説明は該当製品の権限モデルに関するものであり、更新された資料が自社のすべてのAI環境で自動的に安全へ切り替わるという意味ではありません。
資料更新時の確認は、一般担当のテストアカウントで行う提案として扱います。対象外資料が検索結果、引用、下書き、要約、派生表現に現れないかを見て、実施していない試験を合格扱いにしません。社内データをAIへ渡す前の確認では、資料の種類、利用環境、必要部分、更新削除の担当を分ける考え方が示されており、更新後の権限管理でも同じ分け方が役立ちます。（SynClip company-data）
古い商品説明を外す作業は、元ファイルの削除だけでは足りない場合があります。保存済み出力や過去の下書きに旧版の訴求が残っていると、次の制作担当がそれを現行表現として再利用するおそれがあります。資料更新の時点では、現行版として参照してよい資料、検索対象から外す資料、再確認が必要な保存済み出力を別々に並べます。
異動退職で見るもの
異動日と退職日は、アカウント停止、共有リンク、グループ所属、サービス接続、保存済み出力の保管を別々に見ます。異動では、本人のアカウントが残っていても、新しい担当業務で使わない資料や操作が残ることがあります。退職では、アカウント停止だけでなく、過去に作った共有リンクや外部サービス接続が別の入口として残っていないかを確認します。
IPAはAI利用者向けのセキュリティ資料で、AI利用時の最低限かつ有効性の高いセキュリティ対策を紹介すると説明しています。IPA AI利用のセキュリティ生成AIの権限管理では、この考え方を異動退職時の運用へ移し、過剰権限や不要な接続を残さない確認に使います。Microsoft Purviewの資料には、権限付与に有効期限を設定し、期限到来時に権限を自動的に取り消す説明もあります。Microsoft Purviewの権限停止や退役管理は、一度広げた権限を使い続けるためではなく、担当変更後に参照範囲と操作権限を現在の業務へ戻すための運用です。
保存済み出力の保管は、元資料と同じ扱いにしない方が実務に合います。下書きや要約に承認済み資料の一部が含まれる場合、元資料の権限を外しても、出力側に参照できる形で残ることがあります。異動退職の確認では、本人の利用停止、共有先の解除、グループからの除外、接続サービスの見直し、保存済み出力の移管や削除依頼を一つの作業にまとめず、別々の担当で確認します。
自社の業務で試す
業務AIの参照範囲と人の確認位置はインパクトトライアル（最短1ヶ月のスピード検証）で検証する対象として相談できます。自社の商品資料や確認票を使った試作を毎週更新し、合意した指標で変化を確かめます。
