Claudeの脆弱性パッチは、メンテナーのテストで評価すると見かけほど強くない
新たな研究で、Claudeによる脆弱性パッチはクラッシュベースのチェックの90.2%を通過した。一方、メンテナーが作成したテストを通過したパッチは60.7%にとどまった。この29.5ポイントの差は、一見した成功の意味を変える。悪意ある入力によるプログラムのクラッシュを1件防いだからといって、根本の脆弱性が正しく修正されたとは限らない。
Northwestern Universityの研究者であるDang K Le、Wenxuan Shi、Xinyu Xingは10月7日、この結果を報告した。ベンチマーク信頼性に関する研究では、84件のオープンソースプロジェクトに含まれる過去のバグ112件を調査した。データセットはC、C++、Go、Rustのソフトウェアを対象としている。
この論文は、AIコーディングエージェントの評価に使われるスコアリングシステムに疑問を投げかける。多くのベンチマークでは、概念実証（PoC）が報告された障害を発生させなくなれば、パッチに評価を与える。だが、メンテナーは通常、さらに多くを期待する。修正には意図した動作の維持、根本原因への対処、元の報告では検証されなかった近接入力への耐性が求められる。
この乖離は、モデル開発者、ベンチマーク設計者、企業のセキュリティチームに圧力をかける。Claudeをはじめとするコーディングエージェントは、可視化されたテストを満たす能力を高めている。しかし、その進歩がアップストリームのメンテナーに受け入れられるパッチへ同程度につながっていることは、証拠からは示されない。
Claudeの脆弱性パッチスコアは、二つの異なる結果を覆い隠している
この研究は、クラッシュテストの通過と受け入れ可能なセキュリティ修正の作成は同等の達成ではないと示した。
研究者らは、基盤となるClaudeモデルだけを変更しながら、同じ112件をOpenCodeエージェントで実行した。Claude Sonnet 4.0、Sonnet 4.5、Opus 4.7をテストした。各実行にはビルドとテストの指示を与えたが、PoCの本文は提供しなかった。
Sonnet 4.0は、提供されたPoCを77.7%のケースで阻止した。Sonnet 4.5は84.8%、Opus 4.7は90.2%に達した。この推移だけを見ると、自動脆弱性修復は飽和に近づいているように見える。
メンテナー志向の結果は異なる様相を示した。Sonnet 4.0が開発者テストを通過したのは43.8%のケースだった。Sonnet 4.5は48.2%、Opus 4.7は60.7%に達した。
したがってOpusは両方の指標で改善したが、二つの指標の差は依然として大きい。PoCを通過したOpusのパッチのうち、32.7%はなお開発者テストで失敗した。これは見かけ上の成功のおよそ3件に1件に当たる。
研究者らは、従来テスト済みの動作が引き続き機能するかを確認する通常の回帰テストも測定した。Opus 4.7はこれらのテストを94.6%のケースで通過した。この高い結果によっても、大幅に低い開発者テストのスコアは解消されなかった。
新しいセキュリティ修正の背後にある正確な設計判断を、古い回帰テストスイートがコード化していることはまれである。そのため、報告された障害に近い表層的な修正を見逃しながら、既知の動作が維持されていることだけを確認する場合がある。
この研究で使われた開発者テストは、アップストリームの修正コミットから取得された。各バグを修正した際にプロジェクトの開発者自身が書いたユニットテストまたは統合テストである。研究者らはこれらの追加分を再構築し、AIエージェントがパッチを生成した後に適用した。
この手法は、生成されたコードが脆弱性周辺でメンテナーの意図どおりに振る舞うかを問う。AIにメンテナーのパッチ文面を再現させるものではない。プロジェクトで受け入れられたセマンティクスに動作が一致すれば、別の修正でも通過できる。
データセットには四つの連続するゲートも設定された。パッチ適用後のプロジェクトは、ビルドに成功し、繰り返し実行してもPoCを抑止し、既存の回帰テストスイートを通過し、追加された開発者テストにも通過する必要があった。すべての段階を通過して初めて、ケースは完全に解決されたと数えられた。
公開された評価分析は、実務上のリスクを捉えているとして、3件に1件の失敗率に焦点を当てた。魅力的な見出しのスコアは、受け入れられたパッチの多くがメンテナーの意図に最も近いテストで失敗していても維持されうる。
これは、Opus 4.7がセキュリティ作業で有効でないことを示すものではない。報告される能力が、ベンチマークが何を成功と呼ぶかに大きく依存することを示している。モデルやそのパッチを変えずとも、採点ルールによって結論は変わりうる。
クラッシュを止めることは、バグを修正することと同じではない
PoCは一つの障害が消えた証拠であって、有効な動作範囲全体で脆弱な挙動が修復された証明ではない。
概念実証は通常、脆弱性を再現する入力を提供する。メモリ安全性のバグであれば、サニタイザーによるクラッシュを引き起こす場合がある。ロジック上の欠陥なら、無効な状態や禁止された操作を示すかもしれない。
この種の入力は、障害を具体的かつ再現可能なものにするため価値がある。しかし、プログラム内の経路を一つ示すにすぎない。エージェントは、影響を受けた関数を支配するより広い契約を理解しなくても、その経路を塞ぐことができる。
Northwesternの論文は、range()関数に関わる過去のPHPバグでこの問題を説明している。混在する入力型が誤って分類され、PHPが非文字列値を文字列であるかのようにアクセスする結果となった。提供されたある入力はクラッシュを引き起こした。
防御的なパッチは、混在型を直ちに拒否することでクラッシュを止められる。これはPoCを満たし、過去にテストされた多くの動作も維持するだろう。しかし、PHPが変換するべき有効な混在数値・文字列入力まで拒否してしまう。
アップストリームの修正は、その意図された動作を維持しつつ、誤った分類ロジックを変更した。開発者は近接する有効入力のテストを追加し、実際の修正と制限的な回避策を区別した。
これが採点における中心的な問題である。クラッシュする入力だけをチェックするベンチマークは、両方のパッチに同じスコアを与える。メンテナーテストは、サポートされる動作をエラーへ変えてしまうパッチを拒否する。
セキュリティエージェントには、評価者が観測できるものを最適化する強い誘因がある。クラッシュが主なオラクルである場合、クラッシュ箇所の近くにガードを追加することは合理的な対応になりうる。オラクルとは単に、出力が正しいかを決定する仕組みである。
そのようなパッチは、緊急の緩和策としては有用かもしれない。しかし、完全な修正と自動的に見なすべきではない。この運用上の違いは、コードレビュー、デプロイ判断、自律システムに与えられる信頼に影響する。
この問題は、自動プログラム修復の分野ではすでによく知られている。統計モデルが学習データに過剰適合しうるように、パッチもテストスイートに過剰適合しうる。根底の要件を捉えず、利用可能な例だけを満たすのである。
セキュリティでは、この誤りのコストが高い。表層的なパッチは誤った安心感を生み、目に見える症状を抑え、あるいは欠陥を未テストの経路へ移す可能性がある。その結果、レビュアーは自動化された成功ラベルが付いたコードに費やす時間を減らすかもしれない。
関連するパッチ検証研究は、20プロジェクト209件を対象とするPVBenchを導入した。同研究の研究者らは、基本テストで受け入れられたパッチの40%以上が、開発者の修正に基づいて追加されたテストで失敗したと報告した。
二つのデータセットと評価設計は異なるものの、この独立した結果はより広い懸念を裏付ける。繰り返し得られる教訓は、基本的な機能チェックと単一のエクスプロイト入力では、重要な動作が測定されないということだ。
したがって、Claudeによる脆弱性パッチは階層的な能力として解釈すべきである。モデルは原因を特定し、正しいロジックを変更し、正当な動作を維持し、新たな弱点を避けなければならない。クラッシュの停止が検証するのは、その連鎖の一部にすぎない。
ベンチマーク設計は、パッチを改善せずにスコアを動かしうる
プロンプトの詳細、ツールアクセス、テスト表現は、開発者との整合性がほとんど改善しなくても、測定上の性能を高めうる。
Northwesternの研究者らは、ビルド指示が同じモデルとデータセットに与える影響をテストした。詳細なビルドおよびテストコマンドを付与した場合、Sonnet 4.0はPoCの77.7%を通過した。指示がない場合は74.1%だった。
全体の差は小さく見える。しかし、言語レベルでの結果ははるかに大きかった。CおよびC++のケースでは、指示の提供によってPoC通過率は72%から92%へ上昇した。
そのグループにおける開発者テストの性能は、28%から36%への上昇にとどまった。全言語では、41.1%から43.8%へ増加した。より良い指示は主に、エージェントによるテストハーネスの操作と可視的な結果の確認を助けた。
この結果は、指示が不当だという意味ではない。人間のエンジニアも文書化されたビルドコマンドから恩恵を受ける。つまり、情報量が開示されない限り、異なるベンチマークのスコアを安全に比較することはできないということだ。
プログラミング言語の慣習も変数を加える。GoとRustのプロジェクトでは、ビルドやテストのための予測可能なコマンドが用意されていることが多い。CおよびC++のリポジトリでは、ビルドシステム、フラグ、ラッパー、プロジェクト固有の手順がより幅広く混在する。
これらのコマンドを発見できないエージェントは、パッチが意味のある評価を受ける前に失敗スコアを与えられる可能性がある。逆に、慎重に準備されたプロンプトはセットアップ作業を取り除き、同じモデルを大幅に有能に見せうる。
PoCの表現も、別の大きな差を生んだ。62件のGoケースでは、ソースレベルのPoCをエージェントに提示すると、クラッシュテストのスコアは69.4%から95.2%へ上昇した。開発者テストの性能は41.9%から48.4%へ移動した。
ソースハーネスは、実行されるAPIと問題のある呼び出しの形を明らかにした。この文脈は、エージェントが可視的なテストに合わせるのを助けた。しかし、メンテナー志向の指標での改善ははるかに小さかった。
25件のCおよびC++ケースでは、不透明なバイナリまたはテキスト入力を公開してもPoCスコアに差はなかった。92%のままだった。開発者テストのスコアも36%のままだった。
どちらのベンチマーク構成も、エージェントにPoCを与えていると正しく主張できる。しかし、エージェントに同等の情報を与えているわけではない。一方は実行可能な意図を示し、もう一方は意味を推測しなければならない入力ファイルを提供する。
ツールアクセスは、より直接的な汚染リスクをもたらす。過去の脆弱性には、公開されたIssue、アドバイザリー、アップストリームのパッチが存在することが多い。Webアクセスを持つコーディングエージェントは、Issue番号を検索し、受け入れられた修正を取得できる。
論文は、エージェントが回答を書く前にWebツールを使ってアップストリームのパッチを見つけたケースを記録している。別のケースでは、サニタイズされていないGit履歴から過去の修正が露出していた。いずれも成功したパッチを生成したが、独立した修復能力を純粋に測定したものではない。
実際の開発者は、日常的にWebを検索し、リポジトリ履歴を調べる。これらの行動は本番環境では合理的である。ベンチマークが過去のタスクに対する支援なしの推論を測定すると主張する場合にのみ、問題となる。
したがって評価では、意図する能力を明示しなければならない。ツール利用ベンチマークは検索を許可し、効果的な検索・取得を評価できる。モデル推論ベンチマークは、回答漏洩からケースを隔離する必要がある。
インフラのエラーは、逆方向に結果を歪めることがある。誤った権限設定は隠された正解情報を露出させたり、正当なビルドを妨げたりする。タイムアウトは遅いプロジェクトを不利にし、テストファイルの衝突は正しいパッチを失敗と判定しうる。
研究者らは、完全な実行において個別のフレームワーク問題がケースの約5%から32%に影響することを観察した。こうした割合は、リーダーボード上の二つの順位を分けるスコア差を上回る場合がある。
実務上の結論は、すべてのベンチマークスコアが無意味だということではない。スコアは、プロンプト、ツール、ソースのパッケージング、実行制限、採点パイプラインを含む完全なシステムに帰属するということだ。
本当の競争は、ベンチマークでの成功とメンテナーの受容の間にある
主要な対立点は、AIエージェントがもっともらしいパッチを書けるかどうかではなく、その成功シグナルが本番環境での受け入れ基準と一致しているかどうかに移っている。
AIによる脆弱性パッチ適用を提供するベンダーにとって、簡潔な性能数値は有利に働く。購入者も、モデルを選定したりセキュリティエージェントを評価したりする際には、単純な比較を求める。こうしたインセンティブは、目に見える単一の成功率を掲げるリーダーボードを促す。
一方、メンテナーはより扱いにくい定義のもとで運用している。変更が根本原因を修正しているか、サポート対象の動作を守っているか、プロジェクトの慣例に従っているか、数か月後にも理解可能な状態を保っているかを判断しなければならない。
Northwesternのデータセットは、その判断の一部を自動評価へ取り込もうとしている。メンテナーが作成したテストはレビューの完全な代替ではないが、クラッシュを引き起こす入力だけよりも多くの意図を符号化している。
他の研究者も似た方向に進んでいる。PatchBenchの結果では、PoCのみの検証により、11種類のエージェント全体で解決率が平均1.83倍に水増しされることが判明した。このベンチマークには、セキュリティ再現、ユニットテスト、出力チェックが追加されている。
PatchBenchは記憶による影響にも対処した。受け入れられた修正が報告済みクラッシュのスタック外にある脆弱性を選定した。その後、履歴上のパッチを想起する価値を下げるため、変更されたリポジトリ文脈へ脆弱性を移植した。
最も強力なエージェントは元のPoCの97%以上を通過したものの、セキュリティと意味論的検証を組み合わせた条件では、解決できたタスクはおよそ半数だった。このパターンは、Northwesternが特定した採点上のギャップと密接に一致する。
Berkeleyの研究者は、エンドツーエンドのベンチマークで、より楽観的だが両立可能な結論に到達した。CyberGym-E2Eには、139のオープンソースプロジェクトにまたがる920件の脆弱性が含まれ、発見、再現、パッチ適用を一体として試験する。
最良の構成では、対象の脆弱性が与えられた場合に約80%のケースを修復した。エージェントがまず問題を発見しなければならない場合、エンドツーエンド性能は低下した。研究者らはまた、報告されたクラッシュだけを防ぎ、より深い欠陥を残す表層的なパッチも観測した。
これらの研究は、単一の普遍的なランキングを生み出すものではない。タスク、エージェント、モデル世代、定義が異なるためだ。総合すると、単一の割合では防御ワークフロー全体を表せない理由を示している。
より厳しい基準は、履歴上のパッチとのテキスト上の一致を求めるべきではない。ソフトウェアの欠陥には、複数の有効な修正方法が存在することが多い。パッチの類似性に基づくベンチマークでは、別の関数を変更したというだけで、より洗練された代替案を却下する可能性がある。
より望ましい方向は、振る舞いに基づく評価だ。報告されたエクスプロイト、隣接する入力、サポート対象の機能、セキュリティ特性、プロジェクト固有の期待事項をテストすべきである。こうした要件を符号化できない領域では、人間によるレビューが依然として必要となる。
エンタープライズチームも、調達時に同じ区別を適用すべきだ。ベンダーのパッチ適用スコアは、その背後にあるオラクル、環境、ツール権限、失敗カテゴリーを抜きにしては不完全である。
有用な問いは具体的だ。エージェントにはエクスプロイトが渡されたのか。インターネットやGit履歴へアクセスできたのか。成功にはメンテナーのテストが必要だったのか。パイプラインエラーは不正なパッチと区別されたのか。
チームは、結果にパッチによるリグレッション、別経路のエクスプロイト、新たに持ち込まれた弱点が含まれているかも問うべきである。あるエクスプロイトを防ぎながら別のものを露出させるパッチは、擁護可能な成功ではない。
この基準は、Claudeによる脆弱性パッチ適用と、あらゆる競合システムのハードルを引き上げる。同時に、単にPoC通過率を上げることよりも明確な目標をモデル開発者に与える。
この研究が証明すること、証明しないこと
この証拠はベンチマーク感度を示しているが、Claudeやあらゆる本番セキュリティワークフローにおける普遍的な失敗率を確立するものではない。
この論文は2026年10月のarXivプレプリントである。その主張は、自律的なパッチ適用の信頼性に関する業界全体の最終測定値ではなく、研究上の知見として評価すべきだ。
112件のケースは4つの言語カテゴリーと84のプロジェクトにまたがっており、分析に有用な多様性を与えている。しかし、収録には再現可能なビルドと、意味のあるテストを含むアップストリームのコミットが必要だった。この選定は、本番環境で見つかるすべての脆弱性を代表するものではない。
開発者テストはPoCのみのチェックより強力だが、それでもメンテナーの受け入れを不完全にしか代替できない。プロジェクトで追加されたテストが捉えるのは、選ばれた意図された振る舞いであり、すべての性能、互換性、可読性、アーキテクチャ上の懸念ではない。
生成されたパッチが、なお擁護可能でありながら、履歴上の開発者テストに失敗することもある。代替の修正は、文書化されていない動作を意図的に変更したり、より広い攻撃面を閉じたりする可能性がある。人間のメンテナーはレビュー後、そのトレードオフを受け入れるかもしれない。
この研究は、アップストリーム修正で作成されたテストを使うことで、この懸念を軽減している。ただし、個々の不一致を調査する必要性をなくすものではない。テスト失敗は不整合を示すのであって、自動的に危険なパッチを意味するわけではない。
履歴データには別の制約もある。公開された問題、アドバイザリ、修正は、モデルの学習データに含まれていた可能性がある。研究者らは、記憶が絶対的な成功率に影響し得ることを認めている。
モデルとバグを一定に保ちつつ、ベンチマーク条件だけを変えるため、彼らの統制比較には依然として価値がある。記憶だけでは、プロンプトの詳細やオラクルの選択が測定結果を変える理由を説明できない。
実験では、特定のエージェントとモデルの組み合わせも使用された。統制テストではOpenCodeとClaudeモデルが組み合わされ、ケーススタディではClaude CodeとSonnet 4.5が組み合わされた。異なる足場となる仕組みは、異なる探索、編集、検証の振る舞いを生み得る。
本番環境でのClaudeによる脆弱性パッチ適用には、組織固有のテスト、静的解析、ファジング、コードレビュー、段階的ロールアウトが含まれる可能性がある。こうした統制は、学術的なハーネスでは不成功の出力として記録される失敗を捉えられる。
逆もまた真である。本番リポジトリには、不完全なテスト、文書化されていない振る舞い、クリーンなコンテナ内では利用できない依存関係が含まれる場合がある。実際のデプロイは、精選されたベンチマークより難しいことがある。
責任ある結論は、マーケティングや一蹴のいずれよりも限定的である。Claude Opus 4.7は、このデータセットにおいて以前のClaude世代から大幅に改善した。それでもクラッシュテストのスコアは、開発者との整合性を示す結果を29.5ポイント過大に示していた。
セキュリティチームは、生成されたパッチを証拠を必要とする候補として扱うべきだ。この研究は、停止したPoCと成功した既存テストスイートだけに基づく無人デプロイを支持していない。
AIパッチ適用が信頼に値するものになっているかを示す3つのシグナル
今後の進歩は、より強固な評価、透明な評価パイプライン、生成された修正が独立したレビューを生き残ることを示す本番証拠にかかっている。
第1のシグナルは、開発者の意図または意味論的テストの利用拡大である。今後のモデルリリースでは、PoCの成功と、受け入れられたプログラムの振る舞いを中心に設計されたテストでの性能の両方を報告すべきだ。
ギャップの縮小は、モデルが根本原因の修正を学んでいるという見方を強める。メンテナーテストとのギャップが安定したままクラッシュテストのスコアだけが上昇するなら、その主張は弱まる。
第2のシグナルは、ベンチマークの完全な開示である。評価者は、プロンプト、ツール権限、ネットワークアクセス、ソースのサニタイズ、タイムアウト、テスト適用エラー、各段階の結果を公開すべきだ。
これは、エージェントにビルド手順、読み取り可能なPoC、Webアクセス、隠されたリポジトリ履歴が与えられると、スコアが動くため重要である。再現可能な成果物により、研究者はモデルの進歩とハーネスによる支援を切り分けられる。
独立した取り組みは、より広い防御ループをカバーし始めている。Cyber Indexの方法論は、正当な振る舞いを損なうことなく、リポジトリ監査、脆弱性発見、再現、パッチ適用を組み合わせている。
第3のシグナルは、レビュー済みの本番パッチから得られる証拠である。組織は、生成された修正が変更なしで受け入れられる頻度、メンテナーによって改訂される頻度、却下される頻度、セキュリティ上のリグレッションが後続する頻度を追跡すべきだ。
この受け入れファネルは、統制されたスイートで抑制されたクラッシュ数より重要である。自動出力が、隠れたリスクを下流へ移すことなくエンジニアリング作業を減らしているかを測定するものだからだ。
直ちに使うなら、チームは多層的なゲートを導入できる。エクスプロイトが停止することを必須とし、既存のリグレッションテストを実行し、境界ケースを追加し、実用的な場合はファジングを適用し、デプロイ前に人間のレビューを得る。
エージェントのプロンプト、ツールトレース、パッチ、検証結果を保存すべきである。検索可能なエンジニアリング知識ベースは、チームがリポジトリをまたいで繰り返される失敗パターンを比較する助けとなる。
購入者にとっての問いは、AIエージェントが赤いテストを緑に変えられるかどうかではもはやない。その緑の結果が、本番ソフトウェアに求められるセキュリティ特性、サポート対象の振る舞い、メンテナーの意図を表しているかどうかである。
次のClaudeによる脆弱性パッチ適用スコアを信頼する前に、評価者が何を見られたのかを問うべきだ。そして、その評価者が一度もテストしなかったものを問うべきである。
