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

フロンティアコード

概要

  • 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のプライベート版。理想的なエージェントラボでは、このドメインの理解を丁寧に構築することが基本で、それがモデルラボや真剣な顧客があなたのところに来る理由なんだ。

すごい努力だし、私のプライベート評価にDeepSWEより近づいてる。偽陰性と偽陽性に焦点を当ててくれてるのが本当にありがたいし、単に合格するだけでなく、実際にマージ可能な品質出力にもっと集中してるのがいいね。あなたのメトリクスのリストを多くの人が基にするのが見えると思う。とてもよく定義されていて、提供されるコードから求めるべきすべてをしっかりカバーしてる。狭いターゲットにだけ焦点を当ててるわけじゃない。私自身のテストにもこれらのアイデアをたくさん取り入れて、他の部分も少し意図せず似た方向に進んでしまったところを磨いていくつもり。

何かダウンロードできるものはある?GLM 5.1はテストされたの?

これをチャートにするのはフェアじゃないよ。「各モデルは、利用可能な推論努力のすべてで5回実行されます。各努力について、5回の試行の平均を取り、その後、各モデルのスコアを最高の推論レベルで報告します。」例えば、Anthropicの「ミディアム」は、OpenAIの「ミディアム」の3倍の思考を要するかもしれないし、5倍の時間がかかるかもしれない。だから、結果が歪んじゃってるんだよ。線形で同等の範囲だと仮定してるけど、リンゴとリンゴを比較すべきだよ。タスク完了時間を「努力」の指標として考慮に入れるべきで、AI会社が提供する恣意的な努力設定じゃない。基礎的な努力レベルはどうでもいい、同じ時間で複数のモデルの中でどれがより正確にタスクを完了するかが大事なんだ。トークン消費量も考慮すべきだね、TPSを排除するために。でも、最終的な生産性が目標なら、主な要素はどれが早くやるかだよ。コストが気になるなら、トークン数とスピード、あるいはトークン数だけが主な要素になる。第二のチャートはもっと明確な絵を描いてるけど、GPT 5.5 xhighは21kトークンで44.7%、Opus 4.8 maxは75kトークンで49.9%だ。つまり、Opus 4.8の4倍のトークンで5.2%の増加があったってこと。もしGPT 5.5 xhighを同じタスクセットで4倍ループさせたら、49.9%を超えるかな?それが本当の質問だよ。多分超えると思うけど。この全体のフレーミングがOpusが大きなリードを持ってるように聞こえるけど、実際にはもっとハードにループしてトークンを消費してるだけなんだ。彼らの努力レベルは同等じゃない。さらに進めて、Anthropicが裏でやってることを模倣してみて。複数のプロンプトを通してプロンプトを実行し、最終結果に収束させる。GPT 4にベンチマークの異なる側面をカバーする一般的なスキルを与えて、同じトークン数を使うために4倍実行して、それぞれの異なるスキルを使う。結果はどうなる?多分Opusを圧倒すると思う。最終的には、Anthropicはすべての膨張を一つの遅いパッケージで提供してる。GPTは自分の同等のハーネスを作る能力を与えてくれる。自分でやる自由と柔軟性がある方がいいな。人々がオープンソースの周りに強力なハーネスを構築することに集中すれば、閉じたラボと同じレベルで競争できるモデルが出てくると思う。特に、今はNemotron 3 Ultraのようなモデルがあるからね。でも、それには小さくて速いモデルを使ってルーティングや「スキル」やプロンプトを決定するのを手伝うなど、たくさんの賢いアプローチが必要だ。特定のタスクのさまざまな側面を協力的なツリーで処理するために、すべての専門的で速い小さなモデルのパイプラインを使用する。未活用の専門AIモデルがたくさんあるのに、誰もそれらの周りにハーネスを構築していないのが信じられない。例えば、セマンティックコード重複検出とかね。すべてを大きなモデルでやる必要はない、大きなモデルはすべてのツールや小さなモデルのオーケストレーターであるべきだ。これが、大きなラボが誰にも破れないリードを持っている理由だよ。彼らは単にモデルを構築して終わりにするわけじゃなくて、大きなモデルの上にこれらの他のアプローチを活用してるからね。今、強力なオープンソースモデルがあるから、私たちもこれらのことを構築し始めることができる。

わあ、確かに大きな欠陥を見つけたみたいだね。最近のGPTとOpusモジュールは強いと思ってたから、結果には懐疑的だったんだ。他はBかCランクって感じ。これはただのアーティザナルな雰囲気のテストだね。ちゃんと評価するのはすごく難しい。

トータルのトークン消費も考慮すべきことだね、TPSを除外するために。この記事にはそれを比較したチャートがあるよ。 > りんごとりんごを比較しなきゃ。タスク完了にかかる総時間を「努力」の指標として考慮するように重み付けしなきゃ、AI会社が提供する恣意的な努力設定じゃなくて。基礎的な努力レベルがどうであれ、私は複数のモデルの中で、同じ時間を使った場合にどれがより正確にタスクを完了するかが気になるんだ。それがあなたの意見だけど、私の目標はまさにこのベンチマークが測るもので、最終的な結果がラボから提供された設定に基づいてコードベースにマージできるものなんだ。私は50のエージェントを並行して動かさないし、$100のAnthropicプランをちょうど超えないように使ってる。あと、Opusが解決できてCodexが解決できない問題について、あなたのベンチマークの結果に対する具体的な主張は何なの?

自分たちのモデル(SWE-1.6)がひどいスコアを出してる時点で、正直なベンチマークだってわかるよね。

Opus 4.8の低は8.2%、ミディアムは5.9%っていうのは、少なくとも興味深い結果だね。

新しい、もう飽和状態じゃないベンチマークを作ろうとしてる努力がいいね。モデルがそれを完璧にこなすとちょっと疑っちゃうけど。OSSのメンテナーの好みに合うようになるのは質の向上としてはあり得るけど、毎回うまくいくなら、暗記してるんじゃないかって思う。FrontierCodeがこれをやるべきだったとは言わないけど、インタラクションのベンチマークを取るのは面白そうだよね。つまり、もしブロッキング問題があって、コメントを書くことで解決できるなら、それはモデルが壁にぶつかるのとは全然違う。もっと言うと、問題があっても、モデルが事前に短い質問リストを出してくれれば、あまり時間を取られずに解決できる。ユーザーやレビュアーみたいに振る舞うように指示されたLLMをループに入れて、プロンプトにはなかったルーブリック的な情報を与えればいいんじゃないかな。その後、擬似ユーザーがそのモデルで質の高い結果を得るためにどれだけのことをしなきゃいけないのかを見てみればいい。『インタラクションを心配する必要はない、目標はモデルが完璧にこなすことだ』って言うかもしれないけど、そういう理想の状態は存在しないと思う。タスクは大きくなるけど、インタラクションは常に必要だからね。コメントを処理したり、必要なときに良い確認質問をするのは本当に大事な能力だよ。人間のソフトウェアエンジニアはたくさんインタラクションするし、実際のエンジニアリングには要件や好み、その他の漠然とした大きなことについての質問がたくさんあるから。

新しいタイプのベンチマークがあればいいのに…タスクの完了に焦点を当てるんじゃなくて、モデルがアシスタントとしてどれだけうまく機能するかに注目するやつ。私の仕事では、E2Eを通じて広範なドキュメントやユーザーストーリーを提供しても、モデルが質の高いアウトプットを出すのを信頼できないんだ。彼らはできないし、18ファイルの変更をレビューするのは私の負担を増やすだけ。そう、私たちはすでにドキュメントを分割して最適化して、文脈を圧倒しないようにしてる。これを実現するためには、みんなで計画を立てて、エッジケースを見つけて、レビューのスキルを持ち、反復して、変更を説明するビジネスロジックに焦点を当てたドキュメントを作成して、そこからコードの変更セットに焦点を当てたドキュメントに反復していくのがベストな流れだよね。そしたら、モデルがやった編集を一つ一つレビューしたい。平均して、これが大きな変更にかかる時間を3倍にするけど、ビジネスロジックの正確さやコードの質が大幅に向上するし、将来的にメンテナンスがかなり少なくて済むから、結局は一方での利益と、もう一方でのハーネスの改善(より質の高いコード、適切な情報、将来のモデルのための良い例)につながるんだ。問題は、モデルがこの種の作業がどんどん下手になってきてること。明らかに能力は向上してるのに、Opus 4.7とOpus 4.8の間でフィードバックループが明らかに悪化してる。これは私にとって非常に残念で、モデルがプロンプトから最終結果までを自分で出すように強化されていく一方で、私がますますループから外されているのがはっきりしてる。これがフラストレーションを増やして、私の仕事を遅くしてるだけなんだよね。