月3,000〜4,000件の警告を階層型のエージェントで調べます。同社は90%超を自律処理すると報告し、複雑な事案は証拠付きで人へ引き継ぎます。 自律解決率は導入企業の業務条件による値です。誤った終了、記憶の更新、高リスク事案の引き継ぎを含めて評価することが焦点です。 警告の量に合わせ調査を二層へ分ける AWSは11月6日、Greenlight Financialのセキュリティ運用基盤Lunaを紹介しました。AgentCore runtimeとmemoryを使う階層型のエージェントです。同社の月3,000〜4,000件のセキュリティ・リスク事案を処理し、90%超を人の介入なしで解決すると報告しています。漏えいしたカード情報、認証の異常、設備の警告、不審な取引などを調べます。従来は複数のシステムを照合するため、一件に15〜30分かかる作業があったと説明しています。これらはGreenlightの測定と業務に基づく値です。一般のSOCで同じ率を達成できると保証する内容ではありません。 専門エージェントと記憶で調査をつなぐ 最初の監督役が30超の専門エージェントを呼び、認証、端末、設備、支払い、顧客対応などの情報を照合します。確信が足りない案件は、より詳しい推論を行う第二層へ引き継ぎます。複数の情報源を再調査し、人が読める証拠を含む報告を作ります。短期の記憶には直近30日の事象と解決結果を置き、長期には繰り返す対応の知識を残します。解決の結果を再び取り込む処理も用意しています。対象は警告の量が多く、複数の管理画面を行き来する運用チームと見られます。カード情報の通知でも、所有、状態、重複、周辺の行動を調べ、リスクに応じて記録、確認、人への引き継ぎを分けます。自動化は一律の無人対応ではなく、段階ごとに判断を分担する構成です。 終了した件数と見逃しを別々に測る 導入時は、自律解決率の上昇と、正しく調査できたかを別々に測ることが論点になります。過去の正常な事例を記憶して警告を除外する仕組みは、環境が変わった後に見直す必要があると見られます。人へ送る条件だけでなく、低リスクとして閉じた案件の抽出確認も考えられます。原文の削減時間は、件数と手作業の所要時間から推定した値です。現金支出の削減額や人員削減の実績とは区別します。運用側は、承認された対処だけを実行する範囲と、根拠を人へ渡す方法を定める必要があります。記憶を更新する処理も管理対象です。自社の警告の種類、正解の付け方、誤処理の影響を確認した上で、限定した作業から効果を検証することが次の判断点になります。 記憶へ残す解決結果も審査の対象にする 解決の結果を次の判断へ使う構成では、一度の誤りが繰り返される可能性があります。次の判断点は、記憶へ追加する条件と、古い判断を修正する経路が明確かです。警告の種類が変わった場合に、以前の除外がそのまま有効にならないかを確認する方法が考えられます。人へ引き継ぐ件数が減ったことだけで評価せず、根拠を追える案件の割合も見る必要があると見られます。自律処理と監督を一緒に育てることが焦点です。古い知識の訂正も運用に含めます。