セキュリティAIの評価は成功率だけでは不十分｜研究解説

研究・論文

ベンダーから「当社のAIエージェントはこのベンチマークで◯◯%の成功率」と提示されても、いざ自社のSOCに入れると期待外れ——。生成AIを使ったセキュリティ製品（攻撃検証の自動化ツールやSOC支援エージェント）が増えるなか、情シスが直面し始めた評価の難しさです。本記事は、セキュリティAIエージェントを「成功率」ではなく「コスト対効果」で評価し直した査読前の研究を、実務者目線でかみ砕いて解説します。

この記事でわかること

  • なぜ「成功率だけ」のベンチマークは本番運用の判断材料として不十分なのか
  • 研究が示した、攻撃（オフェンシブ）と防御（SOC）でのコスト対効果の違い
  • 情シスがAIセキュリティ製品を評価・選定するときに使える観点

※本記事は査読前（プレプリント）のarXiv論文をもとにしています。結果は今後変わりうる点、単一の研究を過度に一般化しない点にご留意ください。

どんな研究か（1文で）

セキュリティ用途のLLM（大規模言語モデル）エージェントを、従来の「潤沢な計算資源のもとでの最大成功率」ではなく、推論やツール呼び出しにかかるコストと成功率をセットで見る「コスト対効果（cost-success）」の視点で評価し直した研究です。論文タイトルは「Beyond Success Rate: Cost-Aware Evaluation of Offensive and Defensive Security Agents」（Paul Kassianik、Blaine Nelson、Yaron Singer、2026年7月16日投稿）。

なぜ情シスに関係するのか

AIエージェントの評価は、これまで「どれだけ難しいタスクを解けるか」という最大能力の測定に偏りがちでした。脆弱性の発見、エクスプロイト作成、ペネトレーションテスト、CTF（Capture The Flag：セキュリティ競技）の攻略といった攻撃側の腕前を、計算資源を惜しみなく与えた条件で測るやり方です。

しかし研究チームが指摘するのは、実運用では話が変わるという点です。実際のセキュリティ業務では、推論の一手ごと、ツール呼び出し、ログ（テレメトリ）への問い合わせ、外部情報での付加分析（エンリッチメント）——そのすべてが時間とコストという「予算」を消費します。予算を無制限に与えたときの成功率は、限られた予算で回す現場の実力とは別物、というわけです。

これは情シスの製品選定に直結します。カタログの成功率だけを見て導入すると、「解けることは解けるが、1件の調査に膨大なAPIコストと時間を食う」ツールをつかまされかねません。

研究の方法

研究では、性質の異なる2種類のタスクでエージェントを評価しています。

区分 使ったベンチマーク タスクの性質
攻撃（オフェンシブ） Cybench（専門的なCTF課題群） 脆弱性発見・エクスプロイト作成など攻撃能力
防御（ディフェンシブ） Splunk BOTS v1（SOC調査課題） ログ分析・インシデント調査などSOC実務

ポイントは、モデルを同じコスト水準で横並びに比較し、成績を「推論に使ったコスト」と「ツール利用に使ったコスト」に分解して見たことです。単に勝ち負けを見るのではなく、どこに予算を投じると成果が伸びるのかを可視化しています。

何が分かったのか

論文が報告する主な知見は次のとおりです（いずれも著者らの実験に基づく主張で、査読前である点に注意してください）。

  • 攻撃タスク：計算資源を増やせば伸びる。規模を拡張したオープンウェイト（公開重み）モデルは、コストを抑えつつ商用モデルに迫る性能を出せた。テスト時に計算を追加投入するほど成績が上がる傾向がみられた。
  • 防御タスク：計算資源を増やしても頭打ち。SOC調査の成否は、推論予算の多さよりも、規律あるツールの使い方、ログ（テレメトリ）を的確にたどる力、必要な情報だけを選んで付加する判断に強く左右された。

ざっくり言えば、「攻撃はパワー（計算量）がものを言うが、防御は段取りの良さがものを言う」という対比です。防御側は闇雲に推論を回しても成果が比例して伸びず、無駄なログ照会やエンリッチメントを重ねるとコストばかり膨らむ、という現場感覚を裏づける結果といえます。

現場目線の課題

この研究が示す「攻撃と防御でコストの効き方が違う」という点は、情シスの肌感覚とよく合います。SOCの調査業務を思い浮かべると分かりやすいのですが、優秀なアナリストは片っ端からログを引くのではなく、当たりをつけて必要なSIEMのクエリだけを的確に叩きます。AIエージェントに置き換えても、この「無駄打ちの少なさ」が効率を決めるというのは腑に落ちる話です。

裏を返せば、ベンダーの「成功率◯◯%」という数字だけでは、1件の調査あたりに何回ツールを呼び、どれだけAPIコストや時間を消費するのかが見えません。限られた人員・予算で運用する現場にとっては、むしろこの「単価」のほうが導入可否を左右します。派手なデモで解けたタスクが、月々の請求書では割に合わない——そんな落とし穴を避ける視点を、この研究は与えてくれます。

限界・留意点

  • 査読前の研究：arXivのプレプリントであり、第三者の査読を経ていません。手法や結論の一般性は今後の検証待ちです。
  • 特定ベンチマークでの結果：CybenchとSplunk BOTS v1という限定された課題に基づくもので、自社環境の実タスクにそのまま当てはまるとは限りません。
  • コスト＝万能指標ではない：コスト対効果は重要な軸ですが、検知の見逃し（偽陰性）や誤検知の質など、別の観点と組み合わせて評価する必要があります。

情シスはどうすべきか

個別の実験結果を丸のみにする必要はありませんが、AIセキュリティ製品を評価する際の「問いの立て方」として、次の観点は明日から使えます。

  • 成功率だけでなく「単価」を聞く：1件の検知・調査あたりの平均的なツール呼び出し回数、トークン消費、所要時間を確認する。
  • 自社に近いタスクで試す：ベンダー提示のベンチマークではなく、自社のログや典型的なインシデントを使ったPoC（試行導入）で「コスト対効果」を測る。
  • 防御用途は段取りを見る：SOC支援エージェントなら、無駄なクエリを打たず必要な情報に的確に到達できるか（＝ツール利用の規律）を評価軸に入れる。

AIの導入・統制そのものの土台としては、公的・標準的なフレームワークを起点にするのが堅実です。NIST「AI Risk Management Framework（AI RMF）」（https://www.nist.gov/itl/ai-risk-management-framework）や、組織的な運用体制づくりの基礎としてIPA「中小企業の情報セキュリティ対策ガイドライン」（https://www.ipa.go.jp/security/guide/sme/index.html）が参考になります。あわせて、AIに任せきりにせず利用者側のリテラシーを高める地道な啓発も欠かせません。

LLMエージェントを企業で使いこなすための論点は本メディアでも継続的に扱っています。LLMエージェントを監査可能にする設計や、実行時の防御に踏み込んだAIエージェントの実行時防御「トークンフロー監査」もあわせてご覧ください。

まとめ

  • 本研究は、セキュリティAIエージェントを「最大成功率」ではなくコスト対効果（推論・ツール利用の予算と成果）で評価すべきだと提案した（査読前）。
  • 攻撃タスクは計算資源を増やすほど伸びる一方、防御（SOC調査）は推論量よりツール利用の規律・ログをたどる的確さが成否を分けた。
  • 情シスは製品評価で成功率だけでなく「1件あたりの単価（回数・トークン・時間）」を確認し、自社タスクに近いPoCでコスト対効果を測るのが現実的。

出典

タイトルとURLをコピーしました