技術解説
AIエージェントの権限設計：承認・ログ・停止条件を先に決める
AIエージェントへツール操作を任せる前に、読み取り、作成、変更、送信、削除を分け、承認ポイント、監査ログ、上限、停止条件を設計する方法を解説します。
- 公開日
- 最終検証
- 次回確認
- 確信度
- HIGH
この記事で分かること
- エージェントの権限を「接続の許可」だけで判断してはいけない理由
- 読み取り、作成、変更、送信、削除を分ける設計
- 承認・監査ログ・回数上限・停止を一つの運用にする方法
- 導入前に試すべき失敗ケース
結論： AIエージェントの権限は、ツール名ではなく「誰が、どの対象へ、どの引数で、どこまで実行できるか」で設計します。読み取りと外部送信、下書きと公開、変更と削除を一つの許可にまとめないことが出発点です。
操作を分類し、最小権限、承認、監査、停止を重ねて設計する。
なぜ画面上の「接続を許可」だけでは足りないのか
エージェントが行えることは、モデルの設定だけで決まりません。OSやサービスのアカウント権限、ツール実装、接続先、ネットワーク、データの保存先、承認経路が組み合わさって決まります。
MCPの公式セキュリティ資料は、認可フロー、トークンの対象検証、最小スコープ、SSRFなどを含む接続先の安全性を扱っています。NIST AI RMFは、AIのリスクを統治、文脈把握、測定、管理の継続的な活動として整理しています。本記事の操作レベルとテンプレートは、これらの原則を実務向けに具体化した編集部案です。
まず操作を六つに分ける
| レベル | 操作 | 例 | 初期方針 |
|---|---|---|---|
| 0 | 参照なし | 固定説明だけで回答 | 自動可 |
| 1 | 読み取り | 文書検索、一覧取得、状態確認 | 対象を限定して可 |
| 2 | 作成 | 未公開の下書き、提案、検証用ファイル | 保存先を限定して可 |
| 3 | 変更 | 既存データ・予定・設定の更新 | 差分を示して承認 |
| 4 | 外部送信・実行 | メール送信、投稿、発注、デプロイ | 原則として毎回承認 |
| 5 | 削除・権限変更 | 完全削除、共有範囲変更、アカウント停止 | 原則禁止または二段階承認 |
メール連携なら、検索はレベル1、返信案はレベル2、ラベル変更はレベル3、送信はレベル4、完全削除はレベル5です。保存先から後続処理が起きるファイル作成も、実質的な実行として扱います。
最小権限を、対象と引数まで落とす
「更新APIを使える」だけでは粗すぎます。次の項目を決めます。
- 対象：どの組織、環境、フォルダー、レコードか
- フィールド：何を変更できるか。価格、送金先、公開状態、所有者、権限は除外できるか
- 件数・時間：一回に読める件数、変更件数、実行時間、再試行回数
- 接続先：許可するホスト、プロトコル、認証スコープ
- 出力先：下書き、レビュー、公開のどこにだけ書けるか
人の管理者アカウントをそのまま使わせず、用途ごとの専用実行主体を用意します。共有アカウントしか使えず、誰の操作か追えない場合は、変更・送信・削除の権限を渡さない方針が安全です。
承認は「実行される値」を対象にする
承認は画面の説明文に対して行うのではなく、確定した対象と引数に対して行います。最低限、承認画面へ次を表示します。
- 操作名と実行主体
- 対象のID・環境・宛先
- 変更前後の差分
- 金額、件数、権限などの影響情報
- 参照した根拠と、未確認事項
- 承認後に内容が変わった場合の再承認条件
承認後に宛先や本文を変えられるなら、その承認は使えません。対象や引数が変われば、承認を失効して再確認する仕組みにします。
ログと停止条件を先に作る
監査ログには、調査に必要な情報を最小限で残します。
| 残すもの | 残さないもの |
|---|---|
| 実行時刻、タスクID、実行主体、操作種別 | パスワード、トークン、Cookie |
| 対象、正規化した引数、変更前後の差分 | 不要な本文、個人情報の生データ |
| 承認の有無・対象・結果、停止理由 | 認証ヘッダー、秘密を含む例外全文 |
停止条件は「異常が起きたら止める」ではなく、数値や条件で定義します。
stop_conditions:
time_limit_minutes: 10
max_tool_calls: 30
max_records_changed: 3
external_sends_without_approval: 0
stop_on:
- target_outside_allowlist
- approval_payload_changed
- permission_denied
- audit_log_unavailable
- repeated_identical_action
on_stop:
- cancel_pending_actions
- preserve_redacted_audit_log
- require_human_review_to_resumeこれは製品固有の設定ではなく、設計を点検するための例です。実装では、実際に強制できる制御に置き換えます。
導入前に失敗を再現する
権限設計は、正常なデモだけでは確認できません。テスト環境で次を試します。
- 許可外のフォルダーやレコードIDを指定する
- 承認後に宛先、金額、変更内容を変える
- 同じ変更を繰り返し要求する
- ログ保存先を一時的に利用不能にする
- 件数、時間、再試行の上限を超える
- 停止中に新しいタスクを投入する
合格条件は、画面に「停止」と出ることではありません。未実行の操作が中止され、理由が記録され、変更や送信が実システムで起きておらず、人が確認するまで再開できないことです。
導入判断のチェックリスト
- 専用の実行主体があり、管理者権限を流用していない
- 対象、操作、引数、上限、ログが作業単位で決まっている
- 外部送信・公開・削除・権限変更は下書きや読み取りと分離されている
- 承認の対象と実行時の値が一致し、変更時に再承認される
- 停止条件を実際に試験し、復旧手順を説明できる
一つでも満たせない高リスク操作は、エージェントに任せず、情報整理や未公開下書きまでに範囲を絞ります。
まとめ
自律性を一つのオン・オフで考えると、必要以上に広い権限を渡しやすくなります。まずは限定した読み取りと非公開の作成から始め、承認、ログ、停止を検証してから変更や送信へ広げます。速度よりも、止められることと説明できることを優先してください。
参照した一次情報
確認日：2026年8月10日。
PRIMARY SOURCES
確認した一次情報
広告