【無料テンプレート】顧客提出用の障害報告書の書き方 — 記載項目と例文

公開: 2026-08-05 / 最終更新: 2026-08-06

B2Bのサービスで障害を起こすと、高い確率で顧客の情報システム部門から「障害報告書を提出してください」と依頼が来ます。復旧対応が終わって疲れ切ったタイミングで、白紙のWordに向かうのはつらい作業です。

この記事では、そのまま使える顧客提出用の障害報告書テンプレート(本文中に全文掲載、Word/Markdown形式のダウンロードも可)と、各項目の書き方、提出前にチェックすべきNGパターンをまとめました。読み手である「顧客の情シス担当者」が何を見ているかを軸に解説します。

障害報告書の目的と提出タイミング

報告書の読み手には「その先の読み手」がいる

顧客の情シス担当者が障害報告書を求めるのは、多くの場合、自社内への説明義務があるからです。担当者は受け取った報告書をもとに、上長や利用部門へ「原因は◯◯で、再発防止策はこう。継続利用に問題なし」と報告します。

つまり障害報告書は、担当者がそのまま社内報告に流用できる品質になっているのが理想です。逆に、時系列が曖昧だったり原因の説明が専門用語だらけだったりすると、担当者は社内向けに翻訳・補筆する手間を負うことになり、「これでは報告できません」と差し戻される原因になります。

提出タイミングの目安は「1週間以内」

障害報告書は正確さが求められる文書ですが、時間をかけすぎるのも悪手です。提出が遅れるほど「対応がずさんなのでは」という印象を与えます。

恒久対策がまだ確定していない場合は、「恒久対策の詳細は◯月◯日までに追補いたします」と明記して一次版を先に提出する方が、完成を待って遅れるより印象は良くなります。報告書は一発勝負の完成品ではなく、誠実に更新していく文書と捉えてください。

なお、障害発生中の第一報や復旧報告の文面については、別記事システム障害の「お詫びとご報告」例文集 — 発生時・経過・復旧後の3段階で例文付きで解説しています。

障害報告書の必須8項目

顧客提出用の障害報告書に最低限必要なのは、次の8項目です。A4で1〜2枚に収まる分量が目安です。

1. 件名 — どのサービスの何の障害か一読で分かるように
2. 発生日時・検知日時・復旧日時 — 3つの時刻を区別する
3. 影響範囲 — 誰が・何を・どの程度
4. 事象の概要 — 何が起きたかを事実のみで
5. 対応の時系列 — 検知から復旧宣言までのタイムライン
6. 原因 — 直接原因と背景要因を分ける
7. 暫定対応 — その場で何をして復旧させたか
8. 恒久対策・再発防止策 — 具体的な対策と実施予定日

以下、つまずきやすい項目を順に解説します。

発生日時・検知日時・復旧日時は必ず分ける

よくあるミスが、発生時刻と検知時刻の混同です。「10:00に監視アラートで検知した」とき、事象そのものは9:52から始まっていた、ということは珍しくありません。情シス担当者はこの差分(検知までのリードタイム)を見て、監視体制の成熟度を判断します。

検知方法(監視アラートか、顧客からの申し出か)も書きます。「顧客からの問い合わせで発覚」の場合は正直に書いた上で、再発防止策に監視項目の追加を含めると筋が通ります。

影響範囲は「誰が・何を・どの程度」で定量化する

「一部のお客様に影響が発生しました」だけの報告書は、ほぼ確実に「一部とは何割ですか」と質問が返ってきます。最初から定量的に書きます。

影響範囲: クレジットカード決済機能。障害期間中の決済リクエストのうち約12%(214件)がエラーとなりました。エラーとなった決済は課金されておらず、二重決済は発生していません。データの毀損・漏えいはありません。

データ毀損・情報漏えいの有無は、影響がなくても「ない」と明記してください。書いていないと必ず確認の往復が発生します。

対応の時系列は「報告書の背骨」

情シス担当者が最も注意深く読むのがこの欄です。検知から復旧までの対応が時刻付きで並んでいれば、「この会社は障害時に統制の取れた対応ができる」という何よりの証明になります。

ここで効いてくるのが「対応しながら記録していたか」です。復旧後に記憶とチャットログから時系列を復元するのは骨が折れる上、抜けが出ます。障害対応の経過をステータスページ等に随時記録していれば、その記録がそのまま時系列欄になります。

原因は「直接原因」と「背景要因」を分ける

原因: 直接原因は、決済処理サーバーの設定変更に伴う接続先の不整合です。背景として、当該設定変更の事前検証手順に接続確認の項目が含まれていませんでした。

直接原因だけで終わると「では、なぜそれが起きたのか」という疑問が残ります。背景要因(検証手順の不備、レビュー体制など)まで一段掘ると、次の再発防止策が自然につながり、報告書全体の説得力が上がります。ただし顧客向け文書で「担当者のミス」のような個人の特定につながる書き方は避け、仕組みの問題として記述します。

再発防止策は「対策 × 実施予定日」のセットで

「再発防止に努めます」「教育を徹底します」といった精神論は、情シス担当者が最も評価しない書き方です。検証可能な行動と期日で書きます。

「実施済み」の項目を1つでも入れられると、対応の速さが伝わります。

そのまま使える障害報告書テンプレート

上記8項目を反映したひな型の全文です。【 】を自社の情報に差し替えてご利用ください(Word/Markdown形式のダウンロードは記事末尾)。

【YYYY年MM月DD日】

【宛先会社名】 御中

【会社名】 【部署名・役職・氏名】

障害報告書

■ 件名 【例: 【サービス名】決済機能における処理エラー障害のご報告】

■ 発生日時・復旧日時 発生日時: 【YYYY年MM月DD日 HH:MM】 検知日時: 【YYYY年MM月DD日 HH:MM】(検知方法: 【監視アラート / お客様からのお申し出 等】) 復旧日時: 【YYYY年MM月DD日 HH:MM】 影響時間: 【◯時間◯分】

■ 影響範囲 【対象機能・対象顧客の範囲・影響の程度を定量的に。データの毀損・漏えいの有無も明記】

■ 事象の概要 【何が起きたかを事実のみで簡潔に】

■ 対応の時系列 【時刻と対応内容の一覧表。検知〜体制発足〜告知〜原因特定〜暫定対応〜復旧宣言】

■ 原因 【直接原因と、必要に応じて背景要因を分けて記載】

■ 暫定対応 【復旧のためにその場で実施した措置】

■ 恒久対策・再発防止策 【対策と実施予定日の一覧表】

■ お詫び この度は、弊社サービスの障害により多大なご迷惑をおかけいたしましたことを、深くお詫び申し上げます。上記の再発防止策を確実に実施し、サービスの安定運用に努めてまいります。

本件に関するお問い合わせ: 【問い合わせ窓口】

以上

社内向けと顧客向けの違い

社内のポストモーテム(振り返り文書)をそのまま顧客に出すのはおすすめしません。目的が違うからです。

実務では、社内ポストモーテムを先に(または並行して)書き、そこから顧客向けに抽出・翻訳する流れが効率的です。逆順(顧客向けを先に書いて社内版を膨らませる)だと、社内の学びが顧客向けの当たり障りない表現に引きずられがちです。

突き返される報告書のNG例

情シス担当者に差し戻される報告書には共通パターンがあります。提出前のセルフチェックにどうぞ。

テンプレートのダウンロード(Word / Markdown)

この記事で解説した障害報告書ひな型を含む「システム障害の顧客連絡テンプレート集」を無料配布しています。収録内容は以下の5点+使い方メモです。

1. 第一報「お詫びとご報告」(原因調査中)
2. 経過報告(時系列様式)
3. 復旧報告
4. 緊急メンテナンスのお知らせ
5. 顧客提出用 障害報告書ひな型(本記事のテンプレート)

Word / Markdown形式で、【 】を差し替えればそのまま使えます。社内規定に合わせた調整・再配布も自由です。

入手方法: 現在開発中の国産ステータスページサービス「ステータスページJP」の事前登録特典として配布しています。メールアドレスの登録のみ(30秒・無料)で、登録直後にテンプレート集をお送りします。ツールを使わなくてもそのまま使える実用文書です。

テンプレート集を受け取る(無料・30秒)

なお、ステータスページJPでは、障害対応中に記録した経過がそのまま顧客提出用の障害報告書PDFになる機能を開発しています。「復旧後の転記作業」自体をなくしたい方は、サービス紹介ページもご覧ください。

関連記事

• システム障害の「お詫びとご報告」例文集 — 発生時・経過・復旧後の3段階 — 障害発生中に出す告知文(第一報・経過報告・復旧報告)の例文はこちら