障害の原因を短時間で切り分ける

通信障害への初動は、自社だけの不具合か、広域障害かを10分以内に切り分けることが基本です。監視画面、通信事業者の障害情報、別キャリアのスマートフォン、社外クラウドの稼働状況を並行して確認し、憶測による復旧作業を避けます。

原因は基地局・固定回線の故障だけではありません。アクセス集中による輻輳、ルーター設定の誤り、認証基盤の停止、自然災害、DDoS攻撃も候補です。2018年のソフトバンク通信障害では、ネットワーク機器のデジタル証明書の期限切れが原因となり、約3,060万回線に影響が発生しています。

• 障害情報の確認先を担当者ごとに固定する
• 社内LAN、固定回線、クラウドサービスを分けて確認する
• 復旧見込みが不明な段階では代替経路へ早期に移行する

連絡網と復旧手順を事前に決める

実効性のある通信障害対策では、技術担当だけでなく現場責任者、顧客対応、経営判断者の連絡ルールを明文化します。誰が障害宣言を出し、誰が代替回線へ切り替え、誰が顧客へ案内するかを一枚の手順書にまとめることが重要です。

大規模障害は短時間で終わるとは限りません。2022年にはKDDIで約61時間、NTTドコモで約29時間にわたる大規模通信障害が発生し、数千万回線に影響が及びました。24時間365日の連絡先、手動作業へ移す優先業務、復旧後の記録方法まで訓練で検証しましょう。

• 障害宣言・一次報・復旧報のテンプレートを準備する
• 緊急連絡先は社内システム外にも保管する
• 四半期ごとに切替訓練と振り返りを実施する

異なる通信経路を組み合わせる

回線冗長化の答えは、同一障害で同時に止まりにくい経路を二重化することです。主回線を固定回線、待機回線を別キャリアのモバイル回線にし、ルーターで自動フェイルオーバーを設定すると、手作業を減らしながら業務接続を維持できます。

デュアルSIMやマルチプロファイルSIMは、営業端末や小規模拠点の有効な選択肢です。ただし同じ通信設備に依存する組み合わせでは効果が下がります。固定回線、モバイルWi-Fi、衛星通信を、拠点の重要度と災害リスクに応じて使い分けてください。

用途別に必要な経路を比較すると、投資すべきバックアップが明確になります。重要業務ほど自動切替と通信事業者の分散を優先し、フリーWi-Fiは機密情報を扱わない緊急連絡用途に限定することが安全です。

• 主回線と待機回線は可能な限り別キャリアにする
• DNS、認証、クラウド接続も切替後に動くか確認する
• 非常用回線のデータ容量と利用責任者を決める

機器と拠点の弱点を可視化する

回線を二重化しても、1台のルーター、1系統の電源、1か所の配線室に依存すれば停止します。無停電電源装置、予備ルーター、設定バックアップを組み合わせ、拠点ごとに単一障害点を洗い出すことが、実務的な通信障害対策になります。

産業機器やIoTゲートウェイでは、通信仕様と保守性の確認も欠かせません。たとえばYocto Based Linux（Kernel 4.9.88）を採用する機器では、USB2.0 Type A x1やBluetooth4.2（BLE）の利用可否が、現地保守やバックアップ接続の設計に影響します。

• 電源、回線、ルーター、認証基盤を別々に点検する
• 設定ファイルは暗号化して社外でも復元可能にする
• 予備機は本番と同じ構成で定期起動する

VPN代替はアプリ単位で選ぶ

VPN代替として有力なのは、利用者・端末・アプリケーションごとに検証するZTNAやSASEです。社内ネットワーク全体へ接続させるのではなく、必要な業務アプリだけを公開することで、侵入後の横展開リスクと通信混雑の両方を抑えられます。

SASE（Secure Access Service Edge）は、2019年に提唱されたセキュリティモデルです。SDN + SWG + CASB + FWaaS + ZTNA = SASEという構成を理解し、全社一括移行ではなく、利用頻度の高いクラウド業務から段階導入すると運用負荷を抑えられます。

• ID、端末状態、利用アプリ、接続場所で許可を判断する
• 管理者権限の接続は通常業務用アカウントから分離する
• 公開するアプリと通信先を最小限に絞る

認証と監査でリモートアクセスを守る

安全なリモートアクセスでは、MFA、端末のパッチ状態確認、最小権限、操作ログを一体で運用します。VPN、RDP、VDI、セキュアブラウザのどれを選んでも、認証情報だけで接続を許可せず、接続時間とアクセス範囲を制限することが重要です。

統制基準はNIST Special Publication 800-53 Revision 5.2.0:、CSF v1.1 References:、Critical Security Controls Version 8.1、Cloud Controls Matrix v3.0.1、Critical Security Controls Version 7.1を参照して整理できます。侵害時に$600,000規模の損失へ広がる前に、セッション監視と即時遮断を訓練してください。

通信断の際は、利用者が未管理の共有端末や私用ツールへ流れることもあります。代替接続の手順と同時に、許可端末、禁止するファイル転送、緊急時の承認者を明確化し、利便性を理由に統制を外さない設計が必要です。

• MFAを全利用者と特権アカウントに適用する
• 端末が要件を満たさない場合は閲覧専用にする
• 操作ログを定期確認し、異常時は接続を無効化する

クラウドPBXで通話経路を分散する

通話継続には、代表番号を特定のオフィス回線や電話機だけに固定しないことが重要です。クラウドPBXなら、インターネット経由でスマートフォンやPCへ着信を振り分けられるため、拠点閉鎖や固定電話障害でも顧客窓口を維持しやすくなります。

クラウド電話を導入する際は、音声品質だけでなく、着信グループ、時間外アナウンス、転送先、通話録音、権限管理を確認します。データ回線の障害時には別キャリアのモバイル通信へ切り替える手順も用意し、番号が生きていても応答できない状態を防ぎます。

• 代表番号の着信先を複数人・複数拠点に設定する
• 緊急時用の転送先と案内文を事前登録する
• 通話録音の保存先と閲覧権限を分離する

人の連携まで含めて復旧力を高める

技術的な冗長化だけでは、顧客対応やチーム連携は完結しません。障害時は、誰が電話を受け、誰がチャットで状況を共有し、誰が顧客へ次回連絡時刻を伝えるかを決めることで、問い合わせの集中と二重対応を抑えられます。

多拠点チームでは、SWiseのようにアバターの近接で会話を始められるバーチャルオフィスを併用すると、緊急時の所在確認や短い相談を進めやすくなります。リアルタイム字幕翻訳と議事録生成は、海外メンバーを含む復旧連携にも役立ちます。

通信が不安定な環境で会議の理解度を保つには、Web会議翻訳の仕組みと導入時の注意点も確認してください。音声・字幕・議事録の代替経路を含めて準備することが、顧客対応と復旧判断の質を支えます。

• 障害時の役割を窓口、技術、判断、記録に分ける
• 顧客向けの一次回答は事実と次回連絡時刻に絞る
• 復旧後は通話・連絡・切替の記録を必ず見直す