データ要件定義の進め方
データ要件定義は、システムが扱うデータの種類・構造・量・保持期間・機密区分を明確化するフェーズです。物理DB設計（テーブル設計・インデックス設計）は対象外とし、「何のデータをどのように扱うか」の方針を固めます。
データ要件定義とは
データ要件定義は、機能要件・非機能要件と並んで要件定義の中核をなす成果物です。アーキテクチャ設計・DBスキーマ設計・セキュリティ設計すべてがこの定義を起点にします。
- ▸概念データモデル — ビジネス上の主要エンティティとその関係を可視化（ERD相当）
- ▸エンティティ一覧 — 各エンティティの属性・データ型・主要制約を列挙
- ▸データフロー — データの生成元・変換・消費先の流れ
- ▸PII・機密分類 — 個人情報・機密情報の種類と取り扱い方針
- ▸データライフサイクル — 生成〜保持〜アーカイブ〜削除の方針
概念データモデルの作成手順
Step 1: エンティティの洗い出し
業務要件書・機能要件書に登場する「もの」（名詞）を抽出し、エンティティ候補を列挙します。
例: ECサイトの場合
エンティティ候補: 顧客 / 商品 / 注文 / 注文明細 / 在庫 / 支払い / 配送
除外基準: 処理・状態・計算値はエンティティではなく属性または外部テーブルで表現
Step 2: リレーションの定義
エンティティ間のカーディナリティ（1:1 / 1:N / M:N）を定義します。M:N は中間エンティティ（注文明細など）に分解します。
1 : 1
顧客 ↔ 配送先住所（メイン）
1 : N
顧客 → 注文（複数注文）
M : N
注文 ↔ 商品（注文明細で分解）
Step 3: 主要属性の定義
各エンティティに主キー・外部キー・業務上重要な属性を列挙します。このフェーズでは全カラム列挙は不要です。
顧客エンティティの例:
PK: customer_id / 氏名 / メールアドレス（PII）/ 電話番号（PII）/ 登録日時 / ステータス
データ量の見積もりと整合性要件
データ量の分類
- 少量 — 数千件未満（シンプルRDBS + バックアップ）
- 中量 — 数万〜数百万件（RDS + Read Replica + キャッシュ）
- 大量 — 数千万件以上（シャーディング・NoSQL・DWH検討）
整合性モデルの選択
- 強整合性 — 金融・在庫・予約（ACID保証必須）
- 結果整合性 — SNS投稿数・集計・セッション（高スループット優先）
- イベントソーシング — 監査証跡・履歴が重要な業務
PII（個人情報）・機密情報の分類
個人情報保護法・GDPR・業界規制に基づき、データを機密レベルで分類します。このマッピングはセキュリティ設計・ログ設計・アクセス制御設計の入力になります。
データライフサイクル管理
データの保持期間・アーカイブ・削除方針は、法令（会社法7年・電帳法など）・業務要件・ストレージコストの観点から定義します。
よくある保持期間の基準
- ▸ 取引記録 — 7年（会社法・税務）
- ▸ 電子帳簿 — 10年（電帳法）
- ▸ セッションデータ — 90日以内
- ▸ ログ（監査用） — 1〜3年
- ▸ ユーザー削除後のPII — 30日以内に消去
アーカイブ・削除の設計パターン
- ▸ S3 Glacier — コールドアーカイブ（低頻度アクセス）
- ▸ ソフトデリート — deleted_at フラグで論理削除
- ▸ PII マスキング — 匿名化して分析用途に残す
- ▸ イベントログ — 変更不可・追記専用ストア
よくある失敗パターン
データ量を過小見積もり
「今は少ないから」とシンプルな構成を選び、1年後にスケールアップできない問題が発生。初期設計で3〜5年後のデータ量を試算しておく。
PII範囲の定義漏れ
IPアドレス・Cookie IDがPIIであることを見落とし、ログに平文で記録。GDPRや個人情報保護法の対象になり後から改修コストが膨大になる。
整合性要件の未定義
「とりあえず結果整合性で」と設定し、在庫の二重販売や残高の不整合が本番で発生。エンティティごとに整合性レベルを明示すること。
データライフサイクルの先送り
保持期間を定めずに全データを永久保存し、ストレージコストが指数関数的に増大。また個人情報の消去義務を果たせずコンプライアンスリスクになる。
ArchitectAI でのデータ要件定義
ArchitectAI の Step7「データ要件定義」では、業務要件・機能要件・非機能要件の成果物をもとに AI が概念データモデル・エンティティ一覧・データフロー・PII分類・ライフサイクル方針を自動生成します。
データ要件定義書を生成する →