Splunk Observability Cloud AI Assistant 再入門 - 4つの基本ユースケース

Splunk Observability Cloud(o11y cloud)では、LLMを利用してオブザーバビリティデータを分析し、ユーザーにインサイトを提供するチャットボット機能であるAI Assistantを提供しています。ドキュメントに記載されているサポート言語は英語のみですが、実はプレビューリリースから日本語で利用することができ、2025年7月より日本リージョン(jp0 realm)でも一般提供しています。

本記事では、o11y cloudのAI Assistantの機能や動作について、これまで発表した内容を振り返り、再入門のための情報を提供します。

AI Assistantの紹介と機能振り返り

保存したテレメトリデータ・チャート・アラートに関する分析

AI Assistantを活用することで、Splunk Observability Cloudに保存されているメトリクス、チャート、トレース、インシデントアラート、ダッシュボード、サービス、エラーのインサイトをすばやく得ることができます。

一例として、Kubernetesクラスタのメトリクスに関するインサイトを確認してみます。Infrastructure MonitoringのClustersナビゲーターで、対象となるクラスタをフィルタリングして、AI Assistantの”Use current page filters”をONにして障害の予兆がないか質問します。

スクリーンショットでは回答のみが表示されていますが、回答の生成過程ではAI Assistantが自動的にクラスタ内の情報を検索し、SignalFlowを作成・実行して情報を収集していることが見てとれます。

このように、AI Assistantは現在表示しているページをコンテキストとして持ち、自律的に関連情報を収集し、インサイトを生成します。同様に、特定のチャートやインシデントアラート・サービスに関するインサイトを得ることもできます。

質問の際は、調査対象を特定するユニークなIDや名称をプロンプトに含めると、精度の高いインサイトを生成することができます。

エラー率の高いサービスについて、APMデータを基にレポートを生成しました。状況の確認だけでなく、個別のトレースを参照することでトラブルシューティングを行うこともできます。次節で細かく見ていきましょう。

Splunk APMとSplunk Infrastructure Monitoringを使ったトラブルシューティング

前節ではエラーに関する情報を収集しましたが、続いてAI Assistantを利用してエラーの根本原因及び、修正のための手掛かりとなる情報を収集していきます。

AI Assistantの回答は以下のように締めくくられています。

この時点で、既に401エラー(Unauthorized)がv350.10で発生していることが分かります。

エラートレースをいくつか確認するだけでは情報が足りないようなので、引き続きログを検索するように依頼します。

ButtercupPaymentsを利用する際のAPIトークンが無効であることがログから分かりました！Splunk Observability Cloud内部ではOpenTelemetry (以下OTel)の仕様に従い、メトリクス・トレース・ログを関連付けているため、AI Assistantが関連したテレメトリデータを調査し、分析結果を得ることができます。

また、別のケースとして、OTel Collectorの設定をはじめとする、Splunk Observability Cloudそのものを利用するための設定に関するトラブルシューティングもAI Assistantが支援できます。

テレメトリデータに関するインサイトと違い、環境やデータへのアクセスが限定的となりますが、OTelに不慣れな開発者にとって重要な基礎知識を得られます。

SignalFlow作成支援

SignalFlowは、Splunk Observability Cloudで使用されるプログラミング言語であり、リアルタイムのデータストリームを処理するために設計されています。SignalFlowを使用すると、ユーザーは複雑なデータ分析を行い、カスタムメトリクスを作成し、アラートを設定することができます。

データの集計、フィルタリング、変換といったオブザーバビリティで重要なユースケースには強い反面、用途が限定的な言語であるため、使いこなせるエンジニアは貴重です。

そんなSignalFlowですが、AI Assistantを活用することで自然言語で要件を記述することで、対応するSignalFlow文を生成し、チャート作成やディテクターに利用することができます。

生成AIを活用する際、しばしば成果物のレビューがボトルネックとなりますが、SignalFlowの実行結果はチャートとして表示可能なので、開発者が目視で正当性を確認することができます。例を見てみましょう。

1回目の回答で提示されているSignalflowは、言外の要件を反映していないことも多いため、対話を繰り返して納得のいくコードを生成していきます。

Y軸の設定など、Signalflowの範囲外となるチャート設定については手動で行う必要がある点に留意してください。

メトリクス・チャート・アラートの検索

Splunk Observability Cloudは、多数の組み込みチャート、OTel で取得されるメトリクスを利用できますが、時としてこの豊富なデータがあるがゆえに、どのチャートを見るべきか分からなくなることもあるでしょう。

チャート生成の対話を繰り返す際に、全くデータポイントが取得されないためメトリクスを変更する場面がありました。このような場合、改めて Metric Finderを開くことなくAI Assistant経由で最適と思われるメトリクスをいくつかリストアップしてそのまま作業を進めることができます。

プロンプトライブラリの紹介

ここまで、AI Assistantの使い方について一通り説明しましたが、Splunkではより良いプロンプトを作成するためのガイドドキュメントを用意しています。

リンク先に詳しく説明していますが、「できるだけ明確で具体的な質問や指示を提供すること」が原則です。環境名やサービス名、リソースIDなど、操作対象を特定できる情報は積極的にプロンプトに含めることをお勧めします。

ユースケースの紹介

本記事で紹介したユースケースのほかに、別のブログ記事でも7つのユースケースを紹介しています。

プロンプトは書けば書くほど慣れていき、「こんなこともできるのでは？」というアイディアも浮かんできます。是非一度目を通して、AI Assistantの可能性を感じていただければと思います。

APIを経由したデータ取得との違い

最後に、AI Assistantがどのようなアーキテクチャで動作しているかを紹介します。

Splunk Observability Cloudのデータの多くはAPIで取得することができます。このことをご存じの方は手元のAI Agent経由でAPIを呼び出しても、同じような結果を得られると考えた方もいるのではないでしょうか。

Splunk Observability CloudのAI Assistantは、単にAPIリクエストを自動化するツールではありません。内部では、ユーザーからの自然言語による質問や指示を受け取り、複数の内部コンポーネントを連携させて、最適なデータ取得・分析・回答の生成といった一連の流れを実行します。

これは別のブログ記事より引用したAI Assistantのアーキテクチャです。

AI Assistantは、大規模言語モデル(LLM)を核としたエージェント型アーキテクチャを採用しています。ユーザーの質問は「オーケストレーションエージェント」により解釈され、適切なツール(Observability Cloud内の各種APIや内部サービス)を呼び出す計画を立てて実行します。必要に応じて複数のツールを順番に組み合わせ、結果を統合して回答を生成しています。

このアーキテクチャにより、単純なAPIの組み合わせよりも、ユーザーの意図に沿った回答を返せるシステムを実現しています。

おわりに

筆者もまだSplunk Observability Cloudを使い始めて日が浅いのですが、AI Assistantを活用することで、オブザーバビリティの技術実証や学習を高速化できることに驚いています。

若干話が逸れますが、Splunk Observability Cloudは、OpenTelemetryネイティブという特徴を持っているので、手元のアプリケーションを計装する際も、AIコーディングエージェントを使った際の実装がかなり楽になっている実感があります。AIの力をフル活用して開発を進めるにはもってこいの環境です。

Splunk Observability Cloudは、14日間の無料トライアル期間を用意しています。ぜひこの機会に、AI Assistantをお試しいただければと思います。