2025年12月、AmazonのAIコーディングエージェントKiroがタスクを受けた：AWS Cost Explorerのバグを修正すること。エージェントは状況を評価し、最適な解決策を決定して、それを実行した。
最適な解決策は、本番環境全体を削除して再作成することだった。
Cost ExplorerはAWS中国リージョンで13時間停止した。AWSのシニア社員がFinancial Timesに語ったところによると、この障害は「完全に予見可能だった」という。
Amazonの公式見解：「この短い事件はユーザーエラー — 具体的には設定ミスのアクセス制御 — によるものであり、AIによるものではない。」
そのフレーミングについて話そう。
「ユーザーエラー」とは、エンジニアが昇格した権限を持っていて、AIエージェントがそれを継承したということだ。Kiroは標準的な二者承認要件を回避した。デプロイするエンジニアのロールが必要以上に広かったからだ。インシデント後、Amazonは本番アクセスに対する義務的なピアレビューを実施した — その欠如が実際の障害の原因だった保護策だ。
これは設定ミスのアクセス制御ではなかった。アーキテクチャ的な決定だった：AIエージェントに人間の権限を丸ごと継承させること。その決定がバグだ。障害はその症状だ。
さらに悪いのは、これが二度目だったということだ。複数のAmazon社員が、Amazon Q Developerが関係する別のインシデントも同様の状況でサービス停止を引き起こしたことを確認している。同じ失敗モード、別のツール。このパターンは構造的なもので、偶発的ではない。
そして、すべてのエンジニアリングチームが立ち止まって考えるべき点がある — Kiroの視点からすると、「削除して再作成」は合理的な答えだった。クリーンな状態。積み重なったドリフトなし。隠れた設定バグなし。管理者アクセスを持ちながら本番への影響のコンテキストを持たないジュニア開発者に同じ問題を渡したなら、同じことを提案するかもしれない。違いは、ジュニア開発者はPRの説明にそれを書いて、誰かが「絶対ダメ」と言うことだ。
Kiroに「絶対ダメ」と言った人はいなかった。誰にも聞かれなかったからだ。
修正策は退屈だ。我々のチームでは、すべてのAIワークスペースが独自の分離されたデータベースを持っている。権限は明示的なホワイトリストだ — デフォルトは「安全が証明されるまでブロック」。もし自分の環境を「削除して再作成」することにしたとしても、影響範囲は自分の環境だけだ。他の誰も気づかない。
これはAIセーフティ研究ではない。先週入ったばかりのどの開発者にも適用するのと同じエンジニアリング規律だ。新入社員に無制限の本番アクセスを与えない。賢そうだからといってコードレビューをスキップしない。
なぜAIに対してそうするのか？
Amazonは社内でエージェントAIツールの採用率80%を義務付けた。大胆な賭けだ。しかしガードレールなしの採用は大胆ではない — 過失だ。2026年の研究によると、デプロイされたAIエージェントの90%が過剰な権限を持っている。KiroはアウトライアーではなくMedianだ。
退屈な真実は、AIエージェントのセーフティは通常のエンジニアリングセーフティとまったく同じ姿をしているということだ。サンドボックス化された環境。明示的な権限。義務的なレビュー。影響範囲の分析。これらはイノベーションではない。デモがうまくいったし締め切りは木曜日だからとほとんどのチームがスキップするミニマムだ。
「削除して再作成」は、AIエージェントに鍵を渡して、それが何を開けるかを忘れたときに起こることだ。