対象読者
- supabaseで小さいサービス作ろうとしている人
- dbや関連ツールの技術選定中の人
- とりあえずdbスキーマをある程度真面目に作ろうとしている人
- db全部消して～～ってなってる人
自分でWebサービスを個人開発していて、ある程度開発者フレンドリー・AIフレンドリーだなと思った方法と、そこにいたるまでの失敗を共有します。
アプリケーション側のコードとは一切関係ありません。
これは何か
一言でいうと、DBを簡潔にスクラップ＆ビルドするための方法論です。
もう少し具体性をもたせると、「supabaseデータベースに対してPrismaでスキーマ管理をしよう。シードデータは決定論的にUUIDで投入しよう。それらをまとめてリセットするコマンドを作ろう」というものです。
自分が使用しているのでSupabaseで説明しますが、DBは何でも応用可能だと思います。
実際のディレクトリ構造としてはこんな感じになります。
モノレポ想定で自分はCloudflare Workersを使っているのでworkers/apiが生やしています。
上のpackage.jsonにリセットコマンドを登録しておき、DBスキーマを変更するたびに叩きます。
次のコマンドを順番に叩くリセットコマンドを作成しておきます。（local想定）
もしスキーマにあてたいマイグレーションがない場合は、3と4は消して大丈夫です。
私の場合、APIサーバーからSupabaseに接続する都合上service_roleにpublic schemaにアクセスする権限を与えています。
これはスキーマが作成されてから実行しないといけないため、コマンドが多くなってしまいました。
この手法のメリット
別にこの手法が特別というわけじゃないことも多いですが、総合して書きます。
１. 1ファイルでスキーマを管理できる
これが一番大きいです。「ただのPrismaのええところやんけw」というツッコミは置いといてください。
AIにDBスキーマを渡すときに、1ファイルぽんと渡せばそれで済みます。
2. コード量の削減
AIで生成するときにじわじわ効いてきます。すでに億万長者で無限にコンテキストをAIにぶち込んで開発できる方はおいときます。いうて限界はあると思いますが。
自分が作っているサービスの例だと、Drizzleで60,000文字のものがPrismaだと20,000文字ほどで管理できます。（もちろんその分、SQLのほうが詳細に色々設定可能ですが）
3. 開発の再現性を100%にする
シードデータに決定論的なUUID（何度生成しても同じになるID）を採用することで、開発のあらゆる場面で再現性と安定性が劇的に向上します。
-
バグ再現の高速化: 「ユーザーAの作品Bでバグが出た」という報告を受ければ、チームの誰もが手元の環境で100%同じデータ状態を再現できます。これにより、原因の特定から修正までの時間が大幅に短縮されます。
-
テストの安定化: E2EテストやCIは、毎回まったく同じデータで実行されます。これにより、「原因不明のテスト失敗」といった不安定要素がなくなり、テストの信頼性が格段に向上します。
従来のようにテストコードにIDを直接書き込んでも、スキーマ変更のたびにIDを修正する必要がなくなる、といった副次的なメリットもあります。
4. 維持管理コストがほぼかからない
上のディレクトリ構造を見れば分かる通り、関連ファイルがすごく少ないです。（シードデータは別）
つまり、仕様変更を全部AIに丸投げできます。
自分がやったこととしては、環境切り替えの実装やシードデータ入稿スクリプトとかです。
まとめ
この手法の本質：
- スクラップビルドで高速に開発
- 決定論的ID生成により、同じ入力から同じ結果を保証
- コンテキスト少でAIフレンドリー
注意点：
- 本番運用では間違ってもこのコマンドを叩いてはいけない。自分はdrizzleでのmigrationを追加する予定 ※1
- 学習コストはそれなりにある（Supabase, Prisma前提）
※1 なぜこの技術スタックにしたのかは記事の主題とずれるので、別でまとめる予定です。
同じような困りごとで悩んでいる人の参考になれば嬉しいです。質問があればいつでもどうぞ。
