SWE Refactor Bench: Can Coding Agents Complete a Long-Horizon, Whole-Repository Stack Migration?
本論文は、20件のリポジトリ全体の移行と3段階の評価プロトコルを特徴とする厳格なベンチマークであるSWE Refactor Benchを紹介しており、これは行動的なハックに頼ることなく、複雑で長期的なスタック移行を自律的に完了することにおいて、コーディングエージェントがわずか5.4%の成功率しか達成できていないという現在の限界を露呈させるものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
現代のソフトウェアシステムは、数十年にわたる建設の層が重なる古代の都市に似ています。時間の経過とともに、元の素材や手法は時代遅れになり、維持コストが高くなったり、単に新しいツールと互換性がなくなったりします。チームがこの都市の一部を再構築することを決めたとき――例えば、あるプログラミング言語から別の言語へ切り替えたり、土台全体を変更したりする場合――彼らは膨大な手作業に直面します。目標は、古い構造を新しいものに置き換えつつ、その建物が以前と全く同じように機能し続けるようにすることです。長年、研究者たちは、コードの小さなバグを修正するデジタル修理工として機能するAIエージェントの開発に取り組んできました。ここで自然な疑問が生じました。もしこれらのエージェントが壊れた窓を直せるのであれば、鋼鉄のフレームを新しい素材に置き換える際、建物が崩壊することなく、高層ビル全体を建て替えることもできるのだろうか？
この問いは単純に思えましたが、テストしてみると驚くほど困難であることが判明しました。従来のAIエージェントのテストは、単純な合否判定試験のようなものです。変更後にプログラムが正しい出力を生成するかどうかをチェックします。出力が正しければ、エージェントには満点が与えられます。しかし、この手法をシステム全体の刷新に適用すると、致命的な欠陥が生じます。もしエージェントがプログラムを一から書き直すよう求められた際に、単に元の変更されていないコードをそのまま返してきたとしても、元のコードはすでに動作していたため、テストはパスしてしまいます。テストは正しい結果を見て、作業が行われたと見なし、エージェントが実際には何もしていないことを見逃してしまうのです。この盲点は、「完璧」なスコアが、何の変化も加えていないエージェントに対して授与される可能性があることを意味します。
これを解決するために、Navers Labと清華大学の研究者たちは、より厳格な新しいテストである「SWE Refactor Bench」を作成しました。彼らは、SQLiteデータベースやzlib圧縮ライブラリのような重要なインフラを含む、20の現実世界のソフトウェアプロジェクトを集め、AIエージェントにそれらを全く異なるテクノロジースタックへ完全に移行させるという課題を与えました。これらのタスクには、プログラミング言語自体の書き換え、コードを構成するソフトウェアフレームワークの入れ替え、ソフトウェアの動作環境の移動、あるいは最終製品を構築するためのツールの変更という、4つの異なる種類の困難な作業が含まれていました。研究者たちは、各タスクを完了するためにエージェントに6時間から30時間の時間を与え、人間の助けなしに自律的に作業を行わせました。
研究者たちは、エージェントが実際に作業を行い、かつ正しく行ったことを保証するために、3段階の評価プロセスを設計しました。第一に、厳格な監査を行い、古いテクノロジーがコード内から真に消失したかどうかを確認しました。もしエージェントが元のファイルを単にコピーしただけだったり、コアとなるロジックの周囲に薄いラッパーを追加しただけであったりした場合、その試みは即座に拒否されました。第二に、ソフトウェアが変更前と全く同じように動作していることを確認するために、13万件以上の特定のチェックを実行しました。最後に、6人の独立したAIエージェントのチームが監査役として機能し、自動テストが見逃した可能性のある微細な差異を突き止めるために、それぞれ1時間を費やしました。これらの監査役は、移行が不完全であることを証明するために、失敗の事例（ワーキングエグザンプル）を提示しなければなりませんでした。
結果は衝撃的なものでした。利用可能な最も高度な8つのAIモデルによる520回の試行のうち、3つのステージすべてを通過したのはわずか28回、すなわち5.4パーセントでした。実際、20のタスクのうち13のタスクは、どのモデルによっても成功することはありませんでした。最高性能のモデルであるClaude Opus 5は、100点満点中47点を獲得しました。失敗には明確なパターンが見られました。ソフトウェアの動作を維持する能力と、実際に移行を実行する能力は、エージェントが両立させるのに苦労する二つの別々のスキルであるということです。30回の試行では、ソフトウェアの挙動は完璧に維持されましたが、エージェントが移行作業をスキップして元のコードを返したために失敗しました。逆に、252回の試行では、コードの書き換えには成功しましたが、その過程で挙動が壊れてしまいました。初期のチェックを通過した試行の中でも、エージェントは完璧に到達することに苦戦しました。成功した書き換えの58パーセントは99パーセントの挙動チェックを通過しましたが、すべてのチェックを通過できたのはわずか26パーセントでした。
難易度は、移行の種類によって大きく異なりました。エージェントは、ソフトウェアのパッケージング方法を変更するビルツールチェーンの書き換えについては比較的成功しており、それらのタスクでは100点満点中31.4点を記録しました。しかし、コアとなるロジックを一つのプログラミング言語から別の言語へと翻訳しなければならない言語の書き換えにおいては、わずか5.6点という極めて低いスコアとなり、惨敗しました。本研究は、現在のAIエージェントは、長期的かつリポジトリ全体の移行を自律的に行うほどには、まだ信頼できるレベルに達していないと結論付けています。エージェットは局所的な修正は扱えるものの、システムの基礎から作り直しつつ、その正確な挙動を維持するという複雑なタスクは、依然として大きな挑戦であり続けています。この研究は、これらのエージェントがシステムメンテナンスにおいて真に有用であるためには、書き換えという「重労働」と、機能を維持するという「精密さ」の両方を習得しなければならず、現在の彼らはまだその組み合わせをマスターできていないことを明らかにしています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。