AIエージェントが本番を壊す前に, ロールバック可能性を前提化する運用設計

この数日, 開発コミュニティで強く共有された教訓はシンプルです。AIエージェント事故の多くは「モデルが賢くない」ことより, 「権限設計と復旧設計が弱い」ことから起きます。

本番環境のデータやバックアップが削除されるような事故は, たいてい次のパターンで発生します。

ゴールは曖昧だが, 実行権限は広い
事前検証がなく, そのまま書き込みに進む
取り消し手段がある前提だが, 実際には間に合わない

つまり問題は, エージェントを「会話の延長」で運用してしまっている点です。

まず前提を変える

エージェント実行は, 人間の補助UIではなく, 本番トランザクションの実行面です。したがって設計の中心は以下になります。

意図の構造化（何を, どこまで, どの条件で）
権限の最小化（実行ごとに短命・限定）
ポリシー審査（危険操作の遮断）
復旧可能性の実証（演習済みであること）

事故が起きる4層

1. Intent層

「不要データを整理して」のように目的だけ渡し, 安全条件を渡していない。

2. Capability層

通常タスクに不要な破壊系APIまで同じ資格情報で実行可能。

3. Verification層

dry-runや差分確認なしで本実行。承認もチャット合意で終わる。

4. Recovery層

バックアップはあるが, RTO内で戻せない。復旧手順が机上。

推奨アーキテクチャ, 4段階パイプライン

A. Plan-onlyフェーズ

エージェントは「読む・計画する」だけ。出力は機械可読な計画書。

影響リソース一覧
変更差分
リスククラス
ロールバック手順

B. Policy Gate

OPA等のポリシーエンジンで計画を評価。

productionでのワイルドカード削除禁止
バックアップ領域削除は原則deny
high risk操作は二者承認必須

C. Scoped Execution

実行時トークンを都度発行し, TTLとスコープを最小化。

テーブル単位権限
破壊系APIはデフォルト無効
バックアップ管理系の権限分離

D. Post-commit検証

実行後に必ず検証を自動化。

実変更オブジェクトの棚卸し
ポリシー判定IDの紐づけ
整合性Canary
復旧リハーサルフック

失敗時は補償アクションへ自動遷移します。

今週導入すべき運用コントロール

破壊系APIを前段プロキシでdeny-by-default化
dry-runマニフェスト署名を必須化
本番操作用IDとバックアップ管理IDを分離
低遅延で効くグローバルKill Switchを整備
エージェント暴走を想定した復旧ゲームデイを月次化

経営層が見るべき指標

スコープ限定短命トークンで実行された比率
ポリシーによる危険操作ブロック件数
暴走エージェント隔離までの時間
復旧演習の成功率と実測RTO
高リスク操作の二者承認率

「成功率が高い」より, これらの指標のほうが事故予防能力を正確に示します。

まとめ

AIエージェントの導入は止めるべきではありません。ただし, 本番権限を持たせるなら, 実行を必ず制約付きトランザクションに変換する必要があります。

強いプロンプトより先に, 強い実行境界を作る。これが2026年の本番運用の分岐点です。

参考文脈: https://news.ycombinator.com/ / https://gigazine.net/