# Rollback Plan

> 実装・デプロイ・マイグレーションが失敗した場合に元の状態に戻すための手順を設計する。何を・どの順序で・誰が・どこまで戻すかを事前に定義する。

- Skill: `thinkyou0714/rollback-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/rollback-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/rollback-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/rollback-plan

---


## Purpose

「失敗した後に何をすればいいかわからない」を防ぐ。
実装着手前にロールバック手順を設計し、失敗時の混乱と復旧コストを最小化する。

## Use When

- 実装・デプロイ・DB マイグレーションの前
- 「失敗したらどうするか」が未定義のままタスクが進んでいる場合
- ホットフィックス・緊急パッチの前
- 新しい依存関係（ライブラリ・外部サービス）を導入する前

## Inputs

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

- **実装・変更内容**: 何をするか（コード / DB / 設定 / インフラ）
- **変更範囲**: 変更するファイル・テーブル・API・環境変数
- **現在の状態**: 変更前の状態（ブランチ / DB スキーマバージョン / デプロイバージョン）
- **外部依存**: 変更に伴う外部サービス・API の変更（Stripe / Supabase / Vercel 等）
- **許容ダウンタイム**: ロールバック中に受け入れられる最大停止時間

## Output Contract

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

1. **論点**: このロールバック設計を左右する核心的な判断軸
2. **根拠**: その論点をそう判断した理由
3. **ロールバック手順**: 段階別の具体的な手順
4. **含意**: ロールバック可能性の高さ/低さが示す設計上のリスク
5. **改善案**: ロールバックコストを下げるための変更設計上の工夫
6. **代替案**: 完全ロールバックが不可能な場合の部分ロールバック・補償手順
7. **判断材料**: 「このロールバック計画で進む / 計画を強化する / 変更設計を見直す」を選ぶための情報

### ロールバック手順 フォーマット

| ステップ | 操作内容 | 実行者 | 確認方法 | 所要時間概算 |
|---|---|---|---|---|
| 1 | （例: git revert / feature flag OFF） | AI / 人間 | （確認コマンド・URL） | （分） |
| 2 | （例: DB マイグレーションのロールバック） | AI / 人間 | | |
| 3 | （例: 環境変数の切り戻し） | AI / 人間 | | |
| 4 | （例: 動作確認） | AI / 人間 | | |

ロールバック不可能な操作（例: 不可逆 DB 変更、外部サービスへの通知）は「補償手順」として別途記載する。

## Review Lens

- **目的妥当性**: ロールバック手順が実際の変更に対して実行可能か
- **範囲の過不足**: 外部サービス（Stripe / Supabase）の状態変更が含まれているか
- **中長期リスク**: ロールバック後に一時的に整合性が失われる期間がないか
- **LAB全体との整合性**: Vercel / Supabase の具体的なロールバック方法が含まれているか
- **非エンジニア理解可能性**: ロールバック手順を非技術者が実行できるか
- **他LLM移植耐性**: 手順が Claude 固有の解釈に依存していないか

## Instructions

1. 変更を「コード / DB / 設定 / 外部サービス」に分類する
2. 各分類ごとにロールバック方法を具体的に記述する（コマンド・操作を含む）
3. 手順に依存関係がある場合は実行順序を明示する
4. 不可逆な操作を特定し、補償手順（データ修正・ユーザー通知等）を設計する
5. ロールバック後の確認手順（動作確認コマンド・監視確認）を含める
6. 所要時間の概算を付ける（ダウンタイム許容値と照合するため）
7. 最終判断は人間に委ねる

## Guardrails

- 「git revert で戻せる」だけで終わらせない。DB・設定・外部サービスを含める
- ロールバック後に整合性が崩れる箇所（例: 支払い記録と DB の状態の不一致）を省略しない
- 「おそらくロールバック可能」で不可逆操作を無視しない
- ロールバック手順に手動操作が含まれる場合、その人間への通知方法を明示する
- ロールバック計画が実行不可能な変更設計を推奨しない

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | n8n / Webhook フローのロールバックが含まれているか |
| データ / 認証 / ログ | — | Supabase スキーマ・RLS のロールバックが含まれているか |
| 実装 / 運用フロー | — | Vercel デプロイのロールバック（前バージョン revert）が含まれているか |
| 非エンジニア理解可能性 | — | ロールバック手順を説明できる言葉か |
| 会員共有 / 再利用耐性 | — | 手順フォーマットが他変更にも転用できるか |
| 他LLM移植耐性 | — | 手順が Claude 固有に依存していないか |

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

## Handoff Notes

- **要件**: ロールバック手順の定義（ステップ・実行者・確認方法）
- **成功条件**: ロールバック後に変更前の状態が確認できている
- **失敗条件**: ロールバック後もエラーが継続している / DB 整合性が崩れている
- **実行範囲**: ロールバックを実行してよいファイル・DB・環境
- **影響範囲**: ロールバックが波及する外部サービス・ユーザーへの影響
- **ロールバック方針**: （このスキル自体がロールバック方針の出力）
- **コスト比較**: ロールバック計画設計コスト vs ロールバック手順未定義のまま失敗するコスト

## Further Reading

- `implementation-gate` skill — 実装着手前のゲートチェック（ロールバック方針を要求）
- `patch-readiness` skill — パッチ適用前のロールバック準備確認
- `change-impact-scan` skill — 影響範囲の洗い出し（ロールバック対象の特定）
- `lab-data-auth-ops/rollback-readiness` skill — DB ロールバックの詳細確認
- [docs/CONTEXT.md](../../../docs/CONTEXT.md) — Vercel / Supabase のデプロイ環境