根本原因からプルリクエストまで：Splunk Observability CloudのAI SREがClaude Managed Agentsを通じてインシデントの修復も実行

特定と修正の間のギャップを解消

オンコールエンジニアであれば、最悪の夜がどのようなものかご存じでしょう。午前3時に通知が届き、APIが500エラーを大量に生成していることを知り、顧客への影響が拡大し続ける中、有効な対策を探るため、十数個ものサービスにまたがるメトリクス、ログ、トレースの相関付けに追われる、といった具合です。

過去3年間でオブザーバビリティツールへのAI導入が進み、夜間の対応は以前よりも楽になったものの、根本から変わったというわけではありません。AIアシスタントはクエリーを書き、インシデントを要約してくれます。しかし、「可能性の高い根本原因の特定」から「具体的な修復内容の特定」までの作業は依然として、午前3時にほぼ人手で多数のツールを行き来しながら行っているのが現状です。

Splunkが解消しようとしているのはこのギャップです。今年6月に一般提供を開始した Splunk Observability CloudのAI SRE はすでに、インシデントライフサイクル全体にAIとエージェントを統合し、Observability Studioを通じて、インストルメンテーションの効率化、AIドリブンの検出、アラートのグループ分けを実現しています。これにより、アプリケーションとインフラ間で関連するアラートが1つの実用的なインシデントにまとめられ、証拠の連鎖に基づいて可能性の高い根本原因が特定され、ガイド付きの修復計画が提供されます。そして、最終ステップを実現するAnthropic社とのコラボレーションが発表されました。これは、検証済みの診断結果を具体的なコード変更とレビュー可能な修正内容に安全に変換するというものです。

Splunkは、ネットワーク、インフラ、アプリケーション、さらにはAIモデル自体を含むテクノロジースタック全体のテレメトリを保持しています。これだけの深度の運用コンテキストにフロンティアAIの推論能力を適用できるオブザーバビリティベンダーは、現時点ではSplunkだけです。そして、インシデントの発生時にエンジニアリングチームが得られるものも、これまでとは違います。根本原因分析だけでなく、修正案と次回に備えた検知の仕組みも得られます。

新機能：Splunk Observability Studioの、Claude Managed Agentsを基盤とする修復エージェント

Observability CloudのAI SREはエージェンティックチームメイトとして機能し、複雑さと手間を減らすのに役立ちます。インテリジェントアラート機能が、アラートを分類し、統一されたアクションにつながるインシデントに集約します。このAIトラブルシューティングエージェントは、すべてのテレメトリデータを分析して、複雑な問題が最初に発生した可能性のある場所を特定します。次いでチームは、ガイド付きの修復計画を実行するか、Claude Managed Agentsを基盤とする修復エージェントを使って安全なサンドボックス内でコードレベルの修正を実行できます。エンジニアは完全な制御権を維持しつつ、信頼を構築できます。

Splunkは、システムの運用状況に関する情報源として、インテリジェンスとガードレールを提供します。Splunk Observability Cloudの新機能であるAI SREとObservability Studioは、大量のシグナルを、証拠に基づく単一の仮説に変換します。また、Observability Studioは、コントロールプレーンとしてワークフローを所有し、変更が許可されている項目を判断して、検証を実行し、マージリクエストを作成したあと、修復が機能していることを確認します。Splunkは、認証情報、ポリシー、情報の最終記録も保持します。

Anthropic社は実行を担います。Claude Managed Agentsは、コーディングエージェントを安全に実行するためのマネージド環境を提供します。ネットワークから切り離された使い捨てのサンドボックスで、実際のソースコードに対して推論を実行し、変更の候補を提示します。実行エンジンとして動作範囲が慎重に定められており、適切に定義されたタスクを受け取って、必要な処理のみを実行し、結果を返します。

エージェントのコストや信頼性の問題の多くは、エージェントによる調査の再試行や繰り返しによって生じます。Claude Managed Agentsのパフォーマンスが最適化されたハーネスでは、長時間に及ぶ調査でも処理がループしたりコストが急増したりすることはありません。

全体の仕組み

テレメトリは、インシデントが発生する前に収集しておく必要があります。一般提供が開始されたObservability Studioでは、OpenTelemetryのインストルメンテーションがIDEに直接統合されるため、開発者が手動でインストルメンテーションを追加する手間を省くことができます。Observability Studioにコードベースの監査を依頼するだけで、サービスをローカルで実行しながら、そのサービスで収集すべきテレメトリの提案から、依存関係の解決、インストルメンテーションの適用、スパンやメトリクスの検証までを自動的に実行できます。このように、インストルメンテーションを1つのワークフローとしてガイドに沿って自動的に実行できるようになるため、人手での煩雑な作業が不要になります。Observability Studioによって、OpenTelemetry SDKが追加され、トレース、メトリクス、ログを収集する準備が整い、次のステップに進む前にシグナルが適切に送信されることを確認できます。重要なメトリクスがすでにわかっている場合は、ビジネスのニーズに合わせてテレメトリを調整することもできます。本稼働後にオブザーバビリティを実装しようとすると、事後対応的な改修に多大なコストがかかるだけでなく、重要なコンテキストを失うリスクもあります。

検出段階でも、すべてのしきい値を手動で調整する必要はありません。AIを活用した検出機能によって、アプリケーションやKubernetes環境が監視されます。そのため、最初にすべてのディテクターをゼロから定義しておく必要はありません。

関連するアラートは1つのインシデントにまとめられます。AIが検出したシグナルと独自のシグナルがアプリケーションとインフラをまたいでグループ化され、グループ化の理由も提示されます。これにより、調査に必要なコンテキストがトラブルシューティングエージェントに渡されるため、エンジニアは、絶え間なく発生する繰り返しのアラートをトリアージする負担から解放されます。

続いて、Observability Cloudのトラブルシューティングエージェントが調査を行います。インシデントや通知のコンテキストに基づいて、メトリクス、イベント、ログ、トレースが相関付けられ、最も可能性の高い根本原因が、信頼度と、判断の根拠となった証拠の連鎖とともに提示されます。.conf26の基調講演のデモでは、ある小売サイトでの販促キャンペーンによるトラフィック増加に伴う同時実行性の問題を例に挙げています。このような問題は、高負荷時にのみ発生し、コードを見ただけでは発見できず、テレメトリを確認することで初めて特定できます。

最後に、Claude Managed Agentsを活用した修復エージェントが修正策を提案します。この時点で根本原因がすでに特定されているため、修復エージェントは、そのテレメトリに基づいて、関連するコードを直接調査することから作業を開始できます。調査後、検証ステップを含む段階的な計画を提案し、プルリクエストを作成します。根本原因がコードにある場合、担当者はSplunk Observability CloudまたはIDE内のObservability Studioから修復エージェントを実行できます。

コードレベルの修復にエージェントを継続的に使用すれば、精度がさらに向上します。プルリクエストに対するアクション(マージ、編集、クローズ)はすべてフィードバックとして活用されます。Claude Managed Agentsにはセッション管理やメモリーストアの機能があるため、フィードバックが保持され、エージェントはインシデントの合間に学習した内容を統合していきます。エンジニアがエージェントと協力してインシデントに対応するたびに、ランブックが強化されます。

エンジニアは、プルリクエストをレビューする必要はあるものの、午前3時にデバッグに追われることはなくなります。

提供状況

Splunk Observability CloudのAI SRE：一般提供中

Observability Studio：一般提供中

Claude Managed Agentsを活用した修復：アルファ版