CheckerBench：AIエージェントは静的解析チェッカーを開発できるか

CheckerBenchが問うのは、AIエージェントが再利用可能な静的解析チェッカーを開発できるかだ。静的解析は、対象プログラムを実行せずにコードを調べて欠陥を検出する。チェッカーは、その解析器の中で特定の欠陥を見つけるための検査ルールに当たる。今回の研究は、2026年10月6日付のarXivプレプリントとして公開された。

業務上の場面として、開発チームがある脆弱性の修正前後のコードをAIに渡し、同じ欠陥を検出するルールの作成を依頼する状況を考える。修正箇所をそのまま覚えたルールなら、その事例だけでは良い結果が出るかもしれない。しかし、狙いは欠陥の仕組みを捉え、ほかのコードにも使えるルールを作ることだ。本論文はこの違いを評価に組み込む。ただし、評価対象外のリポジトリに広く通用することまで証明しているわけではない。

著者らによれば、従来のコーディング評価は修正パッチや機能実装を、脆弱性評価は検出・分類・修復を主に採点してきた。それに対してチェッカー開発では、欠陥の説明を理解し、リポジトリを調べ、解析器に合うロジックを作り、コンパイルと解析結果を受けて改善する一連の作業が必要になる。

ここには異なる成功条件がある。チェッカーがコンパイルできること、脆弱なコードで警告が出ること、修正後に警告が減ること、欠陥と関係のある場所を指すことは、それぞれ別だ。さらに、修正とは無関係な違いを利用して警告を減らすルールなら、修正前後の比較だけを通過しても欠陥を理解したとは言いにくい。CheckerBenchの中心は、こうした段階を一つの成功率に混ぜず、最終的にはすべて満たすよう求める点にある。

課題は、脆弱性情報を集めたNVDに由来する、再構築可能な修正前後の組から作られる。300課題は297件のCVE、167リポジトリ、85種類のCWEを含む。CVEは個別の脆弱性の識別番号、CWEは欠陥の種類の分類だ。C/C++の159課題にはClang Static Analyzer、略してCSAを使い、Javaの30課題、Pythonの51課題、JavaScriptとGoの各30課題にはCodeQLを使う。どちらも、この研究でチェッカーを動かす解析器である。

ただし、課題集合は全CVEから無作為に選ばれたものではない。構築段階では、人間の診断や指示の改訂を伴う最大3回の試行で合格例が得られた課題から、40以上の意思決定ステップを持つ軌跡を選んでいる。この選択は評価の対象範囲を形づくる。本評価の自律的な生成とは別であり、チェッカー開発に最低40ステップ必要だという証拠でもない。

エージェントには、リポジトリ、修正前後のコード、パッチ、変更された関数、ビルド情報、コマンド、チェッカーの最小雛形を渡す。解析器の資料や公式実装例に加え、パッチの解釈、設計、ビルドの復旧、検証、誤警告の精査を支える共通の「スキル」も提供する。ここでのスキルは作業を支援する資料であり、課題固有の正解を渡すものではない。参照解と評価器は隠し、CVEやCWEのラベルも省く。

先ほどの開発チームの例なら、AIは修正で何が変わったかを読み、その変化が防ぐ欠陥を検査ルールに落とし込む。続いてチェッカーをビルドし、解析を実行し、失敗や警告を見て改善する。修正を読むだけでも、コードを書く一度の応答だけでも完結しない。この反復を含む開発能力が評価対象となる。

本評価は7モデルと3ハーネスの組み合わせ、計21構成で行う。ハーネスとは、モデルのツール利用や対話の進行を支える仕組みだ。OpenCode、Claude Code、Hermes Agentを使い、同じ300課題について各構成を3回独立に生成する。合計は18,900の論理実行で、各回の能動的な生成予算は50分となる。インフラの復旧試行は独立した標本に数えない。

生成終了時には候補ソース、対話軌跡、ツール呼び出しを凍結する。CheckerLabは、その提出ソースを固定環境で再ビルドして解析する。つまり、エージェントが途中で「成功した」と判断しただけでは合格しない。チェッカー自体のビルドと、対象コードを解析して診断を出すことも別々に確かめる。この独立性は、論文内で生成と検証を分けたという意味であり、第三者による再現実験を指してはいない。

まず、ビルド、修正前後の検出差、パッチとの関連性を確認する。CSAでは、脆弱側の診断数が修正側より多く、修正側は50件未満であることを求める。行番号だけに頼らず、チェッカー、ファイル、関数、メッセージを照合し、消えた診断の少なくとも1件が変更された関数に対応することも必要だ。CodeQLには別の差分・関連性規則を適用する。

最終合格には、これらに加えて開発過程と意味の評価が入る。開発過程は、理解、計画、コードの整合性、検証などを採点し、80点以上を求める。意味の評価は、欠陥に対する正しさと、適切な検出機構を使っているかを見る。下限はCSAで10点中7点、CodeQLで8点だ。特定の事例に合わせたハードコーディングなどのリスクがないことも要求する。

さらに、課題の修正前後とは異なるmainline、すなわち別の主系列のコード範囲に凍結候補を適用する。最大10件の警告を精査し、誤警告の割合が25%以下であることを採否条件とする。品質と誤警告はClaude Opus 5が段階を分けて判定し、最初の有効な判断を保持する。低い評価を理由にチェッカーを直したり、採点をやり直したりはしない。良いビルド結果で意味の不足を埋め合わせるような合格方式ではない。

主指標のPass@1は、1回の独立生成で全条件を満たした課題の割合だ。各構成の全300課題を分母とし、3反復を等しい重みで平均する。ビルド成功率のBuild、差分検証成功率のDiff. SRも全課題が分母なので、どの段階で成功が減るかを比較できる。

著者らはDeepSeek-V4-Proの同じ300課題で、支援要素を外す比較も行った。Pass@1は完全構成39.67%、スキルなし8.33%、実行フィードバック非表示13.33%、ツールとハーネスを使わない1回のモデル呼び出しでは0.33%だった。ただし、各変種は1生成で、完全構成は過去の候補を再利用している。実行日、コンテキスト上限、隔離条件も異なる。支援を外した構成が低成績だったとは言えるが、その差を各要素だけの因果効果として読むことはできない。

以下の実験値は著者らの報告である。同じ300課題、各3反復、50分予算で、21構成の平均Buildは78.25%、Diff. SRは73.65%、Pass@1は32.30%だった。BuildからDiff. SRへの差は4.60パーセントポイントだが、Diff. SRと全条件合格の差は41.35パーセントポイントに広がる。最良のOpenCodeとClaude Opus 4.8の組み合わせでも、Pass@1は45.33%にとどまった。

この隔たりは、動作して修正前後を区別できるチェッカーと、全品質条件を満たすチェッカーを同一視できないことを示す。ただし、差の全体を意味の誤りだけに帰すことはできない。選択された失敗4,360実行の分類では、予算切れ25.32%、開発過程の不足22.96%、意味モデルの不足21.15%、過剰な誤警告15.96%だった。これは全失敗の無作為標本とは記されておらず、失敗全体の構成比として一般化するには注意が要る。

ハーネス別の平均Pass@1は、OpenCodeが36.95%、Claude Codeが33.81%、Hermes Agentが26.14%だった。Claude CodeではDeepSeek-V4-Proの38.33%がClaude Opus 4.8の35.00%を上回る。一方、OpenCodeではOpusの45.33%がDeepSeekの39.67%を上回った。この条件での開発能力は、モデルとハーネスの組み合わせとして見る必要がある。

合格率の高さは、合格後の警告精度の順位とも一致しない。合格チェッカーの保存済み・判定済み警告に占める誤警告の割合をFP_passと呼ぶ。OpenCode平均は6.63%、Claude Code平均は1.97%だった。OpenCode内でも、Opusは13.79%で記録警告174件、GPT-5.6は0.00%で7件となる。警告量と合格したチェッカーの集合が違うため、0%だけを見て普遍的な精度優位とは判断できない。

採否用の最大10件は一様な無作為標本ではなく、保存する警告数にも上限がある。FP_passは保存警告の中の誤警告割合であり、全リポジトリの誤検知率ではない。警告を出さなかった例も、完全な精度を証明するものではない。

警告の精査範囲には、結果を左右する余地が残る。主表の後続修正より前に保存された、第1反復の合格1,940候補を全保存警告で再監査すると、81件が追加条件で脱落し、最上位構成も変わった。この集合は現在の3反復主表の合格総数ではない。過去の合格例と保存出力に限った監査なので、現在の順位が網羅的な精査でも維持されるかは未確認だ。

LLM判定の妥当性については、人間との比較がある。CSAとCodeQLの各100提出から、開発過程などの段階判定400件と警告判定200件、計600対を調べた。Opus 5と人間3名の多数決は556対で一致し、偶然の一致を考慮する指標であるCohenのκは0.852だった。

これは二値の採否判断に関する一致の証拠である。数値スコアの誤差や、個別の細かな基準の一致までは調べていない。監査によって本評価の判定も変更していない。したがって、LLMの評価を人間の正解と同一視することはできない。

時間を増やせばどこまで改善するかについて、著者らは既存の50分実行を最終成果物の完了時刻で遡って集計した。Pass@1は10分時点で7.24%、30分で26.05%、50分で32.30%。最後の10分の増分は2.25パーセントポイントだった。ただし、途中成果物を採点した結果でも、短い締切で生成し直した結果でもない。生成時計は資源待ちや後段の検証を含まないため、実時間や金銭コストの削減には結び付けられない。

課題の偏りもある。Linuxが107課題を占め、C/C++にはCSA、他言語にはCodeQLを使うため、言語と解析器の影響を分離できない。また、公開パッチやチェッカーの最初の公開日の監査は未解決で、CVEの日付だけではモデルにとって未見の課題かどうかを保証できない。

本評価は、固定した解析環境での反復開発やモデル・ハーネスの比較に適している。対象プログラムの実行時安全性、未知の解析器への対応、未見リポジトリへの汎化を保証するものではない。次に見るべき証拠は、警告をより広く人間が精査しても品質と順位が保たれるか、未見のリポジトリでも同じ評価手順が有効かである。