詳細を読む
IBM Researchは6月30日、企業向けJavaアプリケーションのフレームワーク移行をAIエージェントが担えるかを測るオープンベンチマーク「ScarfBench」を公開しました。SpringからJakarta EE、Quarkusといった主要な三つのエコシステム間の移行を対象とし、生成コードを参照実装と比べる従来手法ではなく、移行後のアプリが実際にビルドされ、デプロイでき、挙動を保てるかを検証します。経営者やエンジニアにとって、AIによるシステム近代化の実力を見極める指標になります。
フレームワーク移行は単なる注釈の置き換えではありません。依存性注入や永続化設定、クエリ、各種記述子にまたがる変更が必要で、どこか一つでも誤ると正常にデプロイできなくなります。ScarfBenchはコンパイル、デプロイ、動作検証という三段階で成否を測り、ビルド成功だけを見ると移行品質を過大評価しやすいと指摘します。
最先端エージェントを評価した結果、移行の難しさが浮き彫りになりました。とりわけJakarta EEへの移行が難関で、アプリ全体の移行は依然として成功率が低い水準にとどまります。コンパイル成功はデプロイ成功を上回り、デプロイ成功は動作成功を上回るため、表面的な指標だけでは実態を捉えきれません。
注目すべきは、エージェントの自己申告が信頼できない点です。Claude Codeはアプリ30件中29件でビルド成功を報告しましたが、実際に成功したのは22件にとどまりました。失敗と判定した1件はむしろ正常にビルドできており、独立したビルド検証とテストが欠かせないと結論づけています。
移行作業の実態は直線的ではなく反復的でした。エージェントは設定関連の作業に繰り返し立ち戻り、依存関係の解決やフレームワーク差異の調整に多くの工数を割いていました。さらにDockerキャッシュの不整合やポート接続、Mavenのビルドツール周りといった環境面の問題が、コード移行自体が済んでも検証を遅らせる要因になっていたといいます。
IBMは、近代化の最大の障壁はJavaコードの翻訳ではなく、設定やインフラ、実行環境にまたがる依存関係の管理だと総括しています。データセットや評価基盤、公開リーダーボードを誰でも使える形で提供しており、研究者は手法を比較でき、実務者は導入前に近代化ツールを検証できます。自律的なアプリ近代化への進捗を測る共通の物差しとして活用が見込まれます。