システム障害の対応記録とチャットのやり取りから障害報告書の下書きを作る

処理の起点を決める

チケットのステータスが「報告書作成」に変わったときを起点にします。障害の収束を検知して自動で起動する構成は取りません。

理由は、「収束した」の判断が機械的に決まらないためです。監視アラートが止まっても、利用者側の影響が残っていることがあります。担当者が「対応は終わった、報告書に移る」と判断した時点を起点にします。

ステータスを1つ増やす運用変更が必要ですが、それ自体が「報告書を書き始める」合図になり、書き忘れの防止にもなります。

入力データを集める

4番目を入れると粒度が揃います。 「経緯は10〜20行」と数字で指示するより、実物を見せるほうが効きます。ただし、例に引っ張られて別の障害の内容が混ざらないよう、例であることを明示して渡します。

データの取得方法を決める

チケット： Jira Cloud の REST API を使います。チケット番号が分かっていれば課題を1件取得し、コメントとステータス変更の履歴を合わせて取ります。関連するチケットを JQL で検索する場合は /rest/api/3/search/jql を使います。以前の /rest/api/3/search は廃止されており、新しいエンドポイントではページ送りに nextPageToken を使います。 古い実装例を参考にすると、ここで動かなくなります。

チャンネルのメッセージ： Slack の conversations.history メソッドで、対応チャンネルのメッセージを取得します。oldest と latest に時刻（Unixタイムスタンプ）を指定すると、その間のメッセージだけを取れます。件数が多い場合はカーソルによるページ送りで続きを取得します。スレッドの返信は conversations.history だけでは本文が揃わないため、返信のあるメッセージについてはスレッドの取得を別に行います。

チャンネルとチケットの紐づけは、チャンネル名にチケット番号を入れる運用にするのが確実です（例：#inc-1234-ec-checkout）。チャンネル名から番号を取り出して照合します。

Botの権限： Slack アプリには、対象チャンネルの履歴を読む権限が必要です。プライベートチャンネルで対応している場合は、アプリをチャンネルに招待しておく必要があります。ここを忘れると、空の報告書が出ます。

AIへ渡す前に整形する

1. 時刻の統一 … Jira と Slack の時刻を日本時間に揃えます。Slack の時刻はUnixタイムスタンプで返るため変換します
2. 並べ替え … チケットのコメント、ステータス変更、チャットのメッセージを1本の時系列にまとめます
3. ノイズの除去 … 絵文字だけの返信、「了解です」「ありがとうございます」、Botの定型通知を落とします
4. 重複の除去 … 同じ内容がチケットとチャットの両方に書かれていることがあります。近い時刻の似た文面を1件にまとめます
5. 長さの分割 … 長時間の障害でメッセージが数千件になる場合は、時間帯で区切って段階的に整理させ、最後に統合します
6. 機微情報の除去 … パスワード、APIキー、個人の電話番号がチャットに貼られていることがあります。パターンで検出して伏せてから渡します

6番を飛ばさないでください。障害対応の最中は、急いで認証情報をチャンネルに貼ることが実際に起きます。

AIに処理させる

報告書の欄ごとに、させることを分けます。

「原因」と「再発防止策」をAIに書かせないことが、この構成の設計の核です。 報告書を読むのは経営層や他部署で、そこに書かれた原因は事実として受け取られます。

指示内容を固定する

あなたはシステム障害の報告書を整理する担当者です。
障害チケットの記録と、障害対応チャンネルのやり取りを渡します。
報告書の下書きを作ってください。

【厳守事項】
- 記録とやり取りに書かれていないことを書かないでください。
  一般的な障害の原因を推測で書かないでください。
- 時刻は記録に残っている時刻をそのまま使ってください。
  「14時頃」としか書かれていない出来事は、時刻を「14時頃（推定）」と書き、
  unconfirmed に入れてください。
- 原因について、確定した記述がない場合は root_cause を空にし、
  cause_candidates に「チャットで言及された原因の候補」とその発言時刻を並べてください。
- 再発防止策は書かないでください。
  議論に出た案があれば discussed_measures に発言者と時刻とともに列挙してください。
- 人の判断の誤りや責任を示す表現を使わないでください。
  「〇〇さんが誤って」ではなく「設定変更が行われ、その後」と事実だけを書いてください。
- 下の過去の報告書は書き方の参考です。内容を流用しないでください。

【報告書の書式】
{report_template}

【書き方の参考（別の障害の報告書）】
{good_examples}

【障害チケット】
{jira_issue}

【対応チャンネルのやり取り（時系列に整理済み）】
{slack_messages}

「人の判断の誤りや責任を示す表現を使わない」の1行は、運用上とても重要です。 チャットには「すみません、自分がさっき設定を戻し忘れていました」といった発言が残ります。これをそのまま報告書に書くと、個人を責める文書になり、次の障害で率直な書き込みが減ります。記録が正直であり続けることが、この構成の前提です。

出力形式を固定する

{
  "incident_id": "",
  "summary": "",
  "timeline": [
    { "time": "", "time_confirmed": true, "event": "", "source": "jira | slack" }
  ],
  "impact": {
    "systems": [],
    "duration_minutes": null,
    "affected_scope": "",
    "impact_confirmed": false
  },
  "workaround": "",
  "root_cause": "",
  "cause_candidates": [
    { "candidate": "", "mentioned_at": "" }
  ],
  "discussed_measures": [
    { "measure": "", "mentioned_by": "", "mentioned_at": "" }
  ],
  "unconfirmed": []
}

time_confirmed と impact_confirmed を持たせているのは、確定した値と推定の値を報告書上で見分けられるようにするためです。Confluence のページ化の段階で、未確定の値に色を付けます。

duration_minutes は数値で返させます。障害の停止時間は、月次や年次で集計されることがあるためです。

システムへ連携する

下書きは Confluence に「下書き」として作成します。公開はしません。

報告書の公開や関係部署への配信は自動化しません。 上長の承認を経てから、人が共有します。

人が確認する

全件、人が確認します。 確認は2段階です。

1. 担当者 … 時系列の時刻と出来事が正しいかを、監視ツールのログなどで確かめる。原因と再発防止策を書く。未確認事項を解消する
2. 上長 … 報告書として公開してよいかを判断する

担当者の確認を速くするための設計が要ります。

• 時系列の各行に、元のチャットやチケットコメントへのリンクを付ける
• 推定の時刻、未確定の影響範囲を色分けする
• 未確認事項を報告書の冒頭に並べる

例外に対処する

記録を残す

• 取得したチケットとメッセージ（報告書の根拠として）
• AIが作った下書き（初版）
• 担当者が修正した後の版、上長が承認した最終版
• 下書きから最終版までに変更された箇所

最後の項目を見ると、AIの下書きのどこが使われ、どこが書き直されたかが分かります。「時系列はほぼそのまま使われるが、影響範囲は毎回書き直されている」と分かれば、影響範囲の欄はAIに書かせず、監視ツールから数値を取る設計に変えます。

取得したメッセージは、報告書と同じ保存期間で保管します。チャットツール側の保存期間が短い場合、報告書の根拠が後から消えるためです。