調査の流れ
- トリガー — Pulse クラスターが自動エスカレーションするか、インシデント詳細ページから手動でインシデントが作成されます。クラスターのエスカレーションでは、クラスターの要約とすべてのメンバーシグナルがエージェントのコンテキストに注入されるため、完全なシグナル履歴がロード済みの状態で調査が始まります。CloudThinker はバックグラウンドで RCA タスクをキューに入れ、専用の AI 会話を開きます。
- エージェントの起動 — Anna が調査を統括し、接続されたインフラに基づいてスペシャリストがそれぞれのドメインをカバーします。
- コンテキストの収集 — エージェントがインフラトポロジーを探索し、ベースラインメトリクスを収集し、影響を受けたサービスを特定し、最近のデプロイや設定変更を調査します。
- 分析 — エージェントが競合する仮説を立て、ログ・トレース・依存関係に対してそれぞれを検証します。
- 解決 — 確認された仮説が根本原因になります。エビデンスがキュレーションされ、修復提案が生成され、信頼度スコアとともにディスポジションが設定されます。
エージェントはこれらのドメインを並行して調査し、リアルタイムで所見を相関付けます。症状が根本的な問題から遠く離れて現れる場合でも根本原因を特定します。
調査フェーズ
RCA は構造化された 3 フェーズのワークフローに従います。エージェントが新しいフェーズに移行すると、前のフェーズがまだ進行中であれば自動的に完了します。
エージェントは仮説を確認する前に、十分な支持エビデンスを収集し、十分な時間をかけて調査する必要があります。
ディスポジションの設定は調査を終了するために必須です。設定しない場合、インシデントは Investigating ステータスのままになります。
エビデンスチェーン
RCA は自動計算付きの構造化エビデンスチェーンを構築します。各アイテムは特定の仮説にリンクでき、どの所見がどの仮説を支持するかを示します。
エビデンスは重要度でランク付けされます:Critical(直接的な原因)→ High(強い支持)→ Medium(コンテキスト)→ Low(背景情報)。
信頼度スコアリング
特定されたすべての根本原因は 0.0〜1.0 の信頼度スコアを持ちます。
信頼度は、時間的相関・50% 超のメトリクス異常・一致するエラーパターン・除外された代替案・複数の裏付けデータソースにより上昇します。代替説明・弱い時間的相関・検証の欠如・相反するエビデンスにより低下します。
仮説追跡
RCA は「5 つのなぜ」とフィッシュボーン手法にインスパイアされた仮説駆動型調査を実行します。
エージェントは根本原因を設定する前に少なくとも 1 つの仮説を確認し、調査を終了する前にすべての仮説を(確認または否定として)解決します。
レイテンシインシデントの仮説チェーンの例:
調査タイムライン
RCA はすべての調査ステップのリアルタイムタイムラインをストリーミングします。フェーズの進捗、仮説のテスト、タイムスタンプ付きのエビデンス収集が表示されます。各調査は最大 100 エントリーを保持します(データベースレベルで適用)。ディスポジション
すべての調査はディスポジションで終了し、インシデントのステータスを更新します。
ディスポジション設定後、チームがフォローアップアクションを完了するにつれて、インシデントは追加のライフサイクルステータス(Resolved・Post-Mortem・Closed)に進むことができます。
調査を開始する
自動で
Webhook インテグレーションを設定して RCA を自動トリガーします。インシデントが重要度のしきい値を満たすと、バックグラウンドで調査が開始されます。手動で
1
インシデント詳細ページを開く
調査したいインシデントを選択します。
2
「RCA 分析を開始」をクリックする
CloudThinker が重複する RCA が実行されていないことを検証し、1〜3 秒以内に調査を開始します。エージェントが所見を発見するにつれ、タイムラインエントリーがリアルタイムで表示されます。
結果の読み取り方
バージョン追跡(v1・v2・v3…)付きで同一インシデントに対して複数回の調査を実行できます。新しい情報が入手可能になった場合や最初の実行が決定的でなかった場合は RCA を再実行し、履歴ドロップダウンで結果を比較します。
例:EC2 の終了と EKS ネットワーク障害
あるワークスペースで継続的モニタリングにより、2 つの相互に関連する所見が浮上しました。頻繁な EC2 インスタンスの終了と EKS のCreateNetworkInterface 障害です。エージェントがこれらをどのように一緒に調査したかを紹介します。
まず、Alex が終了パターンを分析します。

EC2 終了パターン分析:AutoScaling イベントを表示
次に、Alex がネットワーク障害と終了を相互関連付けします。
ネットワーク障害の相関:CreateNetworkInterface エラーと IP 枯渇
最後に、Anna が Alex(インフラとコスト)、Kai(EKS ネットワーキング)、Oliver(セキュリティ)の所見を 1 つのドキュメントに統合します。
包括的 RCA レポート:所見と修復ステップ
ベストプラクティス
- インシデントが発生する前にトポロジーを接続する — ブラストラジウス分析とサービス相関はトポロジーに依存します。
- Medium 以上の重要度のインシデントに対して RCA を自動トリガーするようWebhookを設定する。
- インシデントの説明にコンテキストを追加する。エージェントが最初にどこを調査するかの指針になります。
- 調査中はタイムラインを監視して、どの仮説がテストされ否定されたかを確認し、エビデンスのタイムスタンプがインシデント開始と相関しているか検証する。
- 信頼度が 0.7 未満の場合は根本原因を手動で検証してから修復し、Critical 優先度の修復アクションから着手する。
- 将来の調査中にエージェントが修復手順を検索・実行できるようRunbooksを接続する。
関連
Pulse
ノイズを抑制し、アクショナブルなクラスターをインシデントにエスカレーションするアップストリームのシグナルインテリジェンス
Webhook インテグレーション
PagerDuty・Datadog・Prometheus などから RCA を自動トリガー
トポロジー
インシデント発生時の迅速なブラストラジウス分析のためにライブ依存マップを構築
Runbooks
エージェントが修復ステップを実行できるよう運用 Runbook を接続