2026年3月6日、アレクセイ・グリゴレフはSubstackにてポストモーテム（事後検証）を公開した。
同氏が創設するDataTalks.Clubのコース管理プラットフォームで、2月26日午後11時頃、Claude CodeエージェントがTerraformのterraform destroyコマンドを実行したことにより、本番インフラが全て削除されたというものだ。
RDS、VPC、ECSクラスター、ロードバランサー、bastionホストが消失し、2.5年分の宿題・プロジェクト・リーダーボードのデータが失われた。自動スナップショットも同時に削除されていた。グリゴレフはAWS Business Supportへアップグレードし、クラウド費用が10%増加した。
AWSサポートは削除から約24時間後の2月27日午後10時頃にスナップショットを復元した。復元後、courses_answerテーブルで1,943,200行のデータが確認された。
From: 
How I Dropped Our Production Database and Now Pay 10% More for AWS
【編集部解説】
この事案を「AIが暴走した」と一言で片付けるのは、あまりにも表面的な見方です。むしろ本質は、AIエージェントという新しい「同僚」とどのように協働すべきかという、私たちが今まさに直面している問いそのものにあります。
まず、事案を理解する上で欠かせない技術的な背景を整理します。Terraformとは、クラウドインフラ全体をコードで定義・管理するツールです。「ステートファイル」と呼ばれる設定ファイルが、現在どのようなインフラが存在するかをTerraformに伝える役割を担っています。このファイルが欠落すると、Terraformは既存のインフラを「存在しないもの」と判断し、ゼロから環境を構築しようとします。逆に古いステートファイルが読み込まれると、そこに記載されたインフラを「正とすべき状態」として扱い、差分を解消しようとします。今回はその両方が最悪のタイミングで重なりました。
見落とされがちな重要な事実があります。Claude Codeはもともと、インフラを共有することへのリスクをグリゴレフ氏に警告していました。月5〜10ドルという微々たるコスト削減を優先したのは人間の側であり、エージェントはむしろ正しい判断を示していたのです。その警告を退けたのは、他でもないグリゴレフ氏自身です。彼自身も記事の中でこの点を率直に認めており、その誠実さこそがこのポストモーテム（事後検証）が世界中で注目された理由の一つでしょう。
では、なぜエージェントはterraform destroyを実行してしまったのか。技術的な経緯を辿ると、エージェントが「論理的に正しい」判断をした結果であることがわかります。Terraformで作成されたリソースをTerraformで削除する、という判断は手順として間違っていません。問題は、エージェントが知らないうちに古いステートファイルに切り替わっており、削除対象が本番環境全体を指していたという文脈を把握できていなかった点にあります。つまりエージェントは、与えられた情報の範囲内では「正しく」動作していたのです。
ここで浮かび上がるのが「コンセント・ファティーグ（承認疲労）」と呼ばれる問題です。AIエージェントがファイルの読み取りやディレクトリの移動といった無害な操作のたびに承認を求め続けると、人間はやがてその確認を深く考えずにクリックするようになります。terraform destroyの実行承認も、そうした流れの中の「もう一つのクリック」に過ぎなかった可能性があります。セキュリティの専門家の間では、この問題が深刻な懸念として認識されています。AWS自体がリソース削除前に「リソース名を入力して確認せよ」という摩擦を設けているのに対し、AIエージェントの承認UIにはそれに相当する重みが存在しない、という指摘は的を射ています。
このインシデントは、グリゴレフ氏個人の失敗にとどまりません。ガートナーは2028年までに企業のセキュリティ侵害の25%がAIエージェントの悪用に起因すると予測しており、クラウド・セキュリティ・アライアンスの調査では、AIエージェントの正式な管理戦略を持つ組織は多くはないと報告されています。AIエージェントが本番環境に深く入り込むほど、「人間が監視できる速度」と「エージェントが行動する速度」の差は広がっていきます。
同時に、このインシデントがAIエージェントの有用性を否定するものではないことも強調したいと思います。グリゴレフ氏自身、復旧作業の中でTerraformを使って他のインフラ部分の再構築を迅速に進め、複数のロードバランサーを一つに統合するなど整理の機会にもしています。また事後に導入したLambdaとStep Functionsによる自動バックアップ検証のワークフローは、適切なガードレールを設けた上での自動化の好例です。自動化の恩恵を受けながら、人間が判断の責任を持ち続けるという姿勢こそが、今後の標準的な運用モデルになっていくはずです。
規制の観点からも、この事案は無視できません。EUのAI規制法（AI Act）は2026年8月2日に完全適用され、重大なリスクをもたらすAIシステムへの要件が厳格化されます。インフラ管理の領域でのAIエージェント活用は、今後ますます規制の射程に入ってくると考えられます。
最後に、この事案が示す最も根本的な教訓を一つ挙げるとすれば、「テストされていないバックアップはバックアップではない」という点です。バックアップの存在を信じ込むことと、バックアップが実際に復元できることを確認し続けることは、まったく別の行為です。グリゴレフ氏が事後に構築した「毎日バックアップから実際にデータベースを復元して確認する」仕組みは、AIエージェント時代のインフラ管理が目指すべき方向を、皮肉にも最も明確な形で示しています。
【用語解説】
ステートファイル（Terraform state file）
Terraformがクラウド上に存在するインフラの現状を記録したファイルである。このファイルをもとにTerraformは「何が存在するか」を把握し、次にどんな操作をすべきかを判断する。ファイルが欠落・古い状態になると、Terraformは実際のインフラを「存在しない」と誤認し、重大な誤操作を引き起こすリスクがある。
VPC（Virtual Private Cloud）
クラウド上に構築される仮想的なプライベートネットワーク空間のことである。AWSなどのクラウド環境において、サーバーやデータベースなどのリソースを外部から隔離し、セキュリティを確保するために使われる。今回の事案では複数のプロジェクトのリソースが同一のVPC内で管理されており、それが被害範囲を拡大させた一因となった。
ECSクラスター（Elastic Container Service cluster）
AWSが提供するコンテナ管理サービスのことである。DockerなどのコンテナをAWS上で動かすための実行環境の集合体であり、Webアプリケーションの本番稼働を支えるインフラの中核を担う。
bastionホスト（踏み台サーバー）
プライベートネットワーク内のサーバーに安全にアクセスするための中継サーバーである。インターネットに直接公開せずに内部リソースへ接続できる構造を実現し、セキュリティを高める役割を持つ。
スナップショット（RDS）
データベースの特定時点における状態を丸ごと保存したバックアップデータのことである。障害時にこのスナップショットからデータベースを復元することができる。通常はデータベースと切り離して管理するが、今回は同一のTerraform管理下に置かれており、データベースと共に削除されてしまった。
コンセント・ファティーグ（承認疲労）
AIエージェントが操作のたびに承認を求め続けることで、人間がその確認を深く考えずにクリックするようになる現象のことである。小さな操作への承認が積み重なることで、本来慎重に判断すべき危険な操作まで無意識に許可してしまうリスクがある。今回の事案でも、このメカニズムがterraform destroyの実行を招いた可能性が指摘されている。
ポストモーテム（事後検証）
システム障害やインシデントが発生した後に、原因・経緯・再発防止策を詳細に記録・分析するプロセスのことである。エンジニアリングの文化として広く定着しており、失敗を組織の学びに転換するための重要な実践である。グリゴレフ氏の記事は、この手法に則った透明性の高いポストモーテムとして、世界中の開発者コミュニティから注目を集めた。
【参考リンク】
Claude Code｜Anthropic（外部）
AnthropicのAIコーディングエージェント。ターミナルから直接操作でき、コード生成・デバッグ・ファイル編集・コマンド実行をAIが担う。今回の事案でTerraformを操作したツールである。
Terraform｜HashiCorp（外部）
クラウドインフラをコードで定義・管理するオープンソースのIaCツール。AWS・Azure・GCPなど主要クラウドに対応し、インフラの構築から削除まで一括して自動化できる。
DataTalks.Club（外部）
アレクセイ・グリゴレフが創設したデータサイエンス・機械学習のグローバルコミュニティ。Slackメンバー8万人以上が参加し、無料のZoomcampコースや週次ポッドキャストを提供している。
Amazon Web Services（AWS）（外部）
Amazonが提供するクラウドコンピューティングプラットフォーム。今回の事案ではRDS・ECS・Lambda・S3・Step Functionsなど複数のサービスが関係した。
AWS サポートプラン（外部）
AWSが提供するサポートプランの一覧ページ。Business Supportは本番インシデントに対して1時間以内の応答を保証する。グリゴレフ氏が加入しAWS費用が10%増加した。
EU AI Act（欧州AI規制法）｜欧州委員会（外部）
EUが策定した世界初の包括的AI規制法。2026年8月2日に完全適用。違反時には最大3,500万ユーロまたは全世界売上高7%の制裁金が科される。
Gartner（外部）
世界有数のITリサーチ・コンサルティング企業。「2028年までに企業のセキュリティ侵害の25%がAIエージェントの悪用に起因する」という予測を発表している。
Cloud Security Alliance（CSA）（外部）
クラウドセキュリティの標準化と啓発を推進する国際的な非営利団体。AIエージェントのセキュリティリスクや承認疲労に関する研究・勧告を発行している。
【参考記事】
Claude Code Wipes Production Database in Terraform Mishap｜Awesome Agents（外部）terraform destroyによる全消失事案を詳報。ステートファイル管理ミス・削除保護不在・バックアップ独立性欠如・無制限アクセスという4つの失敗要因を整理している。
AI Security: IAM at Agent Velocity｜Cloud Security Alliance（外部）
AIエージェントが毎分5,000回操作できる環境での人間監視の限界を論じる。AIインシデントが1年で56.4%増加・2024年に233件報告という統計を提示。
The AI Agent Identity Crisis: A 2026 Guide｜Strata（外部）
AIエージェントの正式な管理戦略を持つ組織は多くはないというCSA調査を報告。HITL実現のアーキテクチャ不足の現状を明示している。
Claude Code Wiped Out 2.5 Years of Production Data in Minutes｜UC Strategies（外部）
事案を「強力な自動化と人間の思い込みの相互作用」と位置づけ、AIエージェントがリスクの爆発半径を把握できない本質的な問題を指摘している。
Claude Code deletes developers’ production setup｜Tom’s Hardware（外部）
技術系メディアの視点から事案を解説。エージェントへの広範な権限付与と、本番環境でのパーミッション管理の重要性を強調している。
Claude Code wiped a developer’s production database｜Aihola（外部）
「コンセント・ファティーグ」を明確に言語化。AWS削除確認UIとAIエージェント承認UIの重みの違いという製品設計上の課題を具体的に指摘している。
Why AI Should Never Run terraform apply｜Medium（外部）terraform applyはライブシステムへの変更行為であり、AIは結果に責任を持てないため人間が担うべきと論じる。事案約1ヶ月前の先見的な論考。
【編集部後記】
月5〜10ドルのコスト削減が、2.5年分のデータ消失と24時間の復旧作業、そしてAWS費用の恒久的な10%増につながった——。笑えない話ですが、「自分は大丈夫」と言い切れる人がどれだけいるでしょうか。
AIエージェントに作業を任せるとき、私たちはどこまでその「文脈」を共有できているか。今一度、確認してみてください。
