AIが本番環境を削除し復旧に13時間 「暴走」ではなかったAWS事例：本番事故を防ぐ権限設計とは

Dockerのデベロッパーアドボケイト、アジート・シン・ライナ氏は、AIコーディングエージェントが本番環境を削除し、AWSのサービスを13時間停止させた事例を紹介した。同事例から得られた5つの対策とは。

[TechTargetジャパン]

　AIコーディングエージェントに不具合の調査を任せたら、本番環境を削除してしまった――。

　Dockerのデベロッパーアドボケイト、アジート・シン・ライナ氏は2026年7月20日、AIコーディングエージェントが、本番環境で人間の担当者と同等の権限を持って動作した結果、AWSのサービスを停止させた事例をDockerのブログで紹介した。

　本稿では、同事例を基に、AIコーディングエージェントを本番環境の近くで利用する際に、情報システム（情シス）部門や開発部門が注意すべき点を紹介する。

小さな修正依頼のはずが、本番環境を削除

併せて読みたいお薦め記事

AIエージェントの関連記事

• 本番DB削除から機密流出まで AI導入企業を襲った4大インシデント
• 大企業の半数がAIエージェントを本番運用も…… 7割が抱える“致命的な課題”

　ライナ氏によると、2025年12月、あるAWSのエンジニアはAIコーディングエージェント「Kiro」に、「AWS Cost Explorer」（AWSのクラウドサービスのコスト削減を支援するツール）の小規模な不具合の調査と修正案の提示を依頼した。

　Kiroは設定の不整合を見つけ、既存環境を部分的に修正する方法や、特定の構成要素だけを再配置する方法などを検討した。その上で、本番環境を一度削除し、構成テンプレートから作り直す方法が最も確実だと判断したという。

　問題は、Kiroが修正案を提示するだけでなく、その判断を直ちに実行できたことだ。実はKiroには、依頼したエンジニアと同じオペレーター権限が与えられていた。削除前の確認画面や、別の担当者による承認、破壊的な操作を検知するポリシーもなかった。

　その結果、中国本土のリージョンでAWS Cost Explorerが停止し、復旧まで13時間を要したという。削除処理自体は短時間で完了したが、環境の再構築や設定の検証、依存サービスとの再接続、蓄積された状態の復元に時間がかかった。

AIは「暴走」したのではなく、与えられた目的を実行した

　この事例で重要なのは、AIが命令を無視したわけではない点だ。Kiroに与えられた目的は、不具合を修正することだった。「環境を削除して再構築する」という方法も、開発環境や検証環境では合理的な選択肢になり得る。

　しかし本番環境では、技術的に実行可能であることと、実際に実行してよいことは同じではない。人間のエンジニアであれば、影響範囲の大きさに気付き、同僚に相談したり、変更申請を出したり、作業を一時停止したりする可能性がある。

　AIエージェントには、こうした組織上の暗黙の慣習が自動的に備わっているわけではない。判断と実行が同じ処理の中で進む場合、担当者がAIの決定を確認する前に、APIの呼び出しやコマンドの実行が完了することもある。

　「実行しますか」と尋ねる確認プロンプトだけでも十分とは限らない。AIエージェント自身が確認に応答できる構成であれば、人間を止めるための確認処理を数ミリ秒で通過してしまう可能性があるからだ。

人間の権限をAIにそのまま継承させる危険

　ライナ氏が根本原因として挙げるのが、AIエージェントと人間のユーザーを、システムが別々の主体として識別できていなかった点だ。

　AIエージェントがエンジニアの認証情報をそのまま利用する場合、クラウドの制御基盤からは、正規の権限を持つエンジニアが操作しているように見える。人間が閲覧できる情報はAIエージェントも閲覧でき、人間が削除できる環境はAIエージェントも削除できる。

　この構成では、AIエージェントが誤った判断をした際の影響範囲は、担当者が持つ権限の大きさと同じになる。管理者権限を持つ担当者がAIエージェントを起動すれば、AIエージェントも事実上、管理者として振る舞えるということだ。

　AIエージェントの利用範囲を広げる際は、利用率や生成コード量だけでなく、「AIエージェントが誤操作した場合に、どこまで影響が及ぶか」を指標として管理する必要がある。以下は、そのための対策だ。

対策1．AI専用の最小権限IDを用意する

　最初に見直すべきは、AIエージェントに使用させるIDだ。担当者の認証情報をそのまま渡すのではなく、作業ごとに権限を限定した専用IDを発行する。

　例えば、障害原因の調査だけを任せる場合は、ログや設定を閲覧できる読み取り専用権限に絞る。修正案を作成させるために、リポジトリへのアクセスが必要であっても、本番環境の削除やデプロイまで許可する必要はない。

　調査、コード作成、テスト、本番反映を同じ権限で実施させるのではなく、それぞれを別の役割として分離することが重要だ。

対策2．認証情報をAIから見えない場所に置く

　APIキーやクラウドの認証情報を、環境変数や設定ファイルとしてAIの実行環境に格納する方法にも注意が必要だ。

　AIが秘密情報を直接読み取れる状態では、誤ってログに出力したり、生成したコードに埋め込んだり、意図しない外部サービスへ送信したりする可能性がある。

　ライナ氏は具体的な対策として、認証情報をAIエージェントの外側にあるプロキシで管理し、許可された通信にだけ認証情報を付与する方式を紹介している。AIエージェントには秘密情報そのものを渡さず、「特定のサービスに対して、許可された操作を実施できる能力」だけを提供する考え方だ。

対策3．接続先を許可リストで制限する

　最小権限のIDを用意しても、ネットワーク上のあらゆる接続先にアクセスできれば、意図しない操作が発生する余地は残る。

　そこで、AIエージェントが接続できるAPIやドメインを許可リストで限定し、本番環境を変更する制御用APIには接続できないようにする。調査に必要な読み取り用APIだけを許可し、削除や更新に利用するエンドポイントを遮断する方法もある。

　権限管理とネットワーク制御を組み合わせれば、認証情報の設定に誤りがあった場合でも、破壊的な操作を別の層で止められる。

対策4．AIエージェントが作成した変更に人間の承認を必須とする

　AIエージェントが生成したコードや設定変更を、そのまま本番環境へ反映させない運用も欠かせない。

　ライナ氏は、「AIエージェントによる変更を通常の変更とは別の区分として記録すること」「少なくとも2人による確認を求めること」を挙げる。経験の浅い担当者がAIエージェントを利用した場合は、上位のエンジニアによる承認を必須にするといったルールも考えられる。

　AIエージェントの導入目的として作業の高速化を挙げるユーザーもいるが、本番への反映まで無条件に高速化すれば、誤った変更も速く広がる。提案や検証はAIエージェントに任せつつ、影響の大きい操作はあえて工数を増やすことが大切だ。

対策5．AIエージェントの操作履歴を独立して記録する

　「誰がAIエージェントを起動したか」だけでなく、「AIエージェントがどの接続先へアクセスし、どの操作を試み、何が拒否されたのか」を記録することも重要だ。

　人間とAIエージェントが同じIDを共有すると、監査ログを見ても、人間が直接操作したのか、AIエージェントが代理で操作したのかを区別できない場合がある。

　AIエージェント専用のIDやセッション単位の実行環境を使い、許可された通信と拒否された通信を記録すれば、事故調査だけでなく、権限設定や許可リストの改善にも利用できる。

安全対策を利用拡大と同じ速度で進める

　企業がAIコーディングエージェントを導入する際、ユーザー数や利用頻度、生成コード量をKPIに設定することは珍しくない。しかし、導入率だけを急いで高めると、AIエージェントが操作できるシステムや認証情報も一気に増える。

　AIエージェントが扱う権限の範囲、破壊的操作を止められる仕組み、人間による承認率、AIエージェントが拒否された通信の件数といった安全性の指標も、利用状況と併せて追跡したい。

　AIエージェントを安全に利用する方法は、「慎重に行動するよう指示する」だけではない。誤った判断をしても、本番環境には到達できない構造を作ることが重要だ。