障害報告書(顛末書)をClaudeで起こす手順 — Slackログから時系列まで

障害報告書(顛末書)の下書きは、Slackのやり取りをClaudeに時刻順の表へ整理させ、報告書の各欄に振り分けさせると速く進みます。時刻と事実の確定だけは人がSlackの元ログと突き合わせます。この分担にすると、対応中のメッセージを拾い集める作業が下書きの数分に縮み、人は確認に集中できます。

社内では障害報告書、顛末書、インシデントレポートと呼び名が分かれますが、骨格は同じです。何が起き、いつ気づき、誰が何をして、どこまで影響し、なぜ起きて、どう再発を防ぐか。この記事は、その骨格をSlackの記録から起こす手順を扱います。

全体の流れ — 下書きはClaude、時刻と事実は人が確かめる

最後の工程を省くと、報告書として提出できません。ログにない時間帯や数値を、下書きが前後の流れから補っていないかは、人でなければ判断できないためです。指示で抑えられますが、確認の代わりにはなりません。

材料をそろえる — Slackのログを渡せる形にする

障害対応の記録は、Slackの障害用チャンネルのやり取りが中心になることが多いでしょう。Claudeに渡す方法は、権限で2通りに分かれます。

ワークスペースのエクスポートを使う

ワークスペースのオーナーと管理者は、パブリックチャンネルのメッセージとファイルのリンクをJSON形式でエクスポートできます。管理画面の「ワークスペースの設定」から「セキュリティ」、「データのインポート / エクスポート」の順に進み、「エクスポート」タブで日付範囲を選びます。準備ができるとメールが届き、zipファイルをダウンロードできます。

障害用チャンネルが非公開だと、取り出せるプランが絞られます。

フリープランでは、ファイルへのリンクは過去90日分しかエクスポートできません。報告書に添付ファイルの出所を残したい場合は、障害から時間が空く前に取り出します。

エクスポートの権限がないとき

エクスポートはオーナーと管理者の操作です。権限がないときは、障害用チャンネルとスレッドの本文を時刻つきでコピーしてチャットに貼る方法になります。時刻が欠けやすいので、貼った後に「時刻の表示形式が揃っているか」を最初に確かめてください。管理者に日付範囲を絞ったエクスポートを頼む手もあります。

JSONを時刻つきの表に変換する

JSONのままでも読めますが、そのまま渡すと二つ困ります。投稿時刻はUNIX時間の数値(1355517523.000005 の形)で、発言者はメンバーIDで記録されています。時刻はGMTの数値、人はIDのままだと、Claudeが読み違えやすく、人が後で裏取りする際も辿れません。

エクスポートには、IDと名前を対応づける users.json が入っています。次のスクリプトは、日付ごとのJSONを読み、日本時間の時刻、名前、元の ts、本文を1行ずつ出力します。元の ts を残すのは、後の裏取りで元メッセージに戻れるようにするためです。

import glob
import json
import sys
from datetime import datetime, timedelta, timezone
 
JST = timezone(timedelta(hours=9))
export_dir, channel = sys.argv[1], sys.argv[2]
 
with open(f"{export_dir}/users.json", encoding="utf-8") as f:
    users = {u["id"]: u.get("real_name") or u.get("name") for u in json.load(f)}
 
for path in sorted(glob.glob(f"{export_dir}/{channel}/*.json")):
    with open(path, encoding="utf-8") as f:
        messages = json.load(f)
    for m in messages:
        if m.get("type") != "message":
            continue
        when = datetime.fromtimestamp(float(m["ts"]), JST)
        who = users.get(m.get("user"), m.get("user", "bot"))
        text = m.get("text", "").replace("\n", " / ")
        print(f"{when:%Y-%m-%d %H:%M:%S}\t{who}\t{m['ts']}\t{text}")

slack_to_tsv.py という名前で保存し、解凍したエクスポートのフォルダとチャンネル名を渡して実行します。

python3 slack_to_tsv.py ./slack-export incident-0912 \
  > incident-0912.tsv

users.json のキー名は、手元のエクスポートを開いて合わせてください。アプリの投稿などで名前が引けないときは、元の値か bot を出す作りにしてあります。

Projectsに置くものと、チャットに添付するもの

Projectsは、プロジェクトごとに独立した知識とチャット履歴を持てる仕組みです。ここに置く物と、障害ごとに渡す物を分けると、報告書の品質が揃います。

プロジェクトの知識には、障害をまたいで使い回すものを置きます。

• 社内の報告書テンプレート
• 過去の報告書の記入例(個人名と顧客名を伏せたもの)
• 社内の用語集とシステム名の一覧
• プロジェクトの指示

今回のログは、プロジェクトの知識ではなく、障害ごとに作るチャットへ添付します。理由は二つあります。まず、プロジェクト内でも、知識に追加しない限りチャット間で文脈は共有されません。次に、障害のログを知識に積むと、次の障害の下書きに別の障害の発言が混じる可能性が出るからです。

添付の上限も押さえておきます。チャットへの添付は1ファイル500MBまで、1チャット20ファイルまでです。プロジェクトの知識に置くファイルは1ファイル30MBまでで、全体がコンテキストウィンドウに収まる必要があります。

プロジェクトの指示を書く

プロジェクトの「Set project instructions」から指示を保存すると、そのプロジェクトのすべてのチャットに効きます。報告書では、事実の根拠をログに限ることと、推測を分けて書かせることが要点です。

あなたは社内の障害報告書(顛末書)の下書きを作る担当です。
- 事実は、添付されたSlackログに書かれていることだけを使う
- ログに根拠がない項目は「不明」と書き、推測で埋めない
- 時刻は日本時間で書き、元ログのts値を併記する
- 原因は「確定」と「推定」を分けて書く
- 再発防止策は案として出し、担当者と期限は空欄にする
- 添付のテンプレートの見出し構成は変えない

作成者と共有の範囲

TeamまたはEnterpriseのプランでは、プロジェクトを非公開にするか、組織全体に見せるかを作成時に選べます。障害ログには顧客名や社内の調査メモが入ります。まず非公開で作り、レビューする人を「Can view」で招待する運用が安全です。「Can edit」はプロジェクトの指示や知識を書き換えられるので、テンプレートの管理者に限ります。

無料アカウントでも作れますが、プロジェクトは5つまでです。

下書きを3回に分けて頼む

報告書を一度に頼むと、時系列の誤りが本文に埋もれて見つけにくくなります。時系列表、本文、確認事項の3回に分けます。

1回目 — 時系列表だけを作る

添付の incident-0912.tsv から、障害対応の時系列表を作ってください。
列は「時刻(日本時間)」「発言者」「出来事」「元のts」です。
出来事は元の発言の言い換えにとどめ、評価や推測は加えないでください。
発言がない時間帯は、空白のまま示してください。

例えば次のような形の表が返ります。

この表は書式の例です。実際の返答では、行数も出来事の言い回しも、ログによって変わります。この段階で、人が先に表を通読します。直すのは、この時点が最も安上がりです。

2回目 — テンプレートに沿って本文を書かせる

確定した時系列表をもとに、添付のテンプレートで報告書の本文を書いてください。
各段落の末尾に、根拠にした行の「元のts」を括弧で付けてください。
ログに根拠がない欄は「要確認」と書いてください。

根拠のtsを付けさせるのが、この回の核心です。裏取りのとき、人が元メッセージに直接戻れます。

3回目 — 人が確認する箇所を挙げさせる

この報告書で、ログだけでは確定できない記述を一覧にしてください。
影響範囲の数値、原因の断定、対応者の特定を優先してください。

Claudeの挙げる一覧は、人の確認の出発点にはなりますが、網羅とは限りません。次の節の6項目は、この一覧と関係なく人が見ます。

人がログと突き合わせる6つの箇所

下書きの責任は、提出する人にあります。次の表は、突き合わせの順番の目安です。

編集や削除されたメッセージは、保存ポリシーで保持する設定になっている場合にだけ、エクスポートに含まれます。保持の設定がなければ、会話の途中で訂正された情報が、エクスポートでは見えません。

影響範囲と原因の2項目は、Slackのやり取りだけでは確定しない代表例です。たとえば「影響は一部の顧客」という発言は、対応中の暫定的な見立てでしょう。報告書には、確定した件数と対象期間を別の記録から書き込みます。

つまずきやすい点を症状から引く

抜けの原因について補足します。プロジェクトの知識が大きくなると、有料プランでは検索ベースの方式(RAG)に自動で切り替わり、質問に関連する部分だけを引いて答えます。時系列のように全件を順番に読む作業は、この方式と相性が良いとは限りません。ログはチャットに添付し、長ければ分割するのが無難です。仕組みの詳細はClaude ProjectsのRAG検索の仕組みにまとめています。

ログに個人名や顧客名が含まれ、そのままでは渡したくない場合は、匿名化と集計の手順が参考になります。

検知ツールや障害管理ツールに記録がある場合

Slackは会話の記録で、障害管理ツールの記録は状態遷移の記録です。両方にあるなら、突き合わせの材料が増えます。

• incident.ioを使っているなら、ステータス更新の履歴をコネクタ経由で読ませる方法があります。手順はClaudeとincident.ioで障害の振り返りを下書きする方法にあります。
• PagerDutyでは、通知から対応までの流れをClaudeに読ませる構成がClaudeとPagerDutyの連携にあります。

Slack側でClaudeを直接呼び出して、スレッドを要約させる経路もあります。プラン別の違いはClaudeとSlackの連携に整理しています。この記事のようにログを書き出して渡す方法は、読ませる範囲と時刻の表記を自分で管理できる点で、報告書に向いています。

まとめ

障害報告書の下書きは、Claudeが時系列表と本文を作り、人が時刻と事実を元ログで確かめる分担にすると、速さと正確さを両立できます。Slackのエクスポートは、JSONの時刻とIDを変換してから渡すこと、プロジェクトには型だけを置き、ログは障害ごとのチャットに添付することがポイントです。

最初の1件は、過去の小さな障害で試してみてください。提出済みの報告書と下書きを比べると、時刻の取り違えや、推定の断定がどこで出るかが分かります。そのずれの傾向をプロジェクトの指示に書き足していけば、次の障害から精度が上がります。