後で直すが一番高くつく、 Prisma の話

〜 今のスキーマ、 1 年後も読めますか 〜

本番データが 1 万件を超えた頃、スキーマを変えようとして手が止まった。

String で定義していたステータスカラムを Enum に変えたい。
nullable にしていたカラムを NOT NULL に制約したい。
1 対 1 で設計していたリレーションを、1 対 N に変えたい。

どれも「ちょっとした修正」のはずだった。
実際には、マイグレーションファイルが壊れ、既存データの変換が必要になり、アプリケーションコードの修正が連鎖し、テストが全滅した。

後で直せばいいと思っていた設計が、後になって最も高くつく
——これが、Prisma を使い続けて僕が学んだ最大の教訓でした。

スキーマは後で直せるという錯覚

Prisma のスキーマ定義は、驚くほど書きやすい。

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String?
  published Boolean  @default(false)
  createdAt DateTime @default(now())
}

この数行を書くだけで、型安全なクライアントが生成される。
モデルを変えたければ schema.prisma を編集して prisma migrate dev を実行する。
まるでコードを書き直すように、スキーマを直せる感覚があります。

ここに罠がある。

開発初期、データが数十件のうちは確かに直せる。
しかし、本番で数千件・数万件になったとき、スキーマの変更は単なるコードの編集ではなくなります。

📌 既存データの変換が必要になる
　（例: String → Enum への変換は全レコードに影響する）

📌 NOT NULL 制約の追加は、既存データが NULL である場合にマイグレーションが失敗する

📌 リレーション構造の変更は、外部キー制約と既存レコードの整合性が問われる

後で直すという判断を下したとき、そのコストを正確に見積もれている開発者は多くありません。
少なくとも、以前の僕には無理でした。

後でのコストが見えにくい理由

なぜ最初の設計が甘くなるのか。

理由は 3 つあると思っています。

【理由 1】 「動く」と「正しい」を混同する

個人開発では、動いた瞬間に完成したと感じやすい。
スキーマが型安全に生成され、CRUD が動作すれば、設計の良し悪しは問われません。

String で定義したステータスが正しいかどうか
——動作確認では判断できないのです。

【理由 2】 変更コストが未来の自分に押しつけられる

スキーマ設計の問題は、書いたその日には現れません。
3 ヶ月後、6 ヶ月後、データが増えた段階で表面化します。

問題が出たとき、多くの場合は締め切りが近い、あるいは別の機能開発で忙しい。
最悪のタイミングで最もコストの高い修正を迫られます。

【理由 3】 Prisma の書きやすさがリスクを隠す

Prisma のスキーマ定義は、本当によくできている。
シンプルで直感的で、書くことへのハードルが低い。

その書きやすさが「気軽に書き始められる」という感覚を生み、「設計を深く考える前に書いてしまう」という行動につながります。

実際に高くついた設計ミス 3 選

僕が実際に経験した、後で直すコストが高かった設計ミスを 3 つ挙げます。

【ミス 1】 ステータスを String で定義した

model Order {
  id     Int    @id @default(autoincrement())
  status String  // "pending" | "shipped" | "delivered" | "cancelled"
}

一見問題ないように見えます。
しかし、アプリケーションコードのあちこちに if (status === "shipped") が散らばり始めた段階で、タイポや値の不一致が起き始めます。

Enum にすれば防げた問題でした。

enum OrderStatus {
  PENDING
  SHIPPED
  DELIVERED
  CANCELLED
}

model Order {
  id     Int         @id @default(autoincrement())
  status OrderStatus @default(PENDING)
}

後からこの変換を行ったとき、既存の String データをすべて Enum 値にマッピングするマイグレーションが必要になり、数時間を要しました。

【ミス 2】 nullable の設計が甘かった

model User {
  id      Int     @id @default(autoincrement())
  address String?  // 後で必須にしたいが NULL が散在
}

初期は「住所は任意入力」と判断して nullable にしていました。
後から「住所は必須にしたい」という要件が加わったとき、既存の全レコードに仮データを入れてから NOT NULL に変更する作業が発生しました。

nullable にするかどうかは、ビジネスロジックの深い理解が必要です。
「後で考えよう」で定義した nullable は、ほぼ必ず後悔します。

【ミス 3】 1 対 1 のリレーションを後から 1 対 N に変えた

// 最初の設計
model User {
  id      Int      @id @default(autoincrement())
  profile Profile?
}

model Profile {
  id     Int  @id @default(autoincrement())
  userId Int  @unique  // 1 対 1
  user   User @relation(fields: [userId], references: [id])
  bio    String?
}

「プロフィールは 1 人 1 つ」という当初の要件が変わり、「複数のプロフィール（例: 企業アカウントの複数担当者）」に拡張する必要が生じました。

@unique を外して 1 対 N に変更する作業は、外部キー制約・既存データの整合性確認・アプリケーションコード全体の修正を伴い、丸 1 日かかりました。

スキーマを書く前に問う 5 つのチェックリスト

経験から作り上げた、スキーマを本番に出す前に必ず確認する 5 つの問いです。

【チェック 1】 このカラムは String のままでいいか

値が有限の選択肢であれば、Enum を使います。

例: status, role, type, category → Enum 候補
例: name, email, description     → String のまま

判断基準:

あるなら Enum が候補。
追加された選択肢をコード上で管理できます。

【チェック 2】 このカラムは本当に nullable でいいか

nullable（?） を定義する前に、この問いを必ず立てます。

明確に答えられないなら、NOT NULL の方が安全です。
後から NOT NULL に変えるより、最初から NOT NULL の方がコストは低い。

nullable にするのは「ビジネス上の理由で空を許容する」と明確に決断したときだけです。

【チェック 3】 このリレーションは将来 1 対 N になる可能性はないか

1 対 1 で設計したリレーションは、後から 1 対 N に変えるのが最も高コストな変更の一つです。

設計時に自問します:

「現時点では 1 つだが、将来的に複数になる可能性がある」と少しでも感じたら、最初から 1 対 N で設計します。
空の配列（レコード 0 件）を持つ 1 対 N は問題ありませんが、1 対 1 を 1 対 N に変えるのは破壊的変更になります。

【チェック 4】 createdAt と updatedAt はすべてのモデルに入れたか

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt   // ← これを忘れがち
}

updatedAt を後から追加する場合、既存レコードにデフォルト値を入れる必要があります。
「ログが取れない」「更新日時でソートできない」という要望は、後から必ず来ます。
最初から全モデルに入れておきます。

【チェック 5】 ソフトデリートが必要なモデルを特定しているか

model User {
  id        Int       @id @default(autoincrement())
  email     String    @unique
  deletedAt DateTime?  // ソフトデリート用カラム
}

ユーザーデータ、注文データ、コンテンツデータなど——削除が必要なモデルに対して、物理削除（レコードの完全削除）かソフトデリート（deletedAt を記録して論理削除）かを、最初に決めます。

後から「削除したユーザーの注文履歴が消えてしまった」という問題が出てから変更するのは、外部キー制約が絡む最も複雑な変更の一つです。

スキーマを出す前の実践レビュー手順

チェックリストを確認する手順は、シンプルに 3 ステップです。

【ステップ 1】 schema.prisma を通しで読む

コードを書いているときは細部に集中しています。
一度書き終えたら、全体を俯瞰で読む時間を 15 分だけ作ります。

「このモデルは 6 ヶ月後も同じ構造でいられるか？」という問いを持ちながら読む。

【ステップ 2】 各モデルに 5 つのチェックを当てはめる

上述の 5 つのチェックリストを、各モデルに順番に当てはめます。

## スキーマレビューチェックリスト

### [モデル名]
- [ ] String カラムに Enum 候補がないか
- [ ] nullable の根拠は明確か
- [ ] リレーションの cardinality（1:1 / 1:N / N:M）は正しいか
- [ ] createdAt / updatedAt が揃っているか
- [ ] ソフトデリートが必要か検討したか

このチェックは、1 モデルあたり 2〜3 分で終わります。
5 モデルあっても 15 分程度です。

【ステップ 3】 変更が必要な箇所はマイグレーション前に直す

ステップ 2 で発見した問題は、最初のマイグレーション実行前に直します。

一度 prisma migrate dev を実行してマイグレーションファイルを生成すると、変更のたびに新しいマイグレーションファイルが増えます。
本番に出す前の段階で修正すれば、開発環境のマイグレーション履歴は prisma migrate reset でリセットできます。

本番前に直すコストと本番後に直すコストの差は、データ量に比例して広がります。

後で直すを選択肢から外す

Prisma の書きやすさは本物です。
スキーマを書くことへのハードルが低く、型安全なコードが自動生成される体験は、他の ORM にはないものがあります。

その書きやすさに乗りながら、後で直すという選択肢を設計時に封じる。
それが、1 年後の自分へのいちばんの親切だと、僕は思っています。

完璧なスキーマは最初から存在しません。
しかし、後で必ず後悔する設計判断は、事前に防ぐことができます。

今のスキーマを、5 分だけ見直してみませんか。

あわせて読みたい

▼ Prisma のクエリ実行時のパフォーマンス問題に直面したときに

スキーマ設計が正しくても、クエリの書き方で地獄に落ちることがある。
N+1 問題の発見から解決まで、実際のコードと共に記録した記事。
スキーマ設計の次に読むと、設計と実行の両輪が揃います。

▼ 認可や境界を最初に決めて、手戻りを防ぎたいときに

スキーマと同じく、認可も後で直すが一番コストがかかる領域。
最初が 9 割になる設計の考え方と、NextAuth.js を使った最小実装で、本番後の手戻りを防げます。

▼ Server Actions やフォームの境界を、本番前に固めたいときに

「どこでバリデーションするか」「認可は誰が担うか」を先に決めておく設計論。
Prisma のスキーマと合わせて読むと、データ層から API 層まで一貫した後で直さない設計がイメージできます。

▼ Next.js のフォームを事故らせずに作りたいときに

入力と設定を最初から型とバリデーションで守る話。
スキーマを正しく設計したあと、その上に乗るフォーム層まで一気に堅くしたい人に刺さります。

▼ 環境変数や設定も後で直す、をやめたいときに

スキーマと同じく、設定も動いたからいいで流すと本番で痛い目を見る。
Zod で検証を仕込む具体的なやり方で、設定まわりも最初から守れます。

▼ 動けばいいで書いて、後からテストで泣きたくなかったときに

動けばいいはスキーマでもテストでも同じ罠。
後から直すコストの大きさと、最初からテストを書く理由が、体験談で腹落ちします。

▼ エラーやログを最初に決めておきたいときに

スキーマを最初に見直すのと同じ発想で、エラーとログの境界を先に決めておく話。
個人開発のバックエンドを一通り堅くしたい人向けです。

▼ 未来の自分を守る設計の考え方を言葉にしたいときに

後で直すを選ばない理由を、速さより持続可能性の視点で言語化したエッセイ。
設計で悩んだときに背中を押してくれます。

▼ Prisma をこれから使い始めるときに

Prisma を導入したきっかけと、型安全な DB アクセスで得られた安心感をまとめた記事。
スキーマ設計の記事とあわせて読むと、設計のなぜがより伝わります。

ひとりごと

スキーマ設計で失敗するたびに思うのは、「あのとき 15 分だけ見直していれば」です。

コードのリファクタリングは比較的気軽にできます。
関数名を変えても、ロジックを整理しても、アプリケーションの振る舞い自体はすぐに戻せます。

スキーマの変更は違います。
一度本番データが入ると、元に戻すという選択肢が実質的になくなることがある。

だからこそ、最初の 15 分が大事です。
誰かの後で直そうが減りますように。