前編のふりかえり

前編では、Telstraで起きた全国規模の通信障害について、その経緯と本当の根本原因を整理しました。

定められた手順どおりに作業したにもかかわらず障害が起きたのは、その手順が対象機器に過去加えられていた設計変更を正しく反映していなかったためでした。文書化されなかった変更、適用されないまま残っていた更新、追跡されなかった既知のリスク。こうした複数の管理上の抜けが重なった結果として大規模障害へと連鎖したことを、ITILの変更実現（Change Enablement）の観点から読み解きました。

後編では、こうした障害を現場で防ぐための実務策と、障害が起きてしまったあとのコミュニケーションについて考えていきます。

第4章：保守作業を安全に行うための実務策

では、今回のような事故を防ぐために、日々の運用保守の現場では何をすればよいのでしょうか。

もちろん、Telstraのような大規模通信事業者と、一般企業の社内システムでは、システムの規模も構成も大きく異なります。

それでも、「過去の変更が分からない」「パッチが残っている」「手順書と実態が違う」といった問題は、多くの現場に共通しています。

ここでは、前回までの記事と同様に、比較的実装しやすい具体策として整理します。

1．すべての変更を、たとえ小さなものでも記録する

機器への設計変更、設定変更、暫定対処、障害対応中に行った一時的な変更。

どれほど小さな変更であっても、本番環境の状態が変わったのであれば、その内容を記録し、必要に応じて構成情報として維持します。

特に危険なのは、「その場で直したから、記録はあとでいい」という運用です。

障害対応中など、緊急性が高い場面では、まず復旧を優先せざるを得ないこともあります。しかし、そこで実施した変更が記録されないまま時間が経つと、「なぜそうなっているのか誰も分からない設定」や、「標準構成と異なるが理由が不明な機器」が少しずつ増えていきます。

今回のTelstraの事案で問題になったのも、まさにそのような状態でした。

変更記録は、単なる管理者向けの台帳ではありません。半年後、一年後に同じ機器を触る自分自身や、別の担当者に対する申し送りでもあります。

2．変更内容を、関連する手順書に反映させる

変更内容を記録しただけでは十分ではありません。

その変更によって、保守時の操作方法や確認項目が変わるのであれば、関連する保守手順書や作業チェックリストも更新する必要があります。

手順書に書かれている状態と、実際の機器の状態が食い違っていれば、作業者は正しい判断ができません。

むしろ、「手順どおりに作業したのに障害が起きる」という、作業者にとって最も避けにくい事故につながります。

運用の現場では、「手順を守れ」と言われることが少なくありません。

もちろん、手順を守ることは大切です。しかし、それと同じくらい重要なのが、「その手順が現在のシステムに対して正しいのか」を継続的に確認することです。

手順書は、一度作成したら完成する文書ではありません。システムに変更が加わるたびに更新されていく、生きた文書として扱う必要があります。

3．既知のリスクを可視化し、優先順位をつけて管理する

適用すべきソフトウェア更新やパッチ、対処すべき既知の不具合については、一覧化し、放置されない状態をつくります。

単にチケットを起票して終わるのではなく、「影響度」「発生可能性」「対象システムの重要度」「回避策の有無」などを踏まえて優先順位を決め、期限や担当者まで明確にすることが重要です。

前回の問題管理の記事で扱った「既知のエラー」の考え方は、パッチ管理や機器保守にもそのまま応用できます。

問題があることを知っているだけでは、リスクを管理していることにはなりません。

「いつか直す」という状態を、「誰が、いつまでに、どのような方法で直すのか」という状態に変える仕組みが必要です。

また、すぐに恒久対策ができない場合には、その期間中にどのような作業を避けるべきか、どのような監視を強化するべきかといった暫定策も残しておく必要があります。

4．保守作業も「変更」として扱い、事前に評価する

一見すると毎回同じことをしているルーチン作業であっても、本番ネットワークや本番システムの状態に影響するのであれば、変更実現の対象として考える必要があります。

「いつもやっている作業だから大丈夫」という判断は、ときに危険です。

システムは少しずつ変化します。構成変更、パッチ適用、機器交換、接続先の変更などが積み重なれば、半年前には安全だった作業が、現在も安全であるとは限りません。

そのため、保守作業の前には少なくとも、影響範囲、想定されるリスク、作業失敗時のロールバック方法、実施タイミング、監視方法などを確認します。

特に深夜や休日など、通常よりも少ない人数で作業する場合には、事前評価と手順の正確さが重要な安全網になります。

作業者の経験や勘だけに頼るのではなく、事前の仕組みで事故を防げる状態にしておくことが大切です。

5．時間帯とブラストレイディウスを意識してスケジュールする

今回の障害は深夜に始まり、その後、朝になって利用者が増え、ネットワーク負荷が高まるにつれて影響が大きくなりました。

この点からは、変更作業の「時間帯」についても考える必要があります。

一般的には、利用者の少ない深夜帯に作業することが安全だと考えられています。それ自体は間違いではありません。

ただし、重要なのは単に「利用者が少ない時間に実施すること」だけではありません。

万一問題が起きた場合に、どのくらいの時間で異常を検知できるのか。朝の利用ピークが来る前に原因を特定できるのか。必要な担当者やベンダーへすぐに連絡できるのか。切り戻しを実施する判断者がその時間帯にいるのか。

そこまで含めて、作業時間を設計する必要があります。

また、一度の変更で影響する範囲、いわゆるブラストレイディウス（被害範囲）を小さくしておくことも重要です。

可能であれば一部の機器や拠点から段階的に変更する、正常性を確認してから対象範囲を広げる、問題が発生した場合に自動的に切り離せる構成にする、といった方法が考えられます。

前回の記事で触れたブラストレイディウスを小さくする考え方は、権限設計だけの話ではありません。

保守作業の実施方法や、変更スケジュールの設計にも、そのまま当てはめることができます。

第5章：障害対応と、その後のコミュニケーション

変更実現という観点に加えて、今回の事案は、インシデント発生時のコミュニケーションについてもいくつかの示唆を与えています。

Telstraは障害の初期段階で、自社サイトを通じて状況を発信しました。

しかし、その時点で把握できていた影響はまだ限定的で、後から判明した大規模な影響を反映した内容ではありませんでした。

CEOは後に、「早期に行った情報更新は、その時点で分かっていた内容を反映したものであり、後になって現れた、より大きな影響については反映されていなかった」という趣旨の説明をしています。

障害の規模が時間とともに拡大するケースでは、この問題は避けにくいものです。

初期段階で情報を出せば、その後に判明した事実と内容がずれる可能性があります。一方で、正確な全容が分かるまで情報を出さなければ、「なぜ何も知らせなかったのか」という問題になります。

だからこそ、障害時の情報発信では、最初からすべてを正確に伝えようとするよりも、「現時点で分かっていること」「まだ分かっていないこと」「次回いつ更新するのか」を明確に分けて伝えることが重要になります。

また、所管大臣への連絡が、最初の異常検知から一定の時間を要した点についても、報道で関心が集まりました。

特に、今回のように緊急通報に影響する可能性のある通信インフラでは、社内での技術的な復旧対応だけを考えるわけにはいきません。

規制当局、関係機関、緊急サービス、利用者などに対して、「いつ」「誰が」「何を」「どの時点まで伝えるのか」をあらかじめ決めておく必要があります。

前回の障害訓練の記事では、「意思決定訓練」「顧客説明訓練」「コミュニケーションルートの確認」といった内容に触れました。

今回のTelstraの事案は、まさにそうした準備が実際の障害時にどう機能するかを問われたケースだといえます。

技術的な原因を調査する担当者が復旧に集中する一方で、別の担当者が外部とのコミュニケーションを進める。必要に応じて経営層や規制当局にも状況を上げる。

大規模障害では、こうした役割分担も重要になります。

なお、この事案の背景には、2025年9月に発生したOptus社の緊急通報障害があります。

そこで得られた教訓を踏まえ、緊急通報の失敗が発生した際の安否確認などについても、通信事業者にはより厳格な対応が求められるようになっていました。

過去の障害を単なる「事故」として終わらせるのではなく、制度や手順へ反映し、次の障害に備える。

その意味では、個々の企業だけでなく、通信業界全体として継続的改善を進めている途中にあることも、この事案から読み取ることができます。

最後に：手順どおりに作業しても、手順が間違っていれば障害は起きる

Telstraの障害が突きつけたのは、運用保守に携わる人にとって少し厳しい事実です。

担当者は手順どおりに作業した。それでも障害は起きた。

なぜなら、その手順そのものが、対象機器に過去に加えられた変更を正しく反映していなかったからです。

これは、運用保守に携わる人であれば、決して他人事とはいえません。

文書化されなかった設計変更。適用されないまま残っているパッチ。更新されていない手順書。障害対応時に一時的に入れたままになっている設定変更。

どれも、一つひとつを見れば地味な問題です。

そして、日々の問い合わせ対応や障害対応、定期作業に追われていると、「今すぐ困っているわけではないから」と、つい後回しにしたくなる作業でもあります。

しかし、今回の事案では、そうした小さな管理上の抜けが積み重なった先で、全国規模の通信障害が発生しました。

ITILの変更実現が教えているのは、変更とは「システムに変更を加えて終わり」ではない、ということです。

変更を記録する。

現在の構成を更新する。

必要な手順書へ反映する。

既知のリスクを追跡する。

必要な恒久対策を実施し、完了まで確認する。

そこまで行って初めて、実施した変更が組織の中で適切に管理された状態になります。

言い換えれば、変更を「機器の中だけ」に残してはいけません。変更した事実と、その理由、注意点を、人や文書、運用プロセスの側にも残しておく必要があります。

前回までの記事で述べてきたこととも、根は同じです。

個人の注意力だけに依存せず、誰かが間違えたとしても大きな障害には至りにくい仕組みをつくること。

そして、障害が起きたときには、「誰が失敗したのか」で終わらせるのではなく、「なぜその失敗が障害にまで発展したのか」を考え、プロセスや仕組みの改善につなげること。

その積み重ねが、長い目で見ればシステムを守ることにつながります。

いま自分たちが管理している機器やシステムの中に、「誰も実態を知らない変更」が眠っていないでしょうか。

適用されないまま残っているパッチはないでしょうか。

現状と内容が食い違っている手順書はないでしょうか。

「昔からこうなっているけれど、なぜこの設定なのかは誰も知らない」という機器はないでしょうか。

もし一つでも心当たりがあるのであれば、それは障害が起きてから慌てて調べるよりも、平常時のうちに確認しておいたほうがよい対象です。

全国規模の障害とまではいかなくても、同じ構造を持った事故は、規模の大小を問わずどの現場でも起こり得ます。

冷や汗をかくような障害になる前に、一度、自分たちの環境を棚卸ししてみてはいかがでしょうか。

参考文献

Telstra Exchange（2026）. “Triple Zero Senate Inquiry, opening statement from Vicki Brady.”（Telstra CEOによる上院委員会での意見陳述）
https://www.telstra.com.au/exchange/triple-zero-senate-inquiry–opening-statement-from-vicki-brady

Telstra Exchange（2026）. “Our recent mobile network outage has been resolved: here’s what happened.”
https://www.telstra.com.au/exchange/some-mobile-calls-and-data-services-are-affected-today–here-s-w

Australian Government, Minister for Communications（2026）. “STATEMENT – Telstra Outage.”
https://minister.infrastructure.gov.au/wells/media-release/statement-telstra-outage

ABC News（2026）. “Time-keeping technology triggers Telstra nationwide outage. Here’s what we know.”
https://www.abc.net.au/news/2026-07-08/telstra-nodes-time-keeping-technology-causes-outage/106892560

The Register（2026）. “NTP server that traveled back in time caused massive Aussie mobile outage.”
https://www.theregister.com/networks/2026/07/17/ntp-server-that-traveled-back-in-time-caused-massive-aussie-mobile-outage/

Information Age (ACS)（2026）. “Telstra ignored bug before 8.8 million-user outage.”
https://ia.acs.org.au/article/2026/telstra-ignored-bug-before-8-8-million-user-outage.html

piyolog（2026）.「オーストラリアで起きた全国的な通信障害についてまとめてみた」.
https://piyolog.hatenadiary.jp/entry/2026/08/22/033313