# FrontierCode Diamond：難しい50タスクでマージ可能率13.4%（2026年6月） > 2026年6月のFrontierCode結果。Diamondの難しい50タスクで13.4%、Extendedで51.8%という範囲と、AIパッチの確認方法を解説します。 Source: https://ailoot.ai/blog/ja/frontiercode-benchmark-mergeable-ai-code/ Canonical: https://ailoot.ai/blog/ja/frontiercode-benchmark-mergeable-ai-code/ Language: ja Publisher: Ailoot (https://ailoot.ai/) Translation: guide-173 Revision: sha256-6108476aba97061cc3946a21e855c1ee019d7a0ec2d2ec0d221aba5636fce2d3
重要なポイント 2026年6月8日、CognitionはFrontierCodeを公開しました。これは、実際のオープンソースリポジトリのメンテナーが、AI生成コードをプロジェクトに取り込むことに同意するかを測定するベンチマークです。注目すべき結果は、業界最高のモデルであるClaude Opus 4.8でさえ、最も難しい50のタスクのうち合格するのはわずか13.4%だということです。HumanEvalやSWE-benchなど従来のベンチマークは「コードが動くか」を測定していましたが、新しいベンチマークが測るのは「メンテナーはこのPRを受け入れるか」です。これは、AI生成コードを本番環境に投入するすべての人にとって、評価の枠組みを変えるものです。
ツールの設定に関する追加資料は、[Ailootのドキュメント](https://ailoot.ai/docs/)にあります。
[Ailootのガイド](https://ailoot.ai/docs/)
## FrontierCodeとは何か、そしてなぜ重要なのか？
重要なポイント FrontierCodeは、Cognitionが開発し、2026年6月8日に公開したAIコード品質ベンチマークです。パッチがメンテナー向けに定義されたマージ基準を満たすかを評価します。ベンチマークの定義上の結果で、全AIコードの一般的な本番準備率ではありません。主要なオープンソースプロジェクトのメンテナー20人以上が各タスクに40時間以上を費やし、正しさだけでなく、スタイル、セキュリティ、テストも必要となるシナリオを作成しました。
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をマージするか？」
重要なポイント FrontierCodeは各解決策を6つの軸で評価します。パッチがタスクを解決するか、他のコードを壊さないか、ビルドとlintのチェックに合格するか、有効なテストがあるか、スコープを守っているか、コードが読みやすいかです。マージ可能と判定されるには、6つすべてに合格しなければなりません。1つでも失敗すれば、PRはマージされません。これにより、評価基準は自動テストから実際のメンテナーの判断へと移ります。
6つの評価軸（Cognitionの公式ブログより）： 1. **動作の正しさ** — パッチはタスクを解決するか？ 2. **回帰への安全性** — 既存のコードを壊さないか？ 3. **機械的な品質** — ビルド、lint、スタイルのチェックに合格するか？ 4. **テストの正しさ** — エージェントが書いたテストは有効か（どんなコードでも通るテストは対象外）？ 5. **スコープ** — 要求されていないファイルに手を加えていないか？ 6. **コード品質** — プロジェクトの規約に従っており、読みやすいか？ マージ可能と判定されるには、パッチは**6つすべての軸**に合格しなければなりません。1つでも失敗すれば、マージされません。 これが視点の主な変化です。Cognitionの言葉を借りれば、「正しさはもはや最低条件」です。以前のベンチマークが問うたのは「コードはテストに合格したか？」でした。今、問われるのは「実際のテックリードはこれをプロジェクトに取り込むか？」です。 Cognitionは3つの新しい採点手法を導入しました。 - **Reverse-Classical**：エージェントが書いたテストは、壊れたバージョンのコードで失敗しなければなりません。そうでなければ、そのテストは見せかけです。 - **Code Scope**：自動チェッカーが、パッチがタスクで合意したファイルと行数の範囲内に収まっているかを検証します。 - **Adaptive Classical Grading**：LLMツールの「mutagent」が、厳格なテストを有効な解決策のバリエーションに適応させます。 ## なぜ従来のベンチマークはもう機能しないのか？
重要なポイント HumanEval（Codex、2021年）とSWE-benchは、コードが自動テストに合格するかを確認します。しかし、テストには合格しても誰もPRを受け入れないケース、つまりコードが粗雑で、隣接するモジュールを壊し、タスクの範囲を超えているケースは見つけられません。2026年3月、独立した研究がSWE-bench Verifiedから生成された296件のAI生成PRを実際のメンテナー4人とともに評価しました。メンテナーの判断は、自動評価より平均24パーセントポイント低い結果でした。つまり、「成功」とされたPRのおよそ半数は、実際のリポジトリにはマージされないということです。
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%
重要なポイント Cognitionは3つのサブセットにわたる12モデルのリーダーボードを公開しました。AnthropicのClaude Opus 4.8がDiamondで13.4%を獲得し、首位です。続くのはGPT-5.5の6.3%、Claude Opus 4.7の5.2%、GoogleのGemini 3.1 Proの4.7%です。オープンコードモデルの最上位は、MoonshotのKimi K2.6で3.8%です。Cognition独自のSWE-1.6モデルは表の下位に位置し、2.5%です。これは、自社を宣伝しているという批判への重要な反証です。
| モデル | Diamond（50） | Main（100） | Extended（150） | |---------------------------------|--------------|------------|----------------| | **Claude Opus 4.8**（Anthropic） | **13.4%** | 34.3% | 51.8% | | GPT-5.5（OpenAI） | 6.3% | \- | \- | | Claude Opus 4.7（Anthropic） | 5.2% | \- | \- | | Gemini 3.1 Pro（Google） | 4.7% | \- | \- | | GPT-5.4-mini（OpenAI） | 4.6% | \- | \- | | Kimi K2.6（オープンコードモデルの最上位） | 3.8% | \- | \- | | Claude Sonnet 4.6 | 3.5% | \- | \- | | **SWE-1.6**（Cognition） | **2.5%** | \- | \- | | MiniMax M2.7 | 2.4% | \- | \- | | MiniMax M2.5 | 1.1% | \- | \- | | Kimi K2.5 | 1.0% | \- | \- | | Gemini 3.1 Flash Lite | 0.7% | \- | \- | 表から読み取れること： - **明確な首位が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%」は何を意味するのか？
重要なポイント Diamondの選ばれた難しい50タスクにおけるOpus 4.8の報告実行では、13.4%がマージ基準を満たし、86.6%は満たしませんでした。却下分がすべて正しそうに見えたとも、普段のプロジェクトで同率になるともいえません。バイブコーディングの実践では、難しい変更をするとき、テストが成功したことだけを見てそのままプッシュできないという意味です。新しいプロジェクトでの単純な変更は別です。AIはそうした作業をうまくこなします。「いつプッシュし、いつ手作業で仕上げるか」の境界が変わったのです。
まず、重要な捉え直しがあります。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つです。
[Ailootのガイド](https://ailoot.ai/docs/)
## 難しいタスクでAIが起こす6種類のミスとは？
重要なポイント FrontierCodeの6つの軸は、AIエージェントが日常的に起こす6種類のミスに対応しています。これらは、結果が弱くなる予測可能なパターンです。ClaudeやCodexが作ったランダムなパッチを取り上げ、この6軸で評価すると、1項目でも失敗すれば実際のテックリードは受け入れません。安心して本番環境に投入するには、マージ前に自分でこの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つの手順
重要なポイント FrontierCodeの6軸とセキュリティチェックをカバーする5段階のチェックリストです。ClaudeやCodexからのパッチをリリースする前に、毎回確認しましょう。手順は少なく、それぞれ数分で済みます。見返りも大きいです。`git rewind`で本番プロジェクトをロールバックし、バックアップからデータベースを復元するのに4時間かけるより、チェックリストに10分使うほうがいいでしょう。
1. ### 変更に関係するテストだけでなく、テストスイート全体を実行する AIはタスクの範囲を超えてコードを変更することがよくあります。問題は隣接するテストに現れます。特定のファイルのテストだけでなく、単一コマンドの`npm test`でテストスイート全体を実行します（パスは指定しません）。大規模プロジェクトでは、git worktreeを使って並行して実行すると便利です（[Claude CodeのGit worktree](https://ailoot.ai/blog/ja/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と人によるレビューで確認します。 ## マージ可能なコードの確率を実際に高めるものは何か？
重要なポイント FrontierCodeは問題を示します。解決策はAIとの作業方法にあり、モデル自体を切り替えても、ここでは実質的な違いはありません。違いを生むのは3つの実践です。プロジェクトのルール、プロジェクトマップ、コンテキストエンジニアリングです。これらがなければ、Opus 4.8でさえ、もっともらしい粗悪品を作ります。これらは制約を明確にしますが、難しい変更はマージ前にリポジトリの検査とレビューが必要です。
準備されていないプロジェクトでは、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と同じ考え方で、「書き手」と「テックリード」の役割を分けます。 関連記事：[バイブコーディングのセキュリティ](https://ailoot.ai/blog/ja/vibe-coding-security/)、[夜間にプロジェクトを壊さないClaude Codeの設定方法](https://ailoot.ai/blog/ja/claude-code-safe-overnight-setup/)、そして概念としてのContext Engineering。
### 出典 - [Cognition - FrontierCodeの紹介（2026年6月8日）](https://cognition.com/blog/frontier-code) - [Cursor Bugbot - コードレビューエージェント](https://cursor.com/bugbot)
ツールの使い方に関する追加資料は、[Ailootのドキュメント](https://ailoot.ai/docs/)をご覧ください。
[Ailootのガイド](https://ailoot.ai/docs/)
[Ailootに移動](https://ailoot.ai/)
## FrontierCode Diamond：難しい50タスクでマージ可能率13.4%（2026年6月）：よくある質問 ### 13.4%は、全AIコードの本番品質の割合ですか？ いいえ。選ばれた難しい50タスクのDiamondで、Opus 4.8が得たマージ可能率です。同じ表の150タスクのExtendedは51.8%です。どちらも全AI生成コードの率ではありません。 ### テスト成功だけでは、なぜマージできませんか？ 回帰、ビルドとスタイル、壊れた実装を検出するテスト、範囲、コード品質も評価するためです。実際の差分を調べ、リポジトリの合格検査を実行してください。テスト1つの成功だけで全条件は証明できません。 ## Ailoot · 企業とそのプロジェクト群 Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。 企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。 Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。