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

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

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

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

まず結論

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

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

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

当時何が起きたのか

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

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

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

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

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

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

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

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

冗長化だけでは足りない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設計で考えるべきこと

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

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

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

まとめ

KDDI の大規模通信障害は、通信キャリアの設計責任と復旧運用の難しさを考える上で重要な事例です。

メンテナンス中のトラフィックルート変更、切り戻し、VoLTE 交換機の輻輳、加入者 DB の負荷、データ不一致、段階的な復旧。これらは、大規模通信インフラが単純な冗長化だけでは守れないことを示しています。

通信キャリアは、単なる土管屋ではありません。社会インフラとしての通信を支える以上、平常時の品質だけでなく、障害時にどう壊れ、どう戻すかまで設計する責任があります。

大規模インフラの設計では、止めないことだけでなく、壊れた時に安全に戻せることが重要です。この障害は、その難しさを強く示した事例だと思います。

関連する記事

• 通信キャリアは土管屋なのか – ネットワーク事業者に求められる技術責任
• ネットワークに詳しいとは何か – ルーティングテーブルを読めない危うさ
• Ubuntu 26.04 障害時の切り分け – OS / ネットワーク / サービスを層で見る
• 基本設計は机上だけで完結するのか – 検証環境と不確実性で考える
• クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える
• パブリッククラウドで NFV は成立するのか – 仮想アプライアンスを置く前に考えること