IBMとKaggle、ScarfBenchの継続更新型移行リーダーボードで提携

2026年10月27日公開のIBM Researchの技術ノートによると、IBMとKaggleは、エンタープライズJavaフレームワークの移行におけるコーディングエージェントの評価を目的とするIBMのオープンベンチマーク、ScarfBenchの公開リーダーボードを継続的に更新するため、提携している。

ScarfBenchは「Self-Contained Application Refactoring Benchmark（自己完結型アプリケーション・リファクタリング・ベンチマーク）」の略称で、エージェントが未知のエンタープライズJavaアプリケーションをJakarta EE、Quarkus、Springの各フレームワーク間で移行し、移行後も動作するソフトウェアを残せるかを検証する。ベンチマークでは、特定の作業に焦点を当てたワークロードとアプリケーション全体の両方を用いて、生成されたアプリケーションがビルドおよび起動し、想定どおりに動作し続けるかを確認する。IBMは2026年初め、AIを活用した移行のための再現可能なベンチマークとしてScarfBenchを発表した。2026年3月11日付の当初の発表では、3つのフレームワークに対応し開発者が検証したエンタープライズアプリケーション、永続化の挙動や依存性注入などの個別の観点を切り分ける特化型ワークロード、複数のアーキテクチャ層を組み合わせたアプリケーション全体、自動ビルド・起動検証、実行時の挙動と機能的同等性を確認する動作テストなど、7つの構成要素が説明された。同発表によると、各ワークロードは、機能的同等性とフレームワークに即した慣用的な使い方を確かめるため、経験豊富な開発者が手作業で実装し、検証した。

IBMとKaggleの提携

この提携のもと、Kaggleはベンチマークと評価の設計についてIBMに助言し、計算資源を提供したうえで、自社プラットフォーム上でScarfBenchを独自に再現して実行した。また、今後も長期にわたりベンチマークを維持する。IBMは、両チームの強みは相互補完的だと説明している。IBMはエンタープライズJavaのモダナイゼーションを念頭にScarfBenchを開発し、Kaggleは独立した評価基盤と継続的なリーダーボードの運用管理を担う。

204件の移行タスクでの結果

ScarfBenchが評価するのは、単独の言語モデルではなくエージェントシステムだ。各結果は、モデルとコーディングエージェントのハーネスを組み合わせた構成を反映しており、ハーネスによって、モデルがリポジトリや開発環境とどのようにやり取りするかが決まる。IBMは、スコアは基盤となるモデル単体の性能測定値ではなく、モデルとハーネスの組み合わせによる結果として解釈すべきだと注意を促した。

204件の移行タスクと、評価対象となった10種類のモデル／ハーネス構成では、主要なスモークテスト指標でAntigravityハーネスと組み合わせたGemini 4 Argonが75.2%で首位になったと、IBMは報告した。続いて、Claude Opus 5.5とClaude Codeの組み合わせが70.5%、Claude Opus 5とClaude Codeの組み合わせが69.8%だった。リーダーボードの指標となるスモークスコアは、部分点を認め、テストスイートの規模が大きいほど重みを高くする。より厳格な全テスト合格率では、Claude Opus 5.5とClaude Codeの組み合わせが72.1%で最高となり、Gemini 4 ArgonとAntigravityの71.1%を僅差で上回った。

投稿によると、感度分析でも上位の順位は変わらなかった。204件のうち4件のタスクは、どの構成でも動作テストの得点がゼロだった。これらを除外すると絶対スコアは上昇したものの、上位の顔ぶれに変化はなく、Gemini 4 ArgonとAntigravityの組み合わせが79.4%、Claude Opus 5.5とClaude Codeの組み合わせが74.5%、Claude Opus 5とClaude Codeの組み合わせが73.7%だった。IBMによると、最も優れた組み合わせでも改善の余地は大きく、移行の全テストに完全合格した構成はなく、合格率はおよそ4分の3を超えなかった。

構成ごとの成功と失敗

IBMの報告によると、評価で最も大きな隔たりが見られたのは、ビルドできるコードと正しく動作するソフトウェアの間だった。全タスクで得点がゼロだった4件を除外すると、Claude Opus 5とClaude Code、Gemini 4 ArgonとAntigravity、Gemini 3.8 Flashとmini-sweの各構成は、タスクの100%をコンパイルできた。また、10構成中8構成は少なくとも97%をコンパイルした。一方、スモークテストのスコアには50ポイントを超える幅があった。正常にデプロイできたアプリケーションに限ると、上位構成の全テスト合格率はおよそ63%から76%に集中した一方、Kimi K3とkimi-codeの組み合わせは53%、Gemini 3.1 ProとOpenHandsの組み合わせは42%、Gemma 4 26B-A4Bとmini-sweの組み合わせは26%にとどまった。

IBMが分類した失敗実行は745件だった。このうち535件、約72%は実行時の動作不良で、アプリケーションはビルドでき、多くの場合起動もしたものの、動作検証に失敗した。このグループには、コンテンツやアサーションの不一致が304件、ルート消失または404エラーが210件、明示的なHTTP 500または405エラーが21件含まれていた。失敗実行の約20%に当たる152件はコンパイルまたはパッケージングの失敗で、約8%に当たる58件は起動時または依存性注入時のクラッシュだった。

投稿では、タスク単位の事例も紹介されている。concurrency-taskcreator-quarkus-to-jakartaでは、Claude Opus 5とClaude Codeの組み合わせは、/taskinfoエンドポイントが「File not found」を返し、HTTP 405を想定したテストにも失敗したため、0/6点だった。address-book-jakarta-to-quarkusでは、GPT-6 AstraとCodexの組み合わせは、一覧ページと作成ページがHTTP 404を返し、2/10点だった。cargotracker-jakarta-to-springでは、Gemini 3.8 Flashとmini-sweの組み合わせは、Spring Bootへの移行後もJSF/JoinFacesの設定を残したため、起動時にfacesContext Beanの作成で失敗した。cart-spring-to-jakartaでは、移行後に残されたパッケージング形式が対象のLibertyランタイムでサポートされておらず、GPT-6 AstraとCodexの組み合わせはデプロイに失敗した。

IBMによると、構成によって効率にも差があった。感度分析による除外後に残った200件のタスクでは、ターン数の中央値は、Claude Codeを使用したClaude Opus 5の32ターンから、mini-sweを使用したGemini 3.8 Flashの79ターンまで幅があり、Claude Codeを使用したClaude Opus 5.5は64ターンだった。Claude Code、Codex、mini-swe、kimi-codeの各構成ではハーネスがコストを報告しており、タスク解決あたりのコストは、Codexを使用したGPT-6.1 Solの1.25ドルから、Claude Codeを使用したClaude Opus 5.5の10.10ドルまでだった。一方、Antigravity、qwen-code、OpenHandsのハーネスは、実行ごとのコストを出力しなかった。

ScarfBenchのリーダーボードでは、これらの結果を一般公開している。公開時点ではモデルの一般投稿は利用できないが、IBMによると、これはロードマップに含まれている。