「速いはず」のコード、本当に速いのは6.11%だけ——LLMコード効率の4大ベンチマークは“速さ”を測れていなかった
- ベンチマーク自身が「速い」として収録する実装のうち、模範解答より統計的に有意に速かったのはわずか6.11%——と著者らは報告(著者測定、第三者未再現)
- 調査対象はLLMのコード効率を測る定番4ベンチマーク(EffiBench、Enamel、EvalPerf、Mercury)の計1,538タスク。各タスクを30回ずつ走らせ、速度差が偶然かどうかを統計検定にかけた2026年7月8日投稿のarXiv論文です
- 差が出なかった308件を人手分析すると、99件は本当に改善なし、209件は「改善はあるのにテストが暴けない」。つまり検出失敗の約3分の2はテスト側の問題(著者報告)
- テストを生成・診断・修復する3つのLLMエージェントで作り直すと、差が出なかった1,345タスクのうち24.01%(DeepSeek-v3.1)/25.43%(GPT-4o)で有意差が現れた(著者報告)
- ただし本論文はアブストラクトのみ確認できる査読前のv1で、コード公開の記載もなし。改善後も約75%のタスクでは依然として有意差が出ていない
「速いはずのコード」を30回走らせて検定にかけた
「高速版」としてベンチマークに収録されている実装のうち、模範解答より統計的に有意に速いと確認できたのは6.11%だけ——。2026年7月8日にarXivへ投稿された論文(Nhat Minh Le、Yisen Xu、Zhijie Wang、Tse-Hsun (Peter) Chenの4氏)が報告した数字です。対象は、「LLMは正しいだけでなく、速いコードを書けるのか」を測るために広く使われる4つのベンチマーク——EffiBench、Enamel、EvalPerf、Mercury——の計1,538タスク。もしこの結果が追認されれば、リーダーボード上の「コード効率」の比較は、モデルより先にテストを疑う必要が出てきます。
仕組みを少しだけ。これらのベンチマークの各タスクには、「模範解答(canonical solution。ベンチマークが用意する標準の正解)」と、それより速いはずの「高速版実装(performant implementation)」がセットで入っています。LLMのコード効率は、こうした基準との比較で採点される建て付けです。研究チームは1,538タスクをそれぞれ30回ずつ実行し、統計的有意性検定——測った速度差が「本物で再現する差」なのか「たまたまの計測ばらつき」なのかを見分ける手続き——をかけました。4ベンチマーク・1,538タスク・30回実行という設定は、論文のアブストラクトに明記されています。
その結果が冒頭の6.11%です。9割以上のタスクでは、"速いはずのコード"と普通の模範解答の間に、確かな速度差を検出できなかったわけです。なおこの6.11%は著者自身の測定値で、第三者による再現はまだありません。
著者分析では、検出失敗の約3分の2が「テストの弱さ」だった
差が出ないのは、コードに本当に差がないからか。それともテストが差を見つけられないだけか。著者らは有意差の出なかったタスクから308件を選び、人手で中身を調べました(著者報告)。
内訳はこうです。99件は、高速版と称する実装に実質的な性能改善がそもそも存在しませんでした。看板に偽りあり、です。残る209件には改善の可能性が確かにあるのに、ベンチマーク付属のテストではそれを露呈させられなかった。つまり、検出に失敗した事例の約3分の2では、コードではなくテスト入力の弱さが原因だったことになります。ただしこの99対209という切り分けは、著者ら自身による人手の判断だという点は覚えておいてください。
自転車とスポーツカーを、家の前の3メートルで競走させるようなものです。距離が短すぎれば、どちらも一瞬でゴールしてタイム差は計測誤差に消えます。ベンチマークのテスト入力が小さすぎると、遅いコードも速いコードもほぼ同時に処理が終わってしまい、本当は存在する速度差が見えなくなる——今回の研究が指摘しているのは、まさにこの状態です。
この見立てが正しければ、含意はかなり大きいものです。「LLMの書いたコードは人間の模範解答より速くならなかった」という、これまでよく報告されてきた否定的な結果の一部は、モデルの限界ではなく測定の失敗だった可能性がある、と読み替えられるからです。
3つのエージェントでテストを「鍛え直す」と、未検出タスクの24〜25%で差が見えた(著者報告)
著者らの提案は、ベンチマークを作り直すのではなく、テストをLLMエージェントに鍛え直させることです。役割の異なる3つのエージェント——性能向けテストを「生成」する係、なぜ差が出ないかを「診断」する係、テストを「修復」する係——が連携する構成で、この3役構成自体はアブストラクトに明記されています。作るのは決定的テスト(毎回同じ挙動をするテスト。実行のたびに条件が変わると、そもそも時間の比較が公平にならないため)です。
効果の検証には、元のテストで有意差が出なかった1,345タスクを使いました。生成し直したテストで再計測すると、DeepSeek-v3.1を使った場合で24.01%、GPT-4oで25.43%のタスクに統計的に有意な速度差が現れた、と著者らは報告しています。元のテストスイートでの6.11%と比べれば、見える差はおよそ4倍(ただし分母が異なる点には注意してください。6.11%は全1,538タスク、24〜25%は有意差の出なかった1,345タスクに対する割合で、単純な同一母集団の比較ではありません)。「隠れていた速度差」の相当数を掘り起こせたことになります。
| 計測条件 | 有意な速度差が出た割合 | 出所 |
|---|---|---|
| 元のテストスイート(1,538タスク) | 6.11% | 著者測定 |
| 生成テスト+DeepSeek-v3.1(元は差が出なかった1,345タスク) | 24.01% | 著者測定 |
| 生成テスト+GPT-4o(同上) | 25.43% | 著者測定 |
著者らはさらに、「既存の最先端(SOTA)のLLMベース性能テスト生成手法を上回る」「生成テストは機能の正しさを保ったまま性能差をよく暴く」とも主張しています。ただしアブストラクトには比較対象の手法の数値が示されておらず、この部分はいまのところ主張として受け取るべきものです。
直せたのは一部——それでも実務への教訓は明確
ただし、いちばん大事なのは「24〜25%まで上がった」ことではないかもしれません。テストを鍛え直してもなお、元は差が出なかったタスクの約75%では依然として有意差が出ないままだからです。この論文には、読み手として押さえるべき限界がいくつもあります。誠実に並べておきます。
まず、現時点で確認できるのはアブストラクトのみで、使われた統計検定の種類や計測ハードウェアの詳細は見えません。査読を経ていないv1のプレプリントで、コードやデータの公開への言及もないため、6.11%も24〜25%も外部からはまだ再現できません。テストを鍛えれば全部解決、という話ではないのです。
それでも、実務への教訓ははっきりしています。EffiBench、Enamel、EvalPerf、Mercuryのスコアでモデル同士の「コード効率」を比べている人は、統計検定を経ていない小さな差をノイズとして扱うべきです。そして「新しいベンチマークを乱造する」のではなく「既存ベンチマークのテストをエージェントに診断・修復させて鍛え直す」というパターンは、評価基盤の整備という地味だが効く方向性として、この論文がうまく実演してみせたものです。
確実に言えるのは、4つの定番ベンチマークが1,538タスク・30回実行の統計検定にかけられた、という研究が出たことまで。「有意に速いのは6.11%」「テストを鍛え直せば24〜25%」はいずれも著者自身の測定で、再現待ちです。ただ、もしこの数字が追認されれば、「このLLMは効率的なコードを書く」というリーダーボード上の宣伝文句の多くは、そもそも今のテストでは測れていなかった——ということになります。スコアの前に、ものさしを疑え。それがこの論文の一番の持ち帰りです。