2026.10.01

ネットワーク復旧の進め方｜業務影響を抑える切り分けと復旧順序

経営リスクナビ編集部

ネットワーク復旧（社内LAN・無線LAN）が必要な局面では、「つながらない／不安定」という現象だけを追うと、復旧が長引いたり、原因が不明なまま再発したりしがちです。さらに、機器不調に見えてもC2サーバーへの通信確立などを狙った設定変更が混ざると、再起動や再設定が不利益（証跡欠落・侵害継続）になり得ます。業務停止を避けるには、影響範囲の切り分け、初動の安全確保、優先順位付け、外部支援への線引きを同じ軸で扱うことが重要です。以下では、ネットワーク障害の判断材料として切り分け観点と復旧の優先順位付けを示します。

ネットワーク復旧の全体像
物理環境と機器を確認する
設定と端末の問題を切り分ける
外部通信と障害範囲を見極める
情報共有と復旧後の維持
BCPと通信インフラを見直す
よくある質問
ネットワーク復旧への対応で次にすべきこと

ネットワーク復旧の全体像

接続障害の典型パターンを整理

ネットワーク接続障害の拡大を防ぐには、まず発生部位（どこで止まっているか）と影響範囲（どこまで影響が及ぶか）を短時間で切り分けることが重要です。典型パターンは、(1) 通信回線・プロバイダ側の障害、(2) ルーター／スイッチ／アクセスポイント等の機器障害、(3) 設定不備・認証エラー等の論理障害に整理できます。

加えて、障害が単なる機器不調に見えても、サイバー侵害によりネットワーク機器の設定が変更されているケースがあります。例えば攻撃者は、C2サーバー（攻撃者の指令先）への通信確立、別セグメントへの侵入、多要素認証の回避や認証情報不要のVPN接続確立といった目的で、ルーター／ファイアウォール／VPN機器の設定を変更することがあります。

影響範囲からの初期切り分け観点

全社的に不通の場合は回線障害・基幹機器障害・境界機器設定変更（ルーター／ファイアウォール等）を優先疑義として扱います。
特定フロアや特定エリアのみ不通の場合はフロアスイッチ・配線・AP配置や干渉など局所要因を優先します。
特定端末のみの不通の場合は端末設定・端末故障・端末のセキュリティ製品検知（EDR等）による遮断も疑います。

この切り分けができると、不必要な点検工程を避け、限られた復旧リソースを「止めどころ（原因の当たり）」に集中できます。特に、侵害の可能性があるときは、後工程（復旧作業）よりも先に「何が起きたかを残す」判断が復旧品質を左右します。

業務影響で復旧の優先順位を決める

復旧対応では、技術的に直せる順ではなく、重要業務（優先して復元すべき活動）への影響を基準に優先順位を決めます。重要業務は「事業そのもの」に限られず、状況によっては被災地支援や従業員支援など直接売上に結び付かない活動も含めて整理します。さらに、目標復旧時間は重要業務ごとに設定します。

参照情報上も、内部監査の事例として、部品メーカーで生産ライン単位の復旧優先順位付けができていないことが課題化し、取引先が重視する部品の優先順位を把握するために取引先ヒアリングを行った例があります。また、別の企業では「被災状況に合わせて判断する」としていたものの、誰がどの情報に基づいて優先順位を判断するのかが不明確である点が内部監査で指摘されています。

優先順位の決め方（実務手順）

重要業務を「活動」として洗い出し、停止したときの影響（売上・取引・安全・法令対応・顧客責任）を言語化します。
重要業務ごとに目標復旧時間を設定し、判断者（誰が決めるか）と根拠情報（何を見て決めるか）を明確化します。
現場都合で揺れやすい工程（例：工場・店舗・受発注窓口）は、平時に取引先ヒアリング等で外部期待値も確認しておきます。

この合意形成があると、障害時に「議論で止まる」時間を減らし、復旧の着手順をぶれさせずに進められます。

安全確保から始める初動フロー

障害発生直後の初動は、復旧の前に安全確保と被害拡大防止を優先します。特に、EDRやウイルス対策ソフトの検知、ファイル暗号化などの不正痕跡がある場合は、通常障害ではなくインシデント対応として動く必要があります。

初動で行う隔離と証跡保全

端末や機器に不正痕跡がある場合、まずLANケーブルの抜線やVLANによる論理隔離を検討します。
ネットワーク隔離ができない場合は電源断も選択肢ですが、電源を落とすとメモリー情報等が失われるため、調査が必要そうなら電源断の前に取得を検討します。
攻撃の疑いがあるときは、サーバのケーブルだけを抜くのではなく、ルーターやファイアウォール等の根本でインターネット接続を切り離す判断を優先します（侵入経路を残す形の部分遮断は避けます）。
以後の作業でログが上書きされ得るため、OS監査ログ、資産管理ソフトやEDRログ、ネットワーク機器ログ、クラウドサービスログはローテートで消える前に別途保全します。

初動フローを平時に定義し、現場の独断で再起動や設定変更をしない運用にすることで、二次被害（原因隠し・範囲拡大・証跡欠落）を抑制できます。

物理環境と機器を確認する

ケーブルと電源の異常を確認する

物理層の点検では、まず電源と配線を確認します。見た目は高度な障害でも、実際にはケーブル抜けや電源断、接触不良が原因のことが少なくありません。

物理層で最初に見る点検ポイント

電源タップやUPSの状態、過負荷による遮断、機器側電源ケーブルの抜けを確認します。
LANケーブルの爪折れ、曲げ・踏み付け、結線部の緩み、配線ダクト内の圧迫を確認します。
不正痕跡がある端末の応急処置として実施する抜線は、復旧目的の抜線と混同しないよう「誰が」「いつ」「どのポートを」抜いたか記録します。

物理確認を最初に行うことで、設定変更や再起動など“痕跡を変える操作”を最小化でき、結果的に調査と復旧の品質が上がります。

故障判断と保守切替の目安を知る

故障判定と保守切替は、社内の粘り過ぎによる停止長期化を防ぐため、あらかじめ線引きしておきます。警告灯の異常、手順に沿った再投入でも改善しない、ログに深刻な内部エラーがある場合は、社内一次対応に固執せず外部保守へ切り替えます。

一方で、単なる故障に見えてもサイバー侵害が疑われる場合、安易な再起動や初期化は避け、ログ保全と影響調査を優先します。ログは容量や期間で削除されるローテート運用が一般的なため、対応が遅れるほど「当時の状態」が失われます。

保守切替の判断に使う客観情報（例）

機器ログに内部エラーや例外停止の記録があり、同時に設定の不審変更も疑われる場合は、復旧だけでなく調査も前提に連絡します。
社内で実施した操作（再起動、抜線、USB挿入、ウイルススキャン等）も上書き要因になり得るため、外部連携時に実施履歴を共有します。

保守契約（オンサイト可否、交換機手配、受付時間等）の範囲と連絡先を、平時から関係者で共通化しておくことが復旧停滞を防ぎます。

保守期限切れ・EOL機器はいつ交換判断するか｜更新停止と予備機有無で線引きする

保守期限切れ・EOL（サポート終了）機器の交換判断は、費用の都合よりも更新停止による脆弱性放置と故障時の調達不能を基準に行います。特に、メーカーの修正提供が止まっている環境は、侵害を受けた際に「塞ぐ手段がない」状態になりやすいです。

参照情報でも、ネットワーク機器（ルーター／ファイアウォール／VPN等）は攻撃者に設定変更され得る前提が示されています。EOL機器は、侵害に悪用される脆弱性があってもファームウェア更新が難しく、結果として一時的な機能停止を含む厳しい運用判断を迫られます。

交換判断の実務上の線引き

セキュリティ修正（ファームウェア更新等）が提供されない、または安全に適用できない状態は撤去・更新の強い根拠になります。
同型機の調達が難しく、社内に即時交換できる予備機もない場合は「止まったら戻せない」ため計画更新へ寄せます。
VPN機器で不審アカウント追加や設定変更が見つかり、脆弱性悪用が疑われる場合は、アップデートできない間の一時停止も選択肢に入れます。

資産台帳として、老朽機器の台数・設置箇所・保守期限を把握し、法務・財務とも共有して更新判断を平準化します。

設定と端末の問題を切り分ける

ルーター設定と再起動を見直す

ルーターやファイアウォール等の再起動・再設定は、原因の隠蔽や侵害の継続を招かないよう、手順と判断基準を固定して行います。特に攻撃の疑いがある場面では「とりあえず再起動」は危険になり得ます。

参照情報では、攻撃者がネットワーク機器の設定を変更し、C2通信の確立や別セグメント侵入、多要素認証回避、認証情報不要のVPN接続を狙う可能性が示されています。そのため、復旧の前に設定が変更されていないかを確認し、不審な変更があればバックアップ等から元に戻し、戻せない・バックアップの安全性が担保できない場合は初期化を検討します。

ネットワーク機器の設定確認と再起動の進め方

ルーター／ファイアウォール／VPN機器について、想定外の設定変更や不審アカウント追加がないか確認します。
不審変更があれば、バックアップ等から復元します。
復元手段がない、またはバックアップの安全性が担保できない場合は初期化を検討します。
VPN機器で脆弱性悪用が疑われる場合はファームウェアのバージョンを確認し、必要に応じてアップデートし、すぐにできない場合は一時的な機能停止も検討します。

再起動は万能策ではなく、調査・保全の前提を壊す操作でもあります。実施する場合は、記録を残したうえで統制された手順に従います。

無線LAN設定とAP配置を最適化する

無線LANの不安定は、AP配置や干渉など物理要因に加え、暗号化方式やパスワード管理の弱さが原因で「つながるが危険」「つながらないが実は攻撃」の状態になっていることがあります。

参照情報では、Wi-Fiの通信暗号化としてWEPが使われている場合、解読が容易で盗聴リスクが高いため危険であり、少なくともWPA2以上へ変更することが推奨されています。また、社外まで電波が届くケースでは、弱いパスワードだと侵入リスクが高まり、車等でアクセスポイントを探すウォードライビング（WarDriving）といった行為も指摘されています。

無線LANの安定化とリスク低減の両立ポイント

チャンネル設計と出力調整で干渉を避け、APあたりの端末集中を運用・設定で分散します。
レイアウト変更（遮蔽物、金属家具、水回り等）に合わせて電波状況を計測し、AP配置を見直します。
Wi-Fi暗号化がWEP等になっていないか確認し、少なくともWPA2以上へ変更します。
工場出荷時パスワードの継続利用を避け、推測されにくい複雑なパスワードへ変更します。

「速度改善」だけでなく、盗聴・侵入リスクを同時に下げる設計にすることで、障害と事故の両面を抑えられます。

再起動前に誰が何を控えるべきか｜設定消失や証跡欠落を防ぐ記録項目

再起動や抜線の前に、何を残すべきかを決めておかないと、復旧後に原因不明となり再発防止が困難になります。インシデント対応では、発生時点に近いデータが必要ですが、ログはローテートで消えたり、電源が入っているだけでディスク未使用領域やメモリーが上書きされたりします。さらに、USBメモリー挿入、ウイルススキャン、抜線などの行為自体も上書き要因になります。

再起動・隔離前に保全する記録（最低限）

OS固有の監査ログ、資産管理ソフトやEDRのログ、ネットワーク機器ログ、各種クラウドサービスのログをローテート前に退避します。
機器の状態（ランプ、エラー表示、現在の設定の要点）と、障害の発生時刻・操作担当者・実施作業を時系列で残します。
調査の必要性が高い端末は優先度を付け、ディープフォレンジック調査ができるよう優先的に保全します。

証跡を確実に残すほど、復旧後の再発防止（設定統制、監視強化、攻撃経路遮断）が具体化し、説明責任にも耐えやすくなります。

外部通信と障害範囲を見極める

回線事業者とクラウド障害を確認

社内機器に明確な異常が見当たらない場合、外部の回線事業者・クラウド側の障害を並行して確認します。ただし、サイバー侵害時は「外部障害に見せかける」こともあり得るため、外部確認と同時に、境界機器（ルーター／ファイアウォール／VPN）の設定改ざんの有無も確認します。

外部要因確認の実務ポイント

事業者の障害情報と公式通知を確認し、問合せ時は発生時刻・症状・自社側の切り分け結果を整理して伝えます。
クラウド利用時は、利用者側の設定不備（公開権限ミス、共有設定の誤り、URLリンクが分かれば第三者が閲覧できる状態等）による情報漏えいリスクも前提に、適宜監査します。
問合せ履歴は担当者個人に閉じず、案件管理としてチームで共有し、対応記録として残します。

外部要因を早期に特定できると、社内の再設定を繰り返す無駄を止め、迂回策や代替運用への移行判断が早くなります。

社内対応と外部サポートの線引き

社内での一次対応は「切り分け」と「被害拡大防止」に寄せ、専門性が必要な領域は早めに外部支援へつなぎます。特に侵害が疑われるときは、復旧作業の速度だけでなく、証跡保全と調査品質が重要になります。

社内で行うこと／外部へ委ねることの目安

社内で行うのは、配線・電源の確認、影響範囲の特定、ログの退避、隔離（LAN抜線やVLAN隔離等）などの一次切り分けです。
外部へ委ねるのは、侵害可能性を含む高度な原因分析、ディープフォレンジック調査、回線事業者網内の判定、専門的なプロトコル解析です。
重要な連絡は電話が迅速な場合もあるため、業務時間外を含め留守番電話・転送機能等の受付体制を整え、担当者の電話番号変更も含めて連絡網を定期チェックします。

線引きを運用に落とすには、「いつ外部へ上げるか」の条件と、連絡先・受付方法・記録方法を平時から整備しておく必要があります。

SLA対象内か対象外かをどう見分けるか｜回線障害・宅内機器・設定変更の責任分界点

SLA（Service Level Agreement）の適用可否は、契約書・約款上の責任分界点に従って判断します。顧客に対する責任として、契約・約款上の履行義務、SLAに関する合意が論点になり得るため、障害時に「どこまでが事業者責任で、どこからが自社責任か」を即答できる状態が望ましいです。

区分	主な対象	SLAの扱いの考え方
回線事業者側	網内設備・引き込み回線の物理障害	契約上SLA対象になり得るため、障害申告と証跡提示を優先します。
自社側（宅内）	ビル内配線・自社管理ルーター等の設定ミス・自社購入機器故障	SLA対象外になり得るため、自社の復旧責任として切り分けと手配を進めます。
自社の変更起因	独自の設定変更に起因する事故	免責事項に該当し得るため、変更管理と記録の整備が重要です。

責任分界の整理（典型）

責任分界点を誤ると、復旧要請の宛先や主張がぶれて時間を失います。敷地内の接続境界装置を基準に、責任範囲を管理表にしておくと実務で迷いにくくなります。

情報共有と復旧後の維持

発生記録と社内連絡の残し方

障害対応では、復旧作業と同時に時系列の発生記録（タイムライン）と社内連絡を整備します。情報不足は現場への問い合わせ集中を招き、復旧の手が止まります。また、インシデント対応では対応記録そのものが後日の調査・説明の根拠になります。

記録として残す項目（時系列）

検知時刻、最初の症状、影響範囲、実施した操作（抜線、隔離、再起動、スキャン等）とその結果を時系列で残します。
ログは一定期間や一定容量でローテートして削除され得るため、消失前に別途保存したかを記録します。
重要連絡は電話が適する場合もあるため、留守番電話や転送機能を含む受付体制を整え、連絡内容は案件管理システム等に対応記録として残します。

社内連絡は「いま何が起きているか」「次回はいつ更新するか」を中心に、関係者の判断に必要な事実へ絞ると混乱が減ります。

再発防止へメンテナンスを定着させる

再発防止は、個別障害の反省だけでなく、モニタリング（予兆の監視）と変更管理を運用に落とし込むことが中心です。不測の事態のリスクは予測不能でも、CPU負荷やディスク容量、取引量の急増イベントのように、直接・間接のモニタリング項目を設計して強化できます。

参照情報では、重要な端末・関連度の高い端末について、詳細なログ分析を前提とした保全（ディープフォレンジック調査ができる状態）を優先する考え方が示されています。また、監査ログ取得と高権限アカウント利用の定期監視、ログオン可能なIPや機器の制限、二要素認証の導入といった統制が、復旧局面の要件として整理されています。

再発防止として定着させる運用項目

OS監査ログ、EDRや資産管理、ネットワーク機器、クラウドのログを取得し、ローテート消失前に保全できる運用を整えます。
高権限アカウントの利用状況を定期監視し、意図しない設定変更の兆候を検知します。
ログオン可能なIPアドレスや機器を制限し、二要素認証の導入を検討します。
クラウドは利用者側設定の不備（公開権限ミス等）が起き得る前提で、適宜監査します。

メンテナンスを「担当者の頑張り」にせず、年間計画と記録保管（監査に耐える形）に落とし込むことが継続的な障害低減につながります。

法務・総務・情シスで分担する初報対応｜障害公表・取引先連絡・報告要否の整理

初報対応は、技術復旧だけでなく、対外説明・契約・責任の論点が絡むため、情シス単独で抱えないことが重要です。参照情報でも、顧客に対する責任として、契約・約款上の履行義務やSLAに関する合意が挙げられています。

初報時の役割分担（実務）

情シスは、影響範囲の確定、隔離（LAN抜線やVLAN隔離等）、ログ保全、復旧作業の指揮を担います。
法務は、契約・約款上の義務、SLA、損害賠償リスク等の論点整理と、対外説明文のリーガルチェックを担います。
総務は、取引先・社内の問い合わせ窓口の一本化、電話連絡を含む連絡網の運用、広報発表の事務局を担います。

インシデント性が疑われる場合、復旧の急ぎ過ぎで証跡を失うと、後日の説明や原因究明が困難になります。部門横断で「何を優先するか（安全確認、証跡、復旧）」の合意を平時から持っておく必要があります。

BCPと通信インフラを見直す

冗長化と代替通信の構成を考える

冗長化は「回線が切れたら終わり」を避ける技術施策ですが、BCPの観点では、障害だけでなくインシデント時にネットワークを遮断する判断も織り込む必要があります。参照情報では、サイバー被害時は攻撃者の追加侵入を防ぐため、ルーターやファイアウォールから根本で切り離して完全遮断する重要性が指摘されています。

冗長化設計にBCP要件として入れる観点

回線・経路の冗長化だけでなく、侵害時に根本遮断できる境界設計（どこを落とせば遮断できるか）を明確にします。
完全遮断の判断時でも業務連絡が止まらないよう、電話（留守番電話・転送機能等）を含む代替連絡手段を整備します。
重要度に応じて、切替後の帯域を重要通信へ優先配分できる運用ルールを用意します。

「切替」だけでなく「遮断」も選択肢になる前提で設計・訓練しておくと、危機時に迷いが減ります。

セキュリティ事故後の復旧方針を定める

セキュリティ事故が疑われる障害では、早期復旧よりも安全性の確認を優先します。参照情報でも、EDR検知や暗号化被害がある端末は隔離し、まずLANケーブル抜線やVLANによる論理隔離を検討し、隔離できない場合は電源断を選択する流れが示されています。ただし電源断はメモリー情報等を失うため、調査が必要なら電源断の前に取得を検討します。

また、ネットワーク機器の設定変更が疑われる場合は、ルーター／ファイアウォール／VPN機器の設定確認を行い、不審な設定変更があればバックアップから戻し、戻せない・バックアップの安全性が担保できない場合は初期化を検討します。

事故後復旧の基本方針（段階的）

不正痕跡がある端末を隔離し、必要なログ・データを保全します（ローテート消失にも注意します）。
侵入経路を遮断するため、ネットワークの根本（ルーター／ファイアウォール等）で遮断する判断も含めて検討します。
ネットワーク機器の不審設定がないか確認し、戻せる場合は復元し、戻せない場合は初期化も含めて対処します。
VPN機器の脆弱性悪用が疑われる場合はファームウェアのバージョンを確認し、必要に応じてアップデートし、困難なら一時的な機能停止も検討します。

この方針を決めておくと、「復旧したが再侵害した」「証跡がなく原因不明」といった最悪の再発パターンを避けやすくなります。

拠点停止を前提に復旧時間目標をどう置くか｜本社・店舗・工場で異なるRTOの決め方

RTO（目標復旧時間）は拠点一律ではなく、重要業務ごとに定める考え方が基本です。参照情報でも、重要業務は「不測の事態のリスク」に直面した場合に優先して復元すべき活動であり、必ずしも事業だけでなく支援活動等も含み得るとされています。したがって、本社・店舗・工場という拠点区分に加え、拠点内の活動単位（例：生産ライン単位）まで落として決めると実効性が上がります。

また、内部監査事例が示すとおり、優先順位や判断者・判断根拠が曖昧だと、災害・障害時に現場判断がばらつきます。RTOを置く際は「誰が」「どの情報に基づいて」判断するのかもセットで定義します。

RTO設計で最低限押さえる論点

重要業務を活動として洗い出し、活動ごとに目標復旧時間を置きます。
工場等は生産ライン単位の優先順位まで掘り下げ、取引先ヒアリング等で外部期待値も確認します。
被災状況に合わせて判断する場合でも、判断者と判断根拠情報を明確にしておきます。

業務特性に合わせた設計にすることで、過不足のない投資と、障害時の迷いのない復旧判断につながります。

よくある質問

ネットワーク復旧を社内だけで対応できるケースは？

社内だけで対応できるのは、影響範囲が局所的で、配線・電源・設定の一次切り分けで原因が特定でき、かつ復旧操作が証跡や安全性を大きく損なわない範囲に限られます。

社内対応で完結しやすい例

LANケーブルの未挿入、ポート差し替え、電源断など物理要因が明確な場合です。
端末のIP設定やWi-Fi設定など、変更内容が管理できる範囲の設定ミスの場合です。
ログ収集や影響範囲特定など、外部委託に渡すための一次情報整理の場合です。

一方で、EDR検知や暗号化痕跡がある場合は、端末隔離（LAN抜線やVLAN隔離）と証跡保全を優先し、調査・復旧は外部専門家の関与も含めて判断するほうが安全です。

無線LANが断続的に切れる場合はどこから確認しますか？

断続的な切断は、干渉・負荷・配置に加えて、セキュリティ設定の不備が混在していることがあります。

断続切断の確認順（実務）

干渉状況とAPあたりの端末集中（負荷）を確認し、チャンネル・出力・配置の見直しを行います。
オフィスの遮蔽物やレイアウト変更の影響を確認し、必要に応じてAP位置を調整します。
暗号化方式を確認し、WEPのような古い暗号化であれば少なくともWPA2以上へ変更します。
工場出荷時のWi-Fiパスワード利用を避け、複雑なパスワードへ変更します（社外まで電波が届く環境では侵入リスクが上がります）。

「つながりやすさ」と「守りやすさ」を同時に満たす設定に寄せると、通信品質とリスク管理の両面で安定します。

経営層や他部門へ最低限共有すべき情報は何ですか？

最低限共有すべき情報は、(1) 影響範囲、(2) 現在の対応ステータス、(3) 復旧見込み（次回更新時刻を含む）の3点です。加えて、法務・総務が判断に必要な「契約・約款・SLAの論点があり得るか」を早期に共有すると、対外対応がぶれにくくなります。

最小限の報告テンプレ（要点）

影響範囲：どの拠点・業務・利用者が止まっているか、部分遮断やVLAN隔離の有無はどうかを共有します。
対応状況：社内切り分け中か、回線事業者照会中か、侵害可能性があるため証跡保全優先かを共有します。
見込み：次回報告時刻を明示し、重要連絡は電話等に切り替えるかも含めて周知します。

技術詳細を過度に説明するより、意思決定に必要な事実を確実に揃えることが、業務停止の二次被害を減らします。

ネットワーク復旧への対応で次にすべきこと

ネットワーク復旧は、まず影響範囲から障害パターンを切り分け、業務影響に基づいて優先順位と目標復旧時間を置くところから整理します。並行して、EDR検知や暗号化など不正痕跡がある場合は通常障害ではなくインシデント対応として、隔離と証跡保全を先行させることが実務上の分岐点になります。特にC2サーバーへの通信確立等を狙った設定変更の可能性があるため、ルーター／ファイアウォール／VPN機器は再起動の前に設定の不審変更有無を確認し、実施した操作は時系列で記録しておきます。社内で抱える範囲と外部支援へ委ねる範囲（高度な原因分析・フォレンジック等）を平時から線引きし、契約・約款・SLAの責任分界点は法務も交えて確認すると判断がぶれにくくなります。個別事情で最適解は変わるため、侵害可能性や対外説明が絡む局面では、情シスだけでなく外部専門家や法務と連携して進めるのが安全です。