Microsoftのエージェント型セキュリティ運用、SOCを委任されたアクションへと移行

Microsoftは2026年9月23日、Microsoft Defender内のAIエージェントを中心とする新たなセキュリティ運用アプローチを発表した。Microsoftのエージェント型セキュリティ運用戦略は、大きな転換を示している。ソフトウェアはもはや、アナリスト向けにアラートを要約するだけではない。インシデントを調査し、証拠を収集し、対応を推奨し、セキュリティツール間の作業を調整する役割を担うようになる。

この違いは重要だ。セキュリティオペレーションセンター（SOC）は、不確実性の下で意思決定を行う。アナリストは、異常なログインが攻撃者によるものなのか、不注意な従業員によるものなのか、あるいは無害な活動なのかを判断しなければならない。AIエージェントはその作業を加速できるが、速度が重大なアクションを誰が承認すべきかという問題を解決するわけではない。

Microsoftは、2025年にタスク特化型のSecurity Copilotエージェントを導入して以降、このモデルへと歩みを進めてきた。競合各社も、エージェント型調査、自動トリアージ、AI支援型対応製品を通じて類似の道筋をたどっている。Microsoftの最新の位置付けは、エージェントを単なる別のアシスタントインターフェースではなく、運用構造の一部として扱うことで、競争の重要性を高めている。

したがって、中心となる競争はMicrosoftと特定のベンダーの対決ではない。委任された機械のアクションと、アナリストが制御する自動化との対立だ。前者のモデルは規模と持続性を約束する。後者はより明確な人間の権限を維持する一方、チームは増え続けるアラート量と調査の遅延にさらされる。

Microsoftのエージェント型セキュリティ運用は作業単位を変える

Microsoftは、アナリストが個別に送信するプロンプトではなく、エージェントに割り当てられた目標を中心にセキュリティワークフローを再構築している。

Microsoftの9月のセキュリティ投稿は、このアプローチをエージェント時代に向けたSOCの再構想として提示している。公開された見出しでは、Microsoft Defenderが運用環境として位置付けられている。また、この設計がAIエージェントのために構築されたものだとも説明している。

この表現が示すのは、単なる対話型インターフェース以上のものだ。従来のコパイロットは、人が質問するのを待つ。エージェントは目標を受け取り、中間ステップを選択し、承認済みツールを使用し、その結果得られた情報を評価する。

SOCにおいて、目標には疑わしいID侵害の調査が含まれる可能性がある。エージェントはサインイン記録を収集し、デバイス履歴を比較し、最近の権限変更を調べ、関連するアラートを結び付けることができる。その後、証拠に裏付けられた結論をアナリストに提示できる。

この転換は、セキュリティ業務の単位を変える。アナリストは従来、アラート、ダッシュボード、クエリシステム、チケットキュー、対応ツールの間を行き来してきた。Microsoft Defender AIエージェントは、これらの分断された活動を調査の成果を中心に整理することを約束している。

Microsoftは2025年3月までに、この方向性の一部をすでに示していた。同社が最初に発表したSecurity Copilotエージェントには、専門的なセキュリティタスク向けにMicrosoftおよびパートナーが開発したエージェントが含まれていた。

これら初期のエージェントは、フィッシングのトリアージ、アラート調査、脆弱性の修復、ID関連リスクなど、範囲が限定されたワークロードを対象としていた。限定されたタスクは、入力、出力、権限、エスカレーション条件をチームが定義できるため、統制しやすい。

2026年の位置付けは、これらの機能をより広い運用モデルの中に置くものだ。Microsoftは、調査の一つのステップに知能を加えるのではなく、エージェント指向のSOCが最初から最後までどのように作業を配分すべきかを問うているように見える。

ただし、この発表の見出しとURLだけでは、すべての実装詳細は明らかにならない。可用性、対応ワークロード、自律性、顧客成果に関するMicrosoftの具体的な主張は、完全な製品ドキュメントで確認する必要がある。

この検証上の隔たりは重要である。「エージェント向けに構築」という表現は、複数の異なるアーキテクチャを指し得る。あるモデルでは、エージェントは情報を収集できても変更は禁じられる。別のモデルでは、アナリストが提案された計画を承認した後に封じ込めを許可する場合がある。

より自律的な実装では、あらかじめ定義された条件下で、エージェントがアカウントを無効化したりデバイスを隔離したりできる可能性がある。ベンダーがいずれもエージェント型セキュリティとして売り出していても、これらのモデルには異なる運用上・法的な帰結が伴う。

購入者にとって、当面の変化は概念的なものだが、重大な意味を持つ。セキュリティプラットフォームは、作業をどのように割り当て、監督し、記録するかを巡って競争を始めている。検知品質は依然として不可欠だが、ワークフロー上の権限が独立した製品上の次元になりつつある。

アラート量の増加がSOCにより多くの作業委任を迫る

この圧力は、アナリストの横に別のチャットウィンドウを置くだけでは解決できない、拡大する調査ワークロードから生じている。

現代のセキュリティチームに不足しているのは、アラートであることはめったにない。より困難な課題は、攻撃者が進展する前に、散在するシグナルを根拠のある意思決定へと変換することだ。各調査では、エンドポイントイベント、ID、クラウドリソース、メッセージ、脅威インテリジェンス、アプリケーション記録が必要になる場合がある。

このプロセスは、アナリストの注意力を大きく消費する。誰かがアラートを調べ、関連活動を検索し、判断の根拠を文書化し、ケースをクローズしなければならない場合、誤検知であっても時間を奪う。

従来の自動化は、ルールとプレイブックを通じて予測可能なステップを処理する。たとえば、リスクスコアが閾値を超えた際にチケットを作成するルールがある。プレイブックはIPアドレスを補強し、既知のインジケーターをブロックし、管理者へ通知する場合がある。

設計者が条件を予測できる場合、こうしたシステムはうまく機能する。曖昧な証拠に応じて調査が分岐する場合には苦戦する。固定的なプレイブックでは、複数のもっともらしい説明のうち、どれが追加のクエリに値するかを容易には判断できない。

大規模言語モデルは異なる選択肢をもたらす。自然言語の文脈を解釈し、利用可能なアクションから選択し、調査計画を修正できる。この柔軟性が、エージェント型SOCセキュリティの基盤となる。

柔軟性は不確実性も生む。定義された条件下で常に同じ結果を生み出す決定論的なルールは、比較的テストしやすい。AIエージェントは、文脈がわずかに変化しただけで異なる経路を選択する可能性がある。

Microsoftの戦略的な答えは、すでにセキュリティテレメトリーと対応制御を保持するプラットフォーム内に、タスクに焦点を当てたエージェントを配置することだ。統合により、システム間でデータを移動する際に失われる時間を減らせる。また、プラットフォームベンダーに各インシデントをより広く見渡す視点を与えることもできる。

商業的な圧力はまず、調査の一段階しか担わないスタンドアロンツールにかかる。Defenderが検知、証拠収集、ケース管理、対応を調整できれば、購入者は追加のワークフロー製品の必要性を問い直すかもしれない。

マネージドセキュリティプロバイダーも圧力に直面する。その価値には、多くの場合、継続的な監視と反復的なトリアージが含まれる。エージェントはこれらのサービスに必要な労働を削減できる一方、対応速度に対する顧客の期待を高める。

人間のアナリストは別の課題に直面する。難しいインシデントには、ビジネス文脈、不完全な証拠、説明責任が関わるため、この役割が単純に消滅することはない。しかし、アナリストは事実を集める時間を減らし、機械が生成した結論をレビューする時間を増やす可能性がある。

この移行は、SOCが重視するスキルを変える。クエリの専門知識は引き続き有用だが、アナリストはエージェントの振る舞いも評価する必要がある。欠落した証拠、循環論法、過度の確信、安全でないアクション計画を見抜かなければならない。

マネージャーには、新たなパフォーマンス指標も必要になる。より多くのアラートをクローズしても、セキュリティの向上を証明するわけではない。エージェントは、同じ種類の攻撃を繰り返し見落としながらスループットを高める可能性がある。

有用な指標には、調査の正確性、有効な封じ込めまでの時間、エスカレーションの品質、アナリストによる修正、誤ったアクションによる損害を含めるべきだ。チームは、人間が覆したエージェントの判断も追跡する必要がある。

この圧力こそ、Microsoftが今このモデルを推進している理由を説明する。攻撃者はすでに、偵察、コンテンツ生成、認証情報テスト、悪用の一部を自動化できる。防御側は、完全に手作業によるケース組み立てで、機械の速度で行われる活動に対抗することはできない。

しかし、その対応が無制限の自律性であってはならない。セキュリティツールは、本番システム、従業員のアクセス、顧客サービスを中断させる可能性がある。業界には、確率的な推論をレビューされない権限に変えることなく、より迅速な意思決定が必要だ。

委任されたアクションこそが真の競争上の分岐点

重要な分岐は、ベンダーがAIを使用するかどうかではなく、そのエージェントにどれだけの運用権限を与えるかにある。

現在、ほぼすべての大手セキュリティプラットフォームが、何らかの生成AI支援を提供している。要約、クエリ生成、自然言語検索、推奨アクションは、期待される機能になりつつある。

これらの機能は、アナリストのインターフェースを改善するが、統制を根本的に変えるものではない。依然として人間が、何を尋ねるか、どの結果を信頼するか、行動するかどうかを決める。

エージェント型システムは、この意思決定プロセスの一部をソフトウェアへ移す。次にどの証拠を取得するかを決める。また、ケースがエスカレーション、クローズ、封じ込めの条件を満たしていると判断する場合もある。

ここでMicrosoftのプラットフォーム上の立場が重要になる。Microsoft Defenderは、エンドポイント、ID、メール、アプリケーション、クラウドセキュリティの証拠を単一ベンダーの環境内で結び付けることができる。この広がりにより、Microsoft Defender AIエージェントは、孤立したアシスタントが受け取るよりも多くの文脈を得られる。

同時に、それは権限を集中させる。広範な可視性と対応制御を備えたプラットフォームは、より効果的に調査できる。同じプラットフォームは、エージェントが状況を誤解した場合に、より広い影響を及ぼす可能性もある。

機密性の高いエンジニアリングファイルにアクセスする、疑わしいアカウントを考えてみよう。エージェントは、見慣れないデバイス、通常とは異なる場所、最近の権限変更を相関させる可能性がある。この証拠は、即時の封じ込めを正当化し得る。

しかし、その従業員は承認済みの昇進を受けた後に出張しているだけかもしれない。最新の組織的文脈を持たないシステムは、正当な変更を複数、侵害の証拠として扱う可能性がある。

この例は、テレメトリーが増えても自動的に完全な理解が生まれるわけではないことを示している。セキュリティデータは技術的な活動を記述する。ビジネス上の例外、従業員の責務、運用上の緊急性を常に捉えるとは限らない。

したがって、委任アクションのモデルには明確な境界が必要だ。低リスクのアクションには、より広範な自動化を適用できる。証拠収集、補強、重複除去、タイムライン構築は、通常このカテゴリーに当てはまる。

影響の大きいアクションには、より強力な制御が必要だ。役員アカウントの無効化、本番サーバーの隔離、メッセージの削除、アプリケーションアクセスの取り消しは、重要な業務を中断させる可能性がある。

リスクベースの自律性は、実用的な中間的アプローチを提供する。組織は、限定的な条件下で、エージェントが可逆的なアクションを実行することを許可できる。不確実性または潜在的な影響が高まる場合には、人間の承認を求めることができる。

これは、確立されたゼロトラストの考え方に似ている。アクセスは、明示的なポリシー、検証済みの文脈、限定的な権限に依存すべきだ。AIエージェントは、信頼されたセキュリティ製品内で動作するというだけで、広範な権限を与えられるべきではない。

エージェントのIDも重要である。すべてのエージェントには、定義されたサービスID、許可されたツール、データ境界、アクション履歴が必要だ。共有認証情報では、責任の所在を再構築することが困難になる。

競合プラットフォームは、自社の管理機能を異なる形で説明する可能性が高い。エンドツーエンドの自律性を強調する企業もあれば、監督下のエージェント、特化型ワークフロー、複数ベンダーにまたがるオープンな統合を訴求する企業もあるだろう。

Microsoftの優位性は、導入済みのプラットフォーム基盤と企業内シグナルへのアクセスにある。弱点は、単一ベンダーが検知、調査、意思決定エンジン、対応メカニズムを兼ねることになりかねないという懸念だ。

この懸念によってモデル自体が無効になるわけではない。むしろ、監査可能性が競争力のある機能となる。顧客は、エージェントがなぜその結論に至ったのか、どの記録が判断に影響したのか、どの代替案を退けたのかを確認できる必要がある。

エージェント型SOCセキュリティは、この証拠の追跡可能性によって評価される。再現可能な推論を伴わない迅速な回答は、調査時間を短縮する一方で、組織的なリスクを高める可能性がある。

AIエージェントが新たなセキュリティ境界を生む

脅威を調査できるエージェントは、それ自体を限定的な信頼しか置けない、セキュリティ上重要なシステムとして扱わなければならない。

セキュリティエージェントは、攻撃者が意図的にデータを操作する環境から情報を取り込む。メールメッセージ、文書、Webページ、チケット、コードリポジトリ、ログフィールドには、いずれも悪意のあるコンテンツが含まれうる。

これにより、信頼できないコンテンツがAIシステムの指示を変更しようとするプロンプトインジェクションへの露出が生じる。攻撃者は、警告を無視したり、制限された情報を開示したりするようエージェントに指示するテキストを文書内に仕込む可能性がある。

エージェントがその指示に従うとは限らない。それでも、その可能性は脅威モデルを変える。かつては証拠としてのみ機能していたコンテンツが、今ではその証拠を解釈するシステムに影響を及ぼしうる。

したがってMicrosoftとその顧客には、信頼できないデータと特権的な指示の隔離が必要になる。エージェントは、どのコンテンツが証拠であるか、どのポリシーに権威があるか、どの要求された操作に承認が必要かを認識すべきだ。

ツール権限も別のリスクをもたらす。読み取り専用アクセスを持つモデルは、誤った結論を導く可能性がある。封じ込め権限を持つモデルは、その誤りを障害へと発展させかねない。

最小権限の原則は、個々のツールレベルで適用すべきである。メールトリアージエージェントに、エンドポイントを隔離する権限が自動的に必要になるわけではない。エンドポイント調査担当に、すべての従業員メールボックスへの無制限アクセスは必要ない。

組織は計画と実行も分離すべきである。あるコンポーネントが調査または対応計画を提案し、実際の操作が行われる前にポリシーレイヤーがその計画を決定論的なルールと照合できる。

そのポリシーレイヤーを、別の言語モデルに全面的に依存させるべきではない。たとえば、エージェントが指定された緊急用アカウントを無効化することを防ぐなど、一部の判断には固定的な制御が必要だ。

米国国立標準技術研究所によるAIリスクフレームワークは、有用なガバナンスの参照点となる。AIリスクへの取り組みを、統治、マッピング、測定、管理という枠組みで整理している。

セキュリティエージェントに適用すると、統治は責任の所在と許容される利用を定める。マッピングは影響を受けるシステムと起こりうる被害を特定する。測定は通常時および敵対的な条件下での挙動を検証する。

そのうえで管理は、これらの知見を権限、監視、承認経路、インシデント対応手順へと落とし込む。モデル、ツール、組織データは変化するため、このサイクルは導入後も継続しなければならない。

MITREが管理するATLAS脅威ナレッジも、関連する別の参照点を提供する。機械学習システムに関わる敵対的手法を記録しており、構造化されたテストを支援できる。

いずれのフレームワークも、特定のエージェントが安全であることを認定するものではない。より良い問いを立て、証拠を整理する方法を提供する。顧客には依然として、自らの環境で製品固有のテストが必要だ。

ログは最終回答を超えて取得されなければならない。有用な記録には、割り当てられた目的、選択されたツール、取得した証拠、中間判断、ポリシーチェック、承認、結果として実行された操作を示す必要がある。

機微な推論データにも保護が必要だ。調査の痕跡には、従業員情報、インシデントの詳細、認証情報、防御上の欠陥に関する記述が含まれうる。あらゆる痕跡を広範に保持すれば、別の価値ある標的を生み出しかねない。

組織は、何をどの期間保存し、誰が閲覧できるかを決めなければならない。また、社内調査や訴訟ホールドの際に証拠を保全するプロセスも必要となる。

モデル更新は別の複雑さを加える。基盤モデル、プロンプト、コネクター、検索システムが変わると、エージェントの挙動も変化しうる。先月テストしたワークフローが、更新後にまったく同じように振る舞うとは限らない。

したがってチームは、エージェント構成をバージョン管理し、重要な評価を繰り返すべきだ。代表的なケース、敵対的な入力、危険なツール使用に関するテストが必要になる。

Microsoftの主張は、インターフェースの流暢さではなく、こうした運用上の制御に照らして評価すべきである。洗練されたインシデント要約は、弱い証拠や不完全な調査経路を隠しかねない。

最も難しい問いは、デモ中にエージェントが正解へ到達するかどうかではない。エージェントが誤った場合に、周辺システムが被害を抑えられるかどうかである。

自律性の向上に伴い、証拠の基準も引き上げなければならない

自律性が高まるほど意思決定の質を示す強力な証拠が求められるため、Microsoftはケース解決の高速化だけで信頼を確立することはできない。

セキュリティ自動化は、しばしば節約された時間で測定される。ベンダーは、手作業の削減、迅速なトリアージ、対応サイクルの短縮を強調するかもしれない。こうした指標は有用だが、不十分でもある。

エージェントがケースを迅速にクローズできるのは、無害なパターンを認識したためかもしれない。一方で、矛盾する証拠を収集できなかったために迅速にクローズすることもある。運用指標は似通って見える一方で、セキュリティ上の結果は異なる。

顧客は、既知のインシデントに対する評価を求めるべきである。テストセットには、確認済みの攻撃、無害な異常、内部リスクのシナリオ、侵害されたアカウント、不完全なテレメトリーを含められる。

ケースには難しいネガティブ事例も含めるべきだ。これは悪意ある行動に似て見える正当な活動を指す。エージェントが相関を証明として扱っていないかを明らかにする。

評価では、証拠の完全性も測定すべきである。エージェントは必要なすべてのデータソースを参照したか。欠落したテレメトリーを特定したか。操作を推奨する前に不確実性を伝えたか。

アナリスト間の一致も別のシグナルとなるが、唯一の基準にすべきではない。特に機械生成の説明が自信に満ち、よく整理されているように見える場合、人間は同じ前提を共有する可能性がある。

ブラインドレビューは、この影響を軽減できる。アナリストは、その結論が人間によるものかエージェントによるものかを見ずに、ケースの証拠を評価できる。その後、差異を体系的に検討できる。

組織には縦断的な証拠も必要だ。統合が変化し、データ品質が低下し、攻撃者が適応した後にエージェントがどのように機能するかは、1回の成功したパイロットでは示せない。

エラーの分類は顧客に見えるようにすべきである。見落とされた関係性は、誤ったID照合とは異なる。根拠のない確信は、危険なツール選択とは異なる。問題ごとに異なる対処法が必要だ。

Microsoftは、評価方法、権限モデル、監査構造を公開することで、自社の主張を強化できる。集計された速度の主張だけでは、中心的なガバナンス上の疑問に答えられないままとなる。

独立したテストは特に重要になる。Microsoftは、この設計におけるプラットフォーム、モデル、多くのデータコネクターを所有している。第三者評価は、社内テストが見落とす前提に疑問を投げかけられる。

同じ精査は競合システムにも適用すべきである。セキュリティベンダーには、アシスタントをエージェントとして、エージェントを自律的なものとして説明する強い動機がある。購入者には、各能力について具体的な定義が必要だ。

国際的なサイバーセキュリティ機関が支持するセキュアAIガイドラインは、安全な設計、開発、展開、運用を重視している。このライフサイクルの視点は、エージェント型セキュリティツールに適している。

責任ある導入は、限定的なスコープから始まる。チームは、人間の承認権限を維持しながら、エージェントに証拠の要約と次の手順の提案を任せられる。

エラーと運用への影響を測定した後に、自律性を拡大できる。破壊的な変更や復旧が難しい変更より先に、可逆的な操作を行うべきだ。

ロールバックのプロセスは依然として不可欠である。エージェントが封じ込め操作を誤って適用した場合、対応担当者にはアクセスを復元し、修正を記録する明確な方法が必要となる。

Microsoftのエージェント型セキュリティ運用は、調達上の疑問も提起する。購入者は、プロンプトと調査データがどこで処理されるのかを知るべきだ。保持、地域的な境界、モデルのトレーニング方針、管理者アクセスを理解する必要がある。

統合の深さにも同様の注意が必要だ。システムはMicrosoftのテレメトリー内では良好に機能しても、第三者のネットワーク、アプリケーション、クラウドサービスにまたがると文脈を失う可能性がある。

この制約は、混在環境を持つ組織にとって重要となる。一貫したインシデントは、複数ベンダーが所有するシステムにまたがることが多い。エージェントはそれらのシステムに到達するか、自身の死角を特定しなければならない。

エージェントがSOCを変革できるという主張は、ワークフローレベルでは信頼に足る。安全にそれを実現できるという主張は、導入ごとに実証的に検証すべき問題である。

エージェント型SOCが機能するかを示す3つのシグナル

次の段階は、顧客による制御、測定可能な調査品質、そしてエージェントが混在環境で運用できることを示す証拠によって決まる。

第1のシグナルは、Microsoftの詳細な権限・承認モデルである。購入者は、管理者が各エージェントのデータアクセス、ツール、対応権限をどのように制限するのかを確認する必要がある。

強力な制御は、委任アクションモデルを支える。すべてのワークフローを同一に扱うことなく、組織が自律性をリスクに見合う形で調整できるようになる。

弱い、または不明確な制御は、Microsoftの主張を損なう。顧客は証拠を集めるエージェントを受け入れるかもしれないが、意味のある対応権限を与えることにはためらうだろう。

文書では、緊急時のオーバーライドがどのように機能するかも説明すべきである。セキュリティチームは、エージェントを停止し、ツールを取り消し、定められた期間に実行したすべての操作を特定できる必要がある。

第2のシグナルは、測定された調査品質である。Microsoftと初期顧客は、時間短縮以上のものを報告すべきだ。誤ったクローズ、見落とされた証拠、不必要なエスカレーション、アナリストによる判断の覆しを検討する必要がある。

最も有用な結果は、テスト対象と運用条件を説明するものだ。選別されたデモでの性能は、ノイズの多いエンタープライズ環境について購入者にほとんど示さない。

繰り返される本番利用からの証拠は、このストーリーを強化する。検知品質が維持または改善される場合、調査時間の短縮には意味がある。

同等の精度を示す証拠なしに迅速なクローズが増えれば、その主張は弱まる。より速い処理は魅力的なダッシュボードを生み出す一方で、重要なミスを集計値の中に埋もれさせかねない。

第3のシグナルはクロスプラットフォームの性能である。大半の大規模組織は、複数のセキュリティ、アイデンティティ、ネットワーキング、クラウドベンダーの製品を利用している。

Microsoft Defender AIエージェントは、こうした環境を一貫して調査するために、十分な第三者コンテキストへアクセスする必要がある。そうでなければ、このモデルは主としてエージェント性能のために顧客の統合を促すことになるかもしれない。

その結果は、商業面ではなおMicrosoftに利益をもたらすだろう。しかし、エージェント指向のSOCがより広いエンタープライズ市場全体で効果的に運用できることの証明にはならない。

オープンなコネクター、標準化されたツールインターフェース、明示的な死角の報告は、Microsoftのアプローチを強化する。エージェントが関連する証拠にアクセスできなかった場合、顧客が調査は完了していたと想定する必要があってはならない。

競合他社の反応も補足的な文脈を提供する。対抗ベンダーは、自社のテレメトリー、特化型モデル、オーケストレーションシステム、ガバナンス制御を強調する可能性が高い。

これらの発表は、本番環境での権限に比べれば重要度は低い。重要なのは、顧客が魅力的な要約を生成するだけでなく、実際の調査と対応を実行することをどのシステムに許可するかだ。

セキュリティ責任者は、その権限を与える前に準備を整えるべきである。まず、可逆性、事業への影響、必要な承認に基づいてアクションを分類できる。

一般的な意思決定に必要な証拠も定義すべきだ。侵害されたアカウントへの対応フローでは、IDリスク、デバイスの状態、セッション履歴、直近のアクセス変更が求められる場合がある。

次に、エージェントがその証拠を一貫して収集できるかを検証する必要がある。情報が欠けている場合は、もっともらしい結論を捏造するのではなく、エスカレーションを促すべきだ。

チームは、アーキテクチャ上の意思決定、調査基準、承認済み例外について、検索可能な記録を維持することもできる。統制されたエンジニアリングナレッジベースは、レビュー時にアナリストがこうした文脈を取得する助けとなる。

目標は、すべての手作業を残すことではない。説明責任まで委譲することなく、業務を委任することだ。

Microsoftのエージェント型セキュリティ運用は、負荷が過大なセキュリティチームに対する有力な答えとなり得る。エージェントは継続的に証拠を収集し、複雑な手掛かりを追跡し、反復的な調査作業を減らせる。

その成功は、証拠が矛盾したとき、ツールが失敗したとき、あるいはモデルが誤った結論に至ったときに何が起こるかに左右される。こうした場面こそ、成功したデモンストレーションよりも、運用上の信頼を明確に示す。

セキュリティチームは、エージェントの権限を拡大する前に、実務的な問いを一つ投げかけるべきだ。重大な影響を及ぼすすべての判断を再構築し、検証し、取り消すことができるか。答えが「はい」なら、エージェントは有用なSOC参加者になり得る。答えが「いいえ」なら、監督下の調査担当者にとどめるべきである。