AIが変えるオブザーバビリティ体験

生成 AI とエージェント型 AI (Agentic AI)の登場によって、IT 運用の現場が急速に変わりつつあります。たとえば Splunk は公式ブログで、2026 年を「Agentic AI 革命の年」(拙訳)と位置付けています。一方で、AI がどれほど賢くなっても、AI が参照できるデータの質と広さがなければ、その判断は推測の域を出ません。

ここで重要になるのが、AI とオブザーバビリティの関係です。両者の関わり方は、次の 2 つの観点に整理できます。

• AI for Observability: AI を活用してオブザーバビリティを進化させる
• Observability for AI: AI システムや LLM アプリケーションそのものをオブザーバビリティで監視

本記事では前者の AI for Observability にフォーカスします。Splunk もこの領域へ次々と投資を重ねてきました。その中核を担う Splunk Observability Cloud で利用できる、3 つの AI 機能を紹介します。

• Splunk MCP server による、AI エージェントとオブザーバビリティデータの接続
• Splunk AI Assistant in Observability Cloud（以下 AI Assistant）による、自然言語での問題調査
• AI troubleshooting agent and remediation plan（以下 AI troubleshooting agent）による、根本原因分析と修復手順の自動生成

対象読者は、SRE・DevOps・アプリケーション運用の担当者です。Splunk Observability Cloud をすでにお使いの方、これから試してみたい方、今後の AI 活用を検討している方を想定しています。それぞれの機能について「何ができるか」「どのような場面で役立つか」を整理していきます。

Splunk MCP server により AI エージェントから Splunk Observability Cloud を活用する

機能概要

Model Context Protocol（以下 MCP）は、AI アシスタントやエージェントが外部のツールやデータに安全にアクセスするための共通プロトコルです。Splunk MCP server は、2026 年 2 月 4 日に一般提供（GA）となりました。これにより、お使いの AI エージェントから、自然言語で Splunk Observability Cloud のデータへ直接アクセスできます。Claude Code・Cursor・Codex CLI などから、メトリック・トレース・ログ・アラートを横断的に参照できます。設定方法は公式ドキュメントの「Interact with your observability data using the Splunk MCP server」を参照してください。VS Code や Claude Desktop からの設定例も掲載されています。

どのようなユースケースで役に立つか

Splunk MCP server が解決するのは、AI と運用データのあいだに生まれていたサイロ化の問題です。これまでは AI が便利でも、肝心の運用データに直接アクセスできなければ、対応できることは限られていました。Splunk MCP server を使うことで、たとえば次のような操作を、お使いの AI エージェントから自然言語のプロンプトで進めやすくなります。

• カスタマーサポート経由で報告された不具合の影響範囲を APM から特定
• エラートレースを取得し、特定のリクエスト属性で発生する障害を切り分け
• 根本原因が特定できたら、既存の開発・CI/CD ツールと組み合わせて、関連するソースコードの修正やデプロイを支援
• 復旧後にメトリックを参照して、アラートが解消したかを確認
• 一連の調査結果から障害報告レポートを生成

これは障害対応の「調査 → 修正 → 確認 → 報告」のサイクルそのものです。従来は複数のダッシュボードを行き来したり、SignalFlow プログラム（分析のための言語）を書いたりする必要がありました。Splunk MCP server があれば、これらの作業の入口を、自然言語の対話と日常的に使う AI エージェントに集約しやすくなります。オブザーバビリティの専門知識が浅いメンバーでも、本番障害の対応に貢献しやすい環境が整います。

デモ動画

以下の動画では、ここまで紹介したワークフローを実際に動く形で確認できます。題材は Amazon EKS 上に展開した OpenTelemetry の公式デモアプリです。Claude Code と Splunk MCP server を組み合わせ、数回のプロンプトだけで不具合を解決する流れを紹介します。具体的には、CAD（カナダドル）決済の失敗を Splunk Observability Cloud のエラートレースから特定します。その後、ソースコードの修正・ビルド・デプロイ・復旧確認・障害報告レポートの自動生成までを、自然言語の対話だけで完結させる様子を確認できます。

AI Assistant で対話的に問題を深掘りする

機能概要

AI Assistant は、Splunk Observability Cloud に組み込まれた生成 AI チャットアシスタントです。「Payment サービスで何が起きていますか」のような自然言語の問いかけに対して、メトリック・トレース・ログ・アラートなどを横断的に参照して回答を返します。正式版（GA）として提供されており、日本リージョン（jp0 realm）でも利用できます。当初は Splunk APM と Infrastructure Monitoring（IM）を中心とした機能でした。現在は対応範囲が広がり、Splunk APM・RUM・IM を横断的に扱えます。

公式ドキュメントの AI Assistant in Observability Cloud では、以下のような利用方法が紹介されています。

• インシデントやアラートのサマリー取得
• サービスヘルスの分析と、過去 15 分や直近 1 時間での問題の特定
• トレース ID を指定したトレース分析、上流・下流サービスの相関調査
• 自然言語からの SignalFlow クエリー生成と即時実行
• インフラストラクチャナビゲーターやチャートの検索

ユーザーは画面右側のツールバーから AI Assistant を開きます。提案プロンプト（「アクティブインシデントを表示」「過去 15 分間のエラートレースを表示」など）を選ぶか、または自然言語で質問するだけで使い始められます。

どのようなユースケースで役に立つか

AI Assistant は、次のような場面で特に効果を発揮します。

• 「最近、何かおかしい気がする」程度の漠然とした懸念から、具体的な兆候を引き出したい場面
• 経験の浅いエンジニアでも、メトリック・トレース・ログ・アラートを横断した調査を独力で進めたいケース
• ダッシュボードを新規作成する際に、SignalFlow をゼロから書かずにたたき台を素早く得たいとき

特にフロントエンドからインフラまで、一貫した目線で調査を AI に任せやすい点が、横断的なトラブルシューティングを大幅に加速します。具体的なユースケースとプロンプト例は、別記事の「Splunk Observability Cloud AI Assistant 再入門 - 4 つの基本ユースケース」でも詳しく解説しています。合わせてお読みいただくと、自社環境への当てはめ方がイメージしやすくなります。

デモ動画

以下の動画では、AI Assistant の動作を確認できます。アラートの調査からトレースの解析、原因特定、対応方針の提案までの流れを、Splunk APM を題材に解説しています。なお現在は Splunk RUM や Splunk IM にも対応しているため、動画の操作感をベースに、ご自身の環境に置き換えてみてください。

この動画の中では Preview という表記が見えますが、現在の AI Assistant 実画面ではその表記はなくなり、正式版となっています。

AI troubleshooting agent で根本原因分析と修復を加速する

機能概要

AI troubleshooting agent は、根本原因分析と修復手順の生成を自動化する AI 機能です。Splunk Observability Cloud のアラートをトリガーとして動作します。対象は Splunk APM と、Splunk IM における Kubernetes 関連のアラートです。ユーザーがアラートを開くと、AI troubleshooting agent が自動的に起動し、根本原因の解析を開始します。現時点では us1 realm の利用者向けにプレビューとして段階的に提供されており、利用を希望する場合は Splunk の担当者へ相談してください。

起動した AI troubleshooting agent は、アラートの要約や影響範囲をまとめ、根本原因の候補と判断材料になる分析結果を示します。合わせて、根拠となるログや Exemplar trace（代表的なトレース）も提示します。解析は画面を一度離れても継続するため、結果を待ちながら他の作業を進められます。

根本原因が示されたら、続く修復ステージ（AI remediation plan）で、グラフ形式の手順を確認できます。Kubernetes 関連の問題では kubectl コマンド、アプリケーションの問題ではコードブロックが提示され、実行結果を貼り付けながら手順を 1 つずつ進められます。すべての手順を消化すると、その流れのままアラートを解決済みとしてクローズできます。これらの画面例は、公式ドキュメントに掲載されています。

どのようなユースケースで役に立つか

AI troubleshooting agent の価値については、Splunk の英語ブログ で詳しく整理されています。ポイントとしては、さまざまなペルソナ・役割に対して、次のような利点をもたらします。

• 一次対応者（システムサポート、L1 アナリスト）にとっては、新人でも対応しやすい一貫したガイドの提供
• SRE にとっては、トリアージから戦略的な改善業務への時間配分
• アプリケーション開発・DevOps にとっては、自分の担当領域に絞った文脈付きの情報を受け取れる環境・仕組み
• サービスオーナー・プラットフォームオーナーにとっては、インシデントの各コンポーネントへの波及を、データに基づいて把握しやすいこと

ここで重要なのは、「AI だから平均復旧時間（MTTR）が短くなる」という一般論ではありません。既にあるメトリック・トレース・ログ・依存関係を相関付け、実際のインシデントの文脈で原因候補と次の確認手順を早く示せる点に本質があります。これにより、原因特定までの時間（MTTI）を短縮しやすくなり、その後の修復判断と作業も進めやすくなるため、MTTR の改善にもつながります。AI が定型的な調査を引き受け、エンジニアは判断や設計、根本対策に集中できる構図です。

デモ動画

以下の動画では、Kubernetes Pod ステータスのアラートを題材に、AI troubleshooting agent の動作を紹介しています。アラートを開くと解析ステータスが表示され、ImagePullBackOff の根本原因候補が高い信頼度で示されるところから始まります。

続いて、Pod ステータスの分析・レジストリ接続性の確認・イメージ存在の確認・セキュリティーチェックといった一連の修復ステップがグラフで提示されます。提示された kubectl コマンドは、担当者がコマンドの内容と安全性を確認したうえで実行します。ターミナルに出力を貼り付けて次のステップへ進めます。つまり、あくまで人間がループの中に留まり、各コマンドの実行可否を判断する設計です。複数の根本原因候補がある場合に Evidence タブで信頼度別の情報を確認できる点や、画面内で AI Assistant にコンテキストを引き継いで対話できる点もデモで示されています。

まとめ

本記事では、Splunk Observability Cloud で利用できる 3 つの AI 機能を紹介しました。

それぞれ役割は異なりますが、いずれも「人間がダッシュボードを順番に眺める運用」から「人間と AI が協働してオブザーバビリティを扱う運用」への移行を後押しする機能です。Splunk Observability Cloud は、こうした AI for Observability の体験を、すでにお使いのオブザーバビリティ基盤の延長線上で提供します。

次のステップとして、まずはご自身の環境で触ってみてください。Splunk Observability Cloud は 14 日間の無償トライアル を提供しています。クレジットカードの登録は不要です。そのためハードルが低く、ご自身で AI for Observability がどこまで進化したかを確かめたい方にも向いています。