障害報告書の書き方｜例文つきテンプレートと再発防止策の立て方

障害報告書とは、システムの障害について「何が起き、どんな影響があり、なぜ起きて、どう防ぐのか」を、関係者に正確に伝えるための文書です。お客様や社内の関係者が状況を理解し、同じ障害を二度と起こさないための対策につなげることが目的です。

項目の一覧やテンプレートを紹介する記事は多くありますが、この記事では、架空の障害を1件取り上げ、報告書の完成版の例文を示します。あわせて、初報・中間報告・最終報告の使い分けと、原因を掘り下げて再発防止策を立てる手順も解説します。

障害報告書の早見表

初報・中間報告・最終報告の使い分け

初報で最も大切なのは速さです。原因がわからない段階でも、「何が起きていて、いま何をしていて、次にいつ報告するか」を伝えるだけで、関係者は判断や準備ができます。

障害報告書に書く10項目

例文：最終報告（架空の障害）

以下は、説明のために作成した架空の障害の例です。

件名：会員登録の確認メールが送信されなかった障害について（最終報告）

1. 発生日時・復旧日時
   発生：2026年X月X日 14:05
   復旧：2026年X月X日 16:40（影響時間：2時間35分）

2. 障害の概要
   会員登録をしたお客様に、登録を完了するための確認メールが
   送信されない状態となりました。その間、新たに登録されたお客様は
   登録を完了できませんでした。

3. 影響範囲
   ・確認メールが届かなかったお客様：312名
   ・上記のお客様には、復旧後の16:55に確認メールを再送信しました
   ・既存の会員の方のログイン・ご利用には影響はありません
   ・個人情報の漏えいはありません

4. 経緯
   14:00  メール送信機能の設定変更をリリース
   14:05  確認メールの送信が失敗し始める（障害の発生）
   15:20  お客様からのお問い合わせで事象を認識（検知）
   15:30  関係者へ初報を連絡、調査を開始
   16:10  14:00の設定変更で、メール送信サービスの認証情報の
          設定名を誤っていたことを特定
   16:35  設定を修正してリリース
   16:40  確認メールが正常に送信されることを確認（復旧）
   16:55  未送信だった312名のお客様へ確認メールを再送信

5. 原因
   【直接の原因】
   メール送信サービスの認証情報を読み込む設定の名前が、
   新しい設定ファイルで誤っていたため、送信時の認証に失敗しました。
   【根本的な原因】
   ・設定の誤りを、リリース前に検知する仕組みがありませんでした
     （検証環境では、別の設定名で動作していたため）
   ・メール送信の失敗を検知する監視がなく、お客様からの
     お問い合わせまで75分間気づけませんでした

6. 暫定対応
   設定名を修正してリリースし、未送信のお客様へ確認メールを再送信しました。

7. 恒久対策
   ①起動時に必須の設定がすべて読み込めているかを確認し、
     不足していれば起動を止める仕組みを追加（担当：開発チーム／X月X日まで）
   ②検証環境と本番環境の設定名を揃え、差分を自動で比較する
     手順をリリースの工程に追加（担当：開発チーム／X月X日まで）
   ③メール送信の失敗が5分間に10件を超えたら通知する監視を追加
     （担当：運用チーム／X月X日まで）

8. 今後の予定
   上記の対策の完了後、実施結果をご報告します。

例文のポイント

経緯（時系列）の書き方

発生から検知までの時間は、特に大切な指標です。例文では、発生から75分後にお客様からのお問い合わせで気づいています。ここを短くすることが、恒久対策③（監視の追加）につながっています。

原因を掘り下げる：なぜなぜ分析

直接の原因（設定名の誤り）だけで終わると、対策が「設定を注意して書く」になってしまいます。「なぜ」を繰り返して、仕組みの問題までたどります。

「なぜ」の答えが「担当者が不注意だったから」になったら、そこで止めずに、もう一段掘り下げます。「なぜ、不注意が障害につながったのか」を考えると、「確認する仕組みがなかった」という、仕組みで直せる原因にたどり着けます。

再発防止策の立て方

「注意する」「徹底する」は、人に頼る対策で、効果が続きにくいものです。対策は、次の順で強くなります。

また、対策には担当と期限を決め、完了したら報告します。「対策を決めた」で終わらず、「対策を実施した」まで追いかけることが大切です。

書くときの言葉づかい

障害報告書は、個人の責任を問うための文書ではありません。仕組みの改善に焦点を当てると、関係者が事実を率直に共有しやすくなり、本当の原因にたどり着きやすくなります。

提出前のチェックリスト

よくある質問

Q. 原因がまだわからない段階でも、報告すべきですか？ A. はい。初報は、原因がわかる前に出すものです。「原因は調査中です。次は〇時に報告します」と書けば十分です。報告が遅れることの方が、関係者の不安と混乱を大きくします。

Q. お客様向けと社内向けで、書き方を変えるべきですか？ A. 内容の事実は同じにしたうえで、お客様向けは影響と対応を中心にわかりやすく、社内向けは技術的な原因と対策を詳しく書くのが一般的です。

Q. ポストモーテムとの違いは何ですか？ A. ポストモーテムは、障害の後にチームで振り返り、学びを共有する取り組みのことで、個人を責めない（ブレームレス）ことを特に重視します。障害報告書が「関係者への報告」の文書であるのに対し、ポストモーテムは「チームの改善」のための振り返りです。両方を行う組織も多くあります。

まとめ

• 障害報告書の目的は、正確な共有と、再発の防止
• 初報は速さ優先、最終報告で原因と対策を固める
• 日時は分単位、影響は数字で。発生と検知の時刻を分けて書く
• なぜなぜ分析で、直接の原因の奥にある仕組みの問題まで掘り下げる
• 再発防止策は「注意する」ではなく、仕組みで防ぐ。担当と期限を決める
• 個人ではなく仕組みに焦点を当てる

株式会社RJCでは、システムを安定して動かし続けるための運用の工夫も、プロジェクトの中で仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。