実世界ベンチマーク、コーディングエージェントは大半のタスクで依然として人間による修正が必要と判定

実際のユーザーリクエストを基に構築された新たなベンチマークによると、AIコーディングエージェントはソフトウェア変更の大部分を完了できても、完全に動作する結果を提供できない場合がある。テストでは、最も強力なシステムでさえ、タスクに必要なすべての部分を完了できたのは26.4%にすぎなかった。つまり、ほぼ4件中3件で人間による修正が必要だった。

Co-Design Benchと呼ばれるこのベンチマークは、Alibabaと複数のアジアの大学の研究者によって開発された。The Decoderの報道によると、孤立したプログラミング問題ではなく、既存のウェブアプリケーションへの変更を通じてエージェントを評価する。タスクには画像などの視覚的リファレンス、音声、動画、ドキュメントが含まれる場合があり、プロダクトチームやエンジニアリングチームがAIツールに与える入力が複合的になっている現状を反映している。

コーディングエージェントに対する、より難しいテスト

Co-Design Benchは、研究者が既存のコーディング評価について「飽和」と表現する状況に対応するために設計された。モデルが自らコードを実行、検査、修正できる場合、従来の一部のベンチマークでは99%を超えるスコアを達成でき、システム間の違いを見分ける余地がほとんどなくなる。

新しいテストはその代わりに、実際のコーディングセッションから得られたリクエストを利用する。研究者は、ユーザーがすでにリクエストの言い換えや、失敗した変更のロールバックを必要としていたケースを選んだ。これらには、レシートから金額を抽出して関連する合計を更新する比較的狭い作業から、より広範なアプリケーションの再設計までが含まれる。

この設計により、ベンチマークは整理された自己完結型のコーディング演習よりも、稼働中のプロダクトを保守する際に伴う複雑な作業をよりよく表すものとなっている。同時に、結果をあらゆるコーディングワークフローの普遍的な指標として読むべきではないということでもある。ただし、もっともらしいコードを生成することと、ユーザーのリクエスト全体を完了することの間にある差は明確に示している。

26.4%という結果を裏付ける証拠

The Decoderが紹介した論文によると、GPT-6 Astraはテスト対象となった10モデルの中で最も高い性能を示した。平均でタスク要件の約70%を満たしたが、完全に解決できたタスクは26.4%にすぎなかった。タスクは、必要な機能がすべてアプリケーション内で動作した場合にのみ完了と判定された。

報告されたランキングではClaude Opus 5とQwen3.8-MaxがGPT-6 Astraに続き、Grok 4.6が最下位となった。大規模なアプリケーション改修では、より小型のQwen3.8-27Bが2位に上昇したが、研究者はこの結果をモデルの一般的な優位性の証拠とはみなしていない。

評価プロセスも、単純なコードレビューより厳格だった。1つの自動判定システムが完成したアプリケーションをブラウザでテストし、2人目のレビュアーが肯定的な結果を確認するとともに、視覚的なモックアップ、ハードコードされた出力、その他のショートカットを調べた。これらは、基礎となる動作を実装せずにリクエストを満たしたように見せる可能性がある。

これは研究結果であり、独立して検証された導入率や生産性の測定ではない。ベンチマークの著者は、自動判定システムが誤る可能性を認めている。また、タスクでは、ユーザーが質問に答えたり作業途中でエージェントを修正したりできるライブの対話ではなく、1つの固定されたリクエストを使用している。したがって結果は、このテスト設定でエージェントがどこで苦戦したかを示すものであり、あらゆる本番環境で必要となる人間の作業量を正確に示すものではない。

モデルはシステムの一部にすぎない

このベンチマークの最も重要な発見の1つは、エージェントハーネスに関するものだ。これは、モデルがファイルを読み、コードを変更し、アプリケーションを実行し、結果を検査できるようにするソフトウェア環境を指す。別の比較では、Qwen3.8-27Bは、より大規模な改修において、あるハーネスでは75%だったが、別のハーネスでは56%にとどまった。2つのモデルの相対的な順位も環境によって変化した。

この結果は、コーディングエージェントをモデルのリーダーボードだけで比較する慣行に疑問を投げかける。モデルの性能は、呼び出せるツール、受け取るコンテキスト、ブラウザの挙動を観察する方法、誤った変更から回復する能力に左右される。AIコーディングアシスタントを評価する購入者にとって、実際に比較すべき単位はモデルとハーネスの組み合わせとなる。

この研究は、追加の計算量が確実に差を縮めるわけではないことも示した。GLM-5.2は小規模な変更でGPT-6 Astraのほぼ6倍のトークンを使用したが、スコアは大幅に低かった。より多くの推論や長い実行が一部のタスクで役立つ可能性はあるものの、トークン使用量の増加は、より良いタスク分解、テスト、アプリケーションとの対話の代わりにはならないことを示唆している。

開発者と企業にとっての意味

エンジニアリングチームにとって直ちに導かれる結論は、AIコーディングエージェントは、プロダクト変更を自律的に担う存在というより、監督下で実装を支援するパートナーとして最も有用だということだ。エージェントは機能の大部分を作成できるかもしれないが、チームは依然としてエッジケース、視覚的な忠実度、データ処理、要件間の相互作用を確認する必要がある。

レイアウト、デザイン、インタラクション、コンテンツの変更を組み合わせるタスクでは、リスクが特に高い。複数の変更タイプを組み合わせるほど、モデル全体で性能が低下した。こうした相互に絡み合った要件は、実際のプロダクト開発では一般的であるにもかかわらずだ。各リクエストを単一のプロンプトとして扱うワークフローでは、説得力のある部分的な実装を生成しながら、重要な詳細を未完成のまま残す可能性がある。

ツールを評価するチームは、新規開発の例だけでなく、既存のコードベースやアプリケーションへの変更を含む、代表的な社内タスクでテストすべきだ。完全な受け入れ率、回帰率、レビュー時間、手動修正の頻度を測定する必要がある。これはSWE-bench Verifiedのような既存の評価を補完するが、人間によるレビューやデプロイ時の安全対策に取って代わるものではない。

この結果はエージェントプラットフォームの開発者にも関係する。ブラウザ検査の改善、状態追跡の明確化、信頼性の高いロールバック、より強力な検証は、基盤モデルを大型化するのと同程度に結果を改善する可能性がある。ハーネスに関する結果は、プロダクトチームが権限、ツールの信頼性、可観測性、失敗からの復旧を含むワークフロー全体を評価すべきことを示している。

今後注目すべき点

次に有用なシグナルとなるのは、Co-Design Benchや類似の評価が、固定された一回限りのリクエストを超えて拡張されるかどうかだ。実際のソフトウェア開発には、確認、変化する要件、ユーザーやプロジェクトリーダーからのフィードバックが含まれるため、対話型のテストはエージェントの有用性について異なる像を示す可能性がある。

研究者と購入者は、単一のモデルランキングを公表するのではなく、モデルとハーネスを組み合わせて報告する結果にも注目すべきだ。独立した再現実験によって、報告されたランキングと環境による大きな影響が、さまざまなコードベースやアプリケーションタイプでも持続するかを確認できるだろう。

最後に、実際のエンジニアリングチームにおける受け入れ率は、ベンチマークの完了率だけよりも意味がある。The Decoderは以前、プロジェクトリーダーがAI生成コードを受け入れた割合が、SWE-bench Verifiedのスコアを約24ポイント下回ったことを示すMETRの研究を紹介した。この差は、タスクを完了したように見えることが、そのままデプロイ可能なソフトウェアにつながるわけではないことを警告している。

Creati.aiの見解

Co-Design Benchが重要なのは、コーディングエージェントの仕事の最後の段階を測定するからだ。つまり、エージェントがコードを生成できるかではなく、要求されたプロダクト変更がアプリケーション全体で実際に機能するかを測っている。完全完了率26.4%という結果は、部分的な自動化でも大きなレビューと修正の負担が残り得ることを示している。

AI開発者と企業の購入者にとっての実践的な教訓は、モデルを製品全体とみなすのをやめることだ。信頼性の高い実行には、モデル、ハーネス、テスト、アプリケーションコンテキスト、人間による承認の組み合わせが必要となる。現実的なタスク上でこれらの要素が一体として評価されるまでは、自律的なソフトウェア開発という主張は慎重に受け止めるべきだ。