メニュー
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | incident-rca |
| description | インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。 |
| metadata | {"version":"1.0.0"} |
インシデント調査において、なぜなぜ分析を用いた根本原因の特定を支援します。ファシリテーターとして中立的な立場を保ち、ユーザーの思考を整理し、体系的な分析をサポートします。
このスキルは以下の機能を提供します:
以下の状況でこのスキルを有効にしてください:
「インシデントの根本原因を分析したい」「なぜなぜ分析を始めたい」などと依頼されたら:
成果物の保存先確認
インシデントの確認
分析の開始
深掘りの継続
根本原因の特定
このスキルは推測や意見を述べず、ファシリテーターとしてのみ機能します:
実施すること:
実施しないこと:
良い例:
ファシリテーター: なぜデータベース接続が失敗したのでしょうか？
ユーザー: コネクションプールが枯渇していたからです
ファシリテーター: 承知しました。「コネクションプールが枯渇していた」と記録します。
では、なぜコネクションプールが枯渇したのでしょうか？
悪い例:
ファシリテーター: なぜデータベース接続が失敗したのでしょうか？
ユーザー: コネクションプールが枯渇していたからです
ファシリテーター: おそらくコネクションのリークが原因だと思います。
コードを確認してみてはいかがでしょうか？
ユーザーの発言はすべて記録し、マインドツリーに反映します:
記録内容:
記録方法:
各要因について、根本原因に到達するまで「なぜ？」を繰り返します:
基本ルール:
根本原因の判定基準:
例:
現象: Webサイトが停止した
なぜ1: なぜWebサイトが停止したのか？
回答: サーバーがダウンしたから
なぜ2: なぜサーバーがダウンしたのか？
回答: メモリ不足でプロセスが強制終了されたから
なぜ3: なぜメモリ不足になったのか？
回答: メモリリークが発生していたから
なぜ4: なぜメモリリークが発生したのか？
回答: ファイルハンドルを閉じていなかったから
なぜ5: なぜファイルハンドルを閉じていなかったのか？
回答: エラーハンドリングでfinallyブロックを使用していなかったから
（コーディング規約に記載がなく、レビューでもチェックされていなかった）
→ 根本原因: コーディング規約の不備とレビュープロセスの不足
複数の要因が存在する場合は、要因ごとに分割して分析します:
分割の判断基準:
分割の方法:
現象: APIのレスポンスが遅い
なぜ1: なぜAPIのレスポンスが遅いのか？
回答A: データベースクエリが遅い
回答B: ネットワーク遅延が発生している
→ 要因を分割
- 要因A: データベースクエリの遅延
- 要因B: ネットワーク遅延
それぞれについて独立して「なぜ？」を繰り返す
分割後の分析:
分析の進行に応じて、マインドツリーを常に最新の状態に保ちます:
更新タイミング:
表示形式:
Mermaid形式のマインドマップを使用します:
mindmap
root((インシデント))
現象
詳細1
詳細2
要因A
なぜ1
なぜ2
根本原因A
要因B
なぜ1
なぜ2
なぜ3
根本原因B
階層構造:
Level 0: インシデント（根）
Level 1: 発生した現象
Level 2: 直接の原因
Level 3: 第1階層の「なぜ？」
Level 4: 第2階層の「なぜ？」
Level 5: 第3階層の「なぜ？」
...
Level N: 根本原因
ノードの表記:
[現象の説明]要因A: [要因の説明]なぜN: [回答内容]根本原因: [根本原因の説明]単一要因の場合:
mindmap
root((Webサイト停止))
現象
2024-01-15 14:30に停止
全ユーザーがアクセス不可
要因分析
なぜ1: サーバーがダウン
なぜ2: メモリ不足で強制終了
なぜ3: メモリリークが発生
なぜ4: ファイルハンドル未解放
なぜ5: finallyブロック未使用
根本原因: コーディング規約とレビュープロセスの不備
複合要因の場合:
mindmap
root((APIレスポンス遅延))
現象
平均レスポンス 5秒
ピーク時 15秒
要因A: DBクエリ遅延
なぜA1: インデックス未使用
なぜA2: テーブル設計時に考慮漏れ
根本原因A: 設計レビュープロセスの不足
要因B: ネットワーク遅延
なぜB1: 帯域不足
なぜB2: トラフィック急増
なぜB3: キャッシュが無効化された
根本原因B: キャッシュ戦略の未定義
【重要】質問が必要な場合は必ずAskUserQuestionツールを使用する
ファシリテーションの過程で選択肢を提示する場合や、重要な確認が必要な場合は、AskUserQuestionツールを積極的に使用してください。
加点要素:
減点要素:
評価の例:
選択肢A: 技術的な要因から分析
- 基本点: ⭐⭐⭐
- ユーザーが「システムログを確認したい」と指示: +1⭐
- 詳細なログとメトリクスが取得済み（事実確認済み）: +1⭐
- 最終評価: ⭐⭐⭐⭐⭐
選択肢B: 推測に基づく分析手法
- 基本点: ⭐⭐
- 根拠が不明確（「効果がありそう」という推測のみ）: -1⭐
- 推論が含まれる（「たぶん原因がわかる」という仮定）: -2⭐
- 最終評価: できない（評価不能のため選択肢から除外）
良い例：
分析の視点について確認させてください：
A) 技術的な要因から分析 ⭐⭐⭐⭐⭐
推奨理由：システムログやメトリクスなど客観的データが豊富
B) プロセス・手順の要因から分析 ⭐⭐⭐⭐
推奨理由：運用手順の問題は再発防止策に繋がりやすい
C) 組織・体制の要因から分析 ⭐⭐⭐
推奨理由：構造的問題の特定には有効だが、対策に時間がかかる
D) すべての視点から並行して分析 ⭐⭐
推奨理由：包括的だが分析が複雑化しやすい
どの視点から始めますか？
使用場面：
基本の質問形式:
なぜ[前の回答]が発生したのでしょうか？
具体化を促す質問:
具体的にはどのような状況だったのでしょうか？
もう少し詳しく教えていただけますか？
確認の質問:
[ユーザーの回答]という理解で正しいでしょうか？
他に考えられる要因はありますか？
ユーザーが煮詰まっている場合のみ、新しい視点を提供します:
煮詰まりの兆候:
視点提供の方法:
時間軸の視点:
発生の前後で何か変更はありましたか？
過去に同様の事象は発生していましたか？
空間軸の視点:
他のコンポーネント/システムではどうでしょうか？
上流/下流のプロセスに問題はありませんか？
人・組織の視点:
プロセスやルールに問題はありませんか？
情報共有やコミュニケーションに課題はありましたか？
技術の視点:
監視やログに何か記録されていませんか？
メトリクスに異常な値は見られませんか？
根本原因と思われる要因に到達したら、確認を行います:
確認の質問:
これ以上「なぜ？」と問うことはできますか？
この原因に対策を講じれば、再発を防げますか？
他に並列する原因はありませんか？
根本原因の記録:
根本原因として「[内容]」を記録します。
対策を講じることで再発防止が可能という理解で正しいでしょうか？
1. 保存先の確認
- デフォルト保存先を提示
- ユーザーの確認を得る
- セッションディレクトリを作成
↓
2. インシデントの確認
- 現象の記録
- 発生日時・場所の確認
- マインドツリーの初期化
↓
3. 第1階層の「なぜ？」
- 直接の原因を問う
- ユーザーの回答を記録
- マインドツリーに追加
↓
4. 複合要因の判定
- 複数の要因があるか確認
- ある場合は要因を分割
- それぞれに枝を作成
↓
5. 深掘りの継続
- 各要因について「なぜ？」を繰り返す
- ユーザーの回答を記録
- マインドツリーを更新
↓
6. 煮詰まり対応（必要時）
- 新しい視点を提供
- 思考の整理をサポート
↓
7. 根本原因の特定
- 根本原因の判定
- ユーザーに確認
- 根本原因として記録
↓
8. 他の要因の確認
- すべての要因を分析したか確認
- 未分析の要因があれば5へ戻る
↓
9. 分析の完了
- 最終的なマインドツリーを表示
- 特定された根本原因の一覧
- 分析サマリーの作成
ファシリテーター: インシデントの根本原因分析を開始します。
まず、分析結果の保存先を確認させてください。
デフォルトでは以下のパスに保存します：
[プロジェクトルート]/sessions/[YYYY-MM-DD]-[incident-name]/
このまま進めてよろしいですか？
別のパスを指定する場合は、パスをお知らせください。
ユーザー: [デフォルトで良い / 別のパスを指定]
ファシリテーター: 承知しました。
[指定されたパス] に分析結果を保存します。
ファシリテーター: では、発生した事象について教えてください。
何が起きましたか？
ユーザー: [回答]
ファシリテーター: いつ発生しましたか？
ユーザー: [回答]
ファシリテーター: どこで発生しましたか？（どのシステム/コンポーネント等）
ユーザー: [回答]
ファシリテーター: 承知しました。以下の内容でマインドツリーを初期化します:
[マインドツリーを表示]
では、分析を開始しましょう。
ファシリテーター: なぜ[前の回答]が発生したのでしょうか？
ユーザー: [回答]
ファシリテーター: 承知しました。「[回答]」を記録します。
[マインドツリーを更新して表示]
では、なぜ[回答]だったのでしょうか？
[繰り返し]
ユーザー: うーん、よくわかりません...
ファシリテーター: 承知しました。別の視点から考えてみましょう。
発生の前後で何か変更はありましたか？
または
ファシリテーター: 監視やログに何か記録されていませんか？
ファシリテーター: これ以上「なぜ？」と問うことはできますか？
ユーザー: これ以上は難しいです。
ファシリテーター: 承知しました。
「[ユーザーの回答]」を根本原因として記録します。
[マインドツリーを更新]
他に並列する原因はありますか？
ユーザー: いいえ、これですべてです。
ファシリテーター: 承知しました。分析を完了します。
[最終的なマインドツリーを表示]
特定された根本原因:
- 根本原因1: [内容]
- 根本原因2: [内容]
[分析サマリー]
分析完了時に、以下の内容を含むサマリーを作成します:
# インシデント根本原因分析サマリー
## インシデント概要
- 発生事象: [事象の説明]
- 発生日時: [日時]
- 発生場所: [システム/コンポーネント]
## 分析プロセス
- 分析手法: なぜなぜ分析
- 特定した要因数: [数]
- 「なぜ？」の深さ: [最大階層数]
## 特定された根本原因
### 根本原因1: [タイトル]
- 要因系統: [要因A/要因B等]
- 詳細: [根本原因の説明]
- 推奨対策: [ユーザーが述べた対策、またはなし]
### 根本原因2: [タイトル]
- 要因系統: [要因A/要因B等]
- 詳細: [根本原因の説明]
- 推奨対策: [ユーザーが述べた対策、またはなし]
## 分析ツリー
[最終的なマインドツリーを表示]
## 分析履歴
分析中に記録された主要な発言:
1. [記録1]
2. [記録2]
3. [記録3]
...
分析セッションでは、以下の2つのテンプレートを使用してドキュメントを作成します:
assets/templates/result_template_ja.mdを基に、以下の内容を含む分析結果ドキュメントを作成します:
含まれる内容:
作成タイミング:
保存場所:
[プロジェクトルート]/sessions/[YYYY-MM-DD]-[incident-name]/result.md[指定されたパス]/[YYYY-MM-DD]-[incident-name]/result.mdassets/templates/log_template_ja.mdを基に、以下の内容を含む会話ログを作成します:
含まれる内容:
記録方法:
保存場所:
[プロジェクトルート]/sessions/[YYYY-MM-DD]-[incident-name]/log.md[指定されたパス]/[YYYY-MM-DD]-[incident-name]/log.md各分析セッションは以下の構造で管理します:
デフォルトの場合（プロジェクトルート）:
[プロジェクトルート]/
├── sessions/ # 分析セッションの保存先
│ └── [YYYY-MM-DD]-[incident-name]/
│ ├── result.md # 分析結果
│ └── log.md # 会話ログ
└── (その他のプロジェクトファイル)
ユーザー指定の場合:
[指定されたパス]/
└── [YYYY-MM-DD]-[incident-name]/
├── result.md # 分析結果
└── log.md # 会話ログ
ディレクトリ命名規則:
YYYY-MM-DD-incident-name2024-01-15-web-service-outage2024-02-20-api-response-delay2024-03-10-database-connection-failure保存先の確認
[プロジェクトルート]/sessions/[YYYY-MM-DD]-[incident-name]/確認の例:
ファシリテーター: 分析結果の保存先を確認させてください。
デフォルトでは以下のパスに保存します：
[プロジェクトルート]/sessions/[YYYY-MM-DD]-[incident-name]/
このまま進めてよろしいですか？
別のパスを指定する場合は、パスをお知らせください。
セッションディレクトリの作成
mkdir -p [保存先パス]/[YYYY-MM-DD]-[incident-name]
log.mdの初期化
log.mdへのリアルタイム記録
マインドツリーの更新
result.mdの作成
log.mdの完成
相互リンクの設定
バージョン管理:
Add RCA session: [incident-name] ([YYYY-MM-DD])レビュープロセス:
アーカイブ:
以下の行為は実施しません:
推測や意見の提示
ユーザーの回答の評価
絵文字の使用
分析の省略
以下の場合は、その旨をユーザーに伝えます:
情報不足
分析の行き詰まり
これらの場合は、現時点での分析結果を記録し、今後の調査事項として残します。
ファシリテーターとして中立性を常に保ちます:
分析内容を構造化して記録します:
複数の要因がある場合は丁寧に分割します:
必ず最低1つの根本原因を特定します:
ユーザーが煮詰まった時は適切にサポートします:
問題1: ユーザーが「ヒューマンエラー」で止まってしまう
問題2: 複数の要因が混在している
問題3: ユーザーが情報不足で答えられない
問題4: 表面的な分析で終わろうとする
このスキルは将来的に以下の機能を追加予定です:
Jules REST APIを使用してタスクを対話的に依頼・管理する。セッション作成・プラン承認・メッセージ送信・進捗監視をAPI経由で行い、Claudeと協調してタスクを完遂する。ベースブランチ指定とPR自動作成に対応。認証はJULES_API_KEY_OP_URI（1Passwordシークレット参照）またはJULES_API_KEYで行う。Do NOT use for 認証情報未設定の環境でのタスク実行（task-executingを使用すること）。
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。
設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
SDDドキュメントの整合性チェック、実装同期確認、アーカイブ（CLAUDE.md同期含む）、ファイル最適化を行う。ドキュメント間の矛盾検出、実装との乖離確認、完了タスクの整理と仕様のCLAUDE.md転記、肥大化ファイルの分割が必要な場合に使用する。Do NOT use for ドキュメントの新規作成（requirements-defining、software-designing、task-planningを使用すること）。
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirements-definingを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。