## 概要 [[Cursor]]が自社のAIコーディングエージェントのモデル品質を評価するために構築した内部ベンチマーク「CursorBench」に関する解説記事。公開ベンチマークの限界を指摘し、実際の開発者ワークフローに即した評価手法を提案している。著者はNaman Jain、2026年3月11日公開。 ![[Pasted image 20260317231616.png]] ![[Pasted image 20260317232008.png]] ![[Pasted image 20260317232141.png]] ## Cursor Blame CursorBenchのタスク収集基盤。`git blame`の発想を拡張し、コミットされたコードからそれを生成したエージェントリクエストまでを遡及追跡するパイプライン。 - **動作フロー**: 1. バージョン管理上のコミット済みコードを起点に解析 2. そのコードを生成した元のCursorエージェントとのインタラクションを特定 3. 開発者クエリとground-truthソリューション（＝実際にコミットされたコード）の自然なペアリングを生成 - **ground-truthの根拠**: 開発者自身がコードを受け入れてコミットした事実そのものが、正解の検証となる - **タスクソースのハイブリッド構成**: - Cursor Blameによる自動トレースされたエージェント-コードマッピング - 内部コードベースおよび管理されたソースからの開発タスク - 統制されたテストシナリオ - モデルの学習データへの混入リスクを低減するため、公開リポジトリではなく内部ソースを重視 - 数ヶ月ごとにスイートを更新し、開発者のエージェント利用パターンの変化を追跡 ## CursorBench-3の特徴 - 初版からコード行数・平均ファイル数ともに約2倍に拡大 - [[SWE-bench]] Verified、Pro、Multilingualよりも大幅に多い行数のタスク - モノレポ環境、本番ログ調査、長時間実験などの複雑なタスクを含む - 単一セッション内で完結するタスク設計 - 意図的に短く曖昧なタスク記述（[[GitHub]]のIssueとは対照的） ## 評価の4次元 - ソリューションの正確性（correctness） - コード品質（code quality） - 効率性（efficiency） - インタラクション挙動（interaction behavior） ## 公開ベンチマークの限界 ### アラインメントの問題 - バグ修正やパズル的タスクが中心で、実際の開発者がエージェントに依頼する作業と乖離 ### グレーディングの問題 - 曖昧な要求に対する複数の正解を適切に評価できない - CursorBenchではエージェント型グレーダー（agentic graders）を使用し、複数の有効な解法を信頼性高く評価 ### コンタミネーションの問題 - 公開リポジトリ由来のタスクがモデルの学習データに混入 - [[OpenAI]]がSWE-bench Verifiedの報告を中止した経緯：フロンティアモデルがパッチを記憶し、未解決問題の約60%に欠陥のあるテストが含まれていたことが判明 ## パフォーマンス結果 - 公開ベンチマークが飽和するフロンティアレベルにおいて、CursorBenchはより大きなモデル間差異を生成 - Haikuクラスのモデルが公開ベンチマーク上でGPT-5に匹敵またはそれを上回るスコアを出す飽和現象 - オンラインでの対照実験（ablationテスト含む：セマンティック検索ツールの完全除去による影響測定など）でモデルランキングが開発者体験とより密接に相関することを検証 ## 今後の方向性 - 開発者のマシン上で独立して動作する長時間実行エージェントへの移行を想定 - 課題：グレーディングコスト、外部サービスの再現性、オフライン-オンライン評価の整合性