AIで障害ふりかえりを回す方法｜事実整理から再発防止までテンプレ化する

こんな悩みはありませんか

深夜のアラートで叩き起こされ、なんとか障害を収束させた翌朝。上司から「ポストモーテムまとめといて」と言われても、正直それどころではない——そんな経験がある方は多いはずです。

障害対応の現場でよく聞かれる悩みは、次の3つに集約されます。

時系列がバラバラ: Slackのやり取り、監視ツールのアラート、対応者のメモがあちこちに散らばっていて、いざふりかえりをまとめようとすると1から時系列を組み立て直す羽目になる
原因分析が浅い: 「デプロイが原因でした」で終わってしまい、なぜそのデプロイが問題を起こしたのか、なぜ事前に気づけなかったのかまで掘り下げられていない
再発防止策が形骸化: アクションアイテムを書いたはいいものの、担当者もアサインされず、次の四半期には同じ原因で似た障害が再発する

SRE専任チームがいる大企業ならまだしも、少人数チームや兼任のエンジニアが障害対応とふりかえりを両方こなすのは、時間的にも精神的にもかなりの負荷です。しかし、ふりかえりの質はサービスの信頼性に直結します。うやむやにすればするほど、同じ障害が形を変えて何度も襲ってきます。

本記事では、生成AI（ChatGPTやClaudeなど）を活用して、障害ふりかえり（ポストモーテム）を「事実整理」「原因分析」「再発防止策の策定」まで一気通貫でテンプレート化する方法を解説します。属人化しがちなこの業務を、誰がやってもある程度の品質を担保できる仕組みに落とし込むのがゴールです。

そもそも障害ふりかえり（ポストモーテム）とは何か

障害ふりかえりとは、システム障害やインシデントが発生した後に、何が起きたのか・なぜ起きたのか・今後どう防ぐのかを整理するプロセスです。GoogleのSREプラクティスをはじめ、多くの企業が「Blameless Postmortem（非難しないふりかえり）」を重視しています。特定の個人を責めるのではなく、仕組みの問題として捉えることで、率直な情報共有と実効性のある改善が可能になります。

このプロセスをAIで支援するメリットは主に3つあります。

時系列整理の自動化: ログやSlackのやり取りを貼り付けるだけで、時系列順のタイムラインを自動生成できる
多角的な原因分析の補助: 人間だと見落としがちな観点（設定変更、依存サービス、キャパシティなど）をAIが漏れなく洗い出してくれる
ドキュメント作成の高速化: フォーマットが決まっていれば、事実を入力するだけで報告書のドラフトが数分で仕上がる

手動ふりかえり vs AI活用ふりかえりの比較

項目	手動でのふりかえり	AIを活用したふりかえり
時系列整理にかかる時間	1〜3時間（ログを手作業で並べる）	10〜20分（ログを貼り付けて要約）
原因分析の網羅性	担当者の経験と知識に依存	Whyの深掘りをAIが機械的に提案
ドキュメントの一貫性	書き手によってフォーマットがバラバラ	テンプレートで統一しやすい
再発防止策の具体性	「気をつける」で終わりがち	担当者・期限・検証方法まで提案させやすい
属人化リスク	高い（ベテランが書くと質が上がる）	低い（誰が使っても一定水準を担保）
心理的ハードル	高い（面倒で後回しにされがち）	低い（下書きがあるので着手しやすい）

もちろんAIが万能というわけではありません。実際の障害の重大性や事業インパクトの評価、関係者への配慮が必要な表現などは、最終的に人間の判断とレビューが不可欠です。AIはあくまで「一次ドラフトを高速に作る」「観点の抜け漏れを防ぐ」ための道具として位置づけるのが現実的です。

AIで障害ふりかえりを回す具体的な手順

ステップ1: 一次情報を集約する

まず、障害対応中に発生した以下の情報をひとつのドキュメント（テキストファイルやNotionページなど）にコピーします。

監視ツールのアラート発火時刻とメッセージ
Slackやチャットでのやり取り（対応者間の会話）
デプロイ履歴、インフラの変更履歴
対応者が取ったアクション（再起動、ロールバックなど）とその時刻

このとき、情報を整形する必要はありません。生のログやコピペのままでOKです。整形はAIに任せます。

ステップ2: AIに時系列タイムラインを作らせる

集めた情報をAIに渡し、以下のようなプロンプトで時系列を整理させます。

以下は障害対応中のログとSlackのやり取りです。
これを時系列順に整理し、
「時刻｜出来事｜対応者｜補足」の表形式でまとめてください。
推測が入る箇所は「（推測）」と明記してください。

[ここに生ログを貼り付け]

「推測は推測と明記させる」のがポイントです。AIは文脈から自然に補完してしまうことがあるため、事実と推測を混同しないよう明示的に指示します。

ステップ3: なぜなぜ分析（Why-Why分析）をAIと一緒に行う

時系列が整ったら、根本原因の分析に入ります。AIに「なぜ」を5回程度繰り返し問いかけさせるのが効果的です。

このタイムラインをもとに、なぜなぜ分析を行ってください。
表面的な原因（例: デプロイが原因）だけでなく、
「なぜそのデプロイが問題を起こしたのか」
「なぜ事前のテストで検知できなかったのか」
「なぜ検知から復旧までに時間がかかったのか」
という観点で、最低3階層まで深掘りしてください。

ここで出てきた候補は、あくまで「仮説」として扱い、実際のログやコードで裏付けを取ることが重要です。AIの出力を鵜呑みにせず、必ず一次情報と突き合わせる習慣をつけましょう。

ステップ4: 再発防止策を「担当者・期限・検証方法」つきで出させる

原因分析ができたら、再発防止策を具体化します。ここで曖昧な策を出させないためのコツは、フォーマットを明示的に指定することです。

特定した原因それぞれに対して、再発防止策を以下の形式で提案してください。
- アクション内容
- 想定される担当チーム
- 完了の目安期限（短期/中期/長期で分類）
- 効果を検証する方法（どうなれば「解決した」と言えるか）

「効果を検証する方法」まで書かせるのが、形骸化を防ぐ最大のポイントです。検証方法が明記されていないアクションアイテムは、たいてい放置されます。

ステップ5: テンプレートに流し込んでレビューする

最後に、社内で使っているポストモーテムのテンプレート（概要・影響範囲・タイムライン・原因・再発防止策・学び）にAIの出力を流し込み、人間がレビューして仕上げます。この「テンプレート化」の工程を一度作っておけば、次回以降は同じフォーマットで高速にふりかえりを回せます。

なお、社内向けの文書テンプレートやレビュープロセスの整備そのものについては、[INTERNAL: internal-documentation-workflow] も参考にしてください。

よくある質問（FAQ）

Q1. AIに社内の障害情報を入力しても情報漏洩のリスクはありませんか？

利用するAIサービスの利用規約とデータ取り扱いポリシーを必ず確認してください。法人向けプランやAPI経由での利用では、入力データを学習に利用しない設定が可能な場合が多いです。機密性の高い情報（顧客データ、認証情報など）はマスキングしてから入力する、あるいは社内で許可されたツールのみを使うといった運用ルールを事前に決めておくことを強くおすすめします。

Q2. AIが出した原因分析をそのまま報告書に使ってよいですか？

いいえ、必ず人間によるレビューを挟んでください。AIは与えられた情報から尤もらしい仮説を提示するのが得意ですが、実際のシステム構成や過去の経緯を完全には把握していません。特に「なぜ検知が遅れたのか」といった組織的な要因については、現場の担当者の実感と照らし合わせることが不可欠です。

Q3. Blameless（非難しない）文化とAI活用は両立できますか？

むしろ相性が良いと言えます。AIに一次分析をさせることで「誰が悪いか」ではなく「どの仕組みに欠陥があったか」という観点で議論しやすくなります。プロンプトの段階で「個人ではなくプロセスや仕組みに焦点を当てて分析してください」と明示的に指示しておくと、非難的なトーンを避けやすくなります。

Q4. 小規模チームでもポストモーテムは必要ですか？

必要です。むしろ人手が少ないチームほど、同じ原因の障害を繰り返す余裕がありません。AIを使えば工数を大きく削減できるため、「時間がないからやらない」という理由が成立しにくくなります。まずは簡易版のテンプレートから始めることをおすすめします。

Q5. 過去のふりかえり資料をAIに学習させて、次の障害対応に活かすことはできますか？

過去のポストモーテムをまとめてAIに読み込ませ、「このパターンの障害に共通する原因は何か」を横断的に分析させることは可能です。ナレッジベースとして蓄積し、定期的に傾向分析を行うことで、個別の障害対応だけでなく、システム全体の弱点を俯瞰的に把握できるようになります。

まとめ：次のアクション

障害ふりかえりは「重要だとわかっていても後回しにされがちな業務」の代表格です。AIを使えば、時系列整理・原因分析・再発防止策の策定という一連の作業を大幅に高速化でき、属人化も防げます。ただし、AIはあくまで一次ドラフトの作成と観点の網羅を助けるツールであり、最終的な判断とレビューは人間が担う必要があります。

今日からできる最初のアクションは次の3つです。

直近の障害対応ログを1件、AIに貼り付けて時系列整理を試してみる
自社のポストモーテムテンプレートを見直し、AIの出力を流し込みやすい形式に整える
再発防止策には必ず「担当者・期限・検証方法」を書くルールをチームで合意する

小さく始めて、次の障害対応時にはすでに「使えるテンプレート」がある状態を目指しましょう。関連する監視体制の整備については [INTERNAL: monitoring-alert-setup]、社内ドキュメント運用の全体設計については [INTERNAL: internal-documentation-workflow] も参考にしてください。