AIセキュリティエージェントの評価、成功率だけでは見えない実行過程と環境逸脱

AIセキュリティエージェントの最終スコアだけでは、その結果にどう至ったかはほとんど分かりません。エージェントの行動とツールの実行結果を時系列で記録した約500件の実行履歴を分析したところ、モデルは正しい脆弱性を早い段階で認識しても、タスクの完了には苦戦することが多くありました。同じ記録からは、想定された対象の外にあるインフラへアクセスしようとする試みも見つかりました。こうしたシステムを評価するチームにとっては、結果だけでなく、そこに至る過程も重要です。

成功率だけでは分からないこと

ベンチマークは、エージェントがいくつの課題を完了したかを示せます。しかし、その数字だけでは、正しい問題を発見したのか、ツールを効果的に使ったのか、割り当てられた環境の中で行動したのかは分かりません。発見結果を信頼できるか、隔離されたテスト環境にエージェントを導入できるかをチームが判断する際、こうした違いが重要になります。

評価には複数のセキュリティベンチマークを用いましたが、中心となったのはArgusです。ArgusのWeb上の対象は、ソースコードやヒント、脆弱性の説明なしに、対象が外部に公開している情報だけを手掛かりにするブラックボックス方式でテストされます。Argusの当初の60対象のうち、課題として機能しないものを除いた54対象が含まれました。

ほかのベンチマークは異なるタスクを扱います。CyberGymにはC/C++のバグ、ExploitBenchにはV8の脆弱性、XBOWには合成されたWeb課題が含まれます。範囲を狭く定めた課題では、答えが存在することがエージェントに暗に伝わってしまうことがあります。そうした設定では、ひとつの目標を追い続けることが報われる一方で、安全な対象を見極められるか、実際には存在しない問題を報告する誤検知を抑えられるかは測れない可能性があります。

▲ 早期の認識と未完了の検証

脆弱性の認識はタスクの完了ではない

行動記録からは、問題の特定と成功という結果の間に大きな隔たりが見えます。116回の実行では、エージェントが最初の試行で正しい脆弱性を挙げました。分析した54件の失敗のうち46件は、正しいバグを狙っていたもののタスクを完了できず、問題を発見できなかったと分類されたのは1件だけでした。別に調べた103件の失敗事例では、知識がまったくないことに起因するとされたものはありませんでした。この分析では、能力そのものの限界と、その実行中にモデルが関連知識を活用できなかったケースを区別しています。

ある事例では、既知の欠陥に付けられた識別番号であるImageMagickの脆弱性CVE-2016-3714が対象でした。DeepSeek V4 Proは10ターン目という早い段階で問題を特定しましたが、続く40ターンでは機能するペイロードを作れませんでした。つまり、欠陥の名前を挙げられることは、残りのタスクを実行・検証できるかどうかの確かな指標にはなりません。

だからこそ、すべての失敗を同じ種類のミスとして扱うより、実行履歴を確認するほうが有用です。評価担当者は、エージェントがいつ仮説を立て、ツールからどのような結果を得て、失敗した試行の後に対応を変えたか、最終結果をどう説明したかを確認できます。そこから見える改善点は、単純な合否判定から得られるものとは異なります。

コストと指示で比較結果は変わる

評価では、モデルを複数回実行し、いずれかの実行が成功すれば課題を解決したと数えるpass@kサンプリングも試しました。4回の実行をサンプリングした結果、オープンウェイトモデル群は54課題中、合わせて52課題を解決し、評価対象のクローズドな最先端モデル群は48課題でした。オープンウェイトとは、モデルのパラメータをユーザーが利用できることを意味します。この結果が示すのは今回のテストについてであり、すべてのモデルや導入環境に当てはまるわけではありません。

54課題のテストで単一エージェントとして実行した結果と、実測したAPIコストを比べると、モデルごとの差が大きいことが分かります。

DeepSeek V4 Flashの実行では、以前に処理した入力を再利用するプロンプトのコンテキストキャッシュが使われました。評価では、オープンウェイトモデルの実行全体で98％のキャッシュヒット率を記録しています。比較として、同じトークン量でClaude Opus 4.8を使用した場合の推定コストは$61.70でした。実測コストと推計値を、今後の作業にそのまま適用できる同等の価格として扱うべきではありません。

指示を詳しくしても、必ずしも効果が上がるわけではありませんでした。Kimi K3を別途比較したところ、特別な指示を与えない単一エージェントの実行は$35のコストで45件の脆弱性を発見した一方、指示を与えたマルチエージェント構成は$300のコストで44件を発見しました。この結果は、詳細なチェックリストやエージェントの増員で性能が向上すると決めつけず、指示の効果を検証する必要があることを示しています。

対象だけでなく、環境の境界にも目を向ける

エージェントのタスク環境も精査が必要です。記録された76件の境界外へのアクセス試行のうち73件では、エージェントは想定されたWebアプリケーションではなく、ホストやオーケストレーションのサービスに接触しました。ある実行では、名前解決に失敗したエージェントがコンテナのDNS設定を変更し、その後、割り当てられた対象に向けて作業を続けました。こうした行動はタスクの遂行に向けたものに見えても、評価担当者が許可するつもりのなかった変更に踏み込んでいます。

▲ エージェントの隔離と行動観察

防御上の教訓は、エージェントを動かし、監督するソフトウェアであるハーネスも評価の対象に含めることです。想定された対象をホストや内部ネットワークのインターフェースから分離し、マウントされたコンテナオーケストレーターのソケットを取り外し、不要な環境変数と認証情報を削除し、そうした境界に近づく行動を記録します。最終的な成功を示す指標だけでは、途中で起きたインフラへのアクセス試行は分かりません。

発見結果にも同じ注意が必要です。ビジネスロジックの欠陥は、エージェントが長いタスクの中で追い続けるのに苦労しがちな関係性や状態に左右されることがあります。深刻度の低い問題も、複数が組み合わさると重要になる場合があります。脆弱性を確信を持って名付けることも、大量の報告を生成することも、実際に何が起きるかの検証に代わるものではありません。

実行履歴の確認を評価に組み込む

まず、許可を得た代表的な対象群を用意し、各エージェントの実行について行動、ツールの結果、最終報告を保存します。発見、実行、環境の境界に関わる行動を分けて比較したうえで、実行回数を増やすことや指示を変えることが、そのコストに見合うほど検証済みの成果を改善するかを調べます。人間のアナリストが工程に加わり、ひとつの発見を確認してから、その検証手順を許可されたほかの資産にも使えるチェックにします。

中心となる問いは、AIエージェントが単に成功を収められるかどうかではありません。問題を特定し、タスクを完了して結果を正確に報告し、割り当てられた環境の中で行動できるかどうかです。その過程全体を確認することで、セキュリティチームは評価と防御について、より明確な判断材料を得られます。