8月28日、AWSが「Reduce MTTR with AI-driven RCA using AWS DevOps Agent and Splunk」と題した記事を公開した。この記事では、AWS DevOps AgentとSplunkをMCPで連携させ、インシデント発生から根本原因特定・緩和計画提示までを自動化する手法について詳しく紹介されている。
「Splunkのアラートが飛んだら、あとはエージェントが調べる」
分散システムの障害対応で最もコストがかかるのは、「どのログとどのメトリクスを突き合わせるか」を人間が考える時間だ。ベテランなら30分で解決できる問題を、ローテーション中の若手が数時間かけて対応するという非対称性は多くの現場で起きている。
AWSが紹介するのは、この非対称性をなくすアーキテクチャだ。SplunkのアラートをWebhookでAWS DevOps Agentに送り、エージェントが仮説検証から根本原因の特定、緩和計画の提示まで自律的に実行する。
AWS DevOps Agentとは何か
AWS DevOps AgentはAmazon Bedrock AgentCore上に構築された運用自動化エージェントだ。「Agent Space」という論理コンテナ内で動作し、以下を統合的に扱う。
- AWSアカウント、リポジトリ、テレメトリソース
- GitHub、GitLab、Jira、PagerDutyなどの外部ツール
- MCP（Model Context Protocol）経由の外部観測基盤
エージェントはIAMロールで読み取り専用アクセスのみを持ち、すべての推論ステップは改ざん不能な監査ジャーナルに記録される。
調査は「Triage（トリアージ）」「RCA（根本原因分析）」「Mitigation（緩和策）」という3つの専門ペルソナが段階的に担当する構造になっている。この設計には明確な意図がある。単一のエージェントに全工程を委ねると、初期の誤った仮説が後続ステップに引きずられるリスクがある。役割を分離することで、各ペルソナが独立した視点で推論を進め、段階ごとに証拠を積み上げていく。「Agent Space」はこれらのペルソナと接続ツール群をひとつの論理境界に収める器であり、アカウント情報やトポロジマップを共有コンテキストとしてペルソナ間で引き継ぐ役割を担っている。
なぜSplunkとの連携が重要なのか
AWS CloudWatchはAWS境界内のメトリクスやログを扱うが、外部APIやオンプレシステムのテレメトリはCloudWatchに届かない。多くの企業はSplunkに何年分もの運用知識（保存済み検索、ダッシュボード、アラートロジック）を蓄積している。
AWS DevOps AgentはSplunk MCPサーバーを介してSplunkに接続し、調査中に自律的なSPLクエリを構築する。既存のインジェストパイプラインやインデックス設定を変更する必要はない。Splunk MCPサーバーの詳細については元記事内のリンクから確認できる。
連携で実現できる主な機能は3つだ。
| 機能 | 内容 |
|---|---|
| 直接Splunkアクセス | エージェントが調査中にSplunkへクエリを発行。パイプライン変更不要 |
| クロスドメイン相関 | Splunkのアプリログ＋CloudWatchメトリクス＋CloudTrail＋CI/CDデプロイ履歴を横断分析 |
| アラートからの自動起動 | SplunkのアラートがWebhookでエージェントを起動。人間のページ待ちが不要 |
MCPという選択にも設計上の理由がある。独自のプラグインAPIを実装すると、観測基盤の種類が増えるたびにエージェント側のコードを修正しなければならない。MCPはその接続層を標準化するオープンプロトコルであり、Splunk以外の観測基盤も同じ仕組みで接続できる拡張性を持つ。AWS・Splunk双方がMCPに対応したことで、既存資産を変更せずに連携できる点がこの構成の実用上の強みだ。
実例：医療請求パイプラインの障害をデモ環境で検証
記事ではヘルスケア分野の請求処理パイプラインを例に挙げている。Lambda→ECS→SQS→DynamoDB→S3という構成で、外部クリアリングハウスAPIが請求の最終送信を担う。
障害シナリオ： 17:25 UTC頃、トラフィックスパイクが発生。Lambda関数が一斉にクリアリングハウスAPIを叩き、レートリミット（HTTP 429）を使い果たした。請求成功率が80.7%低下し、SQSキューが枯渇、査定処理が停止した。
なお、後述する「8分以内」という所要時間は元記事のデモ環境における測定値であり、本番環境での性能を保証するものではない。
ステップ1：Splunkがアノマリを検知
保存済み検索が成功率の閾値割れを検出し、Webhookでエージェントに通知。エラーパターンとタイムスタンプが送信される。
ステップ2：トポロジを参照して影響範囲を特定
エージェントはAgent Space内に事前構築されたトポロジマップを参照し、影響を受けるコンポーネントを即座に特定する。手動トレースは不要だ。
ステップ3：並列で仮説検証
RCAペルソナが2つの仮説を検証する。
仮説A：内部インフラ障害
CloudWatchでECSクラスターのCPU・メモリ・タスク数を確認。すべて正常範囲内。デプロイや設定変更の履歴もなし。内部原因を除外。
仮説B：外部依存の障害
Splunk MCPサーバー経由でクリアリングハウスAPIのレスポンスコードを照会。17:25 UTCからHTTP 429が急増していることを確認。この信号はCloudWatchには存在しない——Splunk連携があって初めて見えるデータだ。
確認された証拠：
- HTTP 429レスポンス：2,737件
- HTTP 200（成功）：655件
- 失敗率：80.7%
ステップ4：緩和計画を提示
根本原因「トラフィックスパイクによる外部APIレートリミット枯渇」が確定し、Mitigationペルソナが以下を出力した。
- 即時対応： クリアリングハウス呼び出しにExponential Backoff + Jitterを実装
- 短期対応： サーキットブレーカーパターンを追加、レートリミット時のリトライキューを設ける
- 予防策： クリアリングハウスベンダーにレートリミット引き上げを申請
デモ環境でのアラート受信から緩和計画提示までの所要時間：8分以内。
セットアップの概要
前提条件として以下が必要だ。
- Agent Spaceの作成（AWSアカウント、リポジトリ、テレメトリソースを含む）
- Splunk MCP ServerをAgent SpaceのツールとしてBearer Token認証で接続
- SplunkのWebhook許可リストにエージェントのWebhook URLを追加（Splunk Web → Settings → Server settings → Webhook allow list）
- SplunkのアラートアクションでWebhookを設定（認証はカスタムヘッダーオプションを使用）
詳細な設定手順は元記事を参照していただきたい。
まとめ
Splunk単体ではAWS内部の構成変更やデプロイ履歴は見えない。CloudWatch単体では外部APIの429パターンは見えない。MCPで両者をつなぐことで、AWS境界をまたいだ完全な根本原因分析が成立する。
この構成は医療請求に限らず、決済ゲートウェイ、配送API、IDプロバイダー、パートナーサービスなど外部依存を持つあらゆるワークロードに適用できると記事は述べている。
詳細はReduce MTTR with AI-driven RCA using AWS DevOps Agent and Splunkを参照していただきたい。
