D2: 概念データモデル

inputする成果物

成果物のパス	重要度	内容
docs/D1.business-requirements/product-requirement-document.md	重要	PRD(モデル化範囲と保有区分の判定元。§プロダクト概要の内製/外部の境界が「本システムが正典の概念」と「外部システムが正典の概念」を分ける根拠。§制約事項・§受け入れ基準はモデル化対象の絞り込みに用いる)
docs/D1.business-requirements/domain-requirements/*.md	重要	ドメイン要求仕様書群(ドメイン共通要求仕様書を含む)。§データアクセス要求(DOM-*-DATA-* / DOM-COMMON-SEC-DATA-*) がエンティティ抽出の第一候補、§業務ルール(DOM-*-BR-*) が関連・多重度・業務上の制約の根拠、§業務状態遷移 が業務状態を持つエンティティの判定元
docs/D1.business-requirements/domain-definition-document.md	補助	ドメイン定義書(DOM-*。エンティティのドメイン所属と、ドメイン別図・一覧表の並び順の根拠)
docs/D2.system-requirements/external-system-list.md	補助	外部システム一覧(EXT-*。外部参照エンティティの正典の特定に用いる。ドメイン要求仕様書に残る旧表記の記号 ID ではなく、本一覧の EXT-<連番> を引く)

outputする成果物

成果物のパス	内容
docs/D2.system-requirements/conceptual-data-model.md	概念データモデル本体。全ドメインの概念エンティティを 1 ファイルに集約する(ドメイン別・レイヤー別にファイルを分割しない)

使用するテンプレート

出力時は以下のテンプレートを読み込み、その章構成・図の枠・表の列構成に従う。

テンプレートのパス	内容
.claude/skills/d2-conceptual-data-model/template.md	概念データモデル テンプレート(タイトル + 章構成 + Mermaid 図の枠 + 表の列構成)

ドメイン別概念モデル図の節は、ドメイン定義書 §一覧 に載るドメインの数だけ繰り返す。

記法の正典サンプル

生成前に以下のサンプルを読み込み、エンティティ名の付け方・多重度の使い分け・関連ラベルの具体度・定義文と属性列の粒度・外部参照エンティティの書き方を引き写す。文言レベルの判断に迷ったときは、本スキルの規約とサンプルの実物を突き合わせて揃える。

サンプルのパス	内容
.claude/skills/d2-conceptual-data-model/example.md	申込受付ドメインの完成形 1 節(ドメイン別図 + エンティティ一覧・関連・業務状態の各抜粋)。他ドメイン/外部参照エンティティの引き込み方を含む

生成規約

以下は本成果物を生成・更新する際に守る規約。

文書構成(全ドメインを 1 ファイルに集約する)

• 本書は 全ドメインの概念エンティティが 1 枚のモデルとして結集した単一ファイル。ドメインをまたぐ関連(申込 と 顧客、申込 と 募集コンプライアンス証跡 等)こそが本書の主要な価値であるため、ドメイン単位でファイルを分けない。
• §概念エンティティ一覧・§エンティティ間の関連・§業務状態を持つエンティティ は、それぞれ 全ドメインを通した単一の表 とする(ドメインごとに表を割らない。ドメインは列で表現する)。CDM-* も文書全体の通し連番とする。
• 総数をハードコードしない: 「全 14 ドメイン」「全 38 エンティティ」のような件数を本文に書かない(エンティティ・ドメインの増減で即座に陳腐化し、更新漏れが誤情報になるため)。件数に言及したくなったら「全ドメイン」「ここに現れないエンティティ」のように 数を持たない表現 に置き換える。表の行数は表自体が示すため、本文で数える必要はない。
• ドメインごとに分かれるのは §ドメイン別概念モデル図 の節のみ。これは 1 枚の全体図では読めない詳細を補うための 同一モデルの部分ビュー であり、全体図・一覧表と重複するエンティティが現れるのは正しい(部分ビューにだけ登場するエンティティを作らない)。

抽象度(概念レベルを厳守する)

本書の最重要原則。本書は「業務上どのような概念が存在し、互いにどう関わるか」までを扱い、それをどう格納するかには踏み込まない。

• 書く: 業務言語での概念名、概念の定義、概念間の関連と多重度、業務上の一意性・存在依存、代表的な属性(概念名のみ)。
• 書かない: テーブル名・カラム名・データ型・桁・NULL 可否・主キー/外部キー・サロゲートキー・インデックス・正規化(第3正規形化 等)・履歴テーブル・採番方式。これらは下流の論理 ER 図・テーブル定義(D3)へ降ろす。
• 多対多を機械的に解消しない: 交差エンティティは「受取人指定」のように 業務上の固有名と意味を持つ場合にだけ 立てる。技術的解消のみを目的とした中間エンティティは作らない(多対多のまま残してよい)。
• 属性は代表的なものに絞る: 業務上その概念を識別・区別するうえで欠かせない属性(3〜6 個程度)に留める。項目の網羅は D3 のテーブル定義に降ろす。

エンティティの抽出と粒度

• 抽出源の優先順: ①各ドメイン要求仕様書 §データアクセス要求の「データ」列 → ②§業務状態遷移の対象物(状態を持つ = 独立した概念) → ③§業務ルールの目的語(「〜を記録する」「〜を判定する」の対象)。
• 1 エンティティの条件: 業務担当者が固有名で呼び、独立して識別・参照される概念であること。
• 束ねる: 同一ライフサイクルで一体に生成・更新・保持される概念は 1 エンティティとし、従属側は属性として持たせる(例: 申込人の住所・連絡先は顧客の属性、保険料払込方法は申込の属性)。
• 分ける: ライフサイクル(生成契機・更新頻度・保持期間)が異なるもの、または一方が他方に対して複数存在しうるものは別エンティティにする(例: 申込 と 受取人指定)。
• 同義語を統合する: ドメインをまたいで別名で呼ばれる同一概念は 1 エンティティに統合し、別名を「定義」列に併記する(例: 「設計書」と「プラン」)。ドメインごとに同義エンティティを重複計上しない。
• 外部が正典の概念: PRD §プロダクト概要・外部システム一覧で外部に委ねるとされた概念(商品・特約仕様、募集人、既存契約 等)は エンティティとして置いたうえで保有区分を「外部参照」とし、正典の EXT-* を定義列に明記する。本システム側が持つのは参照のための識別と業務上必要な最小限の属性である旨を書く。
• 証跡・ログ系: 監査ログ・募集コンプライアンス証跡のように業務上「1 件ずつ発生し保全される」概念はイベントエンティティとして立てる(記録媒体の話に落とさない)。

Mermaid 記法

骨格

• 図は ```mermaid フェンス内の erDiagram。2 段構えで描く: ①全体概念モデル図(全エンティティと主要な関連のみ。俯瞰用)、②ドメイン別概念モデル図(ドメイン定義書の並び順に 1 ドメイン 1 図。当該ドメインのエンティティに加え、関連する他ドメイン・外部参照のエンティティを引き込む)。
• 属性は図に書かない。Mermaid の ER 属性記法は型指定を前提とするため概念レベルの抽象度と合わない。属性は §概念エンティティ一覧 の「主な属性(概念)」列で表現する。
• 図に描いた関連は §エンティティ間の関連 の表にすべて現れること(逆も同様)。

エンティティ名

• エンティティ名はダブルクォートで囲む("申込" ||--|{ "受取人指定" : "...")。日本語名・記号を含む名称を安全に描画するため、全図で統一する。
• 図のエンティティ名は §概念エンティティ一覧 の「エンティティ名」列と 完全一致 させる(表記ゆれを作らない)。
• 外部が正典のエンティティは名称末尾に (外部) を付す(ER 図は色分け・グルーピングを持たないため、名称で区別する)。一覧表側のエンティティ名にも同じ (外部) を付けて一致させる。

多重度と関連ラベル

• 多重度は crow's foot 記法: ||--||(1 対 1)/ ||--o|(1 対 0..1)/ ||--o{(1 対 0..N)/ ||--|{(1 対 1..N)/ }o--o{(N 対 M)。必須・任意(| と o)を業務上の実態に合わせて使い分け、「とりあえず o{」にしない。
• 関連ラベルは業務言語の動詞句("申込の起点となる" / "受取人と受取割合を定める")。「持つ」「紐づく」のような無内容なラベルにしない。
• 同一エンティティ間に業務上異なる意味の関連が複数ある場合(例: 顧客が申込人・被保険者・受取人として登場する)は、関連を分けて別行で描き、ラベルで役割を書き分ける。

図の規模と分割

• 1 図あたり 15 エンティティ程度を上限とする。全体図が超える場合は主要な関連に絞り、詳細はドメイン別図に委ねる。
• ドメイン別図が上限を超える場合は、当該ドメインのエンティティ抽出が細かすぎないか(属性に落とせる概念を立てていないか)を先に疑う。それでも超える場合はドメインの分割要否をユーザーに確認する。

各表の埋め方

概念エンティティ一覧:

• ID: CDM-<連番> の通し番号。ドメインは ID に含めず「ドメイン」列で表現する。
• ドメイン: ドメイン定義書のドメインを ドメイン名: DOM-<コード> 形式で書く(例: 申込受付: DOM-APPL)。ドメイン ID を省略しない(本列がドメイン定義書とのトレーサビリティの担保点となるため)。複数ドメインで共用される概念は、その概念に第一義的な責務を持つドメイン(正典側)を 1 つだけ書く。
• エンティティ名: 業務言語の名詞(体言止め)。図のエンティティ名と完全一致させる。
• 区分: リソース(ヒト・モノ。業務前から存在し参照される概念)または イベント(コト。業務の実行により発生し、発生時点と主体を持つ概念)。
• 保有区分: 本システム(本システムが正典)または 外部参照(EXT-* が正典)。
• 定義: 業務上その概念が何を指すかを 1〜2 文。別名がある場合は併記する。外部参照の場合は正典の EXT-* を明記する。
• 主な属性(概念): 代表的な属性名を中黒区切りで列挙(型・桁は書かない)。
• 関連要求 ID: 抽出根拠となった DOM-*-DATA-* / DOM-COMMON-SEC-DATA-* / DOM-*-BR-*。

エンティティ間の関連:

• 関連元 / 関連先: エンティティ名(図と一致させる)。
• 多重度: <関連元側> : <関連先側> を最小..最大で表記する(1 : 0..N / 1 : 1..N / 0..1 : 1 / 0..N : 0..M)。図の crow's foot 記法と一致させる。
• 関連の意味: 業務上その関連が何を表すか。存在依存(親が消えたら子も存在しえない)・業務上の一意性制約がある場合はここに書く。
• 関連要求 ID: 関連の根拠となる DOM-*-BR-* 等。

業務状態を持つエンティティ:

• ドメイン要求仕様書 §業務状態遷移で状態が定義されている概念のみを挙げる。
• 状態遷移そのものは再掲しない。「主な業務状態」列に状態名を並べ、「定義元」列に当該ドメイン要求仕様書の §業務状態遷移へのリンクを置く(正典は上流にあり、本書は対応付けのみを担う)。

並び順

• 概念エンティティ一覧・ドメイン別図とも、ドメイン定義書 §一覧 の並び順(業務工程ドメイン → 横断ドメイン)を踏襲する。
• エンティティ間の関連は、関連元エンティティの CDM-* 昇順に並べる。

網羅(トレーサビリティ)

1 ドメインにつき最低 1 概念エンティティが存在する ことを本書の基本思想とする。ドメイン定義書に載るドメインは、いずれも業務上何らかの概念を扱うために立てられているため、エンティティが 1 つも立たないドメインは 抽出漏れを疑う。

生成・更新の完了前に、以下を機械的に突き合わせて確認する。

1. ドメインの網羅(必須): ドメイン定義書 §一覧 の全 DOM-<コード> が、§概念エンティティ一覧 の「ドメイン」列に 少なくとも 1 回 現れること。
   • 突き合わせ手順: ドメイン定義書側 grep -oE '^\| [A-Z]{3,6} \|' docs/D1.business-requirements/domain-definition-document.md | tr -d '| ' | sort -u と、本書側 grep -ohE 'DOM-[A-Z]+' docs/D2.system-requirements/conceptual-data-model.md | sed 's/^DOM-//' | sort -u の差集合を取り、差集合が空になるまで エンティティ抽出をやり直す。
   • 0 件のドメインが残った場合は、当該ドメイン要求仕様書の §データアクセス要求・§業務状態遷移を読み直し、①属性として他エンティティに吸収してしまっていないか、②他ドメインのエンティティに名前を奪われていないか(同義語統合の行きすぎ)を確認する。それでも立たない場合は エンティティを立てずに済ませず、要確認マーカーを付けたうえでユーザーにドメイン定義書側の見直し要否を確認する。
2. 要求 ID の網羅(必須): 全ドメイン要求仕様書の DOM-*-DATA-* / DOM-COMMON-SEC-DATA-* が、いずれかのエンティティの「関連要求 ID」列に 少なくとも 1 回 現れること。
   • 突き合わせ手順: grep -ohE 'DOM-[A-Z]+-(SEC-)?DATA-[0-9]+' docs/D1.business-requirements/domain-requirements/*.md | sort -u と、本書の同 grep 結果の差集合を取る。
3. 図と表の整合: 全体図・ドメイン別図に登場するすべてのエンティティが §概念エンティティ一覧 に存在すること(逆に、一覧にあって全体図・ドメイン別図のいずれにも現れないエンティティを作らないこと)。
4. 外部参照の実在: 保有区分 外部参照 のエンティティの正典 EXT-* が外部システム一覧に実在すること。