障害報告書の書き方とテンプレート｜社内向け・顧客向けの例文つき

障害が収まったあと、上司や顧客に出す障害報告書を何から書けばよいか迷う人に向けた記事です。項目の並びだけでなく、時系列・原因・影響範囲・再発防止策をそれぞれどう書けば伝わるかを、悪い例と良い例で説明します。最後に社内向けと顧客向けの雛形を載せているので、コピーして使ってください。

障害報告書とは

障害報告書はシステムの障害について「何が起き、誰にどんな影響があり、なぜ起きて、どう直し、今後どう防ぐか」をまとめた文書です。読み手は大きく 2 種類に分かれます。

• 社内: 経営者、上司、営業やサポート、ほかの開発者。次に同じことを起こさないための判断材料として読みます
• 顧客: 取引先の担当者や、サービスの利用者。自分にどんな影響があったか、もう安心してよいかを知るために読みます

同じ障害でも、読み手が違えば書く内容と書き方が変わります。1 つの報告書で両方に応えようとすると、顧客には細かすぎ、社内には情報が足りない文書になりがちです。社内向けを先に書き、そこから顧客向けを作るのがおすすめです。

障害の振り返りを文書にしたものは「ポストモーテム」とも呼ばれます。ポストモーテムは社内で学ぶための文書で、障害報告書は報告や説明のための文書という違いがあります。小さな会社では同じ文書を兼ねることも多いので、違いは ポストモーテムとは で詳しく説明します。

第一報・中間報告・最終報告の 3 段階

障害報告書を 1 回で完璧に仕上げようとすると、出すのが遅くなります。原因の調査に何日もかかることがあるからです。報告は次の 3 段階に分けて出します。

第一報と中間報告は、障害の最中の連絡そのものです。書き方は 障害対応のフロー の連絡の節で、テンプレートと一緒に説明しています。この記事は主に最終報告の書き方を扱います。

軽い障害なら中間報告を省き、第一報のあと最終報告を出すだけで構いません。顧客との契約や SLA (サービス品質の取り決め) で報告の期限が決まっている場合は、その期限を優先します。

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

違いを表にまとめます。

社内向けで個人名を避けるのは、責任を曖昧にするためではありません。「担当者の確認不足」で終わる報告書は、次に同じ作業をする別の人を守れないからです。人が間違えうる作業を、間違えても止まる仕組みに変えるのが報告書の目的です。

障害報告書に書く項目

最終報告には次の項目を書きます。この順で並べると、読み手が知りたい順になります。

1. 概要 (3〜5 行で全体が分かる要約)
2. 発生日時と復旧日時
3. 影響範囲
4. 時系列
5. 原因
6. 対応の内容 (暫定対処と恒久対処)
7. 再発防止策
8. 今回の対応でうまくいったこと、うまくいかなかったこと (社内向けのみ)

以下、書き方に迷いやすい項目を順に説明します。

概要は最後に書いて最初に置く

概要は、忙しい経営者や顧客が 30 秒で読めるように書きます。ほかの項目を書き終えてから、その要点を集めて書くと楽です。

次は悪い例です。

10月28日にシステム障害が発生しました。現在は復旧しています。
原因はデータベースの問題でした。今後は再発防止に努めます。

次は良い例です。

10月28日 10:35〜11:52 の 77 分間、注文の確定処理の一部が失敗しました。
影響は 214 件の注文、183 名のお客さまです。
10:30 のリリースで追加したデータベースの変更が、注文テーブルの更新を待たせたことが原因です。
11:52 にリリースを戻して復旧し、失敗した注文は 10月29日までにすべてお客さまへご連絡しました。
今後、データベースの変更は本番と同じ量のデータで事前に試験してからリリースします。

良い例は「いつ・何が・どれだけ・なぜ・どう直したか・今後どうするか」が 5 行に収まっています。悪い例の「データベースの問題」「再発防止に努めます」は、読み手が何も判断できない書き方です。

発生日時と復旧日時

日時は「発生」「検知」「復旧」を分けて書きます。発生は異常が最初に出た時刻で、検知は誰かが気づいた時刻です。この 2 つの差が大きいほど、監視に改善の余地があります。

発生: 2026年10月28日 10:35 (JST)
検知: 2026年10月28日 10:42 (監視アラート)
復旧: 2026年10月28日 11:52
影響時間: 77 分

海外の拠点や海外のクラウドのログが混ざる場合は、タイムゾーンを書きます。クラウドの管理画面やログは UTC で表示されることがあり、9 時間ずれた時刻が混ざる間違いがよく起きます。

影響範囲は数字で書く

影響範囲は「一部のお客さま」ではなく、件数で書きます。数字があると、障害の大きさを読み手が自分で判断できます。数えるべきものは次のようなものです。

• 影響を受けたユーザー数、企業数
• 失敗した処理の件数 (注文、決済、送信、バッチ)
• エラーになったリクエストの割合
• 遅延した時間、止まっていた時間
• 金額 (売上の機会損失、返金、補償)
• データの欠損や不整合の有無と件数

件数はデータベースから数えるのが確実です。たとえば、障害の時間帯に失敗した注文と、その注文をしたユーザーの数は、次のような SQL で出せます。テーブル名、列名、状態の値は自社のものに置き換えてください。

-- PostgreSQL の例: 障害の時間帯に失敗した注文と、影響を受けたユーザーの数
SELECT count(*)                AS failed_orders,
       count(DISTINCT user_id) AS affected_users,
       sum(amount)             AS failed_amount
FROM orders
WHERE status = 'failed'
  AND created_at >= '2026-10-28 10:35:00+09'
  AND created_at <  '2026-10-28 11:52:00+09';

ふだんでも一定の割合で失敗する処理なら、前の週の同じ曜日・同じ時間帯の件数も数えて、差を影響として書きます。そのまま全件を影響に数えると、障害を大きく見積もってしまいます。

まだ数えきれていない項目は「確認中」と書き、確定した値と分けます。推測の数字を確定値のように書くと、あとで訂正したときに報告書全体が信用されなくなります。

時系列は「事実」と「判断」を分ける

時系列は起きたこと、気づいたこと、判断したこと、行ったことを時刻順に並べます。対応中に記録したチャットのログがあれば、そこから拾います。

10:30  リリース v2.14.0 を本番に反映 (orders テーブルへのインデックス追加を含む)
10:35  注文確定 API でタイムアウトが出始める (後のログ調査で判明)
10:42  監視アラート「注文 API の 5xx 増加」が発報。山田が障害を宣言
10:48  DB で orders テーブルへの更新がロック待ちになっていることを確認
10:55  ステータスページで顧客に告知
11:05  リリースを戻すと判断。インデックスの作成が終わっていないため、先に作成処理を止める
11:40  インデックス作成を中止
11:52  リリースの切り戻しが完了。注文の成功率がふだんの水準に戻る
12:30  1 時間エラーが出ないことを確認し、収束を宣言

10:35 の行のように、あとで分かったことには「後の調査で判明」と書き添えます。対応中に知っていたことと、あとから分かったことが混ざると、「なぜその時点でそう判断したのか」が読み取れなくなります。

判断の行 (11:05) には理由も書きます。振り返りで「なぜもっと早く戻さなかったのか」を議論するとき、その時点で何が分かっていて何が分かっていなかったかが材料になります。

原因は 3 つに分けて書く

原因の書き方でよくある失敗は、きっかけだけを書いて終えることです。原因は次の 3 つに分けて書きます。

Google の『Site Reliability Engineering』に載っている障害報告の例でも、根本原因 (Root Causes) ときっかけ (Trigger) を別の項目にしています。きっかけは「何がスイッチを押したか」で、根本原因は「なぜスイッチ 1 つで障害になる状態だったか」です。再発防止策は根本原因に対して立てるので、ここが曖昧だと対策も曖昧になります。

悪い例と良い例を並べます。

悪い例:
原因は、担当者がインデックス追加の影響を十分に確認しないままリリースしたことです。

良い例:
インデックスの追加に、作成中は orders テーブルへの書き込みを待たせる方法を使っていました。
開発環境のデータは約 1 万件で数秒で終わったため、本番の約 800 万件で
作成に 1 時間以上かかり、その間の書き込みが待たされることを事前に把握できませんでした。
リリース前のレビューに、DB の変更が本番のデータ量でどれだけかかるかを確かめる項目がありませんでした。

悪い例は原因を人に置いています。良い例は、同じ状況なら誰がリリースしても起きたことが分かり、「レビューの項目を足す」という対策につながります。

原因がまだ分からない場合は、分からないと書きます。「調査を続けており、○月○日までに追加で報告します」と期限をつければ、報告書を出さないまま待たせるより信頼を損ねません。

対応の内容

暫定対処と恒久対処を分けて書きます。暫定対処はサービスを戻すためにその場で行ったこと (リリースの切り戻し、処理の停止など) です。恒久対処は原因そのものを取り除いた修正です。障害のあとに行ったデータの修正 (失敗した注文の再処理、二重に処理されたデータの取り消し) も、ここに書きます。顧客に一番関係するのはこの部分であることが多いからです。

再発防止策は担当・期限・状態つきの表にする

再発防止策は、表で書くと抜けが出にくくなります。SRE 本の例では対策ごとに種類、担当者、課題管理の番号を書いています。小さなチームなら次の列で十分です。

種類を「予防」「検知の短縮」「復旧の短縮」に分けると、対策が予防だけに偏っていないかが見えます。障害を完全に防ぐことはできないので、早く気づき早く戻す対策も同じくらい役に立ちます。

再発防止策では次の書き方を避けます。

左の列の書き方には、終わったかどうかを判定する基準がありません。右の列のように、やり終えたかどうかを誰でも確かめられる形にします。

対策は報告書を出したら終わりではありません。期限の日に状態を確かめる人を決めておくと、報告書に書いたまま放置される対策が減ります。

個人情報の漏えいの可能性がある場合

障害の中で個人情報が漏れた、または漏れたおそれがある場合は、社内と顧客への報告とは別に、個人情報保護委員会への報告が必要になることがあります。委員会の案内では民間の事業者について次の 4 つのどれかに当たる場合を報告の対象としています。

• 要配慮個人情報 (病歴など) が含まれる
• クレジットカード番号など、不正に使われると財産的な被害が生じるおそれがある
• 不正アクセスなど、不正の目的によるおそれがある
• 本人の数が 1,000 人を超える

報告は気づいてから 3〜5 日以内を目安とする速報と、30 日以内 (不正の目的によるおそれがある場合は 60 日以内) の確報の 2 段階です。設定の誤りでデータが別の顧客から見えていた、といったシステム障害でも当てはまることがあります。迷ったら、早めに委員会のページを確かめ、社内の法務や経営者に相談してください。

社内向けの雛形

# 障害報告書: 注文の確定処理の一部失敗 (2026-10-28)

- 作成者: 山田 / 作成日: 2026-10-31 / 状態: 最終報告
- 重大度: SEV1

## 概要
(3〜5 行。いつ・何が・どれだけ・なぜ・どう直したか・今後どうするか)

## 日時
- 発生: 2026-10-28 10:35 (JST)
- 検知: 2026-10-28 10:42 (監視アラート / 顧客の問い合わせ / 社内の報告)
- 復旧: 2026-10-28 11:52
- 影響時間: 77 分

## 影響範囲
- 失敗した注文: 214 件 (前週同時間帯の失敗 3 件を差し引いた数)
- 影響を受けたユーザー: 183 名
- 金額: 約 xxx 円 (再注文で回復した分を除く)
- データの不整合: なし (確認方法: xxx)

## 時系列
| 時刻 | 出来事 |
| --- | --- |
| 10:30 | ... |

## 原因
- きっかけ:
- 根本原因:
- 検知・対応が遅れた理由:

## 対応の内容
- 暫定対処:
- 恒久対処:
- データの修正と顧客への連絡:

## 再発防止策
| 対策 | 種類 | 担当 | 期限 | 状態 |
| --- | --- | --- | --- | --- |

## うまくいったこと / うまくいかなかったこと / 運がよかったこと
-

## 関連資料
- 対応中のチャットのログ、グラフ、関連するチケット

最後の「運がよかったこと」は、SRE 本の例にある項目です。「たまたま詳しい人が社内にいた」「深夜ではなかった」のように、運で被害が小さく済んだ点を書いておくと、次に運が悪かったときの穴が見えます。

顧客向けの雛形

件名: 【ご報告】10月28日に発生したご注文の確定処理の障害について

いつも〇〇をご利用いただき、ありがとうございます。
2026年10月28日に、ご注文の確定処理の一部が失敗する障害が発生しました。
ご迷惑をおかけしましたことを、深くお詫び申し上げます。
原因と今後の対策がまとまりましたので、ご報告いたします。

1. 発生日時
   2026年10月28日 10時35分 〜 11時52分 (77分間)

2. 影響
   上記の時間帯に、ご注文の確定時にエラーが表示され、ご注文が確定しない場合がありました。
   対象のお客さまには、10月29日までに個別にご連絡しております。
   エラーとなったご注文で代金が請求されることはありません。

3. 原因
   同日 10時30分に行ったシステムの更新で、注文データの書き込みが一時的に待たされる状態になったことが原因です。
   更新を元に戻し、11時52分に復旧しました。

4. 今後の対策
   ・データベースに関わる更新は、本番と同じ規模のデータで所要時間を確かめてからリリースします。
   ・同様の事象が起きた際に、より早く検知して元に戻せるよう、監視と手順を見直しました。

今後このようなことが起きないよう努めてまいります。
ご不明な点は、サポート窓口 (support@example.com) までお問い合わせください。

顧客向けでは、「代金が請求されることはありません」のように顧客が一番気にする点に答える一文を入れます。ただし、確かめた事実だけを書きます。対策は社内向けの表から顧客にとって意味のあるものを選び、「何を変えたか」が伝わる言い方にします。

提出前のチェックリスト

書き終えたら、出す前に次の点を確かめます。

• 概要だけ読んで、何が起きてどうなったかが分かるか
• 発生・検知・復旧の時刻が分かれていて、タイムゾーンがそろっているか
• 影響が件数で書かれ、確定値と確認中の値が区別されているか
• 原因が人ではなく、作業の仕組みや手順に置かれているか
• 再発防止策のすべてに担当と期限があり、終わったかどうかを判定できる書き方か
• 顧客向けに、社内の人名、内部のシステム名、未確定の推測が入っていないか
• 個人情報の漏えいに当たる可能性を確かめたか

影響範囲を早く数えるには

報告書で一番時間がかかるのは、影響範囲の数字を集める作業です。注文数、決済の失敗、ジョブの滞留のような数字を、ふだんから SQL で定期的に数えて記録しておくと、障害のときに「いつから、どれだけ」をすぐ答えられます。cron で集計を回して表に残す、監視ツールのダッシュボードに出しておく、といった方法があります。

この作業を AI に任せる方法もあります。Scandock は、データベースの接続文字列を登録すると、AI がテーブルの構成と実データを読み、事業の中心にある数字の監視項目を決めます。異常と判断すると読み取り専用のクエリで関連するデータを調べ、原因・影響・根拠・対処案をつけて通知し、実行したクエリと結果が残ります。報告書の時系列や影響範囲を書くときの材料として使えます。

参考

• Example Postmortem (Site Reliability Engineering, Google)
• Postmortem Culture: Learning from Failure (Site Reliability Engineering, Google)
• 漏えい等の対応とお役立ち資料 (個人情報保護委員会)