SWE-benchのスコアは何を意味する？AIを選ぶときの見方

SWE-benchとは、AIが実際のGitHub上のバグ報告（Issue）を読んで、そのリポジトリのコードを直せるかを測るベンチマークです。用意された2,294件の課題に対してAIがパッチを生成し、修正前は失敗していたテストが通れば「解決（Resolved）」とみなす仕組みで、コーディングAIの実力を示す指標として広く使われています。ClaudeやGPT、Cursorといったツールの発表でよく出てくる「SWE-bench Verifiedで◯%」という数字は、ここから来ています。本記事では、SWE-benchが何を測るのか、スコア（%Resolved）の見方、Full・Lite・Verifiedの違い、そしてサイト制作や自社ツール開発でコーディングAIを選ぶときにこのスコアをどう読むかまでを筆者が整理します。

SWE-benchとは？何を測るベンチマークか

SWE-benchとは、言語モデルやAIエージェントが「実際のソフトウェア開発課題」を解決できるかを測る評価用のデータセットです。筆者が公式論文（ICLR 2024、プリンストン大学らによるSWE-bench）で確認したところ、GitHubの実在するIssueとプルリクエストのペアから作られた2,294件の課題で構成され、対象は12個の人気Pythonリポジトリです。AIにはIssueのテキストとリポジトリのコードだけを与え、問題を直すパッチ（コードの差分）を作らせます。

ポイントは、競技プログラミングのようなクイズではなく、現場で起きた本物のバグや要望を題材にしている点です。だからこそ「実務でどれだけ使えるコードを書けるか」に近い指標として、モデルやコーディングツールの発表で必ず引用されます。以降で、その測り方とスコアの意味を具体的に見ていきます。

SWE-benchが測る「実際のバグ修正力」

SWE-benchが評価するのは、単一の関数を書く力ではなく、リポジトリ全体を読んで正しいファイルの正しい箇所を直す力です。AIは、どのファイルが原因かを自分で探し、Issueの意図を理解し、周囲のコードを壊さずに修正する必要があります。実際の開発で人間がやっている「原因調査から修正まで」の一連の流れを、そのままタスクにしているのが特徴です。

従来のコーディングベンチと何が違うのか

SWE-benchが登場する前は、HumanEvalやMBPPのような「関数を1つ書かせる」ベンチマークが主流でした。両者の違いは、扱う問題の規模と現実味にあります。差分を表にまとめます。

出典：SWE-bench 公式論文（ICLR 2024, arXiv:2310.06770）で筆者が確認（2026年8月）。

Fail-to-Passテストという評価の仕組み

SWE-benchの判定は、テストの通過だけで決まります。各課題には、元のプルリクエストを当てる前は失敗し、当てた後は成功する「Fail-to-Pass」テストが紐づいています。AIが作ったパッチを適用してこのテストがすべて通れば正解、1つでも落ちれば不正解です。人間の主観が入らないため、モデル同士を同じ土俵で比べられるのが強みです。

関数単位のベンチが今も併用される理由

SWE-benchが実務寄りだからといって、HumanEvalのような関数単位のベンチが不要になったわけではありません。関数単位のベンチは、基礎的なコード生成力を短時間・低コストで測れるため、モデル開発の途中経過を追うのに向いています。対してSWE-benchは、環境構築やテスト実行にコストがかかる分、最終的な実力を示すのに向きます。筆者の整理では、両者は測る対象が異なる補完関係にあり、発表資料でも並べて示されることが多いです。目的に応じて、軽いベンチで当たりをつけ、SWE-benchで実力を確かめる、という読み方が実態に近いといえます。

SWE-benchのスコア（%Resolved）はどう見る？

SWE-benchのスコアは「%Resolved（解決率）」で表されます。これは、与えられた課題のうちAIが正しく解けた割合です。たとえば「SWE-bench Verifiedで50%」なら、500問中250問でテストを通すパッチを作れた、という意味になります。数字が高いほど、実際のバグ修正タスクをこなせる可能性が高いと読めます。

スコアの数え方（テスト全通過で正解）

1問を「解けた」と数えるには、その課題に紐づくFail-to-Passテストを全部通す必要があります。部分点はありません。惜しい修正でも、テストが1つでも落ちれば0点扱いです。この厳しさが、スコアの信頼性を支えています。

スコアを鵜呑みにできない理由

%Resolvedは、モデル単体の性能だけで決まるわけではありません。多くの高スコアは、モデルに加えて「どんなエージェント構成（ファイル探索やテスト実行の足回り）で解かせたか」を含んだ数値です。同じモデルでも、周辺のツールや試行回数が変われば結果は動きます。発表されたスコアを見るときは、素のモデルの数字なのか、エージェント込みの数字なのかを区別することが大切です。

SWE-bench Full・Lite・Verified・Multimodalの違い

SWE-benchには、目的に応じた複数のサブセットがあります。発表で最もよく使われるのはVerifiedです。それぞれの件数と用途を表で整理します。

出典：SWE-bench 公式リポジトリ・公式論文で筆者が確認（2026年8月）。Multimodalは2025年1月13日公開、テスト分割は非公開。

なぜVerifiedがよく使われるのか

Verifiedがモデル比較の標準になっているのは、品質のばらつきを人手で取り除いてあるからです。筆者が確認した公式の説明では、Verifiedは実際のソフトウェアエンジニアが「この課題はちゃんと解ける」と確認した500問で構成され、OpenAIのPreparednessチームと共同で作られました。元のFullには、Issueの記述が曖昧だったりテストが不適切だったりする課題も混じっていたため、そこを除いた集合が必要とされたわけです。だからニュースで見る「◯%」の多くはVerifiedの数字です。

FullとVerifiedのスコアは直接比べない

注意したいのは、FullとVerifiedのスコアを並べて優劣を語れない点です。対象の問題集合が違うため、同じモデルでもFullとVerifiedでは%Resolvedが変わります。比較するときは、必ず同じサブセット同士で見比べてください。

MultimodalとMultilingualという派生

SWE-benchは、Python以外の弱点を補う派生も広げています。Multimodalは、スクリーンショットなど視覚要素を含む課題を扱い、UIやフロントエンド寄りの実力を測ります。筆者が確認した公式情報では、テストの分割を非公開にすることで、学習データへの流出を防ぐ設計になっています。加えて、Pythonに限定しない多言語版のMultilingualも用意されており、対象言語を広げた評価が進んでいます。自分の現場が扱う言語や領域に近い派生を選ぶと、スコアの読み違いを減らせます。

SWE-benchのスコアはどこで見られる？

公式のリーダーボードで確認できます。SWE-benchの公式サイト（swebench.com）に、モデルやエージェントごとの%Resolvedが一覧で掲載されています。新しいモデルが出るたびに更新されるため、コーディングAIの現在地を把握する定点観測に使えます。

リーダーボードの列の読み方

リーダーボードを見るときは、いくつかの列に注目します。まず対象サブセット（Verifiedなのか、Fullなのか）を確認し、次に%Resolvedの数値を見ます。エントリー名にはモデル名だけでなくエージェントの名前が併記されていることが多く、これが「エージェント込みの数値」であるサインです。素のモデル性能を知りたいときと、実運用に近い数値を知りたいときで、見るべき行が変わります。

コーディングAI選びでSWE-benchスコアをどう活かすか

ここからは、筆者の実務である「サイト制作」と「効率化のための自社ツール開発」で、SWE-benchのスコアをどう使うかを紹介します。数字を眺めるだけで終わらせず、モデル選定の判断材料に落とし込むのが狙いです。

モデル選定でスコアを読むチェックリスト

コーディングAI（Claude Code・Cursorなど）を業務に入れるとき、SWE-bench Verifiedのスコアは有力な一次情報になります。ただし数字だけで決めず、次の観点とセットで見ると外しにくくなります。

この差がアウトプットにどう出るかは、仕様から次のように想定できます。Verifiedのスコアが高いモデルほど、リポジトリ横断の調査と修正を要する実タスクでの適用が期待できると考えられます。一方で対象がPython中心のため、たとえばフロントのTypeScript案件が多い現場では、スコアの高さがそのまま自社の成果に直結するとは限らないと想定されます。いずれも筆者の実測ではなく、ベンチの仕様からの想定です。

公開スコアと自社タスクの差を埋める：小さくevalする手順

公開スコアはあくまで一般的な指標です。自社の案件に本当に合うかは、手元の実タスクで小さく試すのが確実です。大がかりなベンチを回さなくても、SWE-benchの考え方（Fail-to-Passで判定する）を真似れば、自前の簡易評価が組めます。

# 1. 過去に自分たちが直したバグを3〜5件選ぶ
#    （修正前のコミットと、通るべきテストがある状態）

# 2. 修正前の状態をAIに渡す
#    「このテストが通るように直して」とIssue文とコードを与える

# 3. AIのパッチを適用してテストを実行
pytest    # もしくは各プロジェクトのテストコマンド

# 4. テストが全通過した件数 ÷ 課題数 = 自社版スコア
#    複数モデルで同じ課題を回して比較する

この方法なら、公開スコアでは見えない「自社のコードベースやテスト文化との相性」を数字で確かめられます。数件でも回してみると、リーダーボード上位が自社案件でも上位とは限らないことがはっきりします。モデル比較の考え方は、Claude Opus 5の解説や、コーディングツールのGrok Buildの使い方とあわせて読むと、選定の軸が定まります。

SWE-benchの注意点・限界

便利な指標ですが、万能ではありません。使う前に知っておきたい限界が3つあります。第一に、対象が12のPythonリポジトリ中心のため、他言語やフロント寄りの実力はそのままでは測れません。第二に、有名なオープンソースが題材のため、モデルの学習データに答えが混じっている可能性（データ汚染）が指摘されています。第三に、前述のとおりスコアはエージェント構成に左右されるため、モデル単体の力とは切り分けて読む必要があります。だからこそ、リーダーボードは出発点にとどめ、最終判断は自社タスクでの検証と組み合わせるのが堅実です。

データ汚染（コンタミネーション）の懸念

SWE-benchの題材は、公開されている有名なオープンソースです。そのため、モデルの学習データに元の修正コードが含まれてしまい、実力以上のスコアが出る「データ汚染」の懸念が指摘されています。新しいモデルほど新しいデータを学習しているため、この影響を完全に切り分けるのは簡単ではありません。筆者の見方では、公開スコアはこの前提を踏まえて「上振れの可能性がある数値」として読み、自社の非公開タスクでの検証を併用するのが安全です。

スコアの更新が速い点にも注意

SWE-benchのスコアは、年単位で大きく上がり続けています。少し前まで難しいとされた水準を、新しいモデルとエージェントが次々に超えていく状況です。つまり「◯%は高い」という感覚は短期間で古くなります。数値を見るときは絶対値ではなく、同時期の他モデルとの相対位置で捉えるのが、判断を誤らないコツです。

SWE-benchに関するよくある質問

SWE-bench Verifiedとは何ですか？

SWE-bench Verifiedは、実際のエンジニアが「解ける」と人手で確認した500問のサブセットです。元のSWE-benchにあった曖昧な課題を除いてあり、モデル比較の標準として最もよく使われます。ニュースで見る「SWE-benchで◯%」の多くはこのVerifiedの数値です。

スコアは何%あれば良いと言えますか？

絶対的な合格ラインはありません。SWE-benchは相対比較の指標で、同時期の他モデルと比べてどうか、で読むものです。数値は年々上がっているため、「いつ時点の、どのサブセットの数字か」をセットで見るのが正しい読み方です。

日本語での開発に関係ありますか？

課題文もコードも英語・Pythonが中心のため、日本語UIやドキュメントの評価そのものではありません。ただしコードを直す力自体は言語をまたいで役立つため、日本語環境でコーディングAIを選ぶ際の参考指標にはなります。

SWE-benchは自分でも回せますか？

公式リポジトリが公開されており、環境を用意すれば自分でも評価を実行できます。ただしフルセットは計算コストが高いため、まずはLite（300件）や、自社の実タスクを使った簡易評価から始めるのが現実的です。

LiteとVerifiedはどちらを見ればいい？

モデル同士の実力比較ならVerifiedが標準です。Liteは件数が少なく手早く試せるため、自分で評価を回すときの入り口に向きます。公開されたスコアを読む目的なら、Verifiedを基準に見ておけば大きく外しません。

まとめ：SWE-benchは「実バグを直せるかの指標」

SWE-benchを一言でいえば、AIが実在のバグを直せるかを、テストの通過で白黒つける指標です。読み解くコツは、①どのサブセット（多くはVerified）か ②素のモデルかエージェント込みか ③いつ時点か、の3点を必ず確認することです。そのうえで、公開スコアは候補を絞る出発点として使い、最終判断は自社の実タスクで小さくevalして確かめるのが失敗しない進め方です。モデルごとの特徴はClaude Opus 5の解説、コーディングツールの選択はGrok Buildの使い方とあわせて検討すると、数字に振り回されずに選べます。