Claude Codeでコーポレートサイトの本番DBを吹き飛ばした話

こんにちは、HRdevの永井です。

HRdevのコーポレートサイトはClaudeCodeで制作、運用をしているのですが、悲劇が起きました・・・。

2026年4月18日の朝、Claude Codeをauto modeで動かして管理画面の改修をしていた裏で、自社のコーポレートサイト（hrdev.jp）のブログ記事DBが全件消えました。

原因は古典的なものでしたが、AIのauto modeを業務に組み込んでいる方、特に本番DBの管理をAIに任せきってしまったプロジェクトを持っている方に、同じ事故を起こしてほしくないので記事化しました。笑ってやって下さい。

何が起きたのか

本番DBに保存しておいた公開中のものを含む記事22件と編集履歴が全消失しました・・。

気づいたのは土曜日の昼。別の作業で管理画面を開いたら、ブログの表示件数が0件。リカバリーを試みるも、残念ながら完全なものには至りませんでした。

なぜ prisma migrate dev が本番データを吹き飛ばしたのか

当初、データを初期化するようなコマンドの実行痕跡がありませんでした。「痕跡なく消えた」のが一番の恐怖でしたが、インフラ構成を洗い直す過程で、構造から犯人が見えてきました。prisma migrate dev です。

内部ではshadow DB（作業用の仮DB的なもの）を作成し、接続先DBのテーブルをテーブルごと削除したり再作成する挙動があります。それが原因となって、データを丸ごと吹き飛ばしました。

接続先が本番DBだと、4で本番データが消えます。shadow DB相手だけで作業してくれるわけではなく、接続先にも直接手が入るためです。ドキュメントには「開発環境専用」と書かれていますが、本番DBに向いた .env.local を読み込んだ状態でうっかり実行すれば同じことが起きます。

自分のClaude Codeセッションで、スキーマ変更の検証中にAIが prisma migrate dev を提案して走った可能性が最も高いと判断しています。この時点での .env.local のDATABASE_URLは本番Neon mainを指していました。つまり、「ローカル開発環境だと思って開発コマンドを打ったら、接続先は本番だった」という古典的な構成ミスに、AIがauto modeの最高速で乗ってしまった形です。

事故前データは復旧できたのか

6つの復旧経路を検証して、全てダメでした。可能性を一つずつ潰した結果がこれです。

根因はどこにあったのか

構造的な弱点が3つ重なっていました。

1つ目は本番DB直結、2つ目は履歴テーブルの設計、3つ目は保持期間の短さです。

1. ローカルdev環境が本番DB直結

コーポレートサイトの .env.local のDATABASE_URLが、本番のNeon mainブランチを直接指していました。dev branchの分離は未実施。Claude Codeのauto modeが何らかのDB操作をした瞬間に本番が壊れる設計になっていました。

2. 編集履歴のテーブルが本体と共に消える

履歴テーブルは「事故時の保険」のはずが、記事テーブルとセットで削除されるような形で繋がっていました。事故の瞬間に保険も一緒に消える。履歴の意味をなしていません。

3. Neon Free tierの保持期間が6時間

利用していたDBサービスにはデータ保持の機能が有ったのですが、プランの関係で気づいた時点で保持時間の外でした。

事故は気づくまでに時間がかかるし、気づいてからも調査時間が要る。6時間は短すぎました。お客様がいるサービスでこんな設定になってなくて本当に良かったです。

AIに任せる時代のDBで、最低限押さえておくべき制御

仕組みを作る前に、そもそも何を知っておくべきだったかを最初に整理します。

制御1: ローカル・開発・本番は物理的に別DBと認識する

「ローカル」「開発（staging / preview）」「本番」は、単に環境変数を切り替えるだけの関係ではなく、物理的に別のデータベースを指している状態でなければなりません。（当たり前）

事故前のコーポレートサイトは、この3つが全て同じNeon mainを対象としていました。

ローカルで何か試すと本番が動く、ということです。prisma migrate dev をAIが打って本番が吹き飛んだのは当然の結果でした。

スプレッドシートの同じファイル内にバックアップ用のシートを作るような設計ではデータは守れません。

制御2. バックアップは多層 + オフサイト + 作業前スナップショット

「1回取ればOK」ではなく、異なるタイミングで多層的に、ローカルとオフサイトの二方向に持つようにしました。ローカルバックアップだけだとPC故障・盗難でまとめて飛ぶ構成はそもそもハイリスクなので、これを排除します。

制御3. AIに「何をさせるか」と「何が起きたら気づくか」を、別レイヤーで制御する

AIのauto modeに全権限を渡すと、開発用に見える破壊的コマンド（prisma migrate dev・prisma db push など）を、AI自身の判断で高速に実行してしまいます。そのため、それぞれのレイヤーごとで制御を実施するべきでした。

ログ見ると「〜〜でダメだったので＝＝でやります。できました！」といったブロックすり抜けのコメントも多く、仕組みの設計の重要さを本当に感じます。

どんな防御線を引き直したのか

6つの防御線を、その日のうちに4つ、翌日以降に2つ、Claude Codeと一緒に組み直しました。

A. destructive-guard hook（pre-dump付き自動ブロック）

Claude CodeのPreToolUse hookで、Bashコマンドを毎回チェックする仕組みを入れてもらいました。今回の犯人 prisma migrate dev を筆頭に、危険操作を全部検知します。

B. 日次ローカルバックアップ

macOSのlaunchdで毎朝定刻に自動発火するpg_dumpを仕込みました。Neonの保持期間に頼らず、自分の手元に30日分のスナップショットを持つ形を取っています。

C. プロジェクト内backup script

投稿 / 編集履歴など記事情報だけをpg_dumpするスクリプトを置きました。「DB影響操作をする前は必ず実行する」をルール化し、Claude Code側のmemoryにも書き込みました。

D. memoryとルールへの追記

仕組みだけでなく、AIの判断軸にも手を入れました。memoryにauto modeでの本番DB destructive操作禁止を書き込み、Claude Codeのrulesに「prisma migrate dev を本番DB接続状態で実行禁止」を名指しで追加しています。今後もこういうのは増えそうなので、対策をしっかりしておこうと思っています。

E. Neon devブランチ分離とpromote-articleワークフロー

Neonでdevブランチを切り、ローカルの .env.local の接続先をdevブランチに切り替えました。本番Neon mainに手を入れられるのは、Vercel Production deployと、明示的なコマンドだけにしました。

ローカルファイルはdev DBの投入口と、本番のバックアップ出口を兼ねます。DBが正本でありつつ、ローカル↔DB が双方向に流れる構造に直しました。

F. オフサイトバックアップ（Google Drive同期）+ 異常検知（Detection）

ローカル一極集中を解消するために、Google Drive同期フォルダへの二重保存を足しました。

日次pg_dumpを取得した直後に、同じファイルをGoogle Drive側にもコピーします。OS故障や盗難でも片方が残る構造です。

同時に、全対象DBのテーブル行数を定期監視するヘルスチェックも仕込みました。

今回と同じ事故がまた起きたら、昼まで気づかずに済むのではなく、数十分で手元に通知が届く構造になりました。事故前は完全に検知する仕組みがなかったことの反省から追加しました。

この事故から何を学んだか

開発用コマンドで知るべきものを知ること、AI auto mode前提で本番DB運用の基準を引き上げること、そして仕組みを作る前にまず知識として環境分離・多層バックアップ・Detection・AI制御を押さえることです。

この前提で本番DB運用を見直すと、従来の感覚と大きく変える必要があります。

再発防止は、事前の技術的ブロック、事中の異常検知、事後の復旧可能性、そしてそれを取り巻く通知体制の4層で組む必要があります。どれか1つでも欠けると、今回と同じ構造の事故を次も食らいます。

最後に「まだ整えていない」を最優先タスクに

AIを利活用した採用支援に取り組む自分が、足元の開発でこれを食らいました。

ローカルdev環境が本番DBと直結していて、AIを auto modeが様々なコマンドを走らせている。気づかない間に、事故の種は育っているかもしれません・・・。

「うちは大丈夫」と思っている経営者・ビジネスサイドでゴリゴリとAIを使われている方にこそ、今日中に以下を確認することをお勧めします。

• 本番DBへの接続情報が .env.local や .env に直に入っていないか

• ローカル・開発・本番が物理的に別DBに分離されているか

• バックアップが複数の期間＋ローカル/オフサイトで多層化されているか

• バックアップ・履歴が本体と密結合してる設計になっていないか

• DBの行数急減などを自動検知する仕組みがあるか

• AIが強いコマンドを打てる状態のままになっていないか

• AIに「何をさせるか・させないか」の明示的なルールが設計できているか

痛みを伴う経験こそが、その先の自分を守るような価値のある体験になるということはよくあることだと思っています。この学びを活かして、今後の開発・制作に活かしていけたらと思います。

また、同じ立場の方へ、少しでも参考になれば幸いです。