責任追及で終わらせないインシデント振り返りプロンプト｜時系列・原因・再発防止策を整理する実務テンプレート
障害対応の記録、監視アラート、チャットログをAIへ渡せば、インシデント振り返りレポートの初稿を作れます。ただし「障害をまとめて」だけでは、事実と推測が混ざり、担当者個人に原因を寄せた文章になりがちです。
必要なのは、確認済みの事実、未確認事項、複数の寄与要因、再発防止アクションを分けて出力させる指示です。この記事では、開発・運用チームがそのまま使える汎用LLM向けテンプレートを紹介します。
この記事で分かることは次のとおりです。
- インシデント記録から振り返りレポートを作るプロンプト
- 入力前に用意する情報と、伏せるべき情報
- 責任追及や根拠のない原因断定を防ぐ方法
- 担当者と期限を含む再発防止策の出力方法
- 初稿を人が確認するときのチェックポイント
このプロンプトの用途と完成イメージ
このテンプレートの目的は、障害の犯人を決めることではなく、次の障害を防ぎ、発生時の影響を小さくすることです。
GoogleのSRE資料では、ポストモーテムをインシデント、その影響、対応、原因、再発防止のフォローアップを記録する文書と位置付けています。また、個人を責めず、当時得られた情報や仕組みに目を向けることを重視しています。Google SREの解説に沿えば、「誰がミスしたか」より「なぜその操作が可能だったか」「なぜ検知できなかったか」を掘り下げる必要があります。
想定する入力は、次のような一次情報です。
- 障害の発生日時、検知日時、復旧日時
- 監視アラートやメトリクス
- デプロイ、設定変更、操作の履歴
- インシデント対応中のチャットやチケット
- 利用者への影響と問い合わせ件数
- 暫定対応と恒久対応の候補
完成するレポートには、概要、影響、時系列、寄与要因、対応評価、再発防止策、未確認事項を含めます。経営層向けの要約と技術チーム向けの詳細を分ければ、同じ文書を関係者間の共通資料として使えます。
ここがポイント: AIには原因を発見させるのではなく、提供した証拠を整理させます。入力にない因果関係は「未確認」と明記させてください。
コピペ用プロンプトテンプレート
以下はChatGPT、Claude、Geminiなどの汎用LLMで使える形式です。サービスへ入力できる情報の範囲は、所属組織のセキュリティ規程と各サービスの利用条件を先に確認してください。
あなたは、システム運用とインシデント分析を支援する編集者です。
以下の記録を基に、責任追及を目的としないインシデント振り返りレポートの初稿を作成してください。
# 目的
- 発生した事象と利用者への影響を正確に共有する
- 検知、判断、復旧の流れから改善点を見つける
- 再発確率または再発時の影響を下げるアクションを決める
# 作成ルール
1. 入力にある事実と、推測・仮説を明確に分ける
2. 入力にない情報を補完しない。不明な点は「未確認」と書く
3. 個人の不注意を根本原因にしない
4. 人名は記載せず、{役割名の表記方法}で表す
5. 原因を単一要因に決めつけず、技術・プロセス・検知・情報共有の寄与要因を分ける
6. 時刻はすべて{タイムゾーン}のYYYY-MM-DD HH:MM形式に統一する
7. 同じ出来事について記録が矛盾する場合は、断定せず「記録の不一致」に列挙する
8. 機密情報、認証情報、個人情報が入力に含まれていた場合は本文へ転記せず、要マスキングと指摘する
9. 再発防止策には、優先度、担当する役割、期限、完了条件を付ける
10. レポートは日本語のMarkdownで出力する
# インシデント情報
- インシデント名: {名称}
- 対象サービス: {サービス名}
- 重要度: {重要度と判定基準}
- 発生日時: {日時または不明}
- 検知日時: {日時または不明}
- 復旧日時: {日時または不明}
- 影響を受けた対象: {利用者・機能・地域など}
- 影響規模: {件数・割合・時間。未集計なら未集計}
- 現在の状態: {復旧済み・監視中・調査中など}
# 記録
## 監視・メトリクス
{アラート、ログ、グラフから確認できる数値}
## 変更履歴
{デプロイ、設定変更、作業履歴}
## 対応履歴
{時刻付きの対応記録}
## 関係者からの確認事項
{確認済みの発言や判断理由}
## 既知の制約
{不足ログ、保存期間、アクセスできない記録など}
# 出力構成
## 1. エグゼクティブサマリー
非技術者にも分かるよう、何が起き、誰にどの程度影響し、現在どうなっているかを5文以内で記載する。
## 2. 影響
- 利用者への影響
- 業務への影響
- 影響時間
- 数値で確認できる範囲
数値がない場合は推定せず「未集計」とする。
## 3. タイムライン
「時刻 / 確認された事象 / 情報源 / 対応または判断」の順で箇条書きにする。
## 4. 技術的な経緯
発生から復旧までを、入力情報に基づいて説明する。
## 5. 寄与要因
次の区分ごとに、事実、仮説、追加確認方法を分ける。
- 直接の技術要因
- 影響を拡大した要因
- 検知が遅れた要因
- 復旧に時間を要した要因
- 組織・手順・情報共有上の要因
## 6. うまく機能したこと
検知、連携、判断、復旧作業のうち、記録から確認できる事項だけを書く。
## 7. 改善が必要なこと
個人ではなく、仕組み、手順、権限、監視、設計、連絡経路を対象にする。
## 8. 再発防止アクション
各項目を次の形式で書く。
- アクション:
- 対応する寄与要因:
- 優先度: 高・中・低
- 担当する役割:
- 期限:
- 完了条件:
- 効果の確認方法:
## 9. 未確認事項と追加質問
重要度の高い順に並べ、それぞれ「誰に何を確認するか」を示す。
## 10. 記録の不一致
矛盾する日時、数値、説明があれば併記する。なければ「確認された不一致なし」とする。
## 11. 情報品質チェック
- 根拠のない断定
- 出典のない数値
- 個人への責任帰属
- 機密情報または個人情報
- 担当・期限・完了条件がないアクション
を点検し、修正が必要な箇所を列挙する。
入力時に変える項目
最も重要なのは、日時と数値に情報源を添えることです。 同じ出来事でも、監視ログとチャットの投稿時刻は意味が異なります。
必ず変更する項目
{名称}：後から検索しやすい短い名前{サービス名}：影響を受けたシステムや機能{重要度と判定基準}：社内基準があれば併記{タイムゾーン}：JST、UTCなど{役割名の表記方法}：「当番担当者」「インシデント指揮者」など- 各種日時：推定時刻なら「推定」と明記
- 影響規模：実測値、推定値、未集計を区別
固定した方がよい条件
次の条件は案件ごとに変えず、チームの標準として残すと比較しやすくなります。
- 事実と仮説を分離する
- 人名を役割名へ置き換える
- 記録の矛盾を隠さない
- アクションに担当、期限、完了条件を付ける
- 入力にない情報を補完しない
AWS Incident Managerのポストインシデント分析でも、概要、メトリクス、タイムライン、質問、アクション項目を扱います。特に、検知や軽減までの時間を振り返り、改善項目につなげる構成が示されています。AWS公式ドキュメントを参考に、組織固有の質問を追加するとよいでしょう。
NG例と改善例
短い指示ほど使いやすく見えますが、インシデント分析ではAIが空白を自然な文章で埋めてしまう危険があります。
NG例：原因を一つに決めさせる
以下の障害ログを要約し、根本原因と担当者の問題点、再発防止策を書いてください。
{障害ログ}
この指示には三つの問題があります。
- 証拠が足りなくても「根本原因」を断定しやすい
- 担当者個人への責任帰属を促す
- 再発防止策に担当、期限、完了条件が付かない
改善例：根拠と未確認事項を分ける
以下の記録だけを根拠に、インシデント振り返りの初稿を作成してください。
- 確認済み事実には情報源を付ける
- 因果関係が未確定なら「仮説」と表示する
- 個人ではなく、設計・監視・手順・権限・情報共有の条件を分析する
- 不足情報は推測せず、追加質問に変換する
- 改善策には担当する役割、期限、完了条件を付ける
{障害ログと対応記録}
変えたのは文章量だけではありません。AIの役割を「原因の断定」から「証拠の整理と質問の作成」へ変更したことが重要です。
出力を安定させる3つのコツ
初稿の品質は、モデル名よりも入力の区切り方と検証手順に強く左右されます。
1. 先に時系列だけを整える
大量のログを一度に渡す場合は、最初から完成レポートを求めない方が安全です。まず次の指示で時系列を作ります。
入力記録から、時刻が明記された出来事だけを抽出してください。
各項目に「時刻・出来事・情報源・確度」を付け、重複は統合してください。
時刻がない記録は推定せず、別枠の「時刻未確認」に置いてください。
人がタイムラインを確認した後、その確定版を本テンプレートへ入力します。これにより、投稿時刻を障害発生時刻と誤認するような混同を見つけやすくなります。
2. 「なぜ」を人ではなく条件へ向ける
「担当者が設定を間違えた」で止めると、同じ条件が残ります。確認すべきなのは、たとえば次の点です。
- 危険な設定を単独で本番へ反映できたのはなぜか
- 自動検証が異常値を検出しなかったのはなぜか
- ロールバック手順の開始が遅れたのはなぜか
- アラートから影響範囲を判断できなかったのはなぜか
Atlassianも、責任を個人間で割り当てるのではなく、作業過程や当時の判断をたどって問題の中心を調べる考え方を説明しています。Atlassianのブレームレス・ポストモーテム解説は、AIへの指示文を見直す際にも参考になります。
3. アクションを「実施可能な単位」にする
「監視を強化する」「手順を改善する」だけでは、完了を判定できません。次のように変換します。
- 曖昧：監視を強化する
- 具体化：エラー率が5分間にわたり基準値を超えた場合のアラートを追加し、ステージング環境で通知試験を完了する
しきい値や期限が未定なら、AIに数字を作らせてはいけません。「要決定」と表示し、決定者と確認期限をアクションへ入れます。
活用例：用途に合わせた追加指示
基本テンプレートの末尾に短い指示を追加すれば、読み手に合った派生版を作れます。
経営層・顧客説明向け
技術詳細とは別に、非技術者向けの説明を300字以内で作成してください。
利用者への影響、現在の状態、次の対応を優先し、未確定の原因は断定しないでください。
振り返り会議向け
レポートから会議で合意が必要な論点を最大5件抽出してください。
各論点に「決めること・必要な参加役割・判断材料・未確認情報」を付けてください。
チケット登録向け
合意済みの再発防止アクションだけを、チケット登録用の箇条書きへ変換してください。
各項目に、件名、背景、作業内容、担当する役割、期限、完了条件、依存関係を含めてください。
未合意の提案は別枠に分けてください。
いずれの場合も、AIの出力をそのまま社外公開したり、チケットを自動登録したりせず、インシデント責任者と関係チームが内容を確認します。AIは編集作業を短縮できますが、ログの欠落や組織固有の判断基準までは保証できません。
公開・共有前のチェックリスト
最後に、人が次の項目を確認します。
- [ ] 発生、検知、復旧の各時刻に根拠がある
- [ ] 実測値、推定値、未集計が区別されている
- [ ] 事実と原因仮説が混在していない
- [ ] 個人名や個人への責任帰属が残っていない
- [ ] 顧客情報、認証情報、内部URLなどが除去されている
- [ ] 影響を拡大した要因と、復旧を遅らせた要因が分かれている
- [ ] 再発防止策に担当する役割、期限、完了条件がある
- [ ] 各アクションが、どの寄与要因に対応するか分かる
- [ ] 記録の矛盾や不足情報が明記されている
- [ ] 技術担当者とインシデント責任者がレビューした
振り返りレポートの価値は、読みやすい文章を完成させることでは決まりません。次に同じ兆候が出たとき、アラートが早く届くのか、危険な変更を止められるのか、復旧判断を迷わず下せるのか。レポートから生まれたアクションが期限どおり完了し、効果を確認できるところまで追跡することが、最後に残る実務です。