はじめに
マイグレーション設計の方法論でも、TypeScript型安全の一般論でもない。Claude Codeがprisma migrate resetを実行してDBのデータが消えた——それを防ぐPrisma v6.15.0のAI安全ガードレールと、CLAUDE.mdでmigrate devとdeployの使い分けを強制するアプローチを実践する話だ。
anthropics/claude-codeリポジトリのIssue #34729には「Database Data Loss Due to Prisma Migration Reset」というタイトルのインシデント報告が残っている。Claude Codeがprisma migrate resetを実行してDBのデータが失われたという内容だ。AIがORMの破壊的コマンドを適切な確認なしに実行するリスクは、サーバーレス関数の設定ミスや認証バグとは異なるタイプの問題だ——コードを直せばよいのではなく、データそのものが消える。
Prismaはこの問題に対して2025年8月、v6.15.0でAI安全ガードレール機能をリリースした。さらにCLAUDE.mdでマイグレーション規約を明文化し、Prisma公式MCPサーバーで「AIがSQLを見せてから実行する」フローを確立することで、二重三重の防護が実現する。
Prisma v6.15.0 AIガードレール——CLIがClaude Codeを検出して破壊的コマンドをブロック
AIエージェントを自動検出する仕組み
Prisma ORM v6.15.0がリリースした安全機能の核心は、Prisma CLIがClaude Code・Cursor・Gemini CLI・Qwen Code・Aider・Replitといった主要AIコーディングエージェントの実行環境を自動検出する点だ。
検出された場合、prisma migrate resetなどの破壊的コマンドを実行しようとすると、コマンドがブロックされてユーザーへの明示的確認が要求される。Prismaは「AIアシスタントからのDB保護機能を最初に実装したORM」と公式ブログで表明している。
確認フローと環境変数
ガードレールが発動した場合のフローはこうなる。
1. Claude Codeがprisma migrate resetを実行しようとする
2. Prisma CLIがClaude Code環境を検出してコマンドをブロック
3. ユーザーへの明示的確認を要求するメッセージが表示される
4. ユーザーが意図的に実行を承認する場合、PRISMA_USER_CONSENT_FOR_DANGEROUS_AI_ACTION環境変数に同意文を設定する
5. Claude Codeがその環境変数を設定した上でコマンドを再実行する
なお、PRISMA_USER_CONSENT_FOR_DANGEROUS_AI_ACTIONという環境変数名は公式ブログ（prisma.io/blog/orm-6-15-0-ai-safety-guardrails）に記載のある変数名だが、使用前にPrisma公式ドキュメントで正確な変数名と構文を確認してほしい。バージョンによって変更される可能性がある。
この仕組みの価値は「Claude Codeが自律的にデータを全削除するシナリオを構造的に防ぐ」ことにある。CLAUDE.mdのルールはClaude Codeが尊重しようとするが、設定を読み飛ばすことがありえる。v6.15.0のガードレールはCLI側で機械的にブロックするため、CLAUDE.mdとは独立して機能する。
アップグレードの動機
チームがPrismaの古いバージョンを使っている場合、v6.15.0へのアップグレードはAIコーディングエージェントを安全に使うための投資として説明できる。「パフォーマンス改善のアップグレード」より「AIによるDB破壊リスクの低減」という説明の方が、AI活用を進めているチームには刺さる動機になる。
CLAUDE.mdでPrismaマイグレーション規約を定義する——migrate reset禁止とdev/deploy使い分けの強制
Prisma CLIガードレールだけでは十分でない理由
v6.15.0のガードレールはmigrate resetのような明らかに破壊的なコマンドをブロックする。しかし「migrate devを本番環境で実行する」「prisma db pushでマイグレーションファイルを生成せずにスキーマを変更する」といった問題はガードレールの対象外だ。CLAUDE.mdによるポリシー定義がガードレールの補完として必要になる。
# CLAUDE.md（Prisma・データベース規約）
## Prisma Migration Policy
### 絶対に守るルール
- prisma migrate reset の実行禁止（データが全削除される。実行が必要な場合は必ず人間に確認する）
- prisma migrate dev は開発環境のみ（本番・ステージングで実行禁止）
- prisma migrate deploy が本番・CIでのマイグレーション実行コマンド
- マイグレーションファイル（prisma/migrations/）を手動編集禁止
- スキーマ変更後は必ず npx prisma generate を実行してTypeScript型を更新
### スキーマ変更フロー（開発時）
1. schema.prismaを編集
2. npx prisma migrate dev --name {変更内容} を実行（開発DBのみ）
3. 生成されたマイグレーションSQLを必ずレビュー
4. npx prisma generate でTypeScript型を再生成
5. テスト完了後にPRを作成
### 本番デプロイフロー（CIで自動実行）
- npx prisma migrate deploy のみ使用
- prisma/migrations/はGit管理下に置くこと（migration_lock.tomlも含む）
### 禁止事項
- prisma db push（マイグレーションファイルを生成しないため追跡不可）
- --force-reset フラグの使用
- 本番DB接続時のスキーマ変更操作migrate devとmigrate deployの違いを理解する
この区別をCLAUDE.mdに明記することが特に重要な理由は、migrate devとmigrate deployの挙動の違いにある。migrate devは開発環境向けで、ドリフト（スキーマとマイグレーション履歴の不一致）を検出するとインタラクティブに確認を求め、場合によってはDBをリセットする動作をとる。一方migrate deployは本番・CI向けで、非インタラクティブに動作し、アドバイザリロックを使って同時実行を防ぐ。
Claude Codeが環境を区別しない状態でマイグレーションを実行すると、本番環境にmigrate devが走るシナリオが発生しうる。CLAUDE.mdに「migrate devは開発環境のみ」を明記することで、Claude Codeはマイグレーション実行コマンドを生成する際に環境を考慮するようになる。
N+1問題防止をCLAUDE.mdに組み込む
Prismaを使う際のもう一つの典型的な落とし穴が、N+1クエリだ。CLAUDE.mdに以下を追加することで、Claude Codeがコードを生成する際にPrisma公式ドキュメントが推奨するパターンを自動的に採用する。
## Prisma Query Rules
- リレーションを取得する際は必ず include または select を使用する
（N+1問題を避けるため。ループ内でfindOneを使用しない）
- 複数レコードを取得する際は findMany + include でリレーションを一括取得
- 禁止パターン: posts.forEach(p => await prisma.comment.findMany({where: {postId: p.id}}))
- 推奨パターン: await prisma.post.findMany({include: {comments: true}})Prisma公式MCPサーバー——自然言語でスキーマ設計・マイグレーション確認・型生成
ローカルMCPとリモートMCPの使い分け
Prisma公式MCPサーバーにはローカルとリモートの2種類がある。ローカルMCPはprisma.schemaが置いてあるプロジェクトに直接アクセスするため、開発環境での作業に適している。
claude mcp add prisma-local -- npx -y prisma mcpリモートMCPはPrisma Postgres（マネージドサービス）を使っている場合に対応する。
claude mcp add --transport http prisma-remote https://mcp.prisma.io/mcp提供するツールのカテゴリは、スキーマ管理（マイグレーション状態確認・実行・スキーマ検査）・データ操作（SQLクエリ実行・データ分析）・データベース管理・バックアップ・開発ツール（Prisma Studio起動・型生成）に分かれている。
「AIがSQLを確認させてから実行する」フローの確立
Prisma MCPが接続された状態での指示パターンで最も重要なのは、「確認してから実行する」という会話の流れを作ることだ。
「Userモデルにprofile_imageカラム（String, nullable）を追加して。
マイグレーションを作成してTypeScript型を更新して。
マイグレーションSQLを私に確認させてから適用して」
「現在のマイグレーション状態を確認して、未適用のマイグレーションがあれば一覧を表示して」
「Prisma Studioを起動してUserテーブルの現在のデータを確認できるようにして」「マイグレーションSQLを私に確認させてから適用して」という文言をCLAUDE.mdのスキーマ変更フローに組み込んでおくことで、Claude Codeがデフォルトでこのステップを踏むようになる。「AIが勝手にDBを変更する」という不安を、会話の構造で解消できる。
バックアップを含めた安全フロー
Prisma MCPのバックアップ機能を使えば、スキーマ変更前にバックアップを取るフローもClaude Codeに組み込める。「このマイグレーションを適用する前にDBのバックアップを作成して」という指示を、スキーマ変更指示の前に入れる習慣をCLAUDE.mdで定義することで、万が一の際の復旧手段が常に確保される。
まとめ
Issue #34729のインシデントが示すのは、「AIが生成したコードのバグ」ではなく「AIが生成したコマンドがデータを消す」という新しいリスクカテゴリだ。コードは後から直せるが、DBのデータは消えたら戻らない。
Prisma v6.15.0のAIガードレールは技術的なブロック機構として機能し、CLAUDE.mdの規約定義はClaude Codeの行動方針として機能する。この二重防護の組み合わせがAIによるDB破壊リスクに対する現実的な対策だ。
着手しやすいのはCLAUDE.mdへの「migrate reset禁止」と「migrate devは開発環境のみ」の追記だ。1行追加するだけでClaude Codeの挙動が変わる。Prismaをv6.15.0以降にアップグレードして、その上でCLAUDE.mdによる補完を加えることで、AIを使った開発における「DBだけは触らせるな」という不安を実際に解消できる。
コメント