AIにDB設計を相談する｜前提の渡し方と鵜呑みにしない確認
「このテーブル分け方、これで合ってるのかな」 「後から列を足したくなったとき、困らないだろうか」
一人で設計していると、こういう迷いはなかなか消えませんよね。相談できる先輩がいればいいけれど、いつも隣にいるとは限らない。かといって、動き出してから作り直すのは骨が折れる。
そんなとき、AIはかなり頼れる壁打ち相手になります。テーブルの分け方、正規化、インデックスの当て方——設計の初期に「一人では気づけなかった観点」を出してくれます。
ただ、いきなり「ユーザー管理のテーブル設計を教えて」と聞くと、それらしいけれど、あなたの要件には合っていない案が返ってきます。AIは、あなたのシステムの事情を知らないからです。
この記事は、AIにDB・テーブル設計を相談するときの前提の渡し方と、返ってきた案を鵜呑みにしないための確認をまとめたものです。長く見えますが、全部は要りません。まず効く所から拾えば回ります。
30–60秒のファストパス（最低ライン）
- 前提を3つ添える：何を保存するデータか／どんな検索・更新が多いか／規模（件数の桁）を先に伝える（30秒）
- 一発で決めない：「唯一の正解」ではなく「案を2つ、それぞれの向き・不向き付きで」と頼む（10秒）
- 一点だけ確かめる：返ってきた案の主キーと、よく検索する列にインデックスがあるかだけ自分の目で見る（20秒）
※本物の個人情報・実データは貼らない。列名や構造だけを渡せば十分。
結論：AIへのDB設計相談は、「正解を出してもらう」のではなく「前提を渡して、選択肢を一緒に並べてもらう」もの。まず効くのは、①保存するデータ・主な操作・規模の3点を先に渡す → ②唯一解でなく「案を2つ＋向き不向き」で出させる → ③主キー・外部キー・インデックス・NULL可否を自分の目で確認 → ④将来の変更（列追加・件数増加）に耐えるかを聞き返す。AIは設計の視野を広げる相棒であって、あなたの要件を保証する人ではありません。
AIに相談するのは、判断を丸投げするためではありません。 一人で堂々巡りする時間を減らして、「自分の要件だとどれが効くか」を落ち着いて選ぶためです。
なぜDB設計は、AIと相性がよく・同時に危ういのか
AIは、一般的なDB設計の定石をよく知っています。「ユーザーと注文は分ける」「多対多は中間テーブルで」「更新が多い列は正規化する」——教科書的な観点を、素早く並べてくれます。設計の初期に視野を広げるには、とても向いています。
危ういのは、DB設計に「唯一の正解」がないことです。良い設計は、必ずそのシステムの事情に依存します。
- 何を保存するか：扱うデータの性質で、テーブルの切り方は変わる
- どう使うか：読み取りが多いのか、書き込みが多いのか、どんな検索をするか
- どれくらいの規模か：数百件と数千万件では、正しい設計がまるで違う
- これからどう育つか：後から足したくなる項目、増えていく利用者
前提を渡さないと、AIはこの空白を「よくあるケース」で勝手に埋めます。だから、それらしいのに自分の現場では扱いにくい設計が返ってくる。逆に言えば、前提さえ渡せば、AIは一気に頼れる相談相手になります。次から、その渡し方です。
相談する前に渡す「4つの前提」
聞き方を変える前に、AIに渡す前提を用意します。ここが揃うだけで、返ってくる案の当たり方が大きく変わります。
①何を保存するデータか
まず、扱うデータそのものを言葉にします。「会員」「注文」「在庫」——どんな実体を、どんな項目で持ちたいのか。具体例が1〜2件あると、AIは構造をつかみやすくなります。このとき本物の個人情報や実データは貼らないこと。項目名（列名）とデータの型がわかれば十分です（→社内データをAIに渡すときの線引き）。
②どんな操作・検索が多いか
DB設計は「どう使うか」で決まります。「会員をメールアドレスで検索することが多い」「注文履歴を日付範囲で絞る」「在庫は頻繁に更新される」——こうした主な読み書きのパターンを渡すと、AIはインデックスや正規化の度合いを現実的に提案できます。
③どれくらいの規模か
件数の桁を伝えます。数百件で済むのか、数百万件まで増えるのか。ここが抜けると、AIは「教科書的に正しいが、この規模には過剰（あるいは不足）」な設計を出しがちです。おおよその桁だけでも大きな手がかりになります。
④これから何が増えそうか
分かる範囲で、将来の変化も添えます。「後から会員ランクを足すかもしれない」「多言語対応が入るかも」。今すぐ作り込む必要はありませんが、AIに伝えておくと、拡張しやすい切り方を意識した案が返ってきます。
AIに設計を相談する4つの手順
前提が用意できたら、聞き方を工夫します。ここでも「一発で正解を出させない」のがコツです。
手順1：唯一解でなく「案を2つ＋向き不向き」で出させる
いきなり「最適なテーブル設計を教えて」と聞くと、AIは1つの案を断定的に返してきます。そうではなく、選択肢を並べてもらいます。
次の前提でテーブル設計を考えています。（①何を保存 ②主な操作 ③規模 ④将来の変化 を貼る）
設計案を2パターン出して、それぞれについて「向いているケース」と「向かないケース」も添えてください。
こう頼むと、正規化を効かせた案と、あえて崩して読み取りを速くした案、といったトレードオフ込みの比較が出てきます。判断は自分がする、その材料をもらう、という関係にできます（→AIにアーキテクチャ案を出させて鵜呑みにしない比較の型）。
手順2：主キー・外部キー・型・NULL可否を明示させる
設計案が出たら、ふわっとした箱と線で終わらせず、細部を詰めさせます。
各テーブルについて、主キー、外部キー（参照関係）、各列のデータ型、NULLを許すかどうかを表にしてください。
ここは後から効いてくる地味な部分です。主キーの取り方、外部キーで参照整合性をどう守るか、日付や金額の型、NULLを許すかどうか——ここが曖昧なまま実装に進むと、あとで直しにくくなります。
手順3：検索パターンからインデックスを相談する
手順1で渡した「主な操作」をもう一度使って、インデックスを詰めます。
先ほどの主な検索・更新パターンに対して、どの列にインデックスを張るべきか、理由付きで教えてください。張りすぎの弊害も教えてください。
インデックスは、あればあるほど良いわけではありません。検索は速くなる一方、書き込みは重くなります。AIに「張るべき所」と「張りすぎの弊害」を両方出させると、バランスを考えやすくなります。設計段階でN+1になりやすい構造にも早めに気づけます（→AIにSQLを書かせたときの確認ポイント）。
手順4：将来の変更に耐えるか聞き返す
最後に、育てる目線で一度ゆさぶります。
この設計で、後から「会員ランク」を追加したくなったら、どこをどう変えることになりますか。テーブル構造を大きく壊さずに対応できますか。
「後から列を1本足すだけで済む」のか「テーブルを分け直す大工事になる」のか。ここを先に確かめておくと、動き出してからの作り直しを減らせます。
返ってきた案を鵜呑みにしないために
AIの設計案は、説明が滑らかなほど正しく見えます。でも、滑らかさと、あなたの要件に合っているかは別の話です。実装に移す前に、この点だけ確かめておくと事故を防げます。
- 存在しない機能・構文を、それらしく使っていないか（使っているDBにない機能を前提にしていないか。もっともらしい誤り＝ハルシネーションに注意 →AIのハルシネーションの見抜き方）
- 自分の使うDBの版・種類に合っているか（PostgreSQLとMySQL、古い版と新しい版で使える機能が違う。AIが別物の前提で書いていないか）
- 正規化しすぎ・崩しすぎになっていないか（きれいすぎて結合だらけ、あるいは重複だらけで更新が大変、どちらにも寄りすぎていないか）
- 提案の「なぜ」を自分の言葉で説明できるか（理由を飲み込めない設計は、後で自分が保守できない。分からない所はその場で聞き返す）
全部を採点する必要はありません。自分の要件と照らして「腑に落ちるか」を基準に、合わない所は遠慮なく捨てて構いません（→AIレビューの指摘を取捨選択する判断軸）。
そのまま使えるチェックリスト
- 何を保存するデータか（項目名・型・具体例）を渡したか
- 主な検索・更新パターンを渡したか
- 規模（件数の桁）を伝えたか
- 本物の個人情報・実データを貼らずに、構造だけで相談したか
- 「唯一解」でなく「案を2つ＋向き不向き」で出させたか
- 主キー・外部キー・型・NULL可否を明示させたか
- 検索パターンに対するインデックスを、張りすぎの弊害込みで相談したか
- 将来の列追加・規模増加に耐えるか聞き返したか
- 使っているDBの種類・版に合っているか確かめたか
- 提案の「なぜ」を自分の言葉で説明できるか確かめたか
明日やること
いきなり全テーブルを設計し直そうとしなくて大丈夫です。 明日は、いま一番迷っている1テーブルだけを選んで、「何を保存するか・どう使うか・どれくらいの規模か」の3つをメモにしてからAIに相談してみてください。前提を渡すだけで、返ってくる案の当たり方がまるで変わるのを実感できるはずです。
DB設計は、一度で完璧な正解を出す仕事ではありません。 前提を渡して、選択肢を並べて、自分の要件で選ぶ。その積み重ねで、迷いは少しずつ「判断」に変わっていきます。一人で抱え込まなくて大丈夫です。