Real-SWE Benchmark、AIコーディングスコアとエンタープライズ業務の隔たりを明らかに
Specific Labsは、640回のエージェント実行を含むReal-SWE benchmarkを公開した。最高順位の構成でも、割り当てられた作業を解決できたのは38.8％にとどまった。
この結果は、公開コーディングリーダーボードとの不都合な対比を生む。エージェントはリポジトリ規模の課題を扱えるように見える一方、Real-SWEでは非公開の本番システムに対する試行の大半が失敗した。
この違いは、Real-SWEがより難しいプログラミングパズルを含んでいるだけではない。タスクでは、ビジネスルールを再構築し、未知のアーキテクチャをたどり、コードと接続されたサービスにまたがる変更を調整する必要がある。
この区別は重要だ。企業がソフトウェアエンジニアを雇うのは、孤立した文脈のない演習を解くためではない。顧客データ、権限、請求、インフラをすでに処理しているシステムを変更しながら、既存の動作を維持できるエンジニアを必要としている。
したがってReal-SWEは、公開ベンチマークの高スコアが示唆する期待に疑問を投げかける。未知のエンタープライズコードベースに入り込み、既知の公開アーティファクトに頼らず、経済的に有用な作業を完了できるかを問うものだ。
初期の答えは厳しい。ベンチマークは、コーディングモデルがもっともらしいパッチを生成できる証拠を提示している。しかし、重要なエンタープライズワークフロー全体への無監督デプロイを支持するものではない。
Real-SWE Benchmarkが実際に変えたこと
Real-SWEは、評価対象を公開リポジトリのissueから、企業固有のルールと運用上の依存関係を持つ非公開システムへ移した。
Specific Labsは2026年9月12日にこのベンチマークを発表した。同社はこれを、事業を運営する企業からライセンス供与を受けた非公開の本番コードベース上で、フロンティアモデルを評価するものだと説明している。
初回リリースは10件のタスクと、8種類のモデル・ハーネス構成を対象とする。各構成にはタスクごとに8回の独立した試行が与えられ、合計640回の採点対象ロールアウトが生成される。
この反復実行の設計は重要だ。1回の成功パッチは大きな不安定さを隠し得るが、8回の試行は、エージェントが同じ種類の問題を信頼性高く解けるかを示す。
公開されたリーダーボードはpass@1、すなわち1回の試行でタスクを解決できる確率を報告している。Specific Labsは、この結果を各タスクに割り当てた8回の実行全体で平均している。
Fable 5.1とClaude Codeの組み合わせが38.8％で初回ランキング首位となった。GPT-6 AstraとCodex CLIは33.8％で続き、Gemini 3.8 FlashとGemini CLIは31.2％に達した。
GLM 5.3とClaude Codeは28.8％を記録した。Grok 4.6とMuse Spark 1.3は、それぞれのエージェントシステムでいずれも23.8％に達した。
Kimi K3とKimi Codeは18.8％に達した。GPT-5.6 SolとCodex CLIは、この特定の評価で16.2％だった。
これらの結果が評価するのは、単体の言語モデルではなく組み合わせだ。ハーネスはツールを提供し、対話ループを制御し、モデルがリポジトリを探索・編集する方法を形づくる。
Specific Labsは、現在のエンジニアリングワークフローを反映することを意図したネイティブハーネスを使用したと明言している。この選択は実務的な関連性を高める一方、モデル間比較を複雑にする。
より高いスコアは、モデルの推論、ハーネスの挙動、ツールの信頼性、あるいはその3者すべての相互作用を反映し得る。リーダーボードだけでは、これらの影響を明確に切り分けられない。
ベンチマークにおけるより深い変化は、データの公開範囲に関わる。公開コーディングテストは通常、オープンソースリポジトリ、公開issue、可視化された解決履歴を使用する。
非公開リポジトリは、モデルが学習中に関連パッチに遭遇していた可能性を下げる。また、エージェントが公開検索で答えを見つけることも防ぐ。
公開されたReal-SWE resultsによると、各タスクは実在する非公開コードベースに関連する作業から生まれた。一部の指示は、実際のエンジニアリング作業から直接採られたとされる。
この設計により、評価はモデル向けに作られた試験というより、未知のソフトウェア組織に新しい請負業者を配置することに近づく。
この違いは、失敗の意味も変える。失敗したパッチはコーディング能力の弱さを反映する場合があるが、要件発見の不十分さやシステム理解の不完全さを示すこともある。
まさにこの領域で、エンタープライズ導入はリスクを伴う。パッチがコンパイルされ、明白なテストに通っても、事業の別の場所に埋め込まれたルールに違反する可能性がある。
非公開のエンタープライズコードが異なるテストを生む理由
中心的な課題は、より多くのコードを生成することではない。事業がすでに依存している動作を発見し、複数のシステムにまたがってそれを維持することだ。
Real-SWEの例の一つでは、エージェントに請求書の課税処理を修正するよう求める。短い説明の背後には、事業設定、顧客の免税、地域ルール、外部税務サービスに関する複数の条件が隠れている。
エージェントは、保存された税率を使用する場面と、購入者の配送先に基づいて税額を計算する場面を判断しなければならない。また、税金を徴収しないアカウントも認識する必要がある。
さらに、免税を維持し、請求書の合計を正しく記録し、請求書を停止させずに拒否された住所を報告しなければならない。確定した取引は税務当局に返却する必要がある。
欧州の取引では、VAT登録に関する追加要件がある。作業の完了には、TypeScriptサービス、TaxJar環境、InfluxDB台帳が関わる可能性がある。
これらの個々の操作は、特異なアルゴリズムではない。困難なのは、条件を見落としたり既存の動作を損なったりせずに、それらを連携させる点にある。
このパターンはエンタープライズソフトウェア全体に見られる。局所的に聞こえる要求が、しばしばAPI、データベース、バックグラウンドジョブ、設定、テスト、運用ツールをまたぐ。
Real-SWE環境では、Docker、Kubernetes、GitHub、PostgreSQL、MySQL、Redis、Slack、メール、顧客サポートシステムなどのサービスやツールにアクセスできる場合がある。
各タスクには、そのワークフローに必要なサービスだけが与えられる。それでもエージェントは、どのシステムに関連する証拠があり、どれが注意をそらす要素なのかを判断しなければならない。
ベンチマークによると、指示の長さの中央値は1,742文字である。これは詳細な実装仕様より短く、エージェントには利用可能なコードと文脈から構造を推測することが求められる。
参照ソリューションは中央値で11ファイルを変更した。ベンチマークの比較データでは、これはFrontierCodeとDeepSWEで報告された6ファイルという中央値を上回る。
この差は、リポジトリナビゲーションが重要である理由を説明する。明白な実装箇所を1つ見つけたモデルでも、検証、永続化、設定、下流の利用側を見落とす可能性がある。
Specific Labsによると、10件のタスクのうち6件は解決率が15％未満だった。テスト対象の構成で、すべてのタスクを解決したものはなかった。
失敗分析では、要件の見落としが最も一般的なカテゴリとされている。ほかに観測された失敗には、未検証の前提、統合エラー、リグレッション、誤ったファイルの編集が含まれる。
これらのカテゴリは、構文エラーよりも通常のエンジニアリングレビューコメントに近い。エージェントが完全なシステムモデルを構築せず、もっともらしい局所的変更を頻繁に生み出していることを示唆する。
時間だけでは、成功と失敗を分けなかった。ベンチマークによると、10分未満で終わった98回のロールアウトのうち70回が失敗し、失敗率は71.4％だった。
より長いロールアウトでは、542回中398回が失敗し、73.4％に相当した。したがって、より長い実行時間が弱い探索や誤った前提を自動的に修復したわけではない。
短時間と長時間の比較を、追加の推論が決して役立たない証拠として扱うべきではない。より難しいタスクほど長い試行を生み出す可能性が高く、大きな交絡要因となる。
それでも、この結果は都合のよい説明を弱める。これらのエージェントは、単にモデルが解答を入力し終える前にすべての実行が終了したから失敗したわけではない。
より妥当なメカニズムは、不完全な文脈形成だ。エージェントは要件を特定し、その実装を見つけ、依存関係を追跡し、変更全体を検証しなければならない。
このワークフローは、持続的なリポジトリ知識の恩恵を受ける。エンジニアリングチームが同じ理由でアーキテクチャノート、インシデント履歴、意思決定、技術文書を維持している。
検索可能なengineering knowledge baseは、人間にとって反復的な調査作業を減らせる。エージェントシステムにも、これと同等のコンテキスト層がますます必要になっている。
Real-SWEは、永続メモリがこれらのタスクを解決すると立証するものではない。しかし、ステートレスなコード生成がエンタープライズエンジニアリングの不完全なモデルである理由を示している。
公開コーディングスコアと非公開コードの現実
主な競争は、ベンチマークで可視化されるコーディング能力と、モデルが一度も遭遇したことのないシステム内での信頼できるパフォーマンスの間にある。
SWE-benchは、リポジトリのスナップショット内で実在するGitHub issueを解決するようモデルに求めることで、コーディング評価を変えた。これは、孤立した関数生成テストからの大きな進歩だった。
元のベンチマークは、issueの説明、リポジトリの状態、実行ベースの採点を結び付けた。ソフトウェアを探索、編集、テストするエージェントへと、この分野を前進させる助けとなった。
しかし、これらのリポジトリとissue履歴は公開されている。モデルが改善し、評価データが流通するにつれ、汚染を除外することは難しくなる。
汚染は、モデルの学習データにベンチマークタスク、関連パッチ、または近い複製が含まれる場合に生じる。その場合、高スコアには汎化だけでなく、認識や記憶も混在し得る。
SWE-bench Verifiedは、人間によるレビューを通じてタスク品質の改善を試みた。そのverified datasetは、issue説明とテストを精査した後、500件のサンプルを残した。
このレビュー自体が、コーディング評価の構築がいかに困難かを示した。OpenAIは、仕様、テスト、または関連する問題により、精査対象サンプルの68.3％が除外されたと報告している。
フィルタリング後のベンチマークは依然として有用だったが、公開データへの露出を排除したわけではない。モデル開発者は、リポジトリ、タスク、採点挙動、一般的な失敗パターンを引き続き調査できた。
より最近の監査は、新たな評価設計への圧力を高めた。OpenAIの2026年のbenchmark auditは、広く使われるコーディング評価における設計上および汚染に関する懸念を報告した。
この監査はまた、SWE-Bench Proタスクのおよそ30％が壊れていると推定した。報告された問題には、厳格すぎるテスト、不足する要件、弱いカバレッジ、誤解を招くプロンプトが含まれていた。
Real-SWEは、基盤となるリポジトリとソリューションを非公開に保つことで、この問題の一部に対処する。パッチが一度も公開されていなければ、モデルは正確な公開パッチを取得できない。
ただし、非公開データは別のトレードオフをもたらす。外部研究者は、すべてのリポジトリを自由に検査したり、すべてのタスクを再現したり、隠されたテストを監査したりできない。
ベンチマークが商業的に重要な主張を行うとき、これは透明性を低下させる。読者は、ベンチマーク運営者のライセンス、匿名化、タスク構築、採点プロセスを信頼しなければならない。
Real-SWEは、タスク例、集計結果、信頼区間、失敗分類を提供している。これらの開示は役立つが、公開され再現可能な評価と同じではない。
10タスクという規模も、別の制約を示す。反復実行は試行間の一貫性を測定するが、反復そのものがより広いタスクカバレッジを生むわけではない。
10タスクのベンチマークは、タスク選定の影響を受けやすい。1つのアーキテクチャ、言語構成、または事業領域が、ランキングに実質的な影響を与え得る。
モデルとハーネスの組み合わせも、不確実性をさらに高めている。Claude Codeは複数のモデルで登場し、Codex CLIも複数のモデルで評価されている。
このばらつきは、導入に関する有用な情報をもたらす。一方で、すべてのモデルが同一の足場とツールポリシーを与えられる統制比較にはならない。
したがって、正しい解釈は普遍的なモデルランキングよりも限定的だ。これらのスコアは、文書化された設定のもと、このReal-SWEリリースにおいて名前付きの構成がどのような性能を示したかを表している。
首位のモデルがすべての企業にとって最適であることを証明するものではない。また、最下位の構成に有用なコーディング能力がないことを示すものでもない。
むしろこのベンチマークは、公開スコアを非公開環境での導入期待値へ直接転用すべきではないという警告を発している。この警告は、評価分野で進むより広範な再検討とも一致する。
METRも、タスク方法論で関連する区別を示している。自己完結型のタスクでは、モデルに明確な成功基準が与えられ、組織の履歴への依存も限定されるよう意図されている。
METRは、実際の業務がしばしば過去の会話、暗黙知、既存コードベースへの習熟に依存すると指摘する。同組織の方法論は、エージェントを低コンテキストの業務委託者により近い形で比較している。
Real-SWEは、この低コンテキストの問題をさらに推し進める。実行可能な採点を維持しつつ、企業固有の慣習や運用上の関係性を導入している。
これがこのベンチマークにおける最も重要な転換だ。公開されたIssueでの高い性能は、信頼できるエンタープライズ自律性の十分な証拠ではなくなった。
リーダーボードはモデルベンダーだけでなく購入企業にも圧力をかける
Real-SWEは、ベンダーのスコアでは購入企業自身の環境での検証を代替できないため、エンタープライズの評価チームに圧力をかける。
コーディングエージェントを評価する企業は、通常、情報の非対称性に直面する。ベンダーは自社モデルを知り、購入企業は自社のリポジトリ、ワークフロー、リスク許容度を知っている。
公開リーダーボードは、双方に共通の参照点を提供する。比較を単純化する一方、導入環境がベンチマークと異なる場合には、その単純さが危険になり得る。
Real-SWEはその不一致を可視化した。最も強い構成でさえ、評価対象タスク全体では10回中6回以上の試行で失敗した。
購入企業は、この数値を想定される本番環境の失敗率へ直接置き換えるべきではない。10件のベンチマークタスクでは、すべてのリポジトリやエンジニアリング組織を代表できない。
それでもこの数値は、調達に関する議論を変える。チームに必要なのは、公開Issueの履歴における性能だけでなく、自社コードでの信頼性に関する証拠だ。
これは、代表性のある、過去に完了した業務から社内評価を構築することを意味する。適切なタスクには、既知の結果を持つバグ修正、移行、権限変更、統合作業などが含まれる。
参照実装が唯一許容される実装になってはならない。レビュー担当者は、機能的な正しさと、エンジニアが作成した元のパッチとの表面的な類似性を区別する必要がある。
隠しテストも精査が必要だ。検証器に明示されていない実装詳細が埋め込まれていれば、ベンチマークは有効な代替実装を不当に罰する可能性がある。
OpenAIのベンチマーク監査は、こうした問題がどれほど頻繁に起きるかを示している。評価品質には、指示、テスト、参照変更、エージェントのトレースを比較できる経験豊富なエンジニアが必要だ。
組織は完全な構成も評価すべきである。Real-SWEがモデルとハーネスの組み合わせを採点対象としたのは、コーディングエージェントが実際にそうした形で動作するためだ。
リポジトリ検索、シェルアクセス、テスト実行、コンテキスト管理、再試行ポリシーは、性能を大きく変え得る。基盤モデルだけを測定しても、こうした依存関係は見落とされる。
セキュリティも同じ評価に含めるべきだ。非公開ソースへのアクセスは、保持、プロバイダー側の管理、シークレットの露出、ログ、権限に関する問題を生む。
より多くのタスクを解決できるエージェントでも、組織が安全に付与できる範囲を超えたアクセスを必要とするなら、適さない可能性がある。能力と導入リスクは一体として評価しなければならない。
レビュー負荷も、もう一つの重要な指標となる。最終的に動作するパッチでも、人間による調査をあまりに多く要するなら、生産性向上の効果はほとんどない。
チームは、エージェントが要件を見落とす頻度、リグレッションを生む頻度、修正を促す追加プロンプトを必要とする頻度を記録すべきだ。これらの指標はReal-SWEの失敗カテゴリと密接に対応する。
ばらつきも追跡すべきである。一度の成功デモは、次の試行でもエージェントが同じ結果を再現できるかについて、ほとんど何も語らない。
Hacker Newsのベンチマークに関する議論は、この問題の両面を捉えていた。pass@1の反復試行は一貫性を明らかにするため歓迎する参加者もいた。
他方で、現在のツールは依然として人間との密な協働で最も力を発揮するという意見もあった。この見方では、熟練したオペレーターも評価対象となるシステムの一部であり続ける。
この「ケンタウロス」モデルでは、人間とAIエージェントを組み合わせる。人間は判断、文脈、レビューを担い、エージェントは探索、下書き、機械的な変更を処理する。
Real-SWEは、自律エージェントと専門家・エージェントのチームを比較してはいない。したがって、その結果をコーディング支援ツールに実用的価値がない証拠と読むべきではない。
示しているのは、より具体的な点だ。テストされた構成は、経験豊富なエンジニアが行う文脈把握と検証作業を、まだ信頼性高く置き換えられていない。
この違いは、導入に関する主張において重要だ。エンジニアを支援することと、エンタープライズの変更を自律的に担うことは、別の能力閾値である。
購入企業は、ベンダーに対し、その証拠がどの閾値を裏付けるのかを明示するよう求めるべきだ。公開スコアだけでは、その問いには答えられない。
Real-SWEの数値が証明しないこと
このベンチマークは意味のある警告を提供するが、小規模な非公開サンプルから、すべてのモデルやエンタープライズコードベースについて包括的な結論を導くことはできない。
第一に、Real-SWEのタスクはSpecific Labsが選定した企業に由来する。公開された例には、コンシューマー向けアプリケーション、フィンテックプラットフォーム、エンタープライズ向け営業ソフトウェアが含まれる。
Specific Labsによれば、対象アプリケーションの一つは20万人超のユーザーに利用されている。別のプラットフォームは、10万件超の銀行取引明細を処理しているとされる。
これらの詳細は商業的な関連性を裏付けるが、企業名は匿名のままだ。読者は、そのエンジニアリング品質、アーキテクチャ、ドメインの複雑性を独立して評価できない。
第二に、このベンチマークのプライバシー保護は、完全な公開再現を妨げる。このプライバシーはライセンスされたコードを保護し、直接的な汚染を減らす一方で、検証権限を集中させる。
独立した評価者には、タスクの出所、検証器の品質、環境の同等性、採点を確認するための統制されたアクセスが必要だ。その検証がなければ、一定の不確実性は避けられない。
第三に、リーダーボードは異なるネイティブハーネスを持つ異なるモデルを組み合わせている。これは実際の製品利用に近い一方、基盤となるモデル知能に関する結論を弱める。
構成が負ける原因は、検索戦略の失敗、ツール呼び出しの破綻、コンテキスト管理による関連証拠の破棄かもしれない。これらは製品としての失敗だが、同一の失敗ではない。
第四に、このベンチマークは自動解決を主要な成果指標としている。検証器を通過することは必要だが、エンタープライズで受容されるには、さらに多くの要件が必要になり得る。
本番レビューでは、保守性、可観測性、セキュリティ、移行の安全性、スタイル、将来の運用負荷が考慮されることがある。二値の合格判定では、これらの側面を完全には捉えられない。
逆に、有効なパッチが不完全な検証器により失敗判定されることもある。SWE-bench監査の歴史は、隠しテストが妥当な解決策を却下したり、不完全な解決策を見逃したりし得ることを示している。
Real-SWEは、必要な振る舞いが記述されるか、合理的に発見可能でなければならないとしている。この基準は妥当だが、「合理的に発見可能」かどうかには依然として判断が求められる。
第五に、匿名化されたビジネスタスクは、探索パターンがベンチマークに合致するモデルやハーネスを有利にする可能性がある。異なるリポジトリ構造なら、一部の順位は逆転し得る。
リーダーボードに示された95％信頼区間は、実行間のサンプリング変動を認めている。ただし、わずか10タスクを選定したことによる不確実性までは解消しない。
第六に、ローンチページは、エンタープライズのトークンの大半がフロンティアモデルから依然として見えない状態にあると広く主張している。この主張はベンチマークの動機を支えるものの、公開された測定詳細はない。
これは独立して確立された統計ではなく、同社の問題設定として扱うべきだ。より慎重な結論は、相当量のエンタープライズ文脈が非公開のままであるということだ。
最後に、自律的な解決率の低さは、生産性への影響の低さを意味しない。エージェントは、独力で完了できなくても、調査、テスト生成、ドキュメント作成、パッチの下書きを通じて時間を節約できる。
逆もまた真である。完了したパッチがレビューコストや微妙なリスクを生み、見かけ上の速度向上を相殺することもある。
これらの限界がReal-SWEを無関係にするわけではない。むしろ、その知見が有用となる条件を定義している。
このベンチマークは、導入上のギャップを示す証拠として最も強い。モデルの決定的なランキングや、エンジニアリング雇用の予測としては弱い。
Specific Labsも、エンタープライズデータと評価に関わる商業的な当事者である。同社の企業プロフィールは、現実的なエンタープライズ環境とデータセットを軸とする事業を説明している。
これは取り組みを無効にするものではない。独立した再現と透明な方法論の重要性を高めるものだ。
信頼できるベンチマークのエコシステムには、複数の運営者、定期的に入れ替わる非公開タスク、第三者監査が必要である。単一のリーダーボードが最終的な権威になってはならない。
Real-SWEが重要になるかを決める三つのシグナル
Real-SWEが重要な意味を持つのは、その非公開コードに関するシグナルが、規模拡大、独立した検証、繰り返されるモデルリリースを経ても維持される場合に限られる。
第一のシグナルは、タスクセットの拡大だ。10タスクでも失敗モードは明らかにできるが、より大きなコレクションでは、さらに多くの言語、アーキテクチャ、ビジネスドメインをカバーする必要がある。
拡大にあたっては非公開性を維持しつつ、読者がタスクの多様性を理解できるだけのメタデータを公開すべきだ。また、リポジトリに基づくサンプルと、他のタスク形式も分ける必要がある。
より広いテストセットでも順位が似通ったままであれば、持続的なエンタープライズギャップという主張は強まる。順位が大きく変動すれば、選定がローンチ時の結果を左右していたことを示す。
第二のシグナルは、独立した評価だ。外部研究者やモデル提供者には、タスク、検証器、実行環境を監査するための統制されたアクセスが必要である。
有用な監査では、プロンプトに十分な情報が含まれているか、隠しテストが代替実装を受け入れるか、参照実装が真の本番業務を表すかを調べるべきだ。
独立したレビュー担当者からの一致した評価は、報告された解決率への信頼を高める。テスト上の欠陥が見つかれば、ベンチマークの結論は限定または修正されることになる。
第三のシグナルは、反復されるリリースにわたる進展だ。タスクが漏えいしたり、学習対象になったり、エージェントシステムが適応するなかで固定されたままだったりすれば、非公開ベンチマークの価値は失われる。
Specific Labsには、新しいホールドアウトタスクと明確なバージョニングが必要になる。結果は、モデル、ハーネス、再試行、タスク露出による改善を区別すべきだ。
新しい非公開タスクでスコアが急上昇すれば、より良い汎化を示すことになる。改善が古いタスクに限られるなら、ベンチマーク自体に合わせた最適化を示唆する。
エンタープライズは、見出しとなる合格率とともに失敗の構成も注視すべきだ。より洗練された生成パッチよりも、要件の見落としや未検証の前提が減ることのほうが重要である。
一貫性も改善されるべきだ。タスクを時折解決するモデルでも、同じプロンプトでしばしばリグレッションを生むなら、信頼するのは難しい。
人間とエージェントの比較も、もう一つ有用な層を加える。レビュー時間と総完了時間を測定すれば、完全な自律性がなくてもエージェントがすでに価値を生む領域を示せるだろう。
Real-SWEは、モデル開発者と購入者に正しい問いを突きつけた。履歴、慣習、ビジネスロジックが一度も公開されていないソフトウェアを、エージェントは安全に変更できるのか。
最初の結果は、現在のシステムではしばしばそれができないことを示している。最高の構成でも解決できたのは10件中4件未満で、観測された失敗の大半は要件の見落としだった。
この結論は、全面的な否定ではなく、より良い評価を促すべきだ。エンジニアが対象範囲を管理し、文脈を与え、影響を検証するなら、コーディングエージェントは引き続き価値を発揮できる。
実務上の次の一歩は、権限を広げる前に、代表的な社内業務でテストすることだ。チームは構成を比較し、すべてのタスクを繰り返し実施し、一見妥当に見えるパッチがなぜ失敗するのかを検証すべきである。
Real-SWEベンチマークが重要になるのは、公開スコアを信頼する購買行動から、非公開環境での証拠を求める行動へと変える場合だ。次回のコーディングエージェント試験では、生成されたコードを測定するのか。それとも、自社が安全に受け入れられる完了済みの仕事を測定するのか。
