2026年8月31日
AIエージェントに本番作業を任せる際の権限設計
導入：本番権限は「AIに与えるか」ではなく作業単位で決める
AIエージェントへ本番作業を任せるとき、管理者権限を一括付与してから指示文で制限する設計は避けるべきです。まず「誰が、どの資格で、何を読み、何を書き、どう確認し、失敗時にどこまで戻すか」を一つの作業単位として固定します。
たとえば「Webサイトを更新する」では広すぎます。「本番サイトAの指定プラグインを、承認済みバージョンへ1回更新し、HTTP・管理画面・エラーログを確認する」まで狭めると、必要な権限と停止条件を判断できます。
結論：認証・認可・承認を分け、sandboxの外側にも統制を置く
安全な基本形は、読取資格でpreflightを行い、変更内容をローカルで作り、人が作業単位を承認し、限定された書込み資格と固定wrapperで反映し、別の読取処理でverifyする流れです。sandboxは重要ですが、本番側の認可、バックアップ、監査記録、rollbackの代わりにはなりません。
5つの仕組みの役割
| 仕組み | 答える問い | 実装例 | 単独では防げないこと |
|---|---|---|---|
| 認証 | 操作主体は誰か | 個人アカウント、サービスID、多要素認証 | 認証後の過大な操作 |
| 認可 | 何を操作できるか | 対象別ロール、読取専用資格、限定wrapper | 許可済み操作の誤実行 |
| 承認 | この作業を今実行してよいか | 変更票、承認ID、期限付き許可 | 技術的な権限逸脱 |
| sandbox | エージェントのコマンドが技術的に触れられる範囲はどこか | read-only、workspace-write、network制御 | 本番サービス側の包括権限 |
| 監査記録 | 何が起き、誰が判断したか | 対象、入力、承認、結果、検証、時刻 | 誤操作そのものの防止 |
OpenAI公式では、sandbox modeはコマンドが技術的に実行できる範囲、approval policyは実行前に承認を求める条件として説明されています。両者は組み合わせて使うレイヤーです。NISTの最小権限は、利用者またはその代理プロセスに、割り当てられた仕事に必要な最小限の資源と認可だけを与える考え方です。
作業種別ごとの権限マトリクス
| 作業 | 実行主体 | 資格・技術境界 | 承認 | 実行後の検証 |
|---|---|---|---|---|
| 状態の読取 | 調査エージェント | 読取専用資格、networkは対象だけ | 定常範囲は事前承認可 | 対象ID、取得時刻、baselineを保存 |
| ローカル変更 | 作成エージェント | workspace-write、本番資格なし | brief承認 | test、diff、checksum |
| 外部書込み | 反映エージェントまたは固定wrapper | 対象資源と操作を限定した資格 | payload単位の個別承認 | HTTP、DB、ログを別資格で確認 |
| 削除 | 原則として人または専用手順 | 対象を列挙、保護・保留期間を設定 | 二者確認 | 対象外が残ること、復元可能性 |
| 権限変更 | 管理者 | 通常作業と分離した管理資格 | 二者確認と期限 | 付与内容、期限、取消を再確認 |
「書込み可」という権限を一つにまとめないことが要点です。コンテンツ更新に必要な権限へ、利用者追加、設定変更、削除まで含めないようにします。通常処理で管理資格が必要になった時点で、自動化を止めて作業設計を見直します。
本番作業単位の具体例
以下は架空のWordPressプラグイン更新を想定した作業票です。値は例示であり、実在する接続情報ではありません。
change_id: CHG-EXAMPLE-001
target:
environment: production
site_id: site-a
wordpress_root: <approved-wordpress-root>
purpose: <plugin-slug> を承認済みversionへ更新
allowed_effect:
- <plugin-slug> のファイル更新
- 必要な範囲のWordPress DB更新
forbidden_effect:
- 他pluginの更新・削除
- user・role・network設定の変更
backup:
database: <backup-record-id>
files: <backup-record-id>
payload:
plugin: <plugin-slug>
from: <baseline-version>
to: <approved-version>
verify:
- homepage_http_status == 200
- plugin_version == <approved-version>
- new_error_count == 0
rollback:
wrapper: <approved-rollback-wrapper>
restore_points:
- <database-backup-id>
- <files-backup-id>
approval:
approver: <role-name>
expires_at: <timestamp>承認対象は自由文の「更新してよい」ではなく、このtargetとpayloadです。実行wrapperは change_id、対象ID、現在version、payloadのchecksum、承認期限を照合し、一つでも一致しなければ書込み前に終了させます。
preflightからrollbackまでの運用手順
1. preflight
読取専用資格で、接続先、site ID、現在version、maintenance状態、空き容量、直近エラー、バックアップ完了を確認します。作業票のbaselineと一致しない場合は、現在状態に合わせて勝手に書き換えません。
期待結果は「全項目一致」「backupが完了状態」「承認期限内」です。ここで不一致なら実行せず、実測値と作業票を監査記録へ残します。
2. 限定反映
書込み資格は反映工程でだけ供給し、固定wrapperへ作業票を渡します。任意コマンド、対話shell、他サイト指定を許可しない構成が望ましいです。途中でエラーになったら再実行せず、どの副作用まで完了したかを確認します。
3. 独立verify
反映に使った終了コードだけで成功としません。別の読取資格または監視系から、外部HTTP、対象version、主要画面、DB状態、エラーログを確認します。代表出力を文書へ載せる場合は「例示」と明記し、実測記録と混同しないでください。
4. rollbackまたは保留
verify不合格なら新しい変更を重ねません。rollbackの前提と対象を確認し、承認済み手順で戻した後、同じverifyを再実行します。DBとファイルに依存関係がある場合、片方だけ戻すと不整合になるため、作業票で復元単位を固定します。
失敗状態ごとの停止・記録・再開条件
| 状態 | 停止位置 | 必ず残す記録 | 再開条件 |
|---|---|---|---|
| preflight不一致 | 書込み前 | 期待値、実測値、対象、時刻 | 作業票を再作成し再承認 |
| 途中失敗 | 直ちに追加操作を停止 | 完了した副作用、終了コード、ログ、資格ID | 状態を読取で確定し、rollbackまたは継続を再承認 |
| verify失敗 | 成功扱いせず公開停止 | 不合格項目、HTTP・DB・ログの証跡 | rollback完了または修正版の新規作業票 |
| rollback不能 | 対象への全書込み停止 | 失敗箇所、復元点、影響範囲 | 責任者と専門担当が復旧計画を承認 |
同じpayloadを再実行して安全か確認できない場合は、冪等と推測してはいけません。既に反映された副作用を調査し、新しいchange IDで判断し直します。
監査記録に残す項目
- change ID、対象環境、対象資源
- 指示とpayloadのchecksum
- 認証主体、使用したロール・資格ID（秘密値は記録しない）
- sandbox mode、approval policy、network条件
- preflightの期待値と実測値
- backup IDと完了確認
- 承認者、承認時刻、期限
- 実行開始・終了時刻、終了コード、外部副作用
- verifyの項目、証跡、不合格理由
- rollbackの判断、結果、再verify
OpenAI公式では、監視を明示的に有効化した場合、承認判断やtool resultなどの構造化イベントを出力できると説明されています。ただし、どの監査項目を保存するか、保持期間、閲覧権限は組織側で設計する必要があります。
注意点
sandbox内で動くから安全、本番資格があるから承認済み、バックアップファイルがあるから復元可能、と短絡しないでください。それぞれ別の確認事項です。秘密鍵、トークン、接続値を作業票・ログ・記事へ記載せず、資格の識別子と供給手順だけを記録します。
NIST SP 800-53は組織がリスクに応じて調整する管理策カタログであり、この表を採用すれば同規格へ適合すると断定できるものではありません。法令、契約、業界基準、対象システムの復旧要件を別途確認してください。
公式・一次情報
関連記事
AIエージェントの導入は、対象業務、権限、検証、担当者の役割を一体で設計する必要があります。支援内容はIT・業務改善支援をご覧ください。
