バイブコーディング前にER図は必要？学習記録アプリで学ぶデータ設計

バイブコーディングの前にER図は必要なのでしょうか。データを保存し、複数人が使うアプリなら、先にデータの関係と所有者を整理する価値があります。ただし、画面を試作する段階から完成版の設計図を用意する必要はありません。

この記事では、学習記録アプリを例に「どこまで決めてからAIに作ってもらうか」を整理します。図だけでなく、項目表・権限表・確認テストまでを小さくまとめる方法です。例は本記事用の架空の設計で、公開サービスでの実証結果ではありません。

1. ER図を先に描くと何がよい？ 必須ではない場面もある

ER図は、ユーザーや学習記録といったデータのまとまりと、その関係を表す図です。「1人が複数の記録を持つ」といった関係を、画面と切り離して考えられます。

「学習アプリを作って」だけでは、記録を誰が所有するのか、教材を消すと記録も消えるのかまで決まりません。そこで本記事では、実データを保存する前に、小さなデータ設計をAIと確認する進め方を提案します。これは技術資料を踏まえた編集上の提案で、「ER図を先に描けば開発が必ず成功する」という研究結果ではありません。

実際、Lovableの公式ガイドは、サンプルデータで画面や操作を先に試し、必要になったらバックエンドを追加する流れを紹介しています。役割の整理や、2人のユーザーでアクセス分離を確認することも扱っています。設計と試作は両立できます。出典：Lovable 公式開発ガイド

2. 学習記録アプリを2つのテーブルで考える

最初の機能を「ログインした本人が、日付・学習テーマ・学習時間・メモを保存する」に絞ります。共有、ランキング、チーム機能はまだ作りません。

新規ユーザーは記録が0件でも存在できる一方、学習記録には必ず所有者がいます。主キー（PK）は行を特定する値、外部キー（FK）は関連先の行を参照する値です。

学習テーマはまず文字列にしました。「SQL」「ＳＱＬ」の表記を統一したい、教材ごとのURLや進捗を持ちたい、と必要性が見えたら教材テーブルを追加できます。最初から将来の全機能を設計するより、今の機能で判断が分かれる部分を明確にします。

AIやドキュメントに渡せるMermaidの例

次のコードをMermaid対応エディタへ貼り付けるとER図として表示できます。ブログ上ではコピー用コードとして掲載しています。記法の詳細はMermaid公式ER図ドキュメントを参照してください。

erDiagram
    USERS ||--o{ STUDY_LOGS : owns
    USERS {
        uuid id PK
    }
    STUDY_LOGS {
        uuid id PK
        uuid user_id FK
        date studied_on
        string topic
        int minutes
        string note
    }

図の線は、実際のデータベース制約を自動的に作るものではありません。また、必須項目・入力範囲・権限のすべてをこの図だけで表しているわけではありません。上の項目表と次のルールを一緒に渡します。

3. ER図と一緒に「制約・権限・削除」を決める

制約：保存してよいデータを決める

外部キーは、参照先のユーザーが存在することを確認する仕組みです。必須ならNOT NULLも必要です。学習時間の範囲はCHECKなどで表現できます。これらはデータの整合性を守りますが、操作した人にその権限があるかまでは判断しません。出典：PostgreSQL 制約

本例では同じ日に複数回学習できるため、「ユーザーと日付の組み合わせ」を一意にしません。1日1件にしたいなら別の設計になります。このような業務上のルールこそ、人がAIに伝えるべき内容です。

権限：そのデータを誰が扱えるか決める

この表は、画面とAPIの両方に対応させます。ログイン済みかを調べるだけでなく、対象の記録の所有者を毎回検証します。IDを推測しにくいUUIDにしても、認可の代わりにはなりません。出典：OWASP 認可

PostgreSQLには、行単位のアクセスを制御するRLSもあります。ただしテーブル所有者やBYPASSRLSなどの権限には例外があるため、一般ユーザーとしての実行経路で確認する必要があります。「RLSを有効にした」の一言で完成とせず、読み取りと書き込みのポリシーを設計します。出典：PostgreSQL 行セキュリティ

削除：親を消したときの結果を決める

本例の初版では退会機能を設けず、記録があるユーザーの直接削除は制約で拒否する方針にします。退会機能を追加する段階で、本人確認・対象表示・記録削除・認証基盤側の処理をまとめて設計します。無条件の連鎖削除を、意図を確認せずに採用しないことがポイントです。

4. バイブコーディングの最初に使う依頼文

図と表を保存してから、次のように依頼します。例は設計を確認するためのもので、特定ツール専用ではありません。

学習記録アプリを作りたいです。最初に実装計画を提示してください。

対象：ログインした本人だけが使う学習記録。共有・課金・退会機能は初版に含めません。
データ：添付のER図・項目表・権限表を参照してください。
同じ日に複数回の学習記録を登録できます。
所有者は認証済みの本人から確定し、クライアントが別人に変更できないようにします。

まず次を提示してください。
1. 前提と未決事項。矛盾があれば質問する
2. 利用するDB・認証方式に合う制約と認可の実装方針
3. 作成・読み取り・更新・削除の確認テスト
4. データ移行と変更を戻す方法

設計を確認後、架空データで1機能ずつ実装してください。
本番データの変更や公開は、この依頼に含めません。

「データベースは何でもよい」のままSQLだけを出させず、採用するDBと認証方式を先に合わせます。設計が変わったら、図・項目表・権限表も更新します。AIには変更箇所とその理由を渡すと、会話の途中で前提が食い違うのを減らせます。

5. 完成の判断は図ではなく、データとテストでする

本記事の例なら、少なくとも次の結果を確認してから公開を検討します。自分が管理するテスト環境に、架空のAさん・Bさんを用意して実施してください。

AIが「テストしました」と返した場合も、実行したテスト、期待結果、実際の結果を確認します。管理者だけで試すと、一般ユーザーの権限の問題を見逃すことがあります。

初めてなら、まず「何を保存するか」「誰のデータか」「誰が操作できるか」の3つを書いてみてください。それをER図と表にし、実装とテストにつなげれば、設計そのものが学習教材になります。

関連：Astraのトークン利用効率を上げる方法

あわせて読む：AI時代のセキュリティ対策｜入力情報・連携権限・公開前の確認リスト

資料確認日：2026年9月16日。本文は公式資料を基にした設計の解説です。特定のSNS投稿の主張を検証したものではありません。