ER図の書き方｜業務ルールから作る5ステップ

「顧客と案件を管理したい」。この要望だけでER図を描くと、最初の箱はすぐ作れる。顧客、案件、担当者。線で結べば、それらしい図になる。

ところが、レビューを始めると質問が止まらない。1人の担当者が複数案件に参加できるのか。会社名が変わったら過去の見積書も変えるのか。案件を削除したら活動履歴はどうなるのか。ここが決まっていなければ、図はきれいでも仕様としては弱い。

ER図は、データベースの箱と線を描く資料ではない。業務で守るべきルールを、データの構造へ変換する設計図だ。

Mermaidの公式ドキュメントでは、ERモデルを対象領域のエンティティと、その間に成立する関係として説明している。SQL Server向けのMicrosoft Database Designerガイドでは、図からテーブル、列、キー、インデックス、関係、制約を扱える。製品固有の機能ではあるが、図に含める設計情報を考える参考になる。大事なのは、図形を置くことより制約を明らかにすることだ。

ここでは、ER図の書き方を5ステップに分ける。題材は、企業向けの案件管理システムである。

ステップ1：画面項目ではなく業務上の「もの」を拾う

最初に画面を見てエンティティを決めると、入力フォームの都合に引っ張られる。「会社名」「担当者名」「案件名」が並んでいるから、1つの案件テーブルへ全部入れる。これは手早いが、後で苦しくなる。

先に業務の文章を書く。

> 企業には複数の担当者が所属する。企業との提案機会を案件として管理する。1つの案件には複数の担当者が関わり、打ち合わせやメールの履歴を残す。

この文章から名詞を拾うと、候補は企業、担当者、案件、活動になる。ただし、名詞をすべて箱にすればよいわけではない。次の3つで絞る。

• 独立した識別子を持つか
• 複数の業務から参照されるか
• 変更や履歴を個別に管理する必要があるか

たとえば「企業名」は企業の属性であり、独立したエンティティではない。一方、担当者は異動や退職があり、案件や活動からも参照される。独立させた方がよい。

エンティティ名は単数形の名詞でそろえる。Mermaidの公式例も `CUSTOMER` や `ORDER` のように、対象の種類を単数名で表している。日本語で描くなら「企業」「担当者」「案件」「活動」で十分だ。

この段階では属性を増やしすぎない。まず箱の責任範囲を決める。業務の流れ自体が曖昧なら、先に業務フローをAIが読める仕様へ変える方法を整理すると、エンティティ候補を拾いやすい。

ステップ2：主キーと重複条件で「同一性」を決める

次に「同じもの」をどう見分けるか決める。これが主キーの役割だ。

企業なら会社名を主キーにしたくなる。だが、社名は変わる。同名企業もあり得る。メールドメインも、グループ企業で共有されることがある。業務上の表示名と、システム上の識別子は分けた方が安全だ。

案件管理の例では、次のように置ける。

主キーを決めたら、一意制約も別に考える。主キーがあるだけでは、同じメールアドレスの担当者を二重登録する事故は防げない。逆に、共有メールアドレスを一意にすると、実態に合わない場合もある。

国内法人の法人番号は強い照合材料だが、すべての取引先へ使えるわけではない。個人事業主、海外企業、支店・事業所を含むなら、外部CRMの企業IDや所在地、メールドメインを重複候補の照合に使う。ただし、正式社名と所在地の組み合わせを機械的な一意制約にするのは避けたい。表記変更や移転で別企業扱いになるからだ。

ここで必要なのは「技術的に一意か」ではなく、「業務上、重複と判定してよいか」という会話だ。PostgreSQLの制約ドキュメントでは、主キー、外部キー、UNIQUE、NOT NULL、CHECKを別の制約として扱っている。ER図のレビューでも同じように分けるとよい。

ステップ3：関係を動詞で読み、多重度を決める

箱を線で結ぶ前に、関係を日本語の文にする。

• 企業は担当者を所属させる
• 企業は案件を持つ
• 担当者は案件へ参加する
• 案件は活動を記録する

動詞で読めない線は、関係の意味が曖昧だ。「関連する」だけでは弱い。何をした結果つながるのかを書く。

次に、多重度と必須・任意を決める。

担当者と案件は多対多になりやすい。そこで `案件担当者` のような中間エンティティを置く。ここには `role`、`joined_at`、`is_primary` など、関係そのものの属性を持たせられる。

Mermaidなら、関係を次のようなテキストで管理できる。

erDiagram

COMPANY ||--o{ PERSON : employs

COMPANY ||--o{ DEAL : owns

PERSON ||--o{ DEAL_PERSON : participates

DEAL ||--o{ DEAL_PERSON : assigns

DEAL ||--o{ ACTIVITY : records

`||` はちょうど1、`o{` は0以上を示す。記号を覚えること自体が目的ではない。「担当者が0人の企業を登録できるか」「担当者未確定でも案件を作れるか」を関係者で決め、その答えを記号へ変える。

ステップ4：履歴・状態・削除・権限を図へ戻す

ER図で抜けやすいのは、現在値以外の設計だ。実務では次の4点が後から効く。

履歴

案件のフェーズを `phase` という1列だけで持つと、現在値は分かる。だが、「いつ」「誰が」「なぜ」変えたかは残らない。営業分析や監査に必要なら、`案件フェーズ履歴` を独立させる。

状態

状態名を自由入力にすると、表記揺れが起きる。許可する状態、遷移条件、戻せる状態を決める。状態遷移が複雑なら、状態遷移からAI要件を作る方法とER図を組み合わせる。

削除

企業を削除したとき、案件や活動も消してよいのか。多くの業務システムでは、物理削除より無効化やアーカイブが合う。法令・契約・監査要件がある場合は、保持期間と削除責任者まで確認する。

権限

誰がどの企業・案件を見られるか。組織、担当、案件参加者など、権限判定に使う関係はER図へ現れる。単に `owner_id` を足すだけで済むのか、共有範囲を管理する中間エンティティが必要かを決める。社内AIエージェントの権限設計で扱ったように、参照と更新の権限も分けたい。

この4点を確認すると、ER図はデータベース担当者だけの資料ではなくなる。業務担当は履歴と状態を確認できる。法務・セキュリティ担当は保持と権限を確認できる。開発側は制約を実装へ落とせる。

レビュー後の完成例

ここまでの判断を反映すると、最初の5エンティティは次の形まで育つ。

erDiagram

COMPANY ||--o{ PERSON : employs

COMPANY ||--o{ DEAL : owns

PERSON ||--o{ DEAL_PERSON : participates

DEAL ||--o{ DEAL_PERSON : assigns

DEAL ||--o{ DEAL_PHASE_HISTORY : changes

DEAL ||--o{ ACTIVITY : records

COMPANY {

string company_id PK

string corporate_number

string official_name

boolean is_archived

}

DEAL_PERSON {

string deal_person_id PK

string deal_id FK

string person_id FK

string role

datetime joined_at

datetime left_at

}

DEAL_PHASE_HISTORY {

string history_id PK

string deal_id FK

string phase

string changed_by

datetime changed_at

}

ACTIVITY {

string activity_id PK

string deal_id FK

string external_event_id

datetime occurred_at

}

図だけでは、`external_event_id` を一意にするか、`left_at` が空なら現役とみなすかまでは確定しない。そこで制約表を併記する。ER図を「完成画像」にせず、業務ルールと往復できる設計資料にする。

ステップ5：業務シナリオでER図を壊しにいく

完成したER図は、眺めるだけでは検証できない。具体的なシナリオを流す。

案件管理なら、少なくとも次を試したい。

1. 企業だけ先に登録し、担当者は後で追加する
2. 1人の担当者を2件の案件へ参加させる
3. 主担当を途中で交代し、過去の担当履歴を残す
4. 社名変更後も過去の活動を同じ企業へ結びつける
5. 案件を失注後に再開し、フェーズ変更理由を追えるようにする
6. 担当者を無効化しても、過去メールの送受信者を表示する
7. 同じ外部イベントを2回受信しても、活動を二重登録しない

各シナリオについて、作成・参照・更新・削除の結果を書く。ER図の箱と線で説明できなければ、何かが足りない。

発注者とSIerのレビューでは、ここを役割で分ける。発注者は「同じ企業・同じ案件をどう判断するか」「履歴をどこまで残すか」を決める。SIerは、その判断を主キー、外部キー、一意制約、削除方式へ変換する。どちらか片方だけで閉じると、設計レビュー後に業務ルールが差し戻されやすい。

たとえば「主担当を交代する」なら、`案件担当者` に役割と有効期間が必要になるかもしれない。「同じ外部イベントを二重登録しない」なら、外部サービスのイベントIDへ一意制約が必要になる。受け入れテストからER図へ戻ると、抽象的なレビューより抜けを見つけやすい。

AIテスト自動化は受け入れ条件からでも、テスト対象を機能名ではなく条件で切る考え方を整理している。ER図も同じだ。エンティティの存在ではなく、業務ルールが守られるかで確認する。

ER図レビューで使う10項目

レビューでは、次の10項目を上から確認する。

• エンティティ名が単数形の業務用語になっているか
• 各エンティティの責任を1文で説明できるか
• 表示名と主キーを混同していないか
• 業務上の重複条件が定義されているか
• 関係を具体的な動詞で読めるか
• 多重度と必須・任意に根拠があるか
• 多対多を中間エンティティへ分解したか
• 履歴、状態、削除、権限を確認したか
• 外部連携の重複防止条件があるか
• 業務シナリオと受け入れテストで検証したか

全部を1枚に詰め込む必要はない。概念ER図では業務上のものと関係を示し、論理ER図では属性・キー・多重度を足す。大きいシステムなら、販売、請求、権限など領域別に分ける。SQL ServerのDatabase Designerでも、同じデータベースから焦点の異なる複数の図を作れる。レビュー対象に合わせて図を分けた方が読みやすい。

ER図をAIで作るなら、生成よりレビュー条件を先に渡す

AIへ業務説明を渡せば、ER図の初稿は短時間で作れる。Mermaidのようなテキスト形式なら、差分も確認しやすい。便利なのは間違いない。

ただし、AIは業務ルールの空白を推測で埋める。会社名を一意とみなす。多対多を1本の線で済ませる。削除時の扱いを暗黙に決める。初稿をそのまま実装へ渡すのは危ない。

AIへ渡す入力には、少なくとも次を含める。

• 業務シナリオと用語集
• 重複と同一性の判定条件
• 必須・任意と多重度
• 履歴・状態・削除の方針
• 権限と外部連携の境界
• 受け入れテスト

この順番なら、AIは箱を増やすためではなく、決めた条件の抜けを探すために使える。

たとえばKakusillでは、議事録や既存資料から業務フロー、データ項目、例外、受け入れ条件を整理できる。ER図の線そのものを自動生成して終わるのではなく、「なぜ1対多なのか」「削除後も履歴を残すのか」といったレビュー条件を仕様として残す使い方が合う。仕様変更時も、図だけでなく前提の差分を追える。

既存資料からER図の前提となる業務ルールを整理したい、発注者とSIerの認識差を実装前に閉じたい場合は、株式会社Atsumellへ相談する。画面一覧より一段手前の、業務・データ・制約の整理から支援できる。

関連記事

• AIワークフローは業務フローから設計する
• AI要件定義は状態遷移から始める
• AIテスト自動化は受け入れ条件から