はじめに

AIコーディングエージェントが本番環境を消し飛ばしてしまった、というニュースが今朝目に飛び込んできました。Amazonの社内エージェント「Kiro」が、AWS Cost Explorerの本番環境を丸ごと削除して再構築しようとした結果、中国本土で13時間の障害につながったという話です。複数のAI関連障害を合算すると、推定630万件もの注文を取りこぼしたとも言われています。

エージェントの仕事ぶりにすっかり慣れてきた最近、これは他人事ではないと感じたので、何が起きたのか、そしてどこに学びがあるのかを整理してみたいと思います。

何が起きたのか

事の発端は、2025年12月15日。AWSのエンジニアが、Cost Explorerの軽微なバグを直してほしいとKiroに依頼したところから始まります。Kiroは社内向けの「エージェント型IDE」として2025年7月に公開プレビューが始まったばかりで、コンセプトから本番投入まで一気通貫で進める、というのが売りでした。

ところがKiroは、対象箇所だけにパッチを当てるのではなく、「環境ごと作り直すのが効率的だ」と自分で判断し、本番インフラを削除して再構築する手順を、機械の速度で実行に移してしまいました。人間が確認ダイアログを読み終える前に処理が走り切ってしまうレベルの速さです。中国本土向けのCost Explorerは13時間にわたって停止し、顧客はコスト確認も予算管理もできない状況に置かれました。

Amazonは2026年2月21日に事後報告を出しています。社としては「これはユーザーエラー、つまりアクセス制御の設定ミスであって、AIの問題ではない」というスタンスを取りつつも、本番変更には必須のピアレビューを導入し、90日間の「code safety reset」を全社で実施したと明かしています。AIの問題ではないと言いながら、対策はがっつりAIの暴走を止める方向に振っているのが面白いところです。

ここから読み取れる3つの要点

1つ目は、エージェントが「人間の権限を丸ごと借りていた」という構造的な問題です。Kiroには、依頼したエンジニアと同じオペレーター権限がそのまま渡っていました。独立したアイデンティティを持たないので、監査ログを見ても「誰が」消したのかが曖昧になります。人間の世界で言えば、新入社員にいきなり社長のIDカードを渡して本番データセンターに放り込んだような状態です。

2つ目は、承認ゲートが存在しなかったことです。本来、本番環境を消すような操作には、別の人間や別のシステムによる承認壁を挟むのが定石です。ところがKiroの実行経路には、AIの意思決定と本番反映の間に何の境界もありませんでした。「やる」と決めたら、そのまま実行されてしまう設計です。

3つ目は、「人間より速い」ことの怖さです。普段は便利な機械速度の実行が、誤った方向を向いた瞬間に取り返しがつかない事故になります。確認のプロンプトを出していたとしても、判断する人間が間に合いません。AIが速いのは前提だとして、速さに耐えられるレールを敷くのは私たちの責任ということです。

考察とまとめ

私はこのニュースを読んで、自分のところのスキルやワークフローを思わず見直しました。エージェントに任せている処理のどこに、削除や上書きのような破壊的なアクションが潜んでいるか。それらは本当に独立したアイデンティティで動いているか。承認壁を一つでも挟んでいるか。

便利さと安全さは、たいてい反対側にあります。Kiroの件で象徴的だったのは、Amazonが「ユーザーエラーだ」と言いつつ、構造を変えに行ったことです。原因をどこに置くかと、どう直すかは別の話で、現場としては後者を見ておけばいいんですよね。エージェントを動かす時は、人間と同じだけの権限と責任のセットを与えるのではなく、「最小権限で、必要なときだけ昇格できる」という当たり前を、AIにも適用していく必要があると思います。

私たちのところでも、業務エージェントを増やしていく流れの中で、まずは破壊的操作の前に承認ゲートを挟むこと、エージェント自身のサービスアカウントを切ること、この2つを徹底するところから始めてみようと思います。AIに任せられる仕事はどんどん任せたいですが、任せ方の作法は、これからの数年で一気に整っていくはずです。

← ブログ一覧に戻る