ScarfBench：エンタープライズJavaフレームワーク移行のためのAIエージェントベンチマーク
IBM Researchは、エンタープライズJavaにおけるクロスフレームワーク移行タスクのAIエージェントを評価するためのオープンベンチマークScarfBenchを発表しました。ベンチマークには34のアプリケーション、102のフレームワーク実装、204の移行タスクが含まれています。現在のトップエージェントの行動成功率は10%未満であり、移行中の振る舞い保持の難しさが浮き彫りになっています。
エンタープライズアプリケーションのモダナイゼーションは、組織が行う最大かつ最も高コストなソフトウェアエンジニアリング活動の1つです。チームは、保守性、クラウド対応、開発者生産性、最新機能へのアクセスを向上させるために、フレームワーク間でアプリケーションを移行します。近年のコーディングエージェントの進歩により、AI支援によるモダナイゼーションへの期待が高まっていますが、重要な疑問が残っています：AIエージェントは現実のエンタープライズアプリケーションを確実にモダナイズできるのでしょうか？
既存のソフトウェアエンジニアリングベンチマークは、バグ修正やコード生成で目覚ましい進歩を示していますが、フレームワーク移行は根本的に異なる課題を提示します。成功には、コードの変換だけでなく、振る舞いの維持、ビルドシステムの適応、ランタイム依存関係の処理が必要です。このギャップを埋めるため、IBM ResearchはScarfBench（Self-Contained Application Refactoring Benchmark）を導入します。これは、エンタープライズJavaにおけるクロスフレームワーク移行タスクでAIエージェントを評価するためのオープンベンチマークです。
ScarfBenchは、Spring、Jakarta EE、Quarkusの3つの主要なJavaエコシステム間の移行に焦点を当てています。従来のベンチマークとは異なり、ScarfBenchは生成されたコードを参照実装と比較するのではなく、移行されたアプリケーションが実際にビルド、デプロイ、振る舞いを維持するかどうかを評価します。
フレームワーク移行は、アノテーションの置き換えだけではありません。単純なリポジトリ移行でも、依存性注入、永続化設定、クエリ、フレームワーク記述子の変更が必要になる場合があります。これらの要素の小さなミスが、デプロイの失敗につながる可能性があります。ScarfBenchは体系的な評価方法を提供します。アプリケーションは、正常にビルドされ、正しくデプロイされ、振る舞い検証に合格する必要があります。これにより、モダナイゼーションの品質をより現実的に測定できます。
ベンチマーク概要：34のアプリケーション、102のフレームワーク実装、204の移行タスク、約15万1千行のコード、約2,000のソースファイルとテストファイル、1,331の専門家作成テスト。ScarfBenchには、焦点を絞った移行タスクとアプリケーション全体の移行の両方が含まれています。
最先端のコーディングエージェントを評価したところ、従来のソフトウェアエンジニアリングベンチマークでは強力なパフォーマンスを示すものの、フレームワーク移行は依然として困難です。成功率はフレームワークペアによって大きく異なり、アプリケーション全体の移行は特に困難です。現在の最強エージェントでも、行動成功率は10%未満であり、コンパイル可能なコードの生成とアプリケーションの振る舞い維持との間のギャップを示しています。コンパイル成功率は常にデプロイ成功率を上回り、デプロイ成功率は行動成功率を上回ります。ビルド成功だけでは移行品質を大幅に過大評価します。移行の難易度はターゲットフレームワークに強く依存し、Jakarta EEは特に困難です。
成功率の測定に加えて、ScarfBenchはエージェントがモダナイゼーション中にどのように振る舞うかを理解するのに役立ちます。エージェントは移行完了を確実に判断できるでしょうか？移行されたアプリケーションは、実際にビルドされて実行されて初めて有用です。そこで、エージェントが報告した結果と独立したビルド検証を比較しました。結果：エージェントは過信しています。Claude Codeは30の全アプリケーション中29でビルド成功を報告しましたが、実際に成功したのは22のみでした。一方、エージェントが失敗と分類した1つのアプリケーションは最終的に正しくビルドされました。これは、エージェントの自己評価を移行完了の信頼できるシグナルとして扱うべきではないことを示唆しています。独立したビルドとテストの検証が依然として不可欠です。
フレームワーク移行は、単一のファイルやレイヤーに影響を与えることはめったにありません。設定、サービス、データベース、ウェブコンポーネントの変更は、アプリケーション全体に波及することがよくあります。発見：移行は反復的であり、線形ではありません。最も頻繁に訪問されたレイヤーは、設定、ウェブ、データベース、サービスでした。一般的な遷移には、設定↔ウェブ、サービス↔データベースが含まれます。これは、移行が単純なソース間変換ではなく、反復的な依存関係解決プロセスであることを示唆しています。
エージェントはどこに最も労力を費やすのでしょうか？レイヤーの再訪問頻度を移行労力の代理として使用しました。繰り返し訪問が必要なレイヤーは、通常、デバッグ、依存関係解決、またはフレームワーク適応を伴います。発見：設定が移行労力を支配します。エージェントは、フレームワークの違いや依存関係の問題を解決するために、設定関連の成果物に繰り返し戻りました。
コード変換に関係しない課題は何でしょうか？すべての移行問題がソースコードに起因するわけではありません。発見：環境とツールが重要です。エージェントは、Dockerキャッシュの不整合、ポート接続の問題、Mavenラッパーやビルドツールの問題などの環境問題に頻繁に直面しました。これらの運用上の懸念は、ソースコードの移行がほぼ完了していても、検証を遅らせることがよくあります。モダナイゼーションの失敗は、ビルドシステム、デプロイ環境、依存性注入、データベース、エンドポイント、アサーション、インフラストラクチャに及びます。
重要な教訓：フレームワークモダナイゼーションの最大の課題は、Javaコードを変換することではなく、設定、インフラストラクチャ、ランタイム環境にわたる依存関係のネットワークを管理することです。最先端のエージェントは移行プロセスの大部分を自動化できますが、信頼性の高い検証とアーキテクチャ推論は、成功する結果を達成するために依然として重要です。ScarfBenchはこれらの課題を明らかにし、真に自律的なアプリケーションモダナイゼーションに向けた進歩を測定する標準化された方法を提供します。
ScarfBenchは、研究者と実践者のためのオープンリソースとして設計されています。リソースには、ベンチマークデータセット、評価インフラストラクチャ、公開リーダーボード、ドキュメント、オープンソースコードが含まれます。研究者はエージェントアーキテクチャと技術を比較できます。実践者は、本番環境にモダナイゼーションソリューションをデプロイする前に、ScarfBenchを使用して評価できます。
ウェブサイト：https://scarfbench.info データセット：https://huggingface.co/datasets/ibm-research/ScarfBench スペース：https://huggingface.co/spaces/ibm-research/ScarfBench GitHubリポジトリ：https://github.com/scarfbench/scarfbench リーダーボード：https://scarfbench.info/leaderboard 論文：https://arxiv.org/abs/2605.06754
フレームワーク移行は、AI支援ソフトウェアエンジニアリングにおける最大の未解決問題の1つです。ScarfBenchがコミュニティの進捗測定を支援し、次世代のAI支援アプリケーションモダナイゼーションを加速することを願っています。研究者、実践者、およびフレームワークコミュニティがエージェントを評価し、新しい移行シナリオを提供し、技術の進歩に貢献することを歓迎します。