【IT初心者向け】ネットワーク構築・運用で役立つ障害報告書の書き方｜現場で評価される報告のポイントを解説
障害報告書は、障害の内容・原因・対応・再発防止策を正確に記録する重要な文書です。単に「ネットワークがつながりませんでした」と書くだけでは十分ではありません。いつ、どこで、誰に、どのような影響があり、何を確認し、どのように復旧したのかを時系列で整理することが大切です。
ネットワーク運用では、障害報告書は社内だけでなく、お客様や上司、ベンダーへ提出するケースもあります。新人のうちから正しい書き方を身に付けておくことで、障害対応だけでなく、日常業務でも高く評価されます。
障害報告書とは
障害報告書とは、システムやネットワークで発生した障害について、発生から復旧までの経緯を記録する文書です。
目的は次の3つです。
- 障害内容を関係者へ正しく共有する
- 再発防止策を検討する
- 今後の障害対応に活用する
ネットワーク構築・運用では、障害報告書はトラブルシューティングの履歴としても利用されます。
ネットワーク運用で障害報告書が重要な理由
ネットワーク障害は、多くの利用者へ影響を与える可能性があります。
| 障害内容 | 影響 |
|---|---|
| 社内LAN停止 | 全社員が業務できない |
| インターネット回線断 | Web利用・メール送受信不可 |
| DNS障害 | 名前解決ができない |
| DHCP障害 | IPアドレスが取得できない |
| VPN障害 | テレワーク利用不可 |
障害報告書が正確であれば、次回同じ障害が発生した際に迅速な復旧につながります。
障害報告書に必ず記載する項目
| 項目 | 内容 |
|---|---|
| 障害名 | 何の障害か |
| 発生日時 | 発生した日時 |
| 復旧日時 | 復旧した日時 |
| 影響範囲 | 利用者・拠点・システム |
| 発生場所 | サーバー・拠点・機器 |
| 障害内容 | 発生した現象 |
| 原因 | 判明している原因 |
| 調査内容 | 実施した確認作業 |
| 対応内容 | 復旧手順 |
| 再発防止策 | 今後の対策 |
障害発生時に確認する順番
- 利用者から症状を確認する
- 影響範囲を確認する
- ネットワーク機器を確認する
- サーバーを確認する
- ログを確認する
- 復旧後に原因を調査する
- 障害報告書を作成する
慌てて原因を決めつけるのではなく、事実を一つずつ確認することが重要です。
原因の切り分け方法
| 確認項目 | チェック内容 |
|---|---|
| ユーザー側 | LANケーブル・Wi-Fi・PC設定 |
| ネットワーク側 | スイッチ・ルーター・FW |
| Windows側 | NIC・IP設定・サービス |
| DNS | 名前解決できるか |
| DHCP | IP取得できるか |
| Active Directory | 認証できるか |
| サーバー側 | サービス停止の有無 |
| 回線 | ISP障害の有無 |
障害報告書の記載例
障害概要
障害名
本社インターネット接続障害
発生日時
2026年8月3日 09:15
復旧日時
2026年8月3日 09:45
影響範囲
本社全社員約120名
障害内容
インターネット接続不可。社外Webサイト閲覧およびメール送受信不可。
原因
コアスイッチとルーター間のLANケーブル接触不良。
対応内容
LANケーブル交換後、通信正常化を確認。
再発防止策
定期点検時にケーブル固定状態を確認する運用を追加。
ログの確認方法
Windowsイベントビューアー
- Windowsキー＋X
- イベントビューアーを開く
- Windowsログを選択
- システムログを確認する
- エラー・警告を確認する
障害発生時刻前後のログを重点的に確認します。
コマンドプロンプトで確認する内容
| コマンド | 確認内容 |
|---|---|
| ipconfig | IPアドレス確認 |
| ipconfig /all | 詳細設定確認 |
| ping | 通信確認 |
| tracert | 通信経路確認 |
| nslookup | DNS確認 |
| netstat | 通信状態確認 |
PowerShellで確認できる内容
| コマンド | 用途 |
|---|---|
| Get-NetAdapter | NIC状態確認 |
| Get-NetIPAddress | IPアドレス確認 |
| Test-NetConnection | 通信確認 |
| Get-Service | サービス確認 |
GUIで確認する方法
- ネットワーク接続状態
- IPアドレス設定
- Wi-Fi状態
- イベントビューアー
- デバイスマネージャー
- タスクマネージャー
確認結果の見方
- IPアドレスが169.254.x.xならDHCP取得失敗の可能性が高い
- Default Gatewayが未設定なら通信不可となる
- DNSサーバーが空欄なら名前解決できない
- pingは成功するがWeb閲覧不可ならDNS障害を疑う
- 通信経路が途中で止まる場合はネットワーク機器や回線障害の可能性がある
初心者が混乱しやすいポイント
- 推測を原因として記載してしまう
- 時刻を書かない
- 確認した内容を書き忘れる
- 復旧した理由を書かない
- 影響範囲を記載しない
- 障害と問い合わせを混同する
現場でよくあるネットワーク障害
- LANケーブル抜け
- DHCPサーバー停止
- DNS障害
- Active Directory認証失敗
- ループ障害
- スイッチ故障
- VPN切断
- 回線事業者障害
筆者の経験談
運用現場では、「ネットワークが遅い」という問い合わせに対し、原因を決めつけず事実を時系列で整理することを徹底していました。ある案件では、利用者の申告だけでは回線障害と思われていましたが、調査を進めると一部のPCだけが影響を受けており、最終的な原因はネットワークアダプターの設定変更でした。障害報告書には推測ではなく、確認した事実と実施した対応を記録したことで、同様の問い合わせ時にも迅速な切り分けができました。
上司へ報告するポイント
- 障害発生時刻
- 現在の状況
- 影響範囲
- 実施した調査内容
- 暫定対応
- 復旧見込み
- 追加対応の予定
報告では、推測と事実を分けて伝えることが重要です。
エスカレーションするタイミング
- コアスイッチが停止している
- ルーターが故障している
- Active Directory障害が発生している
- 影響範囲が全社に及ぶ
- 30分以上原因が特定できない
- 機器交換が必要
- ベンダー対応が必要
障害発生時の考え方
ネットワーク障害では、「原因を探す」よりも「影響範囲を把握する」ことを優先すると、復旧までの時間を短縮しやすくなります。利用者全体に影響があるのか、一部の端末だけなのかを最初に確認することで、ネットワーク・サーバー・クライアントのどこを重点的に調査すべきか判断しやすくなります。
新人が覚えておくべきポイント
- 障害発生時刻を必ず記録する
- スクリーンショットを保存する
- ログは復旧前に取得する
- 変更作業があれば必ず記録する
- 事実と推測を分けて記載する
- 障害対応後は再発防止策までまとめる
関連するIT用語
- DNS（Domain Name System）
- DHCP（Dynamic Host Configuration Protocol）
- Active Directory
- VPN（Virtual Private Network）
- TCP/IP
- ルーター
- スイッチ
- ファイアウォール
- イベントビューアー
- ping
- tracert
- nslookup
よくある質問（FAQ）
障害報告書とインシデント報告書は同じですか？
似ていますが目的が異なります。障害報告書は主にシステムやネットワークの障害内容をまとめる文書であり、インシデント報告書は情報漏えいやセキュリティ事故など、より広い範囲の事象を対象とすることがあります。
原因が分からない場合はどう書けばよいですか？
推測を書かず、「調査中」と記載し、実施した調査内容と判明している事実を記録しましょう。原因が判明した時点で追記することが大切です。
復旧後も障害報告書は必要ですか？
必要です。復旧後に記録を残しておくことで、再発時の対応速度向上や再発防止策の検討に役立ちます。
まとめ
障害報告書は、ネットワーク運用において単なる報告書ではなく、将来の障害対応や運用品質の向上につながる重要な資料です。発生日時、影響範囲、調査内容、原因、対応内容、再発防止策を時系列で整理し、事実に基づいて記載することを心掛けましょう。新人のうちから正確な報告書を作成できるようになれば、障害対応の信頼性が高まり、チームからも安心して業務を任せてもらえるようになります。
コメント