本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第3弾として、データモデリングについて解説する記事です。
DBはコードより寿命が長く、数千万行に育ったテーブル構造の変更は数時間のダウンタイムを要します。最初のモデリングが10年後まで効く領域です。本記事では3段階モデリング、正規化と非正規化、主キー設計、スキーマ変更戦略まで解説し、「AIにも人間にも読めるスキーマ」の作り方を示します。
本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。
この記事の結論
- 業務DBは第3正規形（3NF）を基本にする（4NF以降は学術の世界）
- UUID v7+ソフトデリート+監査カラムを標準セットにする
- 英語の自然な命名+COMMENTでAIのSQL生成精度を上げる
- マイグレーションはツールでGit管理する（GUI手作業は事故の元）
この記事を読む前に
本記事はデータベース周りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「データベースの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもデータモデリングとは何か
データモデリングとは、ざっくり言えば「アプリケーションが扱うデータの整理整頓ルールを決めること」です。
引っ越しの荷造りを想像してください。衣類・食器・書類をとりあえず段ボールに詰め込むと、引っ越し先で何がどこにあるか分からなくなります。「衣類は衣装ケース、食器は緩衝材入りの箱、書類はファイルボックス」と分類ルールを決めておけば、誰でも目的の物を素早く取り出せます。データモデリングも同じで、業務で扱う情報を「どんな構造で、どう関連づけて保管するか」を設計する工程です。
なぜモデリングが最重要なのか
DBが一度運用されるとテーブル構造の変更は極めて高コストです。数千万行のテーブルにカラムを追加するだけで数時間のダウンタイムを要することもあり、モデリングミスは長期に渡って負債になります。「アプリは書き直せる。データモデルは書き直せない」のが現実です。
さらに、業務DBは他システム・分析基盤・帳票・BIなど多方向から参照されるためスキーマ変更の影響範囲は想像以上に広く、インデックス・正規化度合い・パーティション戦略といったモデリング段階の決定が将来の性能天井を決めます。
モデリングの3段階
いきなりテーブル定義（物理設計）から入ると業務の本質を掴めず、破綻の元になります。
| 段階 | やること | 成果物 |
|---|---|---|
| 概念モデル | 業務で扱う「モノ」を洗い出す | エンティティ一覧・ER図 |
| 論理モデル | 属性と関連を定義・正規化 | 論理ER図・属性定義書 |
| 物理モデル | DB製品に合わせた実装形式 | CREATE TABLE文・インデックス |
小〜中規模では論理と物理をまとめて進めるのが現実的ですが、概念モデルだけは必ず先に作るべきです。
正規化と非正規化
正規化は、データの重複を排除し、更新時の矛盾を防ぐ設計原則です。「注文テーブル」に顧客名を直接書くと、顧客名の変更時に全ての注文レコードを更新する必要があります。顧客テーブルを分けて注文は顧客IDだけ持つ形にすれば、1箇所の変更で全体が整合します。段階は第1〜第5正規形までありますが、実務では第3正規形（3NF）までで十分です。それ以上は学術の世界です。
一方、正規化はJOINが増えると性能が落ちる副作用があるため、「意図的に冗長を残す」非正規化も使います。業務DB（OLTP）は3NFで設計 → 必要な箇所だけ非正規化が基本動作で、分析DB（OLAP）では非正規化が標準です。
分析DBの定番がスター・スキーマです。中央に「事実（ファクト）」テーブル（売上明細等）、周囲に「次元（ディメンション）」テーブル（商品・顧客・日付・店舗）を配置する星型構造で、「地域別・月別・カテゴリ別の売上」のような多軸集計が極めて高速になります。業務DBは3NF、分析DBはスター・スキーマ、と用途で形を変えます。
主キーとインデックスの設計
主キーは自動採番のサロゲートキーが主流で、業務的な値（メールアドレス・電話番号）を主キーにするのは避けるのが鉄則です。業務値は改姓・メール変更といった現実の変化に耐えられません。現代の最適解はUUID v7（2024年RFC化）またはBIGINT連番です。UUID v4はランダム性ゆえにインデックスの物理配置が分散し、数千万件規模で挿入性能が数倍劣化します。v7は時刻順序とランダム性を両立し、この問題を設計段階で回避できます。
インデックスは正しく張ると数百倍速くなる一方、張りすぎると更新が遅くなります。「WHEREとJOINに使うカラムには張る、それ以外は張らない」が基本方針で、複合インデックスは左から前方一致でしか効きません。初期は必要最小限で張り、実クエリで遅いものにだけ後から追加するのが鉄則です。全文検索・JSON・地理情報にはGIN / GiSTを使います。
スキーマ変更戦略とソフトデリート
運用中のスキーマ変更は最も事故りやすい領域です。NULL許可のカラム追加は低リスクですが、NOT NULL追加は「一旦NULL許可→バックフィル→NOT NULL」、型変更・リネームは「新カラム追加→両方書き込み→切替→旧カラム削除」のexpand/contractパターンで段階的に行います。1000万行超のテーブルはALTER TABLEでロックが発生するため、PostgreSQLなら pg_repack、MySQLなら gh-ost での無停止変更が必須です。そしてマイグレーションはFlyway・Prisma Migrate等のツールでGitで履歴管理します。GUIでの手動変更は履歴・再現・ロールバックが全て不可能になります。
削除の扱いも設計時に決めます。業務データ全般は deleted_at カラムのソフトデリート、金融・医療・監査対象は履歴テーブル（物理削除禁止）、キャッシュ・ログは物理削除。ただしGDPR等の個人情報削除要求があると物理削除が必須になる場面もあり、法令との両立は事前に要件を詰めます。
どう選べばいいのか ― 複雑度と規模で決める
規模の目安は、100万レコード未満は何も考えなくてOK、1000万〜でパーティション検討、1億〜でシャーディングと非正規化も視野に入る、という段階です。そしてEAV・Polymorphic・イベントソーシングのような高度なモデルは、チームが扱いきれないと地獄になります。「チームのSQL・DB理解度に合ったモデル」を選ぶのが現実解です。
モデリング品質の数値Gate
※ 2026年4月時点の業界相場値です。
| 指標 | 閾値 | 超えたらどうするか |
|---|---|---|
| 1テーブルのカラム数 | 20個以下 | 責務が混在。分割を検討 |
| 1テーブルのインデックス数 | 5個以下 | 更新性能劣化。見直し |
| JOINの深さ | 3〜4段まで | 非正規化 or ビューで整理 |
| NULL許容列 | できるだけNOT NULL | 制約を効かせる |
| 主キー型 | UUID v7 or BIGINT | v4は性能劣化 |
3つのシナリオで考える
個人開発・スタートアップの場合
社内管理画面やシンプルなCRUDであれば、3NFで素直に設計して、UUID v7とソフトデリートに監査カラム（created_at / updated_at）を付けておけば十分だと思います。凝ったモデリングパターンは必要ありません。この段階で投資する価値があるのは、スキーマをPrismaやDrizzleの型定義で明示しておくことくらいでしょう。
中小SaaSの場合
ECやSaaSの業務DBは、3NFに履歴保持（注文履歴・価格変更履歴は別テーブル）を加えた形が基本形となります。分析クエリはETLで別のDBへ逃がして、本番DBのモデルは業務処理に集中させるのがポイントです。1000万レコードを超えるテーブルが出てきたら、パーティションを検討し始める時期ですね。
大企業・規制業種の場合
金融・医療・公共では履歴テーブルが必須となり、物理削除も禁止して監査に対応できるモデルにする必要があります。1億レコード級になるとシャーディングや非正規化も視野に入ってきますが、こういった高度なモデルはチームの理解度が前提条件となりますので、体制と合わせて判断してください。
AI判断軸 ― スキーマはAIへの辞書
英語命名+COMMENTがAI生成SQLの精度を決定的に変える
テーブル名が users・orders・order_items のような英語自然命名で、各カラムにCOMMENT（「注文確定日」「税込金額」等）が付いていれば、AIはText-to-SQLで正確なクエリを生成できます。tbl_001・kbn_cd のような略語命名では、AIがカラムの意味を推測できずSQLが不正確になります。命名とコメントは人間のためだけでなく、AIへの辞書として機能します。
外部キー制約の明示がAIのJOIN生成を助ける
外部キー制約がDB上で明示されていると、AIはテーブル間の関連を正確に把握し、JOINの条件を間違えません。制約なしでアプリ側でのみ関連を管理している場合、AIは「どのテーブルとJOINすべきか」を推測する必要があり、誤ったJOIN条件を書く可能性があります。外部キー制約は整合性の砦であると同時に、AIへの構造情報でもあります。
やってはいけないこと
スキーマはDBの骨格なので、後から直すのが最も高コストです。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| JSONBに検索対象を詰め込む | GINインデックスでも通常カラムより遅くフルスキャン化する → 主要属性は通常カラムに切り出す |
| UUID v4を主キーに大量挿入 | インデックス局所性が悪化する → UUID v7かBIGINTにする |
| 業務値（メール等）を主キーにする | 値変更で全外部キー更新の大工事になる → サロゲートキーにする |
| 外部キー制約を性能のために全部外す | 整合性破壊・孤立データが蓄積する → 原則付ける |
| マイグレーションをGUI手作業で実施 | 履歴・再現・ロールバックが不可能になる → ツール+Git管理にする |
| 命名を略語・日本語ローマ字にする | AIも人も読めない → 英語snake_case+COMMENTにする |
筆者メモ ― 「metadata JSONB」が生んだフルスキャン地獄
ある業務アプリでは、ユーザープロフィールの全属性が metadata という1つのJSONBカラムに詰め込まれていた、という話がしばしば語られます。「将来の拡張に備えて柔軟に」が動機だったものの、「会社名にXを含むユーザー」を絞り込むだけで毎回フルスキャンが走る状態になり、データ量が増えるにつれて管理画面が開かなくなったと言います。GINインデックスで応急処置しても通常カラムよりはるかに遅く、結局主要属性を通常カラムに分離する大改修で半年を費やしたそうです。
「柔軟に」と「雑に」は紙一重です。JSONはスキーマが揺れる一部領域だけに限定し、検索対象は通常カラムに切り出します。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 正規化レベル（3NFが基本）
- 主キー戦略（UUID v7を推奨）
- ソフトデリート方針（deleted_at / 履歴テーブル）
- 監査カラム（created_at・updated_at・created_by）
- 命名規則（英語snake_case+COMMENT）
- マイグレーションツール（Flyway・Prisma Migrate等）
この記事に関連する記事
まとめ
本記事はデータモデリングについて、3段階モデリング・3NFと非正規化・主キー設計・インデックス・スキーマ変更戦略・ソフトデリートまで含めて解説しました。如何だったでしょうか。
業務DBは3NF、UUID v7+ソフトデリート+監査カラムを標準セットに、英語の自然な命名でAI生成精度を上げる。これが2026年のデータモデリングの現実解です。
次回はデータ基盤（DWH・データレイク・BI連携）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は PostgreSQL 公式ドキュメント も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（47/95）