Data model review

Purpose

「後から直せないデータ構造」を作り込むリスクを防ぐ。 正規化・整合性・将来拡張・権限境界の観点でスキーマを点検し、設計判断を支える。

Use When

• 新しいテーブル・スキーマを設計するとき
• 既存スキーマに破壊的変更を加える前
• 「この持ち方で後で困らないか」を確認したいとき
• 認証・権限と紐づくデータ構造を決めるとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象: レビューするテーブル・スキーマ・ER 図
• 要件: そのデータが満たすべき業務要件
• アクセス主体: 誰が・どの権限で読み書きするか
• 想定規模: 件数・成長速度（わかる範囲で）

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: このスキーマで最も危ういのはどこか
2. 根拠: その論点をそう判断した理由
3. 設計レビュー表: 正規化 / 整合性 / 拡張性 / 権限境界の評価
4. 含意: 設計が示す将来の保守・移行コスト
5. 改善案: スキーマの改善（制約・インデックス・分割）
6. 代替案: 別の持ち方（正規化度・分割方針の変更）
7. 判断材料: スキーマ確定に必要な人間の確認事項

Review Lens

• 目的妥当性: 構造が業務要件を素直に表現できているか
• 範囲の過不足: 過剰正規化／非正規化のしすぎがないか
• 中長期リスク: 後から変更困難な構造に依存していないか
• LAB全体との整合性: LMS / 自動化 / B2B 展開のデータ要件と整合するか
• 非エンジニア理解可能性: データの持ち方を関係者に説明できるか
• 他LLM移植耐性: 判断が特定 DB 製品の前提に過度に依存していないか

Instructions

1. エンティティと関係を整理し、業務要件との対応を確認する
2. 整合性制約（一意・外部キー・NOT NULL）の過不足を点検する
3. 権限境界（誰がどの行・列にアクセスするか）を確認する
4. 将来の拡張（カラム追加・分割）が破壊的にならないか評価する
5. 計測・監査に必要なメタ列（作成/更新/削除）を確認する
6. 不明な要件は推測せず、確認事項として明示する

Guardrails

• 推測で要件を埋めない。不足は明示して止まる
• 「今動くから」で整合性制約を省略しない
• 破壊的スキーマ変更をロールバック方針なしに勧めない
• 設計の最終確定は人間に委ねる

LAB Cross-Check

観点	状態	備考
自動化フロー	—	自動化が読み書きするデータの整合性を確認したか
データ / 認証 / ログ	—	権限境界・監査列を含めて設計したか
実装 / 運用フロー	—	マイグレーション・運用が現実的か
非エンジニア理解可能性	—	データの持ち方を関係者に説明できるか
会員共有 / 再利用耐性	—	スキーマ設計が他機能にも転用できるか
他LLM移植耐性	—	判断が特定 DB 製品に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 確定したスキーマ定義と制約
• 成功条件: スキーマが要件を満たすと判断する基準
• 失敗条件: 設計を見直すトリガー
• 実行範囲: 変更してよいテーブル・マイグレーション
• 影響範囲: スキーマ変更が波及するクエリ・機能
• ロールバック方針: マイグレーション失敗時の戻し方（rollback-readiness 参照）
• コスト比較: 設計案ごとの移行・保守コスト

Further Reading

• auth-boundary-check skill — データに紐づく認証・認可境界
• pii-handling-review skill — 個人情報を含む場合の取り扱い
• rollback-readiness skill — スキーマ変更のロールバック準備
• glossary.md — PII 等の用語定義