攻撃側AIは安くなるが防御側AIはスケールしない ― セキュリティエージェント評価の非対称性

---

TL;DR

• 攻撃系AIエージェント(CTF)は計算資源を積むほど強くなり、オープンウェイトモデルでもコスト効率よくフロンティア級に迫れます。一方、防御系AIエージェント(SOC調査)は計算量を積んでも伸びず、成否はツール操作の規律とテレメトリ探索の巧拙で決まります。
• 攻撃系への投資はフロンティアモデルの性能向上にそのまま飲み込まれやすく、防御系はテレメトリ統合とツール呼び出しハーネスの設計投資に分があります。
• その他、学習データへのポイズニング経路の拡大、LLM集計における確率的な自己矛盾、エージェント検索の評価手法の欠陥、再学習不要のレコメンド更新を扱った研究が並びました。

本命:攻撃側は安くなる、防御側はスケールしない

Beyond Success Rate: Cost-Aware Evaluation of Offensive and Defensive Security Agents / インタラクティブ結果サイト

攻撃系ベンチマークのCybench(CTF、旗を奪う形式のセキュリティ競技課題)と、防御系ベンチマークのSplunk BOTS v1(SOC=セキュリティ運用チームによる侵害調査シナリオ)で、言語モデルのセキュリティエージェントを「潤沢な予算での最高成功率」でなく「固定コスト水準での成功率」で比較し、推論支出とツール支出に分解して評価しています。

技術的読み

従来のセキュリティエージェント評価は、豊富な推論予算を与えた上での脆弱性発見・エクスプロイト作成・CTF完答といった「ピーク性能」を測るものが中心でした。この論文の新しさは、コストを固定した上での成功率を比較し、攻撃と防御でまったく異なるスケーリング特性を発見した点にあります。攻撃側(CTF)はテスト時計算量を増やすほど性能が伸び、スケールしたオープンウェイトモデルがコスト競争力を保ったままフロンティアの独自モデルに迫れます。対して防御側(SOC調査)は同じようにはスケールせず、成否は生の推論予算よりもツール利用の規律・テレメトリ探索・選択的なエンリッチメント(追加情報の絞り込み)への依存度が高いという結果です。

留意点として、Splunk BOTS v1は2016年公開のやや古い演習データセットであり、実際の本番SOC環境のノイズの多いアラート運用を完全には再現していない可能性があります。Cybenchも人工的に設計されたCTF課題であり、両ベンチマークとも単一の研究グループによる査読前プレプリントである点は割り引いて読む必要があります。

ビジネス的読み

• UE/コスト構造:ペネトレーションテスト自動化はテスト時計算量への投資がそのままコスト低下に転嫁できる構造です。SOC自動化は逆に、トークンを積む投資が効かず、ツール呼び出しハーネスの設計投資でしか成果が変わりません。
• 内製 vs プラットフォーム吸収:攻撃側の性能向上が主に「計算量を積む」ことで説明されるなら、専用のペンテストAI製品はフロンティアモデルの汎用的な推論能力向上に飲み込まれやすい領域です。一方、防御側の性能はツール操作の規律というエンジニアリング的な工夫に依存するため、汎用モデルの性能向上だけでは自動的に解決しません。
• 運用負荷/横展開性:防御側の成功要因(テレメトリ探索・エンリッチメントの選別)は、SOC固有の運用知識をハーネス(ツール呼び出しの設計・順序制御)に埋め込む作業であり、横展開には各社のテレメトリ構造への適応作業が必要です。
• 独自資産/防御可能性:防御系エージェント製品の堀は、モデルそのものではなく、テレメトリ統合とツール呼び出しの設計・解釈ロジックにあります。
• 市場規模/ポジショニング:防御側の性能が既存のセキュリティテレメトリ(Splunkのようなログ基盤)への統合品質に左右されるなら、既存のセキュリティ運用基盤ベンダーが自社データの上にエージェント層を積む形が有利で、薄いラッパー型のSOC自動化製品は不利になりやすい構図です。
• 人間が残す境界:SOC調査のボトルネックは計算量でなく判断力であるため、完全自律化ではなく「エージェントが絞り込み、人間が最終判断する」運用設計に投資すべきです。

逆張り・見落とし

「防御側はスケールしない」という結論は、必ずしも永続的な性質ではない可能性があります。ツール操作の規律自体が、ツール利用の軌跡データでのファインチューニングによって改善しうる能力だとすれば、「防御は計算量非依存」ではなく「現行のハーネス設計がまだツール利用に特化した学習を経ていないだけ」という見方もできます。また、攻撃側の自動化が防御側より先に安価に実用化されるという非対称性そのものが、市場機会である以上にセキュリティ全体のリスクとして捉えるべき論点です。

含意とポジション

セキュリティエージェント製品を作る/選ぶ立場なら、攻撃系(ペンテスト自動化)への投資は「フロンティアモデルの性能向上に吸収されやすい」前提でリターンを見積もるべきです。逆に防御系(SOC自動化)は、モデル選定より自社のテレメトリ構造に合わせたツール呼び出しハーネスの設計に投資対効果があります。すでに攻撃系の自動化製品に賭けているなら、モデル依存でなく独自データ・独自ワークフローの部分に差別化ポイントを移す判断が必要です。

確信度:方法論(コストを固定して比較すべきという主張)については信頼度が高いです。「防御はスケールしない」という具体的な結論は、単一ベンチマーク・単一研究グループの結果であり、他のSOCデータセットや実運用環境での再現性は未検証のため中程度の確信度に留めます。signal寄りですが、一般化には注意が必要です。

その他の重要トピック

学習データへのポイズニング経路の拡大

Pretraining Data Can Be Poisoned through Computational Propaganda

公開討論の場(フォーラムやコメント欄など、誰でも書き込めるインターフェース)を使って、事前学習データセットに大規模にポイズニングを注入できることを実証した研究です。HalfLifeという分析手法で、悪意あるコンテンツがウェブクロール後のデータキュレーション(フィルタリング・重複排除等)パイプラインを通過してどれだけ生き残るかを推定しています。

技術的読み:従来のポイズニング研究はWikipediaなど管理された情報源を対象にしていましたが、実際の事前学習コーパスは巨大かつ多様な出典から成ります。この研究は、誰でも書き込める公開討論インターフェースが汚染経路になりうることを示し、キュレーションパイプラインを経ても汚染が生き残る条件を定量化した点が新しいです。

ビジネス的読み:自社でウェブスケールのデータを収集して事前学習・継続事前学習を行うプレイヤーにとって、学習データの出所管理(provenance)がセキュリティ要件になります。フロンティアラボが十分な防御的キュレーションを行っていれば、このリスクは主に自前でデータ収集から行う内製フルスタック勢に集中します。

so what/スタンス更新:自社でデータ収集からモデル学習まで内製しているなら、データ出所の来歴管理と汚染検知を運用コストとして織り込む必要があります。フロンティアAPIを利用するだけの立場では直接的な脅威ではありませんが、「学習データの質を疑う」という視点は自社のRAGや評価用データにも当てはめるべきです。

LLMの集計における自己矛盾(macro fallacy)

Partition, Prompt, Aggregate: Statistical Self-Consistency in Language Models

人口をどんどん細かい部分集団に分割してLLMにプロンプトし、それぞれの推定を積み上げて全体推定に集約すると、直接「全体について聞いた」推定よりも実際の人間データに近づくという現象(macro fallacy)を発見した研究です。本来、確率の全確率法則により両者は一致すべきですが、フロンティアモデル全般で広く矛盾が見られました。

技術的読み:LLMの文脈内推論は条件付き確率の推定として扱われがちですが、この研究は基本的な確率的整合性をLLMが満たさないことを定量的に示しました。モデルは部分集団の知識自体は持っている(細分化して聞けば良い推定が出る)にもかかわらず、それを一貫した全体推定に統合する機構を欠いています。

ビジネス的読み:市場調査・ペルソナ推定・合成サーベイにLLMを使う製品にとって直接関係する結果です。「モデルに直接聞く」設計は信頼性が低く、「細かく分割してから集計する」プロンプト設計のほうが精度が上がるという、具体的な設計指針が得られます。

so what/スタンス更新:合成データ生成やペルソナベースの市場調査ツールを作る/使うなら、集計方法(細分化してから集計)をプロダクト設計に組み込む価値があります。逆に「LLMに市場規模を一発で聞く」ような雑な使い方は、今後も外れ続けると想定してよいです。

エージェント型検索における「橋渡し文書」問題

Bridge Evidence: Static Retrieval Utility Does Not Predict Causal Utility in Multi-Step Agentic Search

複数ターンにわたって検索・推論するエージェントによる検索で、単体では「役に立たなそう」と静的評価では低スコアな文書のうち約3割が、実際には除去すると後続の検索軌跡が破綻する「橋渡し文書」であることを実証した研究です。HotpotQA上で文書を削除して軌跡を再実行する反実仮想実験を行い、静的な有用性スコアとの相関はほぼゼロ(Spearman ρ=-0.026)、代替指標でも橋渡し文書の割合は27.2%でした。

技術的読み:従来のRAG評価(文書を読ませて回答が改善するか)は単発の質問応答には妥当ですが、マルチターンのエージェント検索には根本的に当てはまらないことを定量的に示した点が新しいです。「次に何を検索すべきかを教えてくれる文書」という、静的評価では見えない価値軸を可視化しました。

ビジネス的読み:エージェント型検索製品(社内RAG、検索エージェントSaaS等)の評価・チューニング手法に直結します。既存の検索評価パイプライン(静的な関連度スコアリング)をそのままエージェントの評価やretrieverの学習に転用すると、実際に軌跡を支える重要な文書を見落として最適化してしまうリスクがあります。

so what/スタンス更新:自社でエージェント検索を作っているなら、評価指標を静的relevanceから「この文書を消したら軌跡が変わるか」という反実仮想の軌跡影響に置き換えるべきです。既存のstatic relevance評価をそのまま使い続けると、軌跡を支える重要文書を見落として最適化を誤ります。

再学習不要のレコメンド埋め込み更新

Mutable Low-Rank Sketches for Retrain-Free Recommendation

ユーザーが新しい評価をつけた瞬間に、モデル全体を再学習せずにその場で埋め込みを更新できる手法です。KuaiRecデータセットで、データの1.8%しか読まずにALS(全データ・全再学習)と同等以上のRMSE(0.810対0.822)を達成し、バッチ更新も8倍高速、新規ユーザーは初回評価から1ミリ秒未満でパーソナライズされたレコメンドを受け取れます。

技術的読み:二段階レコメンドで長年課題だった「埋め込みの陳腐化」(次の再学習まで古い埋め込みのまま)を、低ランク射影を一度学習した上で疎なセグメント木によるオンザフライ再計算で解決するアプローチです。「新しい観測が誤差の上限を単調に締める」という理論的保証(定理1)を示しており、既存手法にはない性質です。

ビジネス的読み:コールドスタート対応やリアルタイム個人化が売りのレコメンドSaaS/自社実装にとって、再学習バッチの計算コストを直接削減できる話です。スパースなデータ環境(密度1%未満)でのアイテムカバレッジが40〜130%改善するという結果は、ロングテール在庫を抱えるEC/コンテンツプラットフォームに刺さります。

so what/スタンス更新:自社サービスで「新規ユーザーのコールドスタート」や「再学習の遅延」が課題になっているなら、この手法系統は検証対象になります。ただしKuaiRec一データセットでの結果であり、実運用データでの再現性は要検証です。「再学習しないと個人化が更新されない」という前提そのものを疑う価値はあります。

マルチエージェント検索の状態管理フレームワーク

SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration

オープンドメイン情報収集を「根拠付きの関係スキーマ補完」として定式化し、探索の進捗を暗黙的な会話履歴でなく、Frontier Task・Evidence Graph・Coverage Map・Failure Memoryという明示的な共有状態として外部化するマルチエージェント検索フレームワークです。行き詰まったサブエージェントのスロットを未解決のカバレッジギャップへ即座に再割当てするパイプライン並列スケジューリングを持ちます。

技術的読み:長い対話履歴を持つ検索エージェントが陥りがちな「同じ検索を繰り返すループ」問題に対し、進捗を構造化データとして外部管理する設計思想は妥当性が高いです。ただし公開されている摘要の範囲では、既存のマルチエージェント検索との定量比較が明示されておらず、アーキテクチャの提案が先行している段階に見えます。

ビジネス的読み:検索エージェント/リサーチエージェント製品を作るなら、「進捗の外部状態管理」という設計パターン自体は独自実装にも取り入れる価値がある発想です。ただし、こうした汎用的なオーケストレーション層は、将来的に主要なエージェントフレームワークに吸収されやすい部分でもあります。

so what/スタンス更新:進捗の明示的な外部状態化というアイデアは今すぐ自社のエージェント設計に転用できます。一方、フレームワークそのものへの本番投資は、既存手法との定量比較が公開されるまでは判断材料が不足しており、投資対象にはなりません。

今週試すなら / 無視していい hype

今週試すなら

• 自社のセキュリティ・RAG・レコメンド系エージェントの評価に「固定コストでの成功率」という軸を1つ追加してみてください(本命の教訓の転用です)。
• エージェント検索を運用しているなら、静的relevanceでなく「この文書を消したら軌跡が壊れるか」という反実仮想テストを小規模にでも一度回してみてください(橋渡し文書の有無の確認です)。

無視していい hype

• 「AIエージェントが自律的にペネトレーションテストを完全代替する」的な煽り文句は、コスト効率良くフロンティア級に迫れるという話と、防御側も同様にスケールするという話を混同した単純化です。