Splunk Agent Launchpadのご紹介：運用シグナルをエージェント主導のアクションに変換

もうご存じのとおり、エージェンティックAIとは、ユーザーに代わってアクションを自動化および実行し、アラートのトラブルシューティングや調査を迅速に行うことにより、ある意味で業務をより円滑にするものです。それはどのようなかたちで実現されるのでしょうか。Splunkは約1年前にMCPサーバーをリリースしました。これにより、企業独自のLLMやツールをSplunkプラットフォームに接続してクエリを実行するエージェントを構築できるようになりました。このエージェントはSplunkプラットフォームの外部で構築され、そこから対話を開始します。社内のデータサイエンティストやエンジニアなどの専門家が、エージェントを構築するためのモデル、ハーネス、ツール接続などを含むエージェンティックシステムを構築する必要があります。

このたび、Splunk環境内でRBACを活用しながらエージェントをノーコードで構築できる、Splunk Agent Launchpadの一般提供を発表します。これらの構築されたカスタムエージェントは、サーチやアラートをトリガーとして起動し、エージェントが推論を行ってアクションを実行するためのコンテキストを伴って動作します。データサイエンティストやAIの専門家は必要ありません。ご自身がIT、セキュリティ、ネットワークの各分野における専門家であり、ワークフローや必要なナレッジベースを把握していれば、自分の業務を効率化するエージェントを構築できます。

Agent Launchpadは、Splunkプラットフォームを統合したCisco Data Fabricの一部であり、エージェンティック運用の有効化と迅速化を実現します。

Splunkはすでに、何かが発生した際に通知を行う機能を備えています。例えば、アラートが発行される、スケジュールサーチで異常が検出される、検出によって不審なアクティビティが特定されるといったことが発生した場合にです。問題は、その後どうなるかです。こうしたシグナルを調査するには、通常、チケット、チャット、ランブック、ナレッジベース、クラウドコンソール、IDシステム、脅威インテリジェンスツールなどを切り替えながら横断的に確認する必要があります。そうすると、切り替えのたびに時間がかかり、実際の業務は、担当者が調査すべき箇所を知っているかどうかで左右されることになります。こうした状況を改善しうる自動化のアイデアがあっても、エンジニアリングのバックログに埋もれがちです。

シグナルとアクションの間に生じるギャップにより、調査が停滞することになります。

Splunk Agent Launchpadは、そうしたギャップを解消します。Splunk AI ToolkitのコンポーネントであるAgent Launchpadを活用すれば、セキュリティ、IT、エンジニアリング、ネットワークの各チームは、AIエージェントを構築し、シグナルが最初に発生したSplunkワークフローから起動して、各エージェントの実行内容を詳しく確認できるようになります。その際、コーディングは不要です。

空白のプロンプトではなく、シグナルから開始

多くのエージェントツールでは、空白の入力欄から始めるかたちになっており、ユーザーは自分が何を求めているのかを記述するよう問いかけられます。Agent Launchpadの場合は、すでに信頼できるとわかっている運用シグナルから始めるかたちになります。アラート、サーチ、スケジュールサーチ、サーチコマンド、検出、調査をトリガーとして、エージェントを起動できます。Splunkが調査に値する事象を特定した瞬間、適切なエージェントが、すでに付与されたコンテキストと共にその処理を引き受けます。

このコンテキストこそが、違いをもたらします。すべての処理は、SPLの結果、ログ、メトリクス、検出、異常、調査履歴などのSplunkのデータに基づいています。エージェントは、一般的な説明ではなく、チームが実際に直面している運用上の現実に基づいて推論を行います。そのため、コンテキストの収集に費やす時間を減らし、アクションの実行に費やす時間を増やすことができます。

コーディングスキルは不要

何を自動化すべきかを最もよく理解しているのは、実際に業務を行っているアナリスト、オペレーター、エンジニアです。しかし、彼らが自動化のための統合コードを記述できることは稀です。Agent Launchpadは、こうした依存関係を取り除きます。

アナリストやオペレーターは、ポイントアンドクリック操作でエージェントを作成します。カスタムモデルやスクリプト記述は不要です。他人のスプリントを待つ必要もありません。例えば、毎日フィッシング攻撃のトリアージを行っているアナリストは、自身が既に適用しているロジックをそのまま活用して、トリアージを自分の代わりに自動で実行するエージェントを構築できます。チームのランブックや個人が持っていた専門知識は、トライバルナレッジ(言語化されていない暗黙知)ではなく、再現可能なエージェントとなります。

設計段階から組み込まれた管理者によるガバナンス

担当者の使いやすさを追求するあまり、制御がないがしろにされては本末転倒です。Agent Launchpadは、この2つの役割を明確に分離しています。

Splunk管理者は、エージェントによる使用が許可されたMCPツール、外部接続、ナレッジソースを設定します。担当者は、これらの境界内でエージェントを構築および起動します。彼らが認証情報を扱ったり、独自のインテグレーションを構築したりすることはありません。また、アクセスは既存のSplunkのロールや権限に準拠しています。実行履歴はフィルタリング、RBAC、経時的な監査に対応しており、プラットフォームチームは環境全体でどのような処理が実行されたのかを把握できます。

担当者はシンプルな構築体験を得ることができ、プラットフォームチームは適切な領域でガバナンスを維持できるというわけです。

アクションをとる前にすべての実行結果を確認

エージェントに対する信頼性は、その実行内容を確認できることから生まれます。Agent Launchpadで完了したすべての実行内容には、実行履歴、呼び出されたツール、エビデンスのトレース、エラー、応答、その実行を対象とした追加の質問など、完全な記録が保持されます。

エージェントがユーザーの代わりに無断で行動し、後から同意を求めるようなことはありません。ユーザーがエビデンスを確認したうえで、次のステップを決定します。このようなレビューモデルだからこそ、誤った行動が重大な結果を及ぼしうるSOCやオペレーションセンターでも、安全に自動化を導入できるのです。

各チームによる構築事例

Agent Launchpadは、2026年1月からお客様向けにアルファ版が提供されています。さまざまなチームから以下のような実際のユースケースが報告されています。

• フィッシングのトリアージ(情報の補足や次の推奨ステップを含む)
• アラートのトリアージと調査
• 複数のSplunk環境にわたりスタックを横断する調査
• インフラの健全性チェックと運用の引き継ぎ
• チケット作成、通知、ランブックを活用したワークフロー

複数のエージェントをつなげることも可能です。あるパターンでは、最初のエージェントがリスクイベントを特定および収集し、関連するリスクIDを抽出します。次に2つ目のエージェントがSPLクエリを通じてその出力を受け取り、イベントの分析、サマリーの生成、リスクのスコアリング、チケットを作成すべきかどうかの判断を行います。データはSplunk内のエージェント間で保持されるため、複数段階のワークフローがプラットフォームの外部に出ることはありません。

アルファ版の顧客である大手インターネットサービスプロバイダーのSOCアナリストは、フィッシング攻撃のトリアージを行うカスタムエージェントの構築について、次のように述べています。

反復的な調査作業はエージェントが担います。アナリストは最終的な判断を下します。

Splunk Agent Launchpadが選ばれる理由

エージェントを作成できるプラットフォームは数多く存在します。しかし、より困難な課題は、適切なエージェントを、最適なタイミングで正しいコンテキストに合わせて起動することです。Agent Launchpadを使用すると、チームがすでに検出、調査、トラブルシューティング、対応を行っているワークフロー内からそれが可能となります。シグナル、分析、運用コンテキスト、ガバナンスといった要素は、すでにSplunk内にあります。Agent Launchpadは、エージェントを正しいコンテキストに誘導し、業務の現場から切り離された別のAI環境にチームが引き込まれるのを防ぎます。

提供状況

Splunk Agent Launchpadは、2026年7月15日より、Splunk AI ToolkitのコンポーネントとしてSplunk Cloud Platformで利用できるようになりました。

詳細については、Agent Launchpadをご覧ください。