FrontierCode: コーディングベンチマークから「正しさ」の次元を超えて「品質」へ測定する革命

概要と革新性

今日までのコーディングベンチマーク（SWE-Bench など）は、AI モデルが正解するコードを書けるかを検証しましたが、本質的な課題は変化しています。

• 「正しさ」は基本条件： AI 生成コードが生産環境への主要な進出経路となるに連れ、「正しく動くこと」は最低限の要件になりました。
• 真の問われていること： 「モデルが本当に高品質なプロダクション・コードを書けるのか？」という問いに対し、新たなベンチマーク FrontierCode を発表します。

他との決定的な違い

1. メンテナーによるマージ可能性測定

単なるコード生成ではなく、実際に PR がマージされるかを厳密に検証します。

• エンドツーエンド品質評価： 正しさ、テスト品質、スコープ規律、スタイル、コードベースへの準拠度を総合的に判断。
• 革新的なアンサンブルグラデーション： ユニットテスト、Rubric（採点基準）、新型 Verifier を組み合わせた独自の検証技術を採用。

2. オープンソースメンテナーが設計・構築

世界クラスのオープンソース開発者 20 名以上が参加し、自身がメンテナンスするリポジトリの文脈から課題を構築しました。

• 現実性の保証： タスクあたり平均 40 時間以上の時間を投資。各メンテナー自らが「マージ可能」という定義を実装しています。

3. 厳格な品質管理（QC）パイプライン

主観的になりがちな評価基準に対し、以下の手法で誤検出を排除しました。

• 敵対的テスト・較正・多段階審査： 認知科学研究所の研究員による手動レビューを含む徹底した QA を実施。
• 高い精度の達成： SWE-Bench Pro と比較し、**誤検出率を 81%**も低下させています。

4. 未飽和な性能とコスト対効果（Cost-Intelligence）

現在の最先端モデルですらまだ限界があり、さらに高い基準が求められています。

• FrontierCode Diamond: 最高性能の Claude Opus 4.8 でさえ得点は **13.4%**のみ。（他モデルはさらに低く GPT-5.5 は 6.3% など）
  • ただし、GPT-5.5 は Opus 4.8 より最多 4 倍少ないトークンを使用し、コスト対性能のバランスを良好に実現。
• FrontierCode Main/Extended: Claude Opus 4.8 がそれぞれ **34.3%**と **51.8%**を記録し、明らかなリードを維持中。
• オープンソースモデルとのギャップ: Kimi K2.6（最良の OSS モデル）でさえ Diamond で 3.8% に留まり、大きな性能差が確認されました。

なぜ FrontierCode を作成したのか：既存ベンチマークの限界

第 1 世代のベンチマーク（SWE-Bench Verified/Pro）は能力に欠けるモデル向けに設計され、以下の問題を抱えています。

• 機能のみを重視： パッチが動けば合格であり、「コード品質」そのものは検証されていませんでした。
• 誤分類エラー（False Positives/Negatives）の多発:
  • 偽陽性 (False Positives)： 簡易的なテストでは通過するが、実際には間違ったコードの場合。
  • 偽陰性 (False Negatives)： テスト自体が厳しすぎて、正解なコードでも判定されない場合。

FrontierCode の改善点:

• 誤分類削減: エージェント軌跡分析により、主要ベンチマークと比較して誤分類ミスを **81%**削減。スコアが現在最も正確なランキングを示します。

• 多様性の向上:
  • 単一の PR スクレイピングではなく、メンテナーによる手作業での精選。
  • SWE-Bench Pro より 3 倍多くの言語をサポート。

• 過剰な手助けの排除: 現代モデルにはヒューマン・ハンドヘルディングは不要です。簡潔な指示（SWE-Bench Pro の約 1/3）で、メンテナーの意図推測能力を測定します。

FrontierCode をどのように構築したか

オープンソースメンテナーチームとの協業

「モデルがマージされる」ことを証明するために、36 の主要リポジトリメンテナーと直接協力しました。

• 専門家の判断基準化: メンテナーは各 PR に対して数十年の経験を凝縮し、「実際に承認されるか」という具体的な評価基準を設定。
• メンテナーの声:

  「FrontierCode は、現実世界での主観的な品質を尊重する AI モデルへのマイルストーンです。」
  — Merlijn Vos, uppy Core Maintainer

6 次元の評価軸とブロック要因

コードを以下の軸で評価し、「マージ可能性」を判断します。

カテゴリ	検証項目	詳細
振る舞いの正しさ	Behavioral correctness	パッチが実際に問題を解決しているか？
退化の安全性	Regression safety	既存コードに影響を与えていないか？
機械的清潔さ	Mechanical cleanliness	ビルド、Lint、スタイルチェックに合格するか？
テストの正しさ	Test correctness	エージェント作成のテストが真の挙動を捉えているか？
スコープ (Scope)	Scope discipline	範囲を超えた変更や不要なリファクタリングが含まれていないか？
コード品質	Code quality	コードベース慣習やデザインパターンの準拠、可読性

ブロック要因（Blocker）と非ブロック要因

• ブロック要因： マージを拒否するレベルの重大事項（正しさ違反、パフォーマンス低下など）。全項目パスが必要。
• 非ブロック要因： スタイルや可読性等の品質シグナル（マージには直接阻害しないがスコアに影響）。

革新的な評価手法（Grading Techniques）

誤分類を減らしつつ、複数の解決策を許容するための技術導入です。

1. 逆転型古典的 (Reverse-Classical):
   • エージェント作成のテストをベースコミットで実行し、必ず失敗するようにする。
   • これにより、エージェントが問題を正しく理解していることを自動保証。
2. コードスコープ (Code Scope):
   • 良い PR は「自制心（Change Minimalism）」を持つべき。不要な変更は厳禁。
   • ファイル制約, サイズ制約, セマンティック制約の組み合わせで境界を強化。
3. 適応型古典評価 (Adaptive Classical Grading):
   • コード名やエラー文字列などの表面変化には依存しない。

   • mutagent

     ツールを活用し、LLM がテスト環境自体を外科的パッチングしてエージェント実装に合わせる。

品質管理プロセス (Rubric Calibration)

評価基準（Rubric）の主観性を解消するため、以下の多段階プロセスを実施。

1. 設計: 古典的テスト（事実確認）、適応型評価（振る舞性）、LLM 評価（ソフトクオリティ）を適切に組み合わせ。
2. ハックレポート： 偽陽性・偽陰性を防ぐため、敵対的プログラミングや意図的なバグ作成を試み、基準の堅牢性をチェック。
3. 較正 (Calibration): 0〜100% の範囲で異なるレベルの解答を作成し、評価の解像度を確保。
4. 審査: 経験豊富なリーダー率いる「評価ポッド」による多段階レビュー。研究員による最終確認を含む。
5. 再審査： 不合格時には返送・修正を繰り返し、パス条件までサイクル。

実例：Claude Opus 4.8 の挙動観察

インタラクティブなタスク事例:

• 背景: C++ で記述された

  jsonschema

  リポジトリに対し、特定ログメッセージの出力方法を関数化し、複数行警告を適切に処理するコードを実装。
• 課題: 慣用的には複数行の警告を一つの

  LOG_WARNING()

  呼出しで記述すべきだが、モデルはこれに失敗しやすい。

比較対照

【失敗例：GPT-5.5/Opus の初期挙動】

// 慣用的な複数行 LOG_WARNING 使用（正解）
LOG_WARNING() << "You are opting in to remove schema identifiers... \n"
              << "The only legit use case...\n"
              << "non-compliant...\n";

【成功例：Claude Opus 4.8 の挙動】 注：振る舞い学的には同じだが、実装方針に差異あり。

// Claude Opus 4.8 は LOG_WARNING() と std::cerr を混在して使用
LOG_WARNING() << "You are opting in to remove schema identifiers...\n";
std::cerr << "The only legit use case...\n";
std::cerr << "non-compliant...\n";

• 分析: これら二つは stderr への出力（振る舞い）は同一ですが、

  LOG_WARNING()

  の将来変更に対する耐性やコードベースの文脈適合度において違いを生みます。FrontierCode はこのような「マージ可能な品質感」を厳密に判定します。

結論と展望

• 次世代ベンチマーク： FrontierCode は開発者、企業、研究員に対し、モデルの「プロダクション準備状況」を真実に評価することを可能にします。
• 公開計画: タスク汚染を防ぐため現時点では非公開ですが、月次でより高い境界（Frontier）へ挑戦できるよう評価機会を提供予定。

謝辞

このプロジェクトは研究コミュニティおよび実践者との緊密な協力によって成り立ちました。以下のみな様に感謝します。

• 研究チーム: Eric Lu, Ben Pan, Deniz Birlikci, Sam Lee, Ray Wang, Rohan Choudhury, Fermi Ma, TC Qin, Carlo Baronio, Silas Alberti
• デザイン: Katie Cheng, Joseph Alessio
• 外部コントリビューター: Claudio Costa, Martin McKeaveny, Lance Fuchia, Merlijn Vos, Tomer Nosrati, Swyx