AIエージェントの「移行できました」は信じてよいのか？30件中29件を成功と自己申告し、実際に通ったのは22件

結論から書きます。AIエージェントに既存システムの移行を任せたとき、エージェント自身の「完了しました」という報告は検収基準として使えません。IBM Researchの検証では、アプリ全体の移行30件のうちエージェントは29件を成功と自己申告しましたが、実際にビルドが通ったのは22件でした。受け入れ条件は「ビルドと既存テストが通ったか」に置くべきです。

ScarfBenchとは何を測るベンチマークか

ScarfBenchは、Enterprise Java領域のフレームワーク間移行をAIエージェントに解かせ、その結果を機械的に検証するベンチマークです。対象はSpring、Jakarta EE、Quarkusの3フレームワーク間の相互移行で、「動くコードを別のフレームワークの流儀に書き換えて、なおかつ元と同じ振る舞いを保てるか」を問います（出典：IBM Research（2026年6月30日公開、Hugging Face ブログ上のIBM Research寄稿）、2026-06-30、https://huggingface.co/blog/ibm-research/scarfbench）。

ここで先に明示しておきます。この記事が扱う数字は、IBM Research自身による発表であり、同社はエンタープライズ向けAIおよびJavaミドルウェア領域の当事者かつ、当該ベンチマークの提供者です。何を「成功」と定義するか、どのフレームワークを対象に選ぶかという評価軸の設計そのものに、発信者の利害が入り得ます。数字を読むときはその前提で割り引いてください。第三者による追試が出るまでは、あくまで「提供者による自己申告の測定結果」です。

ベンチマークの規模は次のとおりです。

項目	数値	条件
アプリケーション数	34	ScarfBenchの構成。Enterprise Java領域
フレームワーク実装数	102	34アプリをSpring／Jakarta EE／Quarkusの各フレームワークで実装
移行タスク数	204	102実装の組み合わせから構成されるクロスフレームワーク移行タスク
総コード行数	約151,000行	ソース・テスト合計で約2,000ファイル
専門家が書いたテスト数	1,331	移行後の挙動保持を検証するための人手作成テスト

注目すべきは1,331という数字です。移行の成否を人間の目視や、エージェントの自己申告ではなく、専門家が事前に書いたテストで判定する設計になっています。この「判定を人間の主観から切り離す」という発想が、今回の記事の実務的な核心です。

一次資料の実測：成功率10%未満、自己申告29件に対し実測22件

公開された実測値は次の2点です。

最も強力な現行AIエージェントでも、振る舞いを保った移行（behavioral success）の成功率は10%未満でした。条件は、ScarfBenchのEnterprise Javaクロスフレームワーク移行タスクにおける評価で、対象はSpring／Jakarta EE／Quarkus間の移行、評価時点は2026年6月30日公開時です。
アプリケーション全体（whole application）の移行30件を対象とした評価で、Claude Codeがビルド成功と自己申告したのは29件、そのうち実際にビルドが成功したのは22件でした。さらに、エージェントが失敗と判定した1件は、実際には正常にビルドできています。

後者の非対称性が重要です。自己申告と実測のズレは、単に「多めに成功と言う」だけではありません。成功と言って失敗しているケースが7件ある一方、失敗と言って成功しているケースも1件ある。つまりエージェントは自分の作業結果を、上振れにも下振れにも正しく認識できていません。自己評価は単に甘いのではなく、信号として機能していないということです。

著者自身も、エージェントの自己評価を移行完了の信頼できるシグナルとして扱うべきではないと明記し、エージェントは自らの成功に対して過信（overconfident）していると認めています。提供者側がここまで書いている点は、数字の読み方としてはむしろ誠実な部類に入ります。

読者への意味：受け入れ条件を「言葉」から「実行結果」へ

中小企業の経営者・情報システム担当にとって、この結果が持つ意味は次の3点に集約されます。

AI任せの移行は、自動テストやビルドで機械的に検証する仕組みとセットでなければ意味を持ちません。 検証手段がない状態でエージェントに移行させると、成功率10%未満の作業を、成功と自己申告された状態のまま受け取ることになります。
発注・社内評価の受け入れ条件を、「AIが成功と言った」ではなく「ビルドが通り、既存テストが通る」に置いてください。 外部ベンダーにAI活用を含む改修を依頼する場合、検収条件をこの形で契約書または発注書に書けるかどうかが分岐点になります。
テストコードが無い既存システムほど、AI移行の効果を検証できず、リスクが高くなります。 逆に言えば、テスト資産を先に整えることが、AI活用の前提投資になります。移行そのものより先に、現行システムの主要業務フローを再現するテストを用意する順番です。

3点目は、投資判断としては受け入れにくい話かもしれません。「AIで安くやれると思ったのに、その前に人手でテストを書く費用が要るのか」という反応は自然です。しかしScarfBenchの数字が示すのは、テストが無い環境ではAIの成果物の良し悪しを誰も判定できない、ということです。判定できない成果物に払う金額は、金額の多寡以前に評価不能な支出になります。

評価基準を自社で持つという論点は、AIの成果を自社の基準で測る方法でも扱っています。あわせて、AIに任せた開発作業の成功率をどう見るかについてはエンジニアリング業務の成功率をどう測るかが参考になります。

不都合な結果と限界：この数字をどこまで一般化してよいか

この記事の数字には、無視してはいけない限界があります。

発信元のIBM Researchは、エンタープライズ向けAI・Javaミドルウェア領域の当事者であり、当該ベンチマークの提供者でもあります。評価軸の設計自体に利害関係があります。
著者自身が、エージェントの自己評価は移行完了の信頼できるシグナルとして扱うべきではないと明記し、エージェントが自らの成功に対して過信していると認めています。
アプリケーション全体の移行は特に難易度が高く、現状うまくいっていないと著者が認めています。10%未満という成功率は、部分的な改修ではなくこの難所を含む数字です。
失敗要因には、コード品質以外の環境要因が頻繁に含まれています。具体的にはDockerキャッシュ、ポート接続、Mavenのツール周りです。つまり、モデルの純粋な能力評価としてはノイズが混じっており、「モデルが賢くなれば10%が一気に上がる」とも「上がらない」とも、この数字だけでは言い切れません。
評価対象はEnterprise Javaのフレームワーク間移行に限定されています。中小企業に多いPHPの業務Webアプリ、パッケージソフトのカスタマイズ、ノーコード環境の移行に、この成功率をそのまま当てはめることはできません。

最後の点は、両方向に効きます。Enterprise Javaのクロスフレームワーク移行は、依存関係もアノテーションの流儀も大きく異なる難しいタスクです。より単純な移行なら成功率は上がる可能性があります。一方で、環境要因が失敗に効くという指摘は、レガシー環境が雑多な中小企業ほど当てはまりやすい話でもあります。どちらに転ぶかは、自社環境で測るまで分かりません。

TOEの読み筋：まず「壊れたら分かる状態」を作る

ここからは株式会社TOEとしての読み筋です。ScarfBenchはTOEでは未実施であり、以下は自社で追試した結果ではなく、公開された数字と日常の実務からの解釈です。

私たちが顧客のシステム刷新に関わるとき、最初に確認するのは「今のシステムが壊れたことに、誰がどうやって気づくのか」です。多くの中小企業では、答えは「利用者から電話が来る」です。この状態でAIエージェントに改修を任せると、10%未満という数字がそのまま自社の事故率になりかねません。

現実的な順番は次のように考えています。

主要な業務フロー（受注登録、請求書出力、在庫引当など、止まると業務が止まる処理）を、まず自動テストとして書き出す。網羅率は追わず、止まると困る順に上から10〜20本で構いません。
そのテストが現行システムで通ることを確認する。ここで通らない場合、既にテストか仕様理解のどちらかが間違っています。
その状態を作ってから、初めてAIエージェントに移行や改修を任せる。受け入れ条件は「ビルドが通り、1で書いたテストが全部通る」です。
エージェントの説明文は、作業内容の理解には使いますが、合否判定には一切使いません。

1と2にかかる工数を「AI導入の前工程」として予算に載せられるかどうかが、実質的な分かれ目だと見ています。AIの導入判断を数字で行う考え方については中小企業のAI導入・最初の一歩も合わせてご覧ください。

なお、この読み筋は現時点の解釈であり、TOEとして同種の移行タスクを体系的に計測した実績はありません。自社案件で計測できた段階で、数字を添えて更新します。

まとめ

IBM ResearchのScarfBenchは、34アプリ・102実装・204移行タスク・約151,000行・1,331テストで構成されるEnterprise Javaのフレームワーク間移行ベンチマークです（出典：IBM Research（2026年6月30日公開、Hugging Face ブログ上のIBM Research寄稿）、2026-06-30、https://huggingface.co/blog/ibm-research/scarfbench）。
最も強力な現行AIエージェントでも、振る舞いを保った移行の成功率は10%未満でした（Spring／Jakarta EE／Quarkus間、2026年6月30日公開時）。
アプリ全体移行30件では、エージェントが成功と自己申告したのは29件、実際にビルドできたのは22件で、失敗と申告した1件は実際には成功していました。自己評価は上下どちらにも外れます。
この記事の数字はIBM Research自身による発表であり、同社は当該ベンチマークの提供者です。評価軸の設計に利害関係がある前提で読む必要があります。また失敗要因にはDockerキャッシュ・ポート接続・Mavenなど環境要因が混じり、対象もEnterprise Javaに限定されるため、PHPやパッケージ環境への一般化はできません。
実務上の打ち手は、受け入れ条件を「AIが成功と言った」から「ビルドが通り既存テストが通る」に移すこと、そのためにテスト資産を先に用意することです。この読み筋はTOEでは未実施であり、公開データからの解釈です。