まとまった機能の実装をAIに任せられれば、開発責任者の仕事は、コードを書く作業の割り振りから、求める動作を決めて成果物を確認する工程へと比重が移る可能性があります。その判断には、AIが課題を解けるかに加え、費用と確認の負担を分けて見る必要があります。
長いソフトウェア開発課題を対象とするベンチマーク、つまり能力を比較するための評価課題群がDeepSWEです。2026年5月26日に公開され、6月14日のv1.1では、課題を変えずに採点環境を見直しました。9月9日の確認では、評価表に113課題と9月3日更新の表示があり、正答率のほか、平均費用、出力トークン、エージェントのステップ数が掲載されています。
これらの項目は、AIに仕事を任せる際の判断材料になります。ただし、評価表の順位だけで、自社で任せられる仕事の範囲まで決まるわけではありません。
課題を解いたコードを、動作で採点する
評価の流れは、開発課題に取り組ませ、提出されたコードの動作を調べ、その結果を正答率などで示すというものです。
入力に当たる課題について、作成者は、既存のコミットやPRを改作せずに作ったと説明しています。コミットはコードの変更を記録したもの、PRは変更を取り込んでもらうための提案です。対象は91のリポジトリ、つまりコードなどの保管場所と、5つのプログラミング言語に及ぶとしています。
提出されたコードを調べるのが、検証器です。成果物が課題の条件を満たすかを確認する仕組みで、作成者は、実装の形よりも動作を調べる検証器を手で作ったと説明しています。決まった書き方に似ているかより、求めた動作を実現できるかに評価の軸を置いた設計と読めます。
v1.1では、コミットしたコードを新しい隔離環境で採点します。隔離環境とは、ほかの作業環境から切り離してコードを実行する場所です。あわせて、コードが利用する外部ソフトウェアの組み合わせなどに関わる「依存関係」のずれや、不安定なテストも修正したと報告されています。同じ課題でも、提出後に採点する条件を見直した更新です。
その出力として、正答率や平均費用などの評価結果を読みます。ここで、独自に課題を作ったという説明と、学習データへの混入がないという保証は区別する必要があります。作成方法の説明だけから、未知の混入まで一切ないとは判断できません。
正答率と費用は同じ版で比べる
正答率は、課題に正答した割合です。高いほど、その評価条件で成功した課題が多いと読めます。平均費用は支出を見る指標で、同程度の成果を得られるなら低い方が費用を抑えられます。ただし、安さだけでは、成果物が必要な動作を満たすかは分かりません。
出力トークンは、AIが生成した文章やコードの量を数える単位です。エージェントは作業を進めるAIの仕組みを指し、そのステップ数は作業の進め方を見る補助になります。どちらも、少なければ品質が高いと判断できる指標ではありません。ステップ数を、人が確認に使う時間や実際の所要時間にそのまま置き換えることもできません。
また、v1.1は課題を維持しながら採点条件を変えています。異なるバージョンの値を直接並べて、AIの能力が伸びた、落ちたと結論づけるのは避けるべきです。順位は版と更新日を確認し、その時点の条件で得られた結果として読みます。