要約

  • 2025年10月13日、Vodafone UKの固定ブロードバンド、4G、5Gは全国規模でおよそ2時間にわたり影響を受けた。Reutersは復旧対応と5万件を超えるDowndetector上の利用者報告を伝えたが、これは影響顧客数ではない。NetBlocksは全国的な接続障害、ウェブサイトとステータスページの停止、約2時間後の復旧を観測した。
  • ThousandEyesはAS25135とAS5378で同時に大規模なBGP経路撤回が生じ、公示アドレス空間がほぼゼロまで落ちたことを観測した。これは共有されたルーティング制御面の影響を示すが、Vodafoneが確認した根本原因ではない。ITVが伝えたVodafoneの説明は、あるベンダーパートナーに関係する悪意によるものではないソフトウェア上の問題であり、公開記録はベンダー名も法的責任も確定していない。
  • 実務上の責任基準は、誰が経路状態を変更できたか、固定系とモバイル系をまたぐ共通依存関係をどのように限定したか、外部からの到達性を独立して監視したか、そして復旧と再発防止を別々に立証できるかである。登録情報や説明文は記録を残すが、継続性を決めるのは稼働中のネットワークである。

利用者に現れた障害と慎重に読むべき境界

障害は2025年10月13日に発生し、固定ブロードバンドと4G・5Gのデータ通信に全国規模の影響が出た。NetBlocksはモバイルとブロードバンドの接続性低下を計測し、約2時間後に復旧したと報告した。ReutersもVodafoneが英国でブロードバンド、4G、5Gの復旧に取り組んでいたと伝えている。

一方、すべてのサービスが同じ形で止まったと一般化してはならない。Reutersは2G音声通話が影響を受けなかったと報じ、ITVはVodafoneの説明として通話とSMSが継続したと伝えた。これらは限定されたサービス境界を示す記録であり、あらゆる場所、端末、通話、SMS、旧世代の機能が個別に検証されたという意味ではない。

NetBlocksはVodafoneのウェブサイトとステータスページも利用できず、Vodafoneの基盤を利用する別のサービスにも影響が及んだと観測した。障害時の案内手段が同じ到達性に依存していれば、サービス停止と説明不能が同時に起きる。ステータス経路の独立性は広報上の装飾ではなく、インシデント対応の一部である。

Downdetectorの5万件超という数字も範囲を限定して読む必要がある。これは利用者による報告件数であって、影響を受けた顧客、重複を除いた利用者、検証済み障害件数ではない。公開資料は全国規模の深刻な混乱を示すが、金銭損失、特定の被害者、公衆安全上の結果を数量化してはいない。規制当局の最終判断、裁判所の認定、罰金、過失の確定もこの証拠群には含まれない。

BGPの観測が障害像に加えるもの

この事例を一般的な通信障害と分けるのは、ThousandEyesによるルーティング観測である。AS25135とAS5378で重要なBGP経路が同時に撤回され、両自律システムの公示アドレス空間はほぼゼロまで落ちた。撤回と回復の周辺では、新たな公示活動も観測された。

BGPは、独立したネットワーク同士が、どのIPアドレス範囲へどの経路で到達できるかを交換する仕組みである。経路が撤回されると、隣接ネットワークは、それまで使っていた行き先への道がその経路では利用できないと判断する。利用者の端末や回線が物理的に動いていても、インターネット側に宛先への地図がなければ通信は完了しない。

二つの自律システムでほぼ同時に大きな変化が起きたことは、共有された制御面、共通の自動化、あるいは連動したポリシー状態を調べる合理的な根拠になる。固定ブロードバンドとモバイルデータは接続技術が異なっても、外部到達性を構成する上位のルーティング機能を共有し得る。ただし、どの内部機器、コントローラー、コマンド、経路反射器、担当者が状態を作ったかは、外部BGPデータだけでは分からない。

Vodafoneの説明は別の証拠層にある。ITVによると、Vodafoneは一社のベンダーパートナーに関係する悪意によるものではないソフトウェア上の問題がインシデントを引き起こし、問題は解消されたと述べた。この説明は悪意ある攻撃という見方を退け、サプライヤーとの関係を示すが、ベンダー名、製品、変更内容、BGP撤回へ至る技術的な連鎖は明らかにしていない。

したがって、安全な結論は限定的である。外部監視では同時の経路撤回が見え、Vodafoneは別途ベンダーパートナーのソフトウェア問題を説明した。両者は整合し得るが、直接因果は公開情報で立証されていない。この空白こそ、責任を問うために必要な追加証拠の所在を示している。

ルーティング状態を変える権限はどこにあったか

通信事業者は、ソフトウェア、運用支援、管理基盤、更新作業を外部企業に委ねることがある。ベンダーが作業を実行し、事業者が承認する場合もあれば、内部動作を直接観察できないサービスに依存する場合もある。今回の公開記録は、どの形態だったかを示していない。

責任を検証するには、組織名ではなく行為ごとに権限を追跡する必要がある。誰がソフトウェアや設定を承認したのか。誰が対象範囲を決めたのか。どの人間または自動化IDが変更を開始し、どの制御系が受理したのか。外部経路の喪失を誰が検知し、誰が停止、分離、ロールバック、復旧を決定できたのか。サプライヤーの権限が始まり、事業者の独立権限へ戻る境界も記録されるべきである。

外部委託そのものが問題なのではない。危険なのは、ソフトウェアを制御する主体と結果を引き受ける主体の間に観測不能な隙間ができることだ。契約上の義務が割り当てられていても、稼働中のネットワークが示すのは、引き渡しが実際に機能したかどうかである。経路の正確性、変更範囲、独立した停止権、回復経路が技術的に実装されて初めて、責任分担は運用上の意味を持つ。

表題の「ソフトウェア障害」はこの限定の中で読む必要がある。Vodafoneが述べたのは、一社のベンダーパートナーに関係する悪意によるものではないソフトウェア上の問題である。公開情報はベンダーを特定せず、過失、欠陥製品、契約違反、法的責任を認定していない。ここでの障害は運用上報告された問題を指し、責任の法的な裁定ではない。

復旧したことと、再発防止が証明されたことは別である

NetBlocksは約2時間後のサービス復旧を報告し、ThousandEyesは撤回と回復の前後でBGP公示の動きを観測した。経路が再び見えることは到達性の回復に必要だが、それだけで利用者サービスが全面的に安定したとは限らない。経路が戻っても、セッションの再確立、アプリケーション、運用ツール、特定の経路で障害が残ることがある。

説得力のある復旧記録は三層を突き合わせる。第一に、対象プレフィックスが意図した相手へ安定して公示されていること。第二に、固定回線とモバイルデータの代表的な利用経路から外部への通信が成功すること。第三に、依存サービス、運用ツール、ステータス手段が機能することだ。経路の一時的な再出現ではなく、一定の観測期間にわたり公示数、経路属性、サービス試験が期待範囲にある必要がある。

公開資料はVodafoneが使った復旧コマンド、復旧基準、観測期間を示していない。「解消した」という説明と外部から見たサービス復帰は、当日の障害が終わったことを支える。しかし、どの防護策が働いたか、原因が隔離されたか、将来の再発防止策が実装され独立に試験されたかまでは証明しない。

公開説明を検証可能にする証拠

信頼できる事後記録には、利用者症状、内部警報、最初の外部BGP撤回、インシデント宣言、重要な変更、安定した経路復帰、固定・モバイル双方の試験完了を同じ時間軸で置く必要がある。時刻の出所と不確実性も残し、後から作った精密さを事実のように見せてはならない。

変更記録には、関係したソフトウェアまたは設定の安定した識別子、承認した人間と機械ID、実行主体、影響可能な範囲を含める。サプライヤーが関与したなら、推奨、承認、実行、監視の権利を分ける。機密情報を保護することと、説明を単なる「ベンダー問題」で終わらせることは同じではない。

ルーティング記録は、影響を受けた自律システム、プレフィックス、意図した公示、実際の公示、相手ネットワークから見た経路、回復時の変動を示すべきである。内部テレメトリーと独立した外部観測が一致すれば確信は強まり、食い違えば監視の盲点が明らかになる。登録簿は番号資源の持ち主と履歴を示すが、実際に経路が正確か、サービスが継続しているかは稼働中の制御面で確かめるほかない。

なお、現在の公開資料では、ベンダー名、ソフトウェア製品、Vodafone内部の構成、変更記録、契約、完全なインシデント記録は分からない。ソフトウェア問題が経路撤回を直接生んだとも確定していない。この不明点を残したまま、観測された経路状態、会社に帰属する説明、今後検証すべき管理策を明確に分けることが、責任ある評価である。

出典