メインコンテンツへスキップ
根本原因分析（RCA）は Deep Response Engine の調査エンジンです。専門エージェントが仮説駆動型の調査を実行し、構造化されたエビデンスチェーンを構築し、修復策を提案します。各ステップの推論過程を完全に可視化できます。

​
調査の流れ

  1. トリガー — Pulse クラスターが自動エスカレーションするか、インシデント詳細ページから手動でインシデントが作成されます。クラスターのエスカレーションでは、クラスターの要約とすべてのメンバーシグナルがエージェントのコンテキストに注入されるため、完全なシグナル履歴がロード済みの状態で調査が始まります。CloudThinker はバックグラウンドで RCA タスクをキューに入れ、専用の AI 会話を開きます。
  2. エージェントの起動 — Anna が調査を統括し、接続されたインフラに基づいてスペシャリストがそれぞれのドメインをカバーします。
  3. コンテキストの収集 — エージェントがインフラトポロジーを探索し、ベースラインメトリクスを収集し、影響を受けたサービスを特定し、最近のデプロイや設定変更を調査します。
  4. 分析 — エージェントが競合する仮説を立て、ログ・トレース・依存関係に対してそれぞれを検証します。
  5. 解決 — 確認された仮説が根本原因になります。エビデンスがキュレーションされ、修復提案が生成され、信頼度スコアとともにディスポジションが設定されます。
エージェント調査対象
Alex（クラウドエンジニア）クラウドインフラ — EC2、ロードバランサー、VPC ネットワーキング
Tony（データベースエンジニア）RDS Aurora および DocumentDB のパフォーマンス、スロークエリ、接続プールの枯渇
Kai（Kubernetes エンジニア）EKS のポッドヘルス、コンテナの再起動、リソース制限、サービスメッシュ設定
Oliver（セキュリティエンジニア）セキュリティグループ、ネットワークポリシー、IAM 権限、セキュリティ関連の障害モード
Anna（ジェネラルマネージャー）統括とクロスドメインの統合
エージェントはこれらのドメインを並行して調査し、リアルタイムで所見を相関付けます。症状が根本的な問題から遠く離れて現れる場合でも根本原因を特定します。

​
調査フェーズ

RCA は構造化された 3 フェーズのワークフローに従います。エージェントが新しいフェーズに移行すると、前のフェーズがまだ進行中であれば自動的に完了します。
フェーズ目標活動内容
1. コンテキスト収集ベースライン条件の確立トポロジーで影響を受けたサービスと依存関係をマッピング。CloudWatch・Prometheus・Datadog からメトリクスを収集。インシデントメトリクスを過去ベースラインと比較。最近のデプロイと設定変更を特定
2. 分析と仮説検証根本原因の絞り込み症状から競合する仮説を生成。ログ・トレース・依存関係・リソースのエビデンスを収集。エビデンスが否定する仮説を除外。エビデンスの蓄積に応じて信頼度を追跡
3. 解決エビデンスとともに根本原因を確定残存する仮説をすべて解決。勝者を根本原因として確認。最強のエビデンスをキュレーション。修復ステップを生成。ディスポジションと信頼度スコアを設定
エージェントは仮説を確認する前に、十分な支持エビデンスを収集し、十分な時間をかけて調査する必要があります。
ディスポジションの設定は調査を終了するために必須です。設定しない場合、インシデントは Investigating ステータスのままになります。

​
エビデンスチェーン

RCA は自動計算付きの構造化エビデンスチェーンを構築します。各アイテムは特定の仮説にリンクでき、どの所見がどの仮説を支持するかを示します。
エビデンスタイプ記録内容フィールド
メトリクスインシデント値とベースラインの比較（自動計算された偏差率付き）— 例：「CPU 95% vs ベースライン 25% = 偏差 280%」incident_value、baseline_value、baseline_period、threshold、unit
デプロイと変更インシデント開始からの時間差を自動計算した最近の変更。正のデルタ = インシデント前（原因の可能性あり）type、description、timestamp、correlation、service
ログCloudWatch・Splunk・Datadog などのログコンソールへのディープリンク付き関連ログエントリsource、description、deep_link、timestamp、severity
トレースリクエストフローとレイテンシの内訳を示す分散トレースデータsource、description、raw_data
設定正確なパラメーター変更内容を持つ設定変更source、description、timestamp
アラートインシデントウィンドウ中のモニタリングシステムからの関連アラートsource、severity、description
エビデンスは重要度でランク付けされます：Critical（直接的な原因）→ High（強い支持）→ Medium（コンテキスト）→ Low（背景情報）。

​
信頼度スコアリング

特定されたすべての根本原因は 0.0〜1.0 の信頼度スコアを持ちます。
スコア範囲カテゴリー意味推奨アクション
0.9 – 1.0非常に高い圧倒的なエビデンスにより根本原因を特定直ちに修復を実施
0.7 – 0.9高い強いエビデンスにより根本原因を特定通常の優先度で修復を実施
0.5 – 0.7中程度根本原因として有力だが、ギャップが残る修復を実施し、代替案を監視
0.3 – 0.5低い根本原因の可能性があるが、エビデンスは状況証拠アクション前に手動で所見を検証
0.0 – 0.3不確定根本原因を確立するエビデンスが不十分判断不能。NOT_FOUND を検討
信頼度は、時間的相関・50% 超のメトリクス異常・一致するエラーパターン・除外された代替案・複数の裏付けデータソースにより上昇します。代替説明・弱い時間的相関・検証の欠如・相反するエビデンスにより低下します。

​
仮説追跡

RCA は「5 つのなぜ」とフィッシュボーン手法にインスパイアされた仮説駆動型調査を実行します。
状態意味
Investigating仮説を検証するためにエビデンスを積極的に収集中
Confirmed十分なエビデンスにより根本原因として支持されている
Ruled outエビデンスが仮説を否定または反証
エージェントは根本原因を設定する前に少なくとも 1 つの仮説を確認し、調査を終了する前にすべての仮説を（確認または否定として）解決します。 レイテンシインシデントの仮説チェーンの例： 
Timeline Entry 1: hypothesis_created
├── Hypothesis 1: "Database connection pool exhaustion"
├── Confidence: 0.75
└── Message: "Pool exhaustion likely given 500s response times"

Timeline Entry 3: hypothesis_ruled_out
├── Hypothesis 1: Ruled Out
├── Reason: "DB metrics show 45/100 connections—well within limits"
└── Evidence: Max concurrent connections remained stable

Timeline Entry 6: hypothesis_created
├── Hypothesis 2: "Lambda cold start latency after memory reduction"
├── Confidence: 0.85

Timeline Entry 8: hypothesis_confirmed
├── Hypothesis 2: Confirmed
├── Updated Confidence: 0.92
└── Evidence: CloudWatch init duration spike, deployment timing match

​
調査タイムライン

RCA はすべての調査ステップのリアルタイムタイムラインをストリーミングします。フェーズの進捗、仮説のテスト、タイムスタンプ付きのエビデンス収集が表示されます。各調査は最大 100 エントリーを保持します（データベースレベルで適用）。
エントリータイプ意味
info一般的な調査ノート
finding分析に影響する特定の発見
warning検証が必要な潜在的問題
error失敗した調査の試み
success確認された所見
hypothesis_created新しい仮説の提案
hypothesis_ruled_out仮説の否定
hypothesis_confirmed仮説の根本原因としての検証

​
ディスポジション

すべての調査はディスポジションで終了し、インシデントのステータスを更新します。
ディスポジション意味再開可能？
IDENTIFIED支持エビデンスとともに根本原因を発見不可（終端）
NOT_FOUND調査を尽くしたが明確な根本原因なし不可（終端）
FALSE_ALARM実際のインシデントではなかった不可（終端）
ON_HOLD外部入力または追加データを待機中可能 — 新しい情報が届くと再開
ディスポジション設定後、チームがフォローアップアクションを完了するにつれて、インシデントは追加のライフサイクルステータス（Resolved・Post-Mortem・Closed）に進むことができます。

​
調査を開始する

​
自動で

Webhook インテグレーションを設定して RCA を自動トリガーします。インシデントが重要度のしきい値を満たすと、バックグラウンドで調査が開始されます。 
{
  "auto_trigger_rca": true,
  "auto_trigger_rca_min_severity": "medium"
}

​
手動で

1

インシデント詳細ページを開く

調査したいインシデントを選択します。
2

「RCA 分析を開始」をクリックする

CloudThinker が重複する RCA が実行されていないことを検証し、1〜3 秒以内に調査を開始します。エージェントが所見を発見するにつれ、タイムラインエントリーがリアルタイムで表示されます。

​
結果の読み取り方

セクション表示内容
根本原因サマリー信頼度スコアと特定タイムスタンプ付きの根本原因の明確な説明
仮説追跡各仮説のライフサイクル：作成 → 検証 → 確認または否定（理由付き）
エビデンスチェーンタイプ別に整理されたエビデンス（重要度ランキング、ソース帰属、ディープリンク付き）
調査タイムライン調査ステップとフェーズ遷移の時系列ログ
修復アクション優先度レベル（critical・high・medium・low）付きの推奨修正手順
影響サービスインシデント中に影響を受けたサービス。トポロジーが接続されている場合はブラストラジウスの可視化も表示
バージョン追跡（v1・v2・v3…）付きで同一インシデントに対して複数回の調査を実行できます。新しい情報が入手可能になった場合や最初の実行が決定的でなかった場合は RCA を再実行し、履歴ドロップダウンで結果を比較します。

​
例：EC2 の終了と EKS ネットワーク障害

あるワークスペースで継続的モニタリングにより、2 つの相互に関連する所見が浮上しました。頻繁な EC2 インスタンスの終了と EKS の CreateNetworkInterface 障害です。エージェントがこれらをどのように一緒に調査したかを紹介します。 まず、Alex が終了パターンを分析します。 
@alex #report investigate EC2 termination patterns for the past 60 days.
Break down by Auto Scaling group, termination reason, instance type, and
availability zone — and explain the 17:15 UTC daily terminations.
EC2 終了パターン分析：AutoScaling イベントとタイムラインを表示

EC2 終了パターン分析：AutoScaling イベントを表示

次に、Alex がネットワーク障害と終了を相互関連付けします。 
@alex #report correlate CreateNetworkInterface failures with EC2
termination events over the last 60 days. Determine whether aggressive
scale-downs cause IP address fragmentation and whether lifecycle hooks
allow proper ENI cleanup.
ネットワーク障害の相関：CreateNetworkInterface エラーと IP 枯渇

ネットワーク障害の相関：CreateNetworkInterface エラーと IP 枯渇

最後に、Anna が Alex（インフラとコスト）、Kai（EKS ネットワーキング）、Oliver（セキュリティ）の所見を 1 つのドキュメントに統合します。 
@anna #report comprehensive RCA for the EC2 termination and EKS network
interface failures. Include an executive summary, the 60-day timeline,
remediation steps with owners and due dates, and preventive measures.
包括的 RCA レポート：所見、修復ステップ、予防措置

包括的 RCA レポート：所見と修復ステップ

​
ベストプラクティス

  • インシデントが発生する前にトポロジーを接続する — ブラストラジウス分析とサービス相関はトポロジーに依存します。
  • Medium 以上の重要度のインシデントに対して RCA を自動トリガーするようWebhookを設定する。
  • インシデントの説明にコンテキストを追加する。エージェントが最初にどこを調査するかの指針になります。
  • 調査中はタイムラインを監視して、どの仮説がテストされ否定されたかを確認し、エビデンスのタイムスタンプがインシデント開始と相関しているか検証する。
  • 信頼度が 0.7 未満の場合は根本原因を手動で検証してから修復し、Critical 優先度の修復アクションから着手する。
  • 将来の調査中にエージェントが修復手順を検索・実行できるようRunbooksを接続する。

​
関連

Pulse

ノイズを抑制し、アクショナブルなクラスターをインシデントにエスカレーションするアップストリームのシグナルインテリジェンス

Webhook インテグレーション

PagerDuty・Datadog・Prometheus などから RCA を自動トリガー

トポロジー

インシデント発生時の迅速なブラストラジウス分析のためにライブ依存マップを構築

Runbooks

エージェントが修復ステップを実行できるよう運用 Runbook を接続