話題のベンチマーク: DeepSWEについて
本文の状態
日本語全文を表示中
詳細モードで約7分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Algomatic Tech Blog
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
株式会社 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 欄に書かれた既存パーサーの問題を考慮して適切に対応する必要があり、全体設計力・構成力が求められます。
翻訳全文
注釈：プロパティや必須項目は指定されているが明示的な '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
翻訳全文
原文を表示
株式会社Algomaticのしぶや（@sergicalsix）です。
こちらはAlgomatic 初夏のアドベントカレンダー2日目の投稿となります。
前日分はこちらです。
今回のテーマは今話題のコーディングエージェントの性能を測るベンチマークであるDeepSWEについてです。
本記事では、DeepSWE がどのような特徴があるか、実際のリーダーボードや具体的なタスク例を交えながら見ていきます。
少しでも参考になれば幸いです。
DeepSWE[1]とはDatacurve社が公開した「実務に近いコーディングエージェント評価ベンチマーク」です。
実際のDeepSWEのリーダーボードは以下図1の通りであり、一般的にコーディング性能が高いとされるGPT-5.5のxhighモデルが性能トップとなっています。
以降では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が既存のハーネスよりも性能が劣っていないことがわかります。
上述したDeepSWEの特徴より、DeepSWEはSWE-Bench Proと比べてモデル間のスコア差が大きいです。このことからDeepSWEは、SWE-Bench Proと比べて解像度高くモデルのコーディングに関する性能を測れていることが示唆されます。
透明性・DeepSWEの実際の中身
DeepSWEの結果、それぞれのタスクは詳細に公開されています。
ヒートマップより各モデルが解けたタスク・解けなかったタスクを簡単に確認できます。
ここで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は私個人として参考になる部分が多いので、これを機にご覧になると良いかもしれません。
また採用も強化中ですので、気になる方は以下よりカジュアル面談等お待ちしています。
参考文献
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み