ER図の書き方【コンサル・PMO向け2026年版】

ER図(Entity-Relationship Diagram)は、業務で扱うデータの実体(エンティティ)と実体同士のつながり(リレーションシップ)を図で表した、データベース設計の基本ドキュメントです。本記事では、システム開発案件でDB設計に関わるPMO・ITコンサルの方に向けて、ER図の記法・書き方の5ステップ・正規化の基礎を整理したうえで、自分で書くだけでなく「エンジニアが書いたER図をレビューする」際に使えるチェックポイントまで解説します。

ER図とは何か——エンティティ・リレーションの基本概念

ER図は、エンティティ・属性・リレーションシップという3つの要素で、業務データの実体と関係を整理した図です。要件定義や基本設計の段階で、業務担当者とエンジニアが「どのデータをどう管理するか」の認識を揃えるために使われます。

エンティティ・属性・リレーションシップの定義

ER図を構成する要素は、エンティティ・属性・リレーションシップの3つです。この3つの意味を正確に押さえておくと、後続の記法やレビューの理解がスムーズになります。

構成要素	意味	具体例
エンティティ	システムが管理する対象そのもの	顧客・商品・注文
属性	エンティティが持つ個々のデータ項目	顧客名・メールアドレス・単価
リレーションシップ	エンティティ同士の関係	「顧客が注文する」「注文が商品を含む」

エンティティには、他のレコードと重複しない形で1件を特定できる項目(主キー)を必ず設定します。顧客エンティティであれば「顧客ID」のような、氏名や電話番号のように変わりうる項目に依存しない識別子を主キーに選ぶことが基本です。

ER図がプロジェクトで果たす役割

ER図は、要件定義〜基本設計フェーズにおいて業務担当者とエンジニアがデータ構造について合意するための共通言語としての役割を果たします。データモデリングの技術は情報処理技術者試験でも専門分野の一つとして扱われており、データベーススペシャリスト試験では「データモデリング技法を理解し、利用者の要求に基づいてデータ分析を行い、正確な概念データモデルを作成できる」ことが期待する技術水準の一つとして挙げられています。

PMO・コンサルの立場では、ER図そのものを設計するというより、要件定義書に書かれた業務ルールがデータ構造に正しく落とし込まれているかを確認する場面で必要になる知識です。

ER図の記法と読み方

ER図にはいくつかの記法がありますが、実務でよく登場するのはIE記法とIDEF1X記法の2つです。どちらも線の書き方でエンティティ同士の関係の多重度(カーディナリティ)を表現する点は共通しています。

IE記法・IDEF1X記法の違いと使い分け

IE記法は、線と「カラスの足」と呼ばれる分岐記号の組み合わせでカーディナリティを表す記法で、記号がシンプルなため初めてER図を読む人にも直感的に理解しやすいという特徴があります。

IDEF1X記法は、実線で「識別関係」(子エンティティの主キーに親の主キーを含む関係)を、破線で「非識別関係」を区別して表現する記法です。1993年12月に米国国立標準技術研究所(NIST)がFIPS Publication 184として標準化し、2012年にはIEEEにも採用された記法で、関係の種類を厳密に区別したい大規模なモデルに向いています。

IE記法とIDEF1X記法の代表的な線の記号を左右に並べて比較した図解。カーディナリティを示す1と多のラベル付き

実務では、業務担当者との合意形成にはシンプルなIE記法、エンジニア間での厳密な設計レビューにはIDEF1X記法、というように場面によって使い分けているプロジェクトが一般的です。

カーディナリティ（多重度）の表記ルール

カーディナリティとは、1つのエンティティのレコード1件に対して、もう一方のエンティティのレコードが何件対応しうるかを表す指標です。1対1・1対多・多対多の3パターンに整理して読み解きます。

パターン	読み方	具体例
1対1	一方の1件に対し他方も1件のみ対応	従業員と従業員専用ロッカー
1対多	一方の1件に対し他方は複数件対応しうる	顧客と注文（1人の顧客が複数回注文する）
多対多	双方が複数件同士で対応しうる	注文と商品（1回の注文に複数商品、1商品が複数注文に登場）

IE記法では線の端に付く「多」のカラスの足記号、IDEF1X記法では実線の端に付く黒丸(識別関係)や白丸(非識別関係)で多重度を読み分けます。多対多の関係は正規化の工程で解消が必要になるため、ER図を読む段階でまず見つけておくべきポイントです。

ER図の書き方（5ステップ）

ER図は、①エンティティ抽出→②属性定義→③リレーション設定→④正規化→⑤レビューという5つのステップで組み立てていくのが実務での標準的な進め方です。

①エンティティ抽出 ②属性定義 ③リレーション設定 ④正規化 ⑤レビュー

エンティティ抽出から属性定義・リレーション設定・正規化・レビューまでの5ステップを順番に示したフロー図

架空の受注管理システムを例に、5ステップの流れを具体的に見ていきます。

ステップ	やること	受注管理システムの例
①エンティティ抽出	要件定義書・業務フロー図に登場する名詞を候補として洗い出す	顧客・商品・注文
②属性定義	各エンティティが持つデータ項目と主キーを決める	顧客ID(主キー)・顧客名・メールアドレスなど
③リレーション設定	エンティティ同士のカーディナリティを決める	顧客と注文は1対多、注文と商品は多対多
④正規化	多対多の関係を中間エンティティで解消し、データの重複を整理する	注文と商品の間に「注文明細」を追加
⑤レビュー	業務要件との整合性・命名ルール・拡張性を確認する	次章のチェックポイントで確認

③で洗い出した「注文と商品は多対多」という関係は、そのままではデータベースのテーブルとして表現できません。④の正規化で「注文明細」のような中間エンティティを間に置き、注文と商品それぞれとの1対多の関係に分解して解消します。

要件定義書とのトレーサビリティを保つ工夫

ER図は一度作って終わりではなく、要件変更のたびに更新が発生します。要件定義書のどの項番から生まれたエンティティ・属性なのかを追跡できる状態にしておくと、後からの変更対応が格段に楽になります。

具体的には、エンティティ・属性の説明欄に要件定義書の項番を残す、業務フロー図に登場する帳票名・項目名をそのままエンティティ・属性の候補として拾う、といった工夫が有効です。業務フロー図から情報を拾う考え方は業務フロー図の書き方で紹介した可視化の手順と共通しており、双方の項目名を揃えておくと後工程での手戻りを防ぎやすくなります。

正規化の基礎知識

正規化とは、データの重複と更新時の不整合を防ぐ目的で、1つの大きなテーブルを複数のテーブルに分割していく設計手法です。実務では第3正規形まで整理するのが基本的な到達点とされています。

第1〜第3正規形の考え方

正規化の考え方も、受注管理システムの例で見ていくと理解しやすくなります。正規化前は、1件の注文レコードに顧客名や商品名までまとめて詰め込んでしまっているような状態です。

段階	やること	受注管理システムでの状態
正規化前	-	1つの注文テーブルに顧客名・商品名・数量を繰り返し項目として全て格納
第1正規形	繰り返し項目を取り除く	1商品1行になるよう「注文明細」テーブルへ分割
第2正規形	主キーの一部にしか従属しない項目を分離する	商品名・単価を「商品」テーブルへ分離
第3正規形	主キー以外の項目に従属する項目を分離する	顧客の住所を顧客IDに従属させ「顧客」テーブルへ分離

この整理により、顧客名や商品名が変わった際に1か所を更新するだけで済むようになり、データの不整合が起きにくくなります。

過度な正規化がもたらすパフォーマンス問題

正規化を進めすぎると、1件のデータを取得するために結合(JOIN)しなければならないテーブル数が増え、参照処理の性能が落ちる場合があります。特に一覧画面や集計処理のように大量データを頻繁に参照する箇所では、結合の増加がそのまま表示速度の低下につながることがあります。

そのため実務では、更新頻度が低く参照頻度が高い項目についてはあえて正規化を崩し、参照用のテーブルに冗長に持たせる判断が取られることもあります。理論を機械的に適用するのではなく、更新と参照それぞれの頻度を踏まえて判断する視点が重要です。

ER図作成に使えるツールの選び方

ER図作成ツールは、無料で使えるものから有償のクラウド型ツールまで幅広く存在します。ツール選定では、機能の豊富さだけでなくチーム内での共有・バージョン管理のしやすさを基準に置くことが実務的です。

無料ツールと有償ツールの機能差

draw.io(diagrams.net)のような無料ツールは、個人利用や小規模なプロジェクトであれば十分な作図機能を備えています。一方で、既存データベースからER図を自動生成する機能や、大規模なモデルを複数人で同時編集する機能は、無料ツールでは制限されている場合が多い傾向があります。Lucidchartなど有償のクラウド型ツールは、共同編集・コメント機能・外部サービス連携といったチーム利用を前提にした機能を備えている点が特徴で、案件の規模やチーム体制に応じて使い分けます。

チーム共有・バージョン管理のしやすさで選ぶ視点

PMOの立場でツールを選ぶ際は、機能の多さより「変更履歴を追えるか」「関係者に確認を依頼しやすいか」を優先することを推奨します。

URLひとつで最新版を関係者に共有でき、都度ファイルを送り合わなくて済むか
いつ・誰が・どの部分を変更したか、変更履歴として残るか
Mermaid記法のようなテキストベースの記述に対応し、Gitなどのソースコード管理と組み合わせられるか

PMO・コンサルがER図をレビューする際のチェックポイント

システム開発案件に関わるPMO・ITコンサルの多くは、ER図を自ら書くというより、エンジニアが作成したER図を要件定義の観点からレビューする役割を担う場面のほうが多くなります。要件定義・基本設計といった上流工程は、運用・保守などの下流工程と比べて単価水準が高い傾向にあるとされ、ER図をレビューできる力は上流工程を担う専門性の裏付けの一つにもなります。

業務要件とデータモデルの不整合を見抜く視点

虫眼鏡で図形のつながりを拡大し、一つだけ形の違う不整合な部分を見つけているイラスト。PMOがER図をレビューして業務要件との不整合を見抜く視点を表している

ER図のレビューでは、次のような視点で業務要件とデータモデルのズレを探します。

要件定義書に登場する業務用語が、エンティティか属性のどちらかとして必ず存在しているか
業務上「一意に特定できる」はずの概念に、主キーがきちんと設定されているか
業務上「同時に複数件存在しうる」関係が、誤って1対1でモデリングされていないか
金額・数量のような計算対象の項目について、単位や桁数が業務要件と食い違っていないか

業務要件を漏れなく分解して確認したい場合は、ロジックツリーの作り方で紹介されている要素分解の考え方を使い、「この業務で管理すべき情報は何か」をMECEに洗い出したうえでエンティティ・属性の抜け漏れを突き合わせる進め方が有効です。

エンジニアとの認識合わせで使える質問リスト

ER図をレビューする際、エンジニアに直接確認しておくと後工程の手戻りを防ぎやすい質問を5つ紹介します。

このエンティティの主キーには何を設定していますか。将来重複する可能性がある項目ではありませんか
この多対多の関係は中間エンティティで解消済みですか、それともこれから解消する予定ですか
レコードを削除する際は、データを残したまま非表示にする方針ですか、実際に削除する方針ですか。その方針を選んだ理由は何ですか
履歴として残す必要がある項目が、更新のたびに上書きされる設計になっていませんか
この粒度まで正規化した判断は、想定されるアクセス頻度やデータ件数を踏まえたものですか

いずれも要件定義書だけでは気づきにくく、ER図と突き合わせて初めて浮かぶ疑問です。認識合わせの場で早めに確認しておくと、基本設計以降の手戻りを減らせます。

ER図作成でよくあるミスと注意点

ER図作成で繰り返し見られるミスは、多対多リレーションの未解消と、将来の拡張性を考慮しないマスタ設計の2つに集約されます。

多対多リレーションの未解消

受注管理システムの例で見た「注文と商品」のような多対多の関係は、中間エンティティを挟んで1対多×2つに分解しないと、そのままではデータベースのテーブルとして正しく実装できません。設計の初期段階でエンティティ抽出とリレーション設定を急ぐと、この分解を見落としたままレビューまで進んでしまうことがあります。

ER図をレビューする際は、線の両端に「多」の記号が付いている関係が残っていないかを重点的に確認します。残っている場合は、中間エンティティで解消できているかをエンジニアに確認する必要があります。

将来の拡張性を考慮しないマスタ設計

もう一つよくあるミスは、顧客区分や商品カテゴリのような分類項目を、決め打ちの選択肢としてカラムに直接埋め込んでしまう設計です。この形にすると、将来分類を追加・変更する際にプログラムの改修が必要になり、データの追加だけでは対応できなくなります。

将来増減する可能性がある分類は、あらかじめ独立したマスタテーブルとして切り出しておくと、区分の追加がデータ追加だけで完結し、拡張に強い設計になります。レビューの際は、決め打ちの選択肢に見える項目がないかを確認するとよいでしょう。

出典・参考情報

IPA 独立行政法人情報処理推進機構「データベーススペシャリスト試験」（2026-08-27参照）：データモデリング技法・概念データモデル作成に関する記述の根拠
IDEF.com「IDEF1X – Data Modeling Method」（2026-08-27参照）：IDEF1X記法の標準化の経緯に関する根拠
bizdev-tech「フリーランスコンサルタントの案件・単価相場」（2026-08-27参照）：上流工程と下流工程の単価傾向に関する参考情報

本記事の情報は2026年8月27日時点のものです。ツールの機能や記法の実務での使われ方は変化することがあるため、最新の状況は各ツールの公式情報もあわせてご確認ください。