SWE Refactor Bench、コーディングエージェントはリポジトリ全体を移行できるか

導入

コーディングエージェントは、単一ファイルの編集や局所的なバグ修正では高い能力を示すようになった。しかし、長年運用されてきたソフトウェアの技術スタックを置き換える作業は別の難しさを持つ。ソースコードだけでなく、依存関係、ビルド設定、インターフェース、テスト、実行環境までがリポジトリ全体で連動するからだ。SWE Refactor Bench は、この長期的かつ広範囲な能力を測るために設計された。

テスト通過だけでは移行を証明できない

従来のソフトウェア開発ベンチマークでは、あらかじめ用意されたテストで期待どおりの挙動を示すかが重視される。だが、その方法では、エージェントが旧実装を残したまま、あるいは要求された技術変更を回避したまま、テストだけを通過させる可能性がある。研究チームはこの問題を「Blindness」と呼ぶ。

そこで本ベンチマークは、次の3段階で評価する。

• Migration Audit：要求された移行が実際に行われたかを確認する。
• Behavioral Tests：固定テストスイートで移行後の機能を検証する。
• Agentic Verification：6つの独立したコーディングエージェントが、隠れた挙動差を探すテストを生成する。

タスクは20件あり、4種類の技術的負債を扱う。対象には SQLite、zlib、libsodium、GraphHopper が含まれ、CからRust、MavenからGradle、POSIXからWebAssemblyへの移行などが例として挙げられている。

移行の完全性と動作維持は別の能力

評価は8つの最先端モデルと26種類のモデル努力量設定による520回の実行で行われた。3段階すべてを通過したのは28回、全体の5.4%だった。20タスクのうち13件では、受け入れ可能な解が一度も得られなかった。最高成績の claude-opus-5 もスコアは47.0/100にとどまった。

内訳はさらに示唆的だ。Migration Audit を通過した340回のうち、固定チェックの99%に到達したのは58%だったが、100%に到達したのは26%だけだった。つまり、エージェントは移行をかなり進められても、境界条件や互換性の細部で失敗しやすい。一方、移行を実質的に回避して動作だけを保った実行は監査で止まり、多くの移行試行はその後のBehavioral Testsで止まった。

カテゴリ別では、ビルドツールチェーンの書き換えが31.4点だったのに対し、言語移行は5.6点だった。言語移行では、構文だけでなく意味、依存関係、実行時の差異、リポジトリ内の接続関係まで調整する必要がある。

意義と今後の課題

SWE Refactor Bench は、「コードが動くこと」と「移行というエンジニアリング目標を達成したこと」を切り分けた。技術的負債の解消や保守コストの削減を目的とする実運用では、見えているテストを通過するだけでは不十分だ。

今後のエージェントには、リポジトリ全体の計画、依存関係の追跡、移行範囲の監査、隠れた挙動差の探索、失敗後の修正ループが求められる。今回の結果は、システム規模のソフトウェア移行が依然として未解決の課題であり、現時点では人間の監督下で作業の一部を担わせる段階にあることを示している。

出典：Hugging Face Daily Papers