AI設計でDB設計はどこまで任せる？役割分担の考え方

AIにDB設計や画面設計を任せると、どこまで使えて、どこから人が決めるべきなのか。この記事では、設計工程の作業を「AIが得意なもの」と「人が判断するもの」に分けて整理します。新規事業のシステムを検討するときに、任せる範囲を決める軸と、設計の品質を確かめる方法まで分かります。

設計工程で「AIに任せる」とは何を指すのか

設計は、要件定義で決めた「何を作るか」を、「どう作るか」という具体的な形に変える工程です。代表的なものに、DB設計、画面設計、API設計があります。DB（データベース）とは、システムが扱うデータを整理して保存しておく仕組みのことです。DB設計では、どんなデータを、どんな構造で持つかを決めます。

「AIに任せる」と言っても、関わり方には段階があります。

• 叩き台を作らせて、人が選んで直す
• 複数の案を出させて、人が比較する
• 人が決めた方針に沿って、細部をAIに埋めさせる
• 人が作った設計を、AIにレビューさせる

設計全体を丸ごと預けるのと、案出しやチェックに使うのとでは、意味がまったく違います。私たちの考えでは、現実的な線引きは「作業はAI、判断は人」です。文章を構造に変える、抜けを洗い出す、案を並べるといった作業はAIが力を発揮します。一方で、事業としてどちらを選ぶかという判断は、人が持ち続ける必要があります。

AI駆動開発全体での役割分担は、AI駆動開発とは｜AIと人の役割分担と発注側の要点で整理しています。設計の前段にあたる要件定義については、AI要件定義で変わること｜AIが整理し人が決める範囲も参考になります。

DB設計：AIに任せやすい作業と人が決めること

AIに任せやすい作業

DB設計では、次のような作業がAIに向いています。

• 要件の文章から、テーブル（データの表）、項目、テーブル同士の関係の初期案を作る
• ER図（データ同士の関係を表した図）を、テキストの記法で書き出す
• 項目名の命名ルールをそろえ、型や制約の候補を挙げる
• インデックス（検索を速くするための索引）の候補を挙げる
• 設計の抜けや矛盾を指摘する
• 複数の構造案について、長所と短所を整理する

どれも「文章で書かれた内容を、決まった形式の構造に変換する」作業です。人が一から手で書くと時間がかかる部分なので、AIの助けが大きい領域といえます。

人が決めること

一方で、事業のルールに関わる判断は人の仕事です。

• 履歴を残すか、上書きするか：料金を改定した後でも、過去の注文金額をそのまま再現できる必要があるか
• 削除の扱い：退会した人のデータを消すのか、個人が特定できない形にして残すのか。法令や規約の確認も関わる
• データの単位：1人のユーザーが複数の組織に属するのか、1契約につき1アカウントなのか
• 将来への備えの度合い：課金方式の追加や対象地域の拡大に、どこまで先回りして備えるのか
• 保管する個人情報の範囲：事業に必要な情報だけに絞るのか

たとえば会員制のサービスで、「会員」と「契約」を同じテーブルにまとめるか、分けるかを考えます。最初は1人が1つの契約を持つだけなので、まとめても問題なさそうに見えます。ところが後から法人向けのプランが加わり、1社で複数人が使う形になると、構造そのものの見直しが必要になることがあります。

AIは、こうした場面で「よくある形」を示すことはできます。しかし、この事業が1年後にどちらへ進むのかは、事業を考えている人にしか決められません。AIが出した案が整って見えても、その前提が事業の実態と合っているかは、人が見極める部分です。

DB設計は後から変えにくい

DB設計には、もう一つ注意点があります。データがたまった後に構造を変えるには、既存データの移行作業が必要になり、手間もリスクも大きくなります。画面の見た目を直すより、はるかに重い変更です。そのため、DB設計では人の判断を厚くしておくのが基本になります。

画面設計：叩き台はAI、使う場面の判断は人

AIに任せやすい作業

画面設計では、AIは次のような作業に力を発揮します。

• 必要な画面の一覧の洗い出し
• 画面の遷移図の作成
• ワイヤーフレーム（画面の骨組みを示した簡単な図）の叩き台づくり
• 入力項目と入力チェックの整理
• エラーメッセージや案内文の文案づくり
• 「読み込み中」「データがない」「エラー」といった状態の抜け漏れの確認

最近は、設計だけでなく、画面の実装まで一続きで進められるようになってきました。案を短時間で複数出せるので、「まず動くものを見てみる」という進め方と相性がよい領域です。

人が決めること

画面設計で人が決めるのは、次のような点です。

• 誰が、どんな場面で、何のために使うのか
• 最初に使ってもらう操作は何か
• 画面や機能をどこまで絞るのか
• 事業の価値が、使う人にきちんと伝わる体験になっているか

特に、実際に触ってみて「これは違う」と言えるかどうかは、人にしかできない判断です。画面は、文書や図だけでは良し悪しを評価しにくく、動くものを触って初めて気づくことが多くあります。実物を見ながらすり合わせる意義は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも触れています。プロトタイプの位置づけは、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分けで整理しています。

画面は、DBに比べて変更しやすい部分です。そのため、AIに案をたくさん出させて試し、人が選ぶという使い方が向いています。

画面とDBはつながっている

画面とDBは、別々に考えられません。画面の入力項目は、データの構造にそのままつながるからです。画面だけを先に作ると、後から「必要なデータを持っていなかった」ということが起こります。AIに設計を任せる場合も、画面とDBで同じ前提を共有させ、整合を確かめる場面を設けておく必要があります。

任せる範囲を決める3つの判断軸

作業ごとに、AIにどこまで任せるかを決めるには、次の3つの軸が使えます。

1. 戻しやすさ：後から変えるのにどれだけ手間がかかるか。変えにくいものほど、人が慎重に決める
2. 事業固有性：一般的なパターンで足りるか、この事業ならではの判断が必要か。固有性が高いほど、人の判断が中心になる
3. 確かめやすさ：動かしたり見たりして、良し悪しを確認できるか。確かめやすいものは、AIの案を試しながら進めやすい

この3つを当てはめると、次のように整理できます。

作業	戻しやすさ	AIの関わり方	人の関わり方
テーブル・項目の初期案	低い	叩き台を作る	事業ルールに照らして選ぶ
履歴・削除・権限の方針	低い	選択肢と影響を整理する	方針を決める
画面一覧・遷移図	高い	案を複数出す	使う場面から絞る
ワイヤーフレーム	高い	叩き台を作る	実物を触って判断する
入力チェック・文言	高い	案を作る	事業の言葉に合わせて直す

戻しにくく、事業固有性が高い判断ほど、人が前に出る。戻しやすく確かめやすい作業ほど、AIに広く任せる。この考え方を持っておくと、設計の場面ごとに迷いにくくなります。

AIに設計を任せるときの落とし穴と確認方法

AIは設計の作業を速く進めてくれますが、使い方によっては次のような問題が起こります。

• もっともらしさと正しさは別：AIは一般的なパターンをもとに、整った案を作ります。ただし、事業の事情に合っているかどうかは別の話です
• 書かれていない前提の補完：要件に書かれていない項目を足したり、逆に権限の扱いのような大事な点を省いたりすることがあります
• 設計書どうしのずれ：用語や項目名が、画面の設計書とDBの設計書で食い違うことがあります。やり取りが長くなると、前に決めた内容が反映されないこともあります
• 個人情報や権限の扱い：誰がどのデータを見られるか、どの情報を保護するかは、確認が欠かせません
• 判断の理由が残らない：なぜその構造にしたのかが残っていないと、後の改修や引き継ぎで困ります

こうした点への対策は、特別なものではありません。

• 決めた方針とその理由を、短い文章で記録しておく
• 設計を人がレビューし、説明できる状態にしておく
• 画面とDBの整合を、節目ごとに確かめる
• 動くものを早い段階で作り、実際に触って確認する

セキュリティの観点はAI生成コードのセキュリティ｜確認点と人の役割、機密情報の扱いは生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで詳しく扱っています。後の保守に関わる点はAI生成コードの保守は可能か｜引き継ぎと改修の確認点が参考になります。AIが関わる開発で人の確認が必要な理由は、AI開発でも品質には人の確認が必要な理由にまとめています。

発注側が設計の品質を確かめる方法

新規事業に取り組む会社の担当者が、DB設計の中身をすべて読み解く必要はありません。ただ、設計の品質は、次のような質問で確かめられます。

• 主要なデータ（たとえば会員、注文、契約）が何で、互いにどう関係するのかを、図と言葉で説明してもらえるか
• 履歴、削除、権限の扱いは、誰がどう決めたのか
• 今後変わりそうな点（料金やプランなど）に、どこまで備え、どこは備えないと決めたのか
• 設計のうち、AIが作った部分と、人が確認した部分は分かれているか
• 後から仕様が変わったときに、影響する範囲を説明してもらえるか
• 設計の段階で、動くものを見る機会があるか

説明が文章や図で返ってくるかどうかは、設計に人の判断が入っているかを見る手がかりになります。AIを使った受託開発を依頼する際の確認点は、AI受託開発に依頼する前に確かめたい6つのことにまとめています。要件の抜け漏れを防ぐ進め方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。

新規事業では、最初から大きな設計を作り込まないことも大切です。最初に作る範囲を絞る考え方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準で、システムと事業モデルを合わせて考える視点は、新規事業のシステム設計とビジネスモデルの作り方で扱っています。

まとめ

AIに設計を任せるときの要点は、次のとおりです。

• 設計の作業（叩き台づくり、案の比較、抜けの指摘）はAIが得意で、判断は人が担う
• DB設計は、後から変えにくく事業の判断が関わるため、人が決める部分を厚くする
• 画面設計は、変更しやすく試しやすいので、AIに案を多く出させ、実物を触って人が選ぶ
• 任せる範囲は、戻しやすさ、事業固有性、確かめやすさの3つの軸で考える
• 判断の理由を記録し、人がレビューし、早い段階で動くものを確認する

JustFitは、AIを活用した独自の開発基盤「LAF」を使っています。LAFでは、要件定義・設計・DB設計・実装・テスト・レビューといった工程ごとに役割を持つ専門AIがチームとして開発を進め、人は「何を作るかを決めること」と「品質の最終判断」を担います。構想をもとに、約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる進め方です。設計の分担や進め方に関心をお持ちでしたら、JustFitのサービス紹介をご覧ください。