障害報告書の書き方：第一報と最終報告の項目・例文、保守契約で決める報告ルール

システムの障害報告書は、障害が起きたあとに発注者・顧客・経営層へ「何が起き、どこまで影響し、なぜ起き、どう防ぐか」を説明する文書です。書く内容は1回で決まるものではなく、発生直後の第一報、調査中の中間報告、原因と対策が固まった最終報告で項目も期限も変わります。この記事では、総務省が通信事業者に課している重大な事故の報告項目を下敷きに、時系列・原因・再発防止策の書き方と、そのまま使えるテンプレートと例文を整理しました。あわせて、運用保守契約に書いておくべき報告期限と様式、個人データの漏えいを伴う障害で別に走る委員会への報告まで扱います。

まとめ：障害報告書は第一報の速さと最終報告の原因の深さを分けて書く

障害報告書でもっとも多い失敗は、原因が分かるまで第一報を出さないことです。第一報は判明している事実だけで構いません。発生日時、影響している機能と利用者の範囲、現在の対応状況、次の報告予定時刻の4つがあれば、受け取る側は社内への説明と業務の回避策を考え始められます。

最終報告では逆に、速さよりも原因分析の深さが評価の軸です。原因は「直接の原因」と「影響が広がった、または長引いた原因」に分け、再発防止策は暫定対処と恒久対処を実施時期つきで書きます。「確認不足」「教育の徹底」で終わる報告書は、同じ障害を3か月後にもう一度呼び込みます。

報告の期限と様式は、障害が起きてから相談するものではありません。重大度ごとの第一報の期限、最終報告の提出日数、報告書の承認者を、運用保守契約やSLAの別紙に書いておくと、報告の質を受託側の担当者の力量に頼らずに済みます。

障害報告書の役割と、第一報・中間報告・最終報告で書く内容が変わる理由

発注者・顧客・経営層へ影響と対策を説明する外部向け文書としての範囲

障害報告書の読み手は、システムの中身を知らない人です。発注者の情報システム部門、業務部門の責任者、経営層、場合によっては取引先や利用者が読みます。読み手が知りたいのは、自社の業務や顧客にどこまで影響したか、同じことがまた起きないかの2点に尽きます。

似た文書にポストモーテムがあります。こちらは開発・運用チームが原因を深く掘り、次の行動を決めるための社内の技術文書です。

両方を作るなら、先にポストモーテムで事実と原因を固め、その要約を障害報告書に移す順にすると、時刻や原因の記述が食い違いません。社内向けの書き方とテンプレートはポストモーテムの書き方とテンプレート、非難しない運用で解説しています。

総務省の重大事故報告が「速やかな報告」と30日以内の詳細報告に分ける仕組み

報告を段階に分ける考え方は、法令にも組み込まれています。総務省の重大な事故の報告のページによると、電気通信事業者は重大な事故を起こしたとき、電気通信事業法施行規則第57条に基づいて「速やかに」発生日時などを報告し、さらに事故の発生から30日以内に所定の様式で詳細を報告しなければなりません。報告を怠ったり虚偽の報告をしたりすると、30万円以下の罰金の対象になります。

注目したいのは第一報の扱いです。同ページは、第一報では報告書類を正式に準備する必要はなく、その時点で判明している事項だけを電話、FAX、電子メールで伝えるよう案内しています。一般の業務システムに法的な報告義務はありませんが、この「速報は判明事項だけ、詳細は期限を切って書面で」という分け方は、そのまま自社の報告ルールの型になります。

第一報・中間報告・最終報告の目的と提出の目安を一覧で比べた整理

3段階の報告は、目的がそれぞれ違います。

提出の目安は、業務への影響が大きい障害を想定した一例です。社内の基幹業務が止まる障害なら第一報は30分以内、夜間バッチの遅延のように翌朝まで影響が出ない障害なら翌営業日の朝でも足ります。期限は重大度で変え、契約で事前に決めておきます（契約章で後述）。

システム障害報告書の記載項目と、総務省の詳細報告様式に学ぶ書き方の粒度

第一報に載せる項目は発生日時・影響範囲・対応状況・次回報告予定の4点

第一報で欲張って原因まで書こうとすると、提出が遅れるうえ、推測の原因が後で覆って信用を落とします。載せるのは次の項目です。

• 発生日時（検知した時刻と、分かれば実際に発生した時刻）
• 影響範囲（止まっている機能、影響している利用者や拠点、件数の概算）
• 現在の対応状況（調査中・切り戻し中・回避策の案内など）
• 次回の報告予定時刻
• 利用者側で取れる回避策（あれば）

上の4つは必須の記載事項で、回避策を添えるのは分かっている場合だけです。件数が確定していなければ「約2,000件（調査中）」のように概算と確定前である旨を並べて書きます。総務省の第一報の記入例も、影響利用者数を「約○万（詳細調査中）」、原因を「○○の不具合と推定」と書いており、確定していないことを隠さない書き方が基準になっています。

最終報告書の記載項目一覧と、総務省様式第50の3が求める記載の粒度

最終報告の項目は、総務省が詳細報告に求める記載内容を、一般のシステム向けに読み替えると過不足がありません。

一般の報告書で抜けやすいのは、最後の「関連する事故の発生傾向」です。同じ原因の障害が過去にあったかを書く欄で、ここが埋まると、前回の再発防止策がなぜ効かなかったのかという問いに自然に進めます。様式第50の3の記載例はPDFとWordで公開されており、書式の下敷きにそのまま使えます。

時系列は検知・判断・措置・連絡を分けて分単位で書き、対応者を残す方法

時系列は報告書の中でいちばん読まれる部分です。総務省の様式も「事故発生から収束までに行った措置を、対応者を含め、時系列で詳細に記載する」と求めています。書くときは、出来事を次の4種類に分け、どれに当たるかが読み手に分かるようにします。

1. 検知：監視のアラート、利用者からの問い合わせなど、障害に気づいたきっかけ
2. 判断：切り戻すか、原因調査を続けるかなど、誰が何を決めたか
3. 措置：再起動、設定の戻し、データの修正など、実際に行った操作
4. 連絡：発注者や利用者への第一報、ホームページへの掲載など

時刻は分単位で、根拠になったログやチャットの時刻に合わせます。「10:15頃」と「10:23」が混在すると、どこで時間を失ったかが読めません。発生から検知までに40分かかった、検知から切り戻しの判断までに1時間かかった、という空白が見えれば、再発防止策は自然に「監視の閾値」や「切り戻しの判断権限」に向かいます。

障害報告書の原因と再発防止策を、直接原因と拡大原因・管理工程に分けて書く手順

発生原因と、影響が大規模化・長時間化した原因を分けて書く理由

原因の欄に「設定ファイルの記述誤り」とだけ書くと、読み手には「担当者が間違えた」としか伝わりません。総務省の様式は、発生原因に加えて「事故が大規模化・長時間化した原因」を書くよう求め、それを設計、工事、維持・運用という管理工程ごとに記載するとしています。

一般のシステムなら、工程を「設計・開発」「テスト・リリース」「監視・運用」に置き換えると書きやすくなります。たとえば、設定の誤りは開発工程の問題、それがレビューを通ったのはリリース工程の問題、検知に40分かかったのは監視の問題、というように分けて捉える考え方です。原因の掘り方そのものはなぜなぜ分析のやり方と向かない場面、要因を工程や4Mで漏れなく洗い出す方法は特性要因図の書き方と4M・5Mの分け方で解説しています。

暫定対処と恒久対処を実施時期つきで書き、教育の徹底で終わらせない基準

再発防止策は、暫定対処と恒久対処に分けて、それぞれに完了日か完了予定日を付けます。暫定対処は「同じ操作をしても障害にならない状態を、今日すぐ作る措置」、恒久対処は「その操作自体が通らない仕組みに変える措置」です。

判断の基準は単純です。対策の主語が人なら暫定対処、主語が仕組みなら恒久対処と見なします。「手順書を見直し、担当者に周知した」は人が主語なので、恒久対処の欄には書けません。「本番環境への設定反映を、レビュー承認のないプルリクエストから実行できないようにした（11月20日完了）」のように、操作が通らなくなったことと日付が書けて初めて恒久対処です。

恒久対処の完了が数か月先になるなら、その期間をどう守るかを暫定対処で埋めます。予定日だけが並ぶ報告書は、次の障害の時点で「まだ終わっていなかった」と判明しがちです。

個人名と責める表現を書かず、操作が通った仕組みとして原因を記述する方法

外部に出す報告書に「担当者Aが誤ってコマンドを実行した」と書いても、読み手の不安は減りません。Google SRE本のPostmortem Cultureの章は、非難しないポストモーテムを「個人やチームを責めず、インシデントの寄与要因の特定に焦点を当てるもの」と定義しています。社外向けの報告書でも同じ書き方が通用します。

次の記述は、個人の操作から仕組みへ焦点を移す書き換えの例です。「担当者が本番環境と検証環境を取り違えた」は、「本番と検証の接続先が同じ画面から選べ、表示上の区別が色だけだったため、取り違えた操作がそのまま実行された」と書きます。後者なら、再発防止策が「接続先の確認ダイアログ」や「本番の権限分離」に向かい、発注者も何が変わるのかを判断できます。

そのまま使える障害報告書のテンプレートと、第一報・最終報告の例文

第一報メールのテンプレートと、受注側から発注者へ送る際の記載例文

第一報はメールかチャットで十分です。件名だけで重大度と状況が分かるようにします。

件名：【障害第一報・重大度2】受注管理システムの受注登録画面でエラー発生（11/14 10:05検知）

○○株式会社 情報システム部 ○○様

受注管理システムで障害が発生しています。現時点で判明している内容をお知らせします。

1. 発生日時：2026年11月14日 10:05 検知（発生は09:58頃と推定・調査中）
2. 影響範囲：受注登録画面で保存時にエラー。約120件の登録が未完了（概算・調査中）
   受注照会・出荷指示の画面は通常どおり利用できます
3. 対応状況：10:20に前日リリース分の切り戻しを決定し、作業中です
4. 回避策：急ぎの受注は紙の受注票で控え、復旧後に登録をお願いします
5. 次回報告：11:00までに復旧見込みをご連絡します

原因は調査中のため、最終報告でご説明します。

この例文は、原因に一言も触れていない点が肝心です。「前日のリリースが原因と思われます」と書きたくなりますが、切り戻しても直らなかった場合に説明が二転します。切り戻しの決定は「対応状況」として事実で書き、原因の推定は中間報告以降に回します。

最終報告書のテンプレートと、原因・再発防止策の欄に具体的に書く例文

最終報告は、前述の項目を見出しにした書式を用意しておくと、毎回の作成時間が半分以下になります。

システム障害報告書（最終報告）

1. 概要：2026年11月14日、受注登録画面で保存エラーが発生し、09:58〜11:12の74分間、受注登録ができませんでした
2. 発生・検知・復旧：発生 09:58 ／ 検知 10:05 ／ 復旧 11:12
3. 影響：未登録の受注 118件（全件を11月14日中に代行登録済み）。データの消失・漏えいはありません
4. 時系列：別紙1（検知・判断・措置・連絡を分単位で記載）
5. 発生原因：11月13日のリリースで追加した入力チェックが、旧形式の得意先コードを不正と判定した
6. 影響が広がった原因：
   (1) テスト工程：テストデータに旧形式の得意先コードが含まれていなかった
   (2) 運用工程：エラー率の監視閾値が高く、検知まで7分を要した
7. 再発防止策：
   暫定対処：旧形式コードを許可する修正を適用（11月14日完了）
   恒久対処：本番の得意先マスタから抽出したテストデータを回帰テストに追加（11月28日完了予定）
   恒久対処：保存エラー率の監視閾値を5%から1%へ変更（11月18日完了予定）
8. 過去の同種障害：2025年6月に得意先コード形式に起因する障害1件。今回と同じテストデータの不足が要因
9. 問い合わせ・周知：問い合わせ 14件。11月14日10:30に社内ポータルへ掲載

8番の「過去の同種障害」に該当があった場合は、前回の再発防止策がなぜ今回を防げなかったかを一文添えます。この例で書くべき内容は、前回はコード形式の修正だけで、テストデータの見直しまで手が回っていなかったという経緯です。この一文がある報告書は、受け取った側が「同じ説明の繰り返しではない」と判断できます。

運用保守契約とSLA別紙に書いておく障害報告の期限・様式・承認者のルール

障害の重大度ごとに第一報の期限と報告先、最終報告の提出日数を決める表

報告のルールは、障害が起きる前に発注者と受託者で合意しておくものです。決めるのは重大度の定義、第一報の期限と相手、最終報告の要否と提出日数の3つで、表1枚にまとまります。

表の数字は、社内業務システムを想定した目安です。夜間・休日に第一報を求めるなら、受託側に待機体制の費用が発生するので、保守料金と合わせて決めます。重大度1の定義に「データ消失」を入れておくと、影響した件数が少なくても最終報告まで必ず書かれるようになります。

報告様式と承認者を保守契約書の別紙に入れ、提出物として定義する方法

期限だけを決めても、報告書の中身が担当者ごとにばらつけば意味がありません。前章の最終報告の見出しを報告様式として保守契約書の別紙に入れ、「最終報告は様式に従い、受託者の責任者の承認を経て提出する」と書いておきます。承認者を決めておくと、現場の担当者が書いた原因の記述が、責任者の目を通らずに発注者へ届くことを防げます。

報告期限の未達をSLAの評価対象に含めるかも、このとき決めます。応答時間や復旧目標の書き方はSLAに書く項目と未達時のサービスクレジット、保守契約書のどこに対応水準を書くかはシステム保守契約書の条項と準委任・請負の違いで整理しています。

個人データの漏えいを伴う障害は委員会への速報3〜5日・確報30日が別に走る

障害の中で個人データが漏えいした、または漏えいのおそれがある場合は、発注者への報告とは別に、法律上の報告期限が動き始めます。個人情報保護委員会の漏えい等の対応とお役立ち資料のページは、要配慮個人情報、財産的被害のおそれ、不正の目的によるおそれ、本人の数が1,000人超の4類型に当たる場合、発覚日から3〜5日以内に速報、30日以内（不正の目的によるおそれがある場合は60日以内）に確報を出すよう案内しています（2026年11月時点）。

委員会へ報告する義務を負うのは、多くの場合データを預けている発注者側です。受託者が漏えいの事実を報告書に書くまで1週間かかれば、発注者は速報の期限を守れません。保守契約には「個人データの漏えい等のおそれを知った時点で、重大度に関係なく直ちに第一報を入れる」と別建てで書いておきます。報告の要否の判断と様式は個人情報保護委員会への報告義務と対象4類型で解説しています。

障害報告書を省略してよい障害の線引きと、報告が形骸化する失敗パターン

個別の報告書を作らず月次報告にまとめてよい軽微な障害の3つの条件

すべての障害に最終報告書を求めると、受託側は報告書づくりに工数を取られ、肝心の恒久対処が遅れます。次の3つをすべて満たす障害は、個別の報告書を作らず、月次の運用報告に件数と概要を載せるだけで足ります。

• 業務の停止がなく、利用者が回避策なしで作業を続けられた
• データの消失・誤更新・漏えいがない
• 過去3か月に同じ原因の障害が起きていない

3つ目の条件が外れたら、影響が小さくても最終報告書を求めます。同じ原因で小さな障害が繰り返されるのは、恒久対処が打たれていない兆候だからです。

報告書が毎回提出されても同じ障害が再発する失敗パターンと見直しの手順

報告書は期限どおりに届くのに、障害が減らない。この状態の多くは、恒久対処の完了を誰も確かめていないことが原因です。最終報告に「11月28日完了予定」と書かれたまま、完了の報告が来ないまま次の障害が起きます。

見直しは、まず過去1年分の障害報告書から恒久対処の行を抜き出し、完了日が入っているかを一覧にすることから始めます。完了日の無い行が半分を超えるなら、見直すべき対象は報告書の書き方ではなく保守体制そのものです。月次の定例で恒久対処の進捗を毎回確認する運用に変えても改善しない場合は、委託先の見直しも視野に入ります。一創の保守運用・内製化支援では、既存システムの保守の引き継ぎから、障害対応と報告の運用設計、社内で保守できる体制づくりまでを支援しています。

よくある質問

障害報告書について、発注者・受託者の双方からよく寄せられる質問をまとめました。

障害報告書とインシデント報告書は何が違いますか？

対象の広さが違います。インシデント報告書は、システム障害に加えて情報漏えい、誤送信、顧客トラブル、ヒヤリハットまで含めた出来事全般を記録する文書として使われることが一般的です。障害報告書は、そのうちシステムの停止や機能の不具合に絞った報告書を指します。社内で呼び名が混在している場合は、対象の範囲と様式を1つに決め、どちらの名前でも同じ書式で書けるようにしておくと混乱が起きません。

障害報告書は誰が書いて、誰に提出するものですか？

運用保守を委託している場合、書くのは受託側の担当者で、受託側の責任者が承認してから発注者の窓口に提出するのが一般的です。発注者の窓口は、その内容を要約して社内の経営層や業務部門に報告します。社内で運用しているシステムなら、作成から提出までの流れは、情報システム部門の担当者による作成、部門長の承認、経営層への提出という順序です。誰が承認するかを事前に決めておかないと、原因の記述が確認されないまま社外に出る事故が起きます。

原因が分からないまま最終報告の期限が来たらどうすればよいですか？

期限どおりに「原因調査中」と明記した報告書を出し、調査の進め方と次回の報告日を書きます。判明している事実、否定できた原因の候補、追加で取得しているログなどを並べれば、受け取る側は調査が止まっていないことを確認できます。推測の原因を確定したかのように書くのは避けてください。後で原因が変わると、報告書全体の信用が失われます。原因が確定した時点で、改めて最終報告を提出します。

障害報告書にお詫びの文章は必要ですか？

外部の顧客や取引先に出す報告書では、冒頭か末尾に短いお詫びを入れるのが一般的です。ただし本文は事実と対策に絞り、お詫びの言葉を原因や対策の欄に混ぜないようにします。「多大なるご迷惑」といった定型句を重ねるより、影響した件数と回復の状況を正確に書く方が、読み手に誠実さを伝えられる記述です。社内向けや保守契約に基づく報告では、お詫びは1文あれば十分で、時系列と再発防止策の具体さに紙面を割きます。

障害報告書の保管期間はどのくらいにすればよいですか？

法令で一律に決まった期間はないため、少なくとも保守契約の期間中と、終了後の引き継ぎが終わるまでは保管します。過去の同種障害を報告書に書くには、数年分の記録が検索できる状態で残っている必要があります。契約期間が3年なら、障害報告書もその3年分を委託先の切り替え時に受け取る文書として契約で定めておくと、次の委託先が同じ原因の障害を見落としません。

関連記事

• システム運用保守ドキュメントの整備手順｜優先順位と更新が止まらない仕組み：障害報告の前提になる障害対応フローと運用手順書の整え方です。
• インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説【2026年版】：重大度の決め方と、検知から復旧までのプロセス全体を扱っています。
• システム運用保守の会社はどう選ぶ？相見積りを比較できる形に揃える手順と契約前の確認点：報告ルールを含めて保守の委託先を比較する手順です。
• ポストモーテムとは？書き方とテンプレート、非難しない運用をGitHubで仕組みにする方法：障害報告書の元になる社内向けの原因分析の書き方です。