AIで障害ポストモーテムを書く方法｜再発防止を形骸化させない記録術
AIで障害ポストモーテムを書く方法｜再発防止を形骸化させない記録術
システム障害の復旧後、「ポストモーテムを書く時間がない」「担当者によって分析の深さが違う」「対策を書いても実行されない」と悩んでいないでしょうか。
ポストモーテムは、障害の責任者を探すための文書ではありません。発生条件や対応上の課題を整理し、同じ種類の障害を防ぐための学習記録です。しかし、作成に時間がかかるうえ、時系列の整理や原因分析には一定のスキルが求められます。
そこで役立つのが生成AIです。ログ、チャット、チケットなどの情報をAIに整理させれば、初稿作成を効率化できます。ただし、AIの文章をそのまま採用すると、事実誤認や抽象的な再発防止策が残る危険があります。
本記事では、AIを使ってポストモーテムを作成する手順と、再発防止を形骸化させない運用方法を解説します。
ポストモーテムとは
ポストモーテムとは、障害発生から復旧までの事実、影響、原因、対応内容、再発防止策を記録した文書です。
優れたポストモーテムには、次の役割があります。
- 障害の発生条件を組織内で共有する
- 検知や復旧が遅れた理由を明らかにする
- システムと運用プロセスの改善点を特定する
- 将来の担当者が同様の障害へ迅速に対応できるようにする
- 対策の担当者と期限を明確にする
重要なのは、個人のミスだけで説明しないことです。「担当者が設定を間違えた」で終わらせず、なぜ誤った設定を投入できたのか、レビューや自動検証が機能しなかった理由まで分析します。
障害対応全体の流れを整えたい場合は、インシデント管理の基本も確認してください。
[INTERNAL: incident-management-guide]
AIを使う場合と人だけで作成する場合の比較
| 比較項目 | 人だけで作成 | AIを活用して作成 |
|---|---|---|
| 初稿作成 | 情報整理に時間がかかる | ログやメモから素早く構成できる |
| 時系列整理 | 転記漏れが起きやすい | 入力情報を時刻順に並べやすい |
| 文章品質 | 作成者の経験に左右される | テンプレートに沿って均一化しやすい |
| 原因分析 | 深い技術判断が可能 | 仮説の洗い出しには強いが確定はできない |
| 正確性 | 関係者が確認しやすい | 事実の補完や誤認が起こり得る |
| 機密管理 | 社内環境で完結しやすい | 入力先や保存方針の確認が必要 |
| 推奨用途 | 原因の確定、意思決定 | 要約、分類、質問作成、初稿作成 |
AIは「分析責任者」ではなく、情報整理を支援する編集者として使うのが適切です。原因の確定、影響範囲の判断、対策の優先順位付けは、システムを理解している担当者が行います。
AIで障害ポストモーテムを書く7つの手順
1. 事実情報を収集する
最初に、障害に関する一次情報を集めます。
- 監視アラート
- アプリケーションやインフラのログ
- 障害対応チャット
- チケットや作業記録
- デプロイ履歴
- 設定変更履歴
- 顧客からの問い合わせ
- メトリクスやダッシュボード
この段階では解釈を加えず、「いつ、何が観測されたか」を集めます。時刻はタイムゾーンを統一し、推測には「未確認」「仮説」と明記しましょう。
AIへ入力する前に、個人情報、認証情報、顧客データ、非公開URLなどを削除またはマスキングします。利用するAIサービスのデータ保持、学習利用、管理者設定も確認してください。
2. AIでタイムラインを整理する
収集した記録をAIへ渡し、時系列に並べます。入力情報が長い場合は、時間帯や情報源ごとに分割し、最後に統合します。
プロンプト例は次のとおりです。
以下は障害対応中の記録です。記載された情報だけを使用し、「時刻・観測事実・実施した対応・結果」の表に整理してください。推測で不足情報を補わず、矛盾や時刻不明の項目は別に列挙してください。
AIに推測を禁止し、矛盾点を出力させるのがポイントです。生成されたタイムラインは、ログやチケットと照合して人が確認します。
3. 影響範囲を定量化する
「一部ユーザーに影響」といった曖昧な表現では、障害の重大度を判断できません。可能な範囲で、次の項目を数値化します。
- 影響した機能やサービス
- 影響開始時刻と終了時刻
- 対象ユーザー数または割合
- エラー件数や失敗率
- 売上、契約、業務への影響
- データ欠損や不整合の有無
- SLA・SLOへの影響
計測できなかった項目も隠さず記録します。影響を測れなかったこと自体が、監視改善の候補になるためです。
SLOの設計方法は、以下の記事で詳しく解説しています。
[INTERNAL: slo-design-basics]
4. 原因を「直接原因」と「背景要因」に分ける
障害原因は一つとは限りません。次のように分けると、対策を考えやすくなります。
- 直接原因：障害を直接発生させた変更や故障
- 背景要因：直接原因が障害に発展することを許した設計・運用上の条件
- 検知要因：検知が遅れた、または誤検知が発生した理由
- 復旧要因：切り分けや復旧に時間がかかった理由
AIには原因を断定させず、「追加確認すべき仮説」と「仮説を検証する証拠」を出させます。
障害記録から考えられる原因仮説を、直接原因・背景要因・検知の遅れ・復旧の遅れに分類してください。各仮説について、根拠、反証となる情報、追加で確認すべきログを示してください。原因は確定しないでください。
これにより、もっともらしい文章に引っ張られず、証拠に基づいて分析できます。
5. 対応の良かった点と改善点を記録する
ポストモーテムには失敗だけでなく、機能した仕組みも残します。
たとえば「監視アラートで5分以内に検知できた」「切り戻し手順が整備されていた」といった情報です。良かった点を記録すれば、維持すべき仕組みが明確になります。
改善点では個人を責めず、システムやプロセスに焦点を当てます。
「担当者の確認不足」ではなく、「危険な設定値をCIで検証できなかった」と表現すれば、実行可能な対策につながります。
6. 再発防止策を実行可能なタスクへ変換する
再発防止策が形骸化する主因は、「監視を強化する」「注意する」といった曖昧な記述です。各対策には最低限、以下を設定します。
| 項目 | 記載例 |
|---|---|
| 対策 | 設定ファイルの上限値をCIで自動検証する |
| 期待効果 | 異常な設定値の本番反映を防止する |
| 担当者 | プラットフォームチーム |
| 期限 | 次回リリースまで |
| 優先度 | 高 |
| 完了条件 | 異常値を含むテストが失敗すること |
| 管理先 | 課題管理チケットのURL |
対策は、予防・検知・影響軽減・復旧高速化の観点で検討します。一つの強力な対策だけに依存せず、多層的な防御を設けることが重要です。
7. レビューして公開する
AIが作成した初稿は、障害対応者、サービス責任者、必要に応じてセキュリティや法務担当者がレビューします。
特に確認すべき点は次のとおりです。
- 記載内容を一次情報で裏付けられるか
- 推測が事実として書かれていないか
- 顧客や担当者の機密情報を含んでいないか
- 原因と対策が論理的につながっているか
- 対策に担当者、期限、完了条件があるか
- 読者が障害の流れを再現できるか
公開後は対策チケットを定期的に確認します。文書の完成ではなく、対策の完了と効果確認までがポストモーテムです。
ポストモーテム作成に役立つツール
生成AIツール
生成AIは、タイムラインの整理、長いチャットの要約、原因仮説の分類、文章の校正に向いています。法人利用では、入力データの学習利用を制御でき、監査やアクセス管理に対応したプランを優先しましょう。
[AFF_LINK: business_ai_assistant]
ドキュメント管理ツール
NotionやConfluenceなどのナレッジ管理ツールを使えば、テンプレートを共通化し、過去の障害記録を検索しやすくできます。サービス名、重大度、原因分類、発生日などのメタデータを統一すると、障害傾向の分析にも役立ちます。
[AFF_LINK: knowledge_management_tool]
課題管理ツール
GitHub Issues、Jiraなどを利用し、再発防止策を通常の開発バックログへ組み込みます。ポストモーテム内に書くだけでは、担当者の日常業務から切り離されてしまいます。
[AFF_LINK: project_management_tool]
監視・インシデント管理ツール
監視通知、担当者の呼び出し、対応履歴の保存を一元化できるツールは、一次情報の収集を効率化します。選定時は既存の監視基盤との連携、監査ログ、権限管理、通知経路を確認しましょう。
[AFF_LINK: incident_response_tool]
再発防止を形骸化させない運用ルール
テンプレートを導入するだけでは、改善は継続しません。次の運用ルールが必要です。
- 重大度ごとに作成対象と提出期限を決める
- レビュー会では責任追及ではなく学習を目的にする
- 対策を必ず課題管理ツールへ登録する
- 期限超過を定例会で確認する
- 完了後に対策の効果を検証する
- 過去の類似障害を定期的に横断分析する
- AIプロンプトとテンプレートを継続的に改善する
同じ原因分類の障害が繰り返されている場合、個別対策だけでは不十分です。共通ライブラリ、開発標準、監視基盤など、組織横断の改善を検討しましょう。
AIポストモーテムのFAQ
Q1. 障害ログをそのままAIへ入力してもよいですか？
原則として、そのまま入力すべきではありません。認証情報、個人情報、顧客データ、内部URLなどを除去し、組織のセキュリティポリシーと利用サービスのデータ管理条件を確認してください。必要なら、閉域環境や法人向け環境を利用します。
Q2. AIだけで根本原因を特定できますか？
AIは仮説の整理には使えますが、根本原因の確定はできません。ログ、メトリクス、コード、変更履歴、再現試験などの証拠を基に、担当者が判断する必要があります。
Q3. ポストモーテムはすべての障害で作るべきですか？
必ずしも必要ではありません。顧客影響、継続時間、データへの影響、対応コスト、再発可能性などから基準を決めます。軽微な障害は簡易記録、重大障害は正式なレビュー対象にすると運用しやすくなります。
Q4. 5 Whysを使えば十分ですか？
5 Whysは原因を掘り下げる補助になりますが、一つの直線的な原因へ単純化しやすい点に注意が必要です。複数の技術要因や組織要因が関係する場合は、因果関係図や変更分析と組み合わせます。
Q5. 再発防止策が進まない場合はどうすればよいですか？
対策を通常の開発タスクとして登録し、担当者、期限、優先度、完了条件を設定してください。期限超過を可視化し、サービス責任者が優先順位を判断する仕組みも必要です。
まとめ
AIを使えば、障害記録の整理やポストモーテムの初稿作成を効率化できます。一方で、AIは入力されていない事実を補ったり、根拠の弱い原因を断定したりする可能性があります。
実用的なポストモーテムを作るポイントは、一次情報を基準にすること、原因と仮説を分けること、再発防止策へ担当者・期限・完了条件を設定することです。
まずは既存の障害記録を一件選び、本記事の7つの手順でタイムラインと対策を見直してみてください。継続運用する場合は、安全なAI環境とナレッジ管理ツールを整え、作成からフォローアップまでを共通プロセスにしましょう。
[AFF_LINK: business_ai_assistant]
[INTERNAL: postmortem-template]