2022年7月2日未明にKDDIが起こした大規模通信障害は、交通や物流、金融、気象などにも使われる重要回線が60時間超にわたってつながりにくくなるという大きな影響をもたらした。同様の社会的インパクトをもたらしたトラブルとして、12カ月に10回以上のシステム障害を起こしたみずほ銀行の例が記憶に新しい。KDDIとみずほ銀行のトラブルに共通点はあるのか。KDDIが再発防止策を準備する中、みずほ銀行の事例から学べる教訓は何か。みずほ銀行とKDDIの障害を追ってきた日経クロステックの記者が集まり、緊急座談会を開催した。（司会は堀越 功=日経クロステック）
KDDIの通信障害は、過去10年間に日本で起きた通信障害の中でも、最大規模の社会的インパクトをもたらしました。
日経クロステック金子寛人：今のスマートフォンやIoT（インターネット・オブ・シングズ）は、これまでの携帯電話と比べて影響範囲が全く異なる点が背景にあります。KDDIの回線は、つながるクルマやATM、貨物列車の運行などにも使われていました。そのため単に通信回線が止まり、電話ができないだけでなく、社会インフラが止まるというインパクトをもたらしました。
KDDIの通信障害は、なぜこれだけ大規模かつ長期化したのでしょうか。
金子：現在分かっている原因は複合的です。最初の発端はルーターのメンテナンスに伴って新しい機材を入れたところ、音声通信が途絶えるという不具合が起きました。古い機材にルーターを切り戻したことで、音声通信の障害はいったん、15分で回復しました。しかしスマホから一斉に大量の呼び出しがかかったことで、アクセスが集中する「輻輳（ふくそう）」が発生しました。
音声通話用のVoLTE（Voice over LTE）交換機と加入者データベース（DB）の輻輳が、加入者DBとVoLTE交換機の間のデータ不一致を誘発するなど、さまざまな事象が複合的に発生し、障害が大規模かつ長期化しました。
総務省はKDDIに対して、詳しい原因の報告と再発防止策について障害発生から30日以内に報告を求めています。KDDIは2022年7月28日にも報告書を提出する方針で、もう少し詳細な原因が出てくることを期待しています。
同じように大きな社会的インパクトをもたらした例として、みずほ銀行が2021年から2022年に連続して起こしたシステム障害があります。みずほ銀行の一連のシステム障害は、何が原因だったのでしょうか。
日経クロステック中田敦：みずほ銀行は12カ月の間に11回も障害を起こしています。それぞれの障害はさまざまな原因があり、共通項を見いだすのは難しいです。それでもあえて共通項をあげるとすると、システム運用体制が非常に弱かった点があります。
みずほ銀行は金融庁から業務改善命令を受けて、2022年1月に再発防止策を出しました。この1年程度は、再発防止策が機能しシステム障害が頻発しなくなったのか見定める経過観察期間のような位置づけです。そのため、みずほ銀行の取り組みが、KDDIの再発防止策の参考になるかどうかは、まだ微妙な段階です。
こうした前提でKDDIとみずほ銀行の障害を比較すると、KDDIについてもやはり、運用体制が十分だったのかを検証していく必要があると思います。
みずほ銀行の一連の障害では、運用担当部門が警告を見逃したり、エラーを分析する体制が不十分だったりした点が問題として指摘されています。
中田：みずほ銀行のシステム監視体制が弱かった点は間違いありません。
システム障害は必ず起き、ゼロにすることは不可能です。日本の金融機関だけでも、1年間で約1500回のシステム障害が発生しています。みずほ銀行のトラブルがこれだけ批判にさらされているのは、システム障害の原因を突き止める作業が遅れ、システムを早く回復させられなかったからです。
例えばみずほ銀行が2021年2月28日に起こしたシステム障害は7～8時間影響が続き、約5000人の利用者がATMに通帳やカードが取り込まれたままになり、立ち往生しました。みずほ銀行は障害の原因をつかむことが遅れ、正しい情報発信もできず、顧客に大きな被害をもたらしました。
顧客に大きな迷惑を与えなければ、システム障害が起きたとしても大きな問題にはなりません。みずほ銀行の場合、この点がうまく行っておらず、これだけ社会問題化しました。
みずほ銀行の障害では、組織間の情報共有も不十分だったと聞きます。
日経クロステック山端宏実：みずほ銀行のシステム運用は、みずほフィナンシャルグループ（FG）の子会社であるみずほリサーチ＆テクノロジーズ（MHRT、旧みずほ情報総研）と、日本IBMとみずほFGの共同出資会社であるMIデジタルサービス（MIDS）が担当しています。2021年2月28日にみずほ銀行が起こしたシステム障害では、MHRTとMIDSの役割分担が不明確だったことが初動の遅れの原因になりました。
通常、エラー監視はMIDSが手掛けます。一方で2月28日のシステム障害の発端となった「みずほe-口座」への切り替え作業は、MHRTがエラー発生状況などを監視していました。ところがMHRT側では担当者が事務所に24時間365日常駐する体制ではなく、さらにMIDSの対応も不要としていました。結果的にエラー監視の仕組みが十分に整っていませんでした。
2月28日のシステム障害では、障害の影響範囲についても的確な判断ができていませんでした。障害の影響度を見誤り、当時のみずほ銀行の頭取はネットニュースでシステム障害を知ったと言います。現場から経営トップまで初動の段階からつまずき、部門連携でも目詰まりを起こしていた点が大きなトラブルにつながりました。
中田：みずほ銀行はATMの監視を外部の会社に委託して、何かトラブルが発生したらメールや電話でみずほ銀行側に連絡することになっていました。そのため、みずほ銀行の情報システム部門や情報システム子会社は、2月28日のシステム障害で一番のトラブルになったATMが顧客の通帳やカードを取り込むという事象について、迅速に把握できていませんでした。
情報システム部門は当初、定期預金システムのトラブルだと判断しており、ATMが顧客の通帳やカードを取り込んでいるという被害を認識するまでに3時間ほど要しました。
