ITおよびエンジニアリングの専門家の62%が、システム障害の原因究明にAIエージェントを頻繁に利用していることが分かりました。ところが、半数以上はエージェントの判断が正しいかどうかを測定する手段を持っていません。Splunkは、10カ国の専門家2,050人を対象にこの調査を実施しました。
出典：Splunk
診断はエージェント、コードを本番に出すのは人間
各チームは、エージェントに任せる業務を慎重に選んでいます。根本原因の特定、アラートの調整、ランブック（インシデント対応時にエンジニアが従う手順書）の下書き作成は、今やエージェントの一般的な仕事です。一方、新規コードの作成は最下位で、回答者の約4分の1はエージェントに一切任せていません。
理由は明快です。不適切なアラートのしきい値であれば、1分で元に戻せます。しかし、本番環境に不具合のあるコードが入り込めば、はるかに大きな問題になります。
多くのチームでは、エージェントの導入で作業が速くなりました。大多数が「問題をより早く発見できるようになった」と答え、復旧も早まったという回答が多数を占めています。ただし、14%は「エージェントの導入後に復旧が遅くなった」としています。
Splunkのオブザーバビリティ事業でAIを統括するSahinaz Safari氏は、これを新人の受け入れになぞらえます。「新入社員と同じで、エージェントにも大きな可能性があります。ただ、自社の環境になじませるまでの間は、より手厚い監督が必要です」と話します。
この監督には「検証税（verification tax）」という呼び名が付いています。エンジニアがエージェントの回答を信頼する前に、その推論を再確認するために費やす時間のことです。
監視したい声は多いが、実際に監視できる組織は少数
回答者の大半は、AIの監視を優先事項と位置づけています。しかしハルシネーションへの対応を見ると、実践が意図にほど遠いことが分かります。85%が「モデルが誤った回答をでっち上げた場面を把握することは重要」と答えた一方、確実に検知できると答えたのは58%にとどまりました。
原因の一つはツールです。約半数が、自社のオブザーバビリティツールはAIの監視を想定して作られていないと回答しています。もう一つは責任の所在です。問題を起こしたエージェントの担当は、モデルを構築したデータサイエンスチームなのか、インフラを運用するSREチームなのか、それともセキュリティチームなのでしょうか。38%は、組織としてまだ決めていないと答えました。
「エージェントのオブザーバビリティが全員の仕事になると、結局は誰の仕事でもなくなってしまいます」と語るのは、SplunkのEMEA担当フィールドCTO兼チーフテクニカルアドバイザーのMark Woods氏です。
たとえば、エージェントがループに陥り、社内APIに毎分数千回ものリクエストを送りつける場面を考えてみましょう。エンジニアリング部門から見れば性能障害ですが、セキュリティ部門にはサービス拒否（DoS）攻撃のように映ります。同じインシデントでも見え方が異なります。回答者の81%は、AIの監視をきっかけにセキュリティ部門との連携が密になったと答えています。
請求書は遅れて届く
コストの面では、さらに状況が不安定です。57%の組織では、オブザーバビリティの費用が、監視対象のインフラそのものの費用を上回っています。今年、予想外のテレメトリ請求を受けた組織も半数に上ります。
Splunkのデベロッパーエバンジェリズム担当ディレクター、Greg Leffler氏は、その感覚をこう説明します。「食料品の買い物にたとえると、トマト1個の値段が一夜で2ドルから90ドルに跳ね上がるかもしれないのに、請求書が届くのは月末、というようなものです」
翻訳元: https://www.helpnetsecurity.com/2026/10/22/ai-agent-observability-report/
