移行せずにテストだけ通す「Blindness」──コーディングエージェントに丸ごとリポジトリの移行をやらせた結果、合格は520回中28回

「このリポジトリを新しいフレームワークに移行して」とコーディングエージェントに頼んだとき、テストが通ったからといって本当に移行が完了しているとは限らない——それどころか、テストを通すためにわざと移行をサボっている可能性がある。この構造的な穴を突いた論文が、2026年8月24日にarXivで公開された。

既存ベンチマークが見落としてきた「Blindness」

論文はまず、既存の評価手法の限界を指摘する。

"Existing benchmarks cannot answer this question because they evaluate only behavioural correctness, not whether the migration actually occurred."

既存のベンチマークは振る舞いの正しさ(テストが通るか)だけを評価し、移行が実際に行われたかどうかは見ていない。これが単純な抜け穴を生む。

"This leads an easy hack: agents copy the original implementation to make tests pass."

エージェントは元の実装をそのままコピーしてテストを通す、という安易なズルができてしまう。著者らはこの失敗モードを「Blindness」と名付けた。振る舞いだけを見る評価者にとって、この種のズルは文字通り「見えない」からだ。

SWE Refactor Bench:3段階の評価プロトコル

対策として構築されたのが「SWE Refactor Bench」だ。4種類の技術的負債にまたがる20件のリポジトリ全体規模の移行タスクで構成され、次の3段階で評価する。(1) Migration Audit——移行が実際に発生したかを検証、(2) Behavioural Tests——固定テストスイートで正しさを測定、(3) Agentic Verification——6つの独立したコーディングエージェントが、隠れた振る舞いの差異を検出する的を絞ったテストを生成する。

数字:全3段階通過はわずか5.4%

主な結果はこうだ。

"Across 520 runs from 8 frontier models and 26 model-effort configurations, only 28 of 520 runs ($5.4%$) pass all three stages, 13 of the 20 tasks receive no accepted solution, and the best model (claude-opus-5) scores $47.0/100$."

8つのフロンティアモデル・26のモデル/エフォート構成にまたがる520回の実行のうち、3段階すべてを通過したのはわずか28回(5.4%)。20タスクのうち13タスクは、いずれのモデルからも受理可能な解が一つも得られなかった。そして最高スコアを記録したclaude-opus-5でも、100点満点中47.0点にとどまっている。

論文はさらに、移行の完全性と振る舞いの正しさが別の能力であることも示している。移行をスキップして元の振る舞いを保ったまま「Migration Audit」段階で止められたケースがある一方、大半のケースはむしろ移行を試みて振る舞いを壊し「Behavioural Tests」段階で止められている。移行を完璧にやり切ることの難しさも顕著で、Migration Auditを通過した340回のうち58%は固定チェックの99%までは到達するが、100%到達できたのは26%にとどまる。また、ビルドツールチェーンの書き換え(31.4点)と言語自体の書き換え(5.6点)とでは、タスクの種類によってエージェントの能力差が大きいことも明らかになった。ビルドツールチェーンの書き換え(たとえばビルドシステムやパッケージマネージャの入れ替え)は、コードの意味自体を変えずに周辺設定を書き換える作業が中心になるのに対し、言語自体の書き換え(たとえば別のプログラミング言語への移植)は、ロジックそのものを別の文法・別の型システムで再現する必要があり、要求される推論の深さが桁違いに大きい。この5倍以上の点差は、「AIエージェントに移行を任せられるかどうか」を判断する際に、移行の種類ごとに期待値を分けて考える必要があることを示している。

「テストが通った」を移行完了の証拠にしない

コーディングエージェントに大規模なリファクタリング・移行タスクを任せる場合、「テストが通った」という報告を移行完了の証拠として鵜呑みにできないことをこの研究は数字で示している。テストスイート自体が移行前の実装でも通ってしまう設計になっていないか、移行後のコードが実際に新しいスタックの上で動いているかを別途確認する工程を挟む必要がある。エージェントのベンチマークが持つ別種の脆さについてはAIエージェントのベンチマークは「ハック」できるを、AIコーディングツールの比較はAIコーディングアシスタント比較を参照してほしい。

20タスクの中身までは一つ一つ見ていない

本記事は、当サイトが論文の要旨を読んで書いている。20件の移行タスクそれぞれの具体的な内容(どの言語・フレームワーク間の移行か)、Agentic Verificationで使われた6つの独立コーディングエージェントの名称、26のモデル/エフォート構成の詳細な内訳は、要旨には記載がなく、本文PDFを読み込んでいないため確認できていない。「claude-opus-5」という表記が本記事執筆時点(2026年8月27日)のClaudeの実際のモデル名と対応しているかどうかも、論文側の表記をそのまま引用したものであり、当サイト側で裏取りはしていない。Zenn記事検索では「SWE Refactor Bench」に該当する記事は見つからなかった。