360 CyberGymの結果：Tulongfeng、脆弱性再現率99.4%を主張
360によると、同社のセキュリティシステムTulongfengは、過去のソフトウェアバグを基にした評価であるCyberGymにおいて、脆弱性再現の成功率約99.4%を達成した。360 CyberGymの結果は、2026年10月30日付の報道で取り上げられた。これは未知の脆弱性を発見する一般的な成功率ではなく、定義されたタスクにおける上限に近いスコアを示すものだ。
この違いは、OpenAI、Anthropic、Googleのモデルを基盤とするエージェントと専門システムを比較するセキュリティチームにとって重要である。特定済みのバグを再現するには、大規模なエンジニアリング作業が必要となる。一方、未知のアプリケーションから明示されていない欠陥を探す作業は、別種の課題だ。前者での強い結果は注目に値するが、それを後者に関するあらゆる主張の根拠とするべきではない。
中心となる論点は、ほぼ完全な再現スコアがどれだけの運用上の価値を裏付けるかである。購入者には、ベンチマークでの成功実行と、自社環境で信頼できる調査とのつながりを示す証拠が必要だ。360にとっては、透明性のある評価詳細と検証可能なセキュリティ成果を通じて、その関係を実証する機会となる。
360 CyberGymの結果が実際に示すこと
報告された結果は既知の脆弱性の再現に関するものであり、正確な評価日は依然として不明である。
10月30日に公開されたXinhuanetの記事で、中国網に帰属するvulnerability reproduction reportは、Tulongfengの性能を紹介した。同記事は、3つの評価における成功率として99.27%、99.47%、99.40%を報告している。全1,507タスクを対象とした平均値は99.38%とされた。
これにより、この話題の公開日は検証できる。しかし、テストの終了時期やリーダーボードの順位が更新された時期までは確定しない。記事は結果を最近のものとして記述しているが、これらの日付は示していない。そのため読者は、10月30日を確認済みの評価上の節目ではなく、報道日として扱うべきである。
記事はTulongfengをリーダーボードの首位とも呼んでいる。この順位に関する主張は、報告された数値とは分けて扱う必要がある。公開されているベンチマークページから取得できた情報には、Tulongfengの順位や構成を独自に確認するのに十分なエントリーは含まれていなかった。したがって本分析では、スコアと首位の主張の双方を報道に帰属させる。
ベンチマーク結果には複数の証拠層がある。公開された発表は、誰かが何を報告したかを示す。詳細な提出資料は、評価がどのように行われたかを説明する。独立した再現は、別のチームが同等の結果を得られるかを検証する。これらの層は異なる問いに答えるものであり、同じ発表を複数のウェブサイトで公開しても、その代替にはならない。
用語の扱いにも注意が必要だ。脆弱性再現とは、指定されたソフトウェア上の欠陥を実証する入力を生成することを指す。発見とは、その存在や場所があらかじめ示されていない欠陥を特定することだ。再現スコアを発見率として表現することは、評価が直接測定している範囲を超えて主張を拡大することになる。
ニュースフィードでこの見出しを目にした読者にとって、これが本質的な訂正である。この発表は、明確な出発点を持つ自動化セキュリティ調査タスクに関するものだ。Tulongfengが任意のソフトウェアにあるほぼすべての脆弱性を見つけること、あるいは導入先の顧客が同等の結果を得られることを示すものではない。
このより限定的な解釈でも、重要な進展は残る。報告された性能が文書化された条件下で維持されるなら、Tulongfengは既知のバグ記述を実行可能な証拠へ変換する非常に高性能なシステムとなるだろう。こうした作業は、報告を受け取ることと、どのエンジニアリング対応が妥当かを判断することの間で、実用的な位置を占める。
重要性は、そのつながりにある。セキュリティシステムは、その出力が問題の検証、範囲の理解、防御可能な判断に役立つときに有用となる。スコアはその有用性を評価する入口であり、それを完全に説明するものではない。
既知のバグはセキュリティエージェントに明確な出発点を与える
CyberGymは要求の厳しい調査タスクを測定するが、自由形式の発見ではまず見つけなければならない情報を提供している。
公式のCyberGym evaluationによると、主要なLevel 1設定では、脆弱性の説明と未修正のコードベースが提供される。概念実証、すなわちPoCとは、指定された欠陥を実証する実行可能なテストである。成功には、そのテストが脆弱なバージョンでは欠陥を発現させ、修正版では問題を起こさないことが求められる。
これは意味のあるエンジニアリング上の課題を生む。エージェント、すなわちソフトウェアツールを通じて行動するモデル駆動型システムは、文章による説明を実際のプログラム挙動へ結び付けなければならない。その出力は実行ベースの検証に耐える必要がある。もっともらしい説明だけでは、このタスクを満たせない。
ただし、提供される説明は探索問題を変化させる。システムは、関連する脆弱性が存在するという証拠を持って調査を始める。その前提を基に調査を組み立てられる。自由形式のレビューでは、どこを探すか、どの不審な挙動が重要か、追加調査にさらなるリソースを投じるべきかも判断しなければならない。
開発者の視点から違いを考えてみよう。具体的なバグ報告は、特定の挙動を調べる理由を与える。大規模なアプリケーションを広く評価してほしいという依頼は、制約が少ない。どちらにも判断は必要だが、その判断が調査の異なる段階に置かれる。
この違いは、報告された結果がセキュリティベンダーに圧力をかけながらも、市場全体の結論を決めない理由を説明する。自動調査を販売する提供者は、比較可能な条件下で自社システムが同じく説得力のある証拠を生み出せるかという具体的な問いに直面する。広範な発見を約束する提供者は、有用な出発点を見つけることに関する、より広い問いに向き合うことになる。
どちらのグループも、流暢な説明だけでこれらの問いに答えることはできない。脆弱性を正確に説明するシステムでも、関連する挙動を示す必要がある。反対に、説明されない失敗を出力するシステムは、エンジニアに追加の解釈作業を残す。有用な自動化は、仮説、テスト、観測された挙動、結論をつなぐ。
ベンチマークの限定されたタスクは、購入者が能力とカバレッジを分ける助けにもなる。能力とは、システムが特定の調査を完了できるかを問うものだ。カバレッジとは、どのアプリケーション、環境、脆弱性クラスを評価できるかを問う。高スコアは評価範囲内での能力主張を支えるが、カバレッジには追加の証拠が必要となる。
この区別は調達に関する議論に影響を与えるべきである。購入者は、システムが信頼性高く完了できる作業をベンダーに説明するよう求めるべきだ。「報告されたソフトウェア脆弱性を再現する」という表現は、自律型セキュリティに関する広範な主張よりも明確な約束を伝える。また、エンジニアが直接評価できるタスクをパイロットプロジェクトに与えることにもなる。
したがって、運用上の意味合いは具体的だ。自動化が再現作業を信頼性高く完了できれば、アナリストは報告が観測可能な問題を示しているかを確立するための労力を減らせる。残る作業には、影響の評価、担当者の調整、提案された対応のレビューが含まれる。初期の技術調査が改善されても、これらの責務は重要であり続ける。
360はスコアの背後に専門的な連携を置く
Tulongfengの報告された設計は、連携したセキュリティ作業を重視しており、システムアーキテクチャ自体が主張の一部となっている。
10月の報道は、セキュリティに特化した言語モデルが専門エージェントと連携する仕組みを説明している。この説明によれば、異なる役割が仮説の構築から検証まで、調査を複数の段階に分割する。提案される利点は、セキュリティ知識、ツール、連携を組み合わせる点にある。
これはシステムレベルの命題である。モデルがコードについて推論する能力は重要だが、その周囲のプロセスも同様に重要である。周辺ソフトウェアは、モデルが受け取る証拠、実行できる行動、不成功の試行をどう処理するかを決定する。こうした選択は最終的な結果に影響する。
専門化にはもっともらしい根拠がある。関連コードの特定に集中する役割は、仮説をテストする別の役割に証拠を提供できる。検証役は、観測された挙動が元の主張を裏付けるかを評価できる。原理的には、責務を分割することで複雑な調査を管理しやすくなる。
ただし、この説明はTulongfengが報告されたスコアを得た理由についての検証済みの説明ではなく、根拠の提示にとどまる。報道には、各コンポーネントの寄与を切り分けるための十分な統制比較がない。連携、モデル訓練、ツール、リソース配分のどれが最大の改善をもたらしたかを確定することはできない。
有用な対比として、清華大学のRedbudAIの研究がある。同研究が公開したsingle-model evaluationでは、GLM-5.2を用いた成功率は86.2%と報告され、別の反復試行分析では93.6%に達した。著者らは、これらの測定値を互換的な結果として提示するのではなく、区別している。
RedbudAIは、ローカル実行、制限されたネットワーク、各タスクに指定された最終テストについても説明している。これらの詳細により、結果はより解釈しやすくなる。Tulongfengとの統制比較を確立するものではないが、この数値の背後にある運用条件を明らかにしている。
この比較は、より広範な分析上の問題を示している。単一モデルのシステムにも、ツールや調査ステップを編成するソフトウェアであるオーケストレーションが相当程度含まれ得る。マルチエージェントシステムでも、その役割がどの程度独立して動作するかには大きな差がある。ラベルだけでは、購入者に実際に行われる作業をほとんど伝えない。
したがって、Tulongfengの報告された首位だけでは、専門エージェントチームが他の設計より普遍的に優れていることは示せない。それを確立するには、ほかの条件を比較可能に保つ必要がある。こうした統制がなければ、この結果が示すのは完全な構成の性能である。
同じ慎重さは、OpenAI、Anthropic、Googleとの比較にも当てはまる。専門のセキュリティシステムと、エージェントフレームワークに接続された汎用モデルは、異なる評価対象である。基盤モデルについて結論を導く前に、いかなる比較でも完全な構成を特定すべきだ。
開発者にとっては、これにより段階間で受け渡される証拠に注意が移る。調査担当は元の仮説を保持しているか。検証担当は関連する実行結果を確認しているか。別のエンジニアが推論を再構築できるか。これらの問いは、エージェント数よりも直接的にアーキテクチャと実用上の信頼を結び付ける。
ここに360の技術的なストーリーの興味深さがある。同社の主張は、セキュリティ専門知識がワークフローにどのように組み込まれ、連続する判断を通じてどのように維持されるかの検証を促す。詳細な公開資料があれば、再現可能なエンジニアリング上の優位性と、魅力的なアーキテクチャの説明を区別しやすくなる。
上限に近いスコアほど評価の詳細が重要になる
最大値に近い結果では、採点ルール、リソース制限、再現可能な証拠の重要性が高まる。
CyberGymの運営者は、チームが自ら結果を評価して提出すると注意を促している。また、強力なシステム間の小さな差が、必ずしも意味のある能力差を表すわけではないとも警告している。こうした留保は、読者が首位に関する見出しをどう解釈すべきかに直接影響する。
高い性能水準では、順位だけで説明できることには限界がある。購入者は、システム間でタスク成功率、リソース使用量、信頼性、評価条件にどのような差があるのかを理解する必要がある。わずかな数値上の優位性が、重要な運用上の不利と共存する場合もある。一方で、詳しく検証すべき実質的な改善を反映している可能性もある。
公式の提出要件も、この問題を認識している。成功率に加えてコストの報告を求め、モデル使用量、タスク所要時間、ログ例、最終結果の提出を要請している。こうした開示は、作業を完了するために実際に何が必要だったのかを明らかにする助けとなる。
企業の購入者にとって、セキュリティ調査はエンジニアリング上の期限と競合するため、所要時間は重要だ。構成が利用可能なインフラに収まらなければならないため、リソース使用量も重要である。時折発生する長時間タスクがスケジューリングを複雑にする可能性があるため、ばらつきも重要となる。これらはいずれも高い成功率を否定するものではなく、その実用的価値を左右する要素である。
採点ルールにも同等の注意を払うべきだ。CyberGymの最終提出ルールでは、システムが最終回答を指定することを求めている。代わりに、成功した候補のいずれかに評価を与えるなら、それは別の問いに答えることになる。調査中にシステムが複数の候補を生成する場合、この違いは重要になる。
正しい出力を選ぶこと自体が有用な能力である。エンジニアには、説明のない試行の集まりを探し回らずに行動へ移せる結果が必要だ。最終的に有効な証拠を生成できるシステムであっても、その証拠を認識し、提示する信頼できる方法が必要になる。
報告された3回の評価には、方法論上の疑問も残る。評価を繰り返すことで一貫性を測定できる一方、1つのタスク内で機会を繰り返すことは成功指標を変えうる。対象となった報道では、Tulongfengについてこの関係を十分に説明していない。詳細な文書化があれば、実行間で何が一定だったのかが明確になるだろう。
ここで「独立」という言葉は慎重に扱うべきだ。別々の実行が、必ずしも別個の外部評価者を意味するわけではない。確認した報道は、外部の研究所が結果全体を再現したとは示していない。読者は、繰り返し評価の記述だけから独立監査を推測すべきではない。
ネットワークアクセスも、比較上の別の問題を生む。過去の脆弱性について、すでに修正や解説が公開されている場合、公開情報へのアクセスは近道をもたらす可能性がある。これは360の不正行為を示す証拠ではなく、ベンチマーク全般に関わる懸念だ。透明性のあるアクセス方針は、結果が意図したタスクを反映しているかをレビュー担当者が判断する助けとなる。
その他の構成上の選択も解釈を左右する。実行可能な脆弱アプリケーションは、ソースコードの確認だけとは異なるフィードバックを提供する。タスクをまたいで蓄積されるメモリは、後続の調査にシステムが持ち込む情報を変える。読者が同等の条件で比較できるよう、文書にはこうした選択を明示すべきである。
こうした未解決の詳細は、慎重な結論を支持する。360のCyberGym結果は技術的な注目に値するが、決定的な優位性を主張するには、さらに多くの証拠が必要だ。方法論に関する不確実性は、根拠のない非難になったり見出しの下に埋もれたりするのではなく、続報の方向性を導くべきである。
企業価値は再現後に何が起きるかに左右される
商業上の問いは、調査の成功がセキュリティ判断を下し実装するために必要な作業を減らすかどうかである。
再現された脆弱性は、エンジニアリングチームに具体的に検証できる対象を与える。研究者、保守担当者、アプリケーション所有者の間のコミュニケーションを支えることもできる。しかし組織はなお、影響を受けるコードが自社環境に存在するか、どの対応が妥当かを判断する必要がある。
たとえば、ソフトウェア依存関係に関する報告を評価する仮想的なチームを考えてみよう。システムは、準備された環境でその挙動を再現できるかもしれない。その後チームは、導入済みのバージョンと利用方法が同じ問題にさらされているかを確認しなければならない。この評価は、技術的な結果と運用上の関連性を結び付ける。
次の判断は、セキュリティ問題を除去または軽減する作業を意味する修正対応に関するものだ。提案された修正にはレビューとテストが必要になる。チームはデプロイ上の制約や意図しない挙動も考慮しなければならない。再現はこのプロセスにとって価値ある証拠だが、すべての段階を完了させるものではない。
これが、ベンチマークのカテゴリーが重要である理由だ。CyberGym-E2Eと呼ばれる別のエンドツーエンド・ベンチマークは、脆弱性の発見、概念実証の生成、パッチ生成を対象とする。そのより広い範囲は、防御ライフサイクル全体を評価する際に必要となる追加作業を浮き彫りにしている。
この広範な評価は、再現の重要性を下げるものではない。むしろ、タスク間の境界を示している。組織は、発見やパッチ適用を委任せずとも、優れた再現支援ツールから恩恵を受けられる可能性がある。明確な境界があれば、チームは適切なレビューを維持しつつ、有用な能力を導入できる。
10月の報道では、Tulongfengの導入実績や脆弱性発見についても、より広い主張がなされている。それらの主張には、それぞれ独自の裏付け証拠が必要だ。顧客の参加、確認済みの発見、完了した修正対応は、それぞれ異なる種類の成果である。それらを効果性についての単一の印象にまとめるべきではない。
購入者にとって最も有益な証拠は、発見事項とその解決を結び付けるものだろう。その問題は責任を負う保守担当者によって確認されたのか。調査は修正に十分な文脈をもたらしたのか。受け取ったチームはその結果を再現できたのか。これらの問いは、自動化が組織の境界を越えて有用な作業を引き渡せるかを検証する。
また、隠れた人的作業を明らかにする助けにもなる。システムは、大規模な環境準備や専門家の介入を経た後に優れた性能を示すかもしれない。そのような支援は完全に正当な場合がある。購入者が理解すべきなのは、どの責務が自社スタッフに残るのかという点だ。
この引き継ぎでは、ナレッジ管理が重要になる。エンジニアは、元の報告、環境の詳細、再現メモ、レビュー判断を結び付けた状態で保持する必要がある。検索可能なエンジニアリング・ナレッジベースは、セキュリティシステムの技術的能力とは別に、この文書化のニーズに対応する。
このつながりは、調査の担当者が変わるときに重要となる。元の運用者だけが理解できる結果は、追加の作業を生む。文書化された結果なら、別のエンジニアが前提を確認し、対応を継続できる。したがってトレーサビリティは、自動化された成功と並んで運用価値を論じる際に含めるべき要素である。
企業にとっての示唆は明確だ。セキュリティベンダーには、完全でレビュー可能な作業単位を示す圧力が高まっている。360にとって、強力な再現性能は信頼できる出発点となるだろう。信頼できる引き継ぎと解決済みの発見に関する証拠があれば、その能力が日常的なセキュリティ運用にどこまで及ぶのかが示される。
結果を明確にする3つのシグナル
次に有用となる証拠は、提出された構成、その効率性、そして過去の再現を超えた成果に関するものである。
第一に、報告されたスコアを特定のベンチマーク構成と結び付ける、詳細なTulongfeng評価リリースに注目したい。そこではモデル、ツールアクセス、採点ルール、代表的な調査記録を特定すべきだ。これにより、報告された結果が正確には何を示すのかを読者が理解できるようになる。
明確なリリースは、主張の範囲に対する信頼を高める。また、外部レビューをより実行しやすくする。文書化が見出しのパーセンテージにとどまるなら、信頼もそれに応じて限定的であるべきだ。説明文書がなければ、報告された結果が誤りだと証明することなく、疑問は未解決のまま残る。
第二に、360および他のセキュリティエージェント開発者による、比較可能な効率性の開示に注目したい。タスク所要時間、モデル使用量、リソース要件は、異なるシステムがどのように結果を得るのかを明らかにする。これらの測定は、購入者がタスク完了と並べて運用上の適合性を評価する助けとなる。
レビュー可能な証拠を一貫して生成する効率的なシステムは、より強い導入根拠を支えるだろう。広範なリソースを要する構成も、専門的な調査には適している可能性がある。重要なのは、すべての高得点システムが同じ導入カテゴリーに属すると想定するのではなく、そのシステムがどのようなワークロードに対応するのかを特定することだ。
第三に、過去の評価対象外のソフトウェアで文書化された発見と修正対応の成果に注目したい。保守担当者による確認、再現可能な証拠、完了した修正は、より広範な発見に関する主張を具体的に裏付ける。明確な報告では、新たに特定された問題と、既知の問題の再現または派生形を区別すべきである。
これらのシグナルは、今後数か月の報道を導くべきだ。セキュリティ自動化を誰が支配するかについて予測することなく、Tulongfengの報告された性能に関する解釈を強めたり限定したりできる。目下のニュースは、主張そのものと、その背後にあるエンジニアリング手法である。
開発者やセキュリティ購入者は、ワークフローを変える前に証拠を精査するきっかけとして、360 CyberGymの結果を活用してほしい。システムがどのタスクを完了したのか、どの情報を受け取ったのか、レビュー担当者が最終出力をどのように確認したのかを問うべきだ。そして、その答えを自社チームが実際に完了させる必要のある調査と結び付ける。報告されたスコアは、その構成、制約、裏付け記録と並べて扱う。詳細な成果物や確認済みの発見が利用可能になった時点で、その評価を見直す。ベンダーを比較しているなら、それぞれに同じ開示を求めよう。どのシステムが、エンジニアにとって独自に理解、再現し、セキュリティ問題の解決に活用できる結果を残すのだろうか。
