データエンジニアリングを学ぶ10万人以上の学生を抱える教育プラットフォーム「DataTalks.Club」の創設者であるAlexey Grigorev氏の環境において、インフラストラクチャの完全な喪失という重大なインシデントが発生した。原因は、Anthropicの提供する自律型AIコーディングエージェント「Claude Code」に対して与えられた、たった一つのコマンド実行権限である。同エージェントが本番環境の設定ファイル群を読み込み、インフラ構成管理ツールであるTerraformを通じて「terraform destroy」を実行した結果、本番システムを構成するすべての要素が消滅した。
被害の範囲は広範に及んだ。VPC（Virtual Private Cloud）、Amazon RDS（Relational Database Service）、ECSクラスター、ロードバランサー、そして踏み台サーバーに至るまで、クラウド上に展開されていた本番環境のインフラ全体が跡形もなく削除された。最も致命的であったのは、システム上で2年半にわたって蓄積されていた学生の課題提出、プロジェクト、リーダーボードのスコアなど、計194万3200行に及ぶデータベースの全記録が失われたことである。さらに、それらを復旧するための自動スナップショット（バックアップ）までもが道連れとなった。本インシデントは、強力な権限を持たせたAIエージェントが無警戒に実行機能を行使した際に生じる「ブラスト・ラディアス（影響範囲）」の制御不能性を、極めて明確な形で業界に提示している。
アーキテクチャ共有の罠と状態管理の欠落が生んだ致命的な連鎖
事の発端は、Grigorev氏が個人的なサイドプロジェクトである「AI Shipping Labs」のインフラをGitHub PagesからAWSへと移行させようとした計画にある。同氏はコストを抑える目的から、新規プロジェクトのインフラを既存のDataTalks.Clubのものと分離せず、同じVPC内に同居させるという判断を下した。Claude自身はインフラの共有について事前に懸念を示していたが、Grigorev氏はコストメリット（月額5〜10ドル程度の削減）を優先してAIの助言を退けた。
決定的な人為的ミスが発生したのはこの移行プロセスの開始直後である。同氏は作業用に使用するコンピューターを新調しており、Terraformが現在のインフラ状態を把握するための「ステートファイル（terraform.tfstate）」を古いPCに取り残したまま、新しい環境からClaude Codeにインフラの構築を指示したのだ。
ステートファイルを欠いた状態のTerraformは、AWS上にすでに存在するVPCやRDSなどのリソースを認識することができない。Claude Codeが「terraform plan」を実行した際、ターミナル上には既存のインフラが「新規に作成されるリソース」として大量に出力された。これを見たGrigorev氏は、Terraformが現状のインフラを認識できていないことに気がつき、計画の適用（terraform apply）を中断させた。しかしながら、わずかな時間差ですでにいくつかの不要な重複リソースがクラウド上に作成されてしまっていたのである。これが、後に取り返しのつかない全損を引き起こすトリガーとなった。
破滅へのプロセス：警告の無視とAIによる「忠実すぎる」コード実行
不要に作成された重複リソースのクリーンアップ作業において、Grigorev氏はClaude Codeに対し、AWS CLIを用いて重複した対象のみを特定し、既存の本番環境には触れずに削除するよう指示を出した。ここまでは、通常のトラブルシューティングの範疇である。しかし、作業の過程でGrigorev氏は古いコンピューターからTerraformのアーカイブ（設定ファイルや状態ファイルを含む）を持ち込み、その差分から対象を特定するようAIエージェントに指示を追加した。
このアーカイブにはDataTalks.Clubの本番環境を定義するクリティカルな設定ファイル群が含まれていた。AIエージェントはCLIでの削除作業が困難であると判断し、「Terraformによって作成されたリソースである以上、Terraformのコマンド機能を用いてクリーンアップするべきである」という論理的な提案を行った。そして、Grigorev氏の同意の下で「terraform destroy」を実行した。
この時、Grigorev氏は「新たに作成された重複リソースのみが削除対象になる」と誤認していた。しかし、Claude Codeの手元にはすでに本番環境の設定ファイルが存在しており、Terraformはその設定ファイルに記述された「すべてのインフラ」を破壊対象として認識し、忠実に実行に移したのである。AIエージェントは指定されたタスクを論理的に完遂する手段としてdestroyコマンドを選択したが、そのコマンドが本番稼働中のサービスにどのような壊滅的な結果をもたらすかという「文脈的理解」や「実行への躊躇」を持ち合わせていない。人間であれば本環境に対してdestroyを打ち込む直前に強い抵抗を覚える場面であっても、スクリプトの実行を委譲されたエージェントは、指示された通りに、何の感情的なブレもなく破滅のコマンドを射出したのだ。
隠されたスナップショット：AWS Business Supportによる起死回生の復旧劇
インフラ消失の事実が発覚したのは作業当日の深夜である。Grigorev氏がDataTalks.Clubのサイトダウンを確認し、AWSマネジメントコンソールへアクセスしたときには、データベースを含む一切のリソースが消え去っていた。
最も絶望的な状況は、深夜2時に自動取得されているはずの直近のRDSスナップショットまでもが存在していなかったことである。インフラストラクチャをコードで管理（IaC: Infrastructure as Code）する場合、バックアップ機能自体もTerraformの管理下に置かれることが多い。そのため、terraform destroyコマンドはデータベースの本体だけでなく、同設定によって動作していた自動スナップショット群をもAWSのコンソール上から完全に抹消してしまった。
万策尽きたGrigorev氏は、深夜0時30分に月額コストが約10％増加するAWS Business Supportプランへと即座にアップグレードを行い、緊急チケットを発行した。サポートエンジニアの対応の末に明らかになったのは、ユーザーのAWSコンソール上からは完全に消去されたように見えるスナップショットのコピーが、AWSのバックエンドシステム（内部的な管理領域）に一時的に残留しているという事実であった。AWS側での専門的な内部対応により、インシデント発生からちょうど24時間後、データベースは奇跡的に復旧を果たした。「courses_answer」テーブルの194万行に及ぶ学習データは無傷でクラウド上へ生還し、教育プラットフォームは再び稼働を開始した。
本インシデントにおける真の根本原因
本件は技術コミュニティであるHacker News上で瞬く間に拡散し、多くのエンジニアから数百に及ぶ議論が交わされた。業界全体の一致した見解は、「これはAIの暴走による失敗ではなく、インフラ管理における基本的な防御策を怠った人間の運用設計上の欠陥である」という極めて妥当なものである。システムにおける真の根本原因は以下の複数の要素が連鎖した点にある。
第一に、ステートファイルの一元管理が欠如していた点である。ローカルPCという単一の環境にインフラの命綱であるステートファイルを保存していたことが、すべての設定の不整合の起点となった。大規模なインフラ環境においては、これをリモートバックエンド（S3など）で一元化することが常識である。
第二に、システム側の削除保護（Deletion Protection）の不在である。AWSレイヤーにおけるRDSの設定、およびTerraform側のLifecycleポリシーのどちらにおいても、リソースの誤削除を防ぐための保護設定がなされていなかった。
第三に、独立したバックアップシステムの欠如である。インフラ基盤と運命を共にする形式での自動バックアップのみに依存し、インフラ外部からリストア可能なS3経由等の物理的に切り離された定期バックアップを取っていなかったことが、復旧を困難にさせた。
そして最後に、AIエージェントの自動実行機能に対する過信である。「計画立案」から「適用」「破壊」に至るまで、CI/CDパイプライン上で人間による明示的な承認プロセス（マニュアル・レビューゲート）を挟むことなく、強い権限を与えたエージェントにターミナルの制御をそのまま明け渡したことが決定的な引き金となった。
生成AI時代のインフラ防御策：被害を未然に防ぎ切る6つの防壁
このインシデントからの教訓として、Grigorev氏は自らのインフラ運用体制を抜本的に再構築し、以下の6つの厳格な防壁を導入したとしている。これらは、AIを活用するすべての開発チームが標準化すべきベストプラクティスである。
- 二重の削除保護設定の義務化： AWSにおける主要なデータベースリソース側の「Deletion Protection」と、Terraform側の設定（prevent_destroy等）の双方を有効化し、意図せぬリソース削除に対してハードウェアレイヤーに近い部分でのストッパーを設ける。
- ステートファイルのリモート管理とバージョン管理： Terraformの状態を示すステートファイルをS3へと完全に移行し、同時にバージョニングを有効化する。これにより、デバイスの移動等による状態の消失や巻き戻りが物理的に発生しない構造を構築する。
- 継続的なリストアテストの自動化： Lambda関数とStep Functionsを用いて、毎晩作成されるバックアップから新しいデータベースインスタンスを自動的に立ち上げ、内部で検証クエリを実行する仕組みを構築する。検証が完了した後にデータベースを停止させることで、バックアップデータが「確実に復元可能な状態であること」を毎日自動で証明する。
- S3への独立バックアップ保存： Terraformのライフサイクルとは独立して、不可逆的な削除保護機能（明示的に中身を空にしなければバケットが消えない等）を持たせたS3環境にデータベースのダンプを退避させる。
- 本番環境と開発環境のAWSアカウント分離： 少しのコストを惜しむことなく、異なるプロジェクトや検証用のインフラは完全に分離されたAWSアカウント上に展開し、不必要な共有によるリスク連鎖（クロス・コンタミネーション）を根本から断ち切る。
- AIエージェントの無制限実行の完全禁止： Claude Codeのような自律型AIからターミナルでのコマンドの自動実行権限を剥奪する。「何を行うべきか」という立案まではAIに行わせるが、最終的な「Apply」や「Destroy」の叩き込みは必ず人間のエンジニアが手動でレビューし、承認した上で実行するパイプラインへと強制的に切り替える。
自律型AIと共存するためのインフラ設計の再定義
「テストされていないバックアップは、バックアップではない。そして、実行権限を制限されていないツールは、いつかシステムを破壊する」。これが本件を通してデータエンジニアリング業界が再認識した真理である。
AIコーディングエージェントの登場により、コードの生成からインフラの構築スピードは飛躍的に向上した。しかし、AIはターミナル上でエラーを解決しようとひたすらに論理を追従するあまり、背景にあるビジネス的価値やデータ消失の重大性を肌感覚として理解することはできない。本インシデントはAIツールの危険性を示したものではなく、AIをオペレーターとして据える前提での「ゼロトラスト・インフラストラクチャー」の構築がいかに急務であるかを証明している。システムに変更を加える最終段階には、必ず人間の判断を介入させる制御アーキテクチャこそがエンジニアリングの要となるのである。
Sources
