Incident RCA Specialist

インシデント発生後の振り返りと根本原因分析を体系的に実施するスキル。

API 不要

スキルパッケージをダウンロード (.skill) GitHubでソースを見る ワークフロー バイリンガル

目次

概要

Incident RCA Specialist は、組織的なインシデント管理プロセスに特化した振り返り・根本原因分析スキルです。タイムライン構築、影響評価、根本原因分析（5 Whys 分岐対応版、Fishbone、Fault Tree Analysis）、SMART 基準に基づく是正措置計画、日英バイリンガルの RCA レポート生成を提供します。

「人的エラー」で分析を止めず、必ずプロセス・システム・教育のギャップまで分解する Blame-Free カルチャーを徹底します。

スコープ境界: ログファイル解析や技術デバッグが必要な場合は log-debugger スキルを使用してください。本スキルは組織的な振り返りプロセスと是正措置の策定に特化しています。

こんなときに使う

  • インシデント発生後の振り返り・レトロスペクティブを実施するとき
  • インシデントレポート・RCA ドキュメントを作成するとき
  • 障害発生後の是正措置計画を策定するとき
  • 再発防止策を策定するとき
  • SLA 違反の有無を評価するとき
  • 複雑なシステム障害に Fault Tree Analysis を適用するとき
  • Lessons Learned を組織的に共有するとき

前提条件

  • Claude Code がインストール済みであること
  • incident-rca-specialist スキルがインストール済み（cp -r ./skills/incident-rca-specialist ~/.claude/skills/）
  • 外部 API やツールは不要

仕組み

8 ステップのワークフローで進行します:

  1. 情報収集 – 構造化された質問でインシデント詳細を収集（タイムライン、影響サービス、ユーザー数、対応経緯）
  2. タイムライン構築 – Mermaid ガントチャートで時系列を可視化し、TTD/TTR/TTM/TTRe を算出
  3. 影響評価 – 4 軸（ユーザー、サービス、ビジネス、運用）で影響を評価し、P0-P4 の重大度を判定
  4. RCA: 5 Whys – 分岐対応版 5 Whys。エビデンス追跡付き。人的エラーは必ずプロセス/システム/教育ギャップに分解
  5. RCA: Fishbone – IT 向け 6 カテゴリ（People, Process, Technology, Environment, Data, External）で石川ダイアグラムを作成
  6. RCA: Fault Tree Analysis – AND/OR ゲートによるトップダウン障害分析、最小カットセット、単一障害点の特定
  7. 是正措置計画 – 3 つの時間軸（即時/短期/長期）と 3D Prevention Framework（Detect, Defend, Degrade）、SMART 基準
  8. レポート生成 – バンドルテンプレートを使用し、日本語または英語で完全な RCA レポートを出力

分岐 5 Whys の詳細

従来の 5 Whys は単一の因果連鎖をたどりますが、本スキルはこれをツリー構造に拡張しています。1 つの「Why」に対して複数の独立した原因が見つかった場合、分析が分岐し各パスを個別に探索します。

症状: 決済サービスが 500 エラーを返した
 Why 1: データベース接続プールが枯渇
   Why 2a: チェックアウトモジュールで接続リーク  Why 2b: 接続上限が低すぎる
     Why 3a: finally ブロックの欠落                Why 3b: 2 年前のデフォルト設定のまま
       Why 4a: 静的解析ルールがない                  Why 4b: キャパシティレビュープロセスがない
         [プロセスギャップ] [証拠: git blame]          [プロセスギャップ] [証拠: 設定履歴]

各分岐は以下の情報とともに独立して追跡されます:

  • エビデンス注釈 – 因果関係を裏付けるログ、メトリクス、タイムスタンプ
  • 信頼度 – 各リンクに High / Medium / Low を付与
  • 人的エラー分解ルール – 分析が「オペレーターのミス」に到達した場合、そこで止めず「なぜこのエラーが可能だったのか?」と続行。プロセスギャップ、システムギャップ、教育ギャップのいずれかに分解する。

Fault Tree Analysis: AND/OR ゲート

FTA はトップレベルの障害イベントを 2 種類の論理ゲートで分解します:

OR ゲート – 子イベントのいずれかが発生すれば親イベントが発生:

        [サービス停止]
             OR
        /          \
[DB 障害]     [ネットワーク障害]

データベース障害またはネットワーク障害のどちらか一方だけで、サービス停止が発生します。

AND ゲート – すべての子イベントが同時に発生した場合のみ親イベントが発生:

        [データ破損]
            AND
        /          \
[書込競合]    [バリデーション無し]

データ破損は、書き込み競合とバリデーションの欠如の両方が揃った場合にのみ発生します。

スキルは最小カットセット（トップイベントを引き起こす基本イベントの最小組合せ）と単一障害点（SPOF）（すべてのカットセットに出現するイベント）を特定し、SPOF を優先的に是正措置の対象とします。

3D Prevention Framework

各是正措置は 3 つの防止次元に分類されます:

  • Detect – 問題をより早く発見する方法（監視閾値、アラートルール、オブザーバビリティの改善）
  • Defend – 発生自体を防止する方法（入力バリデーション、ガードレール、自動化、安全なデフォルト値）
  • Degrade – 障害発生時の影響範囲を限定する方法（サーキットブレーカー、フィーチャーフラグ、グレースフルデグラデーション、バルクヘッド）

使い方の例

例 1: インシデントの全体振り返り 

昨日、決済サービスが 2 時間ダウンしました（2/28 14:00-16:00 UTC）。
約 5,000 ユーザーが影響を受けました。監視アラートは最初のエラーから
20 分後に発報しました。RCA を実施してください。

情報収集からタイムライン構築、影響評価、5 Whys 分析、是正措置提案、最終レポート生成まで一連のワークフローを実行します。

例 2: 是正措置計画のみ 

先週のデータベースフェイルオーバー障害の根本原因はコネクションプール
設定の誤りと判明しています。即時・短期・長期の是正措置計画を策定して
ください。

3D Prevention Framework（Detect/Defend/Degrade）を適用し、3 つの時間軸で SMART な是正措置を策定します。

例 3: Fault Tree Analysis 

今月、CI/CD パイプラインで異なる原因による 3 回のデプロイ失敗が
発生しました。Fault Tree Analysis で単一障害点と最小カットセットを
特定してください。

AND/OR ゲートでトップイベントを分解し、Mermaid で FTA ツリーを生成、優先的に対処すべき SPOF を特定します。

例 4: SLA 準拠の評価 

課金 API の SLA は 99.9% の稼働率を保証しています。昨晩の
45 分間の障害により、今月の SLA に違反したかどうか確認し、
残りのエラーバジェットを算出してください。

SLA 閾値に対する累計ダウンタイムを計算し、SLA 違反の有無を判定します。該当する場合は金銭的ペナルティの見積りとともに影響評価セクションに結果を含めます。

トラブルシューティング

分析が「人的エラー」で止まる

症状: 5 Whys の連鎖が「オペレーターがミスをした」に到達し、分析が完了したように見えるが、具体的な改善策が特定されていない。

解決策: スキルは人的エラー分解ルールを適用し、人的エラーで分析を止めません。「なぜこのエラーが可能だったのか?」と問い続け、プロセスギャップ（チェックリスト不足、手順不明確）、システムギャップ（ガードレール不足、バリデーション欠如）、教育ギャップ（オンボーディング不足、ランブック不備）のいずれかに分解します。分析が早期に停止した場合は「人的エラーをさらに分解してください」とプロンプトしてください。

5 Whys の分岐が多すぎる

症状: 分岐 5 Whys ツリーが数十の分岐を持ち、レポートが読みにくくなる。

解決策: まず High 信頼度のエビデンスがある分岐に集中してください。Low 信頼度の分岐は枝刈りするか、要約ノートにまとめます。スキルに「影響度の高い上位 3 分岐に限定し、残りは『要追加調査』としてレポートに記載してください」と指示することも可能です。

RCA 手法の選び方がわからない

症状: 特定のインシデントに 5 Whys、Fishbone、FTA のどれを使うべきか判断できない。

解決策: 5 Whys は比較的明確な因果連鎖がある場合（例: 設定ミスによる障害）に使用します。Fishbone は複数カテゴリにまたがる寄与因子がある場合（人、プロセス、技術）に使用します。FTA は障害モード間の構造的関係を理解する必要がある複雑なシステム障害に使用します。手法の組み合わせも有効で、例えば Fishbone でカテゴリを特定してから、最も重要なカテゴリに 5 Whys でドリルダウンするアプローチがあります。

ヒントとベストプラクティス

  • Blame-Free の原則: 分析結果は「プロセスが許容した…」のように記述し、個人の責任を追及しません。
  • エビデンスベース: すべての因果関係にはログ・メトリクス・タイムスタンプなどの裏付けが必要です。各リンクに信頼度（High/Medium/Low）を付与します。
  • 手法の使い分け: シンプルなインシデントには 5 Whys、複数の寄与因子がある場合は Fishbone、複雑な構造的障害には FTA を使用します。組み合わせも可能です。
  • SMART な是正措置: 「監視を強化する」のような曖昧な表現は、具体的・測定可能な項目に精緻化されます。
  • バイリンガル対応: バンドルテンプレートを使用し、日本語・英語どちらでもレポートを生成できます。

関連スキル

  • log-debugger – ログファイル解析とコードレベルの技術的根本原因調査
  • operations-manual-creator – 構造化された操作マニュアル・SOP の作成
  • project-manager – プロジェクトヘルスチェックと PMBOK ベースの管理