【第3回】Claude Codeと一緒にER図を考える｜DB設計の壁打ち活用術

社員ブログ

※Claude Codeを使用して記事を作成しています。

前回の記事では、Claude Codeを使って曖昧な要件を仕様書に落とし込む方法を紹介しました。

今回は、仕様書の次のステップです。

「どんなデータを、どう持つか」

DB設計は、後から変更するとコストが大きくなる領域です。
だからこそ、設計段階でしっかり考えることが重要です。

Claude Codeを壁打ち相手にしながら、ER図を整理する方法を実例で解説します。

DB設計でよくある失敗

DB設計を後回しにしたり、深く考えずに進めると、以下のような問題が起きやすくなります。

  • 途中でテーブル構造を変えることになり、既存データの移行が発生する
  • 欲しいデータを取得するためのクエリが複雑になる
  • 機能追加のたびにテーブルを修正する必要が出る

これらは、最初の設計段階で「何をどう持つか」を整理しておくことで、多くを防げます。

Claude CodeはER図を”描く”ツールではない

最初に明確にしておきたいことがあります。

Claude Codeは、ER図を画像として出力するツールではありません。

しかし、

  • テーブルの構成を言語化する
  • カラムの洗い出しを手伝う
  • テーブル間の関係を整理する
  • 設計の選択肢を比較する

という用途では、非常に強力な壁打ち相手になります。

「ER図を描く前の思考整理」にClaude Codeを使う

というイメージで活用してください。

実例：タグ機能のDB設計を考える

前回までの記事で整理した「メモアプリのタグ機能」を例に、DB設計を進める流れを紹介します。

整理済みの要件は以下の通りです。

- メモにタグをつけられる
- 1つのメモに複数のタグをつけられる
- タグの作成・削除・絞り込みが必要
- タグはユーザーが自由に作成できる

ステップ1：必要なデータを洗い出す

まず、この機能で「保存が必要なデータ」を整理します。

【質問例】
メモアプリにタグ機能を追加します。
以下の要件をもとに、必要なテーブルとカラムを洗い出してください。

【要件】
- メモにタグをつけられる
- 1つのメモに複数のタグをつけられる
- タグはユーザーが自由に作成・削除できる
- タグでメモを絞り込める

既存テーブルとして、memosテーブル（id, title, body, created_at, updated_at）があります。

Claude Codeが以下のような提案を返してくれます。

【提案例】

■ tagsテーブル
- id（主キー）
- name（タグ名）
- created_at
- updated_at

■ memo_tagsテーブル（中間テーブル）
- id（主キー）
- memo_id（memosテーブルの外部キー）
- tag_id（tagsテーブルの外部キー）
- created_at

【テーブル間の関係】
- memosとtagsは多対多の関係
- memo_tagsが中間テーブルとして両者を結ぶ

この提案をベースに、認識のズレがないか確認していきます。

ステップ2：テーブルの関係を確認する

テーブルの関係が正しく理解できているか、Claude Codeに確認の質問をします。

【質問例】
memosとtagsが多対多になる理由を、初心者にもわかるように説明してください。
【質問例】
中間テーブルが必要な理由と、中間テーブルがない場合にどんな問題が起きるか教えてください。

設計の「なぜ」を理解しておくことで、後から構造を変更する判断もしやすくなります。

ステップ3：制約や考慮点を深掘りする

テーブル構成が固まってきたら、細かい制約や考慮点を確認します。

【質問例】
以下の点について、それぞれどう設計すべきか教えてください。

1. 同じユーザーが同じタグ名を重複して作れないようにするには？
2. タグを削除したとき、中間テーブルのレコードはどうすべきか？
3. メモを削除したとき、中間テーブルのレコードはどうすべきか？

Claude Codeが返す回答の例です。

【回答例】

1. タグ名の重複防止
   → tagsテーブルのnameカラムにUNIQUE制約を追加する
   → ユーザーごとに一意にする場合は、user_idとnameの複合UNIQUE制約を検討する

2. タグ削除時の中間テーブル
   → ON DELETE CASCADEを設定することで、tagsのレコード削除時にmemo_tagsも自動削除できる

3. メモ削除時の中間テーブル
   → 同様にmemosのid削除時もON DELETE CASCADEで対応できる

こうした細かい考慮点を、設計段階で潰しておくことが重要です。

ステップ4：設計をテキストで整理してもらう

テーブルの構成が固まったら、最終的な設計をテキストでまとめてもらいます。

【質問例】
ここまでの議論をもとに、最終的なテーブル定義をSQL形式でまとめてください。
制約や外部キーも含めてください。

Claude Codeが出力するSQL例です。

CREATE TABLE tags (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE UNIQUE INDEX idx_tags_name ON tags(name);

CREATE TABLE memo_tags (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    memo_id INTEGER NOT NULL,
    tag_id INTEGER NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (memo_id) REFERENCES memos(id) ON DELETE CASCADE,
    FOREIGN KEY (tag_id) REFERENCES tags(id) ON DELETE CASCADE
);

CREATE UNIQUE INDEX idx_memo_tags_memo_tag ON memo_tags(memo_id, tag_id);

このSQLを見ながら、

  • 意図通りの設計になっているか
  • 使用するDBやフレームワークに合っているか

を確認します。

ステップ5：別の設計案と比較する

設計には「唯一の正解」はありません。

別のアプローチがないか、Claude Codeに聞いてみます。

【質問例】
タグをテーブルで管理する方法以外に、メモのカラムにタグをテキストで保存する方法も考えられます。
両者のメリット・デメリットを比較してください。
【回答例】

■ テーブルで管理する方法（今回の設計）
メリット：
- タグの一覧取得・絞り込みが高速
- タグ名の変更が一箇所で済む
- データの整合性を保ちやすい

デメリット：
- テーブルが増える
- JOINが必要なクエリになる

■ テキストで保存する方法
メリット：
- シンプルで実装が早い
- テーブル設計が複雑にならない

デメリット：
- タグでの絞り込みが難しくなる
- タグ名を変更するとき全レコードを更新する必要がある
- データの整合性が崩れやすい

選択肢とトレードオフを整理することで、自分のプロジェクトに合った設計を選べます。

DB設計でClaude Codeを使うときの注意点

壁打ちを進める上で、意識しておきたいことがあります。

使用するDBに合った回答かを確認する

Claude Codeは汎用的な回答を返すことがあります。

MySQLとSQLiteでは構文や機能に差があるため、

SQLiteを使っています。この設計で問題ない点はありますか？

のように、使用するDBを明示して確認することが重要です。

フレームワークの制約も考慮する

RoomやLaravelなど、ORMやフレームワークを使っている場合は、
その制約も一緒に伝えます。

Roomを使ってAndroidアプリを開発しています。
この設計をRoomで実装する場合の注意点はありますか？

ツール固有の制約を踏まえた回答が返ってきます。

まとめ

Claude Codeを使ったDB設計の壁打ちのポイントをまとめます。

  • まず必要なデータを洗い出すところから始める
  • テーブルの関係と「なぜそうなるか」を理解する
  • 制約・削除時の挙動など細かい考慮点を潰す
  • 別の設計案と比較してトレードオフを理解する
  • 使用するDBやフレームワークを明示して確認する

DB設計は、後から変えると影響が大きい領域です。

「実装を始める前に、Claude Codeと一緒に整理する」

この習慣を持つことで、手戻りの少ない開発ができるようになります。

タイトルとURLをコピーしました