通信障害へのAI対策——企業・自治体が今すぐ備えるべきこと

公開日：2026年11月5日文：クリスタルメソッド編集部監修：河合継（代表取締役）

2026年11月5日午前11時ごろ、NTTドコモの5G SA（スタンドアローン）サービスで全国的な通信障害が発生した。音声通話・データ通信・SMSが影響を受け、4GやMVNO契約者には影響がなかったとドコモは説明している。同社はサイバー攻撃によるものではないとしているが、原因は調査中だ（日本経済新聞、ケータイ Watch）。障害を受けたユーザーに対しては、端末のネットワーク設定を4Gへ切り替えるよう案内が出ている。同日にはd払いの別障害も重なり、障害が連鎖する局面となった。通信障害の影響を受けたユーザーの不便に配慮しつつ、ここでは同様の事態に備える組織側の実務を整理する。

担当者が通信障害の第一報を受けたとき、最初の壁は「何が、どこまで止まっているのか」という把握の困難さだ。この記事では、今回の障害が示した課題を起点に、AIを使って通信障害の影響を事前に可視化し、代替手段を自動的に切り替え、障害情報を素早く収集・整理する仕組みを、企業・自治体の現場担当者の視点から整理する。

通信障害が企業・自治体にもたらす構造的な課題

今回の障害が示したのは、「特定のサービス契約者だけが影響を受ける」という部分障害の見えにくさだ。5G SA契約者のみが影響を受け、同じ組織内でも5G SA以外の端末は問題なく動いていた。現場では誰の端末が使えて誰の端末が使えないのかが即座には判別できず、混乱が生じやすい。

自治体や企業が抱える共通の課題は、次の3点に集約できる。

影響範囲の可視化が遅れる：契約回線の種別・台数・拠点ごとの分布を即座に参照できる体制が整っていない組織では、「今この瞬間、何が使えないのか」を把握するだけで時間を要する。
代替連絡手段への切り替えが場当たり的になる：BCP（業務継続計画）に代替手段が記載されていても、実際の手順が自動化されておらず、担当者の記憶と判断に依存しているケースが多い。
障害情報の収集・整理に人手がかかる：キャリアの公式情報、社内からの問い合わせ、SNSの状況報告が並行して流れ込む中で、正確な状況把握が追いつかない。

図：通信障害発生時の3つの主要課題と、それぞれに対応するAI活用の関係。3つの対応が連動することで業務継続（BCP）の迅速化につながる。

AI対策①——通信障害の影響範囲を事前に可視化する

障害発生直後に「何が止まっているか」を素早く把握するには、平時からの準備が要る。組織内の端末・回線・サービスの契約情報を台帳化し、AIがその情報をもとに障害条件（例：5G SA契約者）と突き合わせて影響端末・拠点を即時リスト化できる状態を整えることが第一歩だ。

IT資産管理ツールとの連携：社内のMDM（モバイルデバイス管理）やIT資産管理システムが持つ端末属性データをAIで解析し、障害発生時に「影響を受ける可能性のある端末・ユーザー一覧」を自動生成する。手動で台帳を引き出す手順が不要になり、初動対応にかかる時間を縮められる。
ネットワーク監視AIの活用：拠点ごとの通信ログをリアルタイムで監視するAIシステムは、通常時の通信パターンと乖離が生じた時点でアラートを発する。外部の障害情報が出る前に「自組織としての異常」を検知できる点が利点だ。
サービス依存関係マップの整備：クラウドサービス・VoIP・決済システムなど、通信回線に依存するサービスの関係をグラフ構造で管理し、障害発生時にどのサービスが連鎖停止するかをAIが推論する手法も普及が進んでいる。今回のd払い障害との連鎖はその典型例といえる。

ただし、これらの仕組みが機能するのは台帳・ログのデータ品質が担保されている場合に限る。端末管理が属人的で台帳が古い組織では、AIを活用する前段階での整備が必要になる。

次に読む：Claude障害に備えるBCPはどう設計する？

Claude 障害対策 BCPを設計する：大規模停止に備える企業のAIマルチプラットフォーム戦略

AI対策②——代替連絡手段の自動切り替えを企業・自治体向けに設計する

BCPの弱点の一つは、「計画は存在するが発動が遅い」点にある。担当者が手順書を探し出し、連絡先を確認し、判断を仰ぐまでの間に業務上の損失が積み重なる。ここにAIを介在させることで、発動の速度と確実性を高めることができる。

条件ベースの自動通知フロー：「特定キャリアの公式障害情報が検知された場合」「監視AIが閾値以上の通信異常を検知した場合」をトリガーとして、あらかじめ設定した代替連絡手段（固定電話・別キャリアのSIM・衛星通信・メール・チャットツール）への切り替えを自動で指示するフローを設計する。LLMを用いれば、障害の種類や影響範囲に応じて通知文面を動的に生成することも可能だ。
優先度付きエスカレーション：AIが組織内の役割・拠点・業務上の緊急度をもとに連絡先を優先順位付けし、重要な連絡が漏れなく届くよう管理する。全員に一斉送信するより、業務影響の大きい担当者から順に確認が取れる構造のほうが実務上の混乱は小さい。
自治体における住民向け情報発信の自動化：自治体では障害発生時の住民向け広報に遅れが生じやすい。AIを使った多チャネル一括配信（SNS・防災アプリ・ウェブサイト）の自動化は、担当者が少ない夜間・休日の対応力を補う手段として検討に値する。なお今回の障害でも緊急通報（110・119）は影響を受けなかった（ケータイ Watch）。

自動化の範囲を広げるほど、誤検知による不必要な発動リスクも高まる。最終的な発動判断に人間が介在するポイントをどこに置くかは、事前に明確に設計しておく必要がある。

AI対策③——障害情報の収集・整理をAIで効率化する

通信障害が発生すると、キャリアの公式発表、SNS上の報告、社内問い合わせが同時多発的に流れ込む。これを人手で整理しながら対応を進めるのは、特に規模の大きい組織では現実的ではない。自然言語処理（NLP）を使ったAIシステムは、この情報洪水の整理に有効だ。

公式情報の自動サマリー：キャリアの障害情報ページや公式SNSアカウントをポーリング（定期取得）し、更新があった際にLLMが要約・構造化して担当者へ配信する。今回のドコモ障害のように第四報まで順次発表が更新されるケースでは、前報との差分を自動で抽出できると担当者の読み込み負荷が下がる（NTTドコモ公式）。
社内問い合わせのトリアージ：「電話が使えない」「メールが届かない」という問い合わせをAIチャットボットが受け付け、影響範囲の条件（契約種別・端末・拠点）と照合しながら「障害による影響」「端末個別の問題」「手順書案内で解決可能」に分類する。ヘルプデスクへの集中を緩和し、本当に人が対応すべき問い合わせに集中できる。
テキストマイニングによる傾向分析：過去の障害対応記録や問い合わせログをテキストマイニングで分析し、障害時に頻出する業務上のボトルネックや見落としやすい手順を事前に洗い出しておく。平時のBCP改善に活用できる。

組織種別ごとに見る通信障害AI対策の優先領域

上記の対応が実際に機能する場面を、組織の種別ごとに整理する。

組織種別ごとの通信障害AI対策の優先領域
組織種別	最も影響が大きい業務	AIで優先すべき対応	特記事項
製造業・物流	拠点間の進捗連絡・配送指示	影響端末の即時リスト化・代替通信への自動切替	IoT機器も影響を受ける場合がある
小売・EC	決済・在庫確認・顧客対応	サービス依存関係マップ・障害情報の自動サマリー	d払い等の決済障害との連鎖に注意
自治体・公共機関	住民向け広報・職員間連絡	多チャネル一括配信の自動化・エスカレーション設計	緊急通報（110・119）は今回も影響なし
医療機関	院内連絡・遠隔診療	通信手段の冗長化監視・障害時のアラート	患者安全に直結するため人間の最終判断が必須
金融・保険	顧客対応・内部承認フロー	問い合わせトリアージ・代替手段の自動通知	金融庁への報告義務が発生する場合がある

AI対策の限界と注意すべきリスク

AIを活用した通信障害対策には、明確な限界がある。現場担当者は次の点を念頭に置いたうえで導入を設計すべきだ。

最終判断は必ず人間が行う。AIが「代替手段に切り替えよ」と判断しても、その判断が誤っている場合（誤検知）がある。障害でないのに緊急通知が全社に飛べば、業務混乱は障害そのものより大きくなりうる。自動化の範囲と人間が介在するポイントを明文化しておくことが不可欠だ。

AIは通信回線そのものを修復しない。障害の根本原因の解決はキャリア側の作業であり、AIにできるのはあくまで「障害の影響下で業務をどう継続するか」の支援に限られる。

個人情報・プライバシーのリスク。端末管理・通信ログの分析には従業員や住民の行動データが含まれる。収集・分析の目的と範囲を明確にし、個人情報保護法の要件を満たした設計が必要だ。自治体が住民の通信状況を収集・分析する場合は特に慎重な運用が求められる。

AIシステム自体が通信に依存する。クラウドベースのAIシステムは、通信障害が発生するとそのシステム自体も使えなくなる可能性がある。エッジ処理（端末・拠点内での処理）とクラウド処理の組み合わせ、あるいはオンプレミスでの一部機能の確保を検討する必要がある。

導入・運用コスト。IT資産台帳の整備、MDMの導入、ネットワーク監視AIの設定には相応のコストと工数がかかる。費用対効果の試算なしに進めると、導入後に運用が形骸化するリスクがある。

明日から着手できる実務的な一歩

大掛かりなシステム導入を待たずに着手できることがある。まず手をつけるべきは、組織内の端末・回線の契約種別台帳を最新化することだ。今回のような部分障害では「誰の端末が5G SA契約か」という基本情報がなければ、AIを使う以前に影響範囲の把握が困難になる。

次に、主要キャリアの障害情報ページをRSSやAPIで取得し、SlackやTeams等の社内チャットへ自動転送する仕組みを設定する。これだけでも担当者が手動で確認する手間を省き、初動を早められる。ドコモの障害情報はNTTドコモの公式ページ（https://www.docomo.ne.jp/info/network/）で随時更新されている。

その上で、BCPの手順書に「各通信手段が使えない場合の代替フロー」を追記し、LLMを使って自動通知文を生成するプロトタイプを試作する。まず1つの拠点・1つのシナリオで動作を確認してから範囲を広げる段階的なアプローチが、現場定着の確率を高める。