前回に引き続き、Splunk .conf26の現地レポートをお届けします。

前回のブログでホテルのエレベーターの異音の話をしましたが、2日目の夜に外出しようとエレベーターを呼んだのですが、なかなか来ませんでした。
全く反応がないので仕方なく階段を使って下りました。
ちなみに私の泊まった部屋は"13階"でした。

不吉な予感を覚えながら外に出たのですが、外には消防車がたくさん止まっていました。

原因が分かり一安心です。

※ちなみに外出から帰った際には何事もなく収まっており、何があったのかがわからずじまいです。。

前回は9/14(月)に開催された基調講演「Powering the Rise of the Agentic Enterprise」を紹介しました。
前日の基調講演では、Agentic AI時代に起きる変化として、

•Inference = New Workload
• Agents = New Workforce
• Tokens = New Currency
• Control = New Moat

という4つのキーワードが紹介されました。

今回は翌日の9/15(火)に開催されたProduct Keynote「The Platform for Your Agentic Enterprise」のレポートとなります。

前日の基調講演が「Agentic AI時代に何が変わるのか」というビジョンや概念的な内容だったのに対して、今回のProduct Keynoteでは「それをCiscoとSplunkの製品でどう実現するのか」が、数多くの製品発表やライブデモとともに紹介されました。

情報量の多いセッションでしたので、今回は前半として「AIをどう信頼して運用するのか」という観点を中心に紹介します。

①Trust AI at Scale

最初にKamal Hathi氏から提示されたProduct Keynote全体のテーマが、

「Trust AI at Scale」

です。

AI Agentが企業の中で実際に仕事をするようになると、デジタルレジリエンス(サイバー攻撃や障害が発生しても、事業を継続・復旧する力)の考え方も変わります。

これまではシステムに問題が発生した際に、

「何が起きたのか」
「セキュリティインシデントなのか」
「ネットワークなのか」
「アプリなのか」

を素早く把握し、復旧することが重要でした。

しかし、AI Agent自身が業務を行うようになると、

「AIは実際に何をしているのか」
「意図した通りに動いているのか」
「許可した範囲を超えて行動していないか」

まで把握する必要があります。

そのため、AI Agentのすべての行動を記録し、必要に応じて制御できる仕組みが必要になると説明していました。

そしてSplunkでは「Trust AI at Scale」を実現するための領域を、大きく3つに整理しています。

・Optimize AI at scale
・Defend at machine speed
・Turn machine data into agentic action

今回はこのうち、前半2つを中心に紹介します。

②Optimize AI at scale

最初にAnthropicのJenny Sha氏を迎え、企業がAI Agentを本番環境で利用するために何が必要なのかが語られました。

ここで印象的だったのが、

「AI Agentを新しくチームに入ったエンジニアと同じように考える」

という話です。

AI Agentだからといって、最初からすべての権限を与えて完全自律で動かすわけではありません。
最初はRead Only(読み取り専用)から始め、Agentが何をしようとしているのかを確認し、実績を積みながら徐々に権限を広げていきます。

また、取り消すことのできないアクションを実行する場合には、人間に許可を求めることが重要であると説明していました。
前日の基調講演ではAI Agentを「非常に賢いTeenager」に例え、完全に放置すべきではないという話があり、本Product Keynoteでは、それを実際のシステムとしてどう実装するのかがより具体的に示された形になっていました。

Splunk AI SREとAnthropic ClaudeによるRemediation(修復)デモ

続いてSplunkとAnthropicによるライブデモが行われました。

デモではアプリケーションの開発から、本番環境でインシデントが発生し、修正するところまでを一連の流れとして紹介していました。

SplunkのAI SRE(Site Reliability Engineering)は、AI Agentがアプリケーションのテレメトリを分析し、障害の原因調査を支援するSplunk Observabilityの機能です。

デモでは、AI SREが問題を検知してRoot Cause(根本原因)を特定し、その結果をAnthropic Claudeへ連携。
そしてRemediation Agentの機能で、AI SREが特定したRoot Causeを引き継ぎ、ClaudeがCode Repositoryを確認して修正コードとMerge Requestを作成するところまでを自動化していました。

ただ修正内容をそのまま本番環境へ反映するのではなく、最終的なレビューや承認は人間が行います。
障害の検知・原因分析からコード修正までをAIで大幅に自動化しつつ、重要な判断には人間が介在する「Human in the Loop」を実践したデモとなっていました。

なお、AI SREは現在GA(General Availability)済みで、Remediation Agentは10月に提供予定と説明されていました。
(今後の記事内で機能リリース時期のアナウンスがありますが、米国内での予定時期となり日本でのリリースとは異なる可能性があります)

Agent Observability

次にVikram Chatterji氏により紹介されたのがAgent Observabilityです。

従来のアプリケーションは、基本的には決められたプログラムに従って動作します。
一方、AI Agentは同じ入力に対して必ず同じアクションを取るとは限りません。

そのため従来の「アプリケーションが正常に動いているか」というObservabilityだけではなく、「AI Agentを信頼できるか」
という観点でObservabilityを考える必要があります。

Agent Observabilityでは、

•Agentのふるまい
•モデル
• ツールの利用状況
•パフォーマンス
•トークン
•コスト

などを観測します。

今回、Splunk Agent ObservabilityのGAも発表されました。

Verizonとの対談

続いて、VerizonでAI Governanceを担当するDiganta Nayak氏との対談が行われました。

対談では「You cannot govern what you cannot see（見えないものは管理できない）」という考え方が示され、AI Agentを安全に運用するためには、Agentが何を行い、どのモデルやツールを利用し、意図した範囲で動作しているかを継続的に観測することが重要だと説明されました。

また、AIのコストについても、単純にトークンの使用量を減らすのではなく、得られるBusiness Outcome(事業成果)と合わせて評価する「Tokenomics」という考え方が紹介されました。

AIの費用対効果を捉える考え方に近いものだと思います。

AI Agentのガバナンス、Observability、コストを個別に考えるのではなく、一連の仕組みとして継続的に評価・改善していくことが重要という内容でした。

Agent Observabilityライブデモ

SplunkのXian Ke氏によるライブデモが行われました。

架空のスマートフォンを販売するECサイトに顧客満足度を向上させるAI Agentが導入されています。

顧客がスマートフォンの割引を聞くと、AI Agentは300ドルの割引を提示しました。
顧客としては嬉しい回答です。
しかし問題があり、この300ドルの割引プロモーションはすでに先月終了していました。

「顧客満足度を向上させる」というAI Agentに与えられた目的だけを見れば成功していますが、ビジネス的には損失が発生しています。
このような、開発者が事前に想定していなかったAgentのふるまいをSplunk Agent Observabilityが検出します。

大量のTrace(AI Agentの一連の処理)から、「期限切れのプロモーションが適用されている」というSignal(兆候)を検出し、Root Causeを確認します。
さらに、そのSignalからEvaluator(評価ロジック)を作成し、今後「期限切れのプロモーションを適用していないか」を継続的に評価できるようにします。

さらにSplunkでは、先ほど作成したEvaluatorを監視だけに利用するのではなく、Agentを制御するGuardrailとして利用します。

デモではEvaluatorをInline Guardrailとして組み込んでいました。

その状態でもう一度同じ質問をすると、今度は終了済みの300ドル割引ではなく、現在有効な200ドルの割引が案内されました。
と言いたいところなのですが、なぜかデモでは上手くいかずに300ドルの割引が提示されたままでした。
切り分けを実施されていましたが時間内では上手くいかずにデモはそのまま終了となっていました。
この辺りはライブデモの怖いところで、デモを実施することがある立場としてもヒヤッとするところなのですが、大きな会場内でもそのままさらっと流してしまえるのは見習いたい点です。

話を戻すと、
観測
↓
検知
↓
評価
↓
Guardrail
↓
制御

という一連のループを構成しています。

しかもAI Agentを停止して修正するのではなく、稼働中のAgentに対してリアルタイムに制御を適用している点がポイントです。

前日の基調講演で紹介された「Control = New Moat」が、具体的な製品として見えてきたデモでした。

Tokenomics

Agentic AIでは、無視できない問題の一つがトークンのコストです。

前日のKeynoteでもありましたが、AI Agentは人間から質問された時だけ動くChatbotとは異なり、24×7で動作し、さらにAgent同士でもやり取りするため、トークンの消費量は非常に大きくなります。

今回、Agent Observabilityの一部として「Tokenomics」のGAも発表されました。

ただし、Tokenomicsは単純に、

「トークンをできるだけ減らす」

という考え方ではありません。

Verizonとの対談でもありましたが、単純なトークンの使用量だけではなく、「そのAIのコストによって、どれだけの事業成果を得られたのか」を見る必要があります。
前日の「Tokens = New Currency」に対するSplunk側の具体的な回答がTokenomicsと言えそうです。

Full-stack Observabilityとしてのライセンス

ここまでAgent Observabilityを中心に紹介してきましたが、Splunkが目指しているのはAI Agentだけではなく、AIを支えるシステム全体のObservabilityです。

Splunkでは、Agent Observabilityに加えて、アプリケーション、Digital Experience、ネットワークなどの従来のObservability対象を含むFull-stack Observabilityを提供し、AI Agentからそれを支えるシステムまでEnd-to-Endで観測できる環境を目指しています。

今回、Observability Cloudの新しいEssentials / Premierエディションが発表されました。

Agent ObservabilityはEssentialsに含まれます。

③Defend at machine speed

ここからテーマはObservabilityからセキュリティへ移ります。

最近よく言われることですが、AI Agentを利用するのは企業だけではなく、攻撃者もAIを利用するようになっています。

AIによって、

•脆弱性の探索
•複数の脆弱性を組み合わせた攻撃
•サプライチェーンへの攻撃
•ソーシャルエンジニアリング

などが高速化し、人間だけでマシンスピードの攻撃へ対応することが難しくなると説明していました。

そこでSplunkが進めているのがAI Agentを活用してSOC業務を支援・自動化する「Agentic SOC」です。

Agentic SOC

SplunkのJohn Morgan氏によるAgentic SOCの説明です。

Agentic SOCでは、SOC Analystがすべてのアラートを1件ずつ調査するのではなく、AI Agentが、

Triage(優先度付け)
↓
Investigation(調査)
↓
Response(対応)

などを実行します。

ただし、ここでも「何でもAIに任せる」という考え方ではありません。

SplunkはAgentic SOCの原則として、

•Human Control
•Trusted Agent Design
•Economic Responsibility
•High Efficacy

を挙げていました。

Economic Responsibilityでは、すべての処理をLLMに任せるのではなく、

「これは人間が判断する」
「これはAgentに任せる」
「これは従来通り定型的に処理する」

と使い分けます。

AIでできるから何でもAIに置き換えるのではなく、コストやリスクを考えながら適切な手段を選択するという考え方です。

そしてAgentic SOCについても既にGA済みのアナウンスがありました。

Constellation Energyとの対談

実際にAgentic SOCを導入しているConstellation Energyの事例も紹介されました。

AIをSOC Analystの代替ではなく、業務を支援する「Accelerator」と位置付けていることが紹介されました。
定型的な作業からAI Agentに任せ、信頼性を確認しながら徐々に自動化の範囲を広げることで、ある脅威への対応を約20分から約39秒まで短縮した事例も紹介されました。

Splunk Enterprise SecurityへのAgentic SOCの実装

Agentic SOCはSplunk Enterprise Security上で提供され、今後も機能が段階的に拡張されます。

Agentic SOCはSplunk Enterprise Security上で提供され、今後もDetection & Security Engineering、Threat Hunting、Investigation & Response、Governance & Policyの各領域で機能が段階的に拡張されます。

また、EssentialsにもAgentic SOCの機能が拡張され、Premierではより大規模かつ自律性の高い運用を想定した機能が提供される方向性が示されました。

Agentic SOCライブデモ

続いて、Nicholas Astor氏によるAgentic SOCのライブデモが行われました。

デモでは、AI Agentが複数のアラートを分析し、False Positive（誤検知）の判定やインシデントの調査、対応策の提案までを自動的に進める様子が紹介されました。

リスクが低いインシデントについては自動的に封じ込めを行う一方、より複雑でリスクの高いインシデントでは、調査結果と推奨する対応をSOC Analystに提示します。

また、Agentがどのような判断やツールの実行を行ったのかはAudit Logから確認でき、人間がAgentの行動を確認できる仕組みも紹介されました。

AI AgentによってSOC業務を高速化しながらも、その行動を人間が確認できる「Trusted Agentic SOC」の考え方を具体化したデモとなっていました。

Exposure Analytics

Agentic SOCによるインシデント対応に加えて、攻撃を受ける前にリスクを把握・軽減する「Exposure Analytics」についても紹介されました。

Exposure Analyticsでは、企業環境のAssetやIdentity、それらに関連する脆弱性やリスクを継続的に把握し、優先的に対応すべきセキュリティリスクを特定します。

デモでは、脆弱性の影響を受けるネットワーク機器を特定し、Cisco Live Protectによる防御策を確認し、さらに防御策が適用されるまでの時間に攻撃を受けていなかったかをThreat Huntingするところまで紹介されました。

Exposure Analyticsに関しては、機能拡張が10月にGA予定のアナウンスがありました。

まとめ

今回紹介した2つのテーマを通して印象的だったのは、AI Agentによる自動化を大きく推進しながらも、Human in the Loopを繰り返し強調していた点です。

重要な判断や最終的な責任には人間を残す考え方が一貫して示されていました。

Splunk/Ciscoが目指しているのは、

「人間かAIか」

という二者択一ではなく、「AI Agentにどこまで任せ、どこでHuman Controlを入れるのか」
をObservabilityによって判断できる環境なのだと感じました。

次回は3つ目のテーマの「Turn machine data into agentic action」をテーマに紹介したいと思います。