IBM ResearchがエンタープライズJavaアプリケーションのフレームワーク移行をAIに解かせるベンチマーク「ScarfBench」を公開した。34のアプリケーションと204の移行タスクで構成され、コードのコンパイル可否だけでなく、デプロイの成否や実行時の振る舞い保存を評価する点が特徴だ。主要AIエージェントの成功率は動作検証で10%未満にとどまり、既存のコード生成ベンチマークとの大きな乖離が明らかになった。

動けばOKではない、移行の三関門

ScarfBenchが既存のソフトウェア工学ベンチマークと一線を画すのは、「ビルド」「デプロイ」「動作検証」という三つの関門を設けている点だ。従来の評価は生成コードとリファレンス実装との比較に主眼を置くが、フレームワーク移行では依存性注入や永続化設定、クエリ変換といった微妙な差異が積み重なり、コンパイルに成功しても実際のサーバー上で意図通り動作しないケースが頻発する。公開されたリーダーボードでは、ビルド成功率に対し動作検証の成功率が一貫して低く、コードのコンパイル可否だけを見ていては移行の品質を大きく見誤ることが実証された。

ターゲットが難易度を決める構造

ベンチマークはSpring、Jakarta EE、Quarkusの三つのエコシステム間での移行を対象とし、移行先のフレームワークによって難易度が顕著に異なる結果を示した。特にJakarta EEへの移行は他の組み合わせに比べて成功率が著しく低く、AIエージェントが習得しているフレームワーク固有の知識や学習データの偏在が、現実のプロジェクト成果を左右する可能性を浮き彫りにしている。特定の技術スタックに強いAIが他で通用しない事態は、企業がAI導入を進める際の技術選定にも波及する論点となる。

コード生成の先にある「挙動保存」の壁

最先端のAIエージェントでも全体アプリケーション移行の動作成功率が10%に届かない事実は、コード生成から挙動保存へという課題の本質の移り変わりを示す。アノテーションの置き換えやAPI呼び出しの変換にとどまらず、実行時の振る舞いやビルドシステム、ランタイムの依存関係までを整合させるには、局所的なコード編集を超えたシステム全体の理解が必要になる。IBM Researchのブログが指摘する通り、フレームワーク移行は「フレームワークが体現する意味論ごと変換する」作業であり、この意味論レベルの転移が現在のAIにとって最大の障壁となっている。

エンタープライズAI活用の評価軸が変わる

ScarfBenchの登場は、エンタープライズ領域におけるAI評価の重心が「生成能力」から「保守・移行能力」へと移りつつある流れを加速させる。約15万行のコードと1300超の専門家作成テストを備えたこのベンチマークは、ベンダーのデモ環境では見えにくい実運用レベルの課題を可視化する。今後、AIの導入を検討する企業にとって、コンパイル成功率に加えてデプロイ成功率や動作検証の結果を問う姿勢が標準化していく可能性がある。