クラウド移行

ロールバック計画ろーるばっくけいかく

ロールバック切り戻しリリース管理障害対応デプロイリスク管理

ロールバック計画について教えて

簡単に言うとこんな感じ！

システムをアップデートしたら不具合が出た！そんなとき「元に戻すボタン」を押す手順書がロールバック計画だよ。「もし失敗したら即座にどう元に戻すか」を事前に決めておくことで、最悪の事態でも被害を最小限に抑えられるんだ！

ロールバック計画とは

ロールバック計画（Rollback Plan） とは、システムの更新・移行・リリースを行う際に、何らかの問題が発生した場合に元の状態へ安全に戻すための手順と条件をあらかじめ定めた計画書のことです。「切り戻し計画」と呼ばれることもあります。

新しいシステムやバージョンに移行する際、「うまくいく前提」だけで進めると、障害発生時に混乱が拡大します。ロールバック計画は、「失敗したらどうするか」を成功シナリオと同じ熱量で設計するという考え方に基づいています。例えば、オンプレミスからクラウドへのシステム移行や、大規模なソフトウェアバージョンアップの際には必須とされます。

特にビジネスに直結するシステム（基幹業務システム・ECサイト・決済システムなど）では、数分の停止が数百万円の損失につながることもあります。ロールバック計画は、そのリスクを限定するための保険として機能します。

ロールバック計画の構成要素

構成要素	内容	具体例
切り戻し判断基準（Go/No-Go）	どんな状態になったらロールバックを実行するかの条件	エラー率が5%超え、応答速度が3秒以上など
タイムリミット	何時間以内に判断するかの期限	本番移行後2時間以内に問題なければ継続
手順書	元の状態に戻すための具体的な操作ステップ	DBのリストア手順、DNSの切り替え手順
担当者と連絡先	ロールバック実行時の責任者・承認者	PM、インフラ担当、DB管理者
データ整合性の確認方法	戻した後のデータが壊れていないかの確認手順	チェックサム確認、件数照合
ステークホルダーへの通知方法	切り戻し実施時の社内外への報告手順	ユーザー向けメール文面のひな形

「Go/No-Go判断」の考え方

ロールバック計画で最も重要なのが Go/No-Go（続行か中止か）の判断基準をあらかじめ数値で決めておくことです。「なんとなく様子を見よう」では判断が遅れ、被害が拡大します。以下のように事前に数値化しておくのが鉄則です。

【Go/No-Go 判断基準の例】

✅ Go（続行）の条件
  - エラー率 < 1%
  - 平均応答時間 < 1秒
  - 主要機能の動作確認 OK

❌ No-Go（ロールバック）の条件
  - エラー率 ≥ 5%
  - 決済機能・ログイン機能が動作不能
  - タイムリミット（移行後2時間）を超過

ロールバック方式の種類

ロールバックの実装方法はシステムの構造や規模によって異なります。

方式	説明	向いているケース
ブルー/グリーンデプロイ	旧環境（グリーン）を残したまま新環境（ブルー）に切り替え、問題時は即座に旧環境に戻す	クラウド環境・Webサービス
フィーチャーフラグ	機能のON/OFFをコードを変えずに切り替える	段階的機能リリース
DBバックアップ復元	移行前のスナップショットからデータベースを復元する	データ移行・バージョンアップ
DNS切り替え	DNSの向き先を旧サーバーに戻す	インフラ移行・クラウド移行

歴史と背景

1960〜70年代: データベースのトランザクション管理概念が登場。処理途中でエラーが起きたら「なかったこと」にするロールバックの概念が生まれる
1980〜90年代: 大規模な基幹システム（ERP等）の導入が増え、システム移行時の「切り戻し手順」が正式な工程として認識されるようになる
2000年代: ウォーターフォール開発におけるリリース管理の標準化が進み、ITIL（ITサービス管理のフレームワーク）がロールバック計画を変更管理の必須要素として定義
2010年代: クラウドとDevOpsの普及により、ブルー/グリーンデプロイやカナリアリリースなど、技術的に素早くロールバックできる仕組みが一般化
2020年代: クラウド移行案件の急増にともない、ロールバック計画はプロジェクト契約・要件定義の段階で必須ドキュメントとして求められるケースが増加

ロールバック計画と関連するデプロイ戦略

ロールバック計画は単独で存在するものではなく、どのようにリリースするか（デプロイ戦略） と密接に関係しています。

上図のように、ブルー/グリーンデプロイは旧環境をそのまま残しておくため、ロールバックが最も高速です。一方、通常の上書きデプロイでは旧バージョンを再デプロイする必要があり、ロールバックに時間がかかります。発注・選定の際は「ロールバックの速度とコスト」も含めてデプロイ方式を選ぶことが重要です。

実務でよくある落とし穴

ロールバック計画を作っていても、以下のような理由で「実際には使えない計画」になってしまうケースがあります。

よくある落とし穴	具体的な問題	対策
計画があるが試していない	リハーサルをしていないため、本番でロールバック手順が動かない	事前にステージング環境で必ず試す
データ変更を考慮していない	新システムで顧客データが追加・変更された後にロールバックすると、データが失われる	データのバックアップタイミングと整合性確保の手順を明記
判断者が決まっていない	障害時に「誰がロールバックを決断するか」が曖昧でパニックになる	承認者を事前に明確化し、連絡先も記載
タイムリミットを設けていない	ズルズルと様子を見てしまい、被害が拡大する	「移行後X時間でGo/No-Go判断」と明記
ベンダー依存の手順が不明	クラウドベンダーやSIerに依頼しないとロールバックできない状態	ベンダーの対応時間と手順を事前確認・契約に明記