先に結論
変更凍結とは、リリース前後や繁忙期など、障害を避けたい期間に本番環境への変更を止める運用です。英語では change freeze や release freeze、文脈によって code freeze と近い意味で使われることがあります。
- 変更凍結は
何もしないためではなく事故を減らすために行う - 対象はコード反映だけでなく、設定変更、DB変更、インフラ変更を含むことがある
- カットオーバー前後、年末商戦、重要イベント前によく使われる
- 例外ゼロとは限らず、緊急修正や重大障害対応だけ通すこともある
- 凍結中に変更をため込みすぎると、解除後に逆に事故が増える
要するに、変更凍結は 安全に本番を維持するための一時的なブレーキ です。
変更凍結とは
変更凍結は、本番環境に対する変更を一定期間止める運用ルールです。
ここでいう変更には、アプリケーションの再デプロイだけでなく、設定変更、インフラ更新、権限変更、バッチ差し替え、データ更新、運用ジョブの見直しなどが含まれることがあります。
たとえば、大きなリリースの前日に別件の修正を本番へ入れると、どの変更が原因で問題が起きたのか分かりにくくなります。
このため、リリース直前や直後に 今は本番変更を止める というルールを置き、確認と監視に集中する時間を確保します。
なぜ変更を止めるのか
変更凍結の目的は、単に慎重になることではありません。
主な理由は、影響範囲を狭め、問題が起きたときの切り分けをしやすくすることです。
1. 原因の切り分けをしやすくする
変更が連続して入ると、障害が起きたときに何が原因か見えにくくなります。
変更凍結を入れると、直前に入った変更の数を減らせるため、確認対象を絞りやすくなります。
2. カットオーバーや大きなリリースに集中するため
カットオーバー前後は、技術作業だけでなく、確認、連絡、承認、切り戻し判断が重なります。
この時期に別件の変更が混ざると、担当者の注意が分散しやすくなります。
3. 繁忙期の障害リスクを下げるため
EC のセール時期、月末月初、決算期、イベント本番前など、障害の事業影響が大きい時期には、変更そのものを止める方が安全なことがあります。
Google Cloud の SRE 文脈でも、信頼性に課題があるときに feature freeze を使って信頼性改善へ時間を振る考え方が紹介されています。
4. 監視と初期安定化に時間を使うため
リリース直後は、入れた変更を見守る時間も必要です。
この期間にさらに別の変更を入れると、どの挙動が新リリース由来なのか分からなくなります。
どんな場面で使われるか
変更凍結は、次のような場面でよく使われます。
- 大規模リリースや本番切り替えの前後
- データ移行やシステム切り替えの当日から数日間
- 年末年始、ブラックフライデー、入試、株主総会など重要イベント前後
- 障害が続いていて、まず安定化を優先したい期間
- 監査対応や重要な対外説明の直前
小規模なサービスでは大げさに見えるかもしれませんが、変更凍結は大企業だけのものではありません。
むしろ少人数チームほど、同時に複数の本番変更を抱えると切り分けが難しくなるため、短い凍結期間が効くことがあります。
何を凍結対象にするのか
変更凍結で混乱しやすいのは、何が止まるのか が曖昧なことです。
実務では、次のように対象を明確にした方が安全です。
| 対象 | 凍結することが多いもの | 補足 |
|---|---|---|
| アプリ | 本番デプロイ、新機能公開、設定差し替え | 画面文言だけでも対象に入れることがある |
| インフラ | サーバー設定変更、ネットワーク変更、スケール設定変更 | 自動運用との境界を明確にする |
| DB | スキーマ変更、データ更新、バッチ修正 | 戻しにくいので厳しめに扱うことが多い |
| 外部連携 | Webhook先変更、API接続先変更、認証設定変更 | 影響範囲が広がりやすい |
| 運用設定 | 監視閾値変更、ジョブ時刻変更、権限変更 | ここを対象外にすると事故が起きやすい |
反対に、ログ確認、監視設定の閲覧、障害調査、バックアップ確認などは、通常は凍結対象に含めません。
コードフリーズやメンテナンスウィンドウとの違い
似た言葉にコードフリーズやメンテナンスウィンドウがあります。
コードフリーズとの違い
コードフリーズは、新機能追加や大きなコード変更を止める意味で使われやすい言葉です。
主に開発プロセス寄りで、リリース候補を固める段階で出てきます。
一方、変更凍結は本番運用寄りです。
コードだけでなく、設定変更、DB変更、インフラ変更まで止めることがあります。
メンテナンスウィンドウとの違い
メンテナンスウィンドウは、変更や保守作業を実施してよい時間帯のことです。
AWS Systems Manager の maintenance window も、特定時間帯に保守タスクを実行する考え方です。
変更凍結はその逆に近く、この期間は変更を入れない という制約です。
つまり、メンテナンスウィンドウは作業してよい時間、変更凍結は作業を止める期間です。
例外はどう扱うか
変更凍結があるからといって、どんな変更も絶対禁止とは限りません。
多くの現場では、例外ルールを決めています。
たとえば、次のような変更だけは通すことがあります。
- 重大障害の復旧に必要な変更
- 緊急のセキュリティ修正
- 法令対応や外部期限で避けられない変更
- 事業継続上どうしても必要な最小修正
ただし、例外を広く認めすぎると、凍結の意味がなくなります。
Google Cloud Blog では、feature freeze 中の例外権を安く使いすぎないことが重要だと書かれています。実務でも、例外は 承認者を限定する 理由を記録する 事後レビューする くらいまで決めておく方が安全です。
変更凍結の落とし穴
変更凍結は便利ですが、長く取りすぎると別の問題も起きます。
1. 変更がたまり、解除後に事故が増える
凍結期間中に開発だけ進めて本番反映を止めると、解除後にまとめて多くの変更が流れ込みます。
Google Cloud Blog でも、freeze 後に変更が一気に出ると障害が増えやすいと指摘されています。
2. 例外だらけになって形骸化する
毎回 これは特別 と通していると、結局いつも変更が入る状態になります。
この場合は、凍結ルールの作り方か対象範囲が現実に合っていない可能性があります。
3. 対象が曖昧で現場が迷う
コードだけ止まるのか、設定変更も止まるのか、緊急バッチはどうするのかが曖昧だと、現場ごとに解釈が割れます。
本番への影響がある変更はすべて対象 のように、まず原則を短く決めると運用しやすくなります。
実務で決めておきたいこと
変更凍結を入れるなら、少なくとも次の点を決めておくと回しやすいです。
- いつからいつまで凍結するのか
- 何を凍結対象にするのか
- 誰が例外承認を出せるのか
- 緊急変更の条件は何か
- 凍結中に何を監視・確認するのか
- 凍結解除後にどの順番で変更を再開するのか
特に、解除後の流し込み方は大事です。
ため込んだ変更を一度に出すと危ないので、優先順位をつけて小さく再開した方が安全です。
カットオーバー記事との違い
カットオーバーとは？本番切り替え・移行日・確認手順の基本を整理 は、旧環境から新環境へ本番を切り替える当日と前後の段取りを中心にした記事です。
今回の変更凍結は、その前後で 余計な変更を止める理由 と どこまで止めるか に焦点を当てています。
つまり、カットオーバーは 切り替え作業そのもの、変更凍結は 安全に切り替えや運用を行うための制約 です。
まとめ
変更凍結とは、リリース前後や繁忙期に本番変更を止め、障害リスクと切り分けの難しさを減らすための運用です。
コードだけでなく、設定、DB、インフラ、外部連携まで対象に含むことがあります。
大事なのは、何を止めるのか、例外を誰が承認するのか、凍結解除後にどう再開するのかを明確にすることです。
短く的確に使えば、変更凍結は 慎重すぎる運用 ではなく、リリース品質を守るための実務的な仕組みになります。
参考リンク
- Harness: Freeze deployments
- Google Cloud Blog: Good housekeeping for error budgets
- AWS Systems Manager: Disable or enable a maintenance window using the console
- Google SRE Book: Release Engineering