SWE-bench Verified

概要

SWE-bench Verifiedは、元のSWE-benchデータセットのうち人間が検証した500件のサンプルからなるサブセットで、現実世界のソフトウェアエンジニアリングの課題を解くAIモデルの能力を評価する。Epochによるこのベンチマークの評価では、私たちの基盤で動作を確認した484件のサンプルを使う。各サンプルは、12個のオープンソースのPythonリポジトリのいずれかにあるGitHub issueから作られている。このベンチマークについては、私たちのSWE-bench Verifiedのレビューでさらに詳しく検討している。

評価の流れは次のとおりである。モデルには、コードリポジトリと、修正すべき課題の説明が与えられる。モデルはリポジトリを調べて変更を加え、課題を解決しなければならない。モデルが変更を終えると、変更後のコードベースで単体テストを実行して解答を評価する。

データセットは、93人のソフトウェア開発者による厳格な人手のアノテーション作業を経て選別された。各サンプルは3人のアノテーターがそれぞれ確認し、課題の説明が明確に規定されていること、単体テストが適切であること、評価の信頼性を損ないうる大きな問題がほかにないことを確かめた。それでもあいまいなサンプルが残っている可能性はあり、私たちは以前、誤りの割合を5〜10%と見積もった。

方法論

私たちのSWE-bench Verifiedの評価方法は、5つの要素からなる。

• モデルに指示を与えるプロンプトとその他の情報
• モデルの実行時に使うスキャフォールドとツール
• 評価に使うサンプル
• モデルの入出力の上限
• ベンチマークを実行する環境

プロンプトと情報：私たちが使うのはかなり単純なプロンプトで、SWE-benchの開発者によるbashだけを使う実行のプロンプトに近い。Anthropicのモデルで使われたSWE-bench Verifiedのプロンプトにも似ている。プロンプトの全文は、私たちのログビューアーで見られる。

プロンプトでは、モデルに課題（つまりSWE-benchが提供する課題の説明）、リポジトリ、使えるトークンの予算、使えるツールを伝える。また、テストを変更しないようにも指示する。テストを変更してはならないと伝えておくことは重要である。解答の採点には、リポジトリにある正解基準のテストを使うからだ。この指示がないと、モデルは概念的には正しいのに不合格と判定されるような形でコードをリファクタリングしてしまうかもしれない。たとえば、メソッドの名前を変えたり、返すデータ構造を変えたりした場合である。

スキャフォールドとツール：特に断りのない限り、私たちのスキャフォールドは単純なループで、モデルは一つの行動（たとえば推論とツールの呼び出し）をとり、その出力を見ることができる。各ターンのあと、モデルには残りのトークン予算が知らされる。また、Claude CodeやCodexなど、Inspect-SWEで評価した他のスキャフォールドの結果も載せている。これらには、トークン使用量を確認するためのツールを与える。

コマンドを実行するbashツール、ファイルの閲覧と編集のためのInspectのAnthropic方式のtext_editorツール、ファイルにパッチを当てるOpenAI方式のapply_patchツールを与える。いずれもツール呼び出しのAPIで呼び出す。これらのツールを採用したのは、コーディング向けの代表的な二つのLLMのAPIと結びついており、他の開発者にもよく採用されているからである。また、公開の仕様でしっかり定義されており、何世代ものコーディングモデルにわたって（小さな変更はあるものの）使われ続けている。

使うサンプル：私たちの基盤で安定して動作しない16件のサンプルは除外する。よく見られた問題としては、ネットワークへの接続を必要とするテストや、サンプルで指定された依存関係と合わないリポジトリのバージョンがある。このような除外は、AI開発企業が行う評価ではかなり一般的に行われてきた。たとえばGPT-5は477件の課題を、Sonnet-3.7は489件の課題を使った。その後のAnthropicのリリースでは、問題を修正したうえで500件すべての課題を使っている。SWE-benchの開発者は、公式リーダーボードの評価のためにこうした問題の多くを徐々に修正してきたが、いくつかの問題は残っているかもしれない。

評価には残りの484件のサンプル（テストの一覧を修正した1件を含む）を使う。これがSWE-bench全体の成績に与える影響は無視できるはずである。たとえば、SWE-benchのbashだけを使う設定のリーダーボードでのGPT-5 Miniの結果は、これらの課題を除外すると59.8%になる。すべてのサンプルを使った場合に報告されている値は59.9%である。¹

モデルの入出力の上限：モデルのトークン使用量は、キャッシュされない読み書きのトークン（推論を含む）で200万、キャッシュされたトークンの読み込みで2,000万までに制限する。上限は各ターンのあとに適用する。つまり、どちらかの上限を超えると、モデルはその直後のターンで現在の作業状態を提出させられる。トークン使用量はモデルの呼び出しを重ねるごとに二次関数的に増える。LLMが次のメッセージやツール呼び出しを生成するたびに、会話の履歴が入力として渡されるからである。実際には、ループから抜け出せなくなるといった異常な場合を除き、モデルがこれほど高い上限に達した例は見ていない。

サンプルを実行する環境：ベンチマークは、最低限の構成のLinuxベースのDockerコンテナ内で実行する。不正を防ぐため、ネットワークへの接続は許可しない。各サンプルの依存関係は、私たちが最初のDockerイメージを構築したときに使ったSWE-benchのバージョン（v2.1.0）の仕様に基づいてインストールする。Dockerコンテナを立ち上げるとき、そのサンプルの元のGitHub issueより後のgit履歴はすべて削除する。これにより、モデルが後のgit履歴に含まれる人間の解答を見て不正をするのを防ぐ。

変更履歴

2026年3月6日 GPT-5.1以降のOpenAIのモデルにツールを与える処理を整理し、Codexのネイティブツールを上書きしないようにする防止策も加えた。これらの変更は既存のスコアには影響しない見込みである。ベンチマークのバージョン番号はv2.0.3に上がった。

2026年2月13日 サードパーティのスキャフォールド（Claude CodeとCodex）を追加し、Googleのモデルの推論のトークン使用量が正しく数えられていなかった不具合を修正し、OpenAIのネイティブのapply_patchツールとshellツールの、GPT-5.1以降の新しい版を追加した。これらの変更は、すでに評価済みのモデルには適用されないため、既存のスコアには影響しない見込みである。バージョン番号はv2.0.2に上がった。

2026年2月13日 Inspectの依存関係を更新した。このベンチマークのスコアには影響しない見込みである。バージョン番号はv2.0.1に上がった。

2026年2月12日 スキャフォールド、環境、トークンの上限を大幅に改良した。このベンチマークのEpoch版をv2.0.0に更新し、主要なモデルを評価し直した。その結果、モデルの成績は大きく向上した。上の既定のグラフ表示では、v2.0.0以降の結果だけを示している。