ERDとは何か — バイブコーダーが数か月後に自分のサービスを読み直すための地図

ERDは数か月後の自分のための中間ドキュメントだ

講義はバイブコーダーの開発スタイルから始まる。今はまだコードを直接読むより、コードの外にある中間ドキュメントを使い、システムをできるだけ自分が主導する状態で開発を続けよう、というものだ。中間ドキュメントとは、コードが何をしているかを人の言葉と絵に書き直した文書だと考えればいい。

講義が挙げる中間ドキュメントは三つある。一つ目はPRDで、何をなぜ作るのかを文章で書いた企画書だ。二つ目は画面資料で、ユーザーがどの画面をどんな順に通るかを描いたユーザーフロー、画面の骨組みだけを線で描いたワイヤーフレーム、実際の見た目に近く描いたモックアップをひとまとめにしている。三つ目がERDだ。

前の二つは文章と絵なので、特に習わなくても読める。ERDは違う。概念なしに見ると四角と線しかなく、「で、これを何に使えというのか」と思ってしまう。講義がERDだけに時間を割いた理由だ。

二つ目の理由はもっと実用的だ。最初はたいてい本当に必要な機能だけを入れた最初の版を、いちばん簡単なやり方で作る。しばらくして機能を足そうと開き直すと、当時の文脈が思い出せない。講義は、その瞬間に「自分はどう作ったんだっけ」をすばやく取り戻させてくれるのがERDだと言う。

エンティティ・テーブル・行・列 — 四つの言葉で読める

ERDはEntity Relationship Diagramの頭文字で、エンティティどうしがどんな関係を結ぶかを描いた図という意味だ。関係は次回から扱い、今回は図の中の四角一つを読むところまで進む。

エンティティとは、サービスが関心を持って管理すべき対象だ。モバイル招待状サービスなら、管理者と招待状がそれにあたる。エンティティがデータベースに移るとテーブルになる。データベースはサービスのデータをためておく場所で、開いてみると表計算のような形をしている。その表一枚がテーブルだ。

テーブルの下に一行ずつ積まれるデータ一件を行（row）という。招待状一枚が一行だ。IDや名前のように、そのテーブルが持つ属性一つひとつを列（column）という。表を縦に区切った一つひとつの枠だから列で、英語でカラムだ。

同じものをコードでは別の名前で呼ぶこともある。講義の整理では、エンティティをオブジェクト、行一つをインスタンスと呼ぶ。AIが書いたコードや説明にこの二語が出てきたら、それぞれテーブル一つとその中の一行を思い浮かべればいい。

モバイル招待状でエンティティとカラムを分ける

講義はモバイル結婚式招待状サービスを例にとる。要件は単純だ。管理者がログインする。管理者がモバイル招待状を作る。招待状にはタイトル・日付・会場・メッセージが入る。テンプレートは三つほど決めておき、その中から一つを選んで使う。

ここでのエンティティは何か。講義の答えは二つだ。まず管理者。誰でも入れるサービスではなく、ログインした管理者が招待状を作るので、管理者という対象を別に管理する必要がある。次に、その管理者が作る招待状だ。招待状テーブルには誰が作ったかを書く admin_id の欄を置くが、二つのテーブルをつなぐこうした欄は次回から詳しく見る。

タイトル・日付・会場・メッセージはエンティティではない。招待状が持つ性質なので、招待状テーブルのカラムとして入る。新郎の名前・新婦の名前も同じだ。分ける問いは一つ。別に置いて管理する対象か、それとも何かに付随する属性か。

自分のサービスでも同じことができる。サービスが扱う名詞をすべて書き出し、一つずつこの問いを投げる。前者ならテーブル、後者ならそのテーブルのカラムだ。どちらか迷う名詞が残ったら、そこが対象どうしの関係を考えるべきところだ。

invitations (招待状)
────────────────────────────────────────
id           一枚ごとに付くID
admin_id     作成した管理者
title        タイトル
date         挙式日
place        会場
message      メッセージ
groom_name   新郎の名前
bride_name   新婦の名前
template     テンプレート1・2・3のどれか

一行 = 招待状一枚

枠ごとにデータ型を決める

カラムを決めたら、枠ごとにどんな形の値が入るかを決める。これがデータ型だ。数字の枠に文字が入ったり、日付の枠に適当な文が入ったりしないよう、あらかじめ釘を刺しておくものだ。講義が取り上げた型は下の表のとおり。

たいていは名前を見れば見当がつく。紛らわしいのは二つだ。decimalは数字なのでintegerと似て見えるが、講義は決済残高のようにお金に関わる値に主に使うと整理している。vectorはRAGに使う型だ。RAGはAIが答える前に関連文書を探して読ませる方式で、文書の意味を数字の並びに変えておくと似た内容を探せる。その数字の並びを入れる枠がvectorだ。

enumは、あらかじめ決めた値しか受け付けない型だ。ログイン手段をカカオ・Google・Appleのどれかだけで受けたり、テンプレートを1・2・3のどれかだけで受けたりする。リストにない値が入ってきたらエラーになるようにしておく。

招待状に当てはめるとこうなる。講義はIDをUUID、会場・新郎の名前・新婦の名前をvarchar、テンプレートをenumにした。残りも同じ基準で選べばいい。タイトルは短い文なのでvarchar、メッセージは長くなりうるのでtext、挙式日はdate系だ。

いま作っているサービスがあるなら、下の依頼文をそのままAIに渡せばいい。テーブルとカラム、型を一つの表で受け取っておけば、数か月後に開き直す記録の出発点になる。次回は招待状にお祝いメッセージ機能を付けながら、どの値をカラムに残し、どの値をテーブルに切り出すべきかを見る。

このプロジェクトのデータベーステーブルをすべて探して、
テーブルごとに カラム名 · データ型 · 一行の説明 を表にまとめて。
enumのカラムは許可する値の一覧も一緒に書いて。
コードは直さず、読むだけにして。