ロールバック演習プレイブック：壊れたリリースを5分で復旧する

ロールバックが怖く感じる理由（そして練習が効く理由）

テストでは問題なく見えたリリースが、実トラフィックの最初の5分で壊れることがあります。怖さの本質はバグそのものではなく、不確実性です：何が変わったのか、何を安全に元に戻せるのか、ロールバックで状況が悪化しないか。

リリース直後の障害は単純で目に見えやすいことが多いです。新しいボタンがモバイルでページをクラッシュさせるかもしれません。バックエンドの変更で正しいデータ形が返らずチェックアウトが失敗するかもしれません。小さな設定変更でログインやメール、決済が壊れることもあります。たとえ修正が簡単でも、ユーザーが見ているためにプレッシャーが高まり、1分1秒が重く感じられます。

ロールバックの手順が不明確だとパニックが始まります。人々は同じ質問を同時に投げます：スナップショットはあるか？最後に正常だったバージョンはどれか？アプリを戻すならデータベースはどうする？誰が実行権限を持っている？これらが書かれていないと、チームはサービス復旧ではなく議論に時間を失います。

インシデント中に推測で動くことには実害があります。時間を失い、ユーザーの信頼を損ない、急いだ変更が二次障害を招くこともあります。エンジニアはデバッグ、メッセージ発信、意思決定に同時に引き抜かれます。

練習を行うとムードが変わります。不確実性が筋肉記憶に置き換わるからです。良いロールバック演習は「コードを元に戻せるか」だけでなく、繰り返せるルーティンです：何をスナップショットするか、何を復元するか、何を確認するか、誰が実行を許可するか。数回行えば、ロールバックは失敗の印ではなく安全装置になります。

デプロイ環境が既にスナップショットと復元をサポートしているなら（Koder.aiを含む一部プラットフォームはリリースフローに組み込んでいます）、演習は簡単になります。「既知の正常に戻す」が通常の操作であれば、緊急手順ではなくなります。いずれにせよ目標は同じです：その瞬間に誰も即興で動かないこと。

「5分で復旧」が本当に意味すること

「5分で復旧」とは、すべてが完璧に戻るという意味ではありません。新しいリリースがまだ壊れていても、ユーザーを動作するバージョンに素早く戻せるという意味です。

サービスを優先し、修正は後回しにします。サービスを素早く復元できれば、根本原因を探すための冷静な時間が得られます。

5分は行動のための時間で、議論のためではない

タイマーは「ロールバックを行う」と合意した時点で始まります。長い議論は含みません。

事前にロールバックのトリガーを決めておきましょう。例：「デプロイ後3分でチェックアウトエラーがX%を超えたらロールバックする」。トリガーが発動したら、台本に従って行動します。

「復旧」と見なす基準

「復旧」は、ユーザーが安全でシステムが安定したことを示す小さな信号の集合です。簡潔で確認しやすくします：

• 主要なユーザーアクションが再び動作する（ログイン、チェックアウト、検索、あるいはアプリの必須機能）
• エラーレートがほぼ通常値に戻る
• レイテンシが許容範囲に戻る
• クラッシュループや再起動の嵐がない

これらが良ければ5分タイマーを止めます。その他は後回しにできます。

演習を正直にするために、5分経路で行わない事項を明示してください：深いデバッグ、コード変更やホットフィックス配布、エンジニアリング作業に発展することなどです。

チームが繰り返せるロールバック手法を選ぶ

ロールバックが速く感じられるのは、判断がほぼ事前に決まっている場合です。ほとんどのインシデントで使える方法を1つ選び、それが退屈になるまで練習しましょう。

演習は次の4つの疑問に答えるべきです：

• ロールバックするかホットフィックスするか？
• 何にロールバックするか？
• 何がトリガーか？
• 誰が「実行する」と言えるか？

ロールバック vs ホットフィックス：デフォルトを決める

ロールバックは、新リリースがユーザーやデータに実害を与えており、既に既知の正常なバージョンがある場合に有効です。ホットフィックスは影響が小さく、変更が孤立していて安全にパッチできると確信できる場合に適します。

シンプルなデフォルトが有効です：主要なアクション（チェックアウト、ログイン、サインアップ）が完了できない、またはエラーレートが跳ね上がる場合はまずロールバックし、その後で修正します。ホットフィックスは迷惑だが危険でない問題にとっておきます。

ロールバック対象を選ぶ

「対象」は議論なしに素早く選べるものであるべきです。ほとんどのチームは次の3つのいずれかを使います：

• 直前のバージョン（最後にチェックを通過したリリース）
• 復元可能なデプロイスナップショット
• 設定のみのロールバック（機能フラグや環境設定の変更）

信頼できるスナップショットがあれば、それをデフォルトにしてください。プレッシャー下で最も再現性が高い方法です。コードは問題ないが設定が原因なら、設定のみのロールバックを別パスとして用意します。

また「前の正常」を何とみなすかを定義しておきます。これは監視チェックを完了し、アクティブなインシデントがなかった最も最近のリリースとします。記憶に頼ってはいけません。

トリガーと権限を定義する

インシデント中に会議を待たないでください。ロールバックを開始するトリガーを書き出し、それに従いましょう。典型的なトリガーは、主要フローの破壊が数分続く、エラーレートやレイテンシが閾値を超える、データリスク（誤書き込み、重複課金）、セキュリティやプライバシーの懸念などです。

次に誰がロールバックを承認できるか決めます。1つの役割（インシデントリードまたはオンコール）とバックアップを選びます。その他の人は意見を述べられますが、ブロックできません。トリガーが発動し承認者が「ロールバック」と言ったら、チームは毎回同じ手順を実行します。

毎回のリリース前にスナップショットすべきもの

ロールバック演習は、既知の正常な状態に素早く戻せることが前提です。スナップショットは「あると良いもの」ではなく、何が動いていたか、何が変わったか、どう戻すかを証明する領収書です。

事前に取るべき5つ

リリース前に次を探さずに取得できるようにしてください：

• 出荷した正確なアプリビルド： コミットハッシュ、バージョン番号、ビルドアーティファクト（コンテナタグ、バンドル、パッケージ）
• データベースの状態とマイグレーション計画： どのマイグレーションが適用され、可逆かどうか。リスクの高い変更はすぐに復元できるバックアップやスナップショットを取る。
• デプロイ時の設定： 機能フラグ、環境変数、サードパーティのエンドポイント、何が変わったか。シークレットは安全なシステムに置くが、変更のバージョン記録は必要。
• インフラとルーティング設定： ドメイン、証明書、ロードバランサのルール、トラフィックの向きに関するスイッチ類。
• 短いリリースノート： 何が変わったか一文、ロールバックの確認方法一文。

データベースの安全性が罠になりがちです。アプリのロールバックは速くても、データベースが新しいスキーマを期待していると役に立ちません。リスクのあるマイグレーションは2段階リリース（先にフィールドを追加し、後で使い始める）を計画して、ロールバックが可能な状態にしておきましょう。

スナップショット名は秒で見つけられるように

どこでも1つの命名ルールを使い、ソート可能にしてください：

prod-2026-01-09-1420-v1.8.3-commitA1B2C3

環境、タイムスタンプ、バージョン、コミットを含めます。ツールがUIでスナップショットをサポートするなら、そこで同じ命名ルールを使って誰でも適切な復元ポイントを見つけられるようにします。

役割：誰が何をクリックするか（見ているだけの人は誰か）

演習は各自の担当を知っていると速く落ち着いて行えます。目標は「皆が飛び込む」ことではなく、1人が決定し、1人が実行し、1人が検証し、1人が情報を発信することです。

小～中規模チームには次の役割がうまく機能します（1人が2役を兼ねても構いませんが、演習ではDeployerとVerifierを兼ねるのは避けてください）：

• インシデントリード（時間管理と決定）： 成功目標を述べ、ロールバックを宣言する。
• デプロイヤー（実作業者）： ロールバック手順を正確に実行し、行っていることを口頭で説明する。
• バリファイア（動作確認者）： 必須チェックを実行して主要信号を監視する。
• コミュニケーター（外部への一声）： ステークホルダーやサポートに短く定期的な更新を投稿する。

権限がこの計画を現実にするか文書にするだけかを決めます。演習前に誰が本番をロールバックできるか、緊急時の扱いを合意してください。

簡単な設定例：

• オンコールローテーションや演習ウィンドウ中にデプロイヤーにロールバック権限を付与する。
• インシデントリードが承認を出せる（たとえボタンを持っていなくても）。
• バリファイアにダッシュボードやログの読み取り権限を与える。
• ブレイクグラスオプションを用意する（監査付き、時間制限あり）。
• 演習セットアップ時にアクセスを確認し、5分タイマー中に確認するのは避ける。

スナップショットとロールバックをサポートするプラットフォーム（Koder.aiを含む）を使っているなら、誰がスナップショットを作るか、誰が復元するか、その操作がどこに記録されるかを決めておきます。

ステップバイステップ：ロールバック演習の実行手順

ロールバック演習は火災訓練のように、同じ手順、同じ言葉、同じクリック場所で行うと効果的です。目標は完璧さではなく、オンコールの誰でも議論せずに最後の正常バージョンを素早く復旧できることです。

開始前に

明確なトリガーを1つ選び、演習開始時に声に出して宣言します。例：「チェックアウトが1分以上500を返す」や「デプロイ直後のエラーレートが通常の5倍」など。声に出すことでチームがトラブルシューティングモードに流れ込むのを防ぎます。

ランブックの横に短い準備チェックリストを置いてください：

• ライブのヘルス信号（稼働率、エラーレート、主要ユーザーフロー）が見えていることを確認する
• 最後に正常だったバージョン識別子（タグ、ビルド、スナップショット名）を確認する
• ロールバックを実行する場所を確認する（CI/CD、ホスティングコンソール、プラットフォームUI）
• 新しいデプロイを一時停止する方法を確認する
• タイムスタンプを記録する担当を確認する

5分間の実行手順

1. タイマーを開始。 1人がトリガーと決定を述べる：「ロールバックを今行います。」

2. 変更を凍結。 新しいデプロイを一時停止し、システムを途中で変えるような不要な編集を止める。

3. 最後のチャンスのスナップショットを取る（安全で速ければ）。 後で壊れた状態を再現する必要があれば役立つ。明確に名付けて先に進む。

4. ドキュメントどおりにロールバック操作を実行する。 即興はしない。確認プロンプトは声に出して読んで、記録担当が何が行われたかを捕捉できるようにする。

5. 信頼できる一箇所でロールバック完了を確認する。 毎回同じ画面と同じ指標を使う（デプロイ履歴ビュー、現在のバージョンラベル、明確なステータスインジケータなど）。

操作直後に、忘れないうちに重要なことを記録します：

• 判断時刻（トリガーを述べた時刻）
• ロールバック開始時刻（最初のクリック／コマンド）
• ロールバック完了時刻（前のバージョンがアクティブになった時刻）
• 最初のグリーン検証時刻（主要チェックが通った時刻）
• 何か驚いたこと（権限不足、分かりにくいボタン、遅いステップ）

ロールバックが5分以上かかるなら言い訳しないでください。遅いステップを見つけてランブックを修正し、演習をやり直します。

ロールバック後に何を検証するか

ロールバックが「成功」なのはユーザーがそう感じたときです。目的は旧バージョンがデプロイされたことを証明することではなく、サービスが再び使えるようになり安定していることを示すことです。

検証は小さく再現可能にしてください。リストが5個以上になると、ストレス下で省略されがちです。

合格すべき3～5のチェック

素早く実行でき、合否が明確なチェックを使います：

• ユーザーがログイン（またはサインアップ）してホーム画面にエラーなく到達できる
• コアのトランザクションが動作する（決済、予約、フォーム送信）
• 主要なAPIエンドポイントが200を返しレスポンスが正常に見える
• 管理／サポート側で重要な操作ができる（返金、キャンセル、ステータス更新）
• よく壊れるエッジフローがまだ動く（パスワードリセット、ファイルアップロード、検索）

機能チェックの後で、信頼しているシンプルなシステムヘルスを一目で確認します。エラーレートが数分で通常値に戻り、レイテンシの急上昇が止まることを見たいです。

目に見えない部分も動いているか確認します。バックグラウンドジョブが処理されキューが詰まっていないか、データベース接続が安定しているか、ロックの山がないかなど簡単に確認します。アプリが書き込みできるかもチェックします。

最後に外部とのやり取りを必要に応じてテストします。安全に行えるなら決済テスト、メール配信確認、Webhookが受け入れられているか（少なくとも失敗していないか）を確認します。

「全て正常」の文言を決めておく

誰も即興で言わないように事前に1文を用意しておきます：

“ロールバック完了。コアフローを検証済み（ログイン＋チェックアウト）。エラーレートとレイテンシは通常に戻った。30分間監視。次の更新は14:30。”

例：壊れたリリースとクリーンな5分復旧

火曜日の10:02。新しいリリースが出て、1分以内に一部のユーザーがログインできなくなる。ユーザーの中には「無効なセッション」が出る人や、永遠にスピナーが回る人がいる。サインアップはまだ動くため、問題の発見が遅れることもある。

最初のシグナルは大きな障害でないことが多いです。静かなスパイク：サポートチケット、ログイン成功率の低下、怒ったユーザーからのメッセージなど。オンコールが「デプロイ後5分でログイン成功率が18%低下」のアラートを見て、サポートが「3人が更新後にログインできない」と投稿します。

5分での復旧（実際の流れ）

演習を練習しているチームは長く議論しません。確認し、決定し、行動します。

• 10:03：オンコールが実害を確認しインシデントリードを指名。
• 10:04：ロールバックの決定。ルール：ログインが壊れていて安全な修正が2分以内に見込めない場合はロールバック。
• 10:05：デプロイヤーが前の正常なスナップショットにロールバックをトリガー。
• 10:06：トラフィックが前のバージョンに戻る。チームがWebとモバイルでログインを再テスト。
• 10:07：インシデントリードが「ログイン復旧、10分監視」と投稿し、サポートに影響ユーザーへの返信を依頼。

何がロールバックされるか：WebとAPIサービスのアプリケーションコードと設定。何がそのままか：データベースとユーザーデータ。

もしリリースにデータベースマイグレーションが含まれていたら、5分経路でデータベースをロールバックしないのがルールです。マイグレーションは後方互換にするか、デプロイ前に二重チェックを入れてください。

何を伝えるか（実行中と実行後）

ロールバック中、インシデントリードは数分ごとに短い更新を投稿します：ユーザーが何を見ているか、どのアクションをしているか、次の更新がいつか。例：「ログインを復旧するために直近のリリースをロールバック中。次の更新は2分後。」

ロールバック後、ループを閉じます：「ログインは通常に戻りました。原因調査中です。発生原因と再発防止策を共有します。」

よくあるロールバック演習の失敗（と簡単な対処法）

ロールバック演習は退屈に感じられるべきです。演習が緊張するなら、それは本物のギャップ（アクセス、スナップショット不足、手順が個人の頭の中にしかない等）を露呈しています。

分単位で時間を無駄にする失敗例

• 想定されたアクセスで練習していて実際の権限で練習していない。 インシデント中にデプロイできない、設定変更できない、ダッシュボードに入れないことに気づく。対策：演習は実際に使うアカウントと役割で行う。

• スナップショットはあるが不完全か見つけにくい。 アプリだけスナップショットして環境変数や機能フラグ、ルーティングを忘れる。あるいは名前が意味をなさない。対策：スナップショット作成をリリースステップに組み込み、命名ルールを設け、演習で見えて復元可能か検証する。

• データベースマイグレーションでロールバックが危険になる。 互換性のないスキーマ変更が速いロールバックをデータ問題に変える。対策：追加型マイグレーションを優先する。破壊的変更が避けられない場合はリリースに明記してフォワード修正を計画する。

• ユーザーが感じることを確認する前に成功宣言してしまう。 デプロイは戻ったがログインはまだ壊れている、ジョブが詰まっている。対策：検証は短くても実際的に行い、タイムボックスする。

• 演習が繰り返せないほど複雑になっている。 ツールが多すぎ、チェックが多すぎ、声が多すぎ。対策：演習を1ページ、1オーナーに縮小する。単一のランブックと1つの通信チャネルでできないなら、本番で使えません。

良いロールバック演習は習慣であり、英雄的パフォーマンスではありません。落ち着いて終えられないならステップを減らし、落ち着いてできるようになってから本当にリスクを下げるものだけを追加してください。

クイックチェックリストと次のステップ

ロールバック演習は皆が同じ1ページのチェックリストに従うと最も効果的です。チームが実際に見る場所に固定しておきましょう。

10分未満で実行できるコンパクト版（準備と検証を含む）：

• リリース前： ロールバックポイント（スナップショット／バージョン）を確認し、期待される“正常動作”を記録し、役割（デプロイヤー、バリファイア、コミュニケーション）を割り当てる。
• トリガー： 「ロールバック開始」を宣言し、タイマーを始め、新規デプロイを凍結する。
• ロールバック操作： 最後の既知の正常リリースを復元し、何をクリックしたか順番を記録する。
• 検証： 2～3の重要チェック（ログイン、主要ワークフロー、1つの統合またはAPIチェック）を行い、エラーレート低下を確認する。
• クローズ： 「サービス安定」を宣言し、3点を書き留める（何がうまくいったか、何が遅らせたか、何を変えるか）、デプロイ凍結を解除する。

演習は手順が普通に感じられる頻度で行います。月1回が良いデフォルトです。プロダクトが日々変わるなら隔週でも良いですが、検証はトップユーザーパスに集中させてください。

各演習後、同じ日にランブックを更新します。リリースノートと一緒に保管し、「最終テスト日」を日付付きで追記して古い手順を信用しないようにします。

改善に役立つものだけを測定します：

• ロールバック時間（宣言から復旧まで）
• 検証時間（復旧から安定まで）
• 役割の明確さ（どこでためらいや重複があったか）
• 欠けていた情報（認証情報、権限、スナップショットの場所）

もしチームがKoder.ai上で構築しているなら、スナップショットとロールバックを習慣の一部にしてください：スナップショットに一貫した名前を付け、オンコールで使う同じインターフェースで復元リハーサルを行い、検証者のチェックにカスタムドメインや主要統合を含めておきます。これをランブックに書いておくと演習が日常の出荷フローに沿います。