すぐにポストモーテムを準備したい！Claude Codeスキルの設計指針
テックリード @ 株式会社カケハシ
医療SaaSの共通基盤を開発。TypeScriptと関数型プログラミングで堅牢なシステム設計を実践。
はじめに
インシデント対応が終わったら、なるべく早く忘れないうちにポストモーテムの準備を済ませておきたいものです。ただ、インシデント対応が長時間に渡ってしまった場合、まとめるべき情報はものすごく多くなっていて、その一方で自分自身の体力は少しも残っていないことがほとんどです。
Slack のインシデントチャンネル、Datadog のアラートやダッシュボード、Jira のチケット、GitHub の Issue や Pull Request、Confluence に書かれたランブックや過去の意思決定など、情報はあちこちに散らばっていて、それを時系列に整理してテンプレートに落とし込む必要があります。インシデント直後の疲弊した状態でそれをやるのは、あまりにも辛く厳しいです。
この記事では、ポストモーテムの準備コストを Claude Code のカスタムスキルで低減することを提案します。
なお、incident.io や Rootly などのインシデント管理プラットフォームはすでに AI によるポストモーテム自動生成機能を備えています。これらのプラットフォームをすでにお使いであれば、まずはそれを試すことをお勧めします。ここで想定しているのは、そうしたプラットフォームを導入していないか、自チームのワークフローに合わせたカスタマイズが必要なケースです。
ポストモーテム準備の何が辛いのか
1. 情報源が多すぎる
インシデントの情報は単一のツールに閉じていません。
- コミュニケーション: Slack のインシデントチャンネル
- モニタリング: Datadog のアラート・ログ・APM
- タスク管理: Jira のチケット
- コード: GitHub の Issue・Pull Request
- ドキュメント: Confluence のランブック・過去のポストモーテム・PRD・製品仕様
これらを横断しながら「何が起きたか」を再構成しなければなりません。
2. テキスト量が膨大
Slack のインシデントチャンネルには大量のメッセージが流れていますし、Datadog のアラートも複数発火しています。インシデント発生中は情報が錯綜したり、あちこちでSlackスレッドが乱立したり、そうした混乱もしばしば発生します。分散してしまった情報も検索した上で、全てに目を通して関連情報を拾い出すだけで、かなりの時間を食います。
3. タイムライン作成が手間
「いつ、何が起きたか」の時系列を正確に組み立てるには、複数の情報源のタイムスタンプを突き合わせる必要があります。Slack のメッセージ、アラートの発火時刻、デプロイのタイムスタンプなどを手作業で時系列に並べ替えるのは、単純ですが地味に時間がかかります。しかも、タイムゾーンがバラバラだったり、フォーマットが細かく異なったりします。
4. インシデント直後は疲弊している
そもそもこの準備作業、インシデント対応が終わった直後にやることが多いです。長時間の対応で疲弊した状態で冷静に情報を整理するのは、精神的にも体力的にもしんどいものがあります。
なぜコーディングエージェントが向いているのか
多くの方はご存知かと思いますが、コーディングエージェントの強みは単にコードを実装することだけではありません。私は、「分断された情報源を横断してデータを収集し、それらを構造化できること」がコーディングエージェントの強みの一つだと考えています。
gh コマンドを叩いて GitHub の PR を取得し、MCP サーバー経由で Slack のログを引っ張り、Datadog の API からメトリクスを収集し、それらをソースコードと紐付けてインシデントについて整理する作業では、コーディングエージェントの強みを大きく活かすことができます。
実際、Google Cloud の SRE チームは Gemini CLI でインシデントの会話履歴・メトリクス・ログからポストモーテムを自動生成しています（InfoQ, 2026）。Datadog の Bits AI SRE はアラート発火時に自律的にランブックやテレメトリを分析し、オンコール担当者がログインする前に結論を出します（Datadog Blog, 2025）。
ただし「ポストモーテムを書いて」では機能しない
エージェントに丸投げしても、使い物にはなりません。スキルを設計しないと2つの問題が起きます。
表層的な分析で終わる
多くの場合、コーディングエージェントにインシデントの根本原因を問うても、表層的な結果を返されてしまいます。人間が自分の意図を伝えなければ、コーディングエージェントは世の中に広く共有されている一般論と眼前のインシデントを直接的に紐づけるぐらいで精一杯になりがちです。
コンテキストが爆発する
Slack の全メッセージ、Datadog の全アラート、GitHub の全 PR を一度にコンテキストに詰め込むと、コンテキストウィンドウが溢れて情報の取捨選択が雑になります。関連情報がコンテキストの中間部分に埋もれると正確性が30%以上低下する “Lost in the Middle” 問題も知られています。
どのエージェントのコンテキストウィンドウに何を載せ、何を載せないか、慎重に設計する必要があります。
Claude Code スキルによるアプローチ
Claude Code のカスタムスキルを使えば、/postmortem のようなスラッシュコマンドを定義してポストモーテム準備を自動化できます。
カスタムスキルとは
.claude/skills/<skill-name>/SKILL.md に Markdown で定義するプロンプトテンプレートです。/skill-name で呼び出すと、そのプロンプトに基づいて Claude が動きます。
$ARGUMENTSで呼び出し時の引数を受け取れる!`command`で事前にシェルコマンドを実行し、結果をプロンプトに注入できる- Agent ツールでサブエージェントを並列に走らせられる
- 設定済みの MCP サーバー経由で外部サービスにアクセスできる
全体のフロー
ユーザー: /postmortem INC-1234
1. スキルがインシデントIDを受け取る
2. 情報収集フェーズ（サブエージェントで並列実行）
├─ Agent A: Slack からインシデントチャンネルのログを取得
├─ Agent B: Datadog からアラート・メトリクスを取得
├─ Agent C: Jira からチケット情報を取得
└─ Agent D: GitHub から関連 PR・Issue を取得
3. 要約・構造化フェーズ（別のサブエージェント）
└─ 収集した情報を統合し、テンプレートに落とし込む
4. ポストモーテムのドラフトを出力
5. 人間によるレビューと加筆情報収集をサブエージェントで並列化しているのがミソです。逐次アクセスに比べて時間を短縮できるのに加え、コンテキスト爆発を構造的に防げます。詳しくは指針1で説明します。
スキルの設計指針
指針1: 情報収集はサブエージェントで並列化する
各データソースへのアクセスは互いに独立しているので、サブエージェントで並列に走らせます。
## 情報収集
以下のサブエージェントを**並列**で起動し、情報を収集してください。
### Slack ログの収集
Agent ツールを使い、MCP 経由で Slack のインシデントチャンネル
(#incident-$ARGUMENTS) から以下を取得してください:
- インシデント発生から解決までの全メッセージ
- 対応者のアクションと判断のポイント
### Datadog アラートの収集
Agent ツールを使い、CLI (`datadog-ci`) 経由で Datadog から以下を取得してください:
- インシデント期間中に発火したアラートの一覧
- 関連するメトリクスの変化
### Jira チケットの収集
Agent ツールを使い、MCP 経由で関連する Jira チケットを取得してください。
### GitHub 変更の収集
Agent ツールを使い、CLI (`gh` コマンド) 経由で
インシデント前後の PR・デプロイを取得してください。並列化の利点は時間短縮だけではありません。むしろ、コンテキスト爆発を構造的に防げることの方が大きいです。
Slack のインシデントチャンネルだけで数百メッセージ、Datadog のアラートログも数十件になることは珍しくありません。これを全部メインのコンテキストに流し込めば、たちまちコンテキストウィンドウが逼迫します。
サブエージェントは独立したコンテキストウィンドウを持っています。各サブエージェントが膨大な生データを読み込み、その中で要約・取捨選択を行った結果だけをメインに返す。メインのコンテキストはクリーンなまま保たれます。
CLIを優先し、MCPは必要な場合に使う
外部データソースへのアクセス手段として MCP サーバーと CLI の2つがありますが、2026年時点のベンチマークでは CLI の方がタスク完了率28%高、トークン効率33%優という結果が出ています（jannikreinhard.com）。
MCP サーバーはツール定義をすべてコンテキストに読み込みます。たとえば GitHub の MCP サーバーは93ツールで約55,000トークンを消費します。一方、gh CLI は必要なコマンドだけ実行して予測可能な出力を返してくれます。
gh、jira-cli、datadog-ci などの CLI が使える場面ではそちらを優先し、CLI では対応しにくい Slack のメッセージ取得や Confluence のページ取得には MCP を使うのが現実的でしょう。
サブエージェントの数は2〜4に抑える
Azure SRE Agent チームは当初100以上のツールと50以上のサブエージェントで構築しましたが、エージェントが多すぎてオーケストレーターが適切なエージェントにタスクを振り分けられない問題、1つのエージェントのプロンプトを変更すると他のエージェントの挙動まで壊れてしまう連鎖的な不具合、エージェント間でタスクをたらい回しにする無限ループに直面しています。結局、少数のジェネラリストエージェントに集約して劇的に改善したそうです（Microsoft Tech Community）。
Claude Code のサブエージェントも2〜4程度が妥当です。それ以上に増やしてもオーケストレーションが複雑になるだけで、見合ったリターンがありません。
指針2: 収集した情報は別のサブエージェントで要約する
各サブエージェントが返す収集結果はある程度整理されていますが、データソースをまたいだ統合が必要です。収集と要約を別のサブエージェントに分けると、それぞれのタスクに集中でき、出力の質が上がります。
## 要約・構造化
収集した情報を以下の構造に整理してください:
### タイムライン
各データソースのタイムスタンプを突き合わせ、以下のカテゴリに
分類して時系列順に整理してください:
- エンバグ（原因となった変更のデプロイ等）
- 障害発生
- 障害検知（アラート発火、ユーザー報告等）
- 顧客周知（ステータスページ更新等）
- 止血対応（ロールバック、フェイルオーバー等）
- 原因調査
- 復旧
形式: `HH:MM` [カテゴリ] イベント内容（情報源）
### 影響範囲
- 影響を受けたサービス・機能
- 影響を受けたユーザー数の推定
- ビジネスインパクト
### 対応アクション
- 誰が、いつ、何をしたか
- 判断のポイントとその根拠収集サブエージェントは「できるだけ多くの関連情報を拾う」ことに専念し、要約サブエージェントは「拾った情報を構造化する」ことに専念する。責務の分離です。
指針3: 出力を検証可能にする
AI にドラフトを生成させた後、「レビューして修正して」と指示すれば品質が上がると思うかもしれません。しかし RefineBench の評価（2025-2026）によると、LLM のセルフレビューによる改善は5回の反復で+1.8ポイント以下です。「何度もレビューさせれば良くなる」というのは幻想です。
Zalando のポストモーテム分析では、高性能モデルでも約10%の表面帰属エラーが残りました。インシデントに関連するキーワードが文中に出てくるだけで、実際には因果関係がないのにあるかのように書いてしまう現象です（Zalando Engineering Blog, 2025）。
セルフレビューに期待しすぎるよりも、人間が検証しやすい形で出力する方が確実です。
なお、LLM は Markdown の表形式を好む傾向がありますが、日本語のタイムラインでは表のカラムが崩れやすいので、箇条書きで出力させる方が無難です。障害検知、止血対応などのカテゴリをラベルとして付与すれば、箇条書きでも十分に見通しがよくなります。
## Step 4: 検証可能な形で出力する
タイムラインの各項目には、必ず情報源を明記してください:
- `10:23` [障害検知] アラート発火（Datadog: monitor-12345）
- `10:25` [障害検知] #incident-INC-1234 作成（Slack: msg-ts-xxx）
- `10:30` [止血対応] ロールバック PR 作成（GitHub: PR #456）
- `10:32` [止血対応] ロールバック PR マージ（GitHub: PR #456）
- `10:45` [復旧] エラーレート正常値に復帰（Datadog: dashboard-789）
人間がドラフトをレビューする際に、各記述の根拠を即座に
確認できることが最も重要です。Zalando のチームは当初100%の人間キュレーションを行い、徐々に10〜20%のサンプリングに移行しました。最初から全面的に任せるのではなく、信頼を段階的に築いていくやり方です。
指針4: テンプレートはチームの既存フォーマットに合わせる
ポストモーテムのテンプレートは組織ごとに異なります。スキルには自チームのテンプレートを埋め込んでおきましょう。
## 出力フォーマット
以下のテンプレートに沿ってポストモーテムのドラフトを作成してください。
### タイトル
[日付] インシデント概要
### サマリー
- 何が起きたか（1-2文）
- 影響範囲
### タイムライン
- `HH:MM` [カテゴリ] イベント内容（情報源）
- カテゴリ: エンバグ / 障害発生 / 障害検知 / 顧客周知 / 止血対応 / 原因調査 / 復旧
### 影響
- 影響を受けたサービス
- 影響を受けたユーザー
- ダウンタイム
### 寄与要因 Contributing Factors
（人間が記入）
### 再発防止策
（人間が記入）
### 教訓
（人間が記入）テンプレートの「根本原因」というセクション名は再考した方がよいかもしれません。複雑な分散システムのインシデントで単一の根本原因が見つかることはまれです。PagerDuty/Jeli の Howie Guide や Learning from Incidents コミュニティでは 根本原因 ではなく 寄与要因 が推奨されています。たった1つの原因を探すより、複数の寄与要因を列挙する方が実態に合います。
指針5: 人間が担うべき部分を明示的に残す
ここが一番大事な指針です。
AI は情報の収集と整理が得意です。散在する情報源から関連データを引っ張ってきて、時系列に並べて構造化する作業は、人間がやるより AI が担う方が圧倒的に速いです。
一方、以下は人間が担うべきです。
- 寄与要因の分析: なぜこのインシデントが起きたのか、技術的な要因だけでなく、組織やプロセスの要因も含めた分析
- 再発防止策の策定: 何をすれば再発を防げるか、優先度をつけて計画する意思決定
- 教訓の抽出: チームとして何を学んだか、文化や仕組みにどう反映するか
- ナラティブの記述: 対応者がどんな状況で判断を迫られ、何を考えていたか
テンプレートにこれらの項目を「（人間が記入）」と残しておけば、AI と人間の役割分担が自然にできます。incident.io もこのアプローチで、AI が構造化された80%を生成し、人間が10〜15分でナラティブと洞察を追加する形をとっています。
ポストモーテムの価値は寄与要因の分析と再発防止策の議論にあります。準備の自動化は、チームがその議論に集中するための手段にすぎません。
指針6: セキュリティを考慮する
AI エージェントに本番環境のモニタリングツールやコミュニケーションツールへのアクセスを与えるなら、セキュリティには気を配る必要があります。
2025年の調査では MCP 実装の43%にコマンドインジェクション脆弱性が見つかっています（Equixly Security Assessment）。MCP サーバーのツール説明文にユーザーから見えない悪意ある指示を仕込む「ツールポイズニング」攻撃も報告されています。
最低限、以下は守っておきたいところです。
- 最小権限の原則: エージェントに与える権限は読み取りのみに絞る。New Relic の SRE Agent は「本番システムを変更しない、承認フローをバイパスしない、人間の判断を上書きしない」という制約を意図的に設けています
- MCP サーバーの検証: 信頼できるソースの MCP サーバーのみ使い、ツール定義が変更されていないか定期的に確認する
- 自動承認を無効にする: 本番ツールへのアクセスにはユーザーの明示的な許可を必須にする
スキルの実装エッセンス
/postmortem スキルの SKILL.md の骨格を示します。実際の環境に合わせて MCP サーバーの設定やテンプレートを調整してください。
---
name: postmortem
description: インシデントIDを受け取り、各種データソースから情報を収集してポストモーテムのドラフトを生成する
user-invocable: true
disable-model-invocation: true
allowed-tools: Agent, Read, Write, Bash, Grep, Glob
argument-hint: [incident-id]
---あなたはポストモーテムの準備を支援するアシスタントです。
インシデントID: $ARGUMENTS
## Step 1: 情報収集（並列実行）
以下のサブエージェントを **並列** で起動してください。
各エージェントは、取得した情報を要約して返してください。
生データをそのまま返さないでください。
1. **Slack ログ収集**: #incident-$ARGUMENTS チャンネルの
メッセージを取得し、主要なアクションと判断を時系列で要約
2. **アラート収集**: `datadog-ci` CLI でインシデント期間中の
アラートを取得し、発火時刻と内容を一覧化
3. **チケット収集**: MCP 経由で関連する Jira チケットの
ステータスと概要を取得
4. **コード変更収集**: `gh` CLI でインシデント前後の
PR とデプロイを取得し、変更内容を要約
## Step 2: 要約・構造化
収集結果をもとに、タイムラインを時系列順に構成し、
影響範囲と対応アクションを整理してください。
タイムラインの各項目には必ず情報源を明記してください。
## Step 3: ドラフト出力
チームのテンプレートに沿ってポストモーテムのドラフトを出力してください。
「寄与要因」「再発防止策」「教訓」は人間が記入する欄として空けてください。disable-model-invocation: true にしているのは、このスキルが外部データソースにアクセスする副作用を持つためです。ユーザーが明示的に /postmortem を実行したときだけ動くようにし、Claude が勝手に呼び出すのを防ぎます。
注意: AI はトイルを増やすこともある
2025年の調査（Runframe: State of Incident Management 2025）によると、AI 投資にもかかわらず運用トイルは25%から30%に上昇しました。うまく統合されなければ、AI ツールは既存の作業を減らすどころか検証のオーバーヘッドを新たに生みます。
ポストモーテムの準備スキルを導入しても、「AI の出力を人間が検証する」という新しい作業は発生します。それが手作業での準備より本当に軽いかどうかは、チームの環境と MCP サーバー/CLI の整備状況次第です。
小さく始めて、実際に準備時間が短縮されるか確認しながら改善していくのがよいかと思います。Google Cloud の SRE チームのように、生成されたポストモーテムを次回以降の参考データとして蓄積する「フィードバックループ」を組めれば、スキルの品質は回を重ねるごとに上がっていきます。
まとめ
この記事で紹介した設計指針は6つです。
- 情報収集はサブエージェントで並列化する
コンテキスト爆発を構造的に防ぐ。 CLI優先、サブエージェントは2〜4 - 収集と要約を分ける
責務の分離 - 出力を検証可能にする
セルフレビューの限界を踏まえ、情報源を明記する - テンプレートはチームに合わせる
「根本原因」より「寄与要因」を - 人間が担う部分を残す
AI は情報収集、人間は分析・判断・ナラティブ - セキュリティを考慮する
最小権限、MCP検証、自動承認の無効化```
準備の自動化は、チームが寄与要因の分析と再発防止策の議論に集中するための手段にすぎません。