2025年8月16日·1 分
ロールバック演習プレイブック：壊れたリリースを5分で復旧する
このロールバック演習で、壊れたリリースを5分で復旧するリハーサルを行えます：何をスナップショットするか、何を確認するか、演習中に誰が何をクリックするかを定義します。
このロールバック演習で、壊れたリリースを5分で復旧するリハーサルを行えます：何をスナップショットするか、何を確認するか、演習中に誰が何をクリックするかを定義します。
テストでは問題なく見えたリリースが、実トラフィックの最初の5分で壊れることがあります。怖さの本質はバグそのものではなく、不確実性です：何が変わったのか、何を安全に元に戻せるのか、ロールバックで状況が悪化しないか。
リリース直後の障害は単純で目に見えやすいことが多いです。新しいボタンがモバイルでページをクラッシュさせるかもしれません。バックエンドの変更で正しいデータ形が返らずチェックアウトが失敗するかもしれません。小さな設定変更でログインやメール、決済が壊れることもあります。たとえ修正が簡単でも、ユーザーが見ているためにプレッシャーが高まり、1分1秒が重く感じられます。
ロールバックの手順が不明確だとパニックが始まります。人々は同じ質問を同時に投げます：スナップショットはあるか？最後に正常だったバージョンはどれか？アプリを戻すならデータベースはどうする？誰が実行権限を持っている？これらが書かれていないと、チームはサービス復旧ではなく議論に時間を失います。
インシデント中に推測で動くことには実害があります。時間を失い、ユーザーの信頼を損ない、急いだ変更が二次障害を招くこともあります。エンジニアはデバッグ、メッセージ発信、意思決定に同時に引き抜かれます。
練習を行うとムードが変わります。不確実性が筋肉記憶に置き換わるからです。良いロールバック演習は「コードを元に戻せるか」だけでなく、繰り返せるルーティンです：何をスナップショットするか、何を復元するか、何を確認するか、誰が実行を許可するか。数回行えば、ロールバックは失敗の印ではなく安全装置になります。
デプロイ環境が既にスナップショットと復元をサポートしているなら（Koder.aiを含む一部プラットフォームはリリースフローに組み込んでいます）、演習は簡単になります。「既知の正常に戻す」が通常の操作であれば、緊急手順ではなくなります。いずれにせよ目標は同じです：その瞬間に誰も即興で動かないこと。
「5分で復旧」とは、すべてが完璧に戻るという意味ではありません。新しいリリースがまだ壊れていても、ユーザーを動作するバージョンに素早く戻せるという意味です。
サービスを優先し、修正は後回しにします。サービスを素早く復元できれば、根本原因を探すための冷静な時間が得られます。
タイマーは「ロールバックを行う」と合意した時点で始まります。長い議論は含みません。
事前にロールバックのトリガーを決めておきましょう。例：「デプロイ後3分でチェックアウトエラーがX%を超えたらロールバックする」。トリガーが発動したら、台本に従って行動します。
「復旧」は、ユーザーが安全でシステムが安定したことを示す小さな信号の集合です。簡潔で確認しやすくします：
これらが良ければ5分タイマーを止めます。その他は後回しにできます。
演習を正直にするために、5分経路で行わない事項を明示してください：深いデバッグ、コード変更やホットフィックス配布、エンジニアリング作業に発展することなどです。
ロールバックが速く感じられるのは、判断がほぼ事前に決まっている場合です。ほとんどのインシデントで使える方法を1つ選び、それが退屈になるまで練習しましょう。
演習は次の4つの疑問に答えるべきです：
ロールバックは、新リリースがユーザーやデータに実害を与えており、既に既知の正常なバージョンがある場合に有効です。ホットフィックスは影響が小さく、変更が孤立していて安全にパッチできると確信できる場合に適します。
シンプルなデフォルトが有効です：主要なアクション（チェックアウト、ログイン、サインアップ）が完了できない、またはエラーレートが跳ね上がる場合はまずロールバックし、その後で修正します。ホットフィックスは迷惑だが危険でない問題にとっておきます。
「対象」は議論なしに素早く選べるものであるべきです。ほとんどのチームは次の3つのいずれかを使います：
信頼できるスナップショットがあれば、それをデフォルトにしてください。プレッシャー下で最も再現性が高い方法です。コードは問題ないが設定が原因なら、設定のみのロールバックを別パスとして用意します。
また「前の正常」を何とみなすかを定義しておきます。これは監視チェックを完了し、アクティブなインシデントがなかった最も最近のリリースとします。記憶に頼ってはいけません。
インシデント中に会議を待たないでください。ロールバックを開始するトリガーを書き出し、それに従いましょう。典型的なトリガーは、主要フローの破壊が数分続く、エラーレートやレイテンシが閾値を超える、データリスク（誤書き込み、重複課金）、セキュリティやプライバシーの懸念などです。
次に誰がロールバックを承認できるか決めます。1つの役割（インシデントリードまたはオンコール）とバックアップを選びます。その他の人は意見を述べられますが、ブロックできません。トリガーが発動し承認者が「ロールバック」と言ったら、チームは毎回同じ手順を実行します。
ロールバック演習は、既知の正常な状態に素早く戻せることが前提です。スナップショットは「あると良いもの」ではなく、何が動いていたか、何が変わったか、どう戻すかを証明する領収書です。
リリース前に次を探さずに取得できるようにしてください：
データベースの安全性が罠になりがちです。アプリのロールバックは速くても、データベースが新しいスキーマを期待していると役に立ちません。リスクのあるマイグレーションは2段階リリース（先にフィールドを追加し、後で使い始める）を計画して、ロールバックが可能な状態にしておきましょう。
どこでも1つの命名ルールを使い、ソート可能にしてください：
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
環境、タイムスタンプ、バージョン、コミットを含めます。ツールがUIでスナップショットをサポートするなら、そこで同じ命名ルールを使って誰でも適切な復元ポイントを見つけられるようにします。
演習は各自の担当を知っていると速く落ち着いて行えます。目標は「皆が飛び込む」ことではなく、1人が決定し、1人が実行し、1人が検証し、1人が情報を発信することです。
小～中規模チームには次の役割がうまく機能します（1人が2役を兼ねても構いませんが、演習ではDeployerとVerifierを兼ねるのは避けてください）：
権限がこの計画を現実にするか文書にするだけかを決めます。演習前に誰が本番をロールバックできるか、緊急時の扱いを合意してください。
簡単な設定例：
スナップショットとロールバックをサポートするプラットフォーム（Koder.aiを含む）を使っているなら、誰がスナップショットを作るか、誰が復元するか、その操作がどこに記録されるかを決めておきます。
ロールバック演習は火災訓練のように、同じ手順、同じ言葉、同じクリック場所で行うと効果的です。目標は完璧さではなく、オンコールの誰でも議論せずに最後の正常バージョンを素早く復旧できることです。
明確なトリガーを1つ選び、演習開始時に声に出して宣言します。例：「チェックアウトが1分以上500を返す」や「デプロイ直後のエラーレートが通常の5倍」など。声に出すことでチームがトラブルシューティングモードに流れ込むのを防ぎます。
ランブックの横に短い準備チェックリストを置いてください：
タイマーを開始。 1人がトリガーと決定を述べる：「ロールバックを今行います。」
変更を凍結。 新しいデプロイを一時停止し、システムを途中で変えるような不要な編集を止める。
最後のチャンスのスナップショットを取る（安全で速ければ）。 後で壊れた状態を再現する必要があれば役立つ。明確に名付けて先に進む。
ドキュメントどおりにロールバック操作を実行する。 即興はしない。確認プロンプトは声に出して読んで、記録担当が何が行われたかを捕捉できるようにする。
信頼できる一箇所でロールバック完了を確認する。 毎回同じ画面と同じ指標を使う（デプロイ履歴ビュー、現在のバージョンラベル、明確なステータスインジケータなど）。
操作直後に、忘れないうちに重要なことを記録します：
ロールバックが5分以上かかるなら言い訳しないでください。遅いステップを見つけてランブックを修正し、演習をやり直します。
ロールバックが「成功」なのはユーザーがそう感じたときです。目的は旧バージョンがデプロイされたことを証明することではなく、サービスが再び使えるようになり安定していることを示すことです。
検証は小さく再現可能にしてください。リストが5個以上になると、ストレス下で省略されがちです。
素早く実行でき、合否が明確なチェックを使います：
機能チェックの後で、信頼しているシンプルなシステムヘルスを一目で確認します。エラーレートが数分で通常値に戻り、レイテンシの急上昇が止まることを見たいです。
目に見えない部分も動いているか確認します。バックグラウンドジョブが処理されキューが詰まっていないか、データベース接続が安定しているか、ロックの山がないかなど簡単に確認します。アプリが書き込みできるかもチェックします。
最後に外部とのやり取りを必要に応じてテストします。安全に行えるなら決済テスト、メール配信確認、Webhookが受け入れられているか（少なくとも失敗していないか）を確認します。
誰も即興で言わないように事前に1文を用意しておきます：
“ロールバック完了。コアフローを検証済み（ログイン＋チェックアウト）。エラーレートとレイテンシは通常に戻った。30分間監視。次の更新は14:30。”
火曜日の10:02。新しいリリースが出て、1分以内に一部のユーザーがログインできなくなる。ユーザーの中には「無効なセッション」が出る人や、永遠にスピナーが回る人がいる。サインアップはまだ動くため、問題の発見が遅れることもある。
最初のシグナルは大きな障害でないことが多いです。静かなスパイク：サポートチケット、ログイン成功率の低下、怒ったユーザーからのメッセージなど。オンコールが「デプロイ後5分でログイン成功率が18%低下」のアラートを見て、サポートが「3人が更新後にログインできない」と投稿します。
演習を練習しているチームは長く議論しません。確認し、決定し、行動します。
何がロールバックされるか：WebとAPIサービスのアプリケーションコードと設定。何がそのままか：データベースとユーザーデータ。
もしリリースにデータベースマイグレーションが含まれていたら、5分経路でデータベースをロールバックしないのがルールです。マイグレーションは後方互換にするか、デプロイ前に二重チェックを入れてください。
ロールバック中、インシデントリードは数分ごとに短い更新を投稿します：ユーザーが何を見ているか、どのアクションをしているか、次の更新がいつか。例：「ログインを復旧するために直近のリリースをロールバック中。次の更新は2分後。」
ロールバック後、ループを閉じます：「ログインは通常に戻りました。原因調査中です。発生原因と再発防止策を共有します。」
ロールバック演習は退屈に感じられるべきです。演習が緊張するなら、それは本物のギャップ（アクセス、スナップショット不足、手順が個人の頭の中にしかない等）を露呈しています。
想定されたアクセスで練習していて実際の権限で練習していない。 インシデント中にデプロイできない、設定変更できない、ダッシュボードに入れないことに気づく。対策：演習は実際に使うアカウントと役割で行う。
スナップショットはあるが不完全か見つけにくい。 アプリだけスナップショットして環境変数や機能フラグ、ルーティングを忘れる。あるいは名前が意味をなさない。対策：スナップショット作成をリリースステップに組み込み、命名ルールを設け、演習で見えて復元可能か検証する。
データベースマイグレーションでロールバックが危険になる。 互換性のないスキーマ変更が速いロールバックをデータ問題に変える。対策：追加型マイグレーションを優先する。破壊的変更が避けられない場合はリリースに明記してフォワード修正を計画する。
ユーザーが感じることを確認する前に成功宣言してしまう。 デプロイは戻ったがログインはまだ壊れている、ジョブが詰まっている。対策：検証は短くても実際的に行い、タイムボックスする。
演習が繰り返せないほど複雑になっている。 ツールが多すぎ、チェックが多すぎ、声が多すぎ。対策：演習を1ページ、1オーナーに縮小する。単一のランブックと1つの通信チャネルでできないなら、本番で使えません。
良いロールバック演習は習慣であり、英雄的パフォーマンスではありません。落ち着いて終えられないならステップを減らし、落ち着いてできるようになってから本当にリスクを下げるものだけを追加してください。
ロールバック演習は皆が同じ1ページのチェックリストに従うと最も効果的です。チームが実際に見る場所に固定しておきましょう。
10分未満で実行できるコンパクト版（準備と検証を含む）：
演習は手順が普通に感じられる頻度で行います。月1回が良いデフォルトです。プロダクトが日々変わるなら隔週でも良いですが、検証はトップユーザーパスに集中させてください。
各演習後、同じ日にランブックを更新します。リリースノートと一緒に保管し、「最終テスト日」を日付付きで追記して古い手順を信用しないようにします。
改善に役立つものだけを測定します：
もしチームがKoder.ai上で構築しているなら、スナップショットとロールバックを習慣の一部にしてください：スナップショットに一貫した名前を付け、オンコールで使う同じインターフェースで復元リハーサルを行い、検証者のチェックにカスタムドメインや主要統合を含めておきます。これをランブックに書いておくと演習が日常の出荷フローに沿います。
ロールバック演習は、不具合のあるリリースをシミュレートして、最後に確認された正常なバージョンに復旧するための書かれた手順に従う実習です。
\n目的は「早くデバッグする」ことではなく、プレッシャー下でサービス復旧が再現可能で落ち着いてできるようにすることです。
場当たり的な議論を避けるために事前に決めたトリガーを使いましょう。一般的な判断基準：
\n- コアフロー（ログイン／決済／サインアップ）が数分以上壊れている
ユーザーを素早く動作するバージョンに戻せることを意味します——新しいリリースが壊れたままでも構いません。
\n実際には「復旧」とは、少数の信号が正常に戻ったことを示します（コアのユーザーアクションが動く、エラーレートとレイテンシがほぼ正常に戻る、クラッシュループがない、など）。
議論なしに数秒で選べる対象を決めておきます：
\n- チェックを通過した直近の前のリリース
最低限、リリース前にこれらを取得・記録できるようにします：
\n- 配布したビルドの識別子（バージョン + コミット + アーティファクトタグ）
並び替え可能で素早く見つけられる名前にしてください。例：
\nprod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123
\n環境 + タイムスタンプ + バージョン + コミットを含めると便利です。形式よりも一貫性が重要です。
小～中規模チーム向けのシンプルで再現可能な分担：
\n- インシデントリード： 成功目標の設定と判断（決定）
短く明確な合否チェックにしてください。よく使われる必須チェック：
\n- ログインがエンドツーエンドで動作する
5分の経路に「データベースをロールバックする」を入れないでください。代わりに：
\n- 後方互換（追加型）マイグレーションを優先する（旧コードでも動くようにする）
プラットフォームがスナップショットと復元をリリースフローに組み込んでいる場合、ロールバック演習は簡単になります。
\nKoder.aiを使う場合でも、事前に決めておくこと：
\n- 誰がスナップショットを作成できるか、誰が復元できるか