AIが警告していたのに本番データベースが消えた理由

AIに本番インフラの移行作業を任せた際、Terraformのstateファイルを誤って渡したことで、AIが本番環境全体を削除対象と判断しました。VPCやRDS、2.5年分のデータが消え、AWSサポートの非公開スナップショットから約24時間後に復元できました。AIは冒頭で「統合すべきでない」と警告していましたが、ユーザーが退けて作業を続行しています。根本原因は削除保護の未設定、stateのローカル管理、AIへの破壊的コマンドの無制限委譲が重なった点です。

1. AIエージェントにインフラ移行を任せたら……

2026年2月26日の夜、Alexey GrigorevはサイドプロジェクトのインフラをAWSへ移行する作業をClaude Codeに任せていました。ツールはTerraform。コストを節約するため、既存の本番インフラと同じVPCに新サイトを同居させる構成を選びました。¹

ここで最初のミスが出ます。新しいPCへ移行した際、Terraformのstateファイルを持ち込んでいませんでした。stateファイルとは、Terraformが「現在どのインフラが存在するか」を把握するための台帳です。これがないと、Terraformは本番環境の存在を知らないまま動きます。²

terraform planを実行すると、案の定「すべて新規作成する」という計画が出力されました。Grigorevはキャンセルし、Claude Codeに重複リソースの削除を指示。その後、stateファイルをアップロードしました。

1.1. 全データが消え非公開スナップショットから復元した

ここが致命的な分岐点でした。stateファイルを受け取ったClaude Codeは、それを「現実の正解」として扱い、現状をstateに合わせるためにterraform destroyを実行しました。terraform destroyはTerraformが管理するリソースをすべて破棄するコマンドです。stateファイルには本番インフラ全体が記述されていました。

VPC、RDS、ECSクラスター、ロードバランサーが消えました。2.5年分の受講者データも消えました。スナップショットもTerraform管理下にあったため、一緒に消えています。³

結果として、AWSサポートがバックエンドに保持していた非公開スナップショットから約24時間後に復元できました。194万3200行のデータが戻っています。⁴

2. なぜこうなったか

この事件で見落とされがちな事実があります。

Claude Code自身が作業の冒頭で「インフラを統合すべきでない」と警告していました。
Grigorevはその提言を退けて続行しています。⁵

AIが暴走したのではありません。
AIは与えられた情報に沿って、筋の通った判断をしました。
「stateファイルが正解→現実をstateに合わせる→destroyを使う」。

この論理は一貫しています。
問題は、その論理の射程が本番インフラ全体に及ぶことを、Grigorevが把握していなかった点です。

Grigorev自身もポストモーテムでこう書いています。
「plan、apply、destroyを委譲できるものとして扱い、それが最後の安全層を取り除いた」と。

根本原因はひとつではなく、複数の条件が重なっています。

stateファイルがローカルマシンに置かれており、PC移行時に同期されなかった
本番データベースに削除保護が設定されていなかった
スナップショットがTerraform管理下にあり、destroyの対象に含まれていた
AIの実行に手動承認ゲートがなく、terraform destroyが自動で走った
本番と開発が同じインフラに同居していた

どれかひとつでも塞がれていれば、被害は止まっていました。

2.1. terraform destroyは禁忌ではない

terraform destroyは「危険だから使ってはいけない」コマンドではありません。
テスト環境の後片付けや移行元インフラの一括削除など、目的が明確な場面では必要なコマンドです。

問題は、破壊的なコマンドをAIが自律的に実行できる状態に置いたことです。
人間なら「いまは本番だから止めるべき」という判断が働く場面でも、AIにはその文脈がありません。
与えられた権限と情報の範囲で、最短の手順を選びます。

3. 対策として何をするか

Grigorevが事後に実装した変更は参考になります。

削除保護の有効化。
TerraformとAWSの両レベルで設定します。
有効にすると、削除前に明示的に保護を外す操作が必要になり、誤操作を防ぐ摩擦が生まれます。⁶
stateファイルをS3へ移動。
ローカルに置くと、PC移行やチーム作業でstateが食い違う状態が起きます。
S3に置いてバージョニングを有効にすることで、複数環境から一貫した状態を参照できます。⁷
バックアップの復元テストを自動化。
Lambdaが毎朝バックアップからDBを復元し、Step Functionsで検証クエリを実行します。「バックアップが存在する」と「バックアップから復元できる」は別のことです。
本番と開発をアカウントレベルで分離。
同じインフラに同居させると、片方への操作がもう片方に波及するリスクが残ります。
AIの自動実行を無効化。
terraform planまではAIに任せ、applyとdestroyは人間が実行する。この分割が今回失われていた安全層でした。

3.1. 委譲の設計を先に決める

AIに任せる範囲を決めないまま速度だけを上げると、普段は見えない運用の弱点が一度に露出します。

実務上の出発点として有効なのは、クラウドへの認証接続、CLIの実行、接続の切断という流れを人間の手順として固定することです。
接続を切らずに作業を終えると、AIが到達できる範囲が広がったままになります。

「どこまでAIに委ねるか」の答えはまだ定まっていません。
ただ、答えが出るまで待つ必要はありません。先に境界線を引いて運用し、運用しながら線を見直す。
委譲する領域を決めたら、委譲しない領域も同じ重さで明文化する。
それが現時点で取れる最も手堅い構えです。

GrigorevはDataTalks.Clubというデータエンジニアリング学習プラットフォームの創設者で、10万人以上の受講者にデータエンジニアリングやMLOpsを無料で提供しています。 – How I Dropped Our Production Database and Now Pay 10% More for AWS
stateファイルはデフォルトでプロジェクトのローカルディレクトリに保存されます。PCを移行したとき、このファイルを新しいマシンにコピーしなければ、Terraformは既存インフラの存在を認識できなくなります。 – How to Use S3 as a Terraform State Backend
RDSのTerraformリソースにskip_final_snapshotをtrueに設定したまま（またはデフォルト値のまま）destroyを実行すると、最終スナップショットなしにインスタンスが削除されます。自動バックアップもインスタンスとともに削除されるのがAWSの仕様です。 – prevent deletion of my rds instance created by modules
AWSはRDSの自動スナップショットを、コンソールから見えない状態でも短期間バックエンドに保持することがあります。Grigorevの場合、Business Supportに加入していたことで迅速な対応が得られました。Business Supportは月額費用がベースチャージの10%増しになります。 – Claude Code Wipes Production Database in Terraform Mishap
GrigorevはこのインシデントをClaude CodeのGitHubリポジトリにissue #14411として起票しています。彼はAIを責めるためではなく、他の開発者への注意喚起と改善提案を目的として公開したと述べています。 – Claude Code decided to delete my production database – GitHub Issue #14411
TerraformのRDSリソースにはdeletion_protection属性があり、trueに設定するとTerraformからの削除もエラーになります。ただしTerraformのlifecycle { prevent_destroy = true }には注意点があり、リソースブロックをコードから削除した場合は機能しません。AWS側の削除保護と組み合わせることが推奨されます。 – Strategies to Prevent Accidental Terraform Deletions
S3バックエンドはDynamoDBと組み合わせてstate lockingを設定するのが標準的な構成です。複数人が同時にterraform applyを実行したとき、stateの競合や破損を防げます。AWSの公式ガイドラインでも、S3はイレブンナイン（99.999999999%）の耐久性を持つリモートバックエンドとして推奨されています。 – Backend best practices – AWS Prescriptive Guidance