先に要点
- AIエージェントに本番操作を任せる前に、まず `何をしてよいか` ではなく `何をしてはいけないか` を決めます。
- 重要なのは、権限範囲、承認点、実行ログ、停止条件、ロールバック手順、責任者を先に明文化することです。
- 読み取り、提案、下書き、検証環境での実行、本番反映を分けると、いきなり危険な自動化に進みにくくなります。
AIエージェントがコード、クラウド、データベース、チケット、メール、デプロイツールを扱えるようになると、作業の幅は一気に広がります。
障害調査、ログ確認、設定差分の確認、軽い修正、デプロイ前チェックまで任せられるなら便利です。
ただし、本番環境への操作は別物です。
AIが賢いかどうかだけでなく、間違えたときに止まるか、誰が承認したか、何を変更したか、戻せるかまで決めておかないと、便利な自動化がそのまま事故の入口になります。
この記事では、AIエージェントに本番操作を任せる前に決めることを、実務で確認しやすい順番で整理します。
人間承認そのものは 人間承認をどこで入れるべき？AIエージェントの承認設計を整理、承認後の記録は AIエージェントの承認ログには何を残すべき？後から説明できる記録設計 でも詳しく扱っています。
まず結論：本番操作は「許可したことだけできる」設計にする
AIエージェントに本番操作を任せるときの基本は、自由に動ける担当者を作ることではありません。
決められた範囲の作業だけを、決められた手順で、記録を残しながら進められる実行者を作ることです。
たとえば、次のように段階を分けます。
| 段階 | AIエージェントに任せやすいこと | 注意点 |
|---|---|---|
| 読み取り | ログ確認、設定確認、差分確認、メトリクス確認 | 個人情報や認証情報を読める範囲に注意する |
| 提案 | 原因候補、修正案、影響範囲、手順案の作成 | 提案と実行を同じ権限にしない |
| 下書き | PR作成、SQL案、設定変更案、手順書の作成 | 人間レビューを前提にする |
| 検証環境での実行 | テスト実行、検証デプロイ、再現確認 | 検証環境と本番環境の接続を分ける |
| 本番反映 | 承認済み手順の実行、限定的な再起動、監視確認 | 承認、ログ、停止条件、戻し手順を必須にする |
いきなり 本番DBを更新して 障害を直して と渡すのではなく、どの段階まで自動化するかを分けて決める方が安全です。
決めること1：本番操作の範囲
最初に決めるのは、AIエージェントに渡す作業範囲です。
ここを曖昧にすると、プロンプトでは慎重に書いたつもりでも、ツール権限やAPI権限の方が広すぎて危険になります。
少なくとも次を分けます。
実務では、最初から本番更新を許可しない方が進めやすいです。
まずログ確認、変更案の作成、PR作成、検証環境での確認まで任せ、安定してから本番の限定操作を検討します。
決めること2：ツールと権限の粒度
AIエージェントが使うツールは、便利さだけで選ばない方がよいです。
サーバーにSSHできる DBに接続できる クラウド管理APIを叩ける は、かなり強い権限です。
危険なのは、ひとつのツールに読み取り、書き込み、削除、権限変更がまとまっている状態です。
たとえば database_tool という大きなツールを渡すより、次のように分けた方が判断しやすくなります。
| 粗い渡し方 | 分けた渡し方 | 効果 |
|---|---|---|
| DB操作ツール | 読み取り専用、更新案作成、承認済みSQL実行 | 勝手な更新や削除を防ぎやすい |
| クラウド操作ツール | 状態確認、スケール変更、再起動、削除を分離 | 危険操作だけ承認必須にできる |
| デプロイツール | ビルド確認、ステージング反映、本番反映を分離 | 本番反映だけ強く管理できる |
| 通知ツール | 下書き作成、社内通知、顧客送信を分離 | 外部送信の事故を減らせる |
前回の AIエージェントにツールを渡しすぎると何が起きる？選択ミス・コスト・権限リスクを整理 でも書いた通り、ツールは多ければよいわけではありません。
本番操作では特に、少ないツールを狭い権限で渡す方が扱いやすくなります。
決めること3：承認が必要な操作
すべてを人間承認にすると遅くなります。
一方で、すべてを自動化すると事故の影響が大きくなります。
そのため、承認必須の操作を先に決めます。
代表例は次の通りです。
- 本番DBの更新、削除、マイグレーション
- 本番デプロイ、本番設定変更、再起動
- 顧客や外部サービスへの送信
- 課金、返金、請求、契約状態の変更
- 権限付与、権限削除、認証設定の変更
- 大量データのエクスポート
- 取り消しにくいバッチ実行
ここで大事なのは、承認しますか？ だけの確認にしないことです。
承認者が判断できるように、AIエージェントが何をしようとしているか、対象、影響範囲、戻し方、失敗時の症状を一緒に出す必要があります。
人間承認は、AIへの不信感から入れるものではありません。
影響が大きい作業について、責任ある判断点を明確にするための仕組みです。
決めること4：停止条件
本番操作では、成功条件だけでなく停止条件を決めます。
AIエージェントは、途中で失敗しても別の方法を試そうとすることがあります。調査や下書きでは助かる動きですが、本番では危険になることがあります。
たとえば、次の条件では止めると決めておきます。
- 想定と違う環境に接続している
- 対象件数が予定より多い
- テストやヘルスチェックが失敗した
- 依存サービスの状態が不安定
- 権限エラーが出た
- 同じ操作を複数回失敗した
- 指示にない外部送信や削除が必要になった
- 実行前に提示した差分と実際の差分が違う
特に 権限エラーだから別の方法で突破する ような挙動は止めるべきです。
本番操作では、回避策を探すより、いったん止まって人間に判断を戻す方が安全です。
決めること5：ログに何を残すか
本番操作をAIエージェントに任せるなら、監査ログは必須です。
あとから見たときに、誰の依頼で、どのAIエージェントが、何を見て、何を判断し、何を実行したかが分からないと、障害対応にも説明責任にも耐えにくくなります。
最低限、次を残します。
- 依頼者、承認者、実行者
- 実行日時
- 対象環境
- 対象リソース
- 実行前の入力、判断材料、要約
- 呼び出したツールと引数
- 実行結果
- 承認または拒否の結果
- エラー、再試行、停止理由
- ロールバックしたかどうか
ログは 全部残す だけでも不十分です。
認証情報、個人情報、機密情報をそのまま残すと、ログ自体がリスクになります。マスキング、保存期間、閲覧権限もセットで決めます。
決めること6：ロールバック手順
本番操作を任せる前に、戻し方を決めておきます。
AIエージェントが作業を実行できても、失敗したあとに人間が慌てて戻し方を探す状態では危険です。
本番反映の前に、少なくとも次を確認します。
- 変更前の状態を確認できるか
- 変更差分を説明できるか
- バックアップやスナップショットがあるか
- 戻し手順があるか
- 戻し手順をAIが勝手に実行してよいか
- 戻した後の確認項目があるか
- ロールバック判断を誰がするか
意外と見落としやすいのは、ロールバックも危険操作だという点です。
戻すつもりで別のデータを消す、古い設定へ戻して別の障害を起こす、ということもあります。ロールバックは自動実行より、人間承認つきにする方がよい場面が多いです。
決めること7：責任者と連絡経路
本番操作をAIエージェントに任せる場合でも、責任者はAIではありません。
誰が依頼し、誰が承認し、誰が結果を確認し、問題が起きたら誰に連絡するのかを決めます。
特に、夜間や休日にAIエージェントを動かす場合は注意が必要です。
- 自動でどこまで対応してよいか
- どのエラーで人間を呼ぶか
- 何分以内に応答がなければ止めるか
- 顧客影響がある場合に誰へ通知するか
- 障害報告にAIの実行内容をどう含めるか
AIエージェントは作業者のように見えますが、組織上の責任を持つわけではありません。
そのため、運用フローの中では 誰が最終判断者か を明確にしておく必要があります。
よくある失敗例
実務で危ないのは、次のような始め方です。
失敗例1：本番DBの読み取り権限だけのつもりで更新権限も渡す
調査用に接続しただけのつもりでも、認証情報が更新権限を持っていると、AIエージェントから見れば更新もできる状態です。
プロンプトに 更新しないで と書くより、読み取り専用ユーザーを使う方が堅いです。
失敗例2：検証環境と本番環境を同じツール名で渡す
deploy というツールが検証にも本番にも使えると、指示や文脈の取り違えが起きやすくなります。
deploy_staging と deploy_production_requires_approval のように、ツール名と権限で違いを出した方が安全です。
失敗例3：承認ログは残るが、差分が残らない
承認者と日時だけ残っていても、何を承認したのか分からなければ意味が薄くなります。
SQL、設定差分、デプロイ対象、対象件数、影響範囲を一緒に残します。
失敗例4：AIエージェントに復旧まで任せきる
障害時は早く戻したくなります。
しかし、原因が不明なまま自動復旧を繰り返すと、影響範囲を広げることがあります。復旧操作こそ、停止条件と人間判断を入れるべきです。
実務で使える導入順
最初から本番操作を自動化する必要はありません。
おすすめは、次の順番です。
1. 読み取り専用
ログ、メトリクス、設定、デプロイ履歴を読ませます。ここでは変更権限を渡しません。
2. 提案と下書き
修正案、PR、SQL案、作業手順を作らせます。人間レビューを前提にします。
3. 検証環境で実行
テスト、ステージング反映、再現確認を任せます。本番とは認証情報を分けます。
4. 限定的な本番操作
承認済みの手順だけ実行させます。実行後の確認とログ保存まで含めます。
この順番なら、AIエージェントの便利さを試しながら、失敗時の影響を小さくできます。
MCPや外部ツールを使う場合の注意点
AIエージェントに MCP サーバーや外部APIを渡す場合も、考え方は同じです。
接続できることより、何ができてしまうかを確認します。
見るべきポイントは次です。
- そのMCPサーバーが扱えるリソース
- 読み取りと書き込みが分かれているか
- 危険操作に承認を挟めるか
- ツール呼び出しのログを残せるか
- 認証情報がどこに保存されるか
- 本番環境と検証環境を分けられるか
- ツールの説明文がAIに誤解されにくいか
OpenAI Agents SDK のドキュメントでも、Agents は instructions、tools、handoffs、guardrails などを組み合わせて動くものとして整理されています。
つまり、モデルだけでなく、ツール、ガードレール、承認、実行環境をまとめて設計する必要があります。
本番操作前チェックリスト
最後に、AIエージェントへ本番操作を任せる前のチェックリストをまとめます。
- 本番で許可する操作と禁止する操作を分けた
- 読み取り、下書き、検証、本番反映の段階を分けた
- ツール権限を最小限にした
- DB更新、削除、デプロイ、外部送信、権限変更に承認点を置いた
- 承認画面に対象、差分、影響範囲、戻し方を出す
- 実行ログと承認ログを残す
- 認証情報や個人情報をログに残しすぎない
- 停止条件を決めた
- ロールバック手順を確認した
- 責任者と連絡経路を決めた
- 検証環境で同じ流れを試した
このチェックを通せないうちは、AIエージェントに本番操作を任せるより、提案や下書きに留める方が安全です。
まとめ
AIエージェントに本番操作を任せる前に決めるべきことは、モデル選びだけではありません。
権限範囲、承認点、ログ、停止条件、ロールバック、責任者を先に決めておく必要があります。
本番操作は AIができるか ではなく、間違えたときに止まれるか 後から説明できるか 戻せるか で判断します。
まずは読み取り、提案、下書き、検証環境での実行から始め、限定的な本番操作へ段階的に広げるのが現実的です。
この考え方は、ハーネスエンジニアリングとは？AIエージェントを安定運用する設計を整理 や コード主導のオーケストレーションとは？AIエージェントの流れをコードで決める設計 ともつながります。
本番操作を安全に扱いたいなら、プロンプトだけでなく、AIの外側にある運用設計を一緒に整えることが大事です。