incident-commander

インシデントコマンダーのスキル

カテゴリ： エンジニアリングチーム
ティア： 強力
作成者： Claude Skills Team
バージョン： 1.0.0
最終更新日： 2026年2月

概要

可用性／信頼性に関するインシデント（停止、性能低下、デプロイ失敗）に対応するインシデント対応フレームワークです。重大度の分類、タイムラインの再構成、インシデント後のレビューを行います。

これはセキュリティインシデントのトリアージではありません。 セキュリティイベント（ランサムウェア、侵入、データ持ち出し、IOC 分析、NIST SP 800-61 に基づくフォレンジック）については、incident-response に回してください。どちらのスキルも SEV1～SEV4 のラベルを使用しますが、このスキルは運用への影響（ユーザー、収益、SLA）を評価し、incident-response は攻撃の種類とフォレンジックの処理方法を分類します。

主な機能

• 重大度の自動分類 - 影響度と緊急度の指標に基づいて、インシデントをインテリジェントにトリアージします
• タイムラインの再構成 - 散在するログやイベントを、筋の通ったインシデントの経過にまとめます
• インシデント後レビューの作成 - 複数の RCA フレームワークに基づき、構造化された PIR を作成します
• コミュニケーションテンプレート - ステークホルダーへの状況報告やエスカレーションに使える、すぐに利用可能なテンプレートを提供します
• ランブックとの連携 - インシデントのパターンから、実行可能なランブックを生成します

含まれるスキル

コアツール

1. インシデント分類ツール (incident_classifier.py)

   • インシデントの説明を分析し、重大度を出力します
   • 対応チームと初動を推奨します
   • 重大度に応じたコミュニケーションテンプレートを生成します

2. タイムライン再構成ツール (timeline_reconstructor.py)

   • 複数のソースから、タイムスタンプ付きのイベントを処理します
   • インシデントの時系列を再構成します
   • 抜け落ちている箇所を特定し、所要時間を分析します

3. PIR 生成ツール (pir_generator.py)

   • 包括的なインシデント後レビュー文書を作成します
   • 複数の RCA フレームワーク（5 Whys、フィッシュボーン、タイムライン）を適用します
   • 実行可能なフォローアップ項目を生成します

インシデント対応フレームワーク

重大度分類システム

SEV1 - 重大なサービス停止

定義： すべてのユーザーまたは重要なビジネス機能に影響する、サービスの完全な停止

特徴：

• 顧客向けサービスが完全に利用できない
• ユーザーに影響するデータの損失または破損
• 顧客データの漏えいを伴うセキュリティ侵害
• 収益を生み出すシステムの停止
• 金銭的なペナルティを伴う SLA 違反

対応要件：

• オンコールエンジニアへ直ちにエスカレーション
• 5 分以内にインシデントコマンダーを任命
• 15 分以内に経営幹部へ通知
• 15 分以内に公開ステータスページを更新
• ウォールームを設置
• 必要に応じて全員で対応

コミュニケーション頻度： 解決するまで 15 分ごと

SEV2 - 重大な影響

定義： 一部のユーザーまたは重要度の低い機能に影響する、顕著なサービス低下

特徴：

• サービスの一部で性能が低下（ユーザーの 25% 超に影響）
• ユーザーに不満を生じさせるパフォーマンスの問題
• 重要度の低い機能が利用できない
• 生産性に影響する社内ツールの問題
• ユーザー体験には影響しないデータの不整合

対応要件：

• 15 分以内にオンコールエンジニアが対応
• 30 分以内にインシデントコマンダーを任命
• 30 分以内にステータスページを更新
• 1 時間以内にステークホルダーへ通知
• チームに定期的に状況を共有

コミュニケーション頻度： 対応中は 30 分ごと

SEV3 - 軽微な影響

定義： 回避策が利用でき、影響が限定的

特徴：

• 単一の機能またはコンポーネントに影響
• 影響を受けるユーザーは 25% 未満
• 回避策が利用可能
• UX に重大な影響を与えないパフォーマンスの低下
• 緊急性の低い監視アラート

対応要件：

• 営業時間中は 2 時間以内に対応
• 営業時間外は翌営業日の対応で可
• 社内チームへ通知
• 必要に応じてステータスページを更新

コミュニケーション頻度： 主要な節目のみ

SEV4 - 低影響

定義： 影響が最小限のもの、見た目上の問題、または計画済みのメンテナンス

特徴：

• 見た目上のバグ
• ドキュメントの問題
• ログ記録または監視の不足
• ユーザーに影響しないパフォーマンスの問題
• 開発／テスト環境の問題

対応要件：

• 1～2営業日以内に対応
• 標準的なチケット／課題管理
• 特別なエスカレーションは不要

コミュニケーション頻度： 標準的な開発サイクルに沿った更新

インシデントコマンダーの役割

主な責任

1. 指揮と統制

   • インシデント対応プロセスを統括する
   • リソース配分に関する重要な決定を行う
   • 技術チームとステークホルダーの間を調整する
   • すべての対応チームの状況を把握する

2. コミュニケーションの中核

   • ステークホルダーに定期的な更新を提供する
   • 外部とのコミュニケーション（ステータスページ、顧客への通知）を管理する
   • 対応チーム間の効果的なコミュニケーションを促進する
   • 対応担当者を外部からの妨げから守る

3. プロセス管理

   • インシデントの適切な追跡と記録を徹底する
   • 品質を維持しながら解決に向けて推進する
   • チームメンバー間の引き継ぎを調整する
   • 必要に応じてロールバック戦略を計画し、実行する

4. インシデント後のリーダーシップ

   • インシデント後のレビューを徹底して実施する
   • 再発防止策の実施を推進する
   • 得られた知見を組織全体で共有する

意思決定の枠組み

緊急時の意思決定（SEV1/2）：

• インシデントコマンダーが全面的な権限を持つ
• 分析よりも行動を優先する
• 後でレビューできるよう、決定事項を記録する
• 専門家に相談するが、その回答を待って対応を止めない

リソース配分：

• 必要なチームメンバーを招集できる
• 上級管理職へのエスカレーション権限を持つ
• 外部リソースの緊急支出を承認できる
• コミュニケーションチャネルとタイミングを決定する

技術的な意思決定：

• 実装の詳細については技術リードの意見を取り入れる
• スピードとリスクのトレードオフについて最終決定を行う
• ロールバックと修正継続の戦略を承認する
• テストと検証の方法を調整する

コミュニケーションテンプレート

インシデントの初回通知（SEV1/2）

Subject: [SEV{severity}] {Service Name} - {Brief Description}

Incident Details:
- Start Time: {timestamp}
- Severity: SEV{level}
- Impact: {user impact description}
- Current Status: {investigating/mitigating/resolved}

Technical Details:
- Affected Services: {service list}
- Symptoms: {what users are experiencing}
- Initial Assessment: {suspected root cause if known}

Response Team:
- Incident Commander: {name}
- Technical Lead: {name}
- SMEs Engaged: {list}

Next Update: {timestamp}
Status Page: {link}
War Room: {bridge/chat link}

---
{Incident Commander Name}
{Contact Information}

エグゼクティブサマリー（SEV1）

Subject: URGENT - Customer-Impacting Outage - {Service Name}

Executive Summary:
{2-3 sentence description of customer impact and business implications}

Key Metrics:
- Time to Detection: {X minutes}
- Time to Engagement: {X minutes} 
- Estimated Customer Impact: {number/percentage}
- Current Status: {status}
- ETA to Resolution: {time or "investigating"}

Leadership Actions Required:
- [ ] Customer communication approval
- [ ] PR/Communications coordination  
- [ ] Resource allocation decisions
- [ ] External vendor engagement

Incident Commander: {name} ({contact})
Next Update: {time}

---
This is an automated alert from our incident response system.

顧客向けコミュニケーションテンプレート

We are currently experiencing {brief description of issue} affecting {scope of impact}. 

Our engineering team was alerted at {time} and is actively working to resolve the issue. We will provide updates every {frequency} until resolved.

What we know:
- {factual statement of impact}
- {factual statement of scope}
- {brief status of response}

What we're doing:
- {primary response action}
- {secondary response action}

Workaround (if available):
{workaround steps or "No workaround currently available"}

We apologize for the inconvenience and will share more information as it becomes available.

Next update: {time}
Status page: {link}

ステークホルダー管理

ステークホルダーの分類

内部ステークホルダー：

• エンジニアリング部門のリーダーシップ - 技術的な意思決定とリソース配分
• プロダクトマネジメント - 顧客への影響評価と機能への影響
• カスタマーサポート - ユーザーへの連絡とサポートチケットの管理
• セールス／アカウント管理 - エンタープライズ顧客との関係管理
• 経営陣 - ビジネスへの影響に関する意思決定と外部コミュニケーションの承認
• 法務／コンプライアンス - 規制当局への報告と責任の評価

外部ステークホルダー：

• 顧客 - サービスの可用性と影響に関する連絡
• パートナー - API の可用性と連携への影響
• ベンダー - サードパーティサービスへの依存とサポートのエスカレーション
• 規制当局 - 規制対象業界におけるコンプライアンス報告
• 一般／メディア - 公開されるサービス停止に関する透明性

ステークホルダー別のコミュニケーション頻度

ステークホルダー	SEV1	SEV2	SEV3	SEV4
エンジニアリング部門のリーダーシップ	リアルタイム	30分	4時間	毎日
経営陣	15分	1時間	営業終了時	毎週
カスタマーサポート	リアルタイム	30分	2時間	必要に応じて
顧客	15分	1時間	任意	なし
パートナー	30分	2時間	任意	なし

ランブック生成フレームワーク

動的ランブックコンポーネント

1. 検知プレイブック

   • モニタリングアラートの定義
   • トリアージの意思決定ツリー
   • エスカレーションのトリガーポイント
   • 初動対応

2. 対応プレイブック

   • 段階的な緩和手順
   • ロールバック手順
   • 検証チェックポイント
   • コミュニケーションのチェックポイント

3. 復旧プレイブック

   • サービス復旧手順
   • データ整合性チェック
   • パフォーマンス検証
   • ユーザーへの通知プロセス

ランブックのテンプレート構成

# {Service/Component} Incident Response Runbook

## Quick Reference
- **Severity Indicators:** {list of conditions for each severity level}
- **Key Contacts:** {on-call rotations and escalation paths}
- **Critical Commands:** {list of emergency commands with descriptions}

## Detection
### Monitoring Alerts
- {Alert name}: {description and thresholds}
- {Alert name}: {description and thresholds}

### Manual Detection Signs
- {Symptom}: {what to look for and where}
- {Symptom}: {what to look for and where}

## Initial Response (0-15 minutes)
1. **Assess Severity**
   - [ ] Check {primary metric}
   - [ ] Verify {secondary indicator}
   - [ ] Classify as SEV{level} based on {criteria}

2. **Establish Command**
   - [ ] Page Incident Commander if SEV1/2
   - [ ] Create incident tracking ticket
   - [ ] Join war room: {link/bridge info}

3. **Initial Investigation**
   - [ ] Check recent deployments: {deployment log location}
   - [ ] Review error logs: {log location and queries}
   - [ ] Verify dependencies: {dependency check commands}

## Mitigation Strategies
### Strategy 1: {Name}
**Use when:** {conditions}
**Steps:**
1. {detailed step with commands}
2. {detailed step with expected outcomes}
3. {validation step}

**Rollback Plan:**
1. {rollback step}
2. {verification step}

### Strategy 2: {Name}
{similar structure}

## Recovery and Validation
1. **Service Restoration**
   - [ ] {restoration step}
   - [ ] Wait for {metric} to return to normal
   - [ ] Validate end-to-end functionality

2. **Communication**
   - [ ] Update status page
   - [ ] Notify stakeholders
   - [ ] Schedule PIR

## Common Pitfalls
- **{Pitfall}:** {description and how to avoid}
- **{Pitfall}:** {description and how to avoid}

## Reference Information
→ See references/reference-information.md for details

## Usage Examples

### Example 1: Database Connection Pool Exhaustion

```bash
# Classify the incident
echo '{"description": "Users reporting 500 errors, database connections timing out", "affected_users": "80%", "business_impact": "high"}' | python scripts/incident_classifier.py

# Reconstruct timeline from logs
python scripts/timeline_reconstructor.py --input assets/sample_timeline_events.json --output timeline.md

# Generate PIR after resolution
python scripts/pir_generator.py --incident assets/sample_incident_data.json --timeline timeline.md --output pir.md

例 2：API レート制限インシデント

# Quick classification from stdin
echo "API rate limits causing customer API calls to fail" | python scripts/incident_classifier.py --format text

# Build timeline from multiple sources
python scripts/timeline_reconstructor.py --input assets/simple_timeline_events.json --detect-phases --gap-analysis

# Generate comprehensive PIR
python scripts/pir_generator.py --incident assets/sample_incident_pir_data.json --rca-method fishbone --action-items

ベストプラクティス

インシデント対応中

1. 冷静なリーダーシップを保つ

   • プレッシャーの中でも冷静さを保ちます
   • 情報が不完全でも、断固として判断を下します
   • 不確実性を認めながら、自信を持って伝えます

2. すべてを記録する

   • 実施したすべての対応とその結果
   • 特に議論を呼ぶ判断の根拠
   • 発生した順に記録した出来事のタイムライン

3. 効果的なコミュニケーション

   • 明確で専門用語を使わない言葉を使います
   • 新しい情報がなくても定期的に最新情報を共有します
   • ステークホルダーの期待を先回りして管理します

4. 技術的な卓越性

   • プレッシャーの中では、リスクの高い修正よりロールバックを優先します
   • 解決を宣言する前に修正を検証します
   • 二次障害や連鎖的な影響に備えます

インシデント後

1. 非難しない文化

   • 個人のミスではなく、システム障害に焦点を当てます
   • 何が問題だったか、率直に報告することを促します
   • 学びと改善の機会を称賛します

2. アクションアイテムの管理

   • 担当者と期限を明確に割り当てます
   • 進捗を公開して追跡します
   • リスクと労力に基づいて優先順位を付けます

3. ナレッジ共有

   • PIR を組織内で広く共有します
   • 学んだ教訓に基づいてランブックを更新します
   • よくある障害モードについてトレーニングを実施します

4. 継続的な改善

   • 複数のインシデントに共通するパターンを探します
   • ツールと自動化に投資します
   • プロセスを定期的に見直し、更新します

既存ツールとの統合

モニタリングとアラート

• エスカレーションのための PagerDuty/Opsgenie 連携
• メトリクスとダッシュボードのための Datadog/Grafana
• ログ分析と相関分析のための ELK/Splunk

コミュニケーションプラットフォーム

• ウォールームの調整に使う Slack/Teams
• ビデオ会議用ブリッジに使う Zoom/Meet
• ステータスページプロバイダー（Statuspage.io など）

ドキュメントシステム

• PIR の保存に使う Confluence/Notion
• ランブックのバージョン管理に使う GitHub/GitLab
• アクションアイテムの追跡に使う JIRA/Linear

変更管理

• CI/CD パイプラインとの統合
• デプロイ追跡システム
• 迅速なロールバックのためのフィーチャーフラグプラットフォーム