ER図の書き方とは？基本ルールとエンティティ・リレーションの整理法

ER図は、エンティティ・リレーションシップ・カーディナリティという3つの要素を押さえれば、初めてでも読み書きできるようになります。本記事では、要件定義・基本設計の現場で使われるER図の基本ルールを、実際に使われるIE表記法とIDEF1X表記法の違い、具体的な5つの作成ステップ、独立系のSEやコンサルタントがクライアントへ提出する際に押さえておきたい観点まで、架空の「顧客・注文・商品」の例を交えて整理します。

ER図とは？基本設計で重要な理由

ER図（Entity-Relationship Diagram）とは、業務で扱うデータの実体（エンティティ）と実体同士のつながり（リレーションシップ）を図として整理したもので、要件定義・基本設計の工程でシステム関係者の認識をそろえるために使われます。

後工程でDB設計や実装に進んでからER図の誤りに気づくと、テーブル構造の作り直しやプログラムの手戻りにつながりやすくなります。たとえば「注文」と「商品」の関係を1対1のまま設計してしまうと、複数商品を含む注文を正しく登録できず、実装段階でテーブルを作り直す事態になりがちです。

ER図が正しく描けないと起きる問題

ER図の誤りは、要件定義・基本設計の段階では気づかれにくく、実装・テスト段階で初めて表面化することが少なくありません。

典型的なのは、1対多と多対多の関係を取り違えるケースです。1つの注文に複数の商品を含められる想定を「注文」と「商品」の1対1関係で設計してしまうと、注文明細を管理するテーブルが用意されず、後から中間テーブルを追加する手戻りが発生します。ER図の段階でこうした関係を洗い出しておくことが、後工程の手戻りを避けるうえで有効な方法とされています。

要件定義・基本設計フェーズでのER図の位置づけ

ER図は要件定義工程で作る概念モデルから、基本設計工程の論理モデル、詳細設計工程の物理モデルへと、段階を追って詳細化していくのが一般的な進め方です。

要件定義の段階では、業務で扱う実体と関係の大枠だけを整理した概念モデルとしてER図を作成し、基本設計の段階でデータ型や主キーまで含めた論理モデルに具体化していきます。物理的なテーブル定義やインデックス設計は、詳細設計工程の物理モデルの役割です。情報処理推進機構（IPA）が実施するデータベーススペシャリスト試験でも、正確な概念データモデルを作成できることが技術水準として求められており（2026年9月時点）、ER図の設計スキルは公的な試験制度でも重視されています。

ER図を構成する3要素の基本

ER図は、エンティティ・リレーションシップ・カーディナリティ（多重度）という3つの要素の組み合わせで表現します。

この3つの意味を正確に押さえておくと、後述する記法の違いやレビューの理解がスムーズになります。ここでは「顧客」が「商品」を「注文」する、という架空の業務を例に整理します。

エンティティ（実体）とは

エンティティとは、システムが管理する対象そのものを指し、「顧客」「注文」「商品」のように名詞で表される単位です。

エンティティを洗い出すときは、画面の入力項目ではなく業務の文章に出てくる「もの」を基準にします。画面のレイアウトはあとから変わることがありますが、業務上「顧客」や「注文」という単位そのものが変わることはまれなためです。

リレーションシップ（関連）とは

リレーションシップとは、エンティティ同士のつながりを表す要素で、「顧客が注文する」「注文に商品が含まれる」のように動詞で読める形に落とし込みます。

関係を動詞の文章として書き出すと、多重度をどちらの向きで考えるべきかが明確になります。「1人の顧客が複数の注文をする」のか「1件の注文を複数の顧客が共有する」のかは業務ルール次第であり、関係を文章化しないまま図だけを描くと、この前提を後から確認する手間が発生しやすくなります。

属性とカーディナリティ（多重度）

属性はエンティティが持つ具体的な情報項目、カーディナリティは関係する相手の数を示す多重度で、この2つを合わせて初めてER図として実用的な情報になります。

先ほどの例では、顧客エンティティには顧客ID・顧客名・メールアドレスといった属性を、注文エンティティには注文ID・注文日といった属性を割り当てます。カーディナリティは「1人の顧客は0件以上の注文を持つ」「1件の注文は1件以上の商品を含む」のように、上限・下限の両方を意識して設定します。

ER図の代表的な記法（表記法）の違い

ER図の記法にはいくつかの種類がありますが、実務でよく使われるのはIE表記法（鳥の足記法）とIDEF1X表記法の2つです。

どちらもエンティティ・リレーションシップ・カーディナリティを表現するという目的は同じですが、線や記号の書き方、表現できる多重度の細かさが異なります。

IE表記法（鳥の足記法）の特徴

IE表記法は、線の先が鳥の足のように3本に枝分かれする書き方が特徴で、この見た目から「鳥の足記法」とも呼ばれています。

カーディナリティは「○」「｜」「鳥の足」という3つの記号の組み合わせで表現され、○はゼロ、｜は1、鳥の足の枝分かれは多を示します（出典・参考情報を参照）。線を目で追うだけで多重度を直感的に読み取りやすいため、要件定義の段階で業務部門と合意形成をする際に向いています。

IDEF1X表記法の特徴

IDEF1X表記法は、リレーションシップの向き先を黒丸（●）で表す書き方が特徴で、IE表記法より細かい多重度を指定できます。

たとえば「●P」で1以上、「●Z」で0または1というように、記号を組み合わせて範囲まで指定できる仕様になっています（出典・参考情報を参照）。IE表記法より習得のハードルはやや高くなりますが、詳細設計やレビューの場面で多重度をあいまいさなく確定させたいときに適しています。

どちらを選ぶべきか

コンサルタントの歩み編集部の実務整理としては、要件定義フェーズで業務部門との合意形成に使うならIE表記法、詳細設計やレビューで多重度を厳密に詰めたい場面ではIDEF1X表記法、という使い分けが機能しやすいと考えられます。

プロジェクトによっては最初からどちらかの記法に統一しているケースもあります。その場合は既存の記法に合わせることを優先し、記法自体の優劣にはこだわり過ぎないことが無難です。

ER図の書き方【5ステップ】

ER図は、エンティティの洗い出しからレビューと修正までの5つのステップを順に進めると、初めてでも手順を追って完成させられます。

ステップ1: エンティティの洗い出し

ステップ1では、画面の入力項目ではなく業務の文章に出てくる「もの」を基準にエンティティの候補を洗い出します。

候補が本当に独立したエンティティかどうかは、「独立した識別子を持つか」「複数の業務から参照されるか」「変更や履歴を個別に管理する必要があるか」の3点で絞り込むと判断しやすくなります。

ステップ2: リレーションシップの定義

ステップ2では、洗い出したエンティティ同士の関係を「顧客が注文する」のように動詞の文章に置き換えて定義します。

多対多の関係が見つかった場合は、そのまま線でつなぐのではなく、関係そのものを表す中間エンティティ（例:「注文明細」）を用意し、そこに関係固有の属性（数量・単価など）を持たせるのが一般的な扱い方です。

ステップ3: カーディナリティの設定

ステップ3では、それぞれの関係について「必須か任意か」「上限は1か多か」を業務ルールに沿って具体的に決めます。

「1人の顧客は0件以上の注文を持つ」のように、下限（0か1か）と上限（1か多か）を両方言語化しておくと、実装時にNULLを許可すべきかどうかの判断にもそのまま使えます。

ステップ4: 属性・主キーの整理

ステップ4では、各エンティティにどの属性を持たせるか、そのうちどれを主キー（一意に識別する項目）にするかを整理します。

主キーがあるだけでは、同じメールアドレスの顧客を重複登録してしまう事故は防げません。技術的な一意性だけでなく、「同じ顧客とみなす業務上の条件は何か」という重複判定の基準を、この段階で確認しておくことが実務上は重要です。

ステップ5: レビューと修正

ステップ5では、実際の業務シナリオをER図に当てはめて、作成・参照・更新・削除のいずれも正しく処理できるかを検証します。

「顧客の名前が変わった場合」「注文をキャンセルした場合」といった具体的なシナリオを流し込み、履歴を残す項目や、削除ではなく無効化として扱うべき項目がないかを見直します。ExcelでもER図は作成できますが、図形がER図の作成に最適化されていないため修正に工数がかかる点に注意が必要です。draw.ioやERMasterのようなER図専用ツールなら、エンティティの追加・削除に伴う線の引き直しが少ない工数で済みます。

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

ER図作成でつまずきやすいのは、カーディナリティの誤認と、正規化との整合性が崩れる、という2つのパターンです。

カーディナリティの誤認

カーディナリティの誤認で多いのは、実際には多対多の関係を1対多のまま設計してしまうケースです。

「注文」と「商品」の関係がその典型で、1件の注文に複数の商品を含められる業務であるにもかかわらず、注文と商品を1対1や1対多で結んでしまうと、注文明細を保持する場所がなくなります。関係を必ず動詞の文章で読み上げ、「本当にこの方向で1件しか存在しないか」を業務担当者に確認する習慣が誤認を防ぐ助けになります。

正規化との整合性の崩れ

正規化との整合性が崩れるのは、ER図上のエンティティ分割と、実際のテーブル設計での正規化の結果がずれてしまうケースです。

正規化は、繰り返し項目をなくす第1正規化、主キーに従属する属性を別エンティティへ分ける第2正規化、主キーでない項目に従属する項目をさらに分ける第3正規化という3段階で進めるのが基本で、一般的には第3正規化まで行えば問題ないとされています。ER図の段階でエンティティを大まかに分けたつもりでも、正規化の観点で見直すと属性の置き場所が変わることがあるため、ER図と正規化はどちらか一方で完結させず、両方の観点を行き来しながら整えることが推奨されます。

独立コンサル・フリーランスがクライアント提出時に押さえるべき観点

クライアントへの成果物としてER図を提出する場面では、自分が理解できているかどうかより、レビューする相手がどう評価するかという観点が重要になります。

レビュー観点を言語化して信頼を得る

クライアント提出時に指摘を受けやすいのは、カーディナリティの根拠と、エンティティを分けた理由を口頭でしか説明できていないケースです。

「なぜこのエンティティを分けたのか」「このカーディナリティの根拠は何の業務ルールか」を図の注記に一言添えておくだけで、レビュー側の確認時間は短縮されやすくなります。独立系のSEやITコンサルタントの多くはエージェント経由で案件の紹介を受けており、こうした観点を言語化して示せるかどうかは、次の案件紹介につながる評価材料にもなり得ます。

ドキュメント一式との整合性チェック

ER図単体で完結させず、要件定義書やテーブル定義書など、他のドキュメントとの整合性を確認してから提出することが実務上の基本です。

ER図で「注文」エンティティに持たせた属性が、要件定義書の機能要件と食い違っていないか、テーブル定義書のカラム名と表記がずれていないかを見比べる工程を提出前に組み込んでおくと、後からの手戻りを防ぎやすくなります。

まとめ：ER図の基本を押さえて次のステップへ

ER図は、エンティティ・リレーションシップ・カーディナリティという3つの要素と、IE表記法・IDEF1X表記法という2つの表記法の使い分けさえ押さえれば、実務で十分に通用します。

本記事で整理したポイントを振り返ります。

• ER図は要件定義工程の概念モデルから基本設計工程の論理モデルへと段階的に具体化していきます。
• エンティティ・リレーションシップ・カーディナリティの3要素を、動詞の文章で読み下せる形に整理することが基本です。
• IE表記法は直感的な合意形成に、IDEF1X表記法は厳密な多重度の確定に向いています。
• エンティティの洗い出しからレビューと修正までの5ステップを順に進めると、抜け漏れに気づきやすくなります。
• クライアント提出時は、レビュー観点の言語化と他ドキュメントとの整合性確認まで含めて完成とみなすことが望ましいといえます。

関連記事で理解を深める

ER図の書き方をひととおり押さえたら、隣接するドキュメントの整理にも目を通しておくと理解が深まります。要件定義工程の全体像は要件定義書の書き方で、独立系エンジニアの案件獲得ルートはフリーランスの案件獲得方法で、それぞれ詳しく解説しています。

出典・参考情報

1. 情報処理推進機構（IPA）「データベーススペシャリスト試験」（2026-09-07参照）
2. シンクフィールド「ER図とは？書き方やテクニックをわかりやすく解説」（2026-09-07参照）
3. Qiita「【ER図】ER図の基本知識とIEとIDEF1X の違い」（2026-09-07参照）
4. atsumell「ER図の書き方｜業務ルールから作る5ステップ」（2026-09-07参照）
5. マイナビ転職エンジニア「データベース設計に必須なER図の書き方とは？Excelでも作成できる？」（2026-09-07参照）

本記事は2026年9月時点の一般的な情報を基に、ER図の基本的な書き方を整理したものです。記法の細部やツールの仕様は変更される場合があるため、最新情報は各公式サイト・ツールのドキュメントでご確認ください。最終更新日:2026年9月7日