Claude Opus 4.8とSWE-bench Pro: Anthropic社の見出しを私たちのGatewayで検証しました

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Anthropicが Claude Opus 4.8をリリースした 2026年5月28日、その際の主要な数値はコーディング能力で、 SWE-bench Proで69.2%でした。これは以前の 64.3% (Opus 4.7)から向上したもので、 4.9ポイントの 改善となり、業界で最も難しいソフトウェアエンジニアリングベンチマークの1つにおける成果です。
私たちは、ほとんどのチームが実際にモデルを呼び出す方法、つまり本番環境のゲートウェイ、単一のAPI、実際のレイテンシ、実際のトークン課金を通じて呼び出した場合に、そのアップグレードが実際に現れるかどうかを知りたかったのです。そこで、公開されているSWE-bench Proテストセットから50の難しいコーディング問題をTrueFoundry AI Gatewayを介して実行しました。
Opus 4.8は、すべての問題に対して使用可能なコードパッチを返しました。一方、Opus 4.7は3つの問題で失敗しました。この傾向はAnthropicの主張と一致していました。 しかし、私たちの絶対スコアはそうではありませんでした。そして、そのギャップこそが重要な点なのです。
誰もが引用する数字
主要なモデルがリリースされるたびに、ベンチマークスコアの表が公開されます。Opus 4.8の場合、最も注目された項目はSWE-bench Proでした。
SWE-bench Proは、AIのコーディング能力を測るストレステストです。問題は実際のオープンソースプロジェクトから抽出されており、保守されているコードベース、複数のファイルにまたがるバグなど、シニアエンジニアが午後いっぱいかけて解決するような種類の作業が含まれます。Anthropicが発表した結果は、完全なエージェント設定で測定されました。モデルはリポジトリを閲覧し、コマンドを実行し、修正を試み、反復することができました。これは、モデルが最高の状態で何ができるかを測定する正しい方法です。
しかし、これは、アプリケーションがAPIを通じて単一のリクエストを送信し、応答を待つ際に起こる状況とは異なります。
この違いは重要です。プラットフォームチームは、Anthropicの評価ハーネスの内部で作業しているわけではありません。彼らはゲートウェイの背後で作業しており、そこには単一のエンドポイント、ルーティングルール、レート制限、そして月末の請求書があります。ベンダーが「4.9ポイント向上」と言うとき、実用的な問いはより限定的で、より直接的です。 私たちがすでに使用しているインフラストラクチャ上で、新しいモデルは、難しいコーディング作業において、依然として古いモデルを上回るのか?
このチェックを実施しました
私たちはルーティングしました Claude Opus 4.8 および Claude Opus 4.7 を介して TrueFoundry AI Gateway — これは、お客様が最先端モデルにアクセスするために使用する、OpenAI互換のAPIサーフェスと同じものです。ゲートウェイの背後では、2つのモデルは異なるプロバイダー経路にルーティングされました。アプリケーションの観点からは、統合は同一でした。同じURL、同じ認証情報、異なるモデル名です。
主要なテストとして、私たちは 50問の問題を 公開されているSWE-bench Proテストセット(合計731件の課題)から取得しました。各問題は、実際のレポジトリにおける実際のバグを記述しています。私たちはその記述をモデルに一度だけ送信し、 unified diff — コードパッチの標準形式です。ブラウジングなし。ターミナルアクセスなし。再修正の機会はありませんでした。
その後、私たちは各応答をシンプルなルールで採点しました。 これは有効なパッチと見なせるか? Dockerコンテナを起動したり、プロジェクトのテストスイートを実行したりはしませんでした。また、別のモデルに判定役を依頼することもありませんでした。
これはAnthropicのテストよりも簡易的なものですが、異なる問いに答えるものです。Opus 4.8がゲートウェイに到達した際、Opus 4.7よりも難しい問題に対して信頼できるコーディング出力をより頻繁に生成するかどうか、という問いです。
SWE-bench Proでの調査結果
50問のサンプルにおいて、 Opus 4.8は毎回パッチ形式の回答を返しました — 50問すべてで. Opus 4.7は3つを外し、50点中47点という結果でした。パーセンテージで言えば、我々のスライスでは6ポイントの差があり、Anthropicの公式ベンチマーク全体での4.9ポイントの差よりも大きくなっています。
我々が重視したのは順序です。Anthropicは新しいモデルがこの作業において優れていると述べていましたが、我々のゲートウェイ実行では、 新しいモデルもこの作業において優れていました。
絶対的な数値は別の話であり、安易に比較すべきではありません。Anthropicの 69.2% は、探索・テスト可能なエージェントを用いて、モデルが10問中およそ7問を解決したことを意味します。我々の 100%と94% は、モデルが一度の試行でパッチのようなものを返したことを意味します。我々が設定した基準ははるかに低いです。我々のスコアをAnthropicのスコアを「上回った」と解釈するのは誤解を招きます。この 方向性— 4.7よりも4.8が優れているという — を健全性チェックとして捉えるのは妥当です。
この実行には実用的な側面もありました。Anthropicが発表したローンチ時の価格設定(入力トークン100万あたり5ドル、出力トークン100万あたり25ドル)では、SWE-benchのスライスはOpus 4.8で約1.45ドル、Opus 4.7で約1.66ドルかかりました。長い問題記述に対する応答は、4.8で中央値約12秒、4.7で13秒でした。最も遅い20%のリクエストはそれぞれ27秒と37秒に達しました。一度限りの検証スプリントであれば、これは管理可能です。しかし、タスクごとに何十回もループするエージェントの場合、すぐにコストがかさみます。
ローンチ表の残りを読む
Anthropicの発表はSWE-bench Proに留まりませんでした。同じ投稿では、ターミナルタスク、デスクトップ自動化、大学院レベルの科学Q&A、金融ワークフローなどでの改善が挙げられていました。我々もそれらの公式ハーネスを再実行したわけではありません。各カテゴリを少数の代表的なプロンプトにマッピングし、両モデルをGatewayで実行しました。
コーディングで見たパターンが繰り返されました。Pythonのバグ修正、bashの質問への回答、適切なUIアクションの選択といった短いプロキシタスクでは、両モデルともしばしば最高点を記録しました。これは、モデルがカテゴリに合わせた作業に対して到達可能で応答性が高いことを示しています。
他よりも示唆に富む2つの結果がありました。
On SWE-bench Verified プロキシ(Proよりも単純なコーディング修正)では、Opus 4.8は両方のプロンプトに正しく回答しましたが、Opus 4.7は2つのうち1つにしか回答しませんでした。これはAnthropicの公式発表である88.6%対87.6%よりも大きな差ですが、ごく小さなサンプルでの結果です。
について 金融エージェント プロキシでは、両モデルともゼロ点でした。これは、Opusが金融業務をこなせないという証明ではなく、ミニチュアの代役に対する厳密な回答一致という、ほぼ間違いなく採点上の限界によるものです。軽量なプロキシは静かに失敗するということを改めて認識させられます。私たちが信頼する唯一のスイートは モデルの順序付け 50問のSWE-bench Proです。
残りのカテゴリ、つまり推論試験、知識労働数学、科学の多肢選択式問題については、両モデルとも我々の小規模なプロキシセットをクリアしました。Anthropicの公式表には、我々が捉えきれなかったニュアンスがまだ示されています(例えば、GPQA Diamondはわずかに4.7を支持しています)。我々のプロキシは、それを表面化させるには浅すぎました。
なぜこの方法で実行したのか
私たちはAnthropicの評価を置き換えようとしているわけではありません。彼らの数値は、ツール、時間、そして彼らのハーネスを与えたときにOpus 4.8が何ができるかを示しています。私たちの実行は、ゲートウェイ移行の初日、つまりエンジニアリングチームがエージェントの再トレーニングやプロンプトの再調整を行う前に、トラフィックを4.8にルーティングする価値があるかどうかを知りたいときに何が起こるかを示しています。
スコアボード以外に、3つの点が際立っていました。
• アップグレードの構想は、本番ルーティングとの連携に耐え抜きました。 異なるプロバイダーパス、単一のクライアント統合、アプリケーションの再設計なしで両モデルを呼び出し可能。これこそがGatewayが目指す統合の姿です。
• 正直な採点は、見栄えの良い採点に勝る。 ヒューリスティックな「パッチのように見えるか」というチェックは批判されやすいものであり、私たち自身も批判しています。しかし、それは安価で再現性があり、友好的な評価モデルで不正を働くのが難しいという利点もあります。ローンチ後の方向性を把握するためには、このトレードオフは理にかなっていました。
• ベンダーのベンチマークとゲートウェイの現実は、異なる層を測るものです。 Anthropicの69.2%は上限です。私たちの50問のサンプルは下限の確認です。新しい主力モデルが、あなたのサービスが呼び出す方法で呼び出されたときに、実際に困難なコーディング出力で進歩したのかどうか、という点です。
そこから得られるもの
AnthropicのSWE-bench Proの差分は、Opus 4.8が意味のあるコーディングアップグレードであるという最も強力な公開証拠であり続けています。私たちはその数値を再証明したわけではありません。私たちは 順序が確認されました —4.7を4.8が上回る形で—本番サービスがフロンティアモデルを呼び出すのと同様に、コストとレイテンシーを考慮したゲートウェイパス上で。
私たちのパーセンテージはAnthropic社のものとは比較できず、そのように提示することもありません。私たちのテスト結果から読み取れる重要な点はもっとシンプルです。つまり、私たちのスタック上でも、主要な改善点が同じ方向性を示しているということです。
リリース時期の読み方についても学びました。Anthropic社の69.2%は、ツール、時間、完全な評価ハーネスを備えたモデルを表しており、これは「天井」です。一方、私たちの50問のサンプルは、単一のAPI呼び出しと単純なパッチ形状チェックを表しており、これは「床」です。どちらも正当なものであり、異なる質問に答えています。私たちの質問はこうでした。「Opus 4.8がGatewayに導入された際、ハードコーディングの出力において4.7を明らかに上回るか?」このサンプルでは、答えは「はい」でした。
その質問を検証するために私たちが利用したレイヤーがTrueFoundry AI Gatewayです。これはOpenAI互換の単一APIで、 1000以上のモデルプロバイダーのルーティングは舞台裏で処理されます。同じクライアント、異なるモデル名で、すでに運用しているインフラストラクチャ上で測定可能な違いが見られました。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI
















.webp)




.png)







.webp)
.webp)



.webp)





