# コーディングエージェント評価 コーディングエージェントの能力を測るためのベンチマーク・評価手法の総称。公開ベンチマークと内部ベンチマーク、オフライン評価とオンライン評価の軸で整理される。 ## 公開ベンチマークの限界 [[SWE-Bench-Verified]] を筆頭とする公開ベンチマークには 3 つの構造的限界がある([[CursorBench]] ブログより): | 限界 | 内容 | |---|---| | **調整不足** | SWE-bench はバグ修正特化。機能追加・リファクタリング・コードベース理解等を扱わない | | **採点問題** | 複数の有効解を認識できない。OpenAI は「未解決問題の 60% にテスト欠陥」として報告停止 | | **汚染** | SWE-bench Verified/Pro/Multilingual は訓練データ汚染の影響下 | > [!key-insight] SWE-bench 後退の意味 > OpenAI が SWE-bench Verified 報告を停止したことは、公開ベンチマーク競争の信頼性に対する業界警告として機能する。内部ベンチマーク + オンライン評価への移行を促す圧力になっている。 ## 評価方式の二軸 ### オフライン評価 - 内部ベンチマーク(CursorBench 等)で高速・再現可能に評価 - フロンティアモデル間のスコア差別化に有効 - 汚染対策として実コーディングセッションから問題を生成する手法([[Cursor Blame]] 等)が有効 ### オンライン評価 - 実開発者の使用状況でリグレッション検出 - セマンティックサーチ等の機能 ablation に使用 - 開発者体験と直結するが、コスト・再現性に課題 ## 評価次元 CursorBench 3.1 で採用される 4 次元: 1. **solution correctness** — 解の正しさ 2. **code quality** — コード品質 3. **efficiency** — 効率性 4. **interaction behavior** — インタラクション動作 ## 今後の課題 - 長時間実行エージェント(long-running cloud agents)への評価拡張 - 外部サービス連携タスクの再現性確保 - 採点コストの削減 - オフライン評価と開発者体験のギャップ縮小 ## 横断的知見 - **「機能的正しさ」中心の評価が見落とす次元として、オブザーバビリティが実証的に定式化された**: CursorBench の 4 次元(solution correctness・code quality・efficiency・interaction behavior)は生成コードの正しさ・品質・効率に焦点を当てるが、いずれも「本番で障害が起きた時に診断できるか」を測らない。[[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] は、SWE-Bench 等の機能的正しさ評価が「パッチが issue を解決するか」に閉じており、生成システムが実行時にどれだけ診断可能かを問わない構造的限界を指摘し、Position F1/KeyBag F1(ソースレベル診断意味論)・Fault Signals Rate(実行時障害シグナル)という新しい評価軸を提案する。CursorBench の限界論(調整不足・採点問題・汚染)とは異なる種類の限界——**評価次元そのものの欠落**——を提起した点で対照的である。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]], [[@2026__Cursor__CursorBench - How Cursor Evaluates Model Quality]]) - **リポジトリ全体コンテキストを与える評価設計は、単一関数評価では測れない「文脈適応能力」を可視化する**: Observability-Aware Code 論文は、エージェントが単一関数でなくリポジトリ全体のコンテキストにアクセスできる設定を意図的に採用し、「リポジトリ固有の規約(ロギングスタイル・トレーシングスキーマ・テレメトリ命名パターン)を活用できるか」を評価に組み込む。few-shot(同一ファイル内実例)プロンプトが KeyBag F1・Position F1 双方を Recall 主導で改善した(+0.025/+0.043)ことは、この文脈適応能力が実際に計測可能であることを示す。CursorBench が「実コーディングセッションから問題を生成する手法」で汚染対策をした発想と、「リポジトリコンテキストを与えて標準ベンチマークの限界(孤立した関数評価)を超える」発想は同じ方向性を持つ。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) ## 未解決の問い - CursorBench の 4 次元評価と、Observability-Aware Code 論文の Position F1/KeyBag F1/FSR のような専門ドメイン評価軸は、単一の統合ベンチマークへ統合されうるか。それとも機能的評価と非機能的評価(オブザーバビリティ・セキュリティ・保守性等)は別ベンチマーク体系のまま並走すべきか。(Source: [[@2026__Cursor__CursorBench - How Cursor Evaluates Model Quality]], [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - explicit instruction(observability-hinted プロンプト)が量を増やし質を下げる Quantity-over-Quality 現象は、オブザーバビリティ以外の評価次元(セキュリティ・テストカバレッジ等)でも再現するか。「明示的指示への over-generation バイアス」はコーディングエージェント全般の構造的な失敗モードか。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) ## 関連ページ - [[CursorBench]] — Cursor 社の内部評価ベンチマーク - [[SWE-Bench-Verified]] — 公開ベンチマーク(限界が指摘されている) - [[Cursor Research]] — CursorBench 開発チーム ## 出典 - [[@2026__Cursor__CursorBench - How Cursor Evaluates Model Quality]] - [[@2026__arXiv__Composer 2 Technical Report]] - [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]](Position F1/KeyBag F1/FSR による非機能的評価軸の提案、18 リポジトリ 1,223 インスタンス + 200 系 1,615 障害インスタンスの実証)