incident-response について
技術スタックやツールに依存せず、本番インシデントの検知から解決までを調整するスキルです。段階的な手順、役割、緩和策、コミュニケーション方法を示します。
主な機能
- 015段階のインシデント対応手順
- 02重大度の評価とエスカレーション
- 03役割と意思決定権限の定義
- 04緩和策と検証の指針
- 05社内および顧客への連絡方法
活用シーン
- 01進行中の本番インシデントへの対応
- 02重大度と対応手順の策定
- 03オンコール体制と役割の設定
- 04インシデント調整のチーム研修
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/incident-responseを入力して読み込まれたか確認します。
同梱ファイルREADME.mdreferences/incident-playbook.md
詳細
インシデント対応
検知から解決まで、進行中の本番インシデントに対応します。技術スタックに依存しません。ツールに依存しません。
このスキルは、進行中のインシデントとインシデント対応プロセスを対象としています。事後分析には after-action-report を、計画済みのローンチには launch-runbook を使用してください。
使用するタイミング
- 進行中のインシデントが発生している
- インシデント対応手順を構築する
- 重大度レベルを定義する
- オンコールローテーションを設定する
- チームにインシデント対応のトレーニングを行う
使用しないタイミング
- インシデント後の振り返り（
after-action-reportを使用してください） - 計画済みのローンチ（
launch-runbookを使用してください） - ローンチ前の問題のトリアージ（
qa-testingを使用してください）
必要な入力
- インシデントの認知（アラート、顧客からの報告、社内での発見）
- 本番システムと監視へのアクセス
- 明確に定義された役割と権限
- 利用可能なコミュニケーションチャネル
フレームワーク：5 つのフェーズ
1. 検知
インシデントがどのように認識されるか。
検知元：
- 自動アラート（監視、SLO 違反、エラー率の急上昇）
- 顧客からの報告（サポートチケット、ソーシャルメディア、ステータスページの登録者）
- 社内での発見（エンジニアが異常に気づく）
- サードパーティ（セキュリティ研究者、パートナー）
検知したら：
- 目標時間内に受領を確認します（重大なインシデントでは通常 5〜15 分以内）
- 重大度を評価します（下記の重大度基準を参照）
- まだページングされていない場合は、オンコール担当者にページを送ります
- インシデントチャンネルを開設します
2. トリアージ
重大度と影響を確認します。
重大度基準：
| 重大度 | 定義 | 対応 |
|---|---|---|
| SEV-1（重大） | 顧客向けの主要機能が停止。データ整合性が危険にさらされている。セキュリティ侵害。 | 全員で対応。インシデントコマンダーを配置。ウォールームを稼働。一般向けの告知が必要。 |
| SEV-2（大） | 大幅な性能低下。一部の顧客に影響。収益への影響。 | インシデントコマンダーを任命。積極的に対応。社内に連絡。一般向けの告知が必要な場合と不要な場合がある。 |
| SEV-3（小） | 影響は限定的。回避策がある。少数のユーザーに影響。 | 通常のオンコール対応。担当者は 1 名。 |
| SEV-4（低） | 見た目上の問題、エッジケース、または発生頻度が低い問題。緊急の対応は不要。 | バグとして追跡。通常の対応キューで処理。 |
重大度は変更される場合があります。新たな情報が得られたら再評価してください。
3. 緩和
原因を修正する前に、まず影響を食い止めます。
緩和策（完全な修正より迅速）：
- ロールバック（最近のデプロイを元に戻す）
- フィーチャーフラグをオフにする（デプロイせずに問題のある機能を無効化）
- フェイルオーバー（正常なレプリカまたはリージョンにトラフィックを振り分ける）
- スケールアップ（負荷を吸収できるように容量を増やす）
- スロットリング（残りを保護するため、一部のトラフィックを拒否する）
- グレースフルデグラデーション（コア機能を維持するため、重要でない機能をオフにする）
- メンテナンスモード（最後の手段。すべてのユーザーをブロックする）
緩和の原則： まずユーザーへの影響を止めます。原因分析はその次です。
4. コミュニケーション
インシデント中の連絡対象は 3 つです。
社内チーム：
- インシデントチャンネルでリアルタイムに更新
- 頻度：インシデント対応中は最低 15 分ごと
- 形式：タイムスタンプ付きの状況報告。判明していること、実施中の対応、完了見込み時間を含めます
社内の関係者：
- より広い組織に向けた概要レベルの更新
- 頻度：30〜60 分ごと
- 形式：技術的な詳細ではなく、ビジネスへの影響を中心に説明します
社外／顧客：
- ステータスページを更新
- 頻度：インシデント対応中は最低 30 分ごと
- 形式：平易な表現を使い、責任の追及は避け、ユーザーが経験していることと今後の見通しを伝えます
コミュニケーションの原則：
- 回答がなくても、まず認識していることを伝えます（「問題を認識しており、調査中です」）
- 進展がなくても予定どおりに更新します（「引き続き調査中です。新しい情報はありません」）
- 原因を公に推測しないでください
- 復旧したら、解決したことを明確に伝えてください
5. 解決
修正を検証し、お客様への影響を解消して、インシデントをクローズします。
解決の基準：
- 緩和策が実施され、検証されている
- 根本原因が特定されている（または AAR で扱うことが明示的に保留されている）
- 影響を受けたすべてのシステムが正常な状態に戻っている
- お客様が通常どおり利用を再開できる
- 最終状況の更新が投稿されている（社内および社外）
- インシデントチャンネルをクローズできる（または AAR 用にアーカイブできる）
クローズ後：
- 1～2 週間以内に AAR を予定する
- 記憶が新しいうちに初期タイムラインを記録する
- フォローアップの対応項目を管理する
インシデント対応中の役割
| 役割 | 責任 |
|---|---|
| インシデントコマンダー（IC） | 対応全体を統括します。判断を下し、作業を割り当てます。必ずしも最も技術に詳しい人である必要はありませんが、調整能力が必要です。 |
| コミュニケーションリード | 社内外への情報発信を統括します。IC のコミュニケーション負担を軽減します。 |
| オペレーションリード | 技術調査と緩和策を主導します。多くの場合、オンコール担当者の中で最も上級のエンジニアが務めます。 |
| 記録係 | インシデントの進行に合わせてタイムラインを記録します。AAR に不可欠です。 |
| 分野の専門家 | 必要に応じて参加します。サービスオーナー、データベースの専門家、セキュリティの専門家などです。 |
小規模なチームや重大度の低いインシデントでは、1 人が複数の役割を担うことができます。その場合も、各役割の責任を明確にしてください。
インシデント中の意思決定
IC の権限：
- ロールバックやその他の緩和策を指示する
- 追加の担当者を呼び入れる
- 重大度を引き上げる
- 選択肢が不明確な場合に判断を下す
避けるべき判断の先送り：
- 緩和策があり、影響が発生しているのに「しばらく様子を見ましょう」とする
- ユーザーに影響が出ている最中に根本原因を議論する（まず緩和する）
- 検証前に解決を早まって発表する
- 委員会方式での停滞（多くの人を招集するものの、誰も決断しない）
迷ったときは、行動してください。ユーザーが被害を受け続ける中で何もしないより、ロールバックできる誤った行動のほうがましです。
ステータスページでのコミュニケーションパターン
初回：
「[issue] の報告について調査しています。続報をお知らせします。」
特定済み：
「[scope] に影響する問題を特定しました。エンジニアが修正に取り組んでいます。次回の更新は [time] までに行います。」
監視中：
「修正を適用しました。解決を確認するため監視しています。次回の更新は [time] までに行います。」
解決済み：
「このインシデントは解決しました。サービスは復旧しています。詳細なインシデントレポートを [timeframe] 以内に投稿します。」
避けるべきパターン：
- 曖昧な表現（「いくつかの問題が発生しています」―どのような問題ですか？）
- 影響範囲の記載漏れ（「ログインできません」―全地域ですか、それとも一地域だけですか？）
- 更新予定時刻の記載漏れ
- 検証せずに「まもなく解決する見込みです」と伝える
- 検証前に「復旧した」と伝える
ワークフロー
- 受領を確認する。 最初の対応者が目標時間内に受領を確認します。
- 重大度を評価する。 基準を使用します。適切な対応チャンネルを開きます。
- 役割を割り当てる。 最低限、IC、コミュニケーション、オペレーションを割り当てます。
- 情報を発信する。 初回の状況更新を行います。社内チャンネルでの対応を開始します。
- 調査する。 ログ、メトリクス、最近の変更を確認します。最も一般的な原因は、直近のデプロイ、設定変更、サードパーティ依存関係の変更、負荷の急増の 4 つです。
- 緩和する。 まず被害の拡大を止めます。根本原因の完全な特定を待たないでください。
- 緩和策を検証する。 ダッシュボードだけを信用せず、ユーザーの操作フローをテストします。
- 解決を伝える。 社内および社外に伝えます。
- インシデントをクローズする。 最終タイムラインを記録します。対応項目を管理します。
- AAR を予定する。 1～2 週間以内に実施します。
失敗のパターン
- 明確な IC がいない。 複数の担当者が調整なしに並行してデバッグします。対応が遅れ、互いに矛盾する変更が加えられやすくなります。
- 緩和策を講じず、いきなり根本原因の調査に進む。 エンジニアがデバッグしている間も、ユーザーは影響を受け続けます。
- 「すべて解決した」と早まって発表する。 検証前に解決を告知します。
- コミュニケーションが途絶える。 ユーザーは、誰かが対応しているのか分かりません。
- 状況報告が曖昧すぎる。 詳細を示さずに「対応中です」と伝えます。
- 原因を公の場で推測する。 多くの場合、推測は誤りであり、常に信頼を損ないます。
- 関係者を呼び込みすぎる。 調整にかかる負担が、その価値を上回ります。
- 書記役がいない。 時系列の記録が失われます。AAR ではチャットログから経緯を再構成する必要があります。
- 「軽微な」インシデントの AAR を省略する。 パターンを見落とし、教訓を何度も学び直すことになります。
- 非難する文化。 人々がミスを隠すようになり、インシデントの解決に時間がかかります。
出力形式
インシデント対応中：上記のフレームワークに従って、インシデントチャンネルとステータスページを更新します。
インシデント終結後：AAR に引き継ぐ、簡潔なインシデント概要を作成します。
# Incident: [Brief title]
**Date:** [YYYY-MM-DD]
**Severity:** [SEV-1 / 2 / 3 / 4]
**Duration:** [Detection to resolution]
**Customer impact:** [Who, how many, how, or state the gap per the data-availability rule]
## Summary
[1 to 2 paragraphs]
## Timeline
[Timestamped events]
## Mitigation
[What was done]
## Action items
[Follow-ups, with owners]
## AAR scheduled for
[Date]
必要なデータを利用できない場合
このスキルの出力は、それ自体では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合、認められる出力は、欠落している情報を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載します。成果物を完成させるために、必要な数値を捏造、推定、または補間することは認められません。欠落情報を明記すれば、それだけで完全な回答になります。
参考ファイル
references/incident-playbook.md- 重大度の定義、役割、ステータスページのテンプレート、判断基準。