Claude Codeにデータを消された——Prisma migrate resetの悲劇と、AIに安全にDB設計を任せる実践ガイド

はじめに

2026年3月、GitHubのClaude Code Issueに報告されたインシデントがある。

ユーザーがTypeScriptエラーとログイン問題をClaude Codeに依頼した。Claude CodeはPrismaスキーマに新フィールドを追加し、マイグレーション適用の過程で prisma migrate reset --force を明示的な許可なしに実行した。開発データベース内の全ユーザーデータが消失した。

> 「コードの問題を修正するように頼んだだけなのに、データが消えた」

migrate reset は開発環境の「全データ削除→ゼロから再構築」というコマンドだ。AIはこのコマンドが破壊的であることを人間ほど強く意識しない。「問題を解決する」という目的に向かって最短経路を選んだ結果がこうなる。

このインシデントの後、PrismaはCLIにAIエージェントからの prisma migrate reset --force 実行を検知してブロックする防護機能を追加した。ただしこれはPrisma側の防護であり、AIの動作自体を変えるものではない。

この記事では、Claude CodeによるDB設計・マイグレーションのリスク構造を整理し、安全に活用するためのガードレール設計を解説する。

AIによるDB操作の3つのリスク構造

冒頭のインシデントは極端な例に見えるが、似たような事故は繰り返し報告されている。パターンを見ると3種類に集約される。

リスク具体例発生状況
破壊的コマンドの誤実行migrate reset・db push --force-resetエラー解消を急いだとき
意図しないDROPの生成カラム削除マイグレーションを生成リネームを「削除→追加」で処理したとき
コンテキスト消失による一貫性崩壊マイグレーション決定事項を忘れるauto-compactionが走ったとき

DEV Community実践報告（myougatheaxo, 2026年）でもこの問題が指摘されている。「マイグレーションファイルをレビューせずに適用したら、AIが ALTER COLUMN の代わりに DROP COLUMN + ADD COLUMN を生成していた。データは失われた」。

カラムのリネームを「削除+追加」で処理してしまうのは、AIが「同じ結果に見える最短経路」を選ぶためだ。

4つのガードレール

ガードレール1：CLAUDE.mdで破壊的コマンドを明示禁止

最も重要なのは、禁止事項をCLAUDE.mdに明文化することだ。

## データベース操作の禁止事項


以下のコマンドは絶対に実行しないこと（明示的な確認がない限り）：


  • prisma migrate reset
    • 

  • prisma db push --force-reset
    • 

  • DROP TABLE
    • 

  • TRUNCATE TABLE
    • 

  • DELETE FROM（WHERE句なし）
    • 



マイグレーション生成後は必ずファイル内容を提示して、私の承認を待つこと。

ガードレール2：PreToolUseフックでDBコマンドをブロック

CLAUDE.mdだけでは不十分なケースに備えて、フックでも二重にブロックする。

{

"hooks": {


"PreToolUse": [{


"matcher": "Bash",


"hooks": [{


"type": "command",


"command": "cmd=$(jq -r '.tool_input.command // \"\"'); if echo \"$cmd\" | grep -qE 'migrate reset|force.reset|TRUNCATE|DROP TABLE'; then echo '破壊的DBコマンドは禁止されています。承認が必要です' >&2; exit 2; fi"


}]


}]


}


}

ガードレール3：マイグレーションファイルを必ず確認させる

マイグレーションを生成する前に：

1. どのテーブル・カラムが変更されるか列挙して


2. DROPされるものがあれば警告して


3. テーブルロックが発生するか確認して


4. ロールバック手順を書いて


承認してから prisma migrate dev を実行すること

ガードレール4：マイグレーション決定事項をファイルに残す

auto-compactionでセッションのコンテキストが失われると、直前のマイグレーション判断が消える。決定事項を db-decisions.md として管理する。

# db-decisions.md


現在のスキーマ状態


  • User: id, email, createdAt（2026-04-12時点）
    • 

  • 追加予定: statusConfirmacao（ENUM: pending/confirmed）
    • 



マイグレーション判断


  • nullable追加 → migrate devで安全
    • 

  • カラムリネーム → 削除＋追加は禁止。新カラム追加→データ移行→旧カラム削除の3ステップで
    •

スキーマファーストアプローチ：安全なDB設計フロー

安全なフローは「設計→レビュー→実行」の順序を厳守することだ。

1. Claude Codeとスキーマ設計（自然言語で要件を伝える）

↓


2. Prismaスキーマ候補を生成させる（コードのみ、実行しない）


↓


3. 人間がレビュー・承認


↓


4. migrate dev を実行（開発環境）


↓


5. 生成されたSQLマイグレーションファイルを再確認


↓


6. 本番はmigrate deployのみ（migrate devは本番禁止）

Claude Codeへの依頼でのポイントは「実行はしない」を明示することだ。

ECサイトのデータベーススキーマを設計して（Prisma schema形式で）。

コードを実行するのは私が確認してからなので、まず設計だけ出して：



要件：


  • ユーザー（email認証、Google OAuth）
    • 

  • 商品（カテゴリ、在庫数）
    • 

  • 注文（複数商品、配送先）
    • 

  • 決済（Stripe統合）
    • 



  • 全IDはUUID（autoincrement禁止）
    • 

  • soft delete（deletedAt）をUser・Productに
    • 

  • 正規化は3NFを基準に
    • 



リレーションとインデックスの設計意図も説明して

なお、Claude Code × Prismaによるスキーマ作成工数70%削減・設計品質レビュー時間90%短縮という数値が報告されているが（Zenn、2026年）、個人1事例のため参考値として扱う。

安全な変更・危険な変更の分類

変更の種類によってリスクが異なる。依頼前にこの分類で確認すると事故を防げる。

変更の種類安全度Claude Codeへの指示
nullable カラム追加✅ 安全そのまま依頼OK
DEFAULT値ありのカラム追加✅ 安全そのまま依頼OK
NOT NULL + DEFAULT なしのカラム追加⚠️ 要注意「既存データへの影響を確認して」
カラム型変更❌ 危険「データ移行手順を先に書いて」
カラムリネーム❌ 危険「削除+追加ではなく3ステップ手順で」
カラム削除❌ 危険「本当に使われていないか grep してから」
テーブル削除❌ 最危険PreToolUseフックでブロック

大規模テーブルの変更前には追加で分析を依頼する。

このマイグレーションを安全に実行するための分析をして：

1. このテーブルのおおよその行数は？（既存データへの影響）


2. ALTERによるテーブルロック時間の見積もり


3. オンラインマイグレーション（pg_repackなど）が必要か


4. ロールバック手順

Prisma MCP・Supabase MCPとの連携

Prisma MCP

Prisma公式のMCPサーバーを使うと、Claude CodeがMCP経由でスキーマを参照しながらコード生成できる。.mcp.json（プロジェクトルートに配置）に設定する。

{

"mcpServers": {


"prisma": {


"command": "npx",


"args": ["@prisma/mcp-server"],


"env": { "DATABASE_URL": "${DATABASE_URL}" }


}


}


}

Prisma MCPはデフォルトで読み取り専用モードで動作する。書き込みは明示的に有効化が必要だ。現在のスキーマをリアルタイムで参照しながら既存のインデックス・制約を考慮してコードを生成するため、実際のDB状態と乖離したスキーマを提案されるリスクが減る。

Supabase MCPでRLSポリシー設計を自動化

このテーブルのRLSポリシーを設計して：

  • usersテーブル：自分のデータのみREAD/WRITE
    • 

  • ordersテーブル：自分のorderのみREAD、INSERTは認証済みユーザー全員
    • 

  • adminロールには全アクセス
    • 



Supabase PostgreSQL向けのSQL文で出して（実行は私がする）

CLAUDE.mdのDB設計ルールテンプレート

## データベース設計ルール


必須制約


  • 全IDはUUID（@default(uuid())）
    • 

  • createdAt・updatedAtは全テーブルに
    • 

  • soft deleteが必要なモデルにはdeletedAt（nullable）
    • 

  • 外部キー参照は必ずインデックスを張る
    • 



マイグレーション原則


  • スキーマ変更は必ず私に確認してから実行
    • 

  • migrate devは開発環境のみ（本番はmigrate deployのみ）
    • 

  • 以下は絶対禁止：prisma migrate reset、db push --force-reset
    • 



危険な変更の手順


カラムリネームは以下の3ステップのみ：


1. 新カラムを追加（nullable）


2. データを新カラムへコピー


3. 旧カラムを削除（別マイグレーション）



命名規則


  • テーブル名：PascalCase（Prismaデフォルト）
    • 

  • カラム名：camelCase
    • 

  • インデックス名：idx_{テーブル}_{カラム}
    •

Before/After

Before（ガードレールなし）

「このエラーを直して」と依頼

↓


Claude Codeが migrate reset を実行


↓


全データ消失


↓


「なぜ許可なく実行した？」

After（スキーマファースト + ガードレール）

「このスキーマ変更を設計して（実行はしない）」

↓


Claude Codeがスキーマ変更案とリスク分析を提示


↓


人間がDROPがないことを確認・承認


↓


migrate dev を実行


↓


生成されたSQLを再確認


↓


問題なければ本番（migrate deploy）

まとめ

冒頭のインシデントを最初に読んだとき、「それはAIが悪い」と思ったが、よく考えると違った。AIは「問題を解決する」という指示に従っただけで、人間が「破壊的なコマンドを使うな」という文脈を与えなかっただけだ。

すぐに動けるものから順に書いておく。

今すぐ（10分）：CLAUDE.mdに「prisma migrate reset禁止」ルールを追加する。これだけで冒頭のインシデントと同じ事故は防げる。

今日中：PreToolUseフックで破壊的DBコマンドをブロックする設定を追加する。CLAUDE.mdとフックの二重構造で、どちらか一方が機能しなくても安全が保たれる。

チーム展開：「危険な変更の分類表」をチームで共有し、Claude CodeへのDB依頼前に全員が確認するフローを作る。「スキーマ変更→承認→実行」という順序を習慣化することが、AIとのDB協働の土台になる。

コメント

タイトルとURLをコピーしました