2.2変更管理

稼働中のサービスに手を加える変更は、それ自体がインシデントの主要な原因です。だからといってすべての変更を重い承認プロセスに通していては、日常の定型作業まで滞り、緊急時には手遅れになります。この節では、変更を標準変更・通常変更・緊急変更の三つの経路に振り分ける考え方と、それぞれでCAB（変更諮問委員会）やECAB（緊急変更諮問委員会）が果たす役割、そして変更に必ず伴うべきリスク評価と切り戻し計画を、サービスマネージャの判断という軸から学びます。

2.2.1標準・通常・緊急の三つの経路

• 標準変更＝あらかじめ承認された、低リスクで手順が確立された定型的な変更。都度のCAB審議は不要で、定義済みの手順に従って実施できる（例：あらかじめ承認された手順によるユーザアカウント追加、定型パッチ適用）。頻度が高く影響が小さい変更を軽量に回すための経路。
• 通常変更＝標準変更に該当しない、リスクや影響の評価が必要な変更。変更要求（RFC）を起票し、CAB（変更諮問委員会）がリスク・影響・実施計画・切り戻し計画などを評価してから承認・スケジュールする。多くの計画的な変更がこの経路を通る。
• 緊急変更＝重大インシデントの回復など、通常のCAB審議を待てない緊急の変更。通常より少人数で迅速に判断するECAB（緊急変更諮問委員会）が承認し、まず変更を実施して事後に文書化（記録・レビュー）する。迅速さと引き換えにリスクが高いため、範囲を最小限にとどめる。

2.2.2リスク評価と切り戻し計画

• リスク評価＝変更が失敗した場合の影響範囲・発生可能性を事前に見積もり、実施可否・実施時間帯（サービスへの影響が小さい時間）・必要な立会い体制を判断する。CABの中心的な役割であり、リスクの高い変更ほど慎重な承認と準備を要する。
• 切り戻し計画（バックアウト計画）＝変更が想定どおり動作しなかったときに、変更前の状態へ確実に戻すための手順。切り戻しの可否と所要時間、切り戻し判断の期限（この時刻までに正常確認できなければ戻す、など）を事前に定める。切り戻し計画のない変更は、緊急変更であっても原則として実施すべきでない。

あるサービスマネージャが、稼働中の会員向けオンラインサービスで、認証基盤のミドルウェアに公表された深刻な脆弱性が見つかり、修正パッチをどの変更経路で適用するか判断を迫られています。まず、この変更がすでに「あらかじめ承認された定型手順」に含まれる標準変更に該当するかを確認しますが、認証基盤の中核ミドルウェアへのパッチは影響範囲が広く、既存機能への副作用や再起動を伴う可能性があるため、定型の低リスク変更とは言えず標準変更としては扱えません。次に、脆弱性の深刻度と悪用の切迫度を評価します。仮に、実際に悪用が観測されておらず数日の猶予がある場合は、変更要求（RFC）を起票してCABにかけ、リスク評価・実施時間帯（利用の少ない深夜帯）・立会い体制・そして切り戻し計画（パッチ適用後に認証が失敗した場合に旧バージョンへ戻す手順と、その判断期限）を審議したうえで承認・スケジュールする通常変更として進めるのが適切です。一方、もしこの脆弱性がすでに実際の攻撃に悪用されており、放置すればアカウント侵害が拡大する重大インシデントに直結する状況であれば、通常のCAB審議を待つ余裕はありません。この場合はECAB（緊急変更諮問委員会）を招集して迅速に判断する緊急変更の経路を採り、まずパッチを適用してサービスを保護します。ただし、緊急変更であっても切り戻し計画を省略してよいわけではなく、パッチ適用で認証が壊れたときに即座に戻せる手順を用意し、適用範囲は当該脆弱性の封じ込めに必要な最小限にとどめます。そして実施後には、変更内容・判断根拠・結果を事後に文書化してレビューし、恒久的な再発防止（正式なパッチ運用手順への反映）へつなげます。このように、変更経路の選択は「速いか慎重か」の二択ではなく、脆弱性の切迫度・影響範囲というリスクに応じて標準／通常／緊急を使い分け、いずれの経路でもリスク評価と切り戻し計画は外さないという判断が本質です。

2.2.3この節のまとめ

• 標準変更＝事前承認済みの低リスク定型（CAB審議不要）、通常変更＝RFC起票しCABが評価して承認、緊急変更＝ECABが迅速承認し事後に文書化
• 変更経路の選択はリスク（切迫度・影響範囲）に応じて行い、迅速さと慎重さのトレードオフで判断する
• リスク評価と切り戻し計画は、緊急変更を含むどの経路でも省略してはならない