AIエージェントの権限設計では、モデルがどれだけ賢いかより、「何を読めて、何を提案できて、何を実行してよいか」を分けることが重要です。読み取り、更新、送信、削除までを同じ権限で持たせると、便利でも事故の影響が一気に大きくなります。
AIエージェントの権限設計は、エージェントを「営業支援」「問い合わせ対応」「データ整備」のような用途別のロールに分け、ロールごとに読み取り・更新・送信・削除のどこまでを許すかを表にすることから始めます。そのうえで、金額や件数の上限、社外宛て、個人情報、取り消せない操作といった「人の承認へ戻す条件」を操作ごとに決めます。アプリの権限に加えて、エージェントが動く端末やブラウザのファイル・ネットワークへの到達範囲も分けておきます。
要点
- AIエージェントの権限は、営業支援や問い合わせ対応など用途別のロールに分け、ロールごとに読み取り・更新・送信・削除の範囲を表で決めます。
- 権限内の操作でも、件数や金額の上限超え、社外への送信、価格や個人情報、取り消せない操作は人の承認へ戻します。
- 読み取り範囲はエージェントではなく依頼者の権限で絞り、端末やブラウザのファイル・ネットワークへの到達範囲も別に制限します。
権限を切る基本単位
AIエージェントの権限は、システム単位ではなく操作単位で切る方が実務的です。たとえばCRMにアクセスできるかどうかではなく、閲覧だけか、下書きまでか、更新までか、顧客送信までか、削除までか、という粒度で分けます。
| 権限レベル | 許可する操作 | 初期導入の推奨 |
|---|---|---|
| 閲覧 | レコード参照、検索、要約 | 最初から持たせやすい |
| 提案 | 下書き、更新候補、分類候補 | 初期導入向き |
| 更新 | レコードの項目変更、タグ付け | レビュー付きで開始 |
| 送信 | メール送信、外部投稿 | 承認必須が基本 |
| 削除 | レコード削除、取り消し困難な処理 | 極力限定する |
このように切っておくと、同じAIエージェントでも用途ごとにロールを分けやすくなります。たとえば営業支援用は閲覧と提案まで、運用自動化用は一部更新まで、といった設計が可能になります。
ロール別の権限表
同じAIエージェント基盤でも、用途ごとにロール（実行ユーザー）を分けると、事故が起きたときの影響を1つの用途に閉じ込められます。次の表は、営業・CS領域でよく使う4つのロールの例です。
| ロール | 読み取り | 更新 | 送信 | 削除 |
|---|---|---|---|---|
| 営業支援（要約・次の一手の提案） | 担当範囲の顧客・商談・活動履歴 | 不可（更新候補を下書きで出す） | 不可（メールは下書きまで） | 不可 |
| 問い合わせ一次対応 | FAQ、公開済みの製品情報、問い合わせ本文 | 問い合わせの分類・担当者の割り当て | 定型回答のみ。それ以外は人の承認 | 不可 |
| データ整備（重複統合・項目補完） | 対象オブジェクトの全件 | 指定項目のみ。上限件数内 | 不可 | 不可（統合は人の承認） |
| 定例レポート作成 | 集計に使う項目のみ | レポート用の領域のみ | 社内の決まった宛先のみ | 不可 |
表の「担当範囲」は、エージェント自身の権限ではなく、依頼した人が見られる範囲で絞ります。管理者権限を持つ共通アカウントでエージェントを動かすと、依頼者が本来見られないデータまで読めてしまいます。
人の承認へ戻す条件
権限内の操作でも、次の条件に当てはまるときは自動で実行せず、人の承認を待ちます。数値の上限は業務ごとに決めます。
| 条件 | 例 | 理由 |
|---|---|---|
| 件数・金額が上限を超える | 一度に更新する件数、見込金額の変更幅 | 誤りの影響が一度に広がる |
| 社外へ出る | 顧客宛てメール、外部共有リンクの作成 | 送った後に取り消せない |
| 価格・契約条件・個人情報を含む | 見積金額、値引き、契約期間、氏名や連絡先の変更 | 法務・信用上の影響が大きい |
| 取り消せない操作 | 削除、統合、外部システムへの確定送信 | 元に戻せない |
| 根拠が不足している | 必須項目が空、参照データが古い、判断が分かれる | もっともらしい誤りをそのまま実行しやすい |
たとえば、更新権限は持たせるが上限を超える件数や高額案件だけは承認必須にする、送信権限は持たせず常に下書きまでにする、といった運用です。人がどの場面で止めるかの考え方はHuman in the loop、実行前の確認項目はAIエージェントガバナンス、ログに残す項目の雛形は監査ログテンプレートで確認できます。
実行環境の権限も分ける
AIエージェントの権限設計では、アプリ上のロールだけでなく、エージェントが動く実行環境も分ける必要があります。2026年6月2日の Windows Developer Blog では、Microsoft Execution Containers（MXC）SDKを、AIエージェントのファイル、ネットワーク、プロセス、セッションをポリシーで制約する実行レイヤーとして説明しています。
2026年10月7日の Windows Developer Blog では、MXCの一般提供が発表されました。エージェントが使うファイルやネットワークの接続先をポリシーで宣言し、実行時にエージェントの外側から制限する仕組みです。プロセス単位のコンテナーはWindows 11、macOS、Linuxで使え、MicroVMは試験的な提供とされています。Intuneでの管理ポリシーは今後提供予定とされているため、導入時は対象の端末と管理方法で使える範囲を確認してください。
これはWindowsだけの話ではなく、企業がAIエージェントを本番で使うときの一般原則として使えます。CRMの更新権限を制限していても、同じ端末上のファイル、ブラウザ、社内ネットワーク、クリップボードに自由に触れるなら、別経路で事故が起きます。したがって「CRMで何ができるか」と「実行環境でどこへ到達できるか」を別々に確認するべきです。
| 制約する対象 | 設計で見ること | 曖昧だと起きること |
|---|---|---|
| ファイル | 読み書きできるディレクトリ、添付ファイル、出力先 | 不要な顧客ファイルや社内資料を読み込む |
| ネットワーク | 接続できるAPI、社内ドメイン、外部送信先 | 未承認のSaaSや社内システムへ到達する |
| セッション | 人の画面、クリップボード、入力デバイスとの分離 | 人の作業中データや画面状態に巻き込まれる |
| 監査ID | 人とエージェントの操作主体を分けて記録する | 誰が実行した処理か追えなくなる |
特にローカルPC上で動くコーディングエージェント、営業資料を読むエージェント、ブラウザ操作を伴うエージェントでは、アプリ権限だけでは足りません。専用の実行ユーザー、分離された作業ディレクトリ、許可ドメイン、監査ログを用意し、必要に応じて使い捨ての実行環境を選べるようにすると、失敗時の影響範囲を抑えやすくなります。
最小権限から始めるべき理由
導入初期は、モデルの出力品質だけでなく、参照データの欠損や業務ルールの抜けが見つかります。その段階で更新や送信まで自動化すると、問題が顧客や本番データに直接出やすくなります。
そのため、最初は読み取りと提案を中心に始め、ログと再編集率を見ながら更新権限を広げる方が安全です。いきなり強い権限を与えるより、運用知見が溜まってから拡張する方が、止めるべき条件も決めやすくなります。
権限設計でよくある失敗
- サービスアカウントに人間の管理者と同等の権限をそのまま付与する。
- 送信や削除のような高リスク操作に承認フローを置かない。
- 例外発生時の差し戻し先が決まっていない。
- 監査ログがなく、誰の判断で実行されたか追えない。
とくに外部送信と削除は、技術的に可能でも運用上は強く制限した方が無難です。権限設計はセキュリティ設定ではなく、責任分界の設計でもあります。
よくある質問
AIエージェントの権限設計で重要なことは何ですか？
システム単位ではなく操作単位で権限を切り、閲覧、提案、更新、送信、削除を分けることです。
最初から更新権限を持たせてよいですか？
初期導入では、まず提案中心で始め、ログと品質を見ながらレビュー付きで更新権限を広げる方が安全です。
送信権限はどう扱うべきですか？
顧客影響が大きいため、基本は承認必須か下書き止まりにする方が実務的です。
実行環境の分離はなぜ必要ですか？
アプリ上の権限を制限しても、AIエージェントが同じ端末のファイル、ブラウザ、社内ネットワーク、クリップボードへ自由に触れると別経路で事故が起きます。専用ユーザー、作業ディレクトリ、許可ドメイン、監査IDを分け、失敗時の影響範囲を小さくするために必要です。
権限設計と一緒に決めるべきものは何ですか？
承認ポイント、例外処理、監査ログ、差し戻し先です。ここまで決まって初めて権限が運用に乗ります。
管理者権限のアカウントでエージェントを動かしてもよいですか？
避けます。依頼者が本来見られないデータまで読めてしまい、誤更新の影響も広がります。用途別のロールを作り、読み取りは依頼者の権限で絞ります。
承認へ戻す件数や金額の上限はいくつにすべきですか？
業務ごとに、誤りが起きたときに人が確認・修正できる量を基準に決めます。最初は低めに置き、ログで差し戻しの少なさを確認してから上げます。
