ネットワーク障害対応 実践ガイド
障害発生時の基本フロー、レイヤー別切り分け手法、必須コマンド集、よくある障害パターン10選、障害報告書の書き方まで、実践的なネットワークトラブルシューティングを解説します。
1. 障害対応の基本フロー
ネットワーク障害が発生した時、慌てずに対応するためには、事前に定められたフローに沿って行動することが重要です。ひとり情シスの場合、相談できる同僚がいないことも多いため、体系的なアプローチが不可欠です。
障害対応の5ステップ
| ステップ | 内容 | 所要時間目安 | ポイント |
|---|---|---|---|
| 1. 検知・受付 | 障害の発生を認識し、第一報を記録 | 5分以内 | 「いつ」「誰が」「何が」を正確に記録 |
| 2. 影響範囲の特定 | 障害が及ぶ範囲を迅速に把握 | 10～15分 | 全社か、特定フロアか、特定端末か |
| 3. 原因の切り分け | レイヤー別に原因を特定 | 15～60分 | 物理層から順に確認 |
| 4. 復旧対応 | 原因に応じた復旧作業を実施 | 状況による | 暫定対応→恒久対応の順 |
| 5. 記録・再発防止 | 障害報告書の作成、再発防止策の実施 | 1～3時間 | 必ず振り返りを行う |
ポイント：障害対応で最も重要なのは「記録を取ること」です。障害発生時刻、実施した作業、確認した結果をリアルタイムで記録してください。テキストエディタやメモ帳でもよいので、時系列で記録を残す習慣をつけましょう。この記録は障害報告書の作成にも、今後の類似障害対応にも役立ちます。
エスカレーション判断
ひとり情シスでも、すべてを自分で解決する必要はありません。以下の場合はベンダーやISPへのエスカレーションを検討しましょう。
- 30分以内に原因が特定できない場合：自力解決にこだわりすぎるとダウンタイムが長引く
- 機器のハードウェア障害が疑われる場合：保守契約に基づいて交換を依頼
- ISP側の障害が疑われる場合：ISPのステータスページを確認し、障害報告をあげる
- セキュリティインシデントの可能性がある場合：専門家に相談し、証拠保全を優先
⚠️ 注意
セキュリティインシデント（不正アクセスやマルウェア感染）の場合は、むやみに機器を操作してはいけません。ログの保全を最優先にし、攻撃が進行中であればネットワークの隔離を行った上で、セキュリティ専門家に相談してください。証拠を消してしまうと、原因究明が困難になります。
2. レイヤー別切り分け手法
ネットワーク障害の切り分けは、OSI参照モデルの下位層（物理層）から上位層（アプリケーション層）へと順に確認していくのが鉄則です。上位層から調べると、原因特定に時間がかかることが多いです。
物理層（レイヤー1）の確認
まず最初に確認すべきは物理的な接続です。意外に思われるかもしれませんが、ネットワーク障害の原因の30～40%は物理層に起因します。
- LANケーブルの確認：抜けていないか、断線していないか、ケーブルテスターで確認
- リンクランプの確認：スイッチやNICのLED（リンクランプ）が点灯/点滅しているか
- ポートの確認：スイッチの該当ポートが無効（shutdown）になっていないか
- 電源の確認：機器の電源が入っているか、UPSがバッテリ運転になっていないか
- 環境の確認：サーバー室の温度は正常か、ホコリによる過熱はないか
📋 具体例
「2階の全PCがネットにつながらない」という報告があった場合：まず2階のフロアスイッチのリンクランプを確認します。スイッチ上流側（アップリンク）のランプが消灯していれば、スイッチ間のケーブルが抜けているか、上流スイッチのポートに問題があると判断できます。ケーブルを差し直すだけで復旧するケースは非常に多いです。
データリンク層（レイヤー2）の確認
- MACアドレステーブル：スイッチのMACアドレステーブルに端末が登録されているか確認
- VLAN設定：対象ポートが正しいVLANに所属しているか
- STP（スパニングツリー）：ループが発生していないか、ポートがBlocking状態になっていないか
- PoE供給：PoE機器（AP、IP電話）の場合、給電が正常か
⚠️ 注意
ネットワークループは非常に危険です。誰かがLANケーブルを同じスイッチの2つのポートに接続しただけで、ブロードキャストストームが発生し、ネットワーク全体がダウンする可能性があります。STP（スパニングツリー）の有効化と、ループ検知機能の活用を強くお勧めします。
ネットワーク層（レイヤー3）の確認
- IPアドレス：正しいIPアドレスが割り当てられているか（ipconfig / ifconfig）
- デフォルトゲートウェイ：ゲートウェイのIPアドレスは正しいか、ゲートウェイにpingが通るか
- DNS：DNSサーバーのアドレスは正しいか、名前解決ができるか（nslookup）
- ルーティング：ルーティングテーブルに正しい経路が設定されているか
- DHCP：DHCPサーバーからIPアドレスが取得できているか、APIPAアドレス（169.254.x.x）になっていないか
アプリケーション層（レイヤー7）の確認
- 特定のサービスのみ障害：特定のWebサイトやクラウドサービスのみ接続できない場合は、そのサービス側の障害を確認
- ポート制限：ファイアウォールで必要なポートがブロックされていないか
- SSL/TLS：証明書のエラーが出ていないか、時刻同期は正常か
- プロキシ設定：プロキシサーバーの設定は正しいか
ポイント：障害切り分けでは「変わったことはないか」を必ず確認しましょう。ネットワーク機器の設定変更、新しい機器の追加、オフィスのレイアウト変更、ISPのメンテナンスなど、直近の変更が原因であることが非常に多いです。変更管理記録を普段から残しておくことが、障害時の迅速な原因特定につながります。
3. 必須コマンド集
ネットワーク障害対応で使用する基本コマンドを、Windows/Linux/macOSの対応とともに紹介します。これらのコマンドは日常的に使えるようにしておきましょう。
ping - 疎通確認
最も基本的なコマンドです。指定したホストとの通信が可能か確認します。
| OS | コマンド例 | オプション |
|---|---|---|
| Windows | ping 10.1.10.1 | -t（継続ping）、-n 10（10回）、-l 1400（サイズ指定） |
| Linux/macOS | ping 10.1.10.1 | -c 10（10回）、-s 1400（サイズ指定）、-i 0.5（間隔） |
ping確認の順序（障害切り分け手順）：
- 自分自身（127.0.0.1） → NGならTCP/IPスタックの問題
- デフォルトゲートウェイ → NGならローカルネットワークの問題
- 社内DNSサーバー → NGならVLAN間ルーティングの問題
- 外部IPアドレス（8.8.8.8） → NGならインターネット接続の問題
- 外部ドメイン（google.com） → NGならDNS解決の問題
tracert / traceroute - 経路確認
通信パケットが目的地に到達するまでの経路を表示します。どこで通信が止まっているかを特定できます。
| OS | コマンド例 | 備考 |
|---|---|---|
| Windows | tracert 8.8.8.8 | ICMPを使用 |
| Linux/macOS | traceroute 8.8.8.8 | UDPを使用（-I オプションでICMP） |
nslookup / dig - DNS確認
DNS名前解決の確認を行います。Webサイトにアクセスできない場合の原因切り分けに必須です。
| OS | コマンド例 | 用途 |
|---|---|---|
| Windows | nslookup google.com | デフォルトDNSサーバーで名前解決 |
| Windows | nslookup google.com 8.8.8.8 | 指定DNSサーバーで名前解決 |
| Linux/macOS | dig google.com | 詳細なDNS情報の取得 |
| Linux/macOS | dig @8.8.8.8 google.com | 指定DNSサーバーで確認 |
📋 具体例
「社内のWebシステムにアクセスできない」と報告があった場合、まずnslookupで名前解決を確認します。「nslookup intra.example.local」でIPアドレスが返ってくればDNSは正常。「Server failed」や「Non-existent domain」と表示される場合はDNSの問題です。社内DNSサーバーが停止していないか、DNSレコードが正しく登録されているかを確認しましょう。
arp - ARPテーブル確認
IPアドレスとMACアドレスの対応を確認します。同一セグメント内の通信障害の切り分けに有用です。
| コマンド | 説明 |
|---|---|
| arp -a | ARPテーブル全体を表示 |
| arp -d * | ARPキャッシュをクリア（管理者権限必要） |
netstat - ネットワーク接続確認
現在のネットワーク接続状況やリスニングポートを確認します。
| コマンド | 説明 |
|---|---|
| netstat -an | すべての接続とリスニングポートを数値で表示 |
| netstat -b | 接続に関連するプログラムを表示（Windows、管理者権限必要） |
| netstat -s | プロトコル別の統計情報 |
| ss -tlnp | Linux版。netstatより高速 |
ipconfig / ifconfig / ip - IP設定確認
| OS | コマンド | 説明 |
|---|---|---|
| Windows | ipconfig /all | 全NICの詳細情報表示 |
| Windows | ipconfig /release && ipconfig /renew | DHCP再取得 |
| Windows | ipconfig /flushdns | DNSキャッシュクリア |
| Linux | ip addr show | IPアドレス表示 |
| Linux | ip route show | ルーティングテーブル表示 |
ポイント：これらのコマンドは障害時だけでなく、日常的に使って慣れておくことが重要です。「正常時の出力」を知っておくことで、異常時に何が違うのかをすぐに判断できます。定期的にコマンドを実行し、正常時の出力をドキュメントに残しておくことをお勧めします。
4. よくある障害パターンと対処法10選
中小企業のネットワークで頻繁に発生する障害パターンと、その対処法を紹介します。
パターン1：特定のPCだけネットに接続できない
原因：LANケーブルの接触不良、NICの故障、IPアドレスの競合、ウイルス対策ソフトの誤作動
対処法：ケーブル差し替え → ipconfig確認 → 別ポートで接続 → NICドライバ再インストール
パターン2：全社的にインターネットが遅い
原因：回線の帯域飽和、ルーターのCPU過負荷、DNS応答遅延、Windows Updateの大量配信
対処法：ルーターのトラフィック状況確認 → ISP回線のスピードテスト → DNS応答速度確認 → WSUS導入検討
パターン3：無線LANが頻繁に切断される
原因：電波干渉、APの過負荷、ファームウェアの不具合、電子レンジなどの干渉源
対処法：チャネル変更 → 5GHz帯への誘導 → AP分散配置 → ファームウェア更新
パターン4：DHCPでIPアドレスが取得できない
原因：DHCPサーバーの停止、IPアドレスプールの枯渇、不正DHCPサーバーの存在
対処法：DHCPサーバーの稼働確認 → リース状況確認 → DHCPスヌーピング設定確認
⚠️ 注意
「不正DHCPサーバー」は要注意です。社員が個人のWi-Fiルーターをオフィスに持ち込み、DHCPサーバー機能が有効なまま接続すると、社内PCに不正なIPアドレスが配布され、ネットワーク障害が発生します。L2スイッチのDHCPスヌーピング機能を有効にし、正規のDHCPサーバー以外からの配布をブロックしましょう。
パターン5：特定のWebサイト/サービスにだけ接続できない
原因：DNS問題、ファイアウォールのブロック、プロキシ設定、サービス側の障害
対処法：nslookupで名前解決確認 → IPアドレス直打ちでアクセス確認 → ファイアウォールログ確認 → サービスのステータスページ確認
パターン6：VPN接続ができない
原因：VPNサーバーの障害、認証情報の期限切れ、ファイアウォールのポートブロック、クライアントソフトの不具合
対処法：VPNサーバーの稼働確認 → 認証情報の確認 → 必要ポート（500/4500 UDP, 1723 TCP等）の確認 → クライアント再インストール
パターン7：ネットワークプリンターで印刷できない
原因：プリンターのIPアドレス変更、プリンタースプーラーの停止、ドライバーの不具合、VLANの設定ミス
対処法：プリンターのIP確認 → ping確認 → スプーラーサービス再起動 → ドライバー再インストール
パターン8：突然のネットワーク全断
原因：ループ発生、コアスイッチ/ルーターの障害、停電、ISP回線障害
対処法：コア機器の状態確認 → UPSの状態確認 → ループ検出 → ISPへの確認
パターン9：ファイルサーバーへのアクセスが遅い
原因：ネットワーク帯域の不足、サーバーのディスクI/O負荷、SMBバージョンの不整合、ウイルススキャンの影響
対処法：ネットワーク速度計測 → サーバーのリソース使用率確認 → SMBプロトコルバージョン確認 → ウイルススキャン除外設定
パターン10：DNS解決が遅い/失敗する
原因：DNSサーバーの過負荷、フォワーダー設定の問題、DNSキャッシュの破損
対処法：DNSサーバーのリソース確認 → フォワーダー先の応答確認 → クライアントのDNSキャッシュクリア → 代替DNS（8.8.8.8）での確認
📋 具体例
障害対応チェックリストの活用：上記のパターンをベースに、自社環境に合わせたチェックリストを作成しておくと、障害時に慌てずに対応できます。例えば「インターネット接続不可時チェックリスト」として、1)ルーターのLED確認、2)ルーターにpingテスト、3)ISPのゲートウェイにpingテスト、4)8.8.8.8にpingテスト、5)ISPのステータスページ確認、6)ISPへ電話連絡、のように手順化しておきましょう。
5. 障害報告書の書き方
障害対応後の報告書は、再発防止と組織の知識蓄積のために非常に重要です。経営層に報告する場合も、技術的な詳細を残す場合も、以下のフォーマットが有効です。
障害報告書テンプレート
| 項目 | 記載内容 |
|---|---|
| 障害管理番号 | NW-2026-001 のような一意の番号 |
| 発生日時 | 2026年3月4日 10:15 |
| 検知方法 | ユーザー報告 / 監視アラート |
| 復旧日時 | 2026年3月4日 11:30 |
| 影響範囲 | 全社 / 2Fフロア / 特定ユーザー |
| 影響度 | 業務停止 / 業務遅延 / 軽微 |
| 障害概要 | 何が起きたかを1～2行で簡潔に |
| 原因 | 技術的な原因と根本原因 |
| 対応経緯 | 時系列での対応内容 |
| 恒久対策 | 再発防止のための対策 |
| 残課題 | 未完了の対策や検討事項 |
ポイント：障害報告書は「経営層向け」と「技術記録向け」の2層構成にすると効果的です。経営層向けには「影響範囲」「ダウンタイム」「再発防止策」を簡潔にまとめ、技術記録には「対応手順の詳細」「コマンド実行結果」「設定変更内容」を残します。後者はナレッジベースとして、次回の類似障害対応時間を大幅に短縮できます。
対応経緯の書き方
対応経緯は時系列で記載し、判断の根拠も含めます。
📋 具体例
対応経緯の記載例：10:15 - 総務部Aさんより「インターネットに接続できない」と報告を受ける。10:17 - 他の社員にも確認したところ、2Fフロア全体で同様の症状を確認。1Fおよび3Fは正常。10:20 - 2Fフロアスイッチ（SW-2F-01）を確認。アップリンクポートのリンクランプが消灯していることを確認。10:25 - ケーブルを確認したところ、清掃業者の作業により抜けていたことが判明。ケーブルを再接続し、リンクアップを確認。10:30 - 2Fフロア全端末の疎通を確認。復旧完了。
再発防止策の考え方
再発防止策は「技術的対策」と「運用的対策」の両面から検討します。
- 技術的対策：機器の冗長化、設定変更、セキュリティ強化、監視項目の追加
- 運用的対策：手順書の作成/更新、教育・周知、定期点検の追加、ベンダーとの体制強化
⚠️ 注意
再発防止策として「気をつける」「注意する」は対策になりません。具体的かつ実行可能な対策を記載してください。例えば「ケーブルの抜けに注意する」ではなく「サーバー室の重要ケーブルにケーブルロック（抜け止め）を設置する」「清掃業者への注意事項を明文化し共有する」のように具体的に記載します。
障害報告書のデータベースを作成し、過去の障害を検索・参照できるようにしておくと、ひとり情シスの強力なナレッジベースになります。ExcelやSharePointのリスト、あるいはConfluenceなどのWikiツールを活用しましょう。