はじめに
Claude Code、Codex、Cursor——AIを使えば、1人で数週間あればPOC（概念実証）レベルのWebアプリが作れる時代になりました。
複数人で何ヶ月もかけていたものが、複数のAIエージェントを並列で動かせば、一人でも形にできる。実際に自分も、アカウント管理アプリの開発でAIに要件定義書・基本設計・詳細設計・DB設計まで全部作らせました。
最初はそれで良いと思っていたんです。AIが作ってくれるなら、自分は「AIの出力をチェックする側」に回ればいいんだと。
でも、それは大きな勘違いでした。
想定読者
AIでアプリ開発を始めたが、設計に自信がないジュニアエンジニア
この記事でわかること
- AI時代になぜDB設計を「自分で」学ぶべきか（実体験ベース）
- DB設計の最低限の基礎（正規化・主キー/外部キー・制約・ER図）
AIが設計して、AIがレビューする——何が問題か
自分がやっていたのは、こういうフローでした。
AIが設計して、AIがレビューして、AIがOKと言う。一見問題なさそうですよね。
でもこのフロー、自分がどこにもいないんです。
上司からこう言われました。
「DB設計の基礎がない状態で、この構造が正しいかどうか、判断できてる？」
正直、できていませんでした。
テーブルの数が多いのか少ないのか。リレーションの張り方がおかしくないか。正規化が足りているのか、やりすぎなのか。何が良くて何が悪いのか、自分の中に基準がなかった。
AIの出力を「なんとなく合ってそう」で通していただけでした。
気づき：自分の軸がないと、AIの出力を評価できない
ここで気づいたのは、自分が一度でも設計をやってみないと、判断軸ができないということです。
DB設計の知識がゼロの状態でAIにレビューを頼んでも、AIが「問題ありません」と言えばそれで終わり。本当に問題がないのか、見落としがあるのか、自分では区別がつかない。
逆に、自分で「このアプリにはどんなデータが必要か」「テーブルをどう分けるか」を考えてから設計すると、必要なデータが見えてくる。
その上でAIや上司にレビューしてもらえば、指摘の意味がわかるし、「なぜそう直すべきか」も理解できる。
自分で設計する → レビューをもらう。この順番がエンジニアとしての成長につながると実感しました。
なぜ「DB設計」が特に重要なのか
AI時代にエンジニアとして重要なスキルは何か。上司からもらったアドバイスがシンプルで腑に落ちました。
「DB設計が固まっていれば、UIや機能の追加はAIですぐ作れる。」
つまり、こういう構造です。
- 要件定義：どの課題を解決して、何をやらないかを決める
- DB設計：どうやってデータを管理するか
この2つが土台。土台さえしっかりしていれば、「このテーブル構造で〇〇画面を作って」とAIに指示するだけで、UIもAPIも生成できる。
逆にDB設計が甘いと、機能を追加するたびにテーブル構造の変更が必要になる。マイグレーションが増え、既存データとの整合性が崩れ、AIに指示を出しても矛盾したコードが生まれる。
DB設計は、AIに仕事を任せるための「指示書」の土台なんです。
DB設計の基礎：最低限押さえる3つ
自分もまだ学び始めたばかりですが、「最低限ここを押さえれば設計に手が出せる」と感じた3つを共有します。
1. エンティティとリレーション（何を、どう関連づけるか）
DB設計の出発点は「このアプリで扱うデータは何か」を洗い出すこと。
例えばアカウント管理アプリなら：
- ユーザー（誰が使うか）
- アカウント（何を管理するか）
- ログイン履歴（いつ使ったか）
これが「エンティティ」。そしてエンティティ同士の関係が「リレーション」です。
- 1人のユーザーは複数のアカウントを持つ（1対多）
- 1つのアカウントには複数のログイン履歴がある（1対多）
2. 正規化（データの重複をなくす）
正規化は「同じデータを2箇所以上に書かない」ための整理術です。
やる前（非正規化）：
| ユーザー名 | メール | アカウント名 | サービスURL |
|---|---|---|---|
| 田中 | tanaka@example.com | GitHub | github.com |
| 田中 | tanaka@example.com | Slack | slack.com |
「田中」と「tanaka@example.com」が2行に重複しています。メールアドレスを変更するとき、両方の行を更新する必要があり、片方だけ更新し忘れるリスクがある。
やった後（正規化）：
ユーザーテーブル
| id | ユーザー名 | メール |
|---|---|---|
| 1 | 田中 | tanaka@example.com |
アカウントテーブル
| id | user_id | アカウント名 | サービスURL |
|---|---|---|---|
| 1 | 1 | GitHub | github.com |
| 2 | 1 | Slack | slack.com |
ユーザー情報は1箇所だけ。メールを変えたらユーザーテーブルの1行を更新するだけで済みます。
3. 主キー・外部キー・制約（データを守るルール）
正規化でテーブルを分けたら、次は「テーブル同士をどう繋ぐか」と「おかしなデータを入れさせない仕組み」が必要です。
主キー（Primary Key / PK）
各行を一意に識別するためのカラム。さっきの正規化の例でいう id がこれです。
CREATE TABLE users (
id INTEGER PRIMARY KEY, -- この行を一意に特定する
name TEXT NOT NULL,
email TEXT NOT NULL UNIQUE
);
主キーがあることで「ユーザーID: 1の田中さん」と「ユーザーID: 2の田中さん」を区別できます。同じ名前でも、IDが違えば別の人。
外部キー（Foreign Key / FK）
別テーブルの主キーを参照して、テーブル同士を繋ぐカラム。アカウントテーブルの user_id がこれです。
CREATE TABLE accounts (
id INTEGER PRIMARY KEY,
user_id INTEGER NOT NULL, -- usersテーブルのidを参照
service_name TEXT NOT NULL,
service_url TEXT,
FOREIGN KEY (user_id) REFERENCES users(id)
);
FOREIGN KEY を設定すると、存在しないユーザーIDでアカウントを作ろうとしたときにDBがエラーを出してくれます。「ユーザーID: 999」が存在しないのにアカウントだけ作れてしまう、という事故を防げる。
制約（Constraints）
「このカラムにはこういうデータしか入れさせない」というルールです。
| 制約 | 意味 | 例 |
|---|---|---|
NOT NULL |
空欄を許さない | 名前は必須 |
UNIQUE |
重複を許さない | メールアドレスは一人一つ |
DEFAULT |
値がなければ初期値を入れる |
created_at にデフォルトで現在時刻 |
CHECK |
条件を満たす値のみ許可 | 年齢は0以上 |
AUTO INCREMENT |
IDを自動で1, 2, 3...と採番 | ほぼ全テーブルの id で使う |
ON DELETE CASCADE |
参照先が消えたら関連データも消す | ユーザー削除 → アカウントも削除 |
ON DELETE SET NULL |
参照先が消えたら外部キーをNULLにする | ユーザー削除 → ログ履歴は残すが紐づけを外す |
制約はアプリのコードではなくDB側で守るルールです。アプリにバグがあっても、DBが最後の防波堤になってくれる。AIにコードを書かせるとき、この制約がしっかりしていれば、おかしなデータが入り込むリスクが減ります。
4. ER図で全体像を掴む
テーブルの関係を図にしたのがER図（Entity-Relationship Diagram）です。アカウント管理アプリの例：
この図が読めると、テーブル同士の関係が一目でわかります。「ユーザー1人に対してアカウントは複数」「ログイン履歴はユーザーとアカウントの両方に紐づく」。
ER図を自分で書いてみるだけでも、どんなデータが必要で、どう繋がるかが頭の中で整理されます。
まとめ
- AIにDB設計を丸投げしていたら、上司に「自分の軸がないのでは？」と指摘された
- 自分の軸がないと、AIの出力の良し悪しが判断できない
- まず自分で設計してみる → その上でレビューをもらう。この順番が判断軸を育てる
- AI時代に人間が握るべきは要件定義とDB設計。この土台が固まれば、UI・API・テストはAIに任せられる
- DB設計の基礎は「知識量」ではなく「一度やってみること」で身につく
ジュニアだからこそ、今のうちにDB設計を自分の手で触っておく価値があると思っています。自分もまだ学び始めたばかりなので、実際にアカウント管理アプリのDB設計をゼロから自力でやってみた過程も、今後書いていきます。