Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering
本論文は、現在のコーディングベンチマークが、モデルの性能とシステムハーネスの構成要素を混同し、単一のリファレンス回答に依存することで正当な代替解を罰しており、かつ反復的なシステムの改善に必要な粒度の高いフィードバックを欠いているという点で、エージェンティックなソフトウェアエンジニアリングとは乖離していると論じている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
大きなアイデア：私たちは間違ったものを採点している
想像してみてください。あなたは、複雑な料理を作るシェフがどれほど優秀かを判断しようとしています。
現在、コーディング「エージェント」（ソフトウェアを記述するAIシステム）をテストする方法は、このようになっています。あなたはシェフに、あらかじめ書かれた一つのレシピ（「参照ソリューション」）を与えます。シェフはその料理を作ろうとします。もし最終的な一皿が、レシピ本の写真と全く同じ見た目であれば、シェフには満点が与えられます。もしシェフが、見た目は少し違うものの、より美味しく健康的で創造的な料理を作ったとしても、レシピと完全に一致しなければ低いスコアを付けられてしまいます。
この論文の著者たちは、これは壊れたシステムであると主張しています。彼らは、私たちが単にシェフ（AIモデル）をテストしているのではなく、キッチン全体のセットアップ（「システム・ハーネス」）をテストしているのだと言います。これには、コンロ、道具、材料、そして指示が含まれます。
コアとなる問題：「キッチン」対「シェフ」
この論文では、決定的な区別を行っています。
- モデル（シェフ）： コードを生成するAIの脳です。
- システム・ハーネス（キッチン）： AIが活動する複雑な環境です。これには、使用するツール、読み取るコンテキスト、従うべきルール、そして間違いがあった際にそれを伝えるフィードバックループが含まれます。
たとえ話：
コーディング・エージェントをF1カーだと考えてみてください。
- モデルはエンジンです。
- システム・ハーネスは、シャシー、タイヤ、エアロダイナミクス、ピットクルー、そしてドライバーの戦略です。
現在のベンチマークは、最終的なタイムだけを見て「このエンジンは速い！」と言うようなレースです。しかし、この論文は、たとえ全く同じエンジンであっても、タイヤやドライバーの戦略（ハーネス）を変えるだけで、車のスピードが20%速くなったり遅くなったりすることを指摘しています。
著者たちは、実世界のテストにおいて、「キッチンのセットアップ」（ハーネス）を変更することは、新しいバージョンに「シェフ」（AIモデル）をアップグレードすることと同じくらい結果を左右することを示しています。それにもかかわらず、現在のテストは、その結果が「シェフの才能」によるものだけであるかのように扱っています。
壊れたシステムの3つの症状
論文では、現在のテスト手法が現実とどのように乖離しているかについて、3つの具体的な方法を挙げています。
1. 境界線の曖昧さ（混同）
たとえ話： ある学生が数学のテストを受け、80%のスコアを取ったとします。私たちはその学生が賢いのだと想定します。しかし、もしその学生が電卓とカンニングペーパーと、答えをささやくチューターを使っていたとしたらどうでしょう？ もし彼らがどのようにして80%を取ったのかを報告しなければ、その学生が本当に賢いのか、それともツールが仕事をこなしたのかを判断することはできません。
論文の主張： 現在のベンチマークは、単一のスコア（例：「モデルXの精度は65%」）を報告しています。しかし、どのようなツールや環境が使われたのかを教えてくれません。これでは、AIが実際に賢くなっているのか、それとも「キッチン」がより強力になっただけなのかを知ることは不可能です。
2. 「正解は一つ」という罠（単一参照）
たとえ話： 大工さんにテーブルを作ってほしいと頼んだとします。あなたには、作りたい特定のテーブルの写真があります。
- シナリオA： 大工さんが、頑丈で美しく機能的なテーブルを作りましたが、木目が写真とは少し異なります。
- シナリオB： 大工さんが、写真と全く同じ見た目のテーブルを作りましたが、グラグラしていて崩れてしまいます。
現在のベンチマークでは、シナリオBに満点が与えられ、シナリオAは写真と一致しないために不合格となります。
論文の主張： 本物のソフトウェアエンジニアリングは、単一のソリューションをコピーすることではありません。問題を最適な方法で解決することです。AIに特定の「ゴールドスタンダード（黄金律）」のコード片に一致することを強制することで、創造的で妥当な、しばしばより優れた解決策を、私たちは罰してしまっています。私たちは、AIが特定のパッチを「模倣」できるかどうかをテストしているのであって、問題を「解決」できるかどうかをテストしているのではありません。
3. ブラックボックス（コンポーネント信号の欠如）
たとえ話： あなたの車が故障しました。整備士に持っていくと、彼は「車が壊れています」と言います。これは「エンド・ツー・エンド」のスコアです。何かがおかしいことは分かりますが、何が原因なのかは分かりません。バッテリーですか？ タイヤですか？ それともエンジンですか？
論文の主張： コーディング・エージェントがテストに失敗したとき、現在のベンチマークは単に「失敗」と表示するだけです。なぜ失敗したのかを教えてくれません。AIが指示を誤解したのでしょうか？ ツールが失敗したのでしょうか？ それとも環境がクラッシュしたのでしょうか？ どの部分の「キッチン」が故障したのかが分からなければ、開発者はシステムを修正することができません。彼らは推測するしかなくなります。
代わりに何をすべきか？
著者たちは、これを修正するために3つの変更を提案しています。
- 完全なレシピを報告する： テスト結果を公開する際は、使用したすべてのツール、環境、設定をリストアップしなければなりません。そのスコアが天才的なAIによるものか、あるいは超強力なキッチンによるものなのかを知る必要があるのです。
- 外見ではなく、振る舞いで採点する： コードが「ゴールドスタンダード」と見た目が一致しているかどうかをチェックするのではなく、コードが「機能するか」、そしてルール（安全性チェックやデザインパターンなど）に従っているかどうかをチェックすべきです。問題を解決する方法は他にもたくさんあり、テストはあらゆる妥当な解決策を受け入れるべきです。
- 全体ではなく、パーツをテストする： システムを分解する必要があります。指示を読み取る能力と、ツールを使用する能力を個別にテストします。これにより、どの部分が壊れているのかを推測するのではなく、特定の壊れた箇所を特定して修正できるようになります。
結論
この論文は、私たちが過去の道具（単純な、一回限りのコード生成）を使って、未来のソフトウェアエンジニアリング（複雑で自律的なAIシステム）を測定しようとしていると論じています。
前進するためには、AIモデルだけが重要であると考えるのをやめる必要があります。ツール、ルール、そしてフィードバックループを含む「システム全体」を測定し始める必要があります。なぜなら、現実の世界においては、それこそが仕事を成し遂げる鍵だからです。そうしなければ、私たちのランキングやスコアは誤解を招くものであり続けるでしょう。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。