なぜこう書くのか
AIにデータベース設計を依頼すると、通常は完成したテーブル定義の塊が一気に出力されます。一見整っているように見えますが、なぜそのカラムがそのテーブルにあるのかを検証する余地がなく、不備を見つけるには数十個のテーブル定義を最初からすべて読み直さなければなりません。
そこで、タスクをエンティティ → リレーション → テーブル定義という3つのステップに分けて進めます。エンティティ名だけを確認するステップ1の段階で「予約」と「施術履歴」が混ざっていることに気付けば、その場ですぐに修正でき、以降のステップも修正された前提で進められます。各ステップの終わりで止まるよう明記しないと、AIは1つの回答にすべてを詰め込んで出力してしまいます。
**聞き返し（逆質問）**を入れた理由は、テーブル設計がいくつかの前提条件によって大きく左右されるためです。予約キャンセルの際に履歴を物理削除するのか論理削除するのか、1人のユーザーが複数店舗を利用できるのかによってテーブル数が変わりますが、質問しないAIはこれらを勝手に決めてしまいます。最大3つに制限しているのは、質問ばかりが延々と続くのを防ぐためです。
出力形式でカラムごとに型や制約を明記させたのは、この表をそのままマイグレーションコードに落とし込めるようにするためです。主キーや外部キーが抜けた設計は、見た目が綺麗でも実装段階で必ず行き詰まります。「一覧にない機能のためのテーブルは作らない」という制約は、AIが気を利かせて勝手に追加しがちな通知・ログ・タグテーブルなどを排除するために機能します。
用語が分からなければAha AIで: prompt, chain-of-thought
悪い例との比較
美容室の予約アプリを作るんだけどDBのテーブル設計して
テーブル10個とそのカラム定義が一気に出力されます。問題は、それを検証する術がないことです。会員ランク・ポイント・クーポンといった指示していない機能のテーブルが混ざっていてももっともらしく見えて見過ごされ、肝心の無断キャンセル履歴をどこに持たせるかが抜け落ちたりします。1箇所直すとリレーションが連鎖的に崩れ、結局最初から聞き直すことになります。
バリエーション
出力された設計のレビューを依頼するとき
先ほど作成した{{データベース}}のテーブル設計を再確認し、潜在的な問題点になり得る箇所のみを指摘してください。「該当箇所・何が問題か・どのような状況で障害になるか・修正案」の表形式でまとめ、深刻度の高い順に最大5件まで出力してください。好みの問題に過ぎない命名規則などは指摘しないでください。
設計を受け取ったスレッド内で続けて使います。「最大5件」「好みの問題は除く」と指定しないと、些細な指摘が長々と続き、本当に重要な問題が埋もれてしまいます。
画面要件から逆算して整理するとき
私は{{サービスの説明}}サービスを開発する予定です。以下の機能一覧を読み込み、各機能の画面で何を表示すべきかから逆算して「機能・画面に必要なデータ・そのデータの取得元」の表形式で整理してください。テーブル設計はまだ行わず、表を作成した後に不足しているデータがないか確認の質問をしてください。
""" {{主要な機能}} """
機能一覧が粗削りで、すぐにテーブル設計に入るのが難しい場合に使います。画面に必要なデータを先に洗い出しておくことで、次の段階のテーブル設計の精度が格段に上がります。
モデル別の注意
ステップ1の回答を受け取った後、「次へ」とだけ送信すれば対話が続きます。新しいチャット画面で続ける場合は、前のステップの結果を再度貼り付ける必要があります。
ステップを分けて進めるプロンプトのため、対話が長くなります。ステップ3で前のステップと整合性の合わない表が出力された場合は、そこまでに確定したエンティティ一覧を再度貼り付けてから進めると確実です。ER図の描画を依頼するとモデルによってはアスキーアート等の線が崩れることがあるため、リレーションは「1人のユーザーが複数の予約を持つ」といった文章や表形式で出力させた方が確認しやすくなります。
関連プロンプト
最終更新 2026-09-02 · 誤りがありますか？ 知らせる