Claudeのincident-responseスキルで障害対応とポストモーテムを回す
Anthropic公式のengineeringプラグインに入っているincident-responseスキルを、導入、重大度の4段階、状況更新とポストモーテムの出力型、監視・PagerDuty・Slackとの接続まで順にたどります。
Claudeのincident-responseスキルで障害対応とポストモーテムを回す
incident-responseは、Anthropicが公開しているengineeringプラグインのスキルです。障害の検知からポストモーテム(事後振り返り)までを、1つの流れで支えます。重大度の判定、状況更新の文面、非難なしのポストモーテムの型があらかじめ入っています。
使い方は単純です。/incident-response new で始め、update で途中経過を出し、postmortem で振り返りを起こします。この記事では、導入、4つの段階、出力の型、接続できるツールを順に見ます。
incident-responseスキルとは — engineeringプラグインの6スキルのひとつ
engineeringプラグインは、Anthropicのknowledge-work-pluginsリポジトリにある公式プラグインです。ソフトウェア開発向けで、READMEには、主にCowork向けに設計されていて、Claude Codeでも動くと書かれています。
入っているスキルは6つです。
| スキル | 役割 |
|---|---|
code-review | 役割バグ・セキュリティ・性能・保守性の確認 |
incident-response | 役割本番障害の初動、状況更新、ポストモーテム |
system-design | 役割アーキテクチャ図、API設計、データモデル |
tech-debt | 役割技術的負債の分類と優先順位づけ |
testing-strategy | 役割単体・結合・E2Eのテスト計画 |
documentation | 役割README、APIドキュメント、runbook、オンボーディング資料 |
incident-responseのSKILL.mdには、起動のきっかけが具体的に書かれています。「インシデントが起きた」「本番が落ちている」と話しかけたとき、重大度の判定が要るアラートが来たとき、障害の途中で状況更新が要るとき、解決後に非難なしのポストモーテムを書くときです。
同じ領域を別の側面から扱う記事は、すでにいくつかあります。インシデント管理サービスと接続して経過を読ませるならincident.io連携、オンコールの運用ならPagerDutyのOn-Call Managerです。本記事の主題は、サービスを問わずに使える手順書としてのスキルそのものです。
導入 — marketplaceを足してプラグインを入れる
導入はリポジトリのREADMEにある2行です。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-pluginsmarketplaceの仕組み自体はClaude Codeのプラグインmarketplaceの記事にまとめています。同じknowledge-work-pluginsから別のプラグインを入れる流れは、small-businessプラグインの記事と同じです。
READMEの/incidentは、スキル側では/incident-response
READMEのCommands表には/incidentが載っています。ところがSKILL.md自身の見出しと使用例は/incident-responseです。engineeringディレクトリを見ると、置かれているのはskillsフォルダーで、/incidentに対応するcommandsのファイルは置かれていません。
実際に呼ぶ名前は、入れたあとのスラッシュコマンド一覧で確かめるのが確実です。この記事では、SKILL.mdの記載に合わせて/incident-responseと書きます。
4つの段階 — 検知から振り返りまでの流れ
SKILL.mdは、障害対応を4つの段階に分けています。
incident-responseの4段階
- 1
トリアージ
重大度をSEV1〜4で判定し、影響を受けるシステムとユーザーを洗い出し、指揮役(IC)・連絡役・対応者を割り当てます。
- 2
連絡
社内向けの状況更新を下書きし、必要ならお客様向けの連絡も下書きします。会議用のチャンネル(war room)と更新の間隔も決めます。
- 3
緩和
とった対処を記録し、出来事の時系列を追い、解決を確認します。
- 4
ポストモーテム
非難なしの文書として、時系列の再構成、5回のなぜによる原因分析、担当者つきの再発防止策をまとめます。
3つのモードがあり、モードを指定しないと「いまインシデントのどの段階か」を聞かれます。
| モード | 使う場面 |
|---|---|
new [説明] | 使う場面新しいインシデントを始める |
update [状況] | 使う場面途中経過を共有する |
postmortem | 使う場面インシデントの情報からポストモーテムを作る |
重大度の4段階 — 応答時間つきの基準
トリアージの基準は表で固定されています。
SEVごとの応答時間の目安
SEV1
即時・総動員
サービス停止、全ユーザーに影響
SEV2
15分以内
主要機能が劣化、多数に影響
SEV3
1時間以内
軽微な機能の問題、一部に影響
SEV4
翌営業日
見た目や低影響の問題
この表は出発点です。自社のSLOや契約上の約束と食い違うなら、プロンプトの冒頭で自社の基準を渡しておく運用が考えられます。たとえば次のように書きます。
/incident-response new
決済APIが503を返している。5分前から。
重大度は当社基準で判定して:
- SEV1: 決済が全面停止
- SEV2: 決済の一部手段が失敗、または遅延が30秒超例示であり、スキルが独自基準を受け取る書式は公式に定められていません。渡した基準に沿って判定してもらうという使い方です。
状況更新の型 — 「次の更新はいつか」まで入れる
通信のガイダンスは短く、「何が起きているか、誰に影響があるか、何をしているか、次の更新はいつか」の4点を定期的に出すことです。updateで出力される型は次のとおりです。
## Incident Update: [Title]
**Severity:** SEV[1-4] | **Status:** Investigating | Identified | Monitoring | Resolved
**Impact:** [Who/what is affected]
**Last Updated:** [Timestamp]
### Current Status
### Actions Taken
### Next Steps
### Timeline
| Time | Event |状態はInvestigating(調査中)、Identified(原因特定)、Monitoring(監視中)、Resolved(解決)の4つです。更新のたびに同じ型で出るので、読む側は毎回同じ場所を見ればよくなります。
updateの入力は、貼り付けた断片で足ります。
/incident-response update
原因はキャッシュ更新ジョブの暴走と判明。ジョブを停止してレイテンシは戻りつつある。ポストモーテムの型 — 非難なしと5回のなぜ
postmortemは、次の見出しを持つ文書を出します。
ポストモーテムの構成
概要・影響
日付、継続時間、重大度、作成者、状態(初期値はDraft)。平易な2〜3文の要約と、影響を受けたユーザー、影響の継続時間、数値化できる事業影響を書きます。
時系列・根本原因
時系列はUTCの表です。根本原因は詳しい説明と、「なぜ」を5回たどる欄の2本立てです。
うまくいったこと・いかなかったこと
両方を分けて書く欄があります。
再発防止策・学び
担当者、優先度(P0/P1/P2)、期限を持つ表と、チームへの教訓の欄です。
5回のなぜは、症状から始めて原因を1つずつさかのぼる形式です。たとえば「決済が503を返した」から始め、「接続プールが枯渇した」「ジョブが想定外に走った」と進めます。最後の「なぜ」に根本原因を書く形です。
SKILL.mdの「ヒント」は3行です。完全な情報を待たずにすぐ書き始めること。更新は事実だけにして推測を入れないこと。ポストモーテムは非難なしで、個人ではなく仕組みと手順に焦点を当てること。
誰かの名前が入りそうなときのプロンプト
ポストモーテムの表には作成者と担当者の欄があります。一方で本文は個人を責めない前提です。Slackの会話をそのまま貼ると、個人名が原因の主語になる文章ができやすくなります。次のように指示しておくと、主語を仕組みに寄せられます。
/incident-response postmortem
下のSlackログから作って。原因の記述は個人名ではなく
「手順」「設計」「監視」を主語にして。担当者は再発防止策の欄だけに書く。Slackログからの起こし方はSlackログから障害報告書を起こす記事に詳しくあります。
つなげるツール — 監視、PagerDuty、Slackまで
engineeringプラグインは、ツールを接続しなくても動きます。incident-responseも、障害の状況を自分で説明すれば使えます。接続すると次のことが加わります。
| 接続の種類 | できること |
|---|---|
| 監視 | できることアラートの詳細とメトリクスを取得し、影響を受けた指標のグラフを出す |
| インシデント管理 | できることPagerDuty・Opsgenieで障害を作成・更新し、オンコールを呼び出す |
| チャット | できること障害用チャンネルに状況更新を投稿し、war roomのチャンネルを作る |
プラグインの.mcp.jsonには、Slack、Linear、Asana、Atlassian、Notion、GitHub、PagerDuty、Datadogの接続先が最初から入っています。CONNECTORS.mdの対応表では、監視の同梱はDatadog、インシデント管理の同梱はPagerDutyです。代替候補は、監視がNew Relic・Grafana・Splunk、インシデント管理がOpsgenie・Incident.io・FireHydrantとされています。
監視側をDatadogにするなら、接続の手順はDatadog MCPをClaude Codeにつなぐ記事が扱っています。別の監視ツールであるDynatraceで障害を調べる手順はDynatrace MCPの記事にあります。
接続すると書き込みが起きる点に注意
「障害を作成・更新する」「チャンネルに投稿する」「オンコールを呼び出す」は、読み取りではなく書き込みです。誤った重大度でページを飛ばすと、実際に人が起こされます。
試すときは、まず接続せずに状況を説明するだけで下書きを作り、文面と重大度に問題がないことを見てから接続する順番が安全です。
日々の運用に組み込む — 練習用のインシデントで先に試す
障害が起きてから初めてスキルを使うと、型の読み方で手間取ります。過去の小さな障害の記録を使い、postmortemだけ先に試しておくと、本番の最中に迷いません。
見る点は3つです。
- 時系列が、貼った情報から外れていないか
- 5回のなぜが、4回目以降で仕組みの話になっているか
- 再発防止策に、担当者と期限が入っているか
足りないところは、プロンプトに追加の条件として渡します。自社のテンプレートが決まっているなら、見出しの構成を貼って「この見出しで」と指定すると、スキルの型より優先して整えてもらえます。
まとめ — 型を借りて、判断は人が持つ
incident-responseが用意するのは、重大度の基準、状況更新の型、ポストモーテムの型です。何がSEV1か、誰を起こすか、顧客へどこまで伝えるかの判断は、人の側に残ります。
接続なしでも使えるので、最初はポストモーテムの下書きから試すのが入りやすい選び方です。READMEの/incidentとSKILL.mdの/incident-responseのように表記が揺れている箇所があるため、実際の名前はインストール後の一覧で確かめられます。