障害報告書を作るプロンプト

障害対応が一段落した後、「報告書を書かないといけないが、時系列も原因も整理しきれていない」と感じたことはないでしょうか。障害対応そのものに追われた直後は、冷静に文書としてまとめる余力が残っていないことも多いはずです。

このプロンプトは、発生事象・原因・対応内容を伝えるだけで、AIに一般的な障害報告書の形式に整理させるものです。コピーしてそのままChatGPTやGeminiなどに貼り付けて使えます。

コピペ用プロンプト

以下のコードブロックの中身をそのままコピーして、AIチャットに貼り付けてください。【】で囲まれた部分はご自身の状況に合わせて書き換えてください。

あなたは経験豊富なSRE（サイト信頼性エンジニア）です。以下の情報をもとに、障害報告書を作成してください。

【発生事象（何が起きたか）】: 本番環境のAPIサーバーで応答遅延が発生し、一部リクエストがタイムアウトした
【発生日時・検知方法】: 2026年7月10日14時頃発生、監視ツールのアラートで検知
【原因（判明している範囲でよい）】: 直前にリリースしたバッチ処理が想定より大量のデータベース負荷をかけていたことが原因と推測される
【実施した対応・復旧までの流れ】: 14時15分に該当バッチ処理を停止、14時30分に応答速度が正常値に復旧を確認
【再発防止策（検討中でも可）】: バッチ処理実行前に負荷試験を必須化することを検討中

# 出力してほしい内容
一般的な障害報告書のフォーマットに沿って、以下の項目で文書を作成してください。
1. 概要（サマリー）
2. 発生事象の詳細
3. タイムライン（時系列での対応記録）
4. 原因
5. 対応内容
6. 影響範囲（記載がない場合は「要確認」として明記）
7. 再発防止策
8. 今後の課題

# 出力フォーマット
社内・関係者向けの報告書として、見出しごとに整理してください。

# 制約条件
- 記載されていない情報を推測で補完せず、不明な項目は「要確認」と明記する
- 特定の個人の責任を追及するような表現は避け、事実ベースで淡々と記述する

使い方3ステップ

上記プロンプト内の【発生事象】【発生日時・検知方法】【原因】【実施した対応・復旧までの流れ】【再発防止策】を、実際の障害内容に書き換えます。
ChatGPTやGeminiなどのAIチャットに貼り付けて送信します。
出力された報告書のドラフトを、実際のログや関係者へのヒアリング内容と照らし合わせて正確性を確認し、正式な報告書として仕上げます。

入力例と出力サンプル

入力例（事象を変更した場合）

【発生事象（何が起きたか）】: 会員登録メールが一部ユーザーに届かない不具合が発生した
【発生日時・検知方法】: 2026年7月8日、顧客からの問い合わせで発覚
【原因（判明している範囲でよい）】: メール送信サービスの送信上限に達し、一部メールが送信キューに滞留していた
【実施した対応・復旧までの流れ】: 送信上限プランをアップグレードし、滞留していたメールを再送信して解消
【再発防止策（検討中でも可）】: 送信数の監視アラートを設定することを検討中

出力サンプル（抜粋）

概要 2026年7月8日、会員登録メールの一部が届かない不具合が発生。顧客からの問い合わせにより発覚した。

原因メール送信サービスの送信上限に達し、一部メールが送信キューに滞留していたことが原因。

カスタマイズのコツ

顧客への影響があった場合は、「顧客向け説明文も別途作成して」と依頼すると、社内向け・対外向けを分けて生成できます。
障害の深刻度に応じたレベル分類（Sev1/Sev2等）を使っているチームは、制約条件にその基準を追記すると分類まで含めた報告書になります。
ポストモーテム（振り返り）文化のあるチームは、「Blameless（個人を責めない）な書き方を徹底して」と指定するとより適切なトーンになります。

注意点

障害報告書には社外秘の技術情報（サーバー構成、内部システム名等）が含まれることが多いため、AIサービスへの入力可否を事前に確認してください。
生成された報告書の原因・影響範囲の記載は仮説段階の場合があるため、正式な報告前に必ず技術的な裏付けを確認してください。
個人の実装ミスなど、特定の担当者を名指しで責めるような記述にならないよう、出力内容を確認してください。