KDDI 大規模通信障害から考える通信インフラの設計責任 – 冗長化と復旧運用の難しさ

2022 年 7 月 2 日 1 時 25 分頃から、KDDI で大規模な通信障害が発生しました。影響は音声通話やデータ通信だけでなく、物流、自動車、気象、銀行、交通など、通信を前提とした多くのシステムへ広がりました。

当時は、2018 年 12 月にソフトバンクで発生した大規模障害と比較されることも多く、KDDI の障害は最大約 3,915 万回線に影響したと説明されていました。

この記事では、当時の速報的な見方ではなく、通信インフラの設計・運用責任という観点で、この障害をあらためて整理します。

特定企業を批判するためではなく、大規模な通信インフラでは、冗長化、切り戻し、輻輳制御、加入者管理、外部説明がどれだけ難しいのかを見るための記事です。

まず結論

KDDI の大規模通信障害は、単純に装置が壊れたという話ではなく、メンテナンス作業、切り戻し、トラフィック集中、VoLTE 交換機の輻輳、加入者 DB の負荷、データ不一致、復旧手順が連鎖した事例として見るべきです。

観点	表面的な見方	設計・運用としての見方
障害原因	通信設備で障害が起きた	変更作業後の切り戻しと輻輳制御が連鎖した
冗長化	冗長構成なら止まらないはず	冗長化しても復旧時の流量・状態管理が難しい
復旧	戻せば直るはず	切り戻しでトラフィックが集中し、別の負荷を生むことがある
影響範囲	携帯電話の障害	社会インフラに接続する多層的な通信障害

大規模インフラでは、冗長化していることと、安全に復旧できることは同じではありません。ここが非常に重要です。

原因より先に影響範囲を見る

大規模障害では、最初に原因を当てにいくより、影響範囲を整理する方が重要です。どの利用者が、どのサービスを、どの地域で、どの程度使えなかったのか。音声通話なのか、データ通信なのか、緊急通報なのか、法人向け回線なのか。そこを分けないと、障害の構造が見えません。

KDDI の障害では、携帯電話の通話や通信だけでなく、物流、自動車、気象、銀行、交通など、通信を前提にしたサービスへ影響が広がりました。これは、通信キャリアが単なる回線提供者ではなく、社会システムの前提になっていることを示しています。

影響範囲を見ると、障害対応で何を優先して復旧すべきかも変わります。利用者数だけでなく、社会的な重要度、代替手段の有無、緊急性を含めて判断する必要があります。

当時何が起きたのか

当時の説明では、メンテナンス作業中のトラフィックルート変更に伴い、VoLTE 交換機でアラームが発生しました。その後、当該トラフィックルートの切り戻しを行ったものの、切り戻し後にトラフィックが集中し、VoLTE 交換機の輻輳が発生したとされています。

さらに、並行して加入者 DB の負荷が高まり、データ不一致が発生し、その修正も必要になったと説明されていました。

ここで重要なのは、最初のきっかけだけを見るのではなく、切り戻し後のトラフィック集中や加入者 DB の状態管理まで含めて見ることです。大規模通信障害は、一つの装置や一つの作業だけで完結しないことが多いです。

復旧操作そのものが負荷になる

通信インフラでは、障害時に切り戻せばよい、冗長系へ逃がせばよい、と単純には言えません。

大量の加入者、セッション、認証状態、音声制御、データ通信が絡む環境では、復旧操作そのものが追加の負荷になります。

• 切り戻し先に想定以上のトラフィックが流れる
• 交換機や制御プレーンが輻輳する
• 加入者 DB や認証系への問い合わせが急増する
• 状態不一致の修正に時間がかかる
• 流量制御によって復旧の見え方が段階的になる

つまり、復旧とは単に元に戻す作業ではありません。壊れた状態、混雑した状態、状態不一致が起きた状態から、システム全体を安定状態へ戻す運用です。

冗長化だけでは足りない

通信キャリアのような大規模インフラでは、当然ながら冗長化は行われています。しかし、冗長化しているから障害が起きないわけではありません。

冗長化は、障害時に別経路や別系統へ逃がすための構造です。ただし、その別系統が十分な流量を受けられるか、状態を引き継げるか、切り替え時に制御プレーンが耐えられるかは別問題です。

特に音声系や加入者管理のように状態を持つシステムでは、単純な Active/Standby や経路冗長だけでは語れません。状態管理、復旧順序、流量制御、監視、手動判断まで含めて設計する必要があります。

加入者 DB と制御プレーンの難しさ

元記事でも気にしていた点ですが、VoLTE 交換機と加入者 DB の間で、どのようなデータ連携や状態管理が行われていたのかは非常に重要です。

大規模な通信サービスでは、ユーザーの接続状態、認証状態、サービス利用可否、音声制御、位置情報など、多くの情報が制御プレーン側で扱われます。

この部分に負荷が集中すると、単にパケットが流れないというだけでなく、利用者の状態が正しく扱えない、復旧したはずなのに通信できない、段階的にしか戻せない、といった問題につながります。

通信障害を見る時は、データプレーンだけでなく、制御プレーンと状態管理も見る必要があります。

社会インフラとしての影響範囲

携帯電話の障害は、個人の通話や通信だけにとどまりません。物流、自動車、気象、銀行、交通、決済、監視、設備管理など、多くの社会システムが通信を前提に動いています。

このため、通信キャリアの障害は、単なる一企業のサービス障害ではなく、社会インフラの障害として扱う必要があります。

通信キャリアを土管屋と軽く見ることはできますが、その土管が止まると社会の多くの仕組みが止まります。だからこそ、通信キャリアには非常に重い設計責任と運用責任があります。

記者会見で技術説明できることの意味

当時の記者会見では、技術的な説明が比較的具体的に行われていた印象があります。もちろん、すべての内部構造が公開されるわけではありません。

それでも、何が起点で、どのように輻輳し、どの領域に負荷が波及したのかを説明できることは重要です。大規模障害では、技術説明が曖昧だと、社会的な不信がさらに大きくなります。

障害対応において、技術的な事実を整理し、分かることと分からないことを分けて説明する能力は、運用責任の一部だと思います。

止めない設計と戻す設計は別である

インフラ設計では、止めないための設計に目が向きがちです。冗長化、二重化、分散配置、監視、予備系、バックアップ回線などです。

しかし、大規模障害では、止めない設計だけでは足りません。壊れた後に、どう安全に戻すかが別の設計として必要になります。

設計	見ること
止めない設計	冗長化、分散、監視、事前検知、単一障害点の排除
戻す設計	切り戻し手順、流量制御、段階復旧、状態不一致の解消、外部説明

冗長化は重要です。しかし、復旧時に流量が集中し、制御プレーンや加入者 DB に負荷がかかるなら、冗長化だけでは復旧設計として不十分です。

障害が起きた時に、どの順番で戻すのか。どのサービスから開放するのか。どの状態を確認したら次へ進むのか。復旧を急ぐほど危険になる場面をどう制御するのか。ここまで含めて設計責任です。

設計で考えるべきこと

この障害から学ぶべきことは、単に KDDI が悪かったという話ではありません。大規模インフラを設計・運用する時に、何を考えておくべきかです。

• メンテナンス時の切り戻し手順は安全か
• 切り戻し先に流量が集中しても耐えられるか
• 制御プレーンとデータプレーンの負荷を分けて監視できるか
• 加入者 DB や認証系の状態不一致をどう検知するか
• 段階復旧時にどのサービスから戻すか
• 障害時に外部へ何を説明できるか

冗長化や監視を入れるだけでは不十分です。障害が起きた後に、どう安全に戻すかまで設計しておく必要があります。

まとめ

KDDI の大規模通信障害は、単純に装置が壊れたという話ではありません。メンテナンス作業、切り戻し、トラフィック集中、VoLTE 交換機の輻輳、加入者 DB の負荷、状態不一致、復旧手順が連鎖した事例として見るべきです。

大規模インフラでは、冗長化していることと、安全に復旧できることは同じではありません。止めない設計と、壊れた後に戻す設計は別です。

通信キャリアの障害は、利用者の通話やデータ通信だけでなく、物流、自動車、気象、銀行、交通など、多くの社会システムへ波及します。だからこそ、影響範囲、制御プレーン、データプレーン、加入者管理、復旧順序、外部説明を分けて考える必要があります。

障害対応の質は、障害が起きた瞬間だけでは決まりません。事前にどこまで影響範囲を想定し、復旧手順を設計し、状態不一致を検知し、段階的に戻す準備ができているかで決まります。