data-model-reviewlisted

## 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 / 対象外 で記入すること。 ##