エンタープライズアプリケーションのモダナイゼーションは、組織が取り組むソフトウェアエンジニアリング活動の中で最大かつ最も費用のかかるもののひとつです。チームはメンテナンス性、クラウド対応性、開発者生産性、最新機能へのアクセスの向上を目的に、フレームワーク間でアプリケーションを移行します。
最近のコーディングエージェントの進化により、AI支援によるモダナイゼーションへの期待が高まっています。しかし重要な疑問が残ります。
AIエージェントは実世界のエンタープライズアプリケーションを確実にモダナイズできるのか？
既存のソフトウェアエンジニアリングベンチマークは、バグ修正やコード生成において目覚ましい進展を示していますが、フレームワーク移行は根本的に異なる課題を提示します。成功にはコードの翻訳だけでなく、動作の保持、ビルドシステムの適応、ランタイム依存関係のナビゲーションが必要です。
このギャップに対処するため、私たちはScarfBench（Self-Contained Application Refactoring Benchmark）を導入します。これは、エンタープライズJavaにおけるクロスフレームワーク移行タスクでAIエージェントを評価するためのオープンなベンチマークです。
ScarfBenchは3つの主要なJavaエコシステム間の移行に焦点を当てています。
- Spring
- Jakarta EE
- Quarkus
生成されたコードを参照実装と比較する従来のベンチマークとは異なり、ScarfBenchは移行されたアプリケーションが実際にビルド、展開され、動作を保持するかどうかを評価します。
なぜ移行が難しいのか
フレームワーク移行は、アノテーションの置き換え以上のものです。
単純なリポジトリ移行でも、依存性注入、永続化設定、クエリ、フレームワーク記述子にわたる変更が必要になる場合があります。これらのいずれかで小さなミスがあると、正常な展開が妨げられる可能性があります。
図：Spring → Jakarta移行の例
フレームワーク移行では、ソースコードだけでなくフレームワークのセマンティクスを翻訳する必要があります。
ScarfBenchの紹介
ScarfBenchは、エンタープライズJavaフレームワーク移行タスクでAIエージェントを評価するための体系的な方法を提供します。
アプリケーションには以下の要件があります。
- 正常にビルドされること。
- 正しく展開されること。
- 動作検証に合格すること。
これにより、モダナイゼーションの品質をより現実的に測定できます。
ベンチマークの概要
| 指標 | 値 |
|---|---|
| アプリケーション数 | 34 |
| フレームワーク実装数 | 102 |
| 移行タスク数 | 204 |
| コード行数 | 約151K |
| ソースおよびテストファイル数 | 約2,000 |
| 専門家作成のテスト数 | 1,331 |
ScarfBenchには、焦点を絞った移行タスクとアプリケーション全体の移行の両方が含まれます。
図：ScarfBench構築パイプライン
JSRベースのエンタープライズJava分類から始め、エキスパートによる移行により、Spring、Jakarta EE、Quarkusにわたる検証済み実装を作成します。
最先端エージェントのパフォーマンスは？
ScarfBench上で複数の最先端コーディングエージェントを評価しました。
従来のソフトウェアエンジニアリングベンチマークでは高いパフォーマンスを示していますが、フレームワーク移行は依然として困難です。成功率はフレームワークペアによって大きく異なり、アプリケーション全体の移行は特に困難なままです。
図：現在のリーダーボード
最先端のエージェントでも、動作の成功率は10%未満にとどまっており、コンパイル可能なコードの生成とアプリケーションの動作保持の間にギャップがあることを示しています。
図：コンパイル → 展開 → テストの進行状況
コンパイルの成功率は常に展開の成功率を上回り、展開の成功率は動作の成功率を上回ります。ビルド成功率だけで移行の品質を大幅に過大評価することになります。
図：ターゲットフレームワーク別の移行結果
移行の難易度はターゲットフレームワークに大きく依存し、Jakarta EEが特に困難であることがわかりました。
JavaモダナイゼーションにおけるAIエージェントについてわかったこと
成功率の測定に加え、ScarfBenchはモダナイゼーション中のエージェントの動作を理解するのに役立ちます。
エージェントは移行完了を確実に判断できるか？
移行されたアプリケーションは、実際にビルドして実行できて初めて有用です。
そこで、エージェントが報告した結果と独立したビルド検証を比較しました。
発見：エージェントは過信している
Claude Codeは30件のアプリケーション全体のうち29件でビルド成功を報告しました。
しかし、そのうち実際にビルドに成功したのは22件のみでした。
一方、エージェントが失敗と分類した1件のアプリケーションは、最終的に正しくビルドできました。
これは、エージェントの自己評価を移行完了の信頼できる指標として扱うべきではないことを示唆しています。
独立したビルドおよびテスト検証は依然として不可欠です。
エージェントはアプリケーションの依存関係をどのようにナビゲートするか？
フレームワーク移行は、単一のファイルやレイヤーに影響を与えることはほとんどありません。
設定、サービス、データベース、Webコンポーネントの変更は、アプリケーション全体に波及することがよくあります。
発見：移行は線形的ではなく反復的である
最も頻繁に訪問されたレイヤーは以下の通りです。
- 設定
- Web
- データベース
- サービス
一般的な遷移には以下が含まれます。
- 設定 ↔ Web
- サービス ↔ データベース
これは、移行が単純なソースからソースへの変換ではなく、反復的な依存関係解決プロセスであることを示唆しています。
エージェントは最も多くの労力をどこに費やすか？
レイヤーの再訪問頻度を移行労力の代理指標として使用しました。繰り返し訪問が必要なレイヤーは通常、デバッグ、依存関係解決、またはフレームワーク適応に関連していました。
発見：設定が移行労力を支配する
エージェントは線形に進むのではなく、フレームワークの違いや依存関係の問題を解決しながら、設定関連のアーティファクトに繰り返し戻っていました。
コード変換以外の課題とは何か？
すべての移行問題がソースコードに起因するわけではありません。
発見：環境とツールが重要
エージェントは以下のような環境的な問題に頻繁に苦戦しました。
- Dockerキャッシュの不整合
- ポート接続の問題
- Mavenラッパーとビルドツールの問題
これらの運用上の懸念は、ソースコードの移行自体がほぼ完了している場合でも、検証を遅らせる原因となりました。
図：障害モードの分布
モダナイゼーションの失敗は、ビルドシステム、展開環境、依存性注入、データベース、エンドポイント、アサーション、インフラストラクチャに及びます。
主要なポイント
フレームワークモダナイゼーションにおける最大の課題は、Javaコードの翻訳ではありません。
設定、インフラストラクチャ、ランタイム環境にわたる依存関係のネットワークを管理することです。
最先端のエージェントは移行プロセスの大部分を自動化できますが、信頼性の高い検証とアーキテクチャ上の推論は、成功した結果を得るために依然として重要です。
ScarfBenchはこれらの課題を明らかにし、真に自律的なアプリケーション・モダナイゼーションに向けた進捗を測定するための標準化された方法を提供します。
ScarfBenchを探る
ScarfBenchは研究者と実務者のためのオープンリソースとして設計されています。
リソースには以下が含まれます。
- ベンチマークデータセット
- 評価インフラストラクチャ
- 公開リーダーボード
- ドキュメント
- オープンソースコード
研究者はエージェントのアーキテクチャや技術を比較できます。実務者はScarfBenchを使用して、本番環境に展開する前にモダナイゼーションソリューションを評価できます。
ウェブサイト
データセット
https://huggingface.co/datasets/ibm-research/ScarfBench
Space
https://huggingface.co/spaces/ibm-research/ScarfBench
GitHubリポジトリ
https://github.com/scarfbench/scarfbench
リーダーボード
https://scarfbench.info/leaderboard
論文
https://arxiv.org/abs/2605.06754
フレームワーク移行は、AI支援ソフトウェアエンジニアリングにおける最大の未解決問題のひとつです。ScarfBenchがコミュニティの進捗測定と、次世代のAI支援アプリケーション・モダナイゼーションの加速に役立つことを願っています。
研究者、実務者、フレームワークコミュニティの皆様に、エージェントの評価、新たな移行シナリオの提供、最先端技術の進展へのご協力をお願いします。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.