ソフトウェア開発におけるAIモデルのコーディング能力を測る従来のベンチマークは、現実のタスクを反映しておらず、解答のリークによるチートが横行しているため信頼性に欠ける。Data Curve社が新たに開発したDeepSWEベンチマークは、より実践的なプロンプトと未学習の新規タスクを用いてエージェントの真の実力を測定する。この検証により、OpenAIの最新モデルが圧倒的な性能を示す一方、他のモデルとの間には従来のスコア以上の巨大な性能格差が存在することが明らかになった。
既存のAIベンチマークへの疑念
開発者としての私たちの仕事にどのモデルが本当に適しているのかを知ることは、どんどん難しくなっています。そのためにベンチマークがあるはずですよね。SWEBench ProやArenaのような素晴らしいベンチマークがあり、どのモデルが実際にコーディングが得意かを教えてくれるはずです。しかし現実を見てみましょう。MythosがSWEBench Proで素晴らしい成績を収めるのを見るのはクールですが、個人的にはQuen 37 MaxやGLM 5.1がOpenAIの最先端モデルより意味のあるレベルで優れているとは信じていません。また、Gemini 35 FlashがGPT 54やGPT 55に肉薄しているとも全く思えません。それは明らかに事実ではありません。このベンチマークの数字はしばらく前から無意味なものになっており、SWEBench Proが現実的なコーディング問題に対する現実的なベンチマークになるはずだったことを考えると非常に残念です。問題の質がひどいだけでなく、データが汚染されています。これらの問題を解決するための情報の多くがリークしており、モデルは日常的に不正行為を行いますが、結果を検証する人々はその不正をほとんど測定していません。率直に言って、このベンチマークはかなりひどいです。そして、特に汚染が判明した後もこれがここまで長く使われてきたことはフラストレーションが溜まります。Artificial Analysisは独自のより良いコーディング測定スイートを作ろうと様々なものをまとめようと最善を尽くしてきましたが、それでもまだ素晴らしいとは言えません。明確にしておくと、Artificial Analysisのコーディングエージェントベンチマークは、彼ら独自のベンチマークというよりは、既存の他のベンチマークを組み合わせて、様々なハーネスやモデルで実行しているものです。これらのベンチマークが実際にテストしている問題を見に行けば、なぜそれらがそんなにひどいのか理解できるでしょう。心配しないでください、それについてはこの動画の後半で実際に見ていきます。ここでの問題は誤解を招くほどシンプルです。ベンチマークの対象となっている問題は、私たちが毎日エージェントを使って解決しようとしている実際の作業をリアルに反映していません。プロンプトは少し無意味ですし、使っているツールの構造も理にかなっていません。リポジトリにはすでに解決策が存在しているため、モデルは不正行為が可能です。私たちが毎日実際にやっている仕事と比較すると、これらのベンチマークの仕組みには多くの間違いがあります。
より現実的なベンチマークDeepSWEの登場
少なくとも、以前はそうでした。しかし今はDeepSWEがあります。これは私が何年もの間、データやリサーチ側の知り合い全員に作ってくれと懇願してきたものとほぼ同じです。実際のプロジェクトでエージェントを使って何かを構築する際の手法を正確に反映したベンチマークが欲しかったのです。そして今、ついにそれが手に入りました。その結果はあまりにも決定的で、私は偏見を持っていると非難されるかもしれません。このベンチマークが何であるか、どのように機能するか、そして私たちが慣れ親しんでいるものと比較して結果がどれほど驚異的であるかを解説するのが待ちきれません。しかしその前に、私のバイアスについて開示しておく必要があります。私はData Curveの投資家です。私が彼らにこれをやるように強く迫った理由の一部でもあり、彼らがこれを作ってくれて私がこれほど嬉しい理由でもあります。また、私は自分の人生で投資したどの会社よりも、この会社に対して厳しい意見を言ってきました。彼らがこれを成し遂げたことを非常に誇りに思っていますが、皆さんが考えるような形での偏見は持っていません。そしてAIラボに関しても、私にもData Curveにも特定の偏見はありません。彼らについては後でもう少し話します。
スポンサーメッセージ Browserbase
しかしその前に、今日のスポンサーのために少しだけ偏見を持たせてください。AIモデルはついに、コンピュータの操作を魅力的に思わせるほどに進化しました。エージェントがあなたのコンピュータをナビゲートして様々なことを行うのを見るのは、彼らが立ち往生するまでは本当に驚くべきことです。そして彼らは頻繁に立ち往生します。UI上の入力フィールドが見つけられなかったという理由だけで、たった一つのフィールドを更新しようとしてエージェントが立ち往生したばかりです。少し狂いそうになりましたが、今日のスポンサーを見て、Browserbaseを使っている限りこの問題は解決されると気づきました。具体的には、新しいBrowserbaseのbrowseパッケージを使用する場合です。これはエージェント用のブラウザCLIです。どういう意味でしょうか。私のAIはすでにブラウザを使えると思っていたかもしれませんね。確かに使えますが、何をすべきかを本当に分かっているわけではありません。ページのスクリーンショットを撮り続け、探し物をし、見つけられることはめったにありません。どこに何があるかを知る必要があるのです。その知識を与えるための最良の方法の一つがスキルです。Browserbaseは、あなたが関心を持つであろうすべてのウェブサイトをナビゲートするために必要なすべてのスキルのコレクションに取り組んでいます。まず、関連するすべてのウェブサイトをスキルとして追加すると、インデックスを調べてサイトを適切に使用するために必要な情報があるかどうかを確認してくれます。すべてのスキルが追加されたら、あとはいつも通りClaudeを使うだけです。毎晩のキャンプ場とEV充電の休憩を含めたユタ州へのロードトリップを計画し、Rampで予約して払い戻しを申請してと頼むことができます。これは本当に信じられないことです。これほど多くの異なるステップを一度で成功させるとは以前なら予想もできませんでしたが、適切なスキルを持っていればそれができるのです。もっと細かく制御したい場合も可能です。今いるページの特定のUI要素を呼び出すには、browse clickのようなシンプルなコマンドとクリックしたい入力内容を指定するだけです。あるいは、サンフランシスコのアパートといった特定のテキストを入力させたり、オプションを選択させたり、キーを押させたり、マウスで移動やスクロールさせたり、スクリーンショットを撮ったり、コンテンツを取得したりするように指示することもできます。そしてこれは、すでに使っているどんなツールとも一緒に使えます。自分の仕事を自動化し、デプロイなどの作業を進めようとすればするほど、実際にエージェントに自分のコンピュータ上で作業させるためにこのようなツールを使う価値を強く感じるようになりました。セッションをクラウドに移行する準備ができたら、ぜひ専用リンクからBrowserbaseを試してみてください。
未来からの追記：Opus 4.8の結果について
未来のテオからのご挨拶です。状況は本当に驚くほどのスピードで変化するため、未来のある日のことです。皆さんの多くがこのチャートを見て、テオはOpus 4.8が出る前にこの動画を公開したから、Opusがすごく悪く見えるのも当然だと言っているのは分かっています。だからこそ、今私がここにいます。Data CurveはまだOpus 4.8の最終的な数字をまとめているところですが、現時点で分かっていることを共有したいと思います。彼らは最初、他のすべてのテストで使用されたMini SWEハーネスの代わりにClaude Codeハーネスを使用して実行しました。その結果、Opus 4.7とほぼ同等のパフォーマンスを示しましたが、コストは大幅に安くなりました。これは良い変化です。それでもOpenAIモデルよりはかなり遅く、特にClaude Codeで使用する場合は少し賢さに欠けます。しかし、彼らはMini SWEを使用して追加のテストを行い、スコアの大幅な向上を確認しました。その結果、スコアは63%まで跳ね上がり、70%のGPT 55にかなり近づきました。彼らはなぜOpusがClaude Codeと比較してMini SWEでこれほど優れたパフォーマンスを発揮するのかについて仮説を立てています。現在の彼らの理論は、Claude Codeのシステムプロンプトが、これらのワンショットテストを実行するモデルの能力をある意味で妨げているというものです。正直なところ、私もそう信じたいと思っています。Claude Codeが実行前に立ち止まって質問をし、フィードバックを得るのが好きだということは知っていますが、Claude Codeのシステムプロンプト自体がちょっとゴミのようなものだということもあります。だから全く驚きません。私がここで録画してから何かしらの変更があった場合は、必ずコメント欄にピン留めしておきます。数字が変わっていないか確認したい場合は、そちらを見てください。この動画のそれ以外の部分は、ベンチマークに関する文化、これらの事柄を測定するために私たちが使用する技術、そして最も重要なこととして、現実のコードベースでエージェントを機能させるために実際にどのようにプロンプトを出すべきかについて語っているため、依然として非常に価値があります。SWEがどれほどひどいかを知るにつれて私も徐々に狂気に陥っていきますので、引き続きお楽しみください。
最新ベンチマークにおけるOpenAIの圧倒的優位
結果について皆さんの期待を煽り続けたい誘惑に駆られますが、それはやめておきます。ただ結果をお見せして、それから話し合いましょう。OpenAIがこのベンチマークで圧倒的な勝利を収めました。GPT 55が70%の成功率で断トツのトップでした。次に高かったのはGPT 54で56%です。そしてようやくAnthropicのモデルであるOpusが54%で登場します。そこから大きな落ち込みがあり、これがここで最も注目すべき点ですが、Opus 47から次に高いSonnet 46へのギャップです。54%から32%へと、約50%も落ち込んでいます。一体何が起きているのでしょうか。OpenAIのモデルをこのベンチマークでこれほど優秀にし、他のモデルをこれほど悪くする原因は何なのでしょうか。まず、チャットですでに起きているようなので、偏見についての非難に答えておきます。Data CurveがOpenAIからお金をもらってこのベンチマークを作ったのではないかと考える人がいるようです。このベンチマークをOpenAIに見せたのは私です。私が彼らに連絡してこのことを教えたのです。Data Curveの仕事は、モデルのコーディング能力を高めるためのより良いコードデータのキュレーションを支援するため、データをラボに販売することです。彼らが直面していた問題は、ラボが自社のモデルはコードに非常に優れていると報告していたのに、実際にモデルを使って結果を見てみると、とんでもないゴミがたくさん出てきたことです。モデルのコーディング能力に関する報告と実際の使用感のギャップに彼らは非常に混乱していました。彼らは特にSWEBench Proについて深く掘り下げました。このベンチマークはコーディングタスクにおいて私たちが持っていた最高のものの一つでしたが、正直なところ、含まれる問題の質はあまり高くありません。しかしさらに重要なのは、結果の分析の質が完全にゴミだということです。彼らはAIを使って結果を分析し、期待通りに進んだかどうかを確認するために検証を行っていますが、これらのテストを実行すると、アナライザーとベリファイアの意見が食い違うことがよくあります。ベリファイアが失敗と判定したのに、アナライザーが正しいと判断したケースが19%から28%の実行で発生しました。カンニングというバケツに分類されるものがあります。ベリファイアはコードが機能して合格したと判定したものの、アナライザーが履歴を見てやってはいけないことをしたと判断した場合です。これがOpus 46および47のトライアルの約13%で発生しました。それらの不正な実行の87%は、適切な形状を見つけるためにGit履歴からエージェントが読み取りを行ってカンニングしたものでした。彼らがSWEBench Proのベリファイアが行ったことを比較するために実際にアナライザーを書いていたとは知りませんでした。そしてこれらのギャップを見つけたのです。彼らの監査によると、SWEBench Proは偽陽性の約8%、偽陰性の24%を誤って採点しています。それを進行中の汚染と組み合わせると、このベンチマークはかなりひどいものです。このベンチマークに疑問を持っているなら、このチャートがあなたを納得させるはずです。SWEBench Proでの数字と、この新しいDeepSWEベンチマークでの数字を比較しています。Gemini 3 Flashのようなモデルを使ってコーディングしようとしたことがある人なら、Sonnetが54%を獲得したときにGeminiが35%を獲得するというのが無意味であることが分かるでしょう。これらのモデルは30%の範囲内に収まるようなものではありません。全く別の世界にいます。Sonnet 46は実際に仕事ができますが、Gemini 3は全く使い物になりません。ここには間違いなく確証バイアスがあり、私や私が話をした多くの人々が、このベンチマークが測定するのと同じようにモデルが振る舞うのを見聞きし、経験してきました。私は個人的には実際の開発作業にGeminiモデルを使いません。ツール呼び出しのループに陥ったり、適切なファイルを見つけられなかったり、全くコンパイルできないコードを書いたりして、すぐに失敗するからです。実際の仕事ではただ良くないのです。物事を綺麗にするために1つのCSSファイルを編集することくらいはできるかもしれませんが、実際にコードベースをナビゲートして物事を終わらせることに関しては、全く話になりません。SWEBench ProではSonnet 46がGemini 3 Flashの1.5倍優れていると判定されましたが、彼らのベンチマークではSonnet 46はGemini 3 Flashの6倍優れていると判定しています。これは巨大なジャンプであり、このベンチマークがいかに優れているかを示しています。私にとって最もクレイジーなのは、最下位とトップのギャップが非常に大きいことです。HaikuとGPT 55を比較してみましょう。SWEBench Proではそれらの間には20ポイントの差があります。DeepSWEでは70ポイントの差があります。ついに、実際に見たり学んだりするのに役立つ範囲ができたのです。
DeepSWEのテスト構造と検証の質の高さ
では、このテストの何がそんなに違うのでしょうか。どのようにしてこのような驚異的な結果を得ているのでしょうか。OpenAIモデルのパフォーマンスを良くし、Anthropicモデルのパフォーマンスを悪くするようなヒントを入れているのでしょうか。いいえ、彼らはより現実的にしただけです。すべてのタスクはゼロから書かれています。既存のコミットやPRを使用しているわけではありません。行っているタスクの多様性もはるかに高いです。SWEBenchのように半分がPythonというわけではありません。プロンプトの長さはSWEBench Proのプロンプトの半分ですが、解決策には5倍のコードと2倍の出力トークンが必要です。しかし最も重要な部分は検証レイヤーです。ベリファイアは実装の詳細ではなくソフトウェアの動作をテストするために手書きされています。これの多くはプロンプティングに関わってきますが、彼らがこれについてどのように話しているかが私はとても好きです。彼らは、強力なモデルはプロンプトで指示されない限り自分自身の作業をテストすると述べています。これはSWEBench Proの最大の問題の一つです。結果を検証するための独自のテストを書かないようにモデルに指示しているのです。そのため、モデルはコードを書いてそれが機能することを祈るだけになります。言われた通りにするモデルもあれば、そうでないモデルもあるからです。そしてOpusモデルやClaudeモデルは一般的に、求められたことを無視してやってはいけないことをする傾向があるため、より多くの不正行為を行います。指示されていないときにテストを作り、ハッキングやカンニングなどをして正しい答えを導き出す可能性が高い状況を自ら作り出します。このテストのプロンプトは2つの段落ではなく2つの文のように非常にシンプルなので、結果としてモデルは自分が正しいと思うことをより多く実行できます。カンニングするためのリソースがない場合は、自分でリソースを作らなければなりません。その結果、信頼性ははるかに高くなります。SWEBench Proでテストを書くべきではないときにモデルがテストを書いた頻度と、DeepSWEで指示を与えられなかったときにテストを書いた頻度を示す数字があります。ここでOpus 47を見ると、テストを書かないよう指示されたにもかかわらず、28%の確率でテストを書いています。そして指示を与えられなかった場合は83%の確率でテストを書きました。V4はSWEBench Proではその半分近くの18%の確率でテストを書きました。そしてこのベンチマークでは85%にまで上昇しています。率直に言って、SWEBench Proは、カンニングが許可されテストを書かないよう明示的に指示された汚染されたPythonリポジトリでモデルがどれだけ優れているか、そしてその指示をどれだけ無視しそうかをテストしているのです。つまりSWEBench Proは、人々が行った既存の作業に対して、本当にひどく下手に書かれたプロンプトでテストされているという意味でのみ現実的だと言えます。そしてOpusは確かにプロンプトを無視するのが得意です。もしあなたが求めたことを無視するのが最も得意なモデルを探しているなら、Opusはまさにうってつけのようです。もし求めたことを正確に実行するモデルを探しているなら、それを示すベンチマークがついにできたということです。
現実的なプロンプトとSWEBenchの欠陥
他にもウォールクロック時間、出力トークン、ベンチマーク実行にかかる実際のコストなど、掘り下げるべき面白い点がたくさんあります。それらについては後で話します。しかしその前に、彼らが例を公開しているので実際の例をいくつかお見せしたいと思います。DeepSWEのプロンプトは、開発者がエージェントに話しかける方法と一致しています。それらは動作に焦点を当てており、短く、過度に冗長で規範的な大きなインターフェース定義ブロックを含んでいません。エージェントは、変更をどこでどのように実装するかを発見しなければなりません。そのため、評価される能力のかなりの部分は、過度に指定されたエンジニアリングタスクの単なる実行ではなく、エンドツーエンドの探索に関わっています。GitHubのイシューやプルリクエストから引用された公開ベンチマークには、詳細すぎる情報が含まれていることがよくあります。再現手順、追加のコンテキスト、コードスニペット、特定のシンボルやシグネチャを想定したテストなどです。代わりにDeepSWEは観察可能な動作をスコアリングするため、基盤となるタスクが大幅に長い場合でもプロンプトを短く自然に保つことができます。つまりプロンプトの長さは半分です。追加される行数は5倍で、触れるファイルの数もはるかに多いです。技術の範囲も全体的にずっと優れています。TypeScriptが約30%、Goが約30%、Pythonが約30%、そして他のいくつかの言語があります。これは5つの言語にわたる91のアクティブなリポジトリで行われており、SWEBenchの12とは対照的です。しかし最も重要なのは、すべてのタスクが新規のものであるということです。そのため、GitHub上にエージェントが見つけてカンニングに使えるような既存の解決策はありません。そして偽陽性率と偽陰性率の低下は異常なほどです。彼らのベリファイアはわずか0.3%の確率でしか偽陽性を出しませんでした。SWEBench Proはほぼ10%で、偽陰性は24%から1.1%まで低下しました。ではこれらの例のいくつかを見てみましょう。トップ3だけ見ていきます。これはHappyDOMというGUIなしのウェブブラウザのJSインターフェースに対するものです。これは実際のDOMなしでDOMのテストや操作を行うのに非常に便利です。また、これは正しく実装しなければならない複雑な実装の詳細が大量にあることも意味します。これがプロンプトです。HappyDOMは現在、happydom.close、page.close、browser.close、またはアクティブなページ状態を入れ替えるナビゲーションを通じてシャットダウンされた際、リクエストやレスポンスのボディ消費を中断し、非同期の作業を無効な状態で残してしまいます。読み取りはAbortErrorという名前のDOMExceptionで拒否されなければなりません。同じシャットダウンの動作はマルチパートフォームデータの解析にも適用されるべきです。中断されなかった成功した読み取りは変更されないままにするべきであり、完全にバッファリングされたレスポンスボディはシャットダウン後も読み取り可能でなければなりません。破棄されたページに関連付けられたスケジュールされたタイマーとrequestAnimationFrameコールバックもクリアされなければなりません。素晴らしい。これは良いプロンプトです。具体的にはこのプロンプトは目標が何であるかを非常に明確に示しています。適切に動作する場合、これは何をすべきでしょうか。ここで全てのAnthropicモデルが合格したことがわかります。Gemini 35 Flashも合格し、GPT 54とGPT 55も合格しました。DeepSeek V4は4回中3回合格しました。GLMとKimiは4回中3回です。Mimoは失敗し始めました。Gemini 3 Flashは半分の確率でエラーになりました。31 Proはほとんど失敗しました。そしてまた地獄に戻ります。このことを見ていく上で、このようなタイプの問題について皆さんに本当に考えてほしいと思います。なぜなら、皆さんも似たようなものを作る機会があるはずだからです。自分の仕事にモデルを使ってみて結果があまり良くないと感じた場合、それが起こるたびに書き留めてください。試したモデル、使用したプロンプト、使用していたツール、そしてプロンプトを試したときのコードベースとハッシュを書き留めたメモをどこかに残しておいてください。プロンプトを少し調整してみて探している結果が得られるかどうかを確認するのもいいでしょう。しかし最も重要なのは、これらの失敗のコーパスを保持しておくことです。エージェントがあなたが望む作業を実行できなかったときの記録をつけ、それを保管しておいてください。新しいツールが出たときに自分で測定することができます。自分自身のミニベンチマークを作成することもできます。これらのモデルはそういったことを行うのが非常に得意です。これらの例を集めてどこかのサンドボックスに投げ込み、どのエージェントがそれを解決できてどれができないかを確認できれば、あなたとあなたのビジネスにどのモデルが適していてどれが適していないかを判断するための有用な測定基準を手に入れることができます。公に共有できるほど良いものができるかもしれません。私たちはベンチマークを心底必要としています。日々の仕事の中でモデルが本来すべきことをしないという経験をしているなら、あなたは私が持っていないもの、つまりこれらのベンチマークの一つを作るためのデータを持っています。やってみてください。それほど難しいことではありません。そして、小さくて一見くだらないベンチマークをまとめたとき、リサーチコミュニティがどれほど早くそれに気づくか驚くでしょう。SnitchBenchとSkatebenchへの反響の良さには本当に圧倒されました。答えを知りたい奇妙な疑問を持っていた一人のYouTuberが作った、この2つのくだらないベンチマークへの反響です。この機会を活用してください。構築するのはそれほど難しくありません。SWEBench Proの作成者はプロンプトを読みにくくしているように感じます。なぜならこれが実際に見る唯一の方法であり、めちゃくちゃだからです。彼らが持っている最初の例はNodeBBというNode.jsベースのフォーラムソフトウェアで、長い間誰も使っているのを聞いたことがありません。でもまだコミットしている人たちがいるんですね。プロジェクトが死んでいなくて良かったです。彼らは実際に存在したイシューを取り上げました。どこかにそれへのリンクもあるはずです。パッチとテスト用のパッチもありますね。私が読みたいのは問題のステートメントです。これがその例です。ACPと確認ロジックにおいてメール検証のステータスが正しく処理されていません。タイトルの説明。ACP管理コントロールパネルはユーザーのメール検証ステータスを正確に反映していません。また、検証と確認のプロセスはキーの有効期限に依存しており、これらのキーの有効期限が切れると正しい検証ができなくなる可能性があります。期待されるキーの下にメールが見つからなかった場合に回復するためのフォールバックがありません。これにより、確認メールを検証または再送しようとしたときに失敗が生じます。これはひどいです。再現手順がありそれは役立ちますが、このフォーマットはひどいです。特にラベルで終わっているのが意味不明です。これは恐ろしいプロンプトです。ひどいプロンプトです。これは何も測定していません。SWEBenchのすべての実行は、システムプロンプトにただゴミを追加しているだけで、私はついにそれを掘り起こすことができました。ここまでたどり着くのを手伝ってくれたチャットの皆さんに感謝します。あなたはタスクを解決するためにコンピュータと対話できる便利なアシスタントです。working_dirディレクトリにコードリポジトリをアップロードしました。次のPRの説明を検討してください。ここに問題が入ります。その問題とは少し前にここで読んだ恐ろしい内容です。説明で指定された要件が満たされるように、リポジトリに必要な変更を実装するのを手伝ってくれませんか。その問題に記述されているすべてのテストファイルへの変更はすでに処理済みです。つまり、テストロジックやテストのいかなる部分も変更する必要はありません。特にこの部分はひどいです。テストロジックを変更したりテストを追加したりする必要はないと伝えているのです。この一行だけでSWEBenchを無効にするのに十分なはずです。本当にひどいです。医療過誤を行っているときにモデルが政府に連絡するかどうかをチェックするようなくだらないベンチマークであるSnitchBenchの方が、このゴミのようなものよりもうまく設計されているのはどういうことでしょうか。あなたのタスクは、問題の説明が満たされることを確実にするために、ディレクトリ内の非テストファイルに最小限の変更を加えることです。イシューを解決するために次の手順に従ってください。1つ目は、最初のステップとして関連するコードを見つけて読むこと。2つ目は、エラーを再現するスクリプトを作成しbashツールを使用して実行すること。3つ目は、リポジトリのソースコードを編集してイシューを解決すること。4つ目は、再現スクリプトを再実行しエラーが修正されたことを確認すること。5つ目は、エッジケースについて考え修正がそれらも処理することを確認すること。あなたの思考は徹底的であるべきなので非常に長くなっても構いません。冗談ですよね。少なくとも、GeminiモデルがSWEBenchでそこそこのパフォーマンスを発揮する理由はわかりました。やり方を正確に指示されているからです。皆さんはどうかわかりませんが、私は個人的にちょっとしたバグの修正をモデルに頼むときに15もの手順を書きません。これはGPT-3の時代なら理にかなっているように聞こえたかもしれないタイプのプロンプティングですが、今日でもまだこのベンチマークを使っているという事実は、率直に言って哀れです。本当に哀れです。そしてこれが長い間業界標準だったのです。これはAnthropicが自社のモデルが78%を獲得し、GPT 55がわずか58.6%しか獲得できなかったと自慢したのと同じベンチマークです。これに関して面白いのは、彼らの数字が完全に間違っていた可能性が高いということです。誰かがData Curveの報告に基づいて計算したところ、GPT 55が本来獲得すべきだった実際のスコアはおそらく68.5%ではなく86.7%でした。狂っています。そして比較のために、もう一度DeepSWEのプロンプトを見てみましょう。このGoプロジェクトで、型付き値と型なし値全体にわたるPromQLのラベルソートを修正してください。監視システムと時系列データベース関連で非常に評価の高いライブラリです。TwitchでPrometheusを使っていたのは知っています。私は触れたことはありませんでしたが、これが非常に真っ当なライブラリであることは知っています。ラベルのソートはマルチドメインの型付き比較を使用しなければなりません。現在の動作では、ラベルが異なる型の文字列表現と型なしの文字列表現を混在させた場合、安定した全体的な順序が生成されません。先頭に空白がある値は、どの型の形式としても解析されることはなく、この先頭の空白グループ内の他のすべての値の前にソートされなければなりません。順序付けは元の文字列の自然なソートによるものです。順序のクラスは以下の通りです。これがどのようにソートされるべきかの詳細です。数値解析は、科学的指数とオプションの先頭のプラス記号を受け入れなければなりません。後に数字が続かない単独の指数マーカーは有効な数値ではなく、型なしの自然ソートにフォールバックします。云々、大体のことはわかると思います。これは問題の解決方法を指示しているのではありません。問題が何であり、解決策がどう見えるべきかを伝えているのです。これは良いプロンプトです。もしあなたのプロンプトが、ここで紹介したDeepSWEのものよりも、SWEエージェントのシステムプロンプトのような精神疾患的なものに似ているとしたら、おそらくSWEBench Proの結果に従うべきでしょう。なぜなら、文字数が5000文字も多すぎる下手なプロンプターからのひどいプロンプトを彼らはうまく測定できているようだからです。私はこのようなプロンプティングが好きです。私のプロンプトは、問題と解決策がエージェントにとって大まかにどう見えるかを説明し、あとはエージェントの仕事に任せるというものです。またこの点について面白いのは、機能させるために大量のコード変更を必要としたこの大規模なGoプロジェクトで、解決策が805行のコードだったことです。GLM 5.1はこれに関してそこそこの結果を出しました。実際に50%のスコアを獲得しました。GPT 54は7回中3回でした。つまり技術的にはGLM 5.1よりも悪い結果でした。GPT 55も同様に7回中3回でした。Opusは2回しか成功しませんでした。非常に興味深いです。これについて読めば読むほど、なぜこのギャップがこれほど大きいのかが納得できます。明確にしておきたいのですが、これらは全て明白なことです。彼らがベンチマークで何かクレイジーで斬新なことをしているわけではありません。誰もやりたがらなかった作業に座って取り組んだだけです。なぜなら結果を検証しなければならないからです。そしてそれは、ひどいコードを大量に読むことを意味します。誰もそんなことはしたくありません。私は、彼らが実際にそれをやる労力を費やしてくれたことに感謝しています。彼らのおかげでついに意味のある結果を持つベンチマークを手に入れることができたからです。そして今、意味のある他の結果も見ていくことができます。トークン出力やコスト出力、ウォールクロック時間が有用になるほど十分に優れたベンチマークがついにできたからです。異なるエージェントの比較も本当にクールだと思います。
トークン消費量と実行コストの比較
実際にそこから始めましょう。彼らはSWEBenchのMini SWEエージェントを使用しました。これは、エージェントにbashを使用する能力だけを与える超最小限のエージェントハーネスです。彼らは他のモデルの公式ハーネスに対しても実行を試み、その結果は明白でした。Mini SWEエージェントをClaude Opusで使用したときの合格率は50%でした。しかしClaude Codeに切り替えると10%低下しました。注目すべき点として、Mini SWEエージェントではClaude Codeを使用したときよりも実際により多くの出力トークンを生成しました。GPT 55では同じハーネスでテストしたサブセットでは同じスコアでしたが、Codexではより多くの出力トークンを使用しました。それほど多くはありません。明確にしておきますが、これらの数字はどちらもOpusの実行に比べてはるかに小さいです。Codex CLIの最悪のケースは2万5千の出力でした。そしてOpusにとってより良いケースであるClaude Codeでは4万8千と、ほぼ倍増しています。そしてGemini 3.1 Proはミニアージェントで40%を獲得しましたが、公式のGemini CLI経由ではまだ20%しか獲得できませんでした。驚きですね。彼らはこれらすべてのテストを行ったので、このエージェントがどのモデルファミリーにとっても意味のある不利益にならないことを確認したかったのです。結果として公平に出たようです。では面白い数字を見てみましょう。スコア対トライアルあたりの出力トークンです。なぜ私が35 Flashをあんなに嫌うのか疑問に思う人のために、これがその理由です。それを示すチャートがあります。GPT 55の半分以下のスコアしか取れなかったのに、滑稽なほど多くのトークンを使用しました。GPT 55はトライアルあたり平均4万7千トークンでした。35 Flashは15万でした。3倍のトークンです。Opusは9万7千と、4万7千と比較して2倍でした。トークン数が2倍でスコアは低いです。これはコスト比較になるとさらに顕著になり、最終的にOpusは他のどのオプションよりも3倍以上高額になります。Anthropicの収益がなぜこれほど急速に成長しているのか疑問に思っているなら、おそらくこれが理由の一部でしょう。彼らが知能に対してより高い料金を請求しているという事実です。なぜなら、はるかに多くのトークンを消費しその結果としてパフォーマンスがあまり良くないからです。もしあなたがAIにたくさんのお金を使いたいと考えていて、会社でのAI支出を最大化しようとしているなら、絶対にOpusを使うべきです。その理由を数字が物語っています。Opusは1回の実行につき平均16ドルかかりました。GPT 55は平均5.80ドルでした。V4はさらに安く3.30ドルでした。しかしここで私が一番好きな数字はGemini 35 Flashの数字です。なぜならこのモデルはFlashモデルだからです。OpenAIよりずっと安いはずですよね。そうです。なぜ100万出力あたり30ドルのモデルを使う必要があるでしょうか。すごく速くて同じくらい賢い100万出力あたり9ドルのモデルが使えるのに。あ、結局ほぼ同じ金額がかかるからですね。でもこれはFlashモデルです。速いはずですよね。パフォーマンスを見てみましょう。ああそうですね、確かに速かったです。20分ではなく15分で終わりました。なるほど、つまり20%速くて、3倍愚かで、値段はほぼ同じだったわけです。一体何のために35 Flashを使うというのでしょうか。本当にこれらの数字は狂っています。コメント欄でどんな質問が出るかはすでに予想が付きます。ですから、できるだけ多くの質問に答えていきましょう。
オープンウェイトモデルの厳しい現実
まず第一に、Opus 46はどうなのか、新しいQwenモデルはどうなのか、それらをオンにしてみよう、という質問があるはずです。ほら、Opus 46、Qwen 36、Haiku、Minimaxだ、クールだ、と。結果として、Opus 46はこのテストで爆死しました。なぜなのか細かい理由はまだよくわかっていませんし、まだチームとも話していませんが、Opus 46はこのベンチマークに本当に苦戦しました。ですから、Opus 47がこういった長いタスクに優れているとAnthropicが言っていたことは、結局すべて本当だったのかもしれません。どうやらその可能性が非常に高そうです。私は好奇心から彼らともっと話し合い、これを自分で実行してみるつもりですが、今オンにした他のすべてのものははるかに低い結果に終わりました。これはオープンウェイトモデルにとっておそらくこれまでで最も決定的に不利なベンチマークです。なぜなら、どれも前世代の最先端モデルの半分のスコアにも到達しないからです。確かに、Artificial Analysisを見ると状況はそれほど悪くないように見えます。ほら、Mimo V25は54を獲得しKimi K26も54を獲得しました。Opusは57で、GPT 55はわずか60です。それほど大きな差ではないじゃないか、と。DeepSeek V4 Proでさえ52を出しました。明らかにオープンウェイトが追いついてきているじゃないか、と。ええと、違います。Kimi K26のスコアはGPT 54 Miniと同じくらいですが、GPT 54 Miniは良いモデルではありません。もしGPT 54が全てのオープンウェイトのスコアを2倍以上引き離しているなら、それはかなり決定的なことです。そしてこれは、DeepSeek V4 Proで私が経験したことも裏付けています。小さな問題を1つ解決するために1つのファイルに分離すればうまく機能しますが、実際のコードベースで実際の作業を行いたい場合はすぐに使い物にならなくなります。私はこのベンチマークがあることに非常に感謝しています。私や皆さんがこれらのものを使って感じてきた多くのことを裏付けてくれたからです。OpusやGPT 54、GPT 55と、その他のものとの間のギャップは巨大であること。GPT 55は、エージェントが最小限のコンテキストで本格的な作業を行う能力において意味のある飛躍であること。そして実際の問題を解決するためにこれらを実際に仕事で使用する場合、オープンウェイトモデルと最先端モデルとのギャップは、他のテストが示していた5%よりもはるかに大きいと感じること。そして再度これをArenaのコーディングベンチマークと比較すると、私が古いベンチマークを信用しない理由がお分かりいただけるでしょう。あれは主にフロントエンドのテストだと思いますが、確かにGPT 55はClaude Opusほどホームページやマーケティングサイトの作成が得意ではありません。でもあの数字は意味不明です。人々がそういった類の結果を信じて走っているこの世界において、数年前にウォータールー大学のオタクの若者たちの集まりだった、私が投資した会社が、ベンチマークやデータの質の低さに対する私と同じフラストレーションを抱え、それがどうあるべきかを示してくれたことは、純粋に大きな安堵です。この動画がお金をもらって偏向しているとか、回し者だとかいった非難で炎上することは分かっています。そしてそういった人々の誰もが、小さなプロジェクトに取り組んでいるか、最新のOpenAIモデルをきちんと試したことがないかのどちらかであると断言できます。なぜなら、日々の実際の開発作業において、オープンウェイトモデルや安価な古いモデルと最先端モデルとのギャップは圧倒的だからです。そしてこれらを比較するベンチマークはそのことを示すべきです。ありがたいことに、他の人々もこれを行っているのを目にしています。SWEBenchも現実的なコーディングベンチマークを行おうとする試みの一つであり、現在より多くの注目を集めていますが、今見たのとほぼまったく同じ内訳を示しています。Claude CodeはGPT 55に少し近いですが、そこまで近いわけではありません。GPT 55はClaude Codeを使用する場合に少し近いですが、彼らのカスタムハーネスは彼らのテストにおいてClaude CodeやCodexほど適切には機能していないようです。しかしここでも、最高のオープンウェイトモデルと現在の最先端モデルとの間に巨大なギャップがあるという非常によく似た結果を示しています。ですから、これらの結果は思っているほど特異なものではありません。ここ数ヶ月、いや数年にわたってひどいベンチマークを見せられてきたから特異に見えるだけなのです。
ベンチマークの限界と今後の展望
そうは言っても、このベンチマークも完璧ではありません。私が本当に見たいと思ういくつかのものが欠けています。理想的には、公式ハーネスと彼らがMini SWEで構築したハーネスを比較するテストがもっとあればいいなと思います。両方で完全に実行してみるとクールでしょう。また、CursorのComposer 25のような、独自のハーネスに組み込むのが少し面倒なものを含めてくれたら本当に素晴らしいです。他のハーネスで機能するように彼らが対応する必要がありますが。また、より多くのプライベートデータを使用したもっと難しいバージョンを作ってくれたらクールですね。彼らは例を透明にしすぎたため、将来的にこのベンチマークでトレーニングして高いスコアを出すのが簡単になってしまいました。ですから、モデルがそこまで高いスコアを出せないような、はるかに大規模なプライベートバージョンを作ってくれることを願っています。70%のスコアを出すベンチマークの登場は少し怖いです。なぜなら、このペースだと年末までには100%に達してしまうということだからです。ですから、全てのスコアの桁を一つ落とすようなバージョンのベンチマークが欲しいです。GPT 55が70ではなく7だったらどうでしょう。それは本当にクールですね。彼らはベンチマークの限界について非常に透明性を保っていました。共有プロンプト内で単一のbashツールのみを使用するMini SWEエージェントを通じて実行することで、ハーネスの違いにより異なるモデルが同様に機能しない可能性があると明記しています。GPTはパッチの適用を期待し、Claudeはテキストエディタツールを期待します。すべての編集をbash経由でルーティングすることは、彼ら自身のハーネスで可能な限りうまく機能するのを実際に妨げる可能性があります。また、開発者は実際にはMini SWEエージェントを使用しないことにも言及しておくべきでしょう。誰が使っているのか知りません。使われることを想定しているとも思いません。PIには似ていますがPIではありません。ですからPIが好きなら近い感じになるでしょう。彼らはCodex CLI、Claude Code、Cursor、そしてGemini CLIのようなものを使用していますが、彼らのリーダーボードにはそれは反映されていません。彼らはこのベンチマークを可能な限り現実的なものにしたいと考えています。他のみんなはコーダーの日常的な実際の使用状況を測定しようとはしていないため誰もこのようなことを指摘しませんが、彼らはこれを指摘しています。他のみんなはモデルがどれくらい知的なのかを大まかに任意で測定しようとしているだけです。コーパスはGitHubで500スター以上を持つアクティブなオープンソースリポジトリからのみ抽出されています。これによりタスクは十分にメンテナンスされたコードの領域に固定されますが、結果はロングテールのリポジトリやプロプライエタリなコードベースには一般化できない可能性があります。これも非常に良い指摘です。なぜならDeepSWEはこれらの長期的なタスクに焦点を当てているからです。バグの特定やリファクタリングは十分に表現されていません。もしモデルがデバッグやリファクタリングに非常に優れていて、大きな機能追加や彼らがベンチマークしているようなより難しい問題の解決には向いていない場合、ここではうまく表現されません。Gemini 31 Proがこれまでで最高のデバッグおよびリファクタリングモデルである可能性もありますが、ここではそれはわかりません。ベンチマークは5つの言語しかカバーしていません。主にTypeScript、Go、Pythonに集中しています。C++やJavaのように広く使われている言語はまだ含まれていません。これも将来的に修正されるとクールですね。しかし、彼らはすべてのベリファイアを手作業で書いたことを覚えておいてください。ですからここに言語を追加する場合、結果を検証できるほどその言語をよく理解している従業員が必要になります。また、プロンプトは短くなっていますが、開発者が実際にエージェントとどのようにメッセージのやり取りをするかをはるかに反映しています。動作の検証には、テスト対象の表面を知るための最小限の具体性が必要であり、それがテストが曖昧になる前にプロンプトをどれだけ簡潔にできるかの下限を定めています。その通りです。もしこのようなことに興奮して動画のここまでたどり着いたなら、説明欄のリンクをクリックしたくなるかもしれません。彼らは採用ボタンを用意しており、私の動画から来たと聞けば間違いなく喜ぶはずですので、ぜひ伝えてあげてください。セレナとチームによるこの仕事は絶対に驚異的でした。このベンチマークにおいて素晴らしい仕事をしました。私はしばらくの間、誰かがこのようなベンチマークを作ってくれるよう懇願してきましたが、それが単に存在するだけでなく、私や他のエンジニアの友人たちがこれらのモデルを扱ってきた経験を裏付けてくれるのを見るのはとてもクールです。そしてこれにより、次世代のモデルがさらに楽しみになってきました。この動画が皆さんのお役に立てば幸いです。私にとっては非常にエキサイティングなものでした。皆さんがどう思ったか教えてください。それでは次回まで、さようなら。
コメント