リリース後に画面の異常に気づき、慌てず「戻す手順書」を開いて落ち着いて元に戻そうとしている一人運用の保守担当者
リリース・変更管理約14分

ロールバック手順の作り方｜すぐ戻せるリリース設計を一人運用で

リリースのボタンを押した数分後。 監視のグラフが跳ねて、エラーログが流れ始める。問い合わせの電話も鳴り出した。

このとき、いちばん心臓に悪いのは「直し方が分からない」ことではありません。 「とりあえず、いったん前の状態に戻せるのか」が分からないことです。

前に進む（直す）には、原因の調査も、修正も、テストもいる。時間がかかります。 でも、その時間ずっと本番が壊れたままなのは、つらすぎる。だからまず欲しいのは「いったん元に戻して、落ち着いてから調べる」という逃げ道です。

この逃げ道を、その場の度胸ではなく事前の段取りとして用意しておくのがロールバックです。 この記事では、「すぐ戻せる」を仕組みにするための考え方と、アプリ・DB・設定・ファイルそれぞれの戻し方の違い、そして本番の前に決めておく判断基準までを、一人運用の目線で一緒に深掘りしていきます。一度に全部そろえなくて大丈夫です。

結論：ロールバックは「いざとなったら気合いで戻す」ではなく、「戻す手順を事前に書いて、戻せる状態で出す」ことで成り立ちます。やることは4つ。①このリリースは何で戻すか（前のバージョンに切替か／逆操作か）を出す前に決める、②DB変更は「戻せる形」で分けて出す、③戻す判断の基準（いつ戻すか）を先に決めておく、④小さな変更で一度、実際に戻す練習をしておく。まずは次のリリース1回ぶんの「戻し方」を1行メモするところから始めます。

リリースの仕組み（手動デプロイ・CI/CD・コンテナ・レンタルサーバーのファイル差し替えなど）や構成によって、戻し方の最適解は変わります。 この記事の考え方を出発点に、自分の環境のやり方に読み替えてください。本番に反映する前には、必ず検証環境や公式情報で確認しましょう。

なぜ「戻せない」リリースが生まれるのか

戻せなくなるのは、担当者が雑だからではありません。むしろ丁寧に作り込んだリリースほど、戻すことを後回しにしがちです。理由はいくつか重なります。

どれも「気をつける」だけでは防ぎきれません。だからこそ、戻すことを最初から設計に含めておくことが効いてきます。まずはこの前提を持っておくと、あとの話がすっと入ってきます。

ロールバックの考え方：戻し方は1種類じゃない

ロールバックには「前のバージョンに切り替える戻し方」と「逆の操作で打ち消す戻し方」の2種類があることを示した図
戻し方は大きく2つ。切替で戻せるか、逆操作で戻すか。変更の中身で選ぶ

「ロールバック」とひとことで言っても、戻し方は大きく2つあります。これを分けて考えると、自分のリリースをどう戻せばいいかが見えてきます。

多くのリリースは、この2つが混ざっています。「アプリは切替で戻せるが、DBは逆操作が必要」というように。だからリリースを出す前に、自分の変更がどちらの戻し方になるかを部品ごとに分けて考えるのが、いちばん大事な準備です。

戻し方を「部品ごと」に整理する

リリースに含まれるものを、戻し方の観点でざっくり分けると、こうなります。

変更の種類基本の戻し方戻しやすさ事前にやっておくこと
アプリのコード前の版に切替戻しやすい前の版（タグ・成果物）を残す
設定ファイル・環境変数前の値に切替戻しやすい変更前の値を控える／版管理する
静的ファイル・画像旧ファイルに切替戻しやすい差し替え前を別名で退避する
DBの構造（列追加など）逆操作で打ち消す注意が必要戻す用のSQLを先に書く
DBのデータ書き換え逆操作・バックアップから復元戻しにくい変更前のバックアップ・件数を取る
外部サービス連携の切替設定を戻す・先方と調整場合による切替前の状態と連絡先を控える

表のうち、上のほうは「切替で戻せる」ので比較的安心です。注意がいるのは下の2つ、DB（データ）まわり。ここを"戻せる形"にできるかどうかで、リリース全体の安心感が決まります。次の章で、ここを重点的に見ます。

いちばんの難所：DB変更を「戻せる形」にする

リリースで戻せなくなる原因の多くは、データベースです。コードは差し替えれば戻りますが、データは一度書き換えると、それ自体が消えてしまうからです。ここを丁寧に設計しておくと、リリースの怖さがぐっと減ります。

① 「壊す変更」は一度に出さない（2段階に分ける）

いちばん効くコツが、「足す変更」と「消す変更」を別のリリースに分けることです。

たとえば「列の名前を変えたい」とき、一気にやると戻せません。代わりに段階を踏みます。

  1. まず新しい列を足す（古い列はそのまま残す）。アプリは新旧どちらの列でも動くようにしておく。→ この段階なら、問題が出てもアプリを戻すだけで済む。
  2. しばらく安定して動くのを見届けてから、次のリリースで古い列を消す。

遠回りに見えますが、こうするとそれぞれのリリースが単体で戻せるようになります。「消す」「名前を変える」「データ型を変える」といった後戻りできない変更ほど、独立した小さなリリースに切り出すのがコツです。

とはいえ、納期や依頼ベースの一人運用では「1回で終わらせて」と言われがちで、全部を2段階にするのは現実的でないこともあります。そのときの最低ラインはこうです——「消す」「名前を変える」だけは絶対に別リリースに分ける。「足す」「直す」は同じリリースに同梱してよい。後戻りできない操作だけ切り出せれば、戻せなさのいちばん大きな穴はふさげます。

② 戻す用のSQLを、出す前に書いておく

DBの構造を変えるときは、変更するSQL（前進用）とセットで、それを打ち消すSQL（後退用）を先に書いておきます。マイグレーションツールを使っているなら、戻す処理（down/rollback に相当）を必ず書いて、検証環境で実際に戻して動くかを一度試します。書いてあるのに動かない、はよくあります。

検証環境が無く本番一択、という一人運用の現場も多いはずです。その場合は、戻しSQLを手で書いて声に出して読み合わせる／対象テーブルだけのコピーを作って戻して試す／最悪はバックアップから復元する道だけは確保しておく——このどれかで代わりにします。実際に戻して試せないぶん、復元できる退避だけは必ず持っておきます。

③ データを書き換えるときは、変更前を必ず残す

UPDATE や DELETE でデータそのものを変えるときは、これが戻せるかどうかの分かれ目です。最低限こうしておきます。

この「データ修正を安全に行う段取り」は、それ自体が一つの大きなテーマです。SQLでのデータ修正の安全手順は、別記事で詳しく整理しています（記事末尾の関連リンク）。戻せる状態を作ってから書き換える——この順番だけは、ぜひ守ってください。

戻す「判断基準」を、先に決めておく

リリース後に「直すか・戻すか」をあらかじめ決めた基準で落ち着いて判断する流れを示した図
戻す基準を先に決めておけば、トラブルの最中に迷わず動ける

手順がそろっていても、トラブルの最中に「これは戻すべきか、もう少し粘って直すべきか」で迷うと、その数分が傷を広げます。だから戻す判断の基準を、落ち着いているうちに決めておきます。

決めておくと迷わないのは、たとえばこんな観点です。

この基準は、リリース手順書（runbook）の中に1ブロックとして書いておくのがおすすめです。「進む手順」と並べて「戻す手順」と「戻す基準」を置いておけば、いざというとき、それを読むだけで動けます。

具体例：よくある3つの「戻せなかった」場面

現場では、こんな形でロールバックが詰まりがちです。直し方とセットで見てみましょう。

どれも「もっと慎重に」では防ぎきれず、戻せる形で出す・前の状態を残す・戻し方を先に書くのどれかがあれば救えたものばかりです。

影響：戻せる設計にすると、何が変わるか

リリースを「戻せる前提」で組むようになると、トラブルが減るだけでなく、日々の心持ちが変わります。

逆に、戻し方を用意しないまま出し続けると、いつか「進むことも戻ることもできない」夜が来ます。しかもそれは、たいてい忙しい時期や連休前にやってきます。先に逃げ道を作っておくことが、未来の自分を助けます。

明日やること：次のリリース1回ぶんの「戻し方」を書く

いきなり全部を仕組み化しなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。

  1. 次に予定しているリリースを1つ思い浮かべ、変更内容を「アプリ／設定／ファイル／DB」に分けて書き出す。
  2. それぞれについて、戻し方を1行ずつ書く（「前の版に切替」「変更前の値○○に戻す」「この逆SQLを実行」など）。
  3. DBに戻しにくい変更（消す・書き換える）が含まれていたら、「足すだけ」に分けられないか、バックアップを取れないかを検討する。
  4. 戻す引き金を1つ決める（例：「主要画面が開けなくなったら、リリース後15分で戻す」）。
  5. ここまでを、リリース手順書か作業メモの「戻す手順」欄として残す。次回はそこに書き足していけば、自然と型になります。

1回ぶんの戻し方を書くだけでも、「戻せるか分からない」が「戻せる」に変わります。完璧な仕組みを一気に作ろうとせず、まず次の1リリースから始めましょう。余裕があれば、ごく小さな変更で一度実際に戻す練習をしておくと、本番での安心感がまるで違います。

「すぐ戻せるリリース」チェックリスト

リリースを出す前に、戻せる状態かを確かめる項目です。コピーして、自分のリリースに当ててみてください。全部やる前提ではありません。まずは「これだけは」の3つから。

これだけは（最低ライン）

DBを触るとき／余裕があるとき（任意）

全部に○が付かなくても大丈夫です。上の3つだけ押さえれば、まずは「戻せるか分からない」を抜け出せます。下の項目は、DBを触るときや手が空いているときに少しずつ足していけば十分です。1つでも「戻せる工夫」を足せたら、それだけで次のリリースの怖さはぐっと下がります。

よければ、こちらも

ロールバックは、リリース手順・影響範囲の調査・データ修正・障害の振り返りと地続きの仕事です。あわせて整えておくと、いざという時に落ち着けます。

戻す手順を用意できて、リリースを落ち着いた気持ちで進められるようになった保守運用の担当者

リリースが怖いのは、勇気が足りないからではありません。戻る道が見えていないからです。戻し方を1行書いておくだけで、その道は確かに見えてきます。 今日は、次のリリースの「戻し方」を1行メモするだけで十分です。その小さな備えが、「進むしかない」という追い詰められた感覚から、あなたを少しずつ解放してくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語