SWE-bench (benchmark) — SWEベンチ

From Systems analysis wiki
Jump to navigation Jump to search

SWE-benchは、自動ソフトウェア開発およびデバッグの分野における大規模言語モデル（LLM）の能力を評価するための、大規模なベンチマーク（テストタスクのセット）です[1]。プリンストン大学などの研究者グループによって開発され、ICLR 2024カンファレンスで発表されました[2]。SWE-benchは、従来のコードベンチマークとは異なり、開発現場の実際のタスクを使用している点が特徴です。テストセットには、GitHub上の12の著名なオープンソースPythonリポジトリから、クローズされたissue（課題）とそれに対応するpull request（修正）に基づいた2294件のタスクが含まれています[1][3]。各タスクには問題（issue）の記述が含まれ、モデルは関連プロジェクトのソースコードにアクセスできます。モデルの目標は、指定された問題を修正するために、コードベースに最小限の変更（パッチ）を生成することです[1][3]。

評価の方法と特徴

SWE-benchは、実際のソフトウェア開発プロセスをモデル化しています。各タスクにおいて、モデルには元のGitHub issueのテキスト（問題の記述）と、修正が適用される前のバージョンのリポジトリコードのスナップショットが提示されます[4]。モデル（またはモデルベースのエージェント）は、ソースコードを分析し、エラーの性質や要求される変更を理解し、問題を解消するために適切なファイルに修正を加える必要があります[4][5]。解決策の検証は自動化されており、各タスクには、その問題をクローズしたpull requestからの実際の単体テストが関連付けられています。これらには、「fail-to-pass」テスト（元のコードでは失敗するが、正しい修正を適用すると成功するべきテスト）と、回帰テスト（「pass-to-pass」テスト、元々成功しており、変更後も成功し続けるべきテスト）の両方が含まれます[3]。モデルが提案したパッチをコードに適用した後、関連するテストが実行されます。すべてのfail-to-passテストが成功し、かつpass-to-passテストが失敗しなければ、タスクは正しく解決されたと見なされます[3]。この評価アプローチにより、モデルが構文的に正しいコードを生成する能力だけでなく、既存の機能を損なうことなく、提示されたタスクを実際に解決する能力も検証できます。その際、モデルは大規模なコンテキスト（リポジトリ全体）を扱い、コンポーネント間の相互関係を理解し、複数のファイルにまたがる変更を調整する必要があります[1]。これらはすべて、説明に基づいて関数を作成するような典型的なタスクよりもはるかに複雑です。

SWE-benchの評価には、LLM単体ではなく、モデルを補助的なツール（ファイルナビゲーション、コード実行、デバッガの使用など）でラップしたエージェントシステムが参加するのが一般的です[4][6]。このようなシステムは、実際の開発サイクルを模倣します。モデルはファイルを順番に確認し、テストやスクリプトを実行し、成功するまで段階的に解決策を改善できます[4]。SWE-benchのタスク解決の効率は、この「スキャフォールディング」（エージェントのインフラ）の質に大きく依存することが示されています。同じ基本モデルでも、リポジトリやツールとの連携方法によって異なる結果を示すことがあります[4][7]。したがって、SWE-benchは、モデルとそのタスク解決戦略を組み合わせた能力の指標として機能し、自律型AI開発者の実際の作業条件に近い評価を実現します[4][7]。

タスクセットのバリエーション

SWE-benchの作成者とコミュニティは、その後、さまざまな評価目的のためにいくつかの派生セットを導入しました。

  • SWE-bench Lite — ベンチマークの軽量版で、モデルのテストにかかる複雑さと計算コストを削減するために選ばれた約300件のタスクが含まれます[8]。このサブセットは、モデルの迅速な実験のために作成され、最も手間のかかる検証を排除しつつ、主要な問題の代表性を維持しています[7]。基本的に、Liteにはより単純で短いバグ修正タスクが含まれており、最も困難なケースが除外されているため、Liteでのモデルの成績は通常、完全なセットよりも高くなります[7]。
  • SWE-bench Verified — 2024年8月にOpenAIと共同で発表された、手動検証によってフィルタリングされたサブセットです[7]。研究者たちは93人のプロの開発者を動員して、元のベンチマークの各タスクを分析し、問題の記述が曖昧すぎる場合や、テストで要求される挙動がタスクの条件から明確に導き出せないケースを除外しました[7]。また、環境の問題や不正確なテストのために実際には解決不可能なタスクも削除されました[7]。その結果、解決可能で正しく定式化されていることが保証された500件のタスクからなるセットが形成されました[7]。SWE-bench Verifiedは、不適切なテストやタスクのせいで正しい解決策が拒否されるケースを排除することで、モデルの能力をより信頼性の高い形で評価することを目的としています[7]。このセットは、モデル比較の主要な基準として、元のSWE-benchテストセット（完全版とLite版）に取って代わりました[7]。さらに、Verifiedと同時に、タスクの難易度評価（例：人間が15分未満で解決できる「簡単な」タスクと、1時間以上かかる「難しい」タスクの区別）[7]や、より安定した再現可能なテスト実行のための新しいDockerベースのツールフレームワークも公開されました[7]。
  • SWE-bench Multimodal — 2025年1月に導入されたベンチマークの拡張版で、問題の記述にテキストだけでなく、視覚的要素（インターフェースの画像、エラーのスクリーンショットなど）を含むタスクが含まれています[8]。このセット（517件のタスク[8]）は、プログラミングタスクを解決する際に、視覚情報を理解し利用するモデルやエージェントの能力を検証します。マルチモーダルなセットでの評価も同様に行われますが、モデルにはマルチモーダル能力（例：画像からのテキスト認識）が要求されます。SWE-bench Multimodalのテスト部分は、既知の解答への過剰適合を防ぐために非公開（隠蔽）にされており、開発者は自分のモデルを評価するために、リモートのリーダーボードに解決策を提出することができます[2]。

これらの主要なバリエーションに加えて、SWE-benchの周りにはツールのエコシステムが形成されています。SWE-agentは、ベンチマークのタスクで最先端の結果を示すオープンソースのソフトウェア「エージェント」ソルバーです[2]。SWE-smithは、独自の開発者モデルをトレーニングするためのフレームワークです。SWE-REXは、リポジトリから情報を拡張的に抽出し処理するためのツールです。これらのプロジェクトは、結果の再現を容易にし、自律的なプログラミングシステムの分野における研究を推進することを目的としています。

モデルの成績と進歩

SWE-benchが最初に登場したとき、現代のLLMと熟練プログラマーのスキルとの間に大きな隔たりがあることが明らかになりました。作成者らによると、2023年初頭の最も強力なモデルでさえ、タスクの数パーセントしか解決できませんでした。例えば、Anthropic社のClaude 2モデルは、完全なセットの2%未満しか正しく解決できませんでした[1]。ベンチマーク作成者によって特別に訓練されたモデル（LLaMAベースでSWE-Llamaと名付けられた）や、GPT-4のようなプロプライエタリなモデルは、主に最も単純なエラーしか解決できませんでした[1]。これらの低い初期のメトリクスは、SWE-benchの難しさを示し、新しいアプローチの開発を促すきっかけとなりました。

2024年を通じて、より高度なモデルやエージェントの仕組みが登場するにつれて、結果は大幅に改善されました。プリンストン大学の研究者たちは、GPT-4をコード検索、計画立案などのツールと組み合わせたSWE-agentシステムを発表し、完全なセットで約12.5%のタスクを解決し、学術モデルの新たな基準を打ち立てました[5]。2024年半ばまでに、SWE-benchの公式リーダーボードでは、最良のソリューション（プロプライエタリなものを含む）が、完全なベンチマークで約20%、簡略化されたLiteセットでは最大43%の成功率に達しました[7]。この成長は、モデルの改善（例：GPT-4、Claude 2、Claude 3の登場）と、特に「スキャフォールディング」の発展に関連しています。これは、モデルがタスクをステップに分解し、ドキュメントを読み、デバッグセッションを実行するなどを効率的に行うための外部戦略です[7]。

2024年末にVerifiedセット（不正確なタスクが除去されたもの）が導入された後、測定されるパフォーマンスはさらに向上しました。GPT-4モデル（GPT-4oバリアント）は、Verifiedセットで即座に約33%の成功率を示し、これは元のセットでの約16%から大幅な向上でした[7]。最良のオープンなエージェントフレームワーク（例：Agentless）も、Verifiedセットで結果が約16%から32%へと倍増しました[7]。これは、元のベンチマークが解決不可能なケースを含んでいたためにスコアを過小評価していたという仮説を裏付けました[7]。一方で、Liteと比較したVerifiedでの結果の改善はそれほど劇的ではありませんでした（最良のモデルはすでにLiteで約43%に達していた）。これは、Liteが元々より簡単な例を選び、Verifiedは実行不可能なタスクを除去したものの、難しいタスクは残したため、論理的な結果です[7]。Verifiedへの移行によるスコアの向上は、最も困難なタスクを排除したことによるだけでなく、すべての難易度カテゴリのタスクで発生した点が重要です。つまり、フィルタリングによって、比較的簡単なタスクの中に隠れていた実行不可能なケースも取り除かれたのです[7]。

2025年初頭の時点で、主要なAIシステムは検証済みタスクセットにおいて人間に近い効率を示していますが、100%の達成にはまだほど遠い状況です。2025年1月、Anthropic社は、新しいモデルClaude 3.5 Sonnetが改良されたエージェントと組み合わせて、SWE-bench Verifiedのタスクの49%を解決したと報告し、一時的にトップに立ちました[4]。大手テクノロジー企業や独立したチームも、このベンチマークでの非公式な競争に積極的に参加しています。例えば、CodeStoryチームは、複数のモデルでバリアントを試すアプローチ（「Midwit Agent」）を開発し、Verifiedで記録的な62.2%のタスク解決率を達成しました（2025年初頭のデータ）[5][9]。これを達成するためには、モデルの推論段階での計算リソースを大幅に増やす（いわゆるinference time scaling）必要があり、多数の解決試行を実行して最良の結果を選択したと指摘されています[5]。一方、OpenAIの資料では、実験的なシステムGPT-03が十分な計算スケールでVerifiedの70%の壁を突破したとされる言及がありました（非公式データ）[5]。しかし、これらの結果の独立した検証はなく、このような高いスコアは達成された基準というよりは、将来の研究の目標となっています。

Microsoft Researchの研究（2025年）によると、最新のモデルでさえ、デバッグツールを備えていても、SWE-bench Liteのバグ修正成功率は50%の壁をまだ越えていません[6]。このテストでは、Claude 3.7 Sonnetが最も優れており、タスクの約48.4%を解決しましたが、GPT-4（OpenAI 01）ベースのシステムは約30%、より軽量な03-miniモデルはわずか22%でした[6]。これらの結果は、急速な進歩にもかかわらず、現代のAIはまだ熟練したプログラマーに劣ることを強調しています。人間にとっては（コードを理解していれば）このようなタスクの解決は難しくありませんが、モデルはデバッグツールを効果的に使用できなかったり、多段階のバグ修正プロセスを反映した訓練データが不足していることに苦しむことが多いのです[6]。

限界と展望

SWE-benchは、インテリジェントなコードエージェントを評価するための標準化されたプラットフォームとなりましたが、研究によっていくつかの限界も明らかになっています。主な問題はテストの不完全性です。各タスクの検証テストセットは特定のpull requestから取得されており、通常はバグ修正時に変更されたユニットテストのみが含まれます[3]。浙江大学とシュトゥットガルト大学の研究者グループ（Wang et al. 2025）による分析が示すように、プロジェクトの他のテストを無視すると、一部の解決策の不正確さが隠されてしまう可能性があります[3]。リポジトリの完全なテストスイートで解決策を再検証したところ、SWE-benchで成功とマークされたパッチの平均7.8%が、実際にはプロジェクト内の他のテストに失敗することが明らかになりました[3]。これにより、「解決済みタスク」のメトリクスが約4～6パーセントポイント過大評価されることになります[3]。さらに微妙なケースとして、生成されたパッチがすべての元のテストに合格するものの、開発者の解決策とは等価ではなく、プログラムの挙動を予期しない形で変更してしまう場合があります。追加のテストケースを生成する手法（PatchDiff）を用いて、研究者たちは、AIが提案した修正の約30%が参照パッチとは異なる挙動を示し、約11%は既存のテストでは検出されないものの、明らかに誤っていることを発見しました[3]。したがって、限られたテストセットの合格のみに依存すると、モデルの真の能力が過大評価される可能性があります。SWE-benchの作成者もこの脆弱性を認識しており、ベンチマークは時間とともに進化すべきであると強調しています。テストカバレッジを改善し、望ましくない副作用がないかどうかのチェックを追加し、タスクの種類を拡大する必要があります[7]。このような評価手段の開発は、ますます自律的で強力なAI開発者の登場に備える上で重要な部分であり、SWE-benchの経験は、ベンチマークの品質に注意を払う必要性を示しています[7]。

SWE-benchは、静的なタスクセットに過ぎず、プログラミングのあらゆる側面を網羅しているわけではありませんが、既にコードモデルの比較分析におけるデファクトスタンダードとなっています[3]。科学論文で新しい手法やアルゴリズムを実証するために使用されるほか、産業界の研究グループがプログラミングを自動化するシステムの可能性を評価するためにも利用されています[3]。2023年から2025年にかけてのSWE-benchでの成績の継続的な向上は、実践的な開発タスクを解決するLLMの能力が急速に向上していることを明確に示しています。同時に、それは難易度のバロメーターとしても機能します。解決済みタスクが50～60%に近づいても、モデルはまだ人間を完全に代替するにはほど遠く、特に情報が限られ、要件の微妙な理解が必要な状況ではなおさらです[4][7]。しかし、進歩は止まりません。SWE-benchのような取り組みのおかげで、コミュニティは自らの目標と限界を明確に認識し、人間の専門家レベルでソフトウェアコードを自律的に理解し修正できる本格的なAI開発者の創造に向けて前進し続けています[4][7]。

外部リンク

参考文献

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

脚注

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. 「SWE-bench: Can Language Models Resolve Real-World GitHub Issues?」 arXiv. [1]
  2. ↑ 2.0 2.1 2.2 「SWE-bench/SWE-bench」 GitHub. [2]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. 「Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study」 arXiv. [3]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 「Claude SWE-Bench Performance」 Anthropic. [4]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. 「SWE Benchmark: LLM evaluation in Software Engineering Setting」 Medium. [5]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. 「AI models still struggle to debug software, Microsoft study shows」 TechCrunch. [6]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 「Introducing SWE-bench Verified」 OpenAI. [7]
  8. ↑ 8.0 8.1 8.2 「SWE-bench Leaderboard」 [8]
  9. ↑ 「SOTA on swebench-verified: relearning the bitter lesson」 Hacker News (Y Combinator). [9]


Retrieved from "https://systems-analysis.ru/int/index.php?title=SWE-bench_(benchmark)_—_SWEベンチ&oldid=7668"