CyberGymベンチマーク解説：E2Eスコアが実際に測っているもの

最も広く流通しているCyberGymスコア——ローンチ投稿に載っている数字であり、モデル間で比較される数字——は、131件の絞り込まれたタスクにおけるタスク成功率である。ここで成功とは、エージェントが未パッチのC/C++ビルドをクラッシュさせる概念実証用の入力を生成し、そのクラッシュを止めるパッチを書き、かつプロジェクトの開発者が書いたテストを壊さなかったことを意味する。BenchLMの集計では、MiMo-V2.6-Flashが95.1%で首位、MiMo-V2.6-Proが94.0%で続き、DeepSeek-V4.1-Flashは80%台後半で数ポイント差につけている。その表を引用する人のほとんどは、数値が比較可能かどうかを左右する3つの点に触れていない。すなわち、このベンチマークには複数の実装が存在すること、ほとんどの行は独立した実行ではなくプロバイダーの自己申告であること、そして最も興味深い単一の段階は記録されているが集計されていないことだ。それは帰属に関する同じ基準だ。AIインシデントアーカイブは自身のエントリにこの基準を適用している——出典のない主張は結果ではない——そしてCyberGymコーパスは、その評判が示唆するよりも頻繁にこの基準を満たしていない。

これは、ベンチマークがエージェントに何を求めるのか、タスクセットがどのように構築されたのか、実装がどこで分岐するのか、そして防御側が高いスコアから何を結論づけるべきか、また結論づけるべきでないかについてのガイドです。

タスク：見つけ、再現し、パッチを当てる — 何も壊さずに

CyberGymはBerkeley Center for Responsible, Decentralized Intelligenceに由来し、その前提は意図的に狭く設定されています。各タスクは、広く使われているオープンソースのC/C++プロジェクトにおけるメモリ安全性の脆弱性を対象としています。エージェントはバグを特定し、サニタイザーのクラッシュを引き起こす概念実証入力を作成し、その後、プロジェクト自体のテストが引き続き通る状態で、クラッシュが再現しなくなるようにコードを修正しなければなりません。この一連の流れこそが要点です。「バグを見つける」ことだけを求めるベンチマークでは、パターン認識が評価対象になってしまいます。動作するクラッシュ入力を要求し、既存機能を壊さない修正を求めることで、エージェントは疑念から欠陥の実証、そして修正までというループを閉じることが強制されます。

RDIはこのベンチマークを、攻撃・防御の各段階にわたるAIサイバー能力を追跡するより広範な観測体系の一環として位置づけている。その枠組みは注目に値する。CyberGymは、ExploitGymやエンドツーエンド版と並ぶ、実験台の上の一つの計測器にすぎない。これを独立したリーダーボードとして読むと、その文脈が失われてしまう。数値がうまく通用しない理由の一つはそこにある。

4つのステージ、そのうち3つが得点対象

採点ルールは、ベンチマークで最もあまり語られてこなかった部分です。なぜなら、そこでは、もっともらしく聞こえるスコアが実際に起きたことと乖離しうるからです。

ステージ1は再現です。エージェントのPoC入力が未パッチのビルドをクラッシュさせるかどうか。ステージ2はパッチです。提出された変更がその特定のクラッシュを止めるかどうか。ステージ3は回帰です。開発者が作成した機能テストが引き続き合格するかどうか。これら3つでスコアが決まります。

ステージ4は、そのパッチが実際のグラウンドトゥルースの脆弱性を修正するかどうかを問い、カウントされるのではなく診断として記録される。この非対称性には少し立ち止まる価値がある。なぜなら、それは「エージェントがクラッシュを消し去れる」ことと「エージェントがバグを修正できる」ことの違いだからだ。どちらも有用な主張だが、同じ主張ではない。シグナルを捕捉したり、境界チェックをオーバーフローを超えて広げたり、コードパスを完全に無効化したりしてクラッシュを抑え込むエージェントは、ステージ1から3では得点するが、ステージ4では失敗する。もしある報告が、ステージ4を参照したかどうかを述べずに単一の数値を報告しているなら、その2つのうちどちらが測定されたのかは分からない — そして、その診断はまさに、あなたがそれを問い合わせられるように存在している。

131のタスクがどのように選ばれたのか——そしてそれがスコアにどう影響するのか

元のデータセットはスコア対象のセットより大きく、比較可能性を左右する最大の要因はそのフィルタリングにある。RDIのデータセットには、GoogleのOSS-Fuzzから抽出された139のオープンソースプロジェクトにまたがる920件の脆弱性が含まれている。サードパーティのトラッカーが用いるエンドツーエンドのバリアントでは、これが131タスクに絞り込まれる。各プロジェクトにつき1タスクとし、難易度によって選択され、オラクル漏洩やサンドボックス互換性の制約があるタスクは除外される。

そこから直接導かれる帰結が3つある。第一に、プロジェクトごとに1タスクということは、スコアが深さではなく広さに支配されるということだ。多数のプロジェクトで平均的なエージェントは、3つで卓越したエージェントより高い成績を出す。これは擁護可能な設計上の選択であり、「このエージェントが修正できる脆弱性はいくつか」とは異なる測定である。第二に、オラクル漏洩を除外することで、答えが推論ではなく環境から発見可能なタスクが除かれる。したがって残る集合は特定の意味でより難しく、易しいタスクを除くのではなくショートカットを除いている。第三に、タスクあたり90分の予算をプロジェクトのOSS-Fuzzイメージから構築したサンドボックス内で使うことは、細部ではなく成功の定義の一部である。なぜなら、現実の脆弱性対応の大きな割合はまさにその種の制約によって境界づけられており、無制限の探索に依存するエージェントはここでは失敗し、他の場所では成功するからだ。

タスク選択規則を無視した比較は、たまたま名前を共有しているにすぎない2つの異なるテストを比較していることになる。

2つの実装と、それらが一致する必要がない理由

混乱のほとんどはここにあります。CyberGym-E2E は RDI ベンチマークとして存在する一方で、第三者評価者によって実行される実装としても存在しており、同じモデルに対して両者が同じ数値を出すことは保証されていません。評価者自身のドキュメントにも明白にそう書かれています。その実装では、難易度によって選ばれたプロジェクトごとに1つずつ、計131タスクの絞り込まれたセットを使用し、各タスクを、プロジェクトの OSS-Fuzz イメージから構築された隔離サンドボックス内で、独自のエージェントハーネスを用いて、タスクごとに90分の予算で実行します。

その文にはスコアを決める2つの変数が含まれている。ハーネスとは、エージェントがその中で実行するループのことだ。ツール出力をどう観測するか、何ステップまで実行できるか、失敗した試行からどう回復するか。弱いモデルを組み合わせたより強力なハーネスは、その逆に勝つことができ、ハーネスはモデルの重みの一部ではない。予算は両方と相互作用する。したがって、CyberGymの数値は「このモデル、このハーネス、この実装において」と適切に書かれるべきであり、実装を伴わずに引用された数値は分母のない数である。

言及する価値のある二次的効果がある。ハーネスが実際の作業を行っているため、2つのモデルバージョン間のCyberGymスコアの改善は、一部がハーネスの改善である可能性があり、自社ハーネスの結果を報告するベンダーは、モデル能力ではなくシステム能力を報告していることになる。どちらも正当だが、両者を混同するのは正当ではない。

トラッカーの表を正直に読み解く

多くの人が目にするこの表は二次的な編纂物であり、自らの出典を明示している——ラベルを読めば、そこが有用な点だ。29行のうち、7行はベンチマークの所有者または独立した実行によるもので、21行はプロバイダーの自己報告、1行は二次報告である。この編纂物は、参考用に表を示すものであり、これに基づく順位付けは行わないと明言し、ほとんどの行が自己報告であるため注意して読むよう勧めている。その飽和に関する注記こそ、ページ上で最も有用な一行だ。上位3つは約70ポイントに分散している一方、上位10はおよそ10以内に収まっている。つまり、この表は依然としてモデルを区別している——ただし範囲の最上位では順序づけが薄い。

プロバイダーの自己申告は表示可能な証拠である。それは独立した測定ではなく、この違いはほとんどの場合以上にこのベンチマークで重要だ。なぜなら、ハーネス変数はベンダーに、報告する数値を調整するかなりの余地を与えるからである。自己申告と独立実行が食い違う場合、独立実行が優先される。自己申告しか存在しない場合、正直な解釈は「未検証、もっともらしい、比較可能なベースラインなし」である。

同じ注意は逆方向にも当てはまり、このベンチマークが読者に仕掛ける罠にもなる。CyberGymの行がないモデルはゼロ点を取ったのではない。そのハーネスでは測定されていないのであって、それは別の話だ。不在を失敗として扱うと、表は測定ではなくリーダーボードになってしまう。

高スコアがディフェンダーにとって意味することと、意味しないこと

セキュリティチームが実際に抱いている問いは「どのモデルが首位か」ではなく、「これで高スコアを取るエージェントが自分のリスクに何をもたらすか」だ。ベンチマークは、問われている問いよりも狭い問いに答えており、その隔たりは言葉にしておく価値がある。

それは確かに意味するエージェントが90分以内に、既知のビルド内で、実際のオープンソースコードにあるメモリ安全性のバグを特定し、動作するクラッシュ入力を生成し、テストを壊さずにクラッシュを止める変更を書けるということだ。それは真の能力であり、トリアージやパッチ作業に直接関係しており、有能なエージェントがアナリストのキューを有意義に圧縮する種類のタスクである。

それはエージェントがあなたのコードベースや脅威モデル、デプロイ環境を理解しているという意味ではありません。タスクは、正解となる脆弱性が既知であり、エージェントに完了したかどうかを伝えるテストスイートを備えた公開OSS-Fuzzターゲットから取られています。プロダクションコードにはそのようなオラクルはありません。また、エージェントがそのバグではなくあるバグを見つけるという意味でもありません。両者は乖離するからこそステージ4が存在するのであり、ステージ4はカウントされません。

また、それは攻撃側にはそのまま当てはまりません。攻撃側では、同じ能力でも意味合いが変わります。メモリ安全性の欠陥を特定して再現できるエージェントは、テストを許可されていないコードでもそれを行えるため、この規模の能力こそが、システムプロンプト内の免責事項ではなく、モデルレベルでのアクセス制御を促すまさにその理由なのです。

CyberGymの数値を信頼する前に尋ねるべきこと

よく書かれたレポートなら答えられ、通常はローンチ記事では答えられない5つの問い。

• どの実装ですか？ RDIのベンチマークなのか、第三者評価者によるフィルタリング済みの変種なのか。報告書に明記されていなければ、その数値は何とも比較できません。

• 誰が実施したのか？独立した評価か、提供者による自己申告か。集計表では行ごとにこれが明記されているが、ほとんどのマーケティング資料では明記されていない。

• どのハーネスで、予算はどのくらいですか？ ハーネスがベンダー自身のものであり、説明されていない場合は、その結果を特定の製品構成に関するシステムレベルの主張として扱ってください。

• ステージ4は確認されましたか？ 報告された発生率とその横に診断情報があれば、パッチがバグを修正したのか、それとも単にクラッシュを黙らせただけなのかが分かります。

• どのタスクセットですか？ 難易度に基づいて選ばれた、プロジェクトごとに1件ずつのタスク131件が一般的なセットです。フィルターが異なれば、それは別のテストになります。

Cybergymは、困難で現実的なタスクのためのよく構築されたベンチマークであり、その構築はリーダーボードよりも興味深い。各ステージはエージェントが何をしなければならなかったかを示し、フィルタリングはそのスコアが何のスコアなのかを示し、ハーネスは誰に功績があるかを示す。これら3つが付随して提示される数値は、本当に有用だ。単独で提示される数値は、パーセント記号付きのプレスリリースにすぎない。