ハクソク

世界を動かす技術を、日本語で。

フロンティアコード

2026年6月9日原文(cognition.ai)

概要

  • FrontierCodeはAIによるコード生成の 品質 を評価する新しいベンチマーク
  • マージ可能性 （実際にPRが承認されるか）を世界初で評価
  • 20名以上の OSSメンテナ が現実的・多様なタスクを設計
  • QCパイプラインにより 誤判定率81%減 （SWE-Bench Pro比）
  • 最先端モデルでも 高難度タスクで苦戦、品質評価の新基準を提示

コードの正しさから品質へ：FrontierCodeの登場

  • AIが生成するコードの 正しさ は既に標準となりつつある現状
  • 本当に求められるのは 高品質な本番運用コード の生成能力
  • FrontierCodeは マージ可能性 を軸に、エンドツーエンドのコード品質（正しさ、テスト品質、スコープ遵守、スタイル、基準準拠）を評価
    • ユニットテスト、ルーブリック、新規検証手法の組み合わせによる採点
  • 20名以上の 世界的OSSメンテナ が実タスクを設計・基準定義
    • 各タスク40時間以上を投じて現実的な難易度・多様性を実現
  • QCパイプライン による厳格な品質管理
    • アドバーサリアルテスト、キャリブレーション、多段階レビュー
    • Cognitionリサーチャーが全タスクを手動レビュー
    • SWE-Bench Pro比で 誤判定率81%減
  • FrontierCodeは モデルの保守性・品質生成能力を最も正確に測定
    • 現状最も優れたモデルでも高難度タスクで13.4%のスコアに留まる

FrontierCodeの詳細と特徴

  • 3段階の難易度セット： Diamond（最難50問）、Main（最難100問）、Extended（全150問）
  • 2つの評価指標：
    • Pass rate ：マージ阻害要件を全て満たせば合格
    • Score ：ルーブリック項目の加重合計（ブロッカー不合格なら0点）
  • 各モデルは 5回実行、最良の推論レベルで平均スコアを報告
  • Diamondセットでの最高スコアは Claude Opus 4.8の13.4%
    • GPT-5.5は6.3%、Gemini 3.1 Proは4.7%、他はさらに低スコア
    • Open-sourceモデル（Kimi K2.6）はDiamondで3.8%、Mainで16%、Extendedで37%

なぜFrontierCodeが必要か

  • 旧世代ベンチマーク（SWE-Bench等）は 機能的正しさのみ評価、品質や現実性に乏しい
  • 誤判定（ False Positives/Negatives）が多発
    • 誤った解を合格とする/正しい解を不合格とする
  • FrontierCodeは 誤判定を81%削減 し、最も正確な品質評価を実現
  • タスク多様性の確保
    • 既存ベンチは単一PRから自動生成、FrontierCodeは 複数PRや自由形式リクエスト から手動選定
    • SWE-Bench Pro比で 3倍の言語 をカバー
  • 過剰なガイダンス排除、人間と同等の文脈推論を要求
    • タスク説明＋コードベースガイドラインのみ、説明文も簡潔

採点方法・評価基準

  • マージ可能性 を以下の観点で評価
    • 振る舞いの正しさ
    • 既存コードのリグレッション安全性
    • 機械的クリーンさ（ビルド・Lint・スタイル合格）
    • テストの正しさ
    • スコープ遵守（必要最小限の変更範囲）
    • コード品質（設計・可読性・規約適合）
  • クラシカルテスト・逆クラシカルテスト・適応型採点・スコープチェック など複数手法を組み合わせ
  • 各基準はブロッカー（必須）/ノンブロッカー（品質シグナル）に分類
    • ブロッカー全合格でスコア加算、1つでも不合格なら0点

新規採点技法

  • 逆クラシカルテスト ：エージェントが書いたテストが、元のバグ有コードで失敗するか自動判定
  • スコープチェック ：変更範囲の自動制約（ファイル・行数・意味的ローカリティ）
  • 適応型クラシカル採点 ：複数解に対応、LLMでテストやコードを自動修正し柔軟採点

OSSメンテナの声

  • 「FrontierCodeはCI的な採点ではなく、 Tech Lead がレビューするような品質基準」
  • 「 細部まで調整された難易度、従来にない深さ」
  • 「 主観的な品質 の現実世界での尊重、新しいマイルストーン」
  • 「 人間の経験 に基づく基準で、SWE評価の新たな水準」

今後の展望

  • FrontierCodeは今後、 AIモデルのコード生成品質評価の新標準 となる可能性
  • 本番投入可能なAIコード生成のための指針・課題明確化
  • コード品質・保守性向上のための 客観的ベンチマーク としてOSS・企業で活用期待

Hackerたちの意見

:wave: チームにいたよ！何でも聞いて。いくつかの見出し - コード品質に関する3000のルーブリック。最初のベンチマークは「このコードは実際にマージされるのか？」 - 20人以上のオープンソースメンテイナーが、自分のリポジトリで意見や好みを反映したタスクを作成。 - データセットには1000時間以上の実際のソフトウェアメンテイナーの作業が含まれてる。さらに、実際の作業をよく検証された構造化されたタスクに変えるために40時間以上の人間の作業が必要だった（タスクやプロンプトをdevin-infra特有からプラグイン可能なコーディングエージェントに変えるのはもっと大変だった）。 - SWE-Bench Proよりも81%低い誤検出率を達成。 - 高品質基準：多くのQAステージがあり、各タスクはCognitionの研究者によって手動でレビューされてる（投稿内に例あり）。Opus 4.8はFrontierCode Diamondで13%のスコア。私の目標の一つは、簡単なタスクでも面白いことをデータマイニングすることだった。例えば、目を細めて見ると「2025年後半に何が起こったのか」の答えが見えるかも。 https://x.com/swyx/status/2064081945567580323

└

大規模での品質をどう測るの？コードベースの標準に従っているかを判断する別のモデルはあるの？

└

すごくクール！SWEベンチよりも良い評価を作って共有している人たちを見るのが嬉しい。興味があるんだけど、グラフにエラーバーを入れなかった理由は何かあるの？ダイヤモンドセットにユニークな問題が50個しかない時に役立ちそうに思うんだけど。

└

クロスハーネステストについては何をしたの？評価に使われたハーネスについてブログ投稿には何も書いてないね。SOTAベンチマークは、フロンティアモデルのパフォーマンスがどのツールが使われるかに敏感だって一貫して示してる（例えば、str_replaceとapply_patch）。ラボは自分たちのハーネスでRLしてるけど、モデルを標準のセットアップでテストしたの？それとも彼らのネイティブハーネスで？

└

これめっちゃいいね！今まで見たベンチマークの中で一番考えられてると思う！フロンティアモデルのスコアだけに興味があるのか、それともカスタムハーネスからの提出も受け付けるのか気になるな。今、マルチモデルハーネスに取り組んでるから、あなたのベンチマークでテストしてみたいんだ。タスクは公開する予定ある？

└

Opus 4.6が入ってないのはちょっと残念だな。トークナイザーが4.7以降かなり変わったから。4.7にイライラして以来、ずっと4.6を使ってる。4.8にも少しイライラしてるから、次に進む気になれないんだ。

└

意味のないコメントで、バズワードやマーケティングの数字が並んでるだけ。

└

実際のソフトウェアメンテナーの作業が1000時間以上データセットに記録されている。その上で、40時間以上の実際の人間の作業が、その実際の作業をよく検証され構造化されたタスクに変えるために必要だった（さらに、タスクやプロンプトをdevin-infra特有からプラグ可能なコーディングエージェントに変えるための作業もある）。心強いね。私たちはまだ世界を悪化させる自動化を実現していない。

誰も「コード品質」が何かを知らないし、合意もできないから、人間の出力について測るのは疑わしいけど、LLMについて測るのはどうなんだろう。

└

何かを測るのに、全員の合意なんて必要ないよ。コードの品質を測るための良質な指標はたくさんあるからね。

これ、素晴らしいね。よく考えられていて、評価にたくさんの労力がかかってる。作ってくれてありがとう。良い評価が数千万から数億ドルのコンピュートデプロイメントを生むって、ちょっと驚きだよね。評価やフロンティアモデルの競争には新しさと協力性、競争性があって面白い。今回の「オープンソースメンテイナーが受け入れる短いマージ可能なパッチ」は、世界に届けるべき素晴らしいものだと思う。良いパッチと悪いパッチについて深く掘り下げてはいないけど、swyxやチームの他の人たちが飽和について予測しているか気になる。いつ、どれくらい役立つのかな？つまり、このテストはモデルからより良い行動を引き出すのに十分広いと思う？もしこのテストで飽和が起きたら、一般的により良いパッチやコーディング行動が見られるかな？

└

ありがとう - 評価の深さについてはシラス、エリック、ベン、チームに感謝。トランスクリプト読み会をやってくれた研究チームにも（笑）。オープンソースに基づいている性質上、frontiercodeのパブリックはすぐに飽和するだろうね。frontiercodeのメインは1年以内に80%以上になると思う。ダイヤモンドはもう少し長持ちしてほしいな。年次のリフレッシュはできるけど、それが私の relevancy を保つための戦略じゃない。私がもっと資金を得たいのは、実際の企業顧客の問題を再現したfrontiercodeのプライベート版。理想的なエージェントラボでは、このドメインの理解を丁寧に構築することが基本で、それがモデルラボや真剣な顧客があなたのところに来る理由なんだ。

Hacker Newsで議論の続きを見る