話題のベンチマーク: DeepSWEについて
Datacurve 社が公開した実務に近いコーディングエージェント評価ベンチマーク「DeepSWE」の特徴と、GPT-5.5 xhigh がトップとなるリーダーボードの現状について解説している。
キーポイント
DeepSWE の3大特徴
タスクの妥当性（実務に近い）、評価の妥当性（コンタミネーションなし）、透明性（再現性・追跡可能）を重視した設計となっている。
現在のリーダーボード状況
2026 年 6 月時点のデータでは、一般的に高性能とされる GPT-5.5 の xhigh モデルがトップを獲得している。
評価ベンチマークの意義
既存のベンチマークとの差別化として、再現可能性やトラッキング機能を強化し、より信頼性の高いエージェント性能測定を目指す。
Long-Horizon Tasks とプロンプト設計
DeepSWE は冗長な指示を避け、エージェントが自ら実装方法を発見するよう設計されたプロンプトを使用し、多数のステップを要する Long-Horizon Tasks を評価対象としています。
多言語対応と高品質リポジトリ
SWE-Bench が Python 限定であるのに対し、DeepSWE は TypeScript や Rust など 5 つの主要言語に対応し、GitHub で高い評価を得たオープンソースリポジトリのみを対象としています。
コンタミネーション対策と統一評価環境
既存データ由来ではない新規作成タスクにより学習データのコンタミネーションを排除し、SWE-bench 開発者が構築した mini-swe-agent を用いて評価条件を統一的に保っています。
DeepSWEの解像度の高さ
SWE-Bench Proと比較してモデル間のスコア差が大きいため、コーディング性能をより細かく測定できる高い解像度を持つと示唆されています。
影響分析・編集コメントを表示
影響分析
本記事は、コーディングエージェントの評価基準が単なる正答率から「実務適合性」と「評価プロセスの透明性」へとシフトしていることを示唆しています。GPT-5.5 の優位性が確認される一方で、ベンチマーク自体の信頼性向上が業界全体の技術比較をより公平かつ実践的なものにする可能性があります。
編集コメント
コーディングエージェントの性能評価において、ベンチマークの設計思想（特にコンタミネーション防止と再現性）が重要視される潮流を捉えた内容です。
株式会社 Algomatic のしぶや（@sergicalsix）です。
こちらは Algomatic 初夏のアドベントカレンダー 2 日目の投稿となります。
前日分はこちらです。
tech.algomatic.jp
今回のテーマは今話題のコーディングエージェントの性能を測るベンチマークである DeepSWE についてです。
deepswe.datacurve.ai
本記事では、DeepSWE がどのような特徴があるか、実際のリーダーボードや具体的なタスク例を交えながら見ていきます。
少しでも参考になれば幸いです。
DeepSWE[1]とは Datacurve 社が公開した「実務に近いコーディングエージェント評価ベンチマーク」です。
実際の DeepSWE のリーダーボードは以下図 1 の通りであり、一般的にコーディング性能が高いとされる GPT-5.5 の xhigh モデルが性能トップとなっています。
image図 1: DeepSWE のリーダーボード (6/2 時点)[2]
以降では DeepSWE を細かく見ていきます。
DeepSWE の詳細
DeepSWE は、タスクが現実に即しており、適切にコーディング性能を評価しているといったタスクの妥当性、コンタミネーションがなく評価の手続が適切かといった評価の妥当性、タスクおよび結果が再現可能でトラッキングできるといった透明性の 3 つの特徴を持ちます。
以下それぞれについて解説していきつつ、透明性の節にて DeepSWE のタスクや結果について少し中身を見ていきます。
タスクの妥当性
DeepSWE のプロンプトは、開発者がエージェントと対話する方法に合わせて設計されています。具体的には冗長で指示的なものではないため、エージェントはどのようにファイルに変更を加えるべきか・どのように実装するかを自ら発見する必要があります。
相対値の比較となりますが、SWE-Bench Pro と比べてプロンプトの量は半分かつ、変更すべき箇所は 5.5 倍以上となります。
またこのように、タスク完遂のために、多数のステップを積み重ねる必要があるタスクを Long-Horizon Tasks（長期ホライズン・タスク）と呼びます (DeepSWE のブログでも言及されています)。直近だと、以下 5 月 4 日の Microsoft の報告などで Long-Horizon Tasks については言及されているので、ご興味がある方はぜひご覧ください。
多様性の観点から見ると、従来のベンチマークである SWE-Bench や SWE-Bench Verified は言語が Python 限定であるのに対し、DeepSWE は TypeScript、Go、Python、JavaScript、Rust の 5 つの言語に対応しています。
(余談ですが、現実でよく見られる Java や C++ がタスクに含まれていないことは Blog にて記載されており、今後追加予定とのことです。)
また DeepSWE は 91 のオープンソースリポジトリを対象とした 113 のタスクで構成されています。オープンソースのリポジトリは積極的にメンテナンスされ、GitHub で 500 以上のスターを獲得しているもの (=品質が一定高いもの) に限っています。
評価の妥当性・信頼性
既存のベンチマークでは既存の PR(プルリクエスト) 由来のデータを使っており、コンタミネーション (汚染) が指摘されていました。
コンタミネーションが起きると、本来課題解決能力を図りたいはずのベンチマークにおいてモデルの記憶力が試されてしまいますし、近年のモデルはその記憶力が高いので、スコアは上昇傾向となり、モデル間の差が出にくくなります。
DeepSWE は、上記コンタミネーションの課題に対応しています。本プロジェクトのタスクは既存のコミットやプルリクエストから作成されず、一から作成されています。よってモデルが DeepSWE の答えを事前学習することはありません。
またそれぞれのタスクは、LLM(大規模言語モデル) による分析と独立した人間のレビューの両方を経て採用されるので一定以上の品質のタスクのみで構成されている可能性が高いです。（後続でベンチマークの中身の話をするのですが、筆者は全件まだ見ていないので、こういった曖昧な言葉で記述しています。）
評価には SWE-bench の開発者が構築したハーネスである mini-swe-agent が使用されます。
これにより Codex や Claude Code といったビルダー側のハーネスの違いによるモデルの性能変化を防ぐことができます。
mini-swe-agent は専用のプロンプト群と bash ツールを持っています。詳細は以下の通りです。
また mini-swe-agent と既存のハーネスとの性能比較は以下であり、mini-swe-agent が既存のハーネスよりも性能が劣っていないことがわかります。
image図 2: mini-swe-agent の性能比較 [2]
上述した DeepSWE の特徴より、DeepSWE は SWE-Bench Pro と比べてモデル間のスコア差が大きいです。このことから DeepSWE は、SWE-Bench Pro と比べて解像度高くモデルのコーディングに関する性能を測れていることが示唆されます。
image図 3: SWE-Bench Pro と DeepSWE の違い [2]
透明性・DeepSWE の実際の中身
DeepSWE の結果、それぞれのタスクは詳細に公開されています。
image図 4: DeepSWE の結果 (ヒートマップ)[3]
ヒートマップより各モデルが解けたタスク・解けなかったタスクを簡単に確認できます。
ここで GPT-5.5 と Claude Opus 4.7 それぞれで差があったタスクを一つずつピックアップしてみていきます。
GPT-5.5 の方が正答率が高いタスク:Add shorthand expansion and compression to the lexer
このタスクは CSS のレキサー (lexer) に 2 つのメソッドを追加するというタスクです。（詳細は下記リンクよりご確認ください。）
https://deepswe.datacurve.ai/data/tasks/csstree-shorthand-expansion-compression
難所は以下のバックグラウンドの処理などであり、こちらは複雑な要件を正確に実装できたかどうかを測ることができるタスクであると言えます。（と筆者は解釈しています。）
The background shorthand expands to background-image, background-position, background-size, background-repeat, background-origin, background-clip, background-attachment, and background-color, and supports comma-separated layers where each longhand receives a comma-separated list of its per-layer values, with background-color applying only to the final layer.
また余談ですが、筆者は GPT-5.5 の方が Claude Opus 4.7 より正確なコーディングができるという肌感覚であり、筆者の肌感覚と一致します。
Claude Opus 4.7 の方が正答率が高いタスク:Add JSON Schema refs and dependency keywords
このタスクは JSON Schema パーサーに JSON Schema の参照 ($ref) と依存関係キーワードを実装するタスクです。（詳細は下記リンクよりご確認ください。）
https://deepswe.datacurve.ai/data/tasks/arktype-json-schema-refs-dependencies
Note 欄に書かれた既存パーサーの問題を考慮して適切に対応する必要があり、全体設計力・構成力が求められます。
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
注釈：プロパティや必須項目は指定されているが明示的な 'type' がなく、暗黙のオブジェクトスキーマ検出が行われない場合、パーサーは then/else スキーマを拒否します。parseJsonSchema 関数にフォールバックを追加し、'properties'、'required'、'patternProperties'、'additionalProperties'、'maxProperties'、'minProperties'、'propertyNames'、'dependencies'、'dependentRequired'、'dependentSchemas' のようなオブジェクトキーワードを含みながら 'type' を持たないスキーマを、暗黙的に型："object" のスキーマとして扱うようにしてください。
anyOf 構成内の再帰的な $ref はバグを含む結果を生じる可能性があります。anyOf の各分岐が $defs を参照している際に解決された型をショートサーキットしたり二重にラップしたりしないよう、構成前にエイリアスノードを完全に解決しておく必要があります。
また DeepSWE は以下を参考にすると簡単に追試が可能です。
git clone https://github.com/datacurve-ai/deep-swe
uv tool install git+https://github.com/datacurve-ai/pier
Claude Opus 4.7 via Claude Code
export ANTHROPIC_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model anthropic/claude-opus-4-7
GPT-5.5 via Codex
export OPENAI_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model openai/gpt-5.5
さいごに
本記事では、DeepSWE を「タスクの妥当性」「評価の妥当性」「透明性」の3つの観点から見てきました。
ベンチマークは昨今重要視されない傾向にありますが、一定ベンチマークの結果から見えてくることもあるかなと思っています。
特に DeepSWE は私個人として参考になる部分が多いので、これを機にご覧になると良いかもしれません。
また採用も強化中ですので、気になる方は以下よりカジュアル面談等お待ちしています。
参考文献
https://deepswe.datacurve.ai/blog
https://deepswe.datacurve.ai/data
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
原文を表示
株式会社Algomaticのしぶや（@sergicalsix）です。
こちらはAlgomatic 初夏のアドベントカレンダー2日目の投稿となります。
前日分はこちらです。
今回のテーマは今話題のコーディングエージェントの性能を測るベンチマークであるDeepSWEについてです。
本記事では、DeepSWE がどのような特徴があるか、実際のリーダーボードや具体的なタスク例を交えながら見ていきます。
少しでも参考になれば幸いです。
DeepSWE[1]とはDatacurve社が公開した「実務に近いコーディングエージェント評価ベンチマーク」です。
実際のDeepSWEのリーダーボードは以下図1の通りであり、一般的にコーディング性能が高いとされるGPT-5.5のxhighモデルが性能トップとなっています。
![図1: DeepSWEのリーダーボード(6/2時点)[2]](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sergicalsix/20260602/20260602070249.png)
以降ではDeepSWEを細かく見ていきます。
DeepSWEの詳細
DeepSWEは、タスクが現実に即しており、適切にコーディング性能を評価しているといったタスクの妥当性、コンタミネーションがなく評価の手続が適切かといった評価の妥当性、タスクおよび結果が再現可能でトラッキングできるといった透明性の3つの特徴を持ちます。
以下それぞれについて解説していきつつ、透明性の節にてDeepSWEのタスクや結果について少し中身を見ていきます。
タスクの妥当性
DeepSWEのプロンプトは、開発者がエージェントと対話する方法に合わせて設計されています。具体的には冗長で指示的なものではないため、エージェントはどのようにファイルに変更を加えるべきか・どのように実装するかを自ら発見する必要があります。
相対値の比較となりますが、SWE-Bench Proと比べてプロンプトの量は半分かつ、変更すべき箇所は5.5倍以上となります。
またこのように、タスク完遂のために、多数のステップを積み重ねる必要があるタスクをLong-Horizon Tasksと呼びます(DeepSWEのブログでも言及されています)。直近だと、以下5月4日のMicrosoftの報告などでLong-Horizon Tasksについては言及されているので、ご興味がある方はぜひご覧ください。
多様性の観点だと、従来のベンチマークであるSWE-BenchやSWE-Bench Verifiedは言語がPython限定であるのに対して、DeepSWEはTypeScript、Go、Python、JavaScript、Rustの5つの言語に対応しています。
(余談ですが、現実でよく見られるJavaやC++がタスクに含まれていないことはBlogにて記載されており、今後追加予定とのことです。)
またDeepSWEは91のオープンソースリポジトリを対象とした113のタスクで構成されています。オープンソースのリポジトリは積極的にメンテナンスされ、GitHubで500以上のスターを獲得しているもの(=品質が一定高いもの)に限っています。
評価の妥当性・信頼性
既存のベンチマークでは既存のPR由来のデータを使っており、コンタミネーションが指摘されていました。
コンタミネーションが起きると、本来課題解決能力を図りたいはずのベンチマークにおいてモデルの記憶力が試されてしまいますし、近年のモデルはその記憶力が高いので、スコアは上昇傾向となり、モデル間の差が出にくくなります。
DeepSWEは、上記コンタミネーションの課題に対応しています。のタスクは既存のコミットやプルリクエストから作成されず、一から作成されています。よってモデルがDeepSWEの答えを事前学習することはありません。
またそれぞれのタスクは、LLMによる分析と独立した人間のレビューの両方を経て採用されるので一定以上の品質のタスクのみで構成されている可能性が高いです。（後続でベンチマークの中身の話をするのですが、筆者は全件まだ見ていないので、こういった曖昧な言葉で記述しています。）
評価にはSWE-benchの開発者が構築したハーネスであるmini-swe-agentが使用されます。
これによりCodexやClaude Codeといったビルダー側のハーネスの違いによるモデルの性能変化を防ぐことができます。
mini-swe-agentは専用のプロンプト群とbashツールを持っています。詳細は以下の通りです。
またmini-swe-agentと既存のハーネスとの性能比較は以下であり、mini-swe-agentが既存のハーネスよりも性能が劣っていないことがわかります。
![図2: mini-swe-agentの性能比較[2]](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sergicalsix/20260602/20260602072606.png)
上述したDeepSWEの特徴より、DeepSWEはSWE-Bench Proと比べてモデル間のスコア差が大きいです。このことからDeepSWEは、SWE-Bench Proと比べて解像度高くモデルのコーディングに関する性能を測れていることが示唆されます。
![図3: SWE-Bench ProとDeepSWEの違い[2]](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sergicalsix/20260602/20260602104706.png)
透明性・DeepSWEの実際の中身
DeepSWEの結果、それぞれのタスクは詳細に公開されています。
![図4: DeepSWEの結果(ヒートマップ)[3]](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sergicalsix/20260602/20260602095216.png)
ヒートマップより各モデルが解けたタスク・解けなかったタスクを簡単に確認できます。
ここでGPT-5.5とClaude Opus 4.7それぞれで差があったタスクを一つずつピックアップしてみていきます。
GPT-5.5の方が正答率が高いタスク: Add shorthand expansion and compression to the lexer
このタスクはCSSのレキサー(lexer)に2つのメソッドを追加するというタスクです。（詳細は下記リンクよりご確認ください。）
https://deepswe.datacurve.ai/data/tasks/csstree-shorthand-expansion-compression
難所は以下のバックグラウンドの処理などであり、こちらは複雑な要件を正確に実装できたかどうかを測ることができるタスクであると言えます。（と筆者は解釈しています。）
The background shorthand expands to background-image, background-position, background-size, background-repeat, background-origin, background-clip, background-attachment, and background-color, and supports comma-separated layers where each longhand receives a comma-separated list of its per-layer values, with background-color applying only to the final layer.
また余談ですが、筆者はGPT-5.5の方がClaude Opus 4.7より正確なコーディングができるという肌感覚であり、筆者の肌感覚と一致します。
Claude Opus 4.7の方が正答率が高いタスク: Add JSON Schema refs and dependency keywords
このタスクはJSON SchemaパーサーにJSON Schemaの参照($ref)と依存関係キーワードを実装するタスクです。（詳細は下記リンクよりご確認ください。）
https://deepswe.datacurve.ai/data/tasks/arktype-json-schema-refs-dependencies
Note欄に書かれた既存パーサーの問題を考慮して適切に対応する必要があり、全体設計力・構成力が求められます。
Note: then/else schemas with properties/required but no explicit 'type' are rejected by the parser without implicit object schema detection: add a fallback in parseJsonSchema that treats schemas containing object keywords (properties, required, patternProperties, additionalProperties, maxProperties, minProperties, propertyNames, dependencies, dependentRequired, dependentSchemas) but no 'type' as implicit type: "object" schemas.
Recursive $ref inside anyOf composition can produce buggy results: ensure alias nodes are fully resolved before composition so that anyOf branches referencing $defs do not short-circuit or double-wrap the resolved type.
またDeepSWEを以下を参考にすると簡単に追試が可能です。
git clone https://github.com/datacurve-ai/deep-swe
uv tool install git+https://github.com/datacurve-ai/pier
# Claude Opus 4.7 via Claude Code
export ANTHROPIC_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model anthropic/claude-opus-4-7
# GPT-5.5 via Codex
export OPENAI_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model openai/gpt-5.5さいごに
本記事では、DeepSWE を「タスクの妥当性」「評価の妥当性」「透明性」の3つの観点から見てきました。
ベンチマークは昨今重要視されない傾向にありますが、一定ベンチマークの結果から見えてくることもあるかなと思っています。
特にDeepSWEは私個人として参考になる部分が多いので、これを機にご覧になると良いかもしれません。
また採用も強化中ですので、気になる方は以下よりカジュアル面談等お待ちしています。
参考文献
関連記事
[AINews] FrontierCode：コードの質を評価するベンチマーク「Slop」への対抗
Latent Space が、AI 生成コードの質を測定する新ベンチマーク「FrontierCode」を発表し、低品質な出力（Slop）との戦いを開始した。
非同期コーディングエージェント「Open SWE」の公開を発表
LangChain が、開発者がコードを生成・修正できる非同期型のオープンソースコーディングエージェント「Open SWE」を公開した。
ゲオルギ・ジェルガノフ氏への言及：Qwen3.6-27B のコーディング能力について
Simon Willison は、Georgi Gerganov 氏が Qwen3.6-27B モデルをローカル環境でコーディングタスクにほぼ毎日使用しており、実用的なツールとして非常に有能力であると証言していることを紹介した。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み