評価される障害報告書の書き方｜原因・影響・対応を分かりやすく伝える実践テンプレート

2026年7月19日

ネットワーク障害やシステム障害が発生したとき、エンジニアには技術的な復旧だけでなく、関係者への報告も求められます。

しかし、障害対応を始めたばかりのエンジニアは、次のような悩みを抱えがちです。

どこまで詳しく書けばよいか分からない
技術用語ばかりの報告書になってしまう
原因が分からない段階で何を報告すればよいか迷う
時系列を書いても「結局何が起きたのか分からない」と言われる
再発防止策が「監視を強化する」「確認を徹底する」で終わってしまう

評価される障害報告書とは、専門的で長い文書ではありません。

読み手が知りたい情報を整理し、障害の影響、現在の状況、原因、対応、再発防止策を誤解なく伝えられる文書です。

この記事では、ネットワークエンジニアが障害報告書を作成するときの基本構成、書き方のポイント、よくある失敗、実務で使えるテンプレートまで解説します。

対象：Level 2｜自立型エンジニアを目指す人
必要時間：15分
身につく成果：障害報告書を一定の品質で作成できる
関連スキル：障害対応／原因分析／顧客報告／再発防止

障害報告書が評価される人とされない人の違い

障害対応では、復旧作業の技術力だけが評価されるわけではありません。

同じ障害を解決したとしても、報告の仕方によって周囲からの評価は大きく変わります。

評価されにくい報告

発生した事象だけを並べている
技術用語が多く、顧客や管理者が理解できない
影響範囲が書かれていない
事実と推測が混ざっている
原因だけを説明し、再発防止策がない
誰が何を実施したのか分からない
現在の状態が正常なのか判断できない

評価される報告

最初に結論が書かれている
業務や利用者への影響が明確になっている
事実、推測、未確認事項が分けられている
発生から復旧までの流れを追える
原因と対策に一貫性がある
技術に詳しくない人でも概要を理解できる
次に何をするのかが明確になっている

障害報告書は、単なる作業記録ではありません。

関係者が状況を理解し、次の判断をするための資料です。

結論：障害報告書は「6つの質問」に答える

障害報告書を作成するときは、次の6つの質問に答える形で情報を整理します。

質問	報告書に書く内容
何が起きたのか	障害概要・発生事象
誰に影響したのか	影響範囲
いつ起きたのか	発生日時・復旧日時・時系列
なぜ起きたのか	原因
どのように復旧したのか	対応内容
今後どう防ぐのか	再発防止策

技術的な調査内容を大量に書いても、この6つが分からなければ良い報告書にはなりません。

逆に、複雑な障害でも、この6点が整理されていれば読み手は状況を理解できます。

障害報告は3段階に分けて考える

障害報告には、大きく分けて次の3種類があります。

初報
中間報告
最終報告

すべての段階で原因を説明する必要はありません。

原因が分からない段階で無理に断定すると、後から説明を訂正することになり、信頼を失う可能性があります。

1．初報

初報の目的は、障害が発生していることを関係者へ知らせることです。

原因を詳しく説明するよりも、次の情報を優先します。

発生日時
発生している事象
現時点で確認できている影響
対応状況
次回報告予定

初報の例

2026年7月15日10時20分頃から、東京拠点の一部端末において、社内業務システムへ接続できない事象が発生しています。
現在、ネットワーク機器およびサーバーの状態を確認しています。
影響範囲と原因については調査中です。
次回の状況報告は11時00分を予定しています。

初報では、分からないことを無理に埋める必要はありません。

ただし、「調査中です」だけでは不十分です。

何を確認しているのか、次の報告はいつなのかまで伝えます。

2．中間報告

中間報告の目的は、調査や復旧作業の進捗を伝えることです。

次の内容を更新します。

新たに判明した影響範囲
調査した内容
現時点で考えられる原因
実施済みの対応
今後実施する対応
次回報告予定

中間報告の例

東京拠点のフロアスイッチ1台で、上位スイッチとの接続ポートがリンクダウンしていることを確認しました。
当該スイッチ配下の端末約30台で、社内ネットワークへ接続できない状態です。
現在、接続ケーブルおよびスイッチポートの状態を確認しています。
なお、その他のフロアおよび拠点への影響は確認されていません。
次回の状況報告は11時30分を予定しています。

原因が確定していない場合は、「原因は〇〇です」と断定せず、次のように表現します。

現時点では〇〇の可能性を確認しています
〇〇が原因である可能性が高いと判断しています
原因の確定には追加調査が必要です

3．最終報告

最終報告では、障害の全体像を整理します。

障害概要
発生日時・復旧日時
影響範囲
発生から復旧までの時系列
原因
復旧対応
再発防止策
現在の状態

最終報告は、後から同じ問題が発生したときの参考資料にもなります。

そのため、「誰が読んでも同じ状況を再現できる」程度の具体性が必要です。

評価される障害報告書の基本構成

障害報告書は、次の順番で作成すると読みやすくなります。

1．障害概要

最初に、何が起きたのかを1～3文で説明します。

書く内容

発生した事象
対象システムや機器
利用者への影響
現在の状態

記載例

東京拠点のフロアスイッチと上位スイッチ間の接続障害により、一部端末から社内ネットワークへ接続できない事象が発生しました。
接続ケーブルの交換により、現在は正常に通信できることを確認しています。

障害概要を読めば、報告書全体の内容をおおよそ理解できる状態が理想です。

2．発生日時・復旧日時

障害が継続した時間を明確にします。

項目	日時
障害発生	2026年7月15日 10時20分
障害検知	2026年7月15日 10時23分
対応開始	2026年7月15日 10時28分
暫定復旧	2026年7月15日 11時15分
正常性確認	2026年7月15日 11時30分

発生日時と検知日時は、必ずしも同じではありません。

監視アラートで検知した時刻、利用者から問い合わせを受けた時刻、ログから判明した実際の発生時刻を区別します。

3．影響範囲

読み手が特に知りたいのは、機器の状態ではなく、業務への影響です。

技術視点だけの表現

スイッチのGi1/0/24がリンクダウンしました。

業務影響まで含めた表現

東京拠点3階のフロアスイッチで上位接続ポートがリンクダウンし、当該スイッチ配下の端末約30台から社内業務システムへ接続できない状態となりました。

影響範囲には、可能な限り次の情報を含めます。

対象拠点
対象部署
対象ユーザー数
対象端末数
利用できなかった機能
業務への影響
影響を受けなかった範囲

記載例

東京拠点3階の営業部および管理部で使用している端末約30台が影響を受けました。
影響時間中は、社内業務システム、ファイルサーバーおよびインターネットへ接続できない状態でした。
無線LAN、音声ネットワーク、他拠点および外部公開サービスへの影響はありませんでした。

「影響がなかった範囲」を書くと、読み手は必要以上に不安を感じずに済みます。

4．時系列

時系列では、発生から復旧までに何が起きたのかを整理します。

時刻	内容
10:20	東京拠点3階の端末で通信障害が発生
10:23	ネットワーク監視システムがフロアスイッチの到達不能を検知
10:25	利用者からサービスデスクへ接続不可の連絡
10:28	ネットワーク担当者が調査を開始
10:35	上位スイッチ側の接続ポートがリンクダウンしていることを確認
10:45	スイッチポートおよび接続ケーブルを確認
11:05	接続ケーブルの不良を確認し、予備ケーブルへ交換
11:15	通信が復旧
11:30	対象端末から各システムへの接続を確認し、正常性確認を完了

時系列には、調査で実行したすべてのコマンドを書く必要はありません。

判断や対応の流れを理解するために必要な出来事を記載します。

詳細なコマンド結果やログは、必要に応じて別紙や添付資料にまとめます。

5．原因

原因は、発生した事象を繰り返すのではなく、なぜその事象が起きたのかを説明します。

事象

スイッチのポートがリンクダウンした。

直接原因

スイッチ間を接続するLANケーブルのコネクター部分が破損し、物理リンクが切断された。

背景要因

ケーブルが通路付近に敷設されており、外部から力が加わりやすい状態だった。
また、ケーブルを固定する保護部材が設置されていなかった。

原因分析では、次の3段階に分けると整理しやすくなります。

分類	内容
事象	実際に発生した現象
直接原因	障害を直接引き起こした原因
背景要因	直接原因が発生しやすくなった運用・設計上の問題

原因の記載例

スイッチ間を接続するLANケーブルのコネクター部分が破損し、物理リンクが切断されたことが直接原因です。
ケーブルが人の通行する場所に近い位置で配線され、十分に固定されていなかったことが背景要因として確認されました。

6．対応内容

対応内容では、障害をどのように復旧したかを記載します。

記載例

接続ケーブルの外観および導通状態を確認し、コネクター部分の破損を確認しました。
破損したケーブルを予備ケーブルへ交換し、スイッチ間のリンクアップを確認しました。
その後、対象端末からデフォルトゲートウェイ、社内業務システム、ファイルサーバーおよびインターネットへの通信確認を実施しました。

対応は、次の2つに分けて書くことがあります。

暫定対応

サービスを早期に復旧するための一時的な対応です。

例：

機器の再起動
予備回線への切り替え
冗長機への切り替え
一部機能の停止
設定の切り戻し

恒久対応

原因を取り除くための対応です。

例：

故障機器の交換
設定設計の見直し
ソフトウェアの更新
配線経路の変更
監視項目の追加

暫定復旧だけで対応を完了とせず、恒久対応が必要かを判断します。

7．再発防止策

再発防止策は、原因と対応している必要があります。

良くない再発防止策

注意します
確認を徹底します
監視を強化します
関係者へ周知します

これらは具体的な行動や完了条件が分かりません。

良い再発防止策

通路付近に敷設されているLANケーブルをラック内の配線経路へ変更する
ケーブル固定部材を設置し、コネクターへ外力が加わらないようにする
同一拠点の全スイッチについて、上位接続ケーブルの外観点検を実施する
月次点検表に、ケーブル固定状態の確認項目を追加する
予備ケーブルの保管場所と交換手順を運用手順書へ追記する

再発防止策には、次の項目を設定します。

項目	内容
実施内容	何をするか
担当者・担当部署	誰が行うか
期限	いつまでに行うか
完了条件	何をもって完了とするか

記載例

再発防止策	担当	期限	完了条件
対象ケーブルの配線経路をラック内へ変更する	ネットワーク担当	7月22日	配線変更後の通信試験完了
同拠点の上位接続ケーブルを点検する	運用担当	7月25日	全対象機器の点検記録を提出
月次点検表へ固定状態の確認項目を追加する	運用設計担当	7月31日	改訂版手順書の承認完了

事実・推測・未確認事項を分ける

障害対応中は、まだ原因が確定していない状態で報告することがあります。

このとき、事実と推測を混ぜてはいけません。

事実

ログ、監視情報、機器状態、利用者への確認などによって確認できている情報です。

10時23分に監視システムがスイッチの到達不能を検知しました。

推測

確認済みの情報から考えられる可能性です。

上位接続ポートがリンクダウンしているため、物理層の問題である可能性があります。

未確認事項

調査が終わっておらず、判断できない情報です。

ケーブル不良またはスイッチポート故障のどちらが原因であるかは、現時点では確定していません。

報告書には、次のような表現を使います。

確認しました
判明しました
現時点では〇〇の可能性があります
〇〇と推定しています
詳細は継続調査中です
原因の確定には追加調査が必要です

原因が確定していないにもかかわらず、「原因は〇〇です」と断定しないことが重要です。

技術用語を業務影響へ翻訳する

障害報告書の読み手が、すべてネットワークエンジニアとは限りません。

顧客、営業担当者、プロジェクトマネージャー、管理職など、技術に詳しくない人が読む可能性があります。

そのため、技術的な現象だけでなく、利用者から見た影響も併記します。

技術的な表現	読み手に伝わる表現
BGPセッションがダウン	外部ネットワークへの経路情報を受信できず、一部通信が利用できない状態
DNSの名前解決に失敗	システム名から接続先を特定できず、Webシステムへアクセスできない状態
DHCPでIPアドレスを取得できない	端末がネットワークへ接続するための情報を取得できない状態
VLAN設定に不整合がある	対象端末の通信が正しいネットワークへ転送されない状態
インターフェースでエラーを検知	通信データの一部が正常に送受信できない状態
VRRPの切り替わりが発生	通信を担当する機器が予備機へ切り替わった状態

技術用語を完全に削除する必要はありません。

技術用語と業務影響をセットで説明することが大切です。

悪い障害報告書と良い障害報告書の比較

悪い例

10時頃に通信障害が発生しました。
スイッチを確認したところ、ポートがダウンしていました。
ケーブルを交換したら復旧しました。
今後は確認を徹底します。

この文章には、次の問題があります。

正確な発生日時が分からない
どこで起きたのか分からない
何人が影響を受けたのか分からない
利用できなかったサービスが分からない
原因と再発防止策が曖昧
現在の正常性が分からない

良い例

2026年7月15日10時20分から11時15分まで、東京拠点3階のフロアスイッチと上位スイッチ間で接続障害が発生しました。
この影響により、当該フロアの端末約30台から社内業務システム、ファイルサーバーおよびインターネットへ接続できない状態となりました。

調査の結果、スイッチ間を接続するLANケーブルのコネクター部分が破損し、物理リンクが切断されていたことを確認しました。
破損したケーブルを予備ケーブルへ交換し、11時15分に通信が復旧しました。11時30分までに対象端末から各サービスへの接続確認を実施し、正常性を確認しています。

再発防止策として、対象ケーブルの配線経路を変更するとともに、同一拠点に設置されている上位接続ケーブルの一斉点検を実施します。

良い例では、障害の概要、影響、原因、対応、現在の状態、再発防止策を短い文章で把握できます。

障害報告書でよくある7つの失敗

1．時系列だけで終わっている

時系列は重要ですが、出来事を並べるだけでは結論が伝わりません。

報告書の冒頭には、障害概要と影響範囲を書きます。

2．調査ログをすべて貼り付けている

ログやコマンド結果を大量に貼ると、重要な情報が埋もれます。

本文には判断に必要な情報だけを書き、詳細なログは別紙や添付資料にします。

3．主語が書かれていない

確認したところ、設定が変更されていました。

この文章では、誰が確認したのか、誰が設定を変更したのか分かりません。

ネットワーク運用担当者が設定履歴を確認したところ、保守作業時に対象ポートのVLAN設定が変更されていたことを確認しました。

誰が何をしたのかを明確にします。

4．原因と再発防止策が対応していない

原因が「手順書の記載不足」であるにもかかわらず、再発防止策が「監視を追加する」だけでは、同じ作業ミスを防げません。

原因	対応する再発防止策
手順書の記載不足	手順書へ判断条件と確認項目を追加
作業前レビュー不足	変更作業のダブルチェックを必須化
監視項目不足	対象状態を検知する監視項目を追加
単一障害点の存在	機器・回線の冗長化を検討
ソフトウェア不具合	修正版へのアップデートを実施

5．担当者個人の責任だけにしている

担当者が設定を間違えたことが原因です。

この書き方だけでは、別の担当者が同じミスをする可能性があります。

個人のミスだけでなく、次の観点を確認します。

手順書に不明確な記載がなかったか
レビューの仕組みがあったか
作業前後の確認項目が定義されていたか
テスト環境で検証できたか
ロールバック手順が準備されていたか
権限管理は適切だったか

再発防止では、個人の注意力に依存しない仕組みを考えます。

6．専門用語を説明せずに使っている

報告先に応じて、専門用語へ補足を加えます。

DNSサーバーで名前解決処理が停止し、利用者がシステム名を指定して業務システムへ接続できない状態となりました。

このように、技術事象と利用者への影響をセットで記載します。

7．正常性確認の内容がない

「復旧しました」だけでは、本当に利用可能になったか判断できません。

次のように、確認した内容を書きます。

対象端末からの疎通確認
業務システムへのログイン
ファイルの参照・更新
インターネット接続
監視アラートの回復
機器ログに新たな異常がないこと
利用部門への復旧確認

原因分析で使える「なぜなぜ分析」

根本原因を整理するときは、「なぜ」を繰り返して考える方法があります。

例：VLAN設定ミスによる通信障害

なぜ通信できなかったのか

対象ポートに誤ったVLANが設定されていたため。

なぜ誤ったVLANが設定されたのか

作業者が設定対象ポートを取り違えたため。

なぜポートを取り違えたのか

作業手順書のポート番号と機器の表示方法が異なっていたため。

なぜ事前に気づけなかったのか

作業手順書のレビューで、実機表示との照合を行っていなかったため。

なぜ障害が長時間継続したのか

作業後の疎通確認項目に、対象端末からの業務通信確認が含まれていなかったため。

この場合、再発防止策は「作業者が注意する」ではありません。

手順書へ機器名と物理ポート位置の画像を追加する
レビュー時に実機表示との照合を行う
作業前に対象ポートを現地担当者と相互確認する
作業後確認に業務通信テストを追加する
問題発生時の切り戻し条件を明文化する

原因を深掘りすることで、具体的な再発防止策を作れます。

報告先によって説明の粒度を変える

同じ障害でも、報告相手によって必要な情報は異なります。

利用者向け

知りたいことは、サービスを利用できるかどうかです。

どのサービスが使えないのか
代替手段はあるか
いつ復旧する見込みか
復旧したか

顧客担当者・管理者向け

業務や契約への影響を重視します。

影響範囲
障害時間
原因
対応状況
再発防止策
SLAへの影響

技術担当者向け

調査や再発防止に必要な技術情報を含めます。

対象機器
構成
設定
ログ
コマンド結果
パケットキャプチャー
ソフトウェアバージョン
検証結果

1つの報告書ですべてを説明しようとすると、長くなりすぎます。

概要は本文にまとめ、技術情報は別紙へ分ける方法が有効です。

障害報告書の実践テンプレート

以下は、ネットワーク障害を想定した最終報告書のテンプレートです。

障害報告書

1．件名

〇〇システムにおける通信障害について

2．障害概要

〇年〇月〇日〇時〇分頃、〇〇において、〇〇が利用できない事象が発生しました。

調査の結果、〇〇が原因であることを確認しました。

〇時〇分に〇〇を実施し、現在は正常に利用できることを確認しています。

3．発生日時・復旧日時

項目	日時
障害発生日時	〇年〇月〇日〇時〇分
障害検知日時	〇年〇月〇日〇時〇分
対応開始日時	〇年〇月〇日〇時〇分
復旧日時	〇年〇月〇日〇時〇分
正常性確認完了	〇年〇月〇日〇時〇分

4．影響範囲

対象拠点：
対象部署：
対象ユーザー数・端末数：
利用できなかったサービス：
業務への影響：
影響を受けなかった範囲：

5．発生事象

〇〇により、〇〇の状態が発生しました。

利用者からは、〇〇の操作を行った際に、〇〇の事象として確認されました。

6．時系列

時刻	内容
〇:〇	障害発生
〇:〇	監視システムまたは利用者からの連絡により障害を検知
〇:〇	調査開始
〇:〇	影響範囲を確認
〇:〇	原因を特定
〇:〇	復旧対応を実施
〇:〇	通信復旧
〇:〇	正常性確認完了

7．原因

直接原因

〇〇が発生したことにより、〇〇の通信が停止しました。

背景要因

〇〇の設計、運用または確認手順が不足していたため、直接原因の発生を事前に防止できませんでした。

8．対応内容

暫定対応

〇〇を実施
〇〇へ切り替え
〇〇の正常性を確認

恒久対応

〇〇を交換
〇〇の設定を変更
〇〇の手順書を改訂

9．正常性確認

以下の項目について正常であることを確認しました。

機器間の接続状態
対象端末からの疎通
業務システムへの接続
インターネットへの接続
監視システムの状態
機器ログ
利用部門による動作確認

10．再発防止策

対策	担当	実施期限	完了条件
〇〇を実施する	〇〇担当	〇月〇日	〇〇の確認完了
手順書へ〇〇を追加する	〇〇担当	〇月〇日	改訂版の承認完了
同一構成の機器を点検する	〇〇担当	〇月〇日	全対象の点検完了

11．現在の状況

〇年〇月〇日〇時〇分時点で、対象サービスが正常に利用できることを確認しています。

復旧後、同様の事象および関連する監視アラートは発生していません。

初報テンプレート

件名：〇〇システムの障害発生について

〇年〇月〇日〇時〇分頃から、〇〇において、〇〇が利用できない事象が発生しています。
現時点で確認できている影響範囲は〇〇です。
現在、〇〇の状態および関連するログを確認しています。
原因および復旧見込みについては調査中です。
次回の状況報告は〇時〇分を予定しています。

中間報告テンプレート

件名：〇〇システムの障害に関する状況報告

〇時〇分現在、〇〇の状態を確認しています。
現時点までに、〇〇が影響を受け、〇〇には影響がないことを確認しました。
調査の結果、〇〇が原因である可能性が高いと判断していますが、原因の確定には追加調査が必要です。
現在、復旧に向けて〇〇を実施しています。
次回の状況報告は〇時〇分を予定しています。

障害報告書のセルフチェックリスト

報告書を提出する前に、次の項目を確認します。

内容

障害の概要を最初に理解できるか
発生日時と復旧日時が明確か
影響範囲が具体的か
現在の状態が書かれているか
事実と推測を分けているか
原因と再発防止策が対応しているか
暫定対応と恒久対応を区別しているか
正常性確認の内容が書かれているか
担当者と実施期限が明確か

表現

主語と目的語が分かるか
曖昧な表現を使っていないか
専門用語に補足があるか
一文が長くなりすぎていないか
読み手が知りたい情報から書いているか
個人への責任追及だけになっていないか
感情的な表現を使っていないか

数値

日付と曜日が一致しているか
発生時刻と復旧時刻が一致しているか
障害継続時間の計算が正しいか
対象ユーザー数や端末数が正しいか
機器名、ポート番号、IPアドレスに誤りがないか

障害報告で使える英語表現

海外ベンダーや海外拠点へ報告するときは、次の表現を使用できます。

日本語	英語表現
障害が発生しています	We are currently experiencing an issue.
一部の利用者が影響を受けています	Some users are affected by the issue.
原因を調査しています	We are investigating the root cause.
原因はまだ特定できていません	The root cause has not yet been identified.
暫定対応を実施しました	We have implemented a temporary workaround.
サービスは復旧しました	The service has been restored.
正常性を確認しています	We are verifying that the service is operating normally.
再発防止策を検討しています	We are reviewing preventive measures.
次回の報告は〇時を予定しています	The next update will be provided at 3:00 p.m.

原因が確定していない場合は、次のように表現します。

We suspect that the issue may be related to the network connection, but further investigation is required.

「ネットワーク接続に関連している可能性がありますが、追加調査が必要です」という意味です。

障害報告書はエンジニアの市場価値を示す成果物になる

障害報告書を作成できることは、単に文章を書く能力ではありません。

次の能力を持っていることの証明になります。

障害の全体像を把握する力
技術情報を整理する力
業務影響を考える力
原因を分析する力
関係者へ説明する力
再発防止策を設計する力
対応を最後まで管理する力

監視アラートを確認し、手順書どおりに復旧するだけでは、担当できる業務の範囲は広がりません。

障害の原因や影響を整理し、顧客や上司へ説明できるようになると、障害対応の中心メンバー、設計担当、リーダーなど、次の役割を任されやすくなります。

職務経歴書や面談でも、次のように具体的な実績として説明できます。

拠点ネットワーク障害の切り分けから顧客報告までを担当しました。
機器ログと接続状態から原因を特定し、復旧対応、影響範囲の整理、時系列の作成、再発防止策の提案を実施しました。

「障害対応を経験した」だけでなく、どの範囲まで担当できるのかを示すことが重要です。

まとめ

評価される障害報告書では、次の内容が整理されています。

何が起きたのか
誰に影響したのか
いつ発生し、いつ復旧したのか
なぜ発生したのか
どのように復旧したのか
今後どのように再発を防ぐのか

障害報告で最も大切なのは、難しい技術用語を使うことではありません。

読み手が状況を理解し、安心して次の判断をできるようにすることです。

まずは、今回紹介したテンプレートを使い、障害概要、影響範囲、原因、対応内容、再発防止策の5項目を整理するところから始めてください。

障害を復旧できるだけでなく、その内容を分かりやすく説明できるようになれば、エンジニアとして任される仕事の範囲は大きく広がります。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

Yuki