Rollback readiness

Purpose

「戻せないデータ変更」で本番を壊すリスクを防ぐ。 バックアップ・可逆性・検証手順を点検し、データ層の変更を安全に実行できる状態にする。

Use When

• スキーマ変更・マイグレーションを実行する前
• 一括更新・一括削除・データ移行を行う前
• 「失敗したら戻せるか」を確認したいとき
• failure-point-review / rollback-plan のデータ層版として使うとき

Inputs

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

• 対象変更: 実行するデータ変更の内容
• 対象データ量: 影響する件数・テーブル
• バックアップ状況: 直近バックアップの有無・復元可否
• 許容ダウンタイム: 復旧に許される時間

Output Contract

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

1. 論点: この変更で最も戻しにくいのはどこか
2. 根拠: その論点をそう判断した理由
3. ロールバック準備チェック: バックアップ / 可逆性 / 検証 / 手順
4. 含意: 戻せない場合に起きること
5. 改善案: 可逆性を高める手順（段階適用・シャドー書き込み）
6. 代替案: より安全な変更方法（後方互換マイグレーション）
7. 判断材料: 実行可否の判断に必要な人間の確認事項

Review Lens

• 目的妥当性: 変更が目的に対して最小の侵襲か
• 範囲の過不足: 一度に変えすぎていないか（段階適用の余地）
• 中長期リスク: 不可逆な変更（削除・型変更）の影響
• LAB全体との整合性: LMS / 自動化 / B2B 展開のデータ整合と矛盾しないか
• 非エンジニア理解可能性: 戻し方を関係者に説明できるか
• 他LLM移植耐性: 判断が特定 DB 製品の前提に依存していないか

Instructions

1. 変更を「可逆 / 不可逆」に分類する（削除・型変更は要注意）
2. 直近バックアップの存在と復元手順・所要時間を確認する
3. 後方互換な手順（追加→移行→切替→削除）に分割できるか検討する
4. 適用前の検証（ステージング・ドライラン）の有無を確認する
5. ロールバックのトリガー（失敗条件）と手順を明文化する
6. 不明な点は推測せず、実行をブロックして明示する

Guardrails

• バックアップ・復元手段の確認なしに実行を勧めない
• 不可逆変更（DROP・破壊的型変更）を軽視しない
• 「たぶん戻せる」を「戻せる」と扱わない
• 実行可否の最終判断は人間に委ねる

LAB Cross-Check

観点	状態	備考
自動化フロー	—	自動化が走る最中の変更影響を確認したか
データ / 認証 / ログ	—	バックアップ・整合性チェックを設計したか
実装 / 運用フロー	—	復元手順を実運用で実行できるか
非エンジニア理解可能性	—	戻し方を関係者に説明できるか
会員共有 / 再利用耐性	—	この準備手順が他の変更にも転用できるか
他LLM移植耐性	—	判断が特定 DB 製品に依存していないか

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

Handoff Notes

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

• 要件: 実行するデータ変更と段階適用の手順
• 成功条件: 変更が成功したと判断する基準
• 失敗条件 / ロールバック発動基準: 戻すと決めるトリガー
• 実行範囲: 変更してよいテーブル・データ
• 影響範囲: 変更が波及するクエリ・機能
• ロールバック方針: バックアップからの復元 or 逆マイグレーション手順
• コスト比較: 安全策（段階適用等）の追加工数

Further Reading

• rollback-plan skill — 実装・デプロイ全体のロールバック設計
• data-model-review skill — 変更対象スキーマの設計レビュー
• failure-point-review skill — データ変更を含むフローの障害点
• judgment-gates.md — GATE-1（実装着手ゲート）