安全性と機能性を両立する修正のベンチマーク：Snyk Agent Fixが最先端モデルの修正率を14%以上向上

概要

JavaScript、Java、Pythonの実際の脆弱なコードサンプル約150件を対象に、主要モデルが安全性と機能性を両立した脆弱性修正をどれだけ生成できるかをベンチマークしました。各モデルを単独で実行した場合と、Snyk Intelligence（新しいエージェント型Agent Fixアーキテクチャ）を利用した場合を比較しました。主な結果は次のとおりです。

• 最先端モデルは、追加機能なしでは72～75%に集中します。 Gemini 3.1 Pro、Claude Sonnet 4.6、Claude Opus 4.6は、いずれも数ポイントの範囲に収まります。安全性と機能性を両立する修正では、モデルを選んでも数値はほとんど変わりません。

• Snyk Intelligenceを使うと、同じモデルがこの水準を超えます。 Opus 4.6は74.6%から85.4%に上昇し、10.8ポイント改善しました（修正できたサンプルが14.48%増加）。差を生むのはモデルではなく、セキュリティコンテキストです。

• モデルが最も苦手とする領域で、改善幅が最大になります。 Opus単独ではPythonサンプルの64%しか修正できませんが、Snyk Intelligenceを使うと88%に達します。

はじめに

コーディングエージェントのベンチマークには、ユニットテスト生成、SWE-bench形式のバグ修正、コード補完などがあります。しかし、セキュリティチームが実際に重視するタスク、つまり既知の脆弱性を含むコードから、脆弱性を取り除き、なおかつコードが動作し続ける修正を作るタスクについて、広く使われている公開ベンチマークはありません。この2つは独立した基準です。一方を満たしてもう一方に失敗するのは、よくあるうえにコストのかかる失敗です。SQLインジェクションを取り除いてもクエリの返す内容が変わってしまえば、何の役にも立ちません。見た目は適切な修正でも、インジェクションが残っていれば、解決策のように見えるだけにさらに厄介です。

そこで私たちは、各修正について2つの基準を両方評価するベンチマークを構築し、最先端モデルを2通りで実行しました。単独で実行する場合と、Snykのセキュリティインテリジェンスを利用する場合です。私たちが知りたかったのは、端的に言えば、Snykのセキュリティコンテキストによって最先端モデルの修正能力がどれだけ変わり、どの領域で変化するのか、ということです。

要点を先に述べると、追加機能なしのモデルは72～75%付近で頭打ちになっており、Snyk Intelligenceがその壁を超える力になります。この記事では、その根拠となるデータと手法を紹介します。

測定方法：Golden Testベンチマーク

一般的なコードベンチマークでは、コードが実行できるか、またはバグ報告を解決できるかを確認します。セキュリティ修正では、セキュリティと機能の両方の基準を同時に満たす必要があり、どちらも十分ではありません。私たちの評価セットであるGolden Testsは、両方を測定できるように設計されています。SWE-benchに着想を得て、セキュリティ向けに調整しました。

評価サンプル

このセットは、実際の脆弱なコードサンプル約150件で構成されています。内訳はPythonが50件、JavaScriptが54件、Javaが39件です。各サンプルは脆弱性を1つだけ含むコードで、Snyk Codeが検出し、人間のセキュリティ専門家が確認しています。また、モデルに不足した外部コンテキストを与えなくても、提示されたコードだけで修正できるものを選びました。

評価方法

各サンプルには、人間が検証した2つのユニットテストが用意されています。

• 脆弱性が存在するために失敗するテスト。

• コード本来の機能が保たれている場合に成功するテスト（たとえば、「hello world」を返すべきヘルパー関数が、修正後も「hello world」を返す）。

合格と評価されるには、モデルは両方のテストを最初の試行で、いずれのテストも一度も見ずに成功させるコード修正を行う必要があります。モデルはユニットテストそのものを見ないため、合格は既知のテストに合わせた出力ではなく、安全性と機能性を真に両立した修正を示します。

SQLインジェクションがあるPythonのサンプルを例にしましょう。このコードはユーザー入力を連結してクエリを組み立てます。セキュリティテストではSQLインジェクションのペイロードを送り、データベースから全行が漏えいしないことを確認します。脆弱なコードはこのテストに失敗します。機能テストでは通常のユーザー名を送り、正しいレコードが返ることを確認します。元のコードはこのテストに成功します。モデルの書き換えが、テストを見ていない状態で、最初の試行からセキュリティテストに合格し、機能テストも成功させた場合にのみ修正としてカウントされます。

評価対象

評価した構成は6つです。Snykの従来の社内StarCoderベースAgent Fixモデル、追加機能なしの最先端モデル3種（Gemini 3.1 Pro、Claude Sonnet 4.6、Claude Opus 4.6）、そして新しいエージェント型Agent FixアーキテクチャでSnyk Intelligenceを利用するSonnet 4.6とOpus 4.6です。ここでいう「Snyk Intelligence」とは、動的なFew-shotプロンプティングを指します。修正時に、Snykの脆弱性データベースにある35,000件以上の脆弱性から、対象の弱点に最も関連する専門家作成の修正例を挿入します。（この手法は、同じアイデアで既製のLLMの性能を向上させた先行研究を発展させたものです。）

Snyk Agent Fixベンチマークは、従来のベンチマークとどう違うのでしょうか？

Golden Testセットは、コードに対するAI評価の基準を着実に引き上げてきた研究の流れを受け継いでいます。SWE-benchは、モデルの自己申告による妥当性ではなく、実際の非公開テストを使って評価する方法を確立しました。セキュリティ分野では、Vul4Jが再現可能な脆弱性と、その存在を証明するテストおよび機能的な回帰テストを組み合わせました。これは、失敗から成功への変化と、成功を維持することの両方を評価する私たちの設計に最も近い先例です。BaxBenchやSEC-benchなどの近年の研究も、私たちが前提とする考えを裏付けています。機能的に正しいコードでも、依然として安全でないことは珍しくありません。そのため、信頼できる修正ベンチマークでは両方の特性を同時に評価する必要があります。Golden Testセットの特徴は、3つの本番用プログラミング言語を対象に、人間が検証した実際のサンプルを使い、テストをモデルに見せずに両方の基準で評価する点です。

結果

主な指標は、修正が安全性と機能性の両方を満たしたGolden Testsの割合です。

グラフ1：機能性と安全性を両立した修正率

追加機能なしのモデルは3ポイントの範囲に収まっています。同じモデルにSnyk Intelligenceを加えると、8～11ポイントの差が生まれます。Opus 4.6は74.6%から85.4%に上昇します。

Opusの結果を言語別に見ると、改善は平均値だけのものではないことがわかります。テストしたすべての言語で効果があり、追加機能なしのモデルが最も苦手とする領域で最大の改善が見られます。

グラフ2：言語別の改善幅

最も顕著なのはPythonです。Opus単独ではサンプルの64.0%を修正できましたが、Snyk Intelligenceを使うと88.0%に上昇します。Opusがもともと高い性能を示したJavaScriptとJavaでも、それぞれ5～6ポイント改善しました。

数値が示すこと

安全性と機能性を両立する修正では、モデルの規模を大きくしても性能は頭打ち

追加機能なしの3モデルは72.4%から74.6%の範囲で、2社のモデル間の差は2.2ポイントでした。このタスクでモデルの大型化や新しさが決め手になるなら、この結果にも差が表れるはずです。しかし、そうはなりません。このタスクの難しさは、より汎用的な能力を高めても直接解決しません。モデルには、もっともらしいコードを書くだけでなく、この弱点を安全に修正する方法を知る必要があるのです。

決め手となるのは、より大きなモデルではなくセキュリティコンテキスト

同じOpus 4.6が、修正時に注入するセキュリティ関連の例だけで10.8ポイント（サンプル数で14.48%）改善しました。この手法はモデルに依存しないため、基盤となる最先端モデルの性能向上は、このコンテキストと競合するのではなく、相乗効果を生みます。長期的な価値を持つ資産は、専門家が作成した35,000件以上の修正例です。モデルは業界の進歩に合わせて交換できる構成要素であり、そのため現在の本番環境のAgent Fixでは、Snyk IntelligenceとClaude Opus 4.7を組み合わせています。

モデルが最も苦手とする領域で、改善幅が最大

Opus単独では、最も苦手なPythonサンプルの64%しか修正できませんでした。Snyk Intelligenceを使うと88%に達し、3言語の中で最も大きな改善となりました。セキュリティコンテキストは平均値を上げるだけでなく、最低水準を引き上げます。

追加検証でも結果を確認

OpusとSnykを組み合わせた数値は、2回の実行結果（84.6%と86.0%）の平均です。そのため、主要数値の85.4%は、実行をまたいだ安定した性能を示しています。このセットでの実行ごとの変動はおよそ1ポイントです。構成間の差が1～2ポイントの場合は、その点を考慮する必要があります。

次回予告：Snyk VulnBenchとコーディングエージェントによる脆弱性検出

脆弱性を修正するには、まず発見しなければなりません。2026年6月、私たちはSnyk VulnBench JS 1.0の論文を公開しました。この論文では、まずコード内の脆弱性を検出するうえで、決定論的かつ高速なSASTエンジンであるSnyk Codeと、コーディングエージェント（Claude Codeのハーネス）を活用するLLMを比較し、ベンチマークすることを目指しました。

Snyk VulnBenchの調査結果から、Claude Opus 4.7の最大推論レベル（いわゆるmax）のような最先端の大規模言語モデルでも、高度なコーディングエージェントハーネス（Claude Codeそのもの）を利用した場合でさえ、再現性と決定性に課題があることがわかりました。主な結果は次のとおりです。

• あるケースでは、モデルとコーディングエージェントが報告した結果の約50%が、その後の5回の実行のうち4回で再現されず、エージェント型開発者やAIセキュリティエンジニアに誤検知のバックログと脆弱性疲れをもたらしました。

• 別のケースでは、コーディングエージェントの13%が、対応するものがない脆弱性を5回すべての実行で報告しました。その結果、セキュリティ上の課題のバックログには誤検知の可能性がある項目が増え、さらに混乱や認知的負荷が生じます。

Snyk VulnBenchのデータセットをぜひご覧ください。レビュー用にオンラインで公開しています。https://vulnbench.com/

制約事項

この結果を参考にする前に、読者が考慮すべき制約は4つあります。

1. サンプル数：約150件（Python 50件、JavaScript 54件、Java 39件）で明確な傾向は確認できますが、小さな差の統計的有意性を主張するには十分ではありません。StarCoderのベースラインは、約20%少ないサンプルで実行しました（学習データが存在するAgent Fix対応ルールのみ）。全ルールを対象とした場合のスコアは54.9%です。これはSnyk社内のファインチューニング済みモデルであり、最先端モデルのベースラインではなく、参考値として掲載しています。

2. アプリケーション全体ではなく、コードスニペット単位：各サンプルは脆弱性を1つ含む単一ファイルで、ローカルのコンテキストだけで修正できます。実際のコードベースにはファイルをまたぐコンテキストや、相互に影響する複数の問題がありますが、このベンチマークでは評価していません。

3. 対象言語は3つ：JavaScript、Java、Pythonをベンチマークしました。新しいアーキテクチャはSnyk Codeがサポートするすべての言語に対応していますが、現在Golden Testが用意されているのはこの3言語です。

4. 変動を評価する実行回数が限定的：Snykで強化した構成は2回の実行結果を集計しました。各項目について正式な誤差範囲を示すには、反復回数が不足しています。2ポイント未満の差は概算としてお考えください。

これらの制約を明記するのは、結果を否定するためではなく、どの主張をどの程度参考にすべきか判断できるようにするためです。Snyk Intelligenceによる10ポイント超の差は実行ごとのばらつきを大きく上回りますが、小さな差の言語別の順位はそうではありません。

今後の展望

• 対応言語の拡大：Golden TestセットをJavaScript、Java、Python以外にも拡大し、ベンチマークをアーキテクチャの全言語対応に合わせます。

• 変動の定量化：各構成を十分な回数実行し、2回の平均ではなく適切な誤差範囲を公表します。

• 修正だけでなく検出も評価：このベンチマークは修正を評価します。別の取り組みでは、エージェントがSnyk Codeと比べてどれだけ脆弱性を発見できるかを測定しており、その結果は別途報告します。

新しいエージェント型Agent Fixの展開が始まり、Snyk IntelligenceとClaude Opus 4.7を組み合わせています。皆さんのコードで、安全性と機能性を両立した修正を試してみませんか？Snyk CodeとAgent Fixを始めて、これらの数値を生み出したエンジニアリングについて詳しく知る。

Play Video: Can You Trust AI Code? I Built a Scanner to Find Out

AIが書いたコードは信頼できる？確かめるためにスキャナーを作ってみた

付録：方法論と集計

評価方法: 各ゴールデンテストは、脆弱性を1つだけ含むコードサンプルと、セキュリティユニットテスト（脆弱なコードでは失敗）および機能ユニットテスト（元のコードでは成功）で構成されます。テストをモデルに見せず、最初の試行で修正が両方のテストに合格した場合にのみ、その設定でサンプルを修正できたと判定します。

集計方法: 報告される修正率は、修正できたサンプルの割合です。

• 以前のモデル（StarCoder）の72.4%という数値は、言語ごとの修正率の平均であり、Agent Fixがサポートするルールのみを対象としています。すべてのルールを対象にすると、54.9%に低下します。

• Opus 4.6 + Snyk Intelligenceの85.4%という数値は、複数回の実行における平均です（1回目 = 86.0%、2回目 = 84.6%）。2つ目のグラフに示す言語ごとの数値は、代表的な1回の実行によるもので、複数回の実行を集計した数値より平均がわずかに高くなっています（約86%）。引用する際は、複数回の実行を集計した数値を使用してください。

設定: StarCoder（以前のAgent Fixモデル）、Gemini 3.1 Pro、Claude Sonnet 4.6、Claude Opus 4.6を使用。それぞれ、エージェント型のAgent Fixアーキテクチャで、標準状態の場合とSnyk Intelligenceを使用した場合を比較しました。ここでのデータはOpus 4.6で収集しましたが、本番環境のAgent Fixはその後Claude Opus 4.7に移行しています。Snyk Intelligenceは、生成時に特定の弱点に対する専門家作成の修正例を組み込みます（動的なfew-shotプロンプティング）。