AIにデータベース設計案を作らせるプロンプト｜要件整理からテーブル・制約・SQLまで
このプロンプトは、業務要件からリレーショナルデータベースの設計案を作るためのものです。新規システムのたたき台が必要なエンジニアや、テーブル設計を学びながらレビュー観点を整理したい人に向いています。
大切なのは、いきなりCREATE TABLE文を書かせないことです。先に不足要件を洗い出し、その後でエンティティ、リレーション、制約、インデックスの順に検討させると、設計理由まで確認できる回答になります。
この記事で分かることは次のとおりです。
- コピペして使えるデータベース設計プロンプト
- 入力時に変更する項目と、固定したい指示
- 曖昧な依頼を改善する方法
- 設計案の精度を上げる追加プロンプト
- AIの回答を人が確認するときのチェックポイント
ここがポイント: AIの出力は完成設計ではなく、レビュー可能なたたき台として扱います。業務ルールやデータ量が欠けたままでは、もっともらしい設計でも運用時に破綻します。
このプロンプトで作る設計案
狙う成果物はSQLだけではありません。 テーブルを分けた理由や、削除時の扱い、未確定事項まで含む設計案を作ります。
想定する出力は次の順序です。
- 要件の整理
- 不足情報と確認質問
- エンティティ一覧
- テーブルごとのカラム、型、主キー
- テーブル間のリレーション
- 外部キー、NOT NULL、UNIQUE、CHECKなどの制約
- インデックス候補
- DDLのサンプル
- 設計上の判断理由と未確定事項
たとえば受注管理なら、単にordersテーブルを作るだけでは足りません。「注文後の商品名や単価を当時の値として保存するか」「顧客を退会処理した後も注文履歴を残すか」といった業務判断が設計を左右します。
AIにこの判断を任せきるのではなく、判断が必要な箇所を明示させることが、このテンプレートの中心です。
コピペ用プロンプトテンプレート
以下をコピーし、{}で囲まれた部分を書き換えてください。データベース製品が決まっていない場合は、{対象DB}を「未定」としても構いません。
あなたはリレーショナルデータベース設計を支援するシステム設計者です。
以下の業務要件を基に、レビュー用のデータベース設計案を作成してください。
# 目的
{このシステムで実現したいこと}
# 利用者と主な操作
- 利用者: {管理者、一般ユーザー、担当者など}
- 登録する操作: {例: 顧客登録、注文確定、入金記録}
- 検索する操作: {例: 顧客別の注文検索、月別売上集計}
- 更新・削除する操作: {例: 注文キャンセル、論理削除}
# 管理したいデータ
{分かっている項目、既存の帳票、CSV列、画面項目など}
# 業務ルール
{重複禁止、履歴保持、ステータス遷移、削除条件など}
# 規模と性能条件
- 想定件数: {1日当たりの登録件数、年間件数、保存年数}
- よく使う検索条件: {日時、顧客ID、ステータスなど}
- 同時利用者数: {分かる範囲で記載}
# 技術条件
- 対象DB: {PostgreSQL、MySQL、SQLite、未定など}
- 文字コード・タイムゾーン: {例: UTF-8、UTCで保存}
- ID方式: {連番、UUID、未定}
# 進め方
1. 最初に要件を要約してください。
2. 設計に必要な情報が不足している場合は、重要度順に確認質問を最大10件出してください。
3. 回答できない項目は勝手に確定せず、「仮定」として明記してください。
4. その後、仮定を置いた暫定設計案を作成してください。
5. テーブルを分割・統合した理由を説明してください。
6. 主キー、外部キー、NOT NULL、UNIQUE、CHECK、削除時の動作を検討してください。
7. 想定クエリを基にインデックス候補を示し、目的も説明してください。
8. 保存値から計算できる項目を重複保存する場合は、その理由と整合性維持の方法を示してください。
9. 個人情報、監査ログ、履歴保持で確認すべき点を挙げてください。
# 出力形式
以下の見出し順でMarkdownとして出力してください。
## 1. 要件の要約
## 2. 確認質問
## 3. 仮定
## 4. エンティティと役割
## 5. テーブル定義案
各テーブルについて、カラム名、型、NULL可否、既定値、キー・制約、用途を整理する。
## 6. リレーションと削除時の動作
## 7. 正規化と重複データの判断
## 8. インデックス候補
## 9. DDLサンプル
対象DBで実行可能なSQLをコードブロックで示す。
## 10. リスクと未確定事項
## 11. 人がレビューすべきチェックリスト
# 禁止事項
- 与えられていない業務ルールを確定事項として書かない
- 根拠なく全カラムへインデックスを作らない
- 外部キーの削除時動作を省略しない
- 個人情報や認証情報を平文保存する設計を提案しない
入力時に変える部分
設計品質を最も左右するのは、画面名ではなく業務上の動きです。 「注文管理画面を作る」だけでなく、注文がいつ確定し、誰が変更でき、何年間残るのかを書きます。
必ず入力したい項目
{目的}: 何を記録し、何を検索・集計したいか{利用者と主な操作}: 誰が登録、更新、参照、削除するか{管理したいデータ}: 既存CSVや帳票の列も含める{業務ルール}: 一意性、履歴、キャンセル、削除の条件{規模と性能条件}: 件数、保存期間、頻出検索{対象DB}: 型やDDLの方言を決めるために必要
入力項目がまだ固まっていなければ、「現在分かっていること」と「未決定事項」を分けて貼り付けます。AIに空白を埋めさせるのではなく、確認質問を作らせるためです。
固定したい指示
次の指示は、案件が変わっても残しておくと便利です。
- 仮定と確定要件を分ける
- テーブル分割の理由を書く
- 主キーだけでなく一意制約も検討する
- 外部キーの削除・更新時動作を示す
- インデックスごとに対象クエリを書く
- 未確定事項を最後に残す
PostgreSQLの公式文書でも、主キー、外部キー、NOT NULL、UNIQUE、CHECKはそれぞれ異なる役割を持つ制約として整理されています。型を決めるだけでなく、不正な状態をデータベース側でどう防ぐかまで指定する必要があります。
NG例と改善例
曖昧なプロンプトは、業務要件を無視した一般的なテーブル一覧になりがちです。
NG例
ECサイトのデータベースを設計してください。
テーブルとSQLも作ってください。
この依頼では、少なくとも次の点が不明です。
- 商品価格の変更後も過去の注文金額を再現するか
- 注文が複数の配送先に分かれるか
- 在庫を商品単位とSKU単位のどちらで管理するか
- 会員を削除した後も注文を保存するか
- ゲスト購入を認めるか
AIがこれらを推測すると、回答は整って見えても、実際の業務に合う保証がありません。
改善例
小規模ECサイトの注文管理用データベース案を作成してください。
確定している要件:
- 会員とゲストの両方が購入できる
- 1注文には複数の商品明細がある
- 商品名と販売単価は注文確定時点の値を履歴として残す
- 注文は物理削除せず、キャンセル状態で保持する
- 注文番号は重複不可
- 管理者は注文日、注文番号、メールアドレス、状態で検索する
- PostgreSQLを使用する
未決定:
- 複数配送先への対応
- 退会した会員と注文履歴の関連付け
- 在庫引当のタイミング
最初に未決定事項への確認質問を出し、その後に仮定を明記した暫定案を作成してください。
テーブル、カラム、主キー、外部キー、一意制約、削除時動作、インデックス候補、DDLを示してください。
改善点は、情報量を増やしたことだけではありません。確定事項と未決定事項を分離したことが重要です。これにより、AIは設計判断を事実のように扱いにくくなります。
出力を安定させる3つのコツ
安定した設計案には、入力、形式、確認手順の3点が必要です。
1. 業務イベントを時系列で渡す
静的な項目一覧だけでなく、データが変化する順番を書きます。
業務イベント:
1. 顧客が仮注文を作成する
2. 決済成功後に注文を確定する
3. 倉庫担当者が出荷を記録する
4. キャンセル時は理由と実行者を残す
5. 注文確定後の商品名と単価は変更しない
これにより、単なるマスタ一覧では見えないステータス、履歴、更新権限を検討できます。
2. 出力形式を段階化する
最初からSQLだけを求めると、前提の誤りがDDLに埋もれます。次の順番を固定するとレビューしやすくなります。
- 要件の要約
- 質問と仮定
- 論理設計
- 制約とインデックス
- 物理設計とDDL
OpenAIやGoogleの公式ガイドでも、明確で具体的な指示と、期待する出力形式を伝えることが基本として挙げられています。データベース設計では「詳しく」と頼むより、必要な見出しと確認観点を列挙する方が具体的です。
3. 正規化と検索性能を別々に検討させる
正規化は、重複や不整合を減らすためにテーブルと関係を整理する考え方です。一方、実務では検索速度や履歴再現のために、注文時の商品名のような値を意図的に保持する場合があります。
そこで、次の追加指示が役立ちます。
各重複カラムについて、次のいずれかに分類してください。
- 正規化により別テーブルを参照すべき値
- 履歴再現のため意図的に保存するスナップショット
- 性能上の理由で保持する派生値
後者2つは、元データとの不整合を防ぐ方法も説明してください。
「正規化されているか」だけで採点せず、重複を残す理由と更新方法まで確認するのが実務的です。
活用例と追加プロンプト
初回の設計案が出たら、目的別の追加プロンプトで検証します。同じ設計を言い換えさせるのではなく、別の角度から弱点を探します。
想定クエリからインデックスを見直す
この設計に対して、次の検索・更新処理を想定します。
{実行頻度付きのクエリ一覧}
各処理について、利用候補のインデックス、複合インデックスの列順、書き込みコストを説明してください。
根拠の薄いインデックスは提案しないでください。
外部キーを定義しただけで、参照する側の列に必要なインデックスがすべて自動作成されるとは限りません。PostgreSQLの公式文書も、参照元列へのインデックスは状況に応じて検討する必要があると説明しています。
異常系から制約を見直す
この設計で発生し得る不正データを10件挙げてください。
各項目について、次のどこで防ぐべきかを分類してください。
- データベース制約
- トランザクション制御
- アプリケーションの入力検証
- 運用ルール
データベース制約で防げるものはDDLの修正案も示してください。
要件変更への強さを確認する
次の要件変更が加わった場合の影響を分析してください。
{例: 1注文で複数配送先を扱う}
変更が必要なテーブル、カラム、制約、既存データの移行、APIへの影響を分けて示してください。
既存設計のまま対応する案と、再設計する案のトレードオフも比較してください。
AIの設計案を確認するチェックリスト
DDLが実行できることと、業務に合うことは別問題です。 最後は担当者が次の点を確認します。
- [ ] 確定要件とAIの仮定が区別されている
- [ ] 各テーブルに行を一意に識別する方法がある
- [ ] 業務上重複できない値にUNIQUE制約がある
- [ ] 必須項目のNOT NULLが検討されている
- [ ] 外部キーの削除時動作が業務ルールと一致する
- [ ] 多対多の関係が中間テーブルで表現されている
- [ ] 金額、日時、真偽値に適切な型が選ばれている
- [ ] タイムゾーンと日時保存方針が決まっている
- [ ] 履歴として残す値と常に最新を参照する値が分かれている
- [ ] 頻出検索に対応するインデックスの根拠がある
- [ ] 個人情報、認証情報、監査ログの扱いが確認されている
- [ ] バックアップ、保存期間、削除要求への対応が検討されている
- [ ] DDLを検証環境で実行し、制約違反のテストを行う予定がある
AIに設計を一度出させて終わるのではなく、まず確認質問に答え、次に異常系を洗い出し、最後に代表的なクエリで見直してください。次の分岐点は、実データ量と主要クエリが判明した時点です。 そこまで分かったら、インデックスや非正規化の判断を仮案のままにせず、実行計画と計測結果で確定させます。