# Incident Responder

> 本番障害・インシデントの対応進行（タイムライン記録・影響評価・止血）とポストモーテム（根本原因分析・非難なき振り返り）を支援するスキル。「障害対応」「インシデント対応」「ポストモーテムを書いて」「障害報告書を作って」「根本原因を分析して」「なぜなぜ分析して」「RCAして」「再発防止策をまとめて」などで発動する。

- Skill: `ynitto/incident-responder` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ynitto/incident-responder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ynitto/incident-responder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ynitto (https://skillmd.com/u/ynitto)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ynitto/incident-responder

---


# incident-responder

本番インシデントの **対応進行** と、収束後の **ポストモーテム（事後分析）** を支援する。目的は犯人探しではなく、事実の時系列化・根本原因の特定・再発防止である（blameless）。

> コード内のバグ調査は `systematic-debugging`。本スキルは「本番で何が起きているか／起きたか」の運用・組織プロセスを扱う。

## 原則

- **非難なき（blameless）** — 個人ではなく仕組み・プロセスの欠陥に焦点を当てる
- **事実と推測を分ける** — タイムラインは観測事実で構成し、仮説は仮説として明記する
- **影響を先に評価** — 何が・誰に・どれだけ影響しているか（範囲・深刻度）を最初に確定する
- **暫定と恒久を分離** — 止血（mitigation）と根本対応（remediation）を混同しない

## ワークフロー

### モード判定

依頼が「対応中（active）」か「事後分析（postmortem）」かをまず見分ける。

### モードA: 対応進行（インシデント発生中）

1. **検知と宣言**: 何が観測されたか・いつ・どこで。深刻度を [references/postmortem-template.md](references/postmortem-template.md) の重大度基準で仮設定する
2. **影響評価**: 影響範囲（ユーザー数・機能・データ）、ビジネス影響、進行中か収束したか
3. **役割の明確化**: 指揮（IC）・実作業・記録・対外連絡の担当を確認する（小規模なら兼務）
4. **止血を優先**: ロールバック・フィーチャーフラグ off・スケールアウト・トラフィック制御など、根本原因が未特定でも被害を止める手を検討する
5. **タイムライン記録**: 時刻つきで「観測した事実」「実施した対応」「結果」を逐次記録する（後のポストモーテムの一次資料）
6. **収束確認とコミュニケーション**: 復旧の確認基準を決め、関係者・ユーザーへの告知文面を整える

### モードB: ポストモーテム（収束後）

1. **タイムライン再構成**: 検知→対応→収束を時系列で確定（ログ・記録・関係者証言から）
2. **根本原因分析**: 5 Whys や寄与要因分析で「なぜ起きたか」「なぜ防げなかったか」「なぜ検知が遅れたか」を多層で掘る。単一犯人で止めない
3. **検知・対応の評価**: MTTD/MTTR、検知手段は適切だったか、対応はスムーズだったか
4. **再発防止策（アクションアイテム）**: 恒久対応を担当・期限つきで。優先度を付け、検知改善（アラート）も含める
5. **ポストモーテム文書化**: テンプレートに従い出力。`meeting-minutes` のアクションアイテム形式と整合させ、`redmine-use` 等でのチケット化を提案する

## ガードレール

| 制限 | 内容 |
|------|------|
| 非難の禁止 | 個人名を責める表現を避け、仕組み・プロセスの言葉に置き換える |
| 事実性 | タイムラインに推測を混ぜない。不明な時刻・原因は「不明/要調査」と明記 |
| 二次被害防止 | 対応中の破壊的操作（DB変更・削除）は影響を確認し、可逆性とバックアップを問う |
| 越権しない | 実際のロールバック/本番操作はユーザー承認のもとで。手順の提示に留める |