データベース設計AIで詰む中小企業3つの落とし穴｜本音と回避の判断軸

「ER図は生成AIに出させて、あとはそのまま流し込めば終わる」——中小企業の業務システム案件で、こうした判断が珍しくありません。実装1ヶ月後にデータの欠損・整合性破綻・度重なる仕様変更で身動きが取れなくなり、DB設計をまるごと作り直す現場が静かに増えています。

この記事では、データベース設計をAIに丸投げした中小企業の業務システム案件で繰り返し詰む3つの落とし穴と、AIに任せていい工程・人間が責任を持たなきゃいけない工程の切り分け、回避するための判断軸を整理します。

なぜ中小企業のDB設計はAI丸投げで詰むのか

本記事のテーマに関連するサービスとして、BoostXではIT/Web企業の支援を提供しています。

中小企業の業務システム案件では、DB設計に十分な工数を割けないまま、生成AIに「業務をヒアリングしてER図を出して」と頼むケースが目立ち始めています。背景には、専任のデータベース設計者がいない・要件定義がきれいに書面化されていない・社内に過去設計の知見が文書として残っていない、という3つの構造課題があります。AIは入力された情報の範囲でしか設計できないため、入力が雑なら出力も雑になる、というシンプルな構造です。

私はBoostXで生成AI伴走顧問として、中小企業のAI導入と業務自動化を一気通貫で支援しています。その中で、データベース設計を生成AIに任せようとして詰むパターンには共通点があります。発注側がAIを「優秀な設計者」と認識してしまい、設計責任を曖昧にしたままER図を信用し、実装が走り出してから取り返しがつかなくなる、という流れです。

「設計責任の所在」が曖昧になることが詰みの入口

DB設計AIが出した結果に対して、誰がレビューして・誰がGOサインを出して・誰が後で責任を取るのか、を最初に決めていない案件は高い確率で詰みます。AIは責任を取れないので、人間側にレビュー責任者が必要です。中小企業では「とりあえずエンジニアに見せた」「とりあえず社長が見た」レベルで止まり、設計責任が誰にもない状態でテーブルが走り出すケースが少なくありません。1〜2名規模のシステム担当者しかいない中小企業ほど、この役割分担の曖昧さが運用3〜6ヶ月後にデータ整合性のずれとして表面化します。

設計責任の所在が決まっていない案件では、リリース後3ヶ月〜6ヶ月の間に「このカラム値どっちが正？」「このマスタは誰が更新する？」という問いが社内で必ず1日に1〜2回発生します。聞かれた側はAIが出した設計を理由に答えられず、データの矛盾が積み上がり、半年後に「データが信頼できない」状態に陥ります。設計責任者1名・運用責任者1名・データ監査責任者1名の3名を、ER図確定の前に書面で決めておくこと。これだけで運用後の詰みリスクが大きく下がります。

業務理解が一次情報として揃っていないままER図を出している

DB設計の前段にあるべき業務フロー・データの発生源・更新タイミング・正規化の判断材料が、一次情報として揃わないまま「AIに聞けば」と進む現場が多くあります。これはAIの問題ではなく、入力データの問題です。生成AIに渡せる業務情報が3割しかなければ、出てくるER図の精度も3割を超えません。これは、私が建設業の見積もり案件で繰り返し採用している考え方そのものでもあります。「AIは優秀な検索係であって、設計の責任者ではない」「ゴミを入れればゴミが出る」という原則がDB設計でも同じ構造で効いてきます。

業務情報の一次インプットが不足するとどうなるか。典型的には、ER図のテーブル数は20〜30個と十分に見えるのに、実装3ヶ月後に「現場で発生している伝票が漏れていた」「1日あたり50〜100件流れる業務イベントが想定外だった」「月末月初の集中処理で1日2000件のレコードが入る」などの後出し情報で、テーブル設計の見直しが2〜3回入ります。1回の手戻りで実装工数が10〜20%増えるため、3回入れば当初見積もりの1.3〜1.6倍まで膨らみます。AIに渡す前に、業務担当者3〜5名に対する10〜20時間のヒアリングと、業務イベントの発生件数の概算を必ず手元に揃えておくこと。

データベース設計AIで本当にできることの範囲

データベース設計AIに任せられる範囲を、現実的なラインで切り直します。結論を先に言えば、ER図のドラフト・テーブル名と命名の候補出し・正規化観点のチェック・サンプルSQLの生成までは、生成AIに任せる価値が十分あります。一方で、業務要件のヒアリング・データの実発生現場の観察・将来の業務変更を見越した設計判断・本番運用での保守責任は、人間側に残さなきゃいけません。

この領域でつまずきやすいのは、ツール選定よりも「業務の中のどこに組み込むか」の設計です。BoostXの業務自動化サービスは、業務ヒアリングから設計・定着支援までをサービス対応範囲としてカバーできる領域です。

AI側に寄せていい4つの工程

第一に、業務ヒアリングメモから一次案のER図と主要テーブルのカラム候補を出すドラフト工程は、生成AIが最も得意な領域です。30分かけて手で書く設計書ドラフトが10分でたたき台になります。第二に、テーブル名・カラム名・命名規則の統一は、AIが過去の命名規約を踏まえて候補を5案出すのが速く、人間は選ぶだけで済みます。第三に、第3正規形までの正規化観点で「ここは別テーブルに切り出せる」「ここは冗長な気がする」というレビュー視点の提示は、AIの方が網羅性で勝ります。第四に、サンプルSQL・サンプルマイグレーションの叩き台生成も、AI側で十分です。

人間側に残さなきゃいけない4つの工程

第一に、業務の実発生現場を見て「この入力は本当に1日に何件発生するのか」「この項目は将来も使うのか」「ここは別ロールが触るのか」を、肌感覚で判断する工程は人間にしか務まりません。第二に、将来の業務変更を見越した設計判断、たとえば「3年後にこの業務が分社化されるかも」「来期から多拠点運用になる」といったビジネス文脈は、AIの学習データには含まれません。第三に、運用フェーズで誰がメンテし・誰がデータ品質を担保し・誰が監査を受けるかを決める設計責任は、当然AIには取れません。第四に、セキュリティ要件・個人情報保護法・業界規制対応の最終判断は、人間が責任を持って下す領域です。

中小企業のDB案件で詰む3つの落とし穴

ここからは、生成AIにDB設計を任せて詰む中小企業案件で繰り返し見られる3つの落とし穴と、それぞれの構造的な原因を整理します。どれも「AIが弱い」のではなく、「AIへの入力情報と運用責任の設計が甘い」ことが本質です。

落とし穴1：業務ヒアリングを省いて出力されたER図をそのまま採用してしまう

最も多いのが、現場の業務ヒアリングを2〜3時間しか取らず、生成AIに「だいたいこんな業務です」と要約を渡してER図を出させ、そのまま実装に進む流れです。実装が3割進んだ段階で「現場の伝票はこっちも紐づいていた」「この項目は別部署も更新する」「この日時はタイムゾーンが2種類ある」といった抜けが露呈し、テーブル設計を作り直す羽目になります。業務ヒアリングは、AIが代行できない人間の責任工程です。1案件で最低でも10〜20時間はかけて、複数ロールの担当者の手元を見せてもらう必要があります。

中小企業のIT・業務開発まわりで、業務ヒアリングを後工程に回すと何が起きるか。実装フェーズで毎週1〜2件の仕様変更が走り、4週間で5〜8件の手戻りが積み上がります。1件の手戻りでテーブル変更・マイグレーション・テストデータ作り直しに2〜4時間かかるため、月で見ると20〜30時間が無駄工数として消えます。これはAIが悪いのではなく、AIに渡すべき業務情報の解像度が低いまま走り出した運用設計の問題です。AI導入の前に、業務ヒアリングの工数を当初の3〜5倍に確保するのが現実的な判断軸になります。

落とし穴2：将来の業務変更が反映されないまま固まる

生成AIは現時点の業務情報からER図を出すため、「来期から多拠点になる」「3年後に分社化が予定されている」「将来は外部取引先もこのデータを参照する」といったビジネスの先読みが反映されません。中小企業ほど、組織変更・事業分割・外部連携の発生頻度が高く、3年先までを見据えた設計判断が必要です。AIが出したER図に対して、経営者と現場リーダーが将来の業務変更を5〜10個書き出し、設計に反映するレビューを必ず挟むこと。これだけで詰む確率が大きく下がります。

将来予測のレビューは、社内の経営層1名・現場リーダー2〜3名で1〜2時間の議論を持つだけで、十分な精度になります。論点は、3年以内に発生しうる組織変更・拠点追加・取引先連携・外部システム接続・データ保管要件の変化の5項目です。それぞれに対して「発生確率はどれくらいか」「発生した場合DB設計のどこに影響するか」を1行ずつメモすれば、ER図に組み込むべき柔軟性が見えてきます。AIに渡し直すと、その柔軟性を盛り込んだ第2案が10〜15分で返ってくるため、人間の判断時間は短く・かつ精度の高いレビューが可能になります。

落とし穴3：レビュー責任者と運用責任者が決まっていない

生成AIが出したER図に対して、誰が最終GOを出すのか・誰が運用後にデータ品質を保つのかが決まっていない案件は、ほぼ100%の確率で運用に入ってから揉めます。中小企業では役割が兼務になりがちで、「誰となく」設計が固まり、本番運用後に「これ誰が決めたの」状態に陥ります。最低でも、レビュー責任者1名・運用責任者1名・データ監査責任者1名の3名を明示しておくこと。生成AIの利点は速度ですが、責任の所在は人間側で構造化しておく必要があります。

3名の責任者を立てるとき、兼務はリスクです。レビュー責任者と運用責任者を同一人物にすると、設計時の判断と運用時の負荷判断が同じ目線になり、設計時に「あとで楽だから」を理由に重要な制約を緩めてしまうケースが頻発します。データ監査責任者は経理や情報セキュリティ管理者など、システム部門外の第三者を当てるのが基本です。3名体制が組めない規模なら、外部の生成AI伴走顧問や設計レビュアーを1名挟むのが現実的な代替案になります。月1〜2回・1回30〜60分のレビュー会を持つだけでも、運用後3〜6ヶ月のデータ品質劣化は大きく抑えられます。

AI＋人の役割分担で得られる効果と作業時間の変化

データベース設計を「AIに丸投げ」ではなく「AI＋人の役割分担」で進めると、中小企業の現場でも作業時間と品質の両面で大きな変化が出ます。BoostXで生成AI伴走顧問として中小企業のAI導入を支援する中で、業務自動化全般で1業務あたり50〜70%の時間削減が見込めるという実感を持っています。データベース設計の工程もこのレンジに収まります。

ER図ドラフトと命名候補の生成は工数1/3〜1/5

手書きでER図ドラフトを書き起こすと、業務ヒアリングメモから一次案を出すまでに3〜5時間かかります。生成AIに業務メモを渡してドラフトを出させると、同じ作業が30分〜1時間程度に圧縮できます。命名候補の出し直し・正規化観点での再レビューも、AI側で5分以内にやり直せるため、人間は「どの案にGOするか」の判断に集中できます。

ヒアリングと将来予測の時間を増やせる

ドラフト作成の時間が圧縮されると、人間側は本来時間をかけるべき業務ヒアリング・将来の業務変更の洗い出し・運用フローの設計に時間を振り分けられます。BoostXで業務自動化のクライアント企業を支援した実績では、見積書作業が月20時間から15分に圧縮された事例があります。DB設計でも同じ構造で、AIに渡せるドラフト作業を圧縮し、人間が責任を持つべき業務ヒアリングと先読みに工数を再配分するのが、効果の本筋です。

残業の原因は「人がやらなくていい仕事を人がやっていること」

私の経験では、中小企業のIT・業務開発まわりの残業の多くは、「人がやらなくていい仕事を人がやっている」状態から発生しています。ER図のドラフト・命名候補の作成・正規化の機械チェック・サンプルSQLの叩き台は、まさに「人がやらなくていい仕事」の典型です。AIに任せられる工程を見極めて、人間は判断と責任のある工程に集中する。この再設計が、結果として残業時間と設計品質を同時に改善します。

ビフォーアフター：DB設計プロジェクトがここまで変わる

Before：現状の苦しい1案件

業務ヒアリングは2〜3時間で打ち切られ、要件定義書は箇条書きで3ページ。設計者は片手間で、ER図のドラフト作成に1週間。実装に入ってから「この項目が抜けていた」「この紐付けが違う」と毎週仕様変更が走る。テスト工程でデータ不整合が3〜5件見つかり、リリースが2週間ずれる。リリース後も運用責任者が決まっておらず、データ品質が徐々に劣化し、半年後にはマスタデータが信頼できない状態に陥る。プロジェクト全体で当初見積もりより1.5倍の工数がかかり、関係者全員が疲弊する——これが、AI不在のままでもAI丸投げでも起きる「Before」のリアルです。

After：AI＋人の役割分担で進む1案件

業務ヒアリングに10〜20時間をかけ、複数ロールの担当者の手元と発生データを直接観察する。要件メモを生成AIに渡してER図ドラフトを30分で出させる。経営者と現場リーダーが将来の業務変更を5〜10個洗い出し、AIに再生成させて2案を比較する。レビュー責任者・運用責任者・データ監査責任者の3名を明示し、設計GOを出す。実装中の仕様変更は当初の半分以下に収まり、テスト工程でのデータ不整合はほぼゼロ。リリース後はデータ品質が3ヶ月、6ヶ月、1年と劣化せず、社内の業務改善ループが回り続ける——これが、AI＋人の役割分担で進む「After」の姿です。

違いを生んでいるのはツールではなく運用設計

BeforeとAfterの違いを生んでいるのは、生成AIの性能ではなく、人間側の運用設計です。誰が責任を持ち・どこまでAIに任せ・どこから人間が判断するかの線引きが、結果として品質と工数の両方を決めています。「うちはまだBefore寄り」「AfterのDB設計運用に近づきたい」と感じた方は、次セクションで具体的な相談導線を案内します。Before寄りなら、次セクションで具体的な相談導線を案内します。

よくある質問

公開日：2026年6月