保守作業がなぜ全国的な障害を生んだのか【前編】：Telstra障害の経緯と本当の根本原因
はじめに：「直そうとした作業」が、最大の障害になるとき
運用保守の現場には、ある種の逆説があります。システムを安定させるために行うはずの保守作業そのものが、ときとして大きな障害の引き金になる、というものです。
不具合を直すための作業、機器を安定稼働させるための再起動、既知の問題に対処するためのメンテナンス。どれも本来は、障害を防ぐために行われます。しかし、対象となるシステムの状態や過去の変更履歴が正しく把握されていなければ、「直すための作業」が逆に障害を発生させることがあります。
2026年7月8日、オーストラリアの通信大手Telstraで、全国規模のモバイルネットワーク障害が発生しました。通話とデータ通信が広範囲で利用できなくなり、緊急通報番号Triple Zero（日本でいう110番・119番にあたる000番）への接続にも影響が及びました。ビクトリア州では地方鉄道網が全面的に止まり、決済システムにも支障が出るなど、影響は通信サービスの中だけにとどまりませんでした。
この障害で特に注目すべきなのは、その発端です。
原因となったのは、サイバー攻撃でも、突発的なアクセス集中でもありません。ネットワークの時刻同期を担うサーバーに対する保守作業でした。 バックアップ電源の不具合を直すために行われた、いわば「良かれと思って実施した」メンテナンスが、結果として約880万人の顧客に影響する全国的な通信障害へと連鎖していったのです。
しかも、担当者が勝手な操作をしたわけではありません。公表されている情報を見る限り、担当者は定められた手順に従って作業していました。それでも障害は発生しました。
では、何が問題だったのでしょうか。
本記事では、この事案をオーストラリア側の一次情報、具体的にはTelstraの公式発表、CEOによる上院委員会での意見陳述、所管大臣の声明などをもとに整理します。そのうえで、ITILの変更実現（Change Enablement）プラクティスの観点から、「なぜ通常の保守作業が大規模障害につながったのか」「どのような管理をしていれば防げた可能性があるのか」を掘り下げます。
前回までの記事と同様、主な読者として想定しているのは、運用保守に携わり始めた若手エンジニアや、ITSMに関わる方です。
第1章：タイムラインで見る、障害の連鎖
まず、Telstraのフィッキー・ブレイディCEOが上院委員会に提出した意見陳述などの一次情報をもとに、何が起きたのかを時系列で整理します。
発端となったのは、深夜に実施された保守作業でした。
バックアップ電源の不具合に対応するため、ネットワーク内のNTP（Network Time Protocol）サーバー、つまりネットワーク内の各機器に正しい時刻を提供し、時刻を同期させるための装置に対して保守作業が行われました。
7月8日 午前3時38分：担当者が、規定された手順に従ってサーバーの保守作業を完了し、機器を再起動した。
ところが、内部のソフトウェア構成上の問題により、サーバーは誤った日付で再起動した。 報道によれば、機器の日付は約1,024週間さかのぼり、2006年として認識される状態になったとされています。
モバイルネットワークを構成する一部のシステムは、正確な時刻情報に依存して動作しています。誤った日付の情報がネットワーク内へ伝播するにつれ、通話やデータ通信に失敗するケースが発生し始めました。ネットワーク側から見ると、利用者の端末が「約20年後の未来」から接続してきているような状態になります。その結果、証明書の有効性確認などでも異常と判断され、通信が拒否される事象が発生しました。
午前4時20分：Telstraが最初の異常を検知。
午前4時38分：Telstraが自社サイトに、問題を調査中である旨を掲載。この段階では把握できていた影響はまだ限定的で、大規模障害として扱う閾値には達していませんでした。
その後、朝になって人々が活動を始め、ネットワークの利用量が増えていくにつれて、時刻情報の問題がより多くの箇所で顕在化しました。それに伴い、障害の影響範囲も拡大していきました。
午前7時11分：原因となっている機器を特定し、ネットワークから切り離す作業を開始。
午前10時頃：大半の通話・データ通信が正常化。ピーク時には、モバイルネットワーク上の全通話・データセッションの約45％が影響を受けていました。
午後4時頃：当初発生した障害への対応が完了。
しかし、障害対応はここで完全に終わったわけではありませんでした。
当初の障害を収束させる過程で、Triple Zeroへの一部の発信に影響する二次的な問題が新たに判明します。同じソフトウェア構成に起因する問題ではあったものの、最初の障害とは別の対処を必要とする事象でした。
障害期間を通じて、58,835件のTriple Zeroへの発信は正常に成功しました。一方で、604件の発信ではエラーが発生しています。
Telstraでは、緊急通報への発信が失敗した場合、自動的に安否確認（welfare check）を実施する手順が設けられていました。そのため、今回失敗した604件についても安否確認が実施されています。
この二次的な問題への対応策が実装されたのは、翌7月9日の午前10時38分でした。
つまり、深夜に実施された一件の保守作業が、単なる一台の機器トラブルでは終わらず、最終的には約880万人の利用者に影響し、緊急通報にまで波及し、さらに完全な収束まで複数の段階を要する事態へと連鎖したことになります。
一つの保守作業が、ネットワーク全体へどのように波及していったのか。この点が、この事案を考えるうえで非常に重要です。
第2章：本当の根本原因は「時刻のずれ」ではなかった
技術的な直接原因だけを見れば、NTPサーバーが誤った日付で起動したことが障害の引き金です。
この現象自体は、GPSで扱われる週番号が一定の周期で一巡することによって発生する「GPSロールオーバー」などと関連する、古い機器では知られている問題の一つでした。
しかし、TelstraのCEOが上院委員会で行った陳述を読むと、今回の障害を単純に「古い機器の時刻がおかしくなった事故」と捉えるだけでは、本質を見誤ることが分かります。
CEOの説明から見えてくる本当の根本原因は、単なる技術的な不具合ではなく、運用管理のプロセスにありました。
ブレイディCEOは、原因についておおむね次のように説明しています。
第一に、過去に行われた設計変更が、適切に文書化されていなかったことです。
今回問題となった機器には、以前発生した別の不具合を修正するため、意図的な設計変更が加えられていました。しかし、その変更内容が適切な形で文書に残されていませんでした。
その結果、今回の保守を担当したチームは、その機器が標準的な構成とは異なる状態になっていることや、再起動した際にどのような振る舞いをする可能性があるのかを十分に認識しないまま作業することになりました。
第二に、本来適用されるべきソフトウェア更新が適用されていなかったことです。
問題となった機器のGPSカードには、この問題への対処につながるソフトウェア更新が存在していました。しかし、その更新が当該機器には適用されていませんでした。
ブレイディCEOは、「そのソフトウェア更新が完了していた、あるいは過去の設計変更が適切に文書化され、保守手順に反映されていれば、今回の障害は起こらなかった可能性がある」という趣旨の説明をしています。
さらに、通常の保守作業がこの規模の障害を引き起こし得たこと自体、Telstraの内部統制（controls）が十分ではなかったことを意味すると認めています。
ここに、この事案の核心があります。
今回、実際に作業を行った担当者は、定められた手順に従って作業していました。
にもかかわらず障害が発生したのは、その手順そのものが、対象機器の実際の状態、つまり過去に加えられていた設計変更を正しく反映していなかったからです。
作業者からすれば、手順書に書かれている内容を守って作業しているにもかかわらず、その手順を実行すると障害が起こる状態になっていたことになります。
これは、現場の担当者の注意力だけでは防ぐことが難しい問題です。
言い換えれば、「既知のリスクが存在していたにもかかわらず、それが十分に把握され、優先順位づけされ、対処される前に顧客影響として表面化してしまった」ということです。CEO自身の説明を踏まえても、問われたのはまさにこの部分でした。
前回までの記事で繰り返し扱ってきたテーマが、ここでも当てはまります。
障害は、必ずしも誰か一人の不注意から起こるわけではありません。むしろ、記録されなかった変更、更新されなかった手順、放置された既知の問題といった、複数の小さな管理上の抜けが重なったところから発生します。
「誰が間違えたのか」ではなく、「なぜ正しい手順を実行しても障害につながる状態になっていたのか」を問う必要があります。作業者個人を責めても、仕組みが変わらなければ同じ種類の障害は再び起こります。
第3章：ITILの変更実現（Change Enablement）で読み解く
この事案は、ITILの変更実現（Change Enablement）プラクティスという観点から見ると、非常に分かりやすい教訓を含んでいます。
変更実現とは、サービスや構成アイテムに対して行われる変更について、リスクを適切に評価・管理しながら実施できるようにするためのプラクティスです。
「変更管理」という言葉から、変更を厳しく審査し、できるだけ変更をさせないための仕組みを想像する人もいるかもしれません。しかし、本来の目的は変更を止めることではありません。
必要で価値のある変更を、許容できるリスクの範囲内で、できるだけ円滑かつ安全に実現することが目的です。
そして、ここで重要なのは、変更実現が扱う「変更」は、大規模なシステム更改や新機能の追加だけを意味するわけではないことです。
今回のような機器の設計変更、設定変更、ソフトウェア更新、さらには保守作業に伴って状態が変わる作業も、変更として捉える必要があります。
Telstraの事案を、変更実現の観点から分解してみましょう。
1．過去の設計変更が、変更記録として残されていなかった
問題となった機器には、過去に設計変更が加えられていました。
しかし、その変更内容が適切に文書化されていなかったため、後からその機器を扱う担当者が、現在の構成を正しく把握できない状態になっていました。
ITILの変更実現では、変更を承認して実施するだけでなく、実施した変更を記録し、その結果として構成がどのような状態になったのかを追跡できるようにしておくことが重要です。
変更記録は、単なる監査用の証跡ではありません。
後続の作業者が「この機器はいま、どのような状態なのか」「標準構成と何が違うのか」「過去にどのような理由で変更されたのか」を理解するための情報でもあります。
今回は、その土台となる情報が十分に残されていませんでした。
2．変更の影響が、保守手順に反映されていなかった
設計変更が適切に文書化されなかった結果、その変更内容は保守手順にも十分に反映されませんでした。
そのため、保守チームは対象機器の実際の構成や、再起動時に発生する可能性のある挙動を知らないまま作業することになりました。
変更実現では、変更そのものを実施して終わりではなく、その変更によって影響を受ける手順、構成情報、監視方法、復旧方法などについても必要に応じて更新することが求められます。
つまり、「機器を変更すること」と「その変更を組織の知識として定着させること」は、別々の作業ではありません。
変更後の状態を、他の担当者でも理解し、将来の運用や保守で正しく扱えるようにするところまで含めて、変更を管理する必要があります。
今回の事案では、この「変更を組織に定着させる」という部分が弱かったと考えられます。
3．既知のリスクである未適用の更新が残されていた
問題となった機器には、本来適用されるべきソフトウェア更新が適用されていませんでした。
これは、少なくとも結果として見れば、対処可能なリスクが残された状態で本番運用が続いていたことを意味します。
前回の記事で扱った問題管理の用語を使えば、「既知のエラー」に近い状態と考えることもできます。
原因や対処方法が既に分かっている、あるいは調査すれば把握できる問題については、「知っている」というだけでは意味がありません。
どの程度のリスクがあるのかを評価し、いつまでに対処するのかを決め、実際に恒久対策が完了するところまで追跡する必要があります。
「対応方法は分かっているが、優先順位が低いので後回しになっている」という状態は、多くの現場で起こり得ます。しかし、その「後回し」が長期化すれば、今回のように別の保守作業をきっかけとして問題が表面化する可能性があります。
つまり、今回の直接的な引き金はNTPサーバーの時刻異常でした。
しかし、それを顧客影響を伴う大規模障害にまで発展させた背景には、変更の記録、変更内容の手順への反映、既知リスクの追跡と解消という、変更実現における基本的な動作が十分に機能していなかったことがあったと読み解けます。
前編のまとめと、後編について
ここまでで、今回の障害が単なる時刻の不具合ではなく、変更の記録、手順への反映、既知リスクの追跡という運用管理の課題から生まれたものであることを見てきました。
では、こうした障害を日々の現場で防ぐには、具体的に何ができるのでしょうか。そして、実際に障害が起きてしまったとき、外部とのコミュニケーションはどうあるべきなのでしょうか。
後編では、比較的取り入れやすい実務策と、障害対応時の情報発信のあり方について整理していきます。