Swimlane、TurbineにカスタムAI脅威検知機能と双方向MCP対応を追加

AIセキュリティアナリストはアラートを迅速に調査できますが、そもそも生成されなかった警告を調査することはできません。Swimlaneは、自社のTurbineプラットフォームに顧客が定義できる新たな検知機能を追加し、この課題に取り組んでいます。これにより、セキュリティチームは運用データに独自のロジックを適用し、検知結果のアラートをSwimlane AI SOCに直接送信できます。

10月28日のリリースでは、双方向のModel Context Protocol（MCP）対応と、Hero AIアプリケーションビルダーエージェントも導入されました。これらの機能追加により、同社の自動化プラットフォームは、調査に値するアクティビティの判定、エージェントとツールの接続、セキュリティワークフローを支えるアプリケーションの構築という、相互につながる3つの業務に対応します。

Swimlaneによると、これらの機能は一般提供されています。今回の発表では、セキュリティ情報イベント管理（SIEM）、エンドポイント検知・対応（EDR）、クラウドセキュリティツールなど、既存のセキュリティインフラを補完する機能として位置付けられています。

何をアラートにするかをセキュリティチームが制御

多くのAI SOC製品は、検知システムが不審な挙動を特定した後のトリアージ、調査、対応に重点を置いています。しかし、組織が新たなエージェント、コパイロット、ローカルモデル、MCPサーバーを、既存の検知製品が対応できる速度を上回るペースで導入すると、この役割分担は難しくなります。

企業は、許可されていないAIサービスに送信された機密情報、ローカルモデルの予期しない使用、ガードレールの無効化、あるいはエージェントが想定予算を大幅に超えてリソースを消費している状況を調査する必要が生じる場合があります。こうした状況の中には、ベンダーがあらかじめ定義できる普遍的なシグネチャではなく、組織独自のポリシーや環境に固有のものもあります。

新しいTurbineの機能により、チームはプラットフォームが利用できるデータに独自の検知ロジックを適用できます。Swimlaneによると、1つのビッグデータアクションで並列コンピューティングノード上の数万件のレコードを評価し、その後、アラートをAI SOCに送り、調査とガバナンスに基づく対応につなげることができます。

このアーキテクチャにより、検知ロジックを、その結果に基づいて動作する自動化に近づけられます。条件の特定と、その後の手順の手動での組み立てを別々に行うのではなく、組織固有のルールを既存の調査ワークフローに接続できます。ただし、検知の有用性は、関連するアクティビティがTurbineからアクセスできるデータに含まれているかどうかに左右されます。

「セキュリティ業界はこの2年間、AIがどこまで自律的にアラートに対応できるかを議論してきました。しかし、それではもっと基本的な問いが抜け落ちています。そもそも、そのアラートはどこから来たのでしょうか」と、Swimlaneの共同創業者兼CEO、Cody Cornell氏は述べました。

今回のリリースでは、AIを活用した検知ルールの作成についても説明されています。チームは実現したい検知内容を説明し、Turbineのプレイブック生成機能を使って構築を進めることができます。ただし、ロジックを生成することと、それが意図した挙動を確実に特定できると確認することは、別の作業です。組織固有のルールは、実行環境のデータ、権限、条件を反映する必要があります。

インシデントの原因となり得るAIシステムを調査

Swimlaneは、こうしたシナリオをAI検知・対応（AIDR）と呼んでいます。ここでは、AIシステム自体がインシデントの対象になります。これは、AIモデルを従来型のフィッシングアラートやエンドポイントアラートの要約に使うだけの場合とは異なります。

プロンプトインジェクションは、この違いをよく示す例です。エージェントは処理中のコンテンツに埋め込まれた指示に遭遇する可能性があり、外部の情報によって挙動が左右されるリスクが生じます。有用な調査を行うには、既知のマルウェア指標だけを探すのではなく、エージェントへの入力、ツールの使用状況、そしてその結果としての動作を調べる必要があるかもしれません。

同様に、支出の予想外の急増は、従来型の侵入に似た兆候を示さなくても、エージェントの誤動作や誤った誘導を示している可能性があります。必要な利用状況や運用上のシグナルを取得できることを前提に、顧客が定義するロジックを使えば、各チームは自社の導入環境における異常を表現できます。

発表された処理規模は同社の仕様であり、あらゆる種類のプロンプトインジェクションや不正なAI利用を検知する能力について、公表されたベンチマークではありません。実務上の変化は、既存のセキュリティ製品が提供するアラートに加え、チームが自らの観察結果を実際に対応可能な事案に結び付ける経路が新たに得られることです。

MCPでエージェントと自動化を双方向につなぐ

MCPは、AIアプリケーションがツールを利用するための共通インターフェースを提供します。Swimlaneの10月のリリースは、この接続の両方向に対応しています。

MCPホストとして、TurbineはHero AIがサードパーティーのMCPサーバーに接続し、調査やプレイブックの実行中にそれらのツールを利用できるようにします。認証とアクセス制御は一元管理されます。そのため、セキュリティワークフローは、既存のAPI連携に加えて、外部のMCP互換機能も呼び出せます。

MCPサーバーとして、Turbineはガバナンスの適用された自動化機能を外部のAIクライアントに公開します。発表では、既存のロールベースのアクセス制御の範囲内で、複数ステップのプレイブックなどTurbineのコンポーネントを呼び出せるクライアントの例として、Claude、ChatGPT、Cursor、Gemini CLI、Microsoft Copilotが挙げられています。

この違いは重要です。前者では、Swimlaneのエージェントが別のシステムに働きかけます。後者では、外部アシスタントが承認済みのTurbineワークフローを開始できます。アシスタントを既存のプレイブックに接続すれば、企業はAIクライアントごとに業務プロセスを再構築するのではなく、既存の自動化と権限を再利用できます。

Swimlaneによると、TurbineはMCPツールと従来型のAPIを組み合わせられます。このため、MCPに対応しているシステムが一部に限られる環境にも、この発表は関係します。チームは、既存の連携をすべて一度に変更することなく、より広範なワークフローにこのプロトコルを組み込めます。

人による確認を取り入れたセキュリティアプリケーションの構築

Hero AI Application Builder Agentは、新たなセキュリティ用途に必要なレコード構造、レイアウト、ワークフローの設定という、別の作業負担に対応します。ユーザーが必要な内容を自然言語で説明すると、エージェントが該当するアプリケーションを作成または変更します。

発表によると、生成された変更は、人が確認するまで保存されません。変更箇所は強調表示され、ユーザーは変更が確定する前に承認または却下できます。この承認の段階が重要なのは、アプリケーションの構造が、アナリストによる証拠の記録、ケースの段階間の移動、対応の実施方法に影響し得るためです。

この新しいエージェントは、より広範なHero AIポートフォリオを基盤としています。Swimlaneの製品資料によると、既存のエージェントはデータ取り込み、プレイブック生成、可視化、調査に対応しており、エージェントごとにモデルを選択することもできます。アプリケーション構築によって、こうした作業を支援する機能が、それらを取り巻く運用ワークスペースにも広がります。

AIの推論と予測可能な自動化を組み合わせる

今回の追加機能は、必要な推論の度合いに応じて、決定論的な自動化、AIを活用した調査、完全にエージェント主導の調査の間で作業を振り分けるSwimlane AI SOCのルーティングモデルに組み込まれます。既存のプレイブックで定型的な手順に対応する一方、複雑なケースではエージェント主導の調査と人による確認を活用できます。

これは製品設計の重要な要素です。すべてのタスクをモデルに処理させる必要はありません。既知の対応手順は従来型の自動化として維持しながら、見慣れない証拠の解釈や調査計画の作成をエージェントに支援させることができます。

顧客が定義する検知機能は、この運用モデルに「そもそも何をきっかけにプロセスを開始するのか」という、より早い段階の判断を加えます。組織全体でAIを導入するセキュリティチームにとって、10月のリリースは、自社が許容する行動についての知見を、活動が許容範囲を外れた際に調査と対応を行うツールにつなげる手段となります。