一水 発 信源：凹非寺
量子位 | 公衆号 QbitAI
プログラミングエージェントの時代に、トップ層のCursorが旗手となって新しいベンチマークを発表しました——
CursorBenchは、Cursor内の異なるモデルがどれだけ「エージェント的」であるか（つまり複雑なタスクを高い能率で実行できるか）を評価するために特化されています。
結果を推測してみてください。かつてSWE-Benchで名声を博したClaude Haiku 4.5/Sonnet 4.5が全滅しました。
Claude Haiku 4.5のスコアは73.3から29.4へ低下；Claude Sonnet 4.5のスコアは77.2から37.9へ低下しました。
これは、CursorBenchと他のプログラミングベンチマークの違いを如実に表しています：
SWE-Benchはプログラムが問題を解決できるかどうかを測定しますが、CursorBenchはプログラムが効率的に問題を解決できるかどうかを測定します。この差こそが、一般的なベンチマークテストでは埋められないものです——つまり、実際のトークン制約の下でタスクを完了させることです。
AIコーディングツールが全盛の今、AIを評価するには実行能力が重要であり、しかも効率的な実行が求められています。
CursorBenchの登場は、まさにその空白を埋めるものです。
では、具体的にどのように評価するのでしょうか？
オンライン＋オフライン混合評価
評価方法について、Cursorはブログ記事を公開しました。
冒頭で、Cursorは基本的な背景を紹介しました——
AIプログラミングアシスタントが「エージェント」に近づくにつれて、現在公開されている多くのベンチマークでは不十分になっています。
主に3つの問題があります：
一是タスクのタイプが非現実的です。
よく知られているベンチマークを例にとると、SWE-Benchは主にGitHubのissueのバグ修正であり、タスクが単調です。
Terminal-Benchはコードリポジトリに限られなくなりましたが、各種「パズル式タスク」に偏っており、特定の環境下で一連の課題を達成するものです。この場合、AIは日常的な開発というより、ある種の競技会に参加しているように振る舞います。
そこでCursorは次のように述べています。「これらのタスクは、開発者がエージェントに依頼するプログラミング作業と合致していないことがわかりました」。
現実の生活では、開発者がAIに複数のファイルの修正、本番ログの分析、実験の実行などを依頼するのが一般的です……つまり、ベンチマークよりも複雑です。
二是採点メカニズムが不合理です。
多くの公開ベンチマークは通常、「1つの問題には1つの正解しかない」と仮定しています。
しかし現実は、1つの要件に対して複数の実装方法が存在し、異なるソリューションのコードスタイルやアーキテクチャの選択が異なる可能性があります。
これはしばしば2つの状況を招きます。正しいソリューションにバツをつける（誤判定）か、評価可能性のために曖昧さを強制的に排除する（人為的な制限を课す）かです。
どちらの場合も、ベンチマークは実際の状況を反映できません。
三是公認のデータ汚染問題です。
これは言うまでもありません。ベンチマークが十分に普及すると、後のモデルは直接これらのベンチマークデータを取得して訓練する可能性があります。
したがって、このような「漏題」に近い状況で採点しても、その結果にどれほどの価値があるかは想像に難くありません。
これらの問題に対し、Cursorは「オンライン＋オフライン混合評価」という新しいソリューションを提示しました。
オフラインとは、いわゆるCursorBenchのことで、プロセスも比較的単純です——
異なるモデルに同一の標準タスクを実行させ、システムが正確性、コード品質、効率、インタラクション挙動などの次元から採点を行い、最終的に各モデルがオフラインベンチマークスコアを取得します。
この標準化されたプロセスを採用する利点は明白であり、モデルを比較的同じスタートラインに引っ張って比較できること、繰り返しテストできること、コストも比較的制御可能であることなどが含まれます。
しかし、これは他のベンチマークと変わらないと言う人もいるかもしれません。
急いでください、CursorBenchの「必勝法」はここにあります——選択されるタスクが異なるのです。
その違いは3つの次元に現れています：
一是タスクがリアルです。
以前のベンチマークは「意図的に問題を探す」ようなもので、GitHubのissueや各種パズルを探していましたが、CursorBenchの問題はすべて独自のCursorプラットフォームから来ています。
Cursorには「Cursor Blame」というツールがあり、特定のコードがどのAIリクエストによって生成されたかを追跡できます。
そこで、開発者のリクエストとあるモデルが最終的に提出したコードという、リアルなデータのペアを取得できます。
これらが、CursorBenchの絶好の「出題範本」を構成しています。さらにCursorは次のように補足しています：
多くのタスクは当社の内部コードベースと管理されたソースからのものであり、モデルが訓練段階でこれらのタスクを見たリスクを低減しています。当社は数ヶ月ごとにこのベンチマークを更新し、開発者のエージェント使用方法の変化を追跡しています。
二是タスクの規模が大きいです。
今ではCursorを使う人があまりにも多いため、CursorBenchのタスク規模は明らかに大きくなっています。
例えば、正確性の評価において、コード行数でも平均ファイル数でも、その問題の規模は初期バージョンから現在のCursorBench-3までで約2倍になりました。Cursorは次のように述べています：
コード行数は難易度を測る完璧な指標ではありませんが、この指標での増加は、より困難なタスクをCursorBenchに組み込んでいることを反映しています。例えば、モノレポ（monorepo）のマルチワークスペース環境の処理、本番ログのトラブルシューティング、長時間実行される実験の実行などです。
三是タスクの記述を意図的に「あいまい」に保つことです。
この点も比較的理解しやすいです。
多くの公開ベンチマークのタスク記述は通常非常に詳細ですが、現実ではAIと話すときはしばしば曖昧です。
そのため、あまり正確すぎると反而リアリティとかけ離れてしまいます。
以上の特別な設計に基づき、CursorBenchはプログラミングエージェント時代において、真に「実際の開発シナリオ」を原点として設計されたベンチマークとなりました。
もちろんこれだけではありません。問題を解くだけでは不十分です。多くのAIはオフラインスコアは高いですが、ユーザーが実際に使ってみると期待外れであることがあります。
对此、Cursor还搞了一套线上评测——直接看真实用户使用效果。
对此、Cursorはオンライン評価セットも導入しました——実際のユーザーの使用効果を直接見るのです。
彼らはA/Bテストなどの方法を使用し、一部のユーザーがモデルAを使用し、別のユーザーがモデルBを使用した後の比較効果を観察します。
具体的には、開発者がAIによって生成されたコードを受け入れたか、追及を続けたか、修正を取り消したか、タスクが真に完了したかなど、追跡可能な製品指標を主に見ます。
こうして、オンラインとオフラインが完璧に補完し合い、さらには良性の循環を形成することができます——
オフラインのCursorBenchでまずモデルの能力を迅速にスクリーニングし、その後オンラインでモデルが本当に優れているかを検証し、偏差が発見されたらベンチマークやモデルを調整するのです。
フライホイール（好循環）がこれで回り始めました（doge）。
では、結果は？
では、各モデルは新しいベンチマークCursorBenchでどのようなパフォーマンスを発揮したのでしょうか？
最終的なパフォーマンスを見てみましょう（右上に行くほど良い、「最低コストで最高性能」を表します）：
このグラフを見て、ネットユーザーたちは一時議論を巻き起こしました：
おっと、Claude Sonnet 4.5の「コスパ」が少し低いですね。
このComposerモデル（Cursor自社開発のコーディングモデル）はどこから湧いてきたのでしょうか。
とにかく、Cursorが発表した結果から見て、非常に明らかな結論が導き出されます——
CursorBenchは最先端モデル間の識別力が明らかに高いです。
これは当然のことです。ベンチマークが飽和状態になると、モデル間の差がつかず、みんなの点数が高く、みんな良い状態になります。
しかし、新しくて困難なものに遭遇すると、実力差が自然と露呈します。
特にCursorBenchのようなタスク規模が大きく、環境がより複雑なベンチマークでは、その差は間違いなくさらに拡大されます。
モデルのSWE-BenchとCursorBenchでのスコアを比較するだけでわかります（左側はみんな固まっていますが、右側は階段状になっています）：
また、Cursorは別の点も強調しています——
CursorBenchのランキングは、実際のユーザー体験とより一致しています。
前述のオンライン実験を通じて、彼らはCursorBenchのモデルランキングと、これらのオンライン指標の変化が基本的に同じ方向であることを発見しました。
今後、Cursorは次世代の評価スイートの開発に着手する予定です：
CursorBench-3のタスクは公開ベンチマークのタスクよりも実行時間が長いですが、それでも1回のセッション内で完了できます。我々は今後1年以内に、開発者の大多数の作業が各自のコンピュータ上で独立して実行される長時間実行エージェントによって行われるようになると予想しており、CursorBenchもそれに応じて調整する予定です。
はい、ターゲットはあくまでエージェントですが、より長時間実行されるエージェントです。
参考リンク：
https://x.com/cursor_ai/status/2032148125448610145