SecurityHQのAIエージェント調査、ポリシーがインシデントの説明責任を先行していることを示す
SecurityHQは、調査対象となったサイバーセキュリティ責任者の76%が正式なAI説明責任ポリシーを持つ一方、エージェントの活動を数分以内に再現できると答えたのは17%にとどまったとする調査を発表した。Datadogと共同で実施されたSecurityHQのAIエージェント調査は、実務上の緊張関係を浮き彫りにする。責任を割り当てても、自動化された判断を必ずしも説明可能にできるとは限らない。
2026年10月15日に公表されたこの結果は、エンタープライズ向けエージェントが業務システム全体で作業を実行する権限を得つつある時期に出てきた。AIエージェントは、モデルと接続済みツールを用いてタスクを遂行するソフトウェアシステムである。その権限は、文書化されたポリシーだけでは答えられない問題を生む。
MicrosoftによるSecurity Copilotの拡張は、委任されたセキュリティ業務へのこの移行を示す具体的な事例だ。現在、セキュリティ責任者、アプリケーションの所有者、ベンダーには、自動化された行動を証拠および説明責任を負う人間の権限と結び付けることが求められている。
SecurityHQのAIエージェント調査、ポリシーと対応準備を分けて検証
この調査は、中規模および大規模組織のサイバーセキュリティ責任者204人を対象に行われた。調査発表によると、45%が、責任の所在が不明確なAIエージェントまたは自動化に関わるインシデントを経験したと回答した。
この表現には注意が必要だ。インシデントの分類には自動化も含まれるため、この結果は45%が自律型AIエージェントによる侵害を経験したことを示すものではない。また、責任の所在が不明確であることは、特定の技術的障害や被害規模ではなく、組織上の問題を表している。
この調査結果が問うのは、責任が争点となったときに、組織が委任された行動を説明できるかどうかである。 ポリシーは担当者を特定できても、どの指示、権限、システム間のやり取りが結果を生んだかまでは示せない。
SecurityHQの公開された説明責任に関する調査結果も、過去の可視性と即時の調査対応力を区別している。過去30日間におけるエージェントの行動を完全に再現できると答えたのは49%にすぎなかった。
この区別は、購入者が結果をどう読むべきかを変える。記録を保持する能力と緊急の問いに答える能力は関連しているが、異なる運用上のニーズに対応するものだ。組織は関連証拠を保持していても、それらを結び付けるには相当な手作業を要する場合がある。
逆に、ダッシュボードは最近の活動を要約できても、後日の調査に十分な詳細を保持していない可能性がある。どちらの可能性も、調査対象の組織で何が起きたかを立証するものではない。いずれも、可視性に関する単一の主張をより慎重に検証すべき理由を示している。
重要なのは、調査の枠組みの変化だ。SecurityHQはポリシー上の所有者と行動の一連の流れを確立する能力を並べることで、両者の隔たりを可視化している。
エンタープライズの購入者にとって、これはより厳しい調達上の問いを生む。ベンダーによるガバナンスの説明は、エージェントが行動した後に顧客が受け取る証拠と結び付いていなければならない。
社内のセキュリティチームにとっても、同じ区別が報告に影響する。承認プロセスが存在するだけでは、調査担当者が、争いのある行動に関連する承認を復元できるとは限らない。
説明責任ポリシーは期待事項を定義するため、依然として有用である。その運用上の価値は、人々がその期待事項を特定の事象に適用できるかにかかっている。
この調査は、ポリシーを持つ組織でインシデントが少なかったことを示してはいない。また、追加の監視を購入すれば責任に関する不確実性が解消されることも示していない。
それでも、そのより限定的な貢献は重要だ。エンタープライズは責任を正式に割り当てながら、プレッシャー下でその責任を果たすために必要な証拠を欠いている可能性がある。
だからこそ、この話題はAIリスクに関する別の調査という枠を超えて重要になる。この調査は、ソフトウェアが委任された権限を受け取った後も、従来のガバナンス指標が実際の対応準備を表しているのかを問いかけている。
委任されたセキュリティ業務が購入者と運用担当者に圧力をかける
セキュリティ責任者がプレッシャーに直面するのは、エージェントがすでに異なるチーム間で責任が分かれているシステム内で動作するためだ。アプリケーションの所有者がワークフローを承認する一方、別のチームが認証情報を管理し、さらに別のチームがインシデント対応を担うことがある。
認証情報とは、アクセスを要求する際にソフトウェアが提示するデジタル上の証明である。複数のワークフローが同じ証明を共有している場合、アカウントを特定しても、実際の開始者は不明のままになる可能性がある。
一見すると単純な所有権の問題は、複数の問いへと分かれる。誰がタスクを承認したのか、誰がアクセスを付与したのか、誰が統合を維持したのか、そして誰が実行を停止できたのか。
これらの役割が同じ人物に属する必要はない。組織が調査中にそれらを結び付けられないとき、困難が生じる。
業務を委任することで、権限がどこで始まり、変化し、終わるかを把握する重要性が増す。 ガバナンス文書に名前が記されているだけでは、指名された経営幹部はインシデントを解決できない。
運用上の影響はセキュリティ部門を超える。事業責任者は、エージェントの行動が承認済みの目的に沿っていたかを理解する必要がある。アプリケーションチームには、想定された行動と不正利用を区別するための十分な文脈が必要だ。
法務およびリスクチームは別の懸念に直面する。利用可能な記録が、企業が後から示す説明を裏付けるかどうかだ。根拠となる証拠が断片化したままであれば、自信に満ちた説明の価値は限定的となる。
ベンダーもまた、顧客がその記録の一部を製品設計に依存するため、プレッシャーを受ける。サービスが公開も保持もしない情報を、顧客が独自に復元することはできない。
Microsoftは、これらの問いがなぜ差し迫ったものになったかを示している。同社は2025年3月のセキュリティエージェント発表で、疑わしい欺瞞的メッセージを分類・評価するフィッシングトリアージなどのタスク向けエージェントを発表した。
同社はこれらの機能を、防御担当者の定型業務を減らす手段として提示した。これは具体的な導入文脈を示すものであり、Microsoft製品にSecurityHQが報告したギャップが存在することを立証するものではない。
比較の対象は購入時の提案内容だ。Microsoftはエージェントが担える業務を説明し、SecurityHQは組織がその後に委任された活動を説明できるかを問う。
これらの提案は同じ購買判断の議論に属する。効率性の主張は、購入者が調査に要する労力、介入の選択肢、証拠の可用性も評価できるとき、より有用になる。
脅威の監視と対応を担うセキュリティオペレーションセンターにとって、定型業務の削減は明確な魅力を持つ。しかし、解明されていない行動は別の場所で業務を生む。
エージェントの結論を受け取るアナリストは、状況が変化した際にその根拠を理解する必要がある。元のタスクが完了した後、別の調査担当者がその判断を再検討する必要もあるかもしれない。
したがって、このプレッシャーは導入承認と継続的な運用の双方に及ぶ。購入者には、採用後、とりわけその行動に説明が必要となる場合に、システムがどのように振る舞うかを示す証拠が必要だ。
これは、自律性がセキュリティ業務に本質的に不向きだという意味ではない。委任される権限の範囲こそが、運用上の取引に価値があるかを判断する中心的な要素になるということだ。
有用な自動化にも説明可能な行動履歴が必要
中心にある緊張関係は、通常業務でエージェントが節約する時間と、例外的な結果を説明するために必要となる労力との間にある。組織が正当化できる境界内でのみ、より迅速な実行は価値を生む。
報告されたSecurityHQのインシデントではなく、例示的なワークフローとしてフィッシングトリアージを考えてみよう。エージェントは疑わしいメッセージを確認し、接続された情報を参照し、判断結果を出す。
有用な調査では、メッセージ、参照された情報、エージェントの識別情報、そして最終的な行動を結び付ける必要がある。承認が関与した場合、調査担当者はその承認も行動に結び付ける必要がある。
タスクが完了したと記録するだけでは、より狭い問いに答えるにすぎない。それは終点を確立するが、システムがその結論に至った経緯を必ずしも説明しない。
説明責任を果たす行動履歴には、指示、権限、実行、結果を結び付ける必要がある。 これらのいずれもが、インシデントで争点となり得るため、このつながりは重要だ。
指示は適切でも、権限が過剰だった可能性がある。権限は適切でも、実行中に得た情報がタスクの方向を変えた可能性がある。
あるいは、エージェントは要求されたワークフローに正しく従った一方で、基礎となる業務ルールが誤っていた可能性もある。説明責任には、その可能性も含める必要がある。
モデルだけに焦点を当てた記録では、こうした区別を見落とすおそれがある。モデルは、指示を受け取り、情報を取得し、接続されたツールを呼び出すアプリケーションの一部にすぎない。
アプリケーションプログラミングインターフェース、すなわちAPIは、あるシステムが別のシステムの機能を要求するためのソフトウェアインターフェースである。エージェントの活動は、こうしたインターフェースと、それぞれ別個の記録をまたぐ可能性がある。
各サービスは自らの局所的なやり取りを正確に説明できても、タスク全体の再現は難しいままになる可能性がある。不足しているのは、個別には有効な記録同士の関係性だ。
Salt Securityが10月13日に発表したエージェントセキュリティに関する調査結果は、この問題を別の角度から示している。同社の調査は、380件以上のアンケート回答と本番環境のテレメトリーを組み合わせたものだ。
すべてのエージェントにわたる完全な経路を一貫して追跡できると回答したのは、回答者の12.5%にとどまった。Saltはまた、本番環境で予期せぬ挙動を示すエージェントを自動的に停止できると答えた割合が17.5%だったと報告した。
これらの数値は、SecurityHQの再現に関する問いとは異なる能力を測定している。共通のスコアにまとめたり、同等の推計として扱ったりすべきではない。
その関連性は概念的なものだ。行動を追跡することと、行動を中断することは、制御における別々の要素である。インシデント後の完全な説明は、その影響を元に戻さない。
同様に、ワークフローを停止しても、それが予期せず振る舞った理由までは説明できない。購入者は、片方がもう片方を保証すると考えずに、両方の能力を評価する必要がある。
したがって、商業的な比較は個別ベンダー間の競争より広範だ。SecurityHQは運用上の説明責任を重視し、Microsoftは委任されたセキュリティタスクを説明し、Saltは追跡と封じ込めを強調している。
これらの視点は、共通の顧客課題を軸に交差する。エンタープライズには、責任の確立がより難しくなりがちな製品境界をまたいでも、委任された業務を理解可能な状態に保つ必要がある。
人間の承認だけでは説明責任のすべてを担えない
人間によるレビューは、重要な判断の近くに人を置くため、依然として魅力的な答えである。その有用性は、その人が何を確認し、何を承認できるかに左右される。
曖昧な目的に結び付いた承認では、許可された行動について意見の相違が生じる余地が残る。特定の行動に結び付いた承認は、より明確な境界を確立する。
それでも調査担当者は、実行内容が承認済みの要求と一致していたかを把握する必要がある。承認と実行は異なる時点を示しており、その間に情報やシステム条件が変化している可能性がある。
承認記録が実際に行使された権限と一致しているとき、人による監督は説明責任に寄与する。 人が関与しているだけで、欠けている技術的な履歴が自動的に補われるわけではない。
この区別は、最終レビュー担当者がワークフロー全体の責任を引き受けると期待する経営層にとって重要である。システムが開示しない情報を、レビュー担当者が意味のある形で評価することはできない。
また、承認ステップをどこに置くかを決めるプロダクトチームにとっても重要である。あらゆるアクションを中断すれば摩擦が生じる一方、タスク全体を承認すれば、より広い裁量を委任することになる。
実務上のトレードオフは、どの判断に介入を求め、どの境界をソフトウェアが直接強制できるかに関わる。想定される結果が異なるため、ワークフローごとに妥当な答えも異なる。
応答を推奨するだけのシステムと、アクセス権を変更するシステムでは、権限を巡る問いが異なる。比較すべきなのはAIというラベルの有無ではなく、許可されたアクションである。
エージェントが組織の境界をまたいで行動するほど、アイデンティティの重要性も高まる。認証は誰または何が要求を出しているかを確立し、認可はその要求者が何を行えるかを決定する。
どちらの機能だけでも、要求の背後にある事業上の目的を説明することはできない。技術的なアイデンティティを、タスクおよびそれを委任した人やプロセスと結び付けることは、調査に役立つ。
NISTのエージェント・アイデンティティに関する取り組みは、この課題に対する制度面での参照点を提供している。9月には、最初の実装ユースケースとしてソフトウェア開発を特定した。
この取り組みは、ソフトウェア開発ライフサイクル内でエージェントを識別、認証、認可することに焦点を当てている。これは実装に向けた取り組みであり、企業における説明責任がすでに解決されたことを示すものではない。
この方向性が重要なのは、説明責任が部分的には、権限がソフトウェアを通じてどのように伝達されるかに依存するためである。標準や実証は、こうした関係を一貫して表現しやすくする助けとなり得る。
ただし、技術的なアイデンティティだけでは、争いのある事業上の結果について誰が責任を負うべきかを決められない。組織には、導入、保守、レビュー、緊急介入に関する明確な責任分担が依然として必要である。
明確な記録と明確な役割は、相互に補強し合う。記録は何が起きたかを確立する助けとなり、役割はその証拠を誰が評価し対応しなければならないかを定める。
同じ区別は組織知にも当てはまる。検索可能なチームナレッジベースは、方針や責任へのアクセスを支援できる一方、実行の証拠はシステムが実際に何を行ったかを確立する。
これらの機能を分けておくことは、よくある誤りを避けるのに役立つ。想定されたワークフローを文書化しても、特定の実行がそれに従ったことの証明にはならない。
調査が提起する、調査だけでは決着できない問い
SecurityHQのAIエージェント調査は、回答者が報告した経験と確信に関する証拠を提供している。各組織内のすべてのエージェントの挙動を独自に測定したものではない。
自己申告による準備状況は、実際のインシデント時のパフォーマンスと異なる場合がある。回答者によって、再構成、説明責任、エージェント活動の解釈も異なり得る。
あるリーダーは強力な中央監督を説明する一方で、分散型の導入がその視野の外に残っている可能性がある。別の回答者は、十分な能力を持つチームが不慣れな社内プロセスで運用しているにもかかわらず、準備不足を報告するかもしれない。
こうした可能性が調査結果を無効にするわけではない。ただし、そこから導かれる結論の確実性には限界がある。
この調査は、エージェントの失敗を普遍的に推定するものではなく、企業の準備状況を精査する根拠を提供している。 公開された要約を、個別導入のテストに代えるべきではない。
公開された発表とランディングページには、広範な代表性を確立するのに十分な方法論の詳細がない。読者は、サンプルがあらゆる業界や企業規模を反映していると想定すべきではない。
インシデントに関する設問でAIエージェントと自動化を組み合わせている点も、別の制約を生む。報告された不確実性のどの程度が新しいエージェントに起因し、どの程度が既存の自動化ワークフローに起因するのかは明確ではない。
この区別は、新規性を解釈する際に重要である。組織は長年にわたり、ソフトウェア統合、外部委託サービス、共有された運用プロセスにまたがる責任の割り当てに苦慮してきた。
エージェントの導入は、根本的な弱点のすべてを新たなものにすることなく、その既存の問題を複雑化させ得る。この問題全体をAI特有のものとして扱うと、なじみ深い統制上の失敗が見えにくくなるおそれがある。
方針とインシデントの関係についても、なお解決されていない。集計結果は、特定のインシデント発生時にどの回答者が方針を持っていたかを示していない。
したがって、方針がインシデント防止に失敗したことも、方針のない組織のパフォーマンスがより低かったことも証明できない。いずれの主張にも追加の証拠が必要となる。
SecurityHQのAIエージェント調査は、セキュリティおよび監視に商業的な利害を持つ組織からも発信されている。この背景は、その観察を自動的に退けることなく開示に値する。
適切な懐疑的対応は、定義、方法論、再現可能な証拠を検討することである。商業的なスポンサーシップと有用な知見は両立し得る。
Saltの結果との比較にも、同様の注意が必要である。設問、対象集団、測定方法が異なるため、両調査をまたいで企業の準備状況を明確に順位付けすることはできない。
広範な懸念で一致していることは、測定された有病率での一致を意味しない。両調査は、可視性、権限、介入についてそれぞれ別個の観察を提供している。
また、この調査は、より多くの記録を一元化すれば常にセキュリティが向上することも示していない。記録には機密情報が含まれる可能性があり、調査証拠へのアクセスにはそれ自体の責任が伴う。
分析上の含意はより限定的である。組織には、委任する判断に見合う十分な証拠が必要だ。何が十分と見なされるかは、アクションとその結果に左右される。
説得力のある対応は、特定のワークフローが失敗時にもどのように帰属可能であり続けるかを示すだろう。あるプラットフォームがすべてのエージェントに説明責任を持たせるという広範な主張には、はるかに大きな証拠基盤が必要となる。
インシデントの証拠、プロダクト統制、アイデンティティ実装を注視する
今後数か月で最も有用な進展は、組織が表明した説明責任を実証可能な運用能力へ転換できるかを示すものになる。導入に関する発表だけでは、この問いは未解決のままである。
第一の兆候は、公開されたインシデント再構成と統制演習の質である。有用な説明は、委任されたタスク、関連する権限、アクションの順序、介入を結び付けるだろう。
また、調査担当者が復元できなかった内容も特定すべきである。不完全でも率直な再構成は、チームが統制を維持していたという保証より多くの証拠を提供する。
異なるワークフローで繰り返し実証されれば、説明責任の実務が準備された事例を超えて機能するという確信が強まる。持続的な欠落があれば、SecurityHQが提起した懸念はより強まるだろう。
第二の兆候は、エージェントの実行を調査および封じ込めに結び付けるプロダクト上の証拠である。購入者は、広範なガバナンスの表現に頼るのではなく、ベンダーが顧客に何を開示するかを注視すべきだ。
意味のある実証では、調査担当者が接続されたサービスをまたいでタスクを追跡する方法を示すだろう。また、認可されたオペレーターがワークフローを中断した際に何が起きるかも示すはずである。
中断のタイミングと範囲は重要である。次のアクションを防ぐことと、完了済みの変更を取り消すことは異なり、プロダクトの実証ではその違いを理解できるようにすべきだ。
顧客がその挙動を検証できる場合、より明確な統制はより広範な委任を支えるだろう。ローカル記録間の説明されない隔たりは、より限定的な権限を支持する論拠を強める。
第三の兆候は、エージェントのアイデンティティと認可を巡る実装の進展である。NISTが発表したソフトウェア開発のユースケースは、技術的な成果物を確認する具体的な場を提供する。
実務的な例は、ソフトウェアがサービス間を移動する際に、委任された権限がどのように帰属可能であり続けるかを明らかにし得る。その価値は、組織がこのアプローチを実際のワークフローに適用できるかにかかっている。
進展があれば技術的アイデンティティを巡る曖昧さは減るが、事業上の所有権に関する判断は企業に委ねられたままである。遅延すれば、顧客はプロダクト固有のアプローチにより強く依存することになる。
次に有用なベンチマークは、組織が現実的な条件下で委任された活動を説明し、中断できるかどうかである。 このベンチマークは、調査結果と購入者がすでに直面している判断を結び付ける。
導入を評価する読者にとって、SecurityHQのAIエージェント調査は、既存の保証の裏付けとなる証拠を検討する理由を提供する。まず、すでに責任者がいる重要なワークフローから始める。その責任者に、現在利用できる記録を用いて完了済みの実行を説明してもらう。指示、権限、アクション、結果を追う。そして、それらの要素が一致しなくなったときに誰が介入できるかを特定する。つながりの欠落は、AI安全性への一般的な懸念よりも具体的な問題を明らかにする。また、何を改善すべきかについてベンダーや社内チームとより明確に話し合う土台にもなる。より広範な権限を与える前に、アクション履歴と介入の境界を可視化する実証を求めるべきだ。結果に異議が唱えられたとき、あなたの組織はその説明を守れるだろうか。
