2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIが出したテーブル設計、そのまま採用していませんか? リレーションを見る目を養う3つの質問

2
Posted at

はじめに

Claude Codeに「ブログアプリのDB設計をして」と頼むと、それらしいテーブル定義がすぐに返ってきます。動くコードも一緒に生成してくれるので、そのまま採用してしまいがちです。

ただし、動くこと設計が妥当なことは別の話です。特にテーブル同士の関係(リレーション)は、最初のデータ量が少ないうちは設計のまずさが表に出にくく、後から気づいて直そうとすると、既存データの移行という重い作業が発生します。

本記事では、AIが出したテーブル設計をレビューするときに使える3つの質問を、Before/Afterの具体例とセットで紹介します。

飽和ぎみの「AIにどこまで任せるか」という線引きの話ではなく、任せた結果を評価する目の話です。多対多をどう頼むか(=AIに渡す前の話)ではなく、指定しなかった、あるいは気づかないまま返ってきた設計を、後からどう見抜くかに焦点を当てます。

Before: それらしいが、危ういテーブル設計

「投稿にタグをつけたい」という要件で、AIに設計を頼むと、こういうテーブルが返ってくることがあります。

CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  body TEXT,
  tags TEXT  -- 例: "React,Next.js,初心者"
);

一見シンプルで、動きます。投稿を保存するときに tags 列にカンマ区切りの文字列を入れておけば、表示もできます。

しかし、この設計には次の欠陥があります。

  • 「Reactタグが付いた投稿を一覧で取得する」というよくある操作が、LIKE '%React%' のような曖昧な文字列検索になる(ReactNative にも誤ってヒットする)
  • タグの一覧(重複なしの全種類)を取得しようとすると、全投稿の tags 列を読み込んで自前で分解・重複除去する必要がある
  • タグ名を「React」から「React.js」に変えたいとき、該当する全投稿の tags 列を書き換える必要がある

これは、1件のテーブルに情報を詰め込みすぎたときに典型的に起きる問題です。

After: 中間テーブルで関係を切り出す

同じ要件を、テーブルを分けて設計するとこうなります。

CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  body TEXT
);

CREATE TABLE tags (
  id SERIAL PRIMARY KEY,
  name TEXT UNIQUE NOT NULL
);

CREATE TABLE post_tags (
  post_id INTEGER REFERENCES posts(id),
  tag_id INTEGER REFERENCES tags(id),
  PRIMARY KEY (post_id, tag_id)
);

post_tags が「投稿とタグの組み合わせ」だけを持つ中間テーブルです。これで、

  • 「Reactタグの投稿一覧」は tags.name = 'React' から post_tags 経由で posts を辿るだけの、正確なJOINになる
  • タグの一覧は tags テーブルを見るだけで取得できる(重複除去の自前実装が不要)
  • タグ名の変更は tags テーブルの1行を直すだけで、全投稿に反映される

「1つの投稿が複数のタグを持ち、1つのタグが複数の投稿に付く」という多対多の関係は、間に中間テーブルを1枚挟むことで表現する。これがリレーション設計の基本パターンの1つです。

AIの設計をレビューするときの3つの質問

コードが返ってきた時点で採用を決めず、次の3つを自分に(あるいはAIに)問いかけると、Before側のような欠陥に事前に気づきやすくなります。

  1. 「この2つの情報は、何対何の関係になっていますか?」
    1対1・1対多・多対多のどれかを言葉にできないなら、テーブル設計はまだ固まっていません。

  2. 「同じ情報が、複数の行にまたがって重複して保存されていませんか?」
    Before側の tags 列は、まさにこれです。重複が起きる列は、別テーブルに切り出す候補です。

  3. 「この列で検索や絞り込みをすることは、今後ありそうですか?」
    将来の検索条件になりそうな情報が、他の列と一緒に1つのセルへ詰め込まれていないか確認します。

Claude Codeに設計を頼むときも、出力をもらった直後にこの3つを聞き返すだけで、「それらしいが危ういテーブル」を採用してしまう前に気づけます。

まとめ

  • AIが出すテーブル設計は、動くことと妥当なことが必ずしも一致しない
  • 特に「1対多」「多対多」のリレーションは、最初のデータが少ないうちは問題が表面化しにくい
  • 「何対何か」「重複していないか」「検索条件になりそうか」の3つを聞くだけで、設計レビューの精度は上がりやすくなる

未経験者向けの講座を運営しています

未経験から Next.js + Supabase + Claude Code で Webアプリを公開するまで を、全20セッションで体系化した教材です。Claude Code を学習パートナーにする CLAUDE.md と学習モード(learner / developer)の設計までセットで含みます。

※ Qiita読者の方には易しすぎる内容なので、初心者の知り合いへの紹介や社内研修の参考としてどうぞ。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?