システム障害やITインシデントが発生した際、再発防止と組織内での情報共有のために欠かせないのが「障害報告書」です。
障害報告書を正しく作成することで、原因の徹底分析・影響範囲の明確化・再発防止策の策定が効果的に行えます。
しかし「何をどう書けばいいかわからない」という方も多いでしょう。
本記事では、障害報告書の書き方と作成方法、必要な記載項目、IT障害・システム障害での実践的なポイントを解説していきます。
障害報告書とは？結論として「障害の事実・原因・対策を体系的にまとめた記録文書」
それではまず、障害報告書の基本的な役割と結論から解説していきます。
障害報告書とは、システム障害やITインシデントが発生した際に、その発生経緯・影響範囲・原因・対応内容・再発防止策を体系的にまとめた公式の記録文書のことです。
障害報告書には複数の重要な目的があります。
障害報告書の主な目的を示します。
事実の記録：何がいつ発生し、どのような影響があったかを正確に記録します。
原因の明確化：障害の根本原因（Root Cause）を分析・特定します。
再発防止：同様の障害が再発しないための具体的な対策を定義します。
情報共有：関係者・経営層・顧客などへの報告・説明資料として活用します。
ナレッジ蓄積：将来の障害対応に活用できる知識として組織内に蓄積します。
障害報告書は事後的な責任追及のためではなく、組織の学習と改善のための文書として位置づけることが重要です。
「ポストモーテム（Post-Mortem）」や「振り返り（Retrospective）」とも呼ばれ、先進的な技術組織ではノーブレームカルチャー（責任追及をしない文化）のもとで活用されているでしょう。
障害報告書に必要な基本的な記載項目
障害報告書には必ず含めるべき基本的な記載項目があります。
障害報告書の基本的な記載項目一覧を示します。
1. 概要：障害の内容を1〜2文で簡潔にまとめます。
2. 発生日時・復旧日時：障害が始まった時刻と解消した時刻を記録します。
3. 影響範囲：影響を受けたシステム・サービス・ユーザー数・業務範囲を記載します。
4. 障害の経緯（タイムライン）：発生から復旧まで時系列で対応の経緯を記録します。
5. 根本原因（Root Cause）：障害の直接原因と根本原因を分析して記載します。
6. 対応内容：実施した暫定対応と恒久対応を記載します。
7. 再発防止策：具体的なアクションアイテムと担当者・期限を記載します。
8. 今後の課題：中長期的に取り組むべき改善点を記載します。
特に「根本原因」と「再発防止策」は障害報告書の核心部分であり、表面的な原因だけでなく「なぜその原因が生じたか」という背景まで掘り下げることが重要でしょう。
タイムラインの書き方
タイムライン（時系列の経緯）は障害報告書の中でも特に重要なセクションです。
「いつ」「誰が」「何を発見・実施したか」を時系列で記録することで、障害対応の全体像が明確になり、後から振り返った際の分析精度が高まるでしょう。
タイムラインは発生時刻を含む精度で記録し、重要なイベント（最初のアラート・ユーザー報告・暫定対応実施・根本原因特定・恒久対応実施・復旧確認）を必ず含めます。
24時間対応のシステムでは、勤務時間外の対応も含めて正確に記録することが重要です。
根本原因分析（RCA）の手法
根本原因分析（Root Cause Analysis：RCA）は障害報告書の最も重要なプロセスのひとつです。
「なぜなぜ分析（5 Whys）」は「なぜ」を5回繰り返すことで表面的な原因から根本原因まで掘り下げる手法であり、障害の根本原因特定に広く使われているでしょう。
たとえば「サーバーがダウンした（why）→メモリが枯渇した（why）→メモリリークがあった（why）→コードレビューでリークを見落とした（why）→レビュー基準にメモリ管理のチェックがなかった（根本原因）」というように掘り下げていきます。
フィッシュボーン図（特性要因図）も根本原因の多角的な分析に有用なツールです。
障害報告書作成の実践的なポイント
続いては、障害報告書を効果的に作成するための実践的なポイントを確認していきます。
客観的な事実ベースで記述する
障害報告書では主観的な判断・感情・責任追及的な表現を避け、客観的な事実を中心に記述することが基本です。
「〇〇さんがミスをした」ではなく「〇〇の設定が誤っていた」という事実ベースの記述を徹底することで、建設的な改善のための文書となるでしょう。
Googleのポストモーテム文化に代表されるように、先進的な技術組織では「ノーブレーム（no blame）」の原則のもとで障害分析が行われています。
責任を問うのではなく「システムとプロセスの改善」に焦点を当てることで、より率直な情報共有と深い原因分析が可能になります。
再発防止策は具体的に記述する
再発防止策は「監視強化」「テスト充実」のような抽象的な記述では不十分です。
「誰が」「何を」「いつまでに」実施するかを具体的に記述し、アクションアイテムとして管理できる形にすることが、再発防止策を実効性のあるものにする鍵でしょう。
たとえば「2026年6月末までに、インフラチームがメモリ使用量のアラートをCloudWatchで設定し、しきい値80%で通知されるようにする」という形が望ましい記述例です。
再発防止策の進捗を定期的にフォローアップする仕組みも、実効性のある障害管理プロセスに欠かせません。
報告のタイミングと報告先
障害報告書の作成・報告には適切なタイミングがあります。
障害が発生してから通常24〜48時間以内に暫定版を作成し、根本原因の分析が完了した後（数日〜1週間程度）に完全版を提出するというプロセスが一般的でしょう。
顧客向け・経営層向け・技術チーム向けでは、記述の詳細度や焦点が異なるため、読み手に応じた調整も重要です。
| 記載項目 | 記述のポイント |
|---|---|
| 概要 | 1〜2文で障害の本質を簡潔に伝える |
| 発生・復旧日時 | 分単位で正確に記録する |
| 影響範囲 | 影響を受けたシステム・ユーザー数・ビジネス影響を定量的に |
| タイムライン | 時系列で誰が何をしたかを客観的に記録 |
| 根本原因 | なぜなぜ分析で表面的原因から根本原因まで掘り下げる |
| 再発防止策 | 誰が・何を・いつまでに実施するかを具体的に記述 |
まとめ
本記事では、障害報告書の役割と目的、基本的な記載項目、タイムラインの書き方、根本原因分析の手法、実践的な作成ポイントを解説しました。
障害報告書は「障害の事実・原因・対策を体系的にまとめた記録文書」であり、組織の学習・改善・再発防止のための重要なドキュメントです。
客観的な事実ベースの記述・具体的な再発防止策・ノーブレームの文化が、効果的な障害報告書作成の基本となるでしょう。
障害報告書を正しく作成する能力は、ITシステムの品質向上と組織の技術的成熟度を高めるための重要なエンジニアリングスキルといえます。
