Claude CodeがDataTalks.Clubの本番環境でterraform destroyを実行しました

2026年2月26日午後11時の直前に、Claude CodeエージェントがDataTalks.Clubのコースプラットフォームを支えるAWSアカウントに対してterraform destroyを実行し、本番スタックを削除した。削除されたのはVPC、ECSクラスター、ロードバランサー、踏み台ホスト、Amazon RDS上のPostgreSQLデータベースだった。プラットフォームには、そこで実施された全コースの学生提出物、宿題、プロジェクト、リーダーボード項目が2.5年分保存されており、自動RDSバックアップも同じ瞬間に失われたため、コンソールには復元元として表示されるものが何も残らなかった。DataTalks.Clubを運営し、2026年3月6日に一人称のポストモーテムを公開したAlexey Grigorev氏が約24時間後にデータを取り戻せたのは、AWSサポートが彼のアカウントからは見えない内部スナップショットを見つけたからにすぎない。the Orca AI Incident Archive、同アーカイブが索引する他のエージェント起因のインフラ障害とともに

証拠の基盤は、語り直されている内容が示唆するよりも狭く、出来事の順序を述べる前に率直に記しておく価値がある。ここにある具体的な事実はすべてGrigorevに由来する。AI Incident Databaseにはこのインシデントに関する報告が2件掲載されている。彼のSubstack投稿「How I Dropped Our Production Database and Now Pay 10% More for AWS」と、Bruno Ferreiraによる2026年3月7日のTom's Hardwareの記事であり、後者は前者の要約だ。インシデント管理企業Rootlyが公開したインタビューは、Grigorev本人の言葉で詳細を補っている。Anthropicからの声明も、AWSからの声明も、この出来事に関する規制当局の認定も公表されていない。何が削除されたかについては、すべての説明が一致している。流通した話が彼の実際の記述からずれている箇所については、本記事でどれがどれかを明示する。

それを可能にした2つの決断

移行はありふれた作業だった。グリゴレフはAI Shipping LabsのサイトをGitHub PagesからAWSへ移し、その後Djangoで書き直すことを望んでいた。2つ目の環境を構築する代わりに、彼はそのサイトを、DataTalks.ClubのZoomcampコースを支えるコースプラットフォームをすでに管理しているTerraform設定に加えた。そのシステムは、2.5年分にさかのぼる提出物、宿題、プロジェクト、リーダーボードのエントリーを保持していた。彼の投稿では、節約額を月5〜10ドルと見積もり、エージェントがその取り決めに反対したことを記している。「Claudeは私を説得してやめさせようとしていて、分けておくべきだと言っていた」。それでも彼は、別のVPCは望まなかったため、すべてを既存のVPCに入れるよう指示した。

2つ目の判断は、より静かなものだった。Terraformのstateファイルは、すでに存在するものを記録する台帳だ。Grigorevは最近新しいコンピューターに移ったが、そのファイルを移行していなかった。そのため、2月26日の午後10時ごろにデプロイが始まったとき、planはアカウントが空だと想定し、インフラの複製を作り始めた。彼は作成されていくリソースの長い一覧を見て、applyを停止し、なぜそうなるのかを尋ねた。彼の話では、エージェントの答えは、Terraformが何も存在しないと信じていた、というものだった。

破壊

続いて起きたのは、後片付けのはずがインシデントへと変わってしまったことだった。グリゴレフはエージェントに、AWS CLI を通じて、どのリソースが新たに作成された重複で、どれが本番環境のものかを判別させ、新しいものだけを削除するよう指示した。それが実行されている間に、彼は古いマシンへ戻り、state ファイルを含む Terraform フォルダーをアーカイブして、そのアーカイブをコピーして移し、2 組のリソースを比較できるようにエージェントへそれを指定した。彼の説明によれば、エージェントがアーカイブを展開したことにも、中にあった古い方の state ファイル——本番リソースを記述したもの——で現在使用中の state ファイルを置き換えたことにも気づかなかった。

その状態が存在する中で、エージェントの次の提案は自らの論理に従った。投稿の中でグリゴリエフはそれをこう引用している。「それはできません。terraform destroy を実行します。リソースは Terraform を通じて作成されたため、Terraform を通じて破棄する方が AWS CLI を通じるよりクリーンで簡単です。」彼は同意し、Rootly にこう伝えた。「はい、Claude が terraform destroy を実行し、私はそれを見ましたが止めませんでした。」彼は状態の入れ替えについても、「状態が入れ替えられたことに気づいていませんでした」と述べている。コマンドは午後11時ごろに auto-approve 付きで実行されたため、二度目の確認を求めて中断されることはなかった。

2つの証言は、エージェントの提案を異なる形で伝えている——Rootlyのインタビューでは「これらを1つずつ削除するのは退屈だ。terraform destroy を実行するだけにしたらどうか？」となっている——が、どちらも同じ構図を描いている。破壊が片付けとして提示され、重複だけが対象だと考えた運用担当者がそれを実行させてしまった、という構図だ。この失敗のメカニズムは、エージェントがコマンドを誤解したことではない。エージェントが本番環境を記述した状態ファイルから正しく推論しており、その運用担当者にはそのファイルが変わったことを確認する手段がなかったことにある。

何が破壊されましたか

エージェントが現在参照していた状態ファイルには本番環境が記述されていたため、destroy は本番環境の削除を計画しました。Grigorev は何が失われたかを列挙しています：

• 環境全体を収容していた VPC。

• アプリケーションを実行しているECSクラスター。

• その手前にあるロードバランサー。

• プライベートネットワークにアクセスするために使用される踏み台ホスト。

• コースプラットフォームのデータを保持するAmazon RDSデータベース。

• 上記のすべてを復元可能にするはずだった自動RDSスナップショット。

最後の項目こそ、障害をデータ損失の恐怖に変えたものだ。RootlyのインタビューでGrigorevが説明しているのは、AWS上でマネージドデータベースを削除すると、関連する自動バックアップも削除されるということだ。投稿の中では、AWSサポートが彼に対し、彼のデータベースとすべてのスナップショットが削除されており、「APIリクエストはAWSにすべてを削除するよう明確に指示していた」と確認した。削除がどのように伝播したにせよ、午後11時に重要だったのはその影響だった。彼が頼りにしていたコピーは、元のデータと同じ操作によって削除されたのだ。

24時間リカバリー

最初の問題は、バックアップが消えたように見えることでした。二つ目の問題は、そのうちの一つは消えていなかったことです。グリゴレフは、毎晩午前2時にスナップショットが取得されていることを知っていました。RDSコンソールには一つも見つかりませんでしたが、RDSイベント一覧にはバックアップが作成されたことが依然として表示されていました。それをクリックして開こうとしても、何も開きませんでした。そのスナップショットが削除されたのか、それとも単に見えなくなっただけなのか、彼には判断できませんでした。

彼は真夜中ごろにサポートチケットを開き、本番インシデントに対する1時間以内の応答保証に気づいた後、アカウントを AWS Business Support にアップグレードした。このアップグレードにより AWS の請求額がおよそ10パーセント増え、彼の投稿のタイトルはそこから来ている。サポートは約40分で返信し、削除を確認すると、AWS 側にはスナップショットが存在するが彼のコンソールでは見えないと伝えた。その後40～60分の通話があり、社内チームにエスカレーションされた。データベースが削除されてからちょうど24時間後、AWS はスナップショットを復元し、それが彼のコンソールに現れた。彼は Terraform を使ってそこからインスタンスを再構築した。待っている間に、彼は周辺インフラを再構築し、複数のロードバランサーを1つに統合していた。

復元されたデータベースのcourses_answerテーブルには1,943,200行が含まれていた。彼はこれを、復元が完全だったことの確認として挙げている。この数字は損失の規模としてしばしば繰り返される。それは1つのテーブルの行数であり、データが戻った証拠として使われているものであって、データベース全体の合計ではなく、影響を受けた学生の人数でもない。その人数はどの資料にも示されていない。

なかった警告

いくつかの再話には、Claude が事前にグリゴリエフへ警告したが無視された、という一節がある。資料が裏づける内容はより狭く、その違いによって、この事例が何の例なのかが変わる。エージェントは実際に、破壊が起きる前に共有 Terraform 構成に反対する議論を述べており、その助言は却下された。グリゴリエフのどちらの説明も、エージェントが destroy が本番環境に到達すると警告したとは述べていない。彼はステートファイルがすり替えられていたことを知らなかったと述べており、どちらの説明でもエージェントの提案は、リスクを指摘して放棄されたものではなく、片付けとして提示されている。無視された警告は、コマンドについてではなく、移行のより早い段階でのアーキテクチャについてのものだった。

その区別は、二つの異なる失敗を分ける。危険を認識しながら覆されたエージェントは、人間の判断についてのガバナンス上の話である。世界を記述するファイルがその下で変わったために、危険が存在することを知らないエージェントは、状態、権限、承認ゲートについてのツーリング上の話である。Grigorevの説明は後者であり、アーカイブ自身の分類もそれを反映している。その記録には、運用者の意図から逸脱したエージェント行動に対するアーカイブのROGUEタグが付いており、その下にあるAI Incident Databaseのエントリは、意図を意図的でないものとして、MITタクソノミー7.3「能力または堅牢性の欠如」の下で、AIシステムの安全性、失敗および限界というリスク領域において、展開後段階にあると分類している。データベースは、そのエンティティ一覧の先頭に「alleged」を付けている。これは、いかなる権限ある機関も裁定していない自己申告事例に対する標準的な位置づけである。

責任はどこに帰着したのか

グリゴレフはそれを配布していない。「このインシデントは私の過ちだった」と彼は書き、三つの原因を挙げている。plan、apply、destroyを委任可能なものとして扱ったこと。テスト復元したことのないバックアップを信頼していたこと。そして、データベースが削除しやすすぎたことだ。彼は、AWSを待つ間、データが永久に失われた可能性を考慮しなければならなかったと述べている。当時最終モジュールを進めていたData Engineeringコースについては、すでに復旧を計画しており、より古いコースについては、復元に失敗すればそれで終わりだっただろう。

Tom's Hardwareによる評価は、彼の投稿の翌日に公開され、本質的に同じだ。「誤りは不適切な監督に起因すると考えられる」。その批判は彼のものよりさらに踏み込み、エージェントに付与された広範な資格情報と、本番環境向けに権限を絞り込まれることのなかった権限を指摘している。規制当局、標準化団体、ベンダーのいずれも立場を表明していない。ここにはCVEも、脆弱性の開示も、モデルのジェイルブレイクもない。エージェントはだまされたのではなく、過度に信頼されていたのだ。

その後、何が変わりましたか？

Grigorev は、AWS がまだ復元作業を進めている間にこれらの安全策を実装し、リストとして公開した。以下は彼自身の言葉と順序による：

• Terraform が管理していないバックアップに加え、データベースやインフラストラクチャの状態とは別に保存される S3 ベースのコピー。

• 毎晩のリストアテスト：午前2時の自動バックアップを午前3時ごろに使用して新しいデータベースインスタンスを構築する。これには20～30分かかり、その後、Step FunctionsでオーケストレーションされたLambdaが簡単な読み取りクエリで使用可能かどうかを確認し、インスタンスは削除ではなく停止される。前日のコピーは削除されるため、直近のレプリカが常に1つ利用可能である。

• 削除保護をTerraform設定とAWS自体の2つのレベルで行う。彼は、これらは明示的に無効化すれば誰でも削除できるものの、手間が増えると指摘している。

• S3バックアップのバージョニング。削除しても以前のバージョンが残るため、バケットを空にするには先に中身を削除する必要があります。

• Terraform のステートを S3 に移したことで、それを始めた状況が解消された——ステートファイルが 1 台のラップトップにしか存在せず、彼がマシンを変えたときに消えてしまっていたからだ。

• エージェントはTerraformを一切実行しなくなりました。「すべての権限が無効化されています。自動実行はありません。ファイルの書き込みもありません」と彼は述べています。現在のワークフローは、プランを生成し、手動でレビューし、コマンドを自分で実行するというものです。新しいプロジェクトには、独自の別個のTerraform設定も用意されました。

すべての推奨事項が採用されたわけではない。{{1}}Rootly{{/1}}のインタビューで彼は、単一の{{2}}AWS{{/2}}アカウントを維持したと述べ、開発用と本番用のアカウントを分けることや、{{3}}Atlantis{{/3}}のような承認パイプラインは、一人で運用するには過剰だと判断した。それが事後対応の正直な姿だ。修正は実際に行われており、それは一人でも維持できる修正なのだ。

この記録が何であり、何でないか

これは文書化された自己申告の運用インシデントであり、実際の金銭的損害と可用性への損害を伴っている。そして、それが起きた本人が自身の誤りだった部分も含めて一連の経緯をすべて書き留めているため、異例なほど読み解きやすい。これはモデルが独自の目標を追求した証拠ではなく、アーカイブのROGUEタグは、エージェント側のいかなる意図ではなく、エージェントの行動とその運用者の意図との間の乖離を記述したものとして読むべきである。

持ち帰る価値があるのは、データを救ったその詳細だ。グリゴリエフ自身のバックアップは、それが保護していたデータベースとともに削除されており、夜間スナップショットは、イベントログが存在を主張し続けていたにもかかわらず、彼には見えなかった。2.5年分のコースワークを復元したのは、AWS側に保持されていたコピーで、彼が存在を知らず、テストすることもできなかったものだった。復元したことのないバックアップは信念であって、統制ではない——そして今回、その信念がたまたま真だったのは、誰か別の人が2つ目のコピーを保持していたからにすぎない。