AI SOCエージェントとSOARの違い:実際に何が変わったのか_Masthead

AI SOCエージェントとSOAR:実際に何が変わったのか

AI SOCエージェントとSOAR:実際に何が変わったのか

過去2年間、セキュリティ運用(SecOps)のマーケティングを支配してきた2つの主張は、互いに矛盾している。. 

  • 1つ目:SOARは廃止され、AI SOCエージェントがそれに取って代わる。. 
  • 2つ目は、AI SOCエージェントは、言語モデルを後付けしただけのSOARに過ぎないという点だ。. 

どちらも間違っており、その間のギャップこそが、多くの評価予算が無駄に費やされる原因となっている。. 

ガートナーの2024年ハイプサイクルでは、SOARは「陳腐化する前に飽和状態になる」と位置づけられており、これが最初の主張の根拠となった。しかし、カテゴリの市場構造と顧客ニーズは別物であり、どちらか一方だけが消滅した。このブログの残りの部分では、証拠が裏付ける内容に沿って、SOARが何をしたのか、エージェントがどのように変化したのか、変化しなかったのか、そして本番環境での導入が収束しつつある2層アーキテクチャについて解説する。.

市場がSOARの下落について正しかった点 

SOARは、ある一点において非常に優れた能力を発揮しました。それは、既知の手順を実行可能なワークフローにエンコードすることです。チームが報告されたフィッシングメールをどのように処理するか(解析、添付ファイルの無効化、URLの確認、他の受信者の検索、隔離、通知)を書き出してみてください。SOARは、その手順を機械の速度で、1日に1万回、すべてのステップのログを記録しながら、完全に同じように実行しました。.

その長所は、決定論性、再現性、そして監査可能性であった。同じ入力に対しては常に同じ処理経路が生成された。監査担当者に対して、何が実行され、なぜ実行されたのかを正確に示すことができた。.

その裏側には限界があった。プレイブックは、作成者が想定した状況しか扱えなかった。構築と維持には、多くのチームが見落としていたエンジニアリングの労力と構造化されたデータフローが必要だった。ガートナーの批判は、その維持管理の負担に加え、市場の統合とコストに集中していた。さらに、プレイブックは判断を下すことができなかった。曖昧な状況に直面した場合、事前に誰かが書き込んだ条件に基づいてのみ分岐するのだ。. 

その結果、SOCツールレビューに参加したことのある人なら誰でも認識できるようなワークロードの分割が生じました。チームは、よく理解されていて再現性のあるアラート量を自動化しましたが、曖昧な残りのアラート、つまりアナリストが調べ、考え、判断する必要のあるアラートに埋もれ続けていました。プレイブックがその量を処理しましたが、調査の中間段階は人間が担当していました。.

エージェント 実は 変更しました 

AI SOCエージェントは、SOARとは根本的に異なるアプローチで残りのアラートに対処します。単なる漸進的な変更ではありません。エージェントは事前に作成された手順に従うのではなく、独自の手順を構築します。アラートを読み取り、それを裏付ける、あるいは反証する証拠を判断し、その証拠をシステムに照会し、結果が得られた時点で修正を行い、書面による理由付けとともに判断を下します。. 

プレイブックは手順をコード化する。エージェントは判断を近似的に行う。.

これは単なる名称変更ではなく、真の機能変更です。決定論的な自動化では、これまで新規かつ曖昧なアラートを構造的に調査することはできませんでした。しかし、現在は部分的にそれが可能になっています。「LLMを備えたSOARを使えばよい」という単純な考え方は、実際の運用環境では通用しません。.

変更されなかったエージェントは

判断を下すには代償が伴う。エージェントは確率に基づいて行動する。同じ調査を2回実行しても、異なる経路を辿り、場合によっては異なる結論に至ることもある。彼らは自信を持って間違っている可能性もあるのだ。.

LLM推論ループは、既に決定論的な処理には不適切なツールです。セキュリティ責任者は、封じ込め手順、証拠保全手順、規制当局への通知手順などを即興で実行するモデルを望んでいません。それらは、毎回正確に、かつ証明付きで実行される必要があります。.

これが、代替案が失敗する理由です。決定論的な実行、強制的なプロセス、統合のための基盤、そして監査は、不要になったわけではありません。むしろ、確率的なシステムがループの中に組み込まれ、まさにこれらの特性を周囲に取り込む必要が生じたため、より一層重要になったのです。.

要するに: AI SOCエージェントは、複雑な脅威を調査するために柔軟で確率的な判断を導入するが、信頼性が高く監査可能な実行を保証するためには、決定論的でルールに基づいたプロセスが必要となる。.

SOARとAI SOCの導入が融合する場所 

実際の運用においては、これら2つの機能はレイヤー状に組み合わされる。.

  • レイヤー1、エージェントの推論: トリアージ、調査、判決、勧告。曖昧な中間段階。.
  • レイヤー2、決定論的実行: どの自律性レベルでどの操作が許可されるか、人間の承認が必要な操作は何か、封じ込めはどのように実行されるか、何がログに記録されるか、エージェントの信頼度が低下した場合どうなるか。ガートナーの2026年評価ガイダンスも同様の方向性を示しており、影響の大きい操作には厳格なガードレールを適用し、曖昧な状況下ではデフォルトでエスカレーションを行うよう求めている。.

これをガードレール内のエージェントと呼ぶことにしましょう。推論レイヤーは確率的ですが、権限と実行レイヤーはそうではありません。第2レイヤーなしでエージェントを導入するチームは、モデルの自己抑制を信頼しているだけであり、プロンプトは制御ではありません。純粋なSOARに固執するチームは、機械が処理できるようになった最初の判断作業をアナリストに任せ続け、その費用を払い続けています。.

これはSOC自動化の評価にとって何を意味するのでしょうか? 

AI SOCアーキテクチャに関する疑問は、4つの購入に関する疑問へと発展し、それらはどんな機能マトリックスよりも早く市場を細分化する。

  1. 捜査官の判断を、その捜査官が照会した証拠まで遡って追跡し、監査人に対してその経緯を再現することはできますか?
  2. アクションのアクセス許可はどこに存在しますか?プロンプト内ですか、それともモデル外部の強制ポリシーレイヤー内ですか?
  3. 信頼度が低い場合、何が起こるのか、そしてその閾値は誰が設定するのか?
  4. ベンダーの決定論的実行レイヤーは、AIよりも先に存在していたのか、それとも後からラッパーとして追加されたのか?

最後の質問は、購入者が見落としがちなものです。オーケストレーションをレガシーシステムとして扱うベンダーは、監査不可能なエージェントを出荷することになります。一方、エージェントをアドオンとして扱うベンダーは、概要ボタンを出荷するだけです。Swimlaneでは、実行レイヤーを置き換えるのではなく、継続的に投資してきました。なぜなら、ガバナンス可能な自律性には両方が必要であり、決定論的な部分は後付けがはるかに難しいことを私たちは理解しているからです。.

重要なポイント: 管理可能な自律性を実現するには、後付けのラッパーではなく、堅牢で組み込み型の決定論的な実行レイヤーが必要となる。.

結論:SOAR市場に何が起こったのか 

スタンドアロン型のSOAR市場は、ガートナーが指摘した通り、より広範なプラットフォームに吸収され、消滅した。しかし、SOARという概念自体は消滅しなかった。オーケストレーション、決定論的な実行、そして監査が、エージェントの自律性を制御するための基盤となったのである。.

変化したのは分業体制だ。機械が最初の判断を下し、人間は機械を制御する。その制御を実際に機能させるための仕組みは、デモに登場することはほとんどなく、監査担当者との接触後もこの仕組みが機能し続けるかどうかは、この仕組みにかかっている。.

スイムレーンタービン

Swimlane AI SOCの動作をご覧ください

ガバナンス可能なAI SOCエージェントが、確率的推論と決定論的実行を組み合わせることで、複雑な脅威調査を安全に自動化する方法を体験してください。.

デモのリクエスト

ライブデモをリクエストする