FrontierCode Diamond：難しい50タスクでマージ可能率13.4%（2026年6月）

ツールの設定に関する追加資料は、Ailootのドキュメントにあります。

FrontierCodeとは何か、そしてなぜ重要なのか？#

Cognitionは、Devin（2024年3月に登場した初の自律型AIエンジニア）とWindsurf（2025年7月に買収）を手がけた企業です。また、独自のSWE-1.xモデル系列も開発しています。このベンチマークは、公開ブログのcognition.com/blog/frontier-codeで公開されました。

重要な変化は新しい数値ではありません。物事を測る尺度が変わったことです。

ベンチマークには3つの難易度があります。Extended（150タスク、全セット）、Main（Diamondを含む最難関の100タスク）、Diamond（極めて難しい50タスク）です。Cognitionは意図的にDiamondを「ほぼ未飽和」の状態にしています。最高のモデルでも解けるのは15%未満です。これは、ベンチマークに1年分の余裕を持たせ、HumanEvalのように1か月で飽和するのを防ぐことを目的としています。

FrontierCodeが測るもの：「メンテナーはこのPRをマージするか？」#

6つの評価軸（Cognitionの公式ブログより）：

1. 動作の正しさ — パッチはタスクを解決するか？
2. 回帰への安全性 — 既存のコードを壊さないか？
3. 機械的な品質 — ビルド、lint、スタイルのチェックに合格するか？
4. テストの正しさ — エージェントが書いたテストは有効か（どんなコードでも通るテストは対象外）？
5. スコープ — 要求されていないファイルに手を加えていないか？
6. コード品質 — プロジェクトの規約に従っており、読みやすいか？

マージ可能と判定されるには、パッチは6つすべての軸に合格しなければなりません。1つでも失敗すれば、マージされません。

これが視点の主な変化です。Cognitionの言葉を借りれば、「正しさはもはや最低条件」です。以前のベンチマークが問うたのは「コードはテストに合格したか？」でした。今、問われるのは「実際のテックリードはこれをプロジェクトに取り込むか？」です。

Cognitionは3つの新しい採点手法を導入しました。

• Reverse-Classical：エージェントが書いたテストは、壊れたバージョンのコードで失敗しなければなりません。そうでなければ、そのテストは見せかけです。
• Code Scope：自動チェッカーが、パッチがタスクで合意したファイルと行数の範囲内に収まっているかを検証します。
• Adaptive Classical Grading：LLMツールの「mutagent」が、厳格なテストを有効な解決策のバリエーションに適応させます。

なぜ従来のベンチマークはもう機能しないのか？#

AIエージェントは2024年までにHumanEvalで高得点を取るようになっていました。SWE-bench Verifiedも大差ありません。2025年8月、OpenAIは汚染問題を公に認めました（モデルが学習中にデータセットを「見ていた」のです）。ベンチマークは、トップモデル間の差を見分ける力を失いました。

従来の物差しを揺るがした重要な研究は、2026年3月に発表されました。

研究内容：

• 3つのリポジトリ（scikit-learn、Sphinx、pytest）から、活動中のメンテナー4人を選出しました。
• SWE-bench Verifiedから生成されたAIのPRを296件評価してもらいました。すべて自動テストには合格したPRです。
• メンテナーの判断を自動評価の結果と比較しました。

つまり、ベンチマークは「合格」と言う一方で、メンテナーは「マージしない」と判断します。これは平均して4分の1のケースで起きています。却下理由の上位3つを、深刻度の低い順に示します。

1. コード品質 — リポジトリのスタイルに合っていない。
2. 他のコードを壊す — 隣接するコードを壊している。
3. 中核機能の不備 — テストは成功しているのに、タスクを完全には解決していない。

FrontierCodeはまさにこの問題を体系化したものです。Cognitionはこのアイデアを取り入れ、メンテナー4人ではなく20人以上が参加する包括的なベンチマークに発展させました。

さらに追い打ちをかけるのが、AIが生成したパッチの安全性に関する2025年12月の研究です。

この研究では、Claude 4 Sonnetを使ったSWE-Agentの解決策の61%が機能的に正しかったものの、安全なのはわずか10.5%でした。

コードはテストに合格しますが、その一方でパッチの2つに1つはセキュリティ上の穴をもたらします。SWE-benchのベンチマークではセキュリティを測定しないため、これはまったく見えません。FrontierCodeは少なくとも「機械的な品質」とコード品質の軸で検出しようとしています。

モデルの順位：Opus 4.8は13.4%、GPT-5.5は6.3%#

表から読み取れること：

• 明確な首位が1つ。 AnthropicのOpus 4.8は、次点の競合をおよそ2倍引き離しています。SWE-benchでは見えにくかった差が、FrontierCodeでははっきり表れています。
• オープンモデルはまだ追いついていない。 オープンコードモデルの最上位であるKimi K2.6は、Diamondで3.8%です。Opus 4.8の3～4分の1にあたります。CognitionはMainとExtendedについて、Kimi K2.6の完全な結果を公開していないため、現時点では全セットでの比較はできません。
• Cognitionは自社モデルを正直に表の下位に載せました。

Diamondサブセットは意図的に「未飽和」の状態にされています。Cognitionは今後数年にわたる余裕を設けました。従来のベンチマークが12～18か月で飽和したのに対し、FrontierCodeはより高い上限を持つよう設計されています。

Claude Codeを使うバイブコーダーにとって「マージ可能13%」は何を意味するのか？#

まず、重要な捉え直しがあります。FrontierCodeのDiamondセットは、意図的に極めて難しく設定されています。依存するモジュールが40個もない、新しいスタートアッププロジェクトの一般的なタスクでは、AIエージェントはこれより明らかに良い成績を出します。同じOpus 4.8は、Extended（全150タスク）でマージ可能率51.8%を獲得しています。これはまったく違う見え方です。

51.8%は、150タスクのExtendedセットでの結果です。Diamondより高いものの、いずれも自分のタスクで全モデルのパッチがどれだけマージ可能かを推定する数値ではありません。他モデルのMainやExtendedが未掲載でも、成績を補ってはいけません。

本番環境への投入を目指すバイブコーダーにとって、これは次のことを意味します。

• テスト成功は、もはや「マージの準備完了」を意味しません。 AI自身が書いたテストは役に立たないことがあります。どんなコードでも合格する可能性があるからです。FrontierCodeはReverse-Classicalでこれを直接測定します。壊れたバージョンでテストが失敗しなければ、評価対象になりません。
• リポジトリのスタイルと規約が重要です。 プロジェクトに確立されたパターンがあり、AIがそれに従わなければ、実際の共同作業者は変更を受け入れません。ルールのない個人プロジェクトでは大きな問題ではありません。チームでは、最初に直面する問題です。
• テストでセキュリティの問題は解決しません。 先ほどの数値を思い出してください。正しいパッチが61%ある一方で、安全なものはわずか10.5%です。これはトークン、.envファイル、デフォルトパスワードを検出するツールを使って、別途確認する必要があります。
• タスクの範囲を超えることは、AIによくあるミスです。 認可関数を修正するよう頼んだら、内部レイヤーとログまで書き換えるパッチが返ってくる。これはFrontierCodeの6軸の1つです。

難しいタスクでAIが起こす6種類のミスとは？#

各軸を平易な言葉で見ていきましょう。

1. 動作の正しさ — パッチはタスクを解決するか？

最も基本的な軸です。AIは解決策のように見えるコードを書きながら、間違った問題を解いていることがよくあります。「メッセージに既読通知を追加して」と頼むと、markAsRead関数ができても、チャットコンポーネント自体には接続されていないことがあります。関数のテストには合格します。しかし、業務上のタスクは解決していません。

2. 回帰への安全性 — 隣接するコードを壊さないか？

AIが1つのモジュールを変更したら、別のモジュールが動かなくなる。よくあるのは、AIエージェントが関数のシグネチャを変更し、その関数がほかの17か所から呼び出されていることを忘れるケースです。SWE-benchでは気づけません。1つのファイルのテストしか実行しないからです。FrontierCodeでは、リポジトリ全体のテストスイートを実行します。

3. 機械的な品質 — ビルド、lint、スタイルのチェックに合格するか？

AIはローカルではコンパイルできても、CIでは失敗するコードを作ることがあります。importの不足、スペースの代わりにタブを使うこと、行末の余分なスペースが2つあること、あるいはeslint.config.jsの誤りなどです。稼働中のプロジェクトでは、スタイルは気まぐれではありません。チームのルールです。

4. テストの正しさ — AIが書いたテストは有効か？

最も厄介な軸です。AIがテストを書き、合格します。しかし、壊れたコードを含め、どんなコードでも合格するテストです。何度も見てきました。「正しい結果を返したか」ではなく、「スクリプトがクラッシュしたか」を確認するテストです。FrontierCodeのReverse-Classicalは、まさにこのケースを検出します。

5. スコープ — 関係のないファイルに手を加えていないか？

1つの関数を直すよう頼むと、タスクと無関係なファイルまで含む12ファイルへのパッチが返ってくる。これは、頼んでもいない変更によって本番プロジェクトを壊す、AIの「気の利かせすぎ」です。この軸はFrontierCodeで明確なブロッカーになります。

6. コード品質 — リポジトリの規約に従っているか？

AIはlib/に既存のヘルパーがあるのに、それを使わず関数を「一から」書くことがあります。あるいは、変数名がプロジェクトのスタイルに合わないことがあります。または、アーキテクチャ上、間違ったレイヤーにロジックを置きます。テスト上はすべて動いています。テックリードの視点では、マージできません。

AIコードをプッシュ前にチェックする方法：5つの手順#

1. 変更に関係するテストだけでなく、テストスイート全体を実行する

   AIはタスクの範囲を超えてコードを変更することがよくあります。問題は隣接するテストに現れます。特定のファイルのテストだけでなく、単一コマンドのnpm testでテストスイート全体を実行します（パスは指定しません）。大規模プロジェクトでは、git worktreeを使って並行して実行すると便利です（Claude CodeのGit worktreeを参照）。

2. lint、スタイル、型のチェックを実行する

   3つのコマンドを順番に実行します：eslint .、prettier --check .、tsc --noEmit。AIエージェントは、タブも行末の余分なスペースも見落とすことがあります。プロジェクトに厳格なチェックがある場合は、リリース前にローカルで実行してください。

3. テスト自体をテストする

   5つのチェックの中で最も重要です。コードに小さな「故障」を仕込みます（return trueをreturn falseに変更します）。テストは失敗するはずです。失敗しない場合、AIが形だけのテストを書いたのであり、役に立ちません。そのテストを削除し、「壊れたバージョンでテストが失敗しなければならない」という条件を明示して、AIに書き直しを頼みます。

4. AIが変更したファイルを確認する

   git diff --statコマンドで、変更されたファイルと行数を確認できます。「問い合わせフォームを直して」という依頼に対してAIが12ファイルに手を加えたなら、タスクの範囲を超えています。余計なファイルは、ファイルを指定した単一コマンドで元に戻します。

5. 既製のスキルでセキュリティチェックを実行する

   テストではSQLインジェクションやハードコードされたパスワードは見つかりません。Claude Code向けの既製のセキュリティスキルを使います（既製のセキュリティスキル754個を参照）。最低限、プロジェクト内のコードで「password」「secret」「key」という単語を手動で検索し、.env.exampleに必要な項目がそろっているか確認します。

5つの手順で、FrontierCodeの6軸のうち5つ（1～5）をカバーできます。残る6つ目の軸であるコード品質は、lintと人によるレビューで確認します。

マージ可能なコードの確率を実際に高めるものは何か？#

準備されていないプロジェクトでは、AIエージェントに見えるのは、あなたが開いたファイルだけです。判断の履歴も、規約も、モジュールの地図もありません。単純な変更なら大きな問題ではありません。難しい変更では文脈不足に対処すべきですが、ベンチマークの13.4%は、その原因を文脈品質だけへ切り分けた結果ではありません。

この13%を、実際に本番環境へプッシュできるものに変えるために必要なこと：

1. プロジェクトのルール — インターネットの平均ではなく、あなたの考え方をAIに再現させる。

これは、あなたが用意した解決策、習慣、学んだルールをまとめ、AIエージェントがリクエストごとに読み込める形式にしたものです。ルールが30個以上になると、AIは「業界平均」をでっち上げなくなり、あなたのスタイルで提案するようになります。リクエストの範囲を超える問題には、ルールに「リクエストで明示されたファイル以外には触れない」と1行加えることで対処できます。

2. プロジェクトマップ — プロジェクトを説明するフォルダー。

ここには、製品、ユーザー層、経済性、指標、設定などを置きます。リクエストの前に、AIエージェントは目次を読み込み、ビジネスのどの部分を担当しているのかを理解します。これにより、前述の却下理由のうち2つ（スタイルと他のコードを壊すこと）に自動的に対処できます。

3. Context Engineering — リクエストの前にAIが見る情報を管理する。

これは「プロンプトをどう書くか」ではなく、「プロンプトの前にコンテキストウィンドウに何を入れるか」です。CLAUDE.md、前提条件、対象を絞ったファイルへのリンクなどです。これにより、動作の正しさとコード品質に関する失敗に対処できます。

この組み合わせは検査の準備として使い、すでに5軸へ合格した証拠にはしないでください。受け入れる前に、実際のパッチで動作、回帰、テスト、範囲、コード品質を検証します。

追加の層として、レビューエージェントがあります。

• Cursor Bugbot — 各PRを自動でレビューします。Cursorによると、このツールは月に約200万件のPRを処理します。
• Claude Code v2.1.172のネストされたサブエージェント — 1つのエージェントがコードを書き、2つ目がレビューし、3つ目がテストを実行します。これはFrontierCodeと同じ考え方で、「書き手」と「テックリード」の役割を分けます。

関連記事：バイブコーディングのセキュリティ、夜間にプロジェクトを壊さないClaude Codeの設定方法、そして概念としてのContext Engineering。

ツールの使い方に関する追加資料は、Ailootのドキュメントをご覧ください。