【2026年8月最新】生成AI・AIエージェントの権限設計｜最小権限・承認・監査ログの決め方

社内文書を検索するだけなら問題なく動いていたAIが、メール送信やデータ更新まで行うようになると、管理の難しさは一段上がります。

「誰が使えるか」だけを決めても十分ではありません。AIがどのデータを読み、どのシステムへ書き込み、どの操作で人の承認を求めるかまで設計する必要があります。この記事では、特定製品に依存しない権限設計の基本を、情シス・DX推進担当者が実務で使える形に整理します。

この記事の要点

AIの権限設計とは

AIの権限設計とは、生成AIやAIエージェントに対して、誰の指示で、どの情報へアクセスし、どこまで操作してよいかを決めることです。

従来の社内システムでも、利用者ごとの閲覧・編集権限は設けられてきました。AIエージェントでは、これに「AIが自らツールを選び、複数の処理を続けて実行する」という性質が加わります。1つの依頼が、検索、要約、ファイル作成、メール送信まで連続することもあります。

OWASPは、LLMを使ったシステムに必要以上の機能・権限・自律性を与えるリスクを「Excessive Agency」として整理しています。たとえば、商品情報を読むだけのAIに、商品マスタの更新・削除権限まで渡す必要はありません。OWASPの公式解説でも、利用する拡張機能、機能の範囲、接続先の権限を必要最小限に抑え、影響の大きい操作には人の承認を求めることが推奨されています。

NISTの生成AI向けAIリスク管理プロファイルも、組織の目的、要件、許容できるリスクに合わせて管理策を決める考え方を示しています。製品名から設定を選ぶのではなく、業務と影響範囲から権限を決めるのが出発点です。

権限は5つの層に分けて考える

権限を「管理者か一般社員か」だけで決めると、抜けが生まれます。次の5層に分けると、議論しやすくなります。

発注前の全体設計から整理したい場合は、AI開発の要件定義とRFPで、対象業務、データ、非機能要件、役割分担を先に確認してください。本記事は、その中でも権限と監査を具体化する位置づけです。

重要なのは、5層を個別に見るだけでなく、組み合わせを確認することです。営業担当者が顧客情報を検索できることと、その情報を外部宛てのメールへ自動挿入して送信できることでは、リスクが異なります。

利用者の権限

最初に、AIを利用する人と管理する人を分けます。一般利用者、業務責任者、AIの設定担当者、システム管理者では、必要な権限が違います。

ここで避けたいのが、全員を同じ権限にすることです。営業部には営業資料を、人事部には採用関連資料を見せる必要があっても、互いの機密情報まで共有する理由はありません。既存の部署・役職・プロジェクト単位のアクセス権をAI側にも引き継ぎます。

データの権限

接続するデータを、公開、社内、機密、要配慮のように分類します。そのうえで、誰が何を検索できるかを決めます。

RAGや社内検索AIは、登録された文書を何でも回答する仕組みではありません。元の文書を閲覧できない人には、AI経由でも内容を返さない設計が必要です。部署ごとに検索対象を分けるか、利用者の権限を検索時に反映させます。

社内データの扱い方は、社内でChatGPTを使えない企業向けの選択肢でも、法人向けクラウド、専用環境、オンプレミスに分けて解説しています。

機能の権限

AIに接続できるツールは、業務に必要なものだけに絞ります。検索しか必要ないAIへ、メール、ファイル削除、外部Webアクセス、任意のコマンド実行まで与えると、障害や攻撃が起きたときの影響範囲が広がります。

「将来使うかもしれない」という理由で権限を先に渡さないことが大切です。利用目的が決まり、テストを通過した機能から追加します。

操作の権限

同じシステムへ接続していても、閲覧と更新は分けます。さらに、下書き作成と外部送信、予約登録と決済、レコード更新と削除も別の操作です。

たとえばメール対応AIなら、次のように段階を設けます。

1. 過去のメールを検索する

2. 返信案を作る

3. 担当者が内容を確認する

4. 担当者の承認後に送信する

最初から4まで自動化する必要はありません。1と2だけでも、担当者の負担は減らせます。

実行環境の権限

AIが動く場所と、接続先への通信経路も確認します。個人のブラウザで動くAI、社内テナント内のAI、APIで構築した専用AIでは、管理方法が異なります。

端末へファイルを書き出せるか、外部URLへ接続できるか、秘密情報をどこへ保存するかも権限の一部です。機密情報を扱う場合は、環境の名称だけで安全と判断せず、実際のデータフローを確認してください。オンプレ生成AIの要件定義ガイドでは、データ、権限、精度、運用をPoCで確認する方法を整理しています。

最小権限は「読める範囲」だけではない

最小権限とは、仕事に必要な最低限のアクセスだけを渡す考え方です。AIエージェントでは、次の3つを同時に絞ります。

• 接続できるシステム

• システム内で扱えるデータ

• 実行できる操作

Microsoftも、自律型エージェントの設計指針で、データベースの読み取りだけが必要なら書き込み権限を与えないこと、重要な操作には人の確認を求めること、詳細なログを残すことを挙げています。Microsoft Learnの設計ガイドはCopilot Studio向けですが、この原則は他のAIエージェントにも応用できます。

Copilot Studioを導入する企業向けには、料金見積もり・権限・運用体制を含む要件定義もまとめています。

最小権限を実務へ落とすときは、「通常時に必要か」だけでなく、「誤動作したときに何が起きるか」を見ます。読み取り権限の誤動作は情報露出につながり、更新権限の誤動作は業務データを壊します。送信権限の誤動作は、顧客や取引先へ直接影響します。

人の承認を残す操作

すべての処理に承認を入れると、AIを使う意味が薄れます。一方、すべて自動化すると事故時の影響が大きくなります。承認の要否は、操作を間違えた場合の影響と、元に戻せるかどうかで決めます。

最初はAIに「提案」まで任せ、人が「実行」する形が現実的です。精度と運用が安定してから、対象を限定して自動実行へ広げます。

監査ログには何を残すか

監査ログは、問題が起きた後の調査だけに使うものではありません。AIが期待した業務だけを行っているか、不要な権限へ触れていないかを確かめる運用データでもあります。

最低限、次の項目を追えるようにします。

• 実行日時

• 指示した利用者、または処理を開始したシステム

• 利用したAI・エージェントの識別子とバージョン

• 参照したデータや呼び出したツール

• 実行した操作と対象

• 承認者、承認日時、承認結果

• 成功・失敗とエラー内容

• 変更前後の値、または生成した成果物の保存先

Microsoftのエージェント設計資料でも、受け取ったトリガー、判断、実行した操作を記録し、通常と異なるデータアクセスを検知する考え方が示されています。また、Microsoft Entra Agent IDのベストプラクティスでは、資格情報の追加、権限付与、ロール変更などを監視し、不要になったエージェントを定期的に確認することが案内されています。

ログの保存期間は一律に決めず、社内規程、法令、契約、インシデント調査に必要な期間を踏まえて決めてください。個人情報や機密情報をログへそのまま残すと、ログ自体が新たなリスクになります。プロンプト全文を保存するのか、識別子や要約だけにするのかも事前に決めます。

権限表を作る手順

いきなり管理画面を設定する前に、1業務を対象に権限表を作ります。

1．業務の開始から終了までを書き出す

誰の依頼で始まり、どの情報を読み、どのシステムへ何を返すかを整理します。AIだけでなく、人が行う確認と例外対応も含めます。

2．データと操作を分ける

参照する文書、顧客情報、入力データ、生成物を列挙します。各データについて、閲覧、作成、更新、送信、削除のどこまで必要かを決めます。

3．実行主体を決める

利用者本人の権限で実行するのか、AI専用のIDを使うのかを決めます。複数人の処理を共通の高権限アカウントで動かすと、誰の操作か追いにくくなり、不要な情報へアクセスする原因になります。

4．承認条件を決める

外部送信、公開、契約、支払い、削除など、影響の大きい操作を抽出します。金額、送信先、データ分類などの条件によって承認者を変える方法もあります。

5．ログとアラートを決める

何を記録し、誰がどの頻度で見るかまで決めます。ログを残すだけでは運用になりません。想定外の接続先、権限変更、失敗の急増など、すぐ確認すべき条件にはアラートを設けます。

そのまま使える権限設計シート

次の項目を1業務につき1枚作成すると、情シス、業務部門、開発会社の認識を合わせやすくなります。

業務名：
利用目的：
利用者・対象部署：
業務責任者：
AI・エージェントの管理者：

参照するデータ：
参照を許可しないデータ：
接続するシステム・ツール：

許可する操作：
禁止する操作：
人の承認が必要な操作：
承認者：

実行に使うID：
秘密情報の保管場所：
ログへ残す項目：
ログの確認担当・頻度：
異常時の停止方法：

PoCで確認するシナリオ：
本番移行の条件：
見直し日：

このシートは、セキュリティ部門だけで完成させないでください。業務上どこまで自動化する価値があるかは現場が判断し、技術的にどこまで制御できるかは開発・情シスが確認します。

よくある失敗

管理者アカウントを共用する

接続が簡単だからと高権限の共通アカウントを使うと、不要なデータまで読めるうえ、誰の指示で処理したかを追いにくくなります。利用者本人の権限か、用途を限定した専用IDを使います。

閲覧と更新を同時に許可する

検索AIとして始めたのに、接続設定では更新・削除も許可されているケースがあります。連携できる機能ではなく、実際に必要な操作だけを許可してください。

承認をAI自身に任せる

AIが作った内容を同じAIが確認して送信しても、独立した承認にはなりません。影響の大きい操作は、人または別の確定的なルールで止めます。

ログはあるが誰も見ない

保存だけしても、異常や権限の広がりには気づけません。通常と異なる利用、失敗回数、権限変更、長期間使われていないエージェントを定期的に確認します。

担当者の異動後も権限が残る

AIの所有者や利用部署が変わっても、接続や秘密情報が残ることがあります。四半期など一定の周期で、所有者、利用目的、権限、最終利用日を見直します。

導入前チェックリスト

• 利用者、管理者、業務責任者が決まっている

• AIが参照するデータを分類している

• 元データのアクセス権がAIの回答にも反映される

• 閲覧、作成、更新、送信、削除を分けている

• 接続ツールを業務に必要なものへ限定している

• 外部送信、公開、支払い、契約、削除に承認がある

• 共通の高権限アカウントを使っていない

• 秘密情報の保管・更新方法が決まっている

• 実行者、参照先、操作、承認結果を追跡できる

• 異常時に停止できる担当者と手順がある

• 担当異動や利用終了時に権限を回収できる

• 定期的な権限レビューの日程が決まっている

1つでも決まっていない項目があれば、製品の設定より先に業務上の判断をそろえます。生成AIの情報漏洩対策全体は、社内利用で外せない5つのチェックポイントも参考にしてください。

端末操作や外部サービス連携まで許可するエージェントでは、製品固有の設定も必要です。たとえばOpenClawについては、Gateway・実行権限・サンドボックス・監査手順を別記事で解説しています。

商談で権限設計が止まりやすい理由

1,000件を超える商談データを分析した傾向では、セキュリティへの不安が25.1％、推進担当者の孤立が15.5％の商談で話題になりました。これは事故が起きた企業の割合ではなく、相談の場で該当テーマへの言及があった割合です。

現場は便利に使いたい一方、情シスは事故を防ぎたい。推進担当者が両者の間に入り、すべてを一人で決めようとすると止まりやすくなります。

解決策は、抽象的に「安全性を確認する」と依頼することではありません。対象業務を1つに絞り、利用者、データ、操作、承認、ログを表にして関係者へ渡します。判断する項目が見えれば、法務・情シス・現場の分担も決めやすくなります。

よくある質問（FAQ）

Q. AIエージェントには専用IDが必要ですか？

用途によります。個人の指示をその人の権限で処理するなら、利用者本人の認証を引き継ぐ方法があります。定期処理や部門共通処理では専用IDが候補になります。いずれの場合も、高権限の共通IDを安易に使わず、所有者と用途を明記してください。

Q. 閲覧だけなら人の承認は不要ですか？

外部への変更がないため、送信や削除より自動化しやすい操作です。ただし、機密情報を閲覧できる範囲は利用者の権限に合わせる必要があります。大量取得や通常と異なる検索には、制限やアラートを設けます。

Q. AIの回答内容も監査ログへ残すべきですか？

調査や品質改善に必要な範囲で残します。ただし、入力・回答の全文には個人情報や機密情報が含まれる可能性があります。保存目的、閲覧者、保存期間、マスキングの要否を先に決めてください。

Q. プロンプトで「削除しない」と書けば十分ですか？

十分ではありません。指示文は補助的な制御です。削除が不要なら、接続先の権限やツールの機能から削除操作そのものを外します。

Q. PoCでも本番と同じ権限設計が必要ですか？

本番と同じ規模にする必要はありませんが、実データを使うなら最低限の認証、アクセス制御、ログ、停止方法は必要です。PoC用データや対象者を限定し、本番移行時に広げる権限を明記します。

Q. 権限設計は誰が責任を持つべきですか？

業務責任者が利用目的と許容できる影響を決め、情シス・セキュリティ担当が技術的な制御を確認し、開発担当が実装します。個人任せにせず、承認者と定期レビューの担当まで決めてください。

権限設計を自社の業務へ落とし込むために｜AIworkerの支援

権限表だけを作っても、対象業務が曖昧なままでは設定を決められません。AIworkerでは、現場の業務を整理し、どこまでAIへ任せるか、人がどこで確認するかを決めたうえで、研修、伴走、業務特化AIの構築を組み合わせます。

AIネイティブX研修｜安全に使う判断力をそろえる

利用者が入力してよい情報、確認すべき出力、禁止される操作を、実際の業務に合わせて学びます。規程を読むだけで終わらせず、現場で迷う場面を使って判断基準をそろえます。

AIネイティブX伴走｜権限と運用を現場で改善する

利用状況を見ながら、権限が広すぎる箇所、承認が多すぎて使われない箇所、ログで追えない箇所を見直します。担当者の異動やツール変更があっても続けられるよう、手順と判断基準を社内へ残します。

業務AIプロ｜必要な範囲だけ動くAIを構築する

社内データ、CRM、ファイル管理、業務システムをつなぐ場合に、利用者ごとのアクセス制御、操作制限、承認、監査ログを含めて設計します。まず1部署・1業務に絞って検証し、問題がない範囲から広げます。

自社のAIが持つ権限を整理したい場合は、対象業務と接続予定のシステムを確認し、最初に作る権限表の範囲を一緒に整理します。

▶️ サービス資料のダウンロード（資料請求）

▶️ 無料カウンセリング・AI活用診断のご予約

著者情報

株式会社AIworker

企業の生成AI導入・人材育成・業務改善を支援しています。1,000件を超える企業商談から得た課題を基に、生成AI研修、業務AI・AIエージェント開発、現場に入る伴走支援を提供。「研修して終わり」ではなく、AIが実際の業務で使われ続ける状態づくりを重視しています。

株式会社AIworker：https://ai-worker.net/

この記事が参考になりましたら、今後の記事づくりの励みになるので、スキをお願いします。

参考資料

• OWASP Foundation「LLM06:2025 Excessive Agency」（2025年版）https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

• NIST「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（2024年7月26日）https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

• Microsoft Learn「Design autonomous agent capabilities」（2026年6月11日更新）https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/autonomous-agents

• Microsoft Learn「Best practices for Microsoft Entra Agent ID」（2026年4月時点の公式案内、2026年8月19日閲覧）https://learn.microsoft.com/en-us/entra/agent-id/best-practices-agent-id

#生成AI #AIエージェント #権限設計 #アクセス制御 #最小権限 #監査ログ #AIガバナンス #生成AIセキュリティ #情報セキュリティ #情シス #情報システム #DX推進 #AI導入 #AI活用 #社内AI #業務AI #RAG #社内GPT #ChatGPT #MicrosoftCopilot #CopilotStudio #OpenClaw #AI開発 #システム開発 #要件定義 #PoC #内部統制 #リスク管理 #データガバナンス #ゼロトラスト #プロンプトインジェクション #シャドーAI #個人情報保護 #機密情報 #人の承認 #HumanInTheLoop #IAM #ID管理 #株式会社AIworker #AIworker