コーディングAIエージェントベンチマークの変遷をたどる

この記事は KNOWLEDGE WORK Blog Sprint の 23 日目の記事になります。

基礎的ベンチマークの飽和

近年のコーディングAIエージェントの進化は凄まじいものがあります。
その進化を定量的に評価・比較する上で、共通のベンチマークは欠かせません。
これまで、様々なベンチマークが提案されてきました。
本記事では、その一部を見ていけたらと思います。

コード生成タスクの初期段階では、HumanEval や MBPP (Mostly Basic Python Programming) などのベンチマークが、モデルの能力を測定するための標準的な指標として利用されました。これらのベンチマークは、主に独立した関数を記述する能力を評価することに焦点を当てていました。

しかし、LLM の能力が向上するにつれて、これらの基礎的なベンチマークは「飽和」状態に達しつつあり、実世界のソフトウェア開発における実用性を評価するための新たな指標が求められています。

近年の新しいベンチマーク

このリアリズムへの要求に応えるため、近年ではコーディングAIエージェント評価の文脈で様々なタイプのベンチマークが提案されています。ここでは NeurIPS、ICLR、ICML、EMNLP、NAACL、ACL、ICSE などのカンファレンスで発表された研究を踏まえ、なるべく年代順に紹介し、その変遷を辿ります。

他ライブラリ依存コードの生成タスク

より現実的な設定として、多様な外部ライブラリを利用したコード生成を評価するベンチマークとして ODEX が提案されました。ODEX の提案論文では、ライブラリ依存が強いコードとビルトイン中心のコードとの違いが分析されています。

• ODEX (Open-Domain Execution-based Code Generation)
  • Execution-Based Evaluation for Open-Domain Code Generation (Findings of EMNLP 2023)
  • https://github.com/zorazrw/odex

マルチファイル・リポジトリ文脈のコード補完タスク

独立した関数レベルのコード生成だけでなく、複数ファイルやリポジトリ全体でのコード生成タスクを評価するために、CrossCodeEval や RepoBench が提案されました。
CrossCodeEval では、プロジェクト全体を視野に入れたモジュール間依存を捉える必要があり、モデルは不完全なコードスニペットに対して、他ファイルの情報を踏まえた正しい続きを生成できるかを評価されます。補完精度は Exact Match や編集距離で測定されます。RepoBench では検索がサブタスクとして設定され、関連コード検索・コード補完・パイプライン（検索＋補完）の3つのサブタスクから構成されています。

• CrossCodeEval
  • CrossCodeEval: A Diverse and Multilingual Benchmark for Cross-File Code Completion (NeurIPS 2023)
  • https://github.com/amazon-science/cceval
• RepoBench
  • RepoBench: Benchmarking Repository-Level Code Auto-Completion Systems (ICLR 2024)
  • https://github.com/Leolty/repobench

多プログラミング言語間コード変換タスク

プログラミング言語間のコード翻訳能力を評価する専門ベンチマークとして、Code Lingua が提案されています。C, C++, Go, Java, Python などの異なる言語で計 1700 のコードスニペットが用意され、それぞれに対して他言語への正確な変換が求められます。単なる文法置換にとどまらず、翻訳中に混入するバグや既存のバグの修正も分析され、出力コードのセマンティックな一貫性とロバスト性が評価指標となります。

• Code Lingua
  • Lost in translation: A study of bugs introduced by large language models while translating code (ICSE 2024)
  • https://github.com/codetlingua/codetlingua

実際のバグ修正・機能要求などの課題解決タスク

本物のソフトウェア開発では、バグ修正や機能要求の実装などのメンテナンス作業が日常的に発生します。実際の GitHub リポジトリから収集されたバグ修正や機能要求をエージェントに課すベンチマークとして SWE-bench が提案され、近年のコーディングAIエージェント評価のデファクトスタンダードの一つとなっています。
また、SWE-bench Verified という人間が検証したサブセットにおいては、Gemini 2.5 Pro (63.8%)、Claude Opus 4 (72.5%)、GPT-5 (74.9%) などが公式に評価指標を報告しています。
しかし、SWE-bench は特定の限定ライブラリに偏っているといった課題もあり、SWA-Bench (Software Applications Bench)、SWEE-Bench (SWE-Bench Extended) など多様な派生ベンチマークも提案されています。

• SWE-bench
  • SWE-bench: Can Language Models Resolve Real-world Github Issues? (ICLR 2024)
  • https://www.swebench.com/index.html
• SWA-Bench, SWEE-Bench
  • Automated Benchmark Generation for Repository-Level Coding Tasks (ICML 2025 Poster)

検索拡張コード生成（RACG）

コーディングAIエージェントの能力の中でも特に、外部知識を活用する力を評価するために設計されたベンチマークとして CodeRAG-Bench があります。これはチュートリアル、ライブラリドキュメント、Stack Overflow の投稿、GitHub リポジトリなど多様でオープンなデータを含んでいます。

• CodeRAG-Bench
  • CodeRAG-Bench: Can Retrieval Augment Code Generation? (Findings of NAACL 2025)
  • https://code-rag-bench.github.io/

エンドツーエンドのワークフローシミュレーション

エージェントがコードリポジトリを活用して実用的なタスクを完了する能力を評価するベンチマークとして、GitTaskBench が提案されています。GitTaskBench では評価指標として、実行完了率 (ECR)、タスク合格率 (TPR) のほか、費用対効果を測る Alpha Practical Value という値も導入されています。
また、入力の具体性を3段階で評価する ProjectEval も提案されています。レベル1が数行のプロジェクト説明、レベル2が関数などのチェックリスト、レベル3が docstring を含むスケルトンコードとなっており、より効果的なコーディングAIエージェント開発の示唆が得られると主張されています。
さらに、複数ツールを組み合わせてタスクを解決するエージェントを評価する BigCodeBench も提案されています。
OpenAI からは、フリーランスのソフトウェア開発タスクをベンチマーク化した SWE-Lancer や、AI 研究を再現する能力を測る PaperBench なども提供されています。

• GitTaskBench
  • GitTaskBench: A Benchmark for Code Agents Solving Real-World Tasks Through Code Repository Leveraging
  • https://gittaskbench.github.io/#/leaderboard
• ProjectEval
  • ProjectEval: A Benchmark for Programming Agents Automated Evaluation on Project-Level Code Generation (Findings of ACL 2025)
  • https://ryanloil.github.io/ProjectEval/
• BigCodeBench
  • BigCodeBench: Benchmarking Code Generation with Diverse Function Calls and Complex Instructions (ICLR 2025)
  • https://bigcode-bench.github.io/
• SWE-Lancer
  • SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering?
  • https://openai.com/index/swe-lancer/
• PaperBench
  • PaperBench: Evaluating AI's Ability to Replicate AI Research
  • https://openai.com/index/paperbench/

とりあげた変遷まとめ

独立した関数レベルのコード生成から始まり、外部ライブラリ依存コード、さらにリポジトリ全体やマルチファイル依存を考慮したコード補完タスク、多言語コード変換などが評価されるようになりました。
その後、現実の開発プロセスに即したタスク解決型ベンチマークが主流となり、近年では単なる生成能力だけでなく、外部知識の検索・統合能力を評価するもの、さらに進んでプロジェクト全体やエンドツーエンドのワークフローをシミュレーションする評価が導入され、エージェントとしての実用性や費用対効果を含めた総合的な評価が目指されています。
また、実世界のフリーランス開発や研究再現といったタスクそのものを評価基準に取り込む試みも行われています。

これから

今回取り上げられなかった研究も数多く存在しますが、方向性としてはより実践的なタスクやエンドツーエンドでの実行に焦点を当てたベンチマークへと進化していることは明らかです。これからのベンチマークは、より現実のソフトウェア開発に近い形へと進化し、チームでの協調作業や長期的な保守、さらにはコストの観点まで含めて、AI エージェントを測るベンチマークを整備していく必要があると考えられます。

おわりに

KNOWLEDGE WORK Blog Sprint の 24 日目の執筆者はバックエンドエンジニアの torotake さんです。ぜひ続けてお楽しみください。