ER図の書き方｜エンティティ・リレーションの決め方を手順で解説

ER図の書き方は、業務で使う用語を洗い出し、そこからエンティティを決め、エンティティ同士の関係（1対多など）を線で結ぶ、という3段階で整理できます。記号の覚え方から入ると手が止まりやすいため、本記事では「業務の言葉をどうデータの単位に直すか」という順番で解説します。

データベース設計を学び始めたSEや、要件定義・基本設計といった上流工程を目指す方を想定しています。基本の構成要素、手順、受注管理と予約管理の2つの例題、つまずきやすい間違い、テーブル定義書への展開までを順に確認します。2026年10月時点の一般的な実務の考え方に基づいて書いており、記法や運用はプロジェクトごとに異なる場合があります。

ER図とは

ER図（実体関連図）とは、業務で扱うデータを「モノ・コト」の単位と、その間のつながりで表した設計図です。データベースのテーブル構造を決める前段階で、関係者が同じ認識を持つために使います。

目的

ER図の目的は、データの構造を図にして、設計者と業務担当者の認識のずれを早めに見つけることです。ER図という考え方は、1976年にPeter Chen氏が論文「The Entity-Relationship Model: Toward a Unified View of Data」（ACM Transactions on Database Systems 第1巻）で発表したものが原点とされています。

文章だけで「顧客は複数の注文をする」「注文には複数の商品が含まれる」と説明しても、人によって解釈が分かれます。図にすると、1人の顧客が何件の注文を持てるのか、1件の注文に商品が何点入るのかが線の形で一目に見えるため、認識合わせの時間が短くなります。

使う場面

ER図が使われるのは、主に要件定義から基本設計にかけての段階です。情報処理推進機構（IPA）が公開する「超上流から攻めるIT化の事例集」では、要件定義の機能要件（データ）の項に、概念ERD、論理ERD、データ項目定義書が成果物の例として挙げられています（出典：IPA「超上流から攻めるIT化の事例集：要件定義」）。

実務では、新規システムの設計だけでなく、既存システムの改修時にデータの持ち方を整理し直す場面でも使います。基本から確認したい方はER図の基本と目的、具体例を見たい方はER図の具体例が参考になります。要件定義書全体の書き方は要件定義書の具体例で解説しています。業務フロー図が「作業の流れ」を描くのに対し、ER図は「扱うデータの構造」を描くという役割の違いがあります。

基本の構成要素

ER図の基本の構成要素は、エンティティ、属性、リレーション（関係）の3つです。この3つが読み書きできれば、ほとんどの業務システムのER図は描けます。

エンティティ

エンティティとは、業務の中で「管理したい対象」を1つの単位にまとめたものです。顧客、注文、商品、予約、会議室のように、名詞で表せるものが候補になります。

見分け方の目安は、「複数の具体例を持ち、1件ずつ区別して記録したいか」です。たとえば「顧客」は山田さん、佐藤さんと1件ずつ記録するのでエンティティになります。一方、「顧客の電話番号」は顧客に付随する情報なので、エンティティではなく次に説明する属性として扱うのが基本です。

属性とリレーション

属性はエンティティが持つ情報の項目で、リレーションはエンティティ同士のつながりです。顧客エンティティなら、顧客名や連絡先が属性にあたります。

属性の中でも、1件ずつを一意に特定する項目を主キー（PK）と呼びます。顧客なら顧客ID、注文なら注文番号です。別のエンティティの主キーを自分の属性として持ち、つながりを表す項目は外部キー（FK）と呼びます。リレーションは線で表し、線の端の記号で「1」か「多」かを示します。この「1」か「多」かを表す部分を多重度（カーディナリティ）と呼びます。

記法にはIE表記法（線の端が鳥の足のように枝分かれする形）やIDEF1X表記法などがあり、プロジェクトの規約に合わせて選びます。記号の読み方を詳しく確認したい場合は、ER図の見方と記号の意味も参考になります。

書き方の手順

ER図は、用語の洗い出し、エンティティの決定、関係の決定の順に進めると、手戻りが少なくなります。いきなり図を描き始めず、まず言葉を集めるのがコツです。

業務の用語を洗い出す

最初の作業は、対象業務に登場する名詞と、帳票や画面に並ぶ項目名を、すべて書き出すことです。業務の説明文、既存の帳票、担当者へのヒアリング記録が材料になります。

たとえば受注管理なら、「顧客」「注文」「注文日」「商品」「単価」「数量」「出荷」「請求先」といった言葉が並びます。この段階では分類せず、重複や言い回しの違いだけをそろえます。「お客様」と「顧客」は同じものを指すなら、どちらか一方に統一します。

エンティティを決める

洗い出した用語を、「1件ずつ区別して記録したいもの」と「それに付随する情報」に仕分けると、エンティティが決まります。前者がエンティティ、後者が属性の候補です。

実務では、帳票の見出しにある単位がエンティティの手がかりになります。注文書には注文番号があり、その下に商品の明細行が並んでいるなら、「注文」と「注文明細」の2つに分けられる可能性が高いといえます。エンティティが決まったら、それぞれに主キーを1つ決めておきます。

関係(1対多など)を決める

関係は、エンティティを2つ選び、「Aが1件あるとき、Bは何件あり得るか」と「Bが1件あるとき、Aは何件あり得るか」を両方向から問うと決まります。

「1人の顧客は何件の注文をするか」は複数件、「1件の注文は何人の顧客のものか」は1人なので、顧客と注文は1対多です。片方向だけで考えると誤りやすいため、必ず逆向きも確認します。結果は、多側のエンティティに外部キーを持たせて表現します。この例では注文が顧客IDを持ちます。

例題で書いてみる

ここでは受注管理と予約管理の2つの架空の業務を使い、手順どおりにER図の中身を組み立てます。結果は表で示すので、そのまま自分の業務に置き換えて使えます。

受注管理の例

受注管理の例では、顧客・注文・注文明細・商品の4つのエンティティになります。用語の洗い出しで出た「数量」と「単価」は、注文に直接ぶら下げず、注文明細の属性にします。1件の注文に複数の商品が含まれるためです。

関係は、顧客と注文が1対多、注文と注文明細が1対多、商品と注文明細が1対多です。販売単価を注文明細に持たせているのは、商品の標準単価が後から変わっても、過去の注文の金額が変わらないようにするためです。

予約管理の例

予約管理の例として、会議室の予約システムを考えます。エンティティは、利用者、会議室、予約の3つです。予約は「誰が」「どの会議室を」「いつ」使うかを1件ずつ記録するため、独立したエンティティにします。

利用者と予約は1対多、会議室と予約も1対多です。利用者と会議室の間には「予約」を介した多対多の関係が成り立っており、予約エンティティがその橋渡しを担っています。

よくある間違い

ER図で多い間違いは、多対多の関係をそのまま残すことと、属性を置く場所を誤ることの2つです。どちらもテーブル設計の段階で破綻する原因になります。

多対多の扱い

多対多の関係は、間に中間のエンティティを置き、2つの1対多に分解して表します。関係データベースは、1つのテーブルの1行に別のテーブルの複数行を直接持たせられないためです。

たとえば生徒と講座は多対多ですが、そのまま線で結ぶと、どちらに外部キーを持たせるか決められません。「受講」というエンティティを挟み、生徒と受講が1対多、講座と受講が1対多とすれば解決します。中間のエンティティは、受講日や成績のように、組み合わせごとに決まる属性の置き場所にもなります。

属性の置き場所

属性は、「そのエンティティの主キーが決まれば、値が1つに決まるか」を基準に置き場所を判断します。この基準を満たさない属性は、別のエンティティに移すべきサインです。

実務で起きやすいのは、注文に「商品名」を持たせてしまう例です。商品名は商品IDが決まれば決まる情報なので、商品エンティティの属性です。注文に直接持たせると、商品名の変更時に過去の注文すべてを更新する必要が出たり、表記ゆれが生じたりします。同じ情報が複数の場所に散らばっていないかを見るのが、確認のポイントです。

設計書への展開

ER図は、そのまま終わりにせず、テーブル定義書などの設計書に展開して初めて開発に使えます。ER図は構造の全体像、テーブル定義書は項目の細部を担当します。

テーブル定義書との関係

ER図のエンティティは、テーブル定義書では1つのテーブルに対応し、属性は列に対応します。ER図で決めた主キーと外部キーが、そのままテーブルの主キー制約と外部キー制約になります。

ER図には書かなかった細部は、テーブル定義書で補います。IPAの事例集でも、データ項目定義書は「データ項目名、説明、データ型、桁数、編集方法」といった項目を定める成果物として紹介されています。テーブル定義書の書き方はテーブル定義書の書き方で整理しているので、あわせて確認してください。

レビューの観点

ER図のレビューでは、業務に合っているか、構造として破綻していないか、後工程に渡せるか、の3つを確認します。

• 業務の用語がすべてエンティティか属性として図に現れているか
• すべての線に、1対多などの多重度が明記されているか
• 多対多の関係が、中間のエンティティで分解されているか
• 属性が、主キーで値が決まるエンティティに置かれているか
• エンティティ名と属性名が、業務の担当者が使う言葉と一致しているか

上流工程で設計を担う経験は、案件の場面でも評価されやすい領域です。一般に、上流（戦略策定・要件定義）は下流（運用・保守）より高単価の傾向があり、IT戦略は月150〜200万円、運用・保守寄りは下限が50〜60万円台まで下がる幅があります。個別の条件で変わるため、あくまで目安として捉えてください。

案件の探し方については、大手企業や上場企業では与信や購買規定の都合から個人との直接契約を避け、エージェントを挟む3者間契約になるケースが多いとされています。独立を考える場合は、エージェント2〜3社に登録し、並行してリファラルも活用する進め方が一般的です。

出典・参考情報

1. Peter Chen「The Entity-Relationship Model: Toward a Unified View of Data」書誌情報（2026-10-07参照）
2. 独立行政法人情報処理推進機構（IPA）「超上流から攻めるIT化の事例集：要件定義」（2026-10-07参照）

本記事は2026年10月時点の情報に基づきます。最終更新日は2026年10月7日です。単価などの数値は目安であり、実際の条件は案件や契約によって異なります。