「設定を一つ変更するだけです」
「問題が出たら、元に戻せば大丈夫です」

パソコンやクラウド、ネットワークの保守を依頼するとき、このような説明を受けたことはないでしょうか。

ここで確認したいのは、変更する設定の数だけではありません。

その設定は、どの業務に影響するのでしょうか。異常を何で見つけ、誰が作業を止めるのでしょうか。そして、元へ戻すための画面に入れなくなっても、対応できるでしょうか。

「元に戻せるはず」と「戻す手順を用意し、実際に使えることを確認している」は、別の状態です。

今回は、2025年11月に発生したCloudflareの障害と、その後の改善報告を取り上げます。大規模なクラウド事業者の仕組みをそのまま再現するのではなく、中小企業の設定変更に取り入れられる、確認・停止・切り戻しの方法を整理します。

本文の管理表、時間の計算例、訓練の想定は、当事業所による実務上の提案です。実在企業の内部手順を再現したものではありません。

Cloudflareの障害は、外部からの攻撃が原因ではなかった

Cloudflareは、2025年11月18日に発生した障害について、サイバー攻撃や悪意ある活動が原因ではなかったと説明しています。発端となったのは、同社が行ったデータベースの権限変更でした。

この変更によって、ボット判定に利用する設定ファイルへ重複した項目が出力され、ファイルが想定より大きくなりました。それがネットワーク全体へ配布され、読み込むソフトウェアの制限を超えたことで、通信処理に障害が生じたと報告しています。

重要なのは、データベース側の変更自体は段階的に行われていた一方、そこで生成された設定ファイルは広い範囲へ配布されていたことです。変更した箇所の数だけでは、影響範囲を判断できない事例として読めます。

復旧では、問題のある設定ファイルの生成・配布を止め、正常と確認されたファイルへ差し替え、必要な再起動などを行ったと説明されています。単に最初の設定項目を戻すだけの対応ではありませんでした。

ここから自社の点検につなげたいのは、「設定を変更してはいけない」という結論ではありません。

変更がどこまで伝わるかを確認し、異常があれば広がる前に止め、必要な範囲を戻せるようにすることです。

その後の改善報告では、設定の配布方法も見直されている

Cloudflareは2026年5月1日、障害を受けて進めた改善活動について報告しました。設定変更を段階的に配布し、稼働状況を監視しながら、異常時には自動で元へ戻す仕組みなどを説明しています。また、新しい設定を読み込めない場合に、可能な範囲で直前の正常な設定を使う設計も示しています。

これは、問題となった一つのファイルを修正するだけでなく、変更の届け方や、失敗したときの動作を見直す取り組みです。

中小企業でも、同じ規模のシステムを導入する必要はありません。例えば、全端末へ同時に適用する前に一部で確認する、想定した結果を得られなければ残りへ広げない、戻す設定を事前に用意するといった運用へ置き換えられます。

ただし、古い設定を使い続ければ常に安全というわけでもありません。変更の目的が脆弱性への対応であれば、戻すことによって残る問題も考える必要があります。

本記事では、変更を安全に進める計画と、失敗した場合の計画を、一組で作る方法を提案します。

「一か所だけの変更」でも、影響は一か所とは限らない

設定変更の重要度を、変更する行数や操作時間だけで決めないようにしましょう。

例えば、次のような変更を自社で行う場合を考えてください。

変更する内容の例併せて確認したい業務・接続
ルーターやファイアウォールの通信ルール業務システム、拠点間通信、外部保守、監視の接続
クラウドのアクセス制御従業員の利用、管理者の接続、自動処理、外部担当者の作業
メールに関する設定通常の送受信、問い合わせフォーム、請求・予約などの自動通知
データ連携の抽出条件出力されるデータ、連携先での読込み、その後の集計や処理

この表は、必ずこれらすべてに影響するという意味ではありません。変更前に、どこを調べるかを整理するための例です。

例えば、「この部署だけを対象にする」と説明されていても、変更する設定が全社共通のものなら、その部署だけに影響を限定できるか確認が必要です。

一台のサーバーで試しているつもりでも、そのサーバーが作った設定やデータを他の端末へ配る構成なら、試験の影響が外へ出ていないかを調べます。

確認するときは、「何を変更するか」に加えて、「その結果を誰が使うか」まで追うことをおすすめします。

不明な接続が見つかった場合は、「たぶん使っていない」と扱わず、利用者や保守会社へ確認してください。変更の影響を判断できていないこと自体を、作業前の課題として残します。

小さく試すときは、台数だけでなく条件を選ぶ

設定や更新を一部から適用する方法は、問題が広がる前に気付くための手段です。

GoogleのSRE資料では、少数の対象へ先に変更を適用して比較する方法が説明されています。同時に、対象数、観察時間、処理内容などが、全体の利用を代表できるかを考慮する必要があるとしています。

中小企業であれば、最初に一部の端末や利用者で確認し、問題がなければ範囲を広げる方法が考えられます。ただし、「一台で動いた」という結果を、条件の異なる全端末へそのまま当てはめないようにしましょう。

例えば、事務所内からの接続だけを試しても、在宅勤務や外部保守の接続を確認したことにはなりません。一般利用者で確認しても、管理者だけが使う機能は未確認のままです。

試行対象は、台数だけでなく、業務、権限、接続場所、端末の構成などから選びます。

また、試行用と本番用が同じデータベースや共通設定を使っている場合は、分けたつもりの範囲を越えて影響しないかを確認してください。Googleの資料でも、試行対象と比較対象が共有する依存先に注意することが示されています。

段階的に適用できないサービスや機器については、その制約を明記します。事前検証、変更時間帯、保守会社の待機、切り戻しの準備など、別の方法で補う必要があります。

「エラーが出ていない」と「正常に使われた」を分ける

変更後の確認で、「しばらく待ったが、問い合わせはなかった」と報告するだけでは、判断材料が不足します。

その時間帯に、対象の機能が使われていなかった可能性を考える必要があるからです。

Microsoftの安全な展開に関する資料でも、エラーや利用者からの申告がないことだけでなく、実際の利用状況を確認するよう示されています。

そこで、変更前に確認する業務を決め、変更後に実際の結果を確かめましょう。

例えば、通信ルールの変更なら、業務画面が表示されるだけでなく、必要な入力、保存、帳票出力まで確認します。アクセス制御なら、許可する人が利用できることに加え、許可しない人には利用できないことも確認対象です。

正規の利用ができるようになった代わりに、制限すべき相手まで通していれば、変更の目的を満たしていません。

観察時間も、一律に「五分間、問題がなければ完了」と決めるのではなく、対象の処理に合わせます。毎時動く連携や夜間の処理があるなら、それらを確認する方法と時刻を計画してください。

設定画面の表示、実際の動作、業務上の結果を、別々に確認することが大切です。

変更前の状態は、戻すために使える形で残す

切り戻しの準備では、変更前の設定を保存します。ただし、何かを保存してあれば十分ということではありません。

保存した設定が、どの機器やサービスのものか。いつ取得し、その時点でどの業務が正常だったのか。復元する際、どの操作が必要なのかを確認してください。

例えば、管理画面のスクリーンショットは、変更内容を比較する材料になります。しかし、その画像を用意しただけでは、設定を一括で戻せるとは限りません。

設定の出力機能がある場合も、同じ機器やバージョンへ読み戻せるか、認証情報など別途必要なものがないかを、製品の手順で確認します。

保存する対象も、変更した画面の項目だけでよいかを検討してください。関連するルールの順番、対象グループ、連携先の情報などが、切り戻しに必要な場合があります。

本記事では、変更前の状態に識別番号や日時を付け、作業計画から参照できるようにする方法を提案します。「最新」「最終版」という名前だけでなく、どの変更の直前のものかを特定できるようにしましょう。

また、設定の出力ファイルに秘密情報や内部構成が含まれる場合に備え、保管場所と閲覧者を限定してください。作業関係者へ配る計画書に、パスワードや秘密鍵をそのまま記載する必要はありません。

切り戻しは、変更ボタンを押す前の状態へ戻すだけとは限らない

切り戻しでは、何を戻すのかを分けて考えます。

設定値を戻す作業と、すでに生成・配布された設定やデータを置き換える作業、実際に動いている処理へ反映させる作業は、同じではありません。

ここでは、架空の社内システムを考えます。

管理画面の設定をもとに、端末用の設定ファイルを自動生成し、配布する仕組みです。問題のある設定を元へ戻しても、端末がすでに受け取ったファイルを使い続ける構成なら、配布済みのものをどう扱うかを確認しなければなりません。

逆に、正常なファイルを手動で置いても、自動生成処理が問題のある内容で上書きするなら、同じ状態へ戻ってしまいます。

このような構成では、生成と配布を止める範囲、戻すファイル、反映の確認、自動処理を再開する条件までを計画します。

また、データベースの構造や保存形式を変える作業では、旧版へ戻すこと自体が難しい場合があります。Microsoftも、データを保持する構成要素の変更では、ロールバックが複雑になることを説明しています。

その場合は、変更を元へ戻す方法だけでなく、修正を追加して復旧する方法や、検証済みの別環境へ切り替える方法を検討します。

「戻します」と書く前に、戻す対象、順番、方法、戻せない条件を具体化してください。

なお、設定を戻すために、変更後に受け付けた正規の業務データまで一律に消すような対応にはしないでください。設定の復旧と、業務データの扱いは分けて判断します。

作業終了時刻から、切り戻しの判断期限を逆算する

作業予定が「21時から22時まで」であっても、22時まで新しい設定の調整を続けてよいとは限りません。

戻す操作と、戻ったことの確認にも時間が必要です。

例えば、次の条件を事前試験で確認したとします。以下は、計画の考え方を示す架空の例です。

切り戻し操作に15分、動作確認に10分、予備時間として5分を確保する場合、合計30分が必要です。22時までに利用可能な状態へ戻す計画なら、切り戻しを始めるための判断期限は21時30分になります。

22時00分 − 15分 − 10分 − 5分 ＝ 21時30分

この例で21時45分まで「あと少しで直りそう」と調整を続ければ、予定した切り戻し時間は確保できません。

もちろん、21時30分までは異常を放置してよいという意味でもありません。必要な通信が止まった、意図しない相手にアクセスを許した、確認用の記録が取得できなくなったなど、あらかじめ決めた条件に該当すれば、その時点で作業を止めて判断します。

この時刻は、切り戻し時間の見積りが妥当であることを前提にした計画値です。実際に何分かかるか分からない場合は、その不確かさを明記し、確認や余裕時間の確保を先に行ってください。

作業の予定表には、開始と終了だけでなく、「いつまでに継続か切り戻しかを決めるか」も入れましょう。

「設定変更・切り戻し計画書」を一枚にまとめる

ここまでの内容を、作業前に確認できる形へまとめます。

NISTの構成管理に関するガイドでは、変更の依頼、影響の評価、試験、承認、実施、実施後の確認を管理する流れが示されています。手続きの厳密さは、組織やシステムへの影響に応じて調整する考え方です。

小規模な事業所であれば、最初から大きな会議体や複雑な申請システムを設ける必要はありません。まず、次の項目を一つの計画書へまとめる方法を提案します。

項目作業前に決める内容
変更の目的何を改善・修正するのか。実施しない場合に何が残るか
対象と変更内容対象の機器・サービス、変更前後の値、今回変更しない範囲
影響する業務利用者、接続先、自動処理、保守・監視への影響
実施体制作業者、承認者、業務確認者、緊急連絡先
変更前の記録設定・関連資料の識別番号と保管場所、正常性の確認結果
適用と確認の順番最初に試す範囲、確認項目、次の範囲へ進む条件
中止・切り戻し条件動作上の異常、確認不能、判断期限など
切り戻し方法戻す対象、停止する自動処理、操作手順、所要時間
管理接続を失った場合承認済みの代替接続、現地対応、保守会社への依頼方法
完了条件業務と制限が意図どおりに動き、残件と記録を確認できた状態

「問題があれば戻す」ではなく、例えば「対象の業務画面で保存できない場合は、残りの端末への適用を止める」と書けば、現場で判断しやすくなります。

また、承認した後に対象や手順を変える場合の扱いも決めましょう。作業中に思い付いた別の改善を、同じ承認の中へ追加しないことをおすすめします。

変更内容が広がれば、影響範囲や切り戻し方法も変わるためです。追加対応が必要なら、現在の状態を記録し、責任者へ確認してから進めます。

管理画面へ入れなくなったとき、誰が戻すのか

ネットワークや認証の設定を変更する場合は、変更対象そのものを使って管理作業をしていないか確認してください。

例えば、外部からの保守接続を制御する設定を、同じ外部接続経由で変更する場面です。変更によって管理者の接続まで切れた場合、同じ経路から元へ戻せるでしょうか。

Cloudflareの2026年5月の改善報告でも、自社サービスを使う管理経路への依存を見直し、緊急時の代替認証経路や訓練を整備したことが説明されています。

自社では、現地で操作できる人が必要か、別の管理経路を用意できるか、保守会社の対応を確保すべきかを、作業前に決めてください。

これは、普段から誰でも使える無制限の管理口を作るという意味ではありません。利用条件、認証、担当者、使用記録を定めたうえで、正規の緊急手段を用意することです。

また、手順書と連絡先を、変更によって使えなくなる可能性がある共有フォルダーだけへ置かないようにしましょう。会社が認めた方法で、必要な担当者が参照できる控えを準備します。

予備の接続方法があるという説明だけでなく、実際に使う担当者が手順を確認し、必要な権限を持っているかまで確かめてください。

異常が出たら、無関係な設定変更を重ねない

変更後に問題が起きたとき、複数の担当者が、それぞれ思い当たる設定を変更し始めると、現在の状態を整理しにくくなります。

本記事では、異常を検知したら、まず追加の適用を止め、作業の窓口を一本化する方法を提案します。そのうえで、発見時刻、影響した業務、直前の変更、実施済みの対処を記録します。

ただし、記録を完成させるために、影響のある状態を長時間残す必要はありません。停止や切り戻しを進めながら、実施した操作を記録してください。

原因調査と、業務への影響を止める判断も分けます。原因が完全に分かるまで切り戻してはいけない、という運用にはしないようにしましょう。一方、戻すことでデータの不整合や別の危険が生じる構成では、事前に定めた方法に従って判断します。

「直前に設定を変えたから、それが原因に違いない」と断定することも避けてください。時刻が近いことは重要な手掛かりですが、他の障害や不正アクセスの可能性を否定する証拠ではありません。

確認できた事実と、調査中の原因を分けて記録すると、その後の保守会社への相談や再発防止に使いやすくなります。

障害が怖いからといって、更新を止め続けない

変更に伴うリスクを説明すると、「今動いているのだから、そのままにしておこう」という判断へ傾くかもしれません。

しかし、更新を行わないことにも、対処されない脆弱性などのリスクがあります。Microsoftの安全な展開に関する資料も、変更のリスクを管理しながら、必要な更新を継続する考え方を示しています。

目指すのは、変更をなくすことではありません。目的、影響、確認、停止の条件をそろえて、必要な変更を進めることです。

緊急の脆弱性対応では、通常と同じ長さの事前試験を待てない場合もあります。そのため、平時の変更と、緊急変更の手順を分けて用意します。

緊急時に確認を省略した項目があれば、何を省略し、どの対策で補い、誰が判断したかを残してください。NISTのガイドでも、緊急変更を管理の対象とし、実施後に速やかに確認することが示されています。

また、セキュリティ上の問題を直す変更を切り戻した場合は、元の問題が残っていることを管理します。接続制限などの暫定措置、再実施の担当者と期限を決め、「戻って動いたので完了」としないようにしましょう。

外部サービスの障害では、自社の設定を不用意に変えない

自社が設定を変更していなくても、外部サービスの障害によって業務が使えなくなる場合を考えておきましょう。

その際、すぐにDNSや認証設定を変更し、セキュリティ機能を外す方法を標準の対処にしないでください。

まず、自社で直前に変更したこと、利用できない範囲、サービス提供者の公式な障害情報を照合します。提供者側の障害と分かった場合は、その状況を記録し、自社で必要な代替業務や案内を判断します。

例えばCloudflareの一時停止機能は、通信を直接Webサーバーへ向ける仕組みです。その間はWAFなどの機能を利用できなくなると、公式資料に記載されています。単に経路を変えるだけで、従来と同じ保護が維持されるわけではありません。

このため、外部サービスを迂回する方法を準備するなら、直接接続を受けられる構成か、必要な保護を何で確保するか、認証や証明書に問題がないかを、あらかじめ保守会社と確認しておきます。

本番障害が起きてから、未検証の方法を試すことと、承認済みの代替手段へ切り替えることは違います。

また、外部サービスの利用者側では、提供者内部の変更を切り戻せない場合があります。契約上どこまで依頼できるか、設定履歴を取得できるか、変更通知を受け取れるかを確認してください。

自社で戻せるもの、提供者へ依頼するもの、業務で代替するものを分けておくことが必要です。

外注する作業も、完了条件は業務側で確認する

設定変更を保守会社へ依頼する場合、「変更しました」という報告だけを受け取って終わらせないようにしましょう。

技術的に設定を反映したことと、利用者が必要な仕事を行えることを、双方で確認します。

例えば、保守会社には設定値と接続記録を確認してもらい、自社の担当者は受注入力や帳票出力などを確認する役割分担が考えられます。作業前に確認項目を共有すれば、担当者の不在によって完了判断ができない事態も避けやすくなります。

依頼文は、例えば次のように作れます。

今回の設定変更について、対象と影響範囲、変更前の記録方法、変更後の確認項目、切り戻し条件と所要時間をご提示ください。管理接続を失った場合の対応方法も確認したいと考えています。作業完了時には、実施内容、確認結果、残る課題を共有してください。

これは依頼文の作成例です。実際の契約範囲に合わせて調整してください。

小規模事業者で複数の担当者を置けない場合も、何を確認したかを残し、影響の大きい変更だけ外部の確認を受ける方法を検討できます。

なお、NISTのガイドでは、変更の完了は実施後の確認まで含むものとされています。「設定を投入した時刻」だけを完了記録にしないことが重要です。

正常化した後には、臨時に緩めた制限や停止した自動処理が残っていないかを確認し、設定台帳と手順書を実際の状態へ更新します。

訓練では、「戻す判断」と「戻す操作」を別々に試す

切り戻し計画を用意したら、使えるかを確認しましょう。

まず、実際の機器を操作しない机上演習で、判断を試す方法があります。

21時に通信ルールを変更しました。管理画面では適用済みになっていますが、業務担当者から「保存処理だけ失敗する」と連絡がありました。保守会社は調査中で、切り戻しの判断期限まで残り10分です。

この架空の状況に対して、誰が追加適用を止め、誰が切り戻しを判断し、何を記録するかを確認します。

途中で「管理画面に接続できなくなった」「手順書を置いた共有フォルダーも開けない」という条件を加えれば、代替接続と資料の保管方法も点検できます。

次に、検証環境や適切に計画した保守作業で、切り戻し操作の所要時間と手順を確認します。机上で「戻せます」と回答できても、操作できることを確認したことにはなりません。

確認したいのは、必要な設定を取り出せるか、担当者が正しく操作できるか、戻した後に業務とアクセス制限を確認できるかです。

訓練のために本番の制御を無断で外したり、利用者のデータを壊したりする必要はありません。影響のない方法を選び、実施できなかった確認は未確認事項として残してください。

切り戻しを行ったこと自体を、失敗の隠蔽や担当者の能力不足と捉えないことも大切です。決めた条件で止め、影響を抑えられたのであれば、その判断と手順は機能したと評価できます。

まとめ――変更の成功には、「必要なら戻せる準備」も含まれる

設定変更の計画では、何を変更するかだけでなく、どこへ影響し、何を確認し、どの条件で止めるかを決めましょう。

変更前の記録を保存し、切り戻す対象と方法を具体化する。必要な時間を見積もり、作業終了時刻から判断期限を逆算する。管理接続を失った場合にも、正規の方法で対応できるようにする。

これらを「設定変更・切り戻し計画書」へまとめ、実際の作業で使ってください。

変更後に問題が出なかったことだけでなく、必要な業務と制限を確認できたことを、完了条件にします。切り戻した場合は、残った問題と再実施の計画まで管理しましょう。

「問題が出たら戻します」から、「何が起きたら、誰が、いつまでに、何を戻すか決めています」へ。

まずは、次に予定している設定変更を一つ選び、その説明ができるかを確認するところから始めてみてください。

ライトハウスコンサルタントでは、クラウドやアカウント、社内ルールの現状確認と、インシデント発生時の判断・連絡・復旧方針を確認する机上演習を支援しています。自社の変更手順や、保守会社との役割分担を整理したい場合は、ご相談ください。

投稿タグ
, , , , , , , , , , , ,