thinkyou0714 Purpose
「後から直せないデータ構造」を作り込むリスクを防ぐ。 正規化・整合性・将来拡張・権限境界の観点でスキーマを点検し、設計判断を支える。
Use When
- 新しいテーブル・スキーマを設計するとき
- 既存スキーマに破壊的変更を加える前
- 「この持ち方で後で困らないか」を確認したいとき
- 認証・権限と紐づくデータ構造を決めるとき
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 対象: レビューするテーブル・スキーマ・ER 図
- 要件: そのデータが満たすべき業務要件
- アクセス主体: 誰が・どの権限で読み書きするか
- 想定規模: 件数・成長速度（わかる範囲で）
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: このスキーマで最も危ういのはどこか
- 根拠: その論点をそう判断した理由
- 設計レビュー表: 正規化 / 整合性 / 拡張性 / 権限境界の評価
- 含意: 設計が示す将来の保守・移行コスト
- 改善案: スキーマの改善（制約・インデックス・分割）
- 代替案: 別の持ち方（正規化度・分割方針の変更）
- 判断材料: スキーマ確定に必要な人間の確認事項
Review Lens
- 目的妥当性: 構造が業務要件を素直に表現できているか
- 範囲の過不足: 過剰正規化／非正規化のしすぎがないか
- 中長期リスク: 後から変更困難な構造に依存していないか
- LAB全体との整合性: LMS / 自動化 / B2B 展開のデータ要件と整合するか
- 非エンジニア理解可能性: データの持ち方を関係者に説明できるか
- 他LLM移植耐性: 判断が特定 DB 製品の前提に過度に依存していないか
Instructions
- エンティティと関係を整理し、業務要件との対応を確認する
- 整合性制約（一意・外部キー・NOT NULL）の過不足を点検する
- 権限境界（誰がどの行・列にアクセスするか）を確認する
- 将来の拡張（カラム追加・分割）が破壊的にならないか評価する
- 計測・監査に必要なメタ列（作成/更新/削除）を確認する
- 不明な要件は推測せず、確認事項として明示する
Guardrails
- 推測で要件を埋めない。不足は明示して止まる
- 「今動くから」で整合性制約を省略しない
- 破壊的スキーマ変更をロールバック方針なしに勧めない
- 設計の最終確定は人間に委ねる
LAB Cross-Check
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化が読み書きするデータの整合性を確認したか |
| データ / 認証 / ログ | — | 権限境界・監査列を含めて設計したか |
| 実装 / 運用フロー | — | マイグレーション・運用が現実的か |
| 非エンジニア理解可能性 | — | データの持ち方を関係者に説明できるか |
| 会員共有 / 再利用耐性 | — | スキーマ設計が他機能にも転用できるか |
| 他LLM移植耐性 | — | 判断が特定 DB 製品に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。
- 要件: 確定したスキーマ定義と制約
- 成功条件: スキーマが要件を満たすと判断する基準
- 失敗条件: 設計を見直すトリガー
- 実行範囲: 変更してよいテーブル・マイグレーション
- 影響範囲: スキーマ変更が波及するクエリ・機能
- ロールバック方針: マイグレーション失敗時の戻し方（
rollback-readiness参照） - コスト比較: 設計案ごとの移行・保守コスト
Further Reading
auth-boundary-checkskill — データに紐づく認証・認可境界pii-handling-reviewskill — 個人情報を含む場合の取り扱いrollback-readinessskill — スキーマ変更のロールバック準備- glossary.md — PII 等の用語定義