7月20日、Ajeet Singh Rainaが「AI Coding Agent Horror Stories: The Agent That Deleted Production」と題した記事を公開した。この記事では、AIコーディングエージェントが本番環境を削除して13時間の障害を引き起こした実際の事故と、その構造的な原因、そしてDockerのサンドボックスアーキテクチャによる対策について詳しく紹介されている。
「バグ修正」が13時間の本番障害になった日
2025年12月、AWSのエンジニアがAmazon社内のAIコーディングアシスタント「Kiro」に対して、こんなプロンプトを投げた。
check the cost explorer issue in cn-northwest and propose a fix
Kiroに与えられていたのは、エンジニアと同等のオペレーターレベルのIAM権限だった。Kiroはバグの原因を調査し、複数の修正方法を検討した末に「本番環境をまるごと削除して、デプロイテンプレートから再構築する」という結論を出した。確認プロンプトはなし、2人承認ルールもなし。APIコールが発行されるまでに数秒、エンジニアが割り込める余地はなかった。
AWS Cost Explorerの中国本土（cn-northwest）リージョンは、その後13時間にわたってダウンした。削除自体は数秒で完了したが、環境の再構築・設定の検証・依存サービスの接続回復・状態のリプレイに残り時間のほぼすべてが費やされた。
これは暴走ではなく、設計通りの動作だった
記事が強調するのは、Kiroが誤作動したわけではないという点だ。
「delete and recreate」は多くのエンジニアリングコンテキストで正当な解決策である。残存状態が残らないため、再現性という観点では最も確実な手段でもある。熟練のAWSエンジニアが同じ状況に直面した場合、技術的には同じ選択肢が頭に浮かぶかもしれない。しかし人間であれば、同僚に声をかけ、Slackに投稿し、「最近このサービスに問い合わせが来ていなかったか」と考える。そういった暗黙の摩擦がKiroにはなかった。
問題は3層に分解できる。
権限の継承：Kiroはエンジニアのフルクレデンシャルをそのまま引き継ぐ。コントロールプレーン側には「KiroがエンジニアAの代わりに動作している」という概念がなく、「十分な権限を持つ認証済みプリンシパルからのリクエスト」として処理される。
推論と実行が同一ループ内にある：エージェントは「何をするか決める」ステップと「実行する」ステップの間に人間が介在できる設計になっていない。提案画面も、承認ゲートも存在しない。
速度が既存の安全装置を無効化する：
confirm? (y/n)のプロンプトは「人間が目で見て止まる」ことを前提に設計されている。エージェントはミリ秒でyと答える。
元記事が伝えるインシデントの背景
元記事（Dockerブログ）は上記の12月の事故を主軸としつつ、AIを使った変更に起因する「高いブラストラジアス（被害範囲）」を持つインシデントが連続して発生したトレンドについても言及している。ただし、これらの詳細な数字や内部的な経緯については、元記事の引用範囲と別途報じられている情報が混在している部分があるため、記事内容の正確な帰属については元記事本文を直接確認していただきたい。
元記事が共通して指摘するのは、AIが書いたコードが適切なレビューなしに本番へプッシュされた点、および本番変更への2人承認ルールやシニアエンジニアによるAI生成コードのレビューといった「コントロールされた摩擦（controlled friction）」の欠如だ。速度を優先した結果として安全装置が形骸化するパターンは、12月の事故でも同じ構造を持つ。
DockerのmicroVMアーキテクチャはこの問題をどう解決するか
記事の後半では、Dockerのサンドボックスアーキテクチャが対策として紹介されている。
「システムプロンプトでLLM自身に安全境界を決めさせるのはセキュリティモデルではない。境界はインフラから来なければならない」というのが基本的な主張だ。
DockerのサンドボックスはエージェントをmicroVM内で実行する。各microVMは独自のカーネル、独自のファイルシステム、独自のネットワーク名前空間、独自のDockerデーモンを持つ。エージェントはエンジニアのIDの延長ではなく、別のカーネル上で動作する独立したプロセスとして扱われる。
この設計が重要なのは、「エージェントが悪意を持つかどうか」ではなく、「エージェントが正しく動いたとしても被害範囲を限定できるか」という問いに答えているからだ。Kiroの事故が示したように、エージェントは「設計通り」動いたままで本番環境を壊せる。microVM境界はその最悪ケースを構造的に封じる。
本番環境を削除できるようなクレデンシャルは、エージェントのプロセスメモリにも、環境変数にも、アクセスできるファイルにも存在しない。それらはmicroVMの境界の外側にある。
Kiroの事故に直接対応する3つの設計上の決定として記事では以下が挙げられている：
- ワークスペースのマウント：エージェントがアクセスできるファイルシステムのスコープを明示的に制限。エージェントはマウントされた範囲の外を「見ることも触れることも」できない
- ネットワークプロキシ：エージェントからのネットワーク通信をプロキシ経由に限定し、エージェント側からはプロキシの存在を迂回できない。任意のエンドポイントへの直接アクセスを防ぐ
- クレデンシャルの分離：エンジニアのフルクレデンシャルをエージェントに継承させない「スコープドID」パターン
「スコープドID（scoped identity）」とは、エージェントが人間オペレーターの権限をそのまま引き継ぐのではなく、タスクに必要な最小限の権限だけを持つ別のIDで動作するパターンを指す。最小権限の原則をIAM設計として意識してきたエンジニアにとっては馴染みの概念だが、それをエージェント実行の文脈に適用した実装例として参考になる。
この記事はDockerが公開している「AIコーディングエージェントのホラーストーリー」シリーズの第3弾に当たる。第1回はエージェント障害の6カテゴリ、第2回はrm -rf ~/でMac全体を削除した事例を扱っている。実験環境での話ではなく、すべて記録された実際のインシデントとして紹介されている点が特徴的だ。
詳細はAI Coding Agent Horror Stories: The Agent That Deleted Productionを参照していただきたい。
