コーディングエージェントが作業している最中に、コードや要件が変わったらどうなるのか。この問いを測るベンチマーク「SWE-Shift」を、研究チームが10月23日にarXivで公開しました。17のエージェントを試したところ、全員が変化のない条件より大きく成績を落としています。首位のGPT-6 Astraでも、成功率は67.35%から24.79%に下がりました。現場の開発に近い条件では、今のエージェントがまだ弱いことを数字で示した研究です。
背景と文脈
コーディングエージェントの実力は、これまで主にSWE-bench（GitHubの実際のissueを解かせ、テストが通るかで評価するベンチマーク）型の試験で測られてきました。こうした試験では、作業の開始から終わりまで、リポジトリも課題も変わらないことが前提です。
しかし実際の開発はそう静かではありません。同僚が同じファイルを書き換え、依存ライブラリが更新され、仕様も途中で変わります。エージェントに長い作業を任せるほど、途中で状況が変わる確率は上がります。
このずれを測るために作られたのが、SWE-Shift: Evaluating Coding Agents in Evolving Workspacesです。論文は47ページあり、コードもGitHubで公開されています。先週紹介した対話型の修正を測るUserSWEが「利用者とのやり取り」に注目したのに対し、SWE-Shiftは「作業環境そのものの変化」に焦点を当てています。
技術/ビジネス面
仕組みの核は、同じ地点から2本に分ける比較です。作業の途中まで進んだ状態を保存し、そこから何も起きない「Clean」と、途中で変更が入る「Shifted」を走らせます。成功とみなすのは、今の課題を終え、まだ有効な作業を壊さず、状態と根拠の確認にも通った場合だけです。
変更の種類は12に分かれます。協力者がコードを書き換える、APIの契約が変わる、プロセスやポートの状態が変わる、ツールの権限や仕様が変わる、といったものです。古い結果をそのまま信じてしまう「古い根拠」や、別のブランチの結果を取り違える「根拠の取り違え」も含まれます。120のシナリオを、それぞれ9つのタイミングで試しました。
結果は厳しいものでした。2位のClaude Fable 5.1は62.01%から18.33%へ、Claude Opus 5は53.76%から16.09%へ下がっています。ツールやセッションの変更、古い根拠の2種類では、17のシステムすべてが両方の条件で成功した割合（ペア成功率）0%でした。ある例では、エージェントが協力者の追加したAPIを消しても、元の39個のテストはすべて通りました。テストだけでは「他人の作業を壊したか」を見抜けないことを示しています。
改善策の手がかりもあります。変更後に会話の履歴をリセットする対策が、5つ中4つのシステムで最も効きました。ただし最終的なペア成功率は10.89〜17.54%にとどまります。トークン予算を基準の4倍より増やしても、上積みはわずかでした。
これからどうなるか
この研究は、ベンチマークの点数と現場での使いやすさの差を説明する材料になります。Cleanでの成績が高いモデルほど変化に強いとは限りません。Kimi-K2.6は、Cleanの点数がKimi-K3より低いのに、変化後に作業を保つ割合は上回りました。今後はエージェントの評価に「変化への強さ」を加える動きが広がりそうです。
開発者にとっては、エージェントに長い作業を任せる間、同じブランチを人が触らない運用が当面の現実解になります。並行して作業するなら、作業ツリーを分け、変更があったら一度履歴を切ってから再開させるほうが安全です。CIでも元のテストに頼るだけでなく、既存のAPIが消えていないかを確かめるチェックを足すと、取りこぼしを減らせます。
まとめ
SWE-Shiftは、作業中にコードや要件が変わる状況でコーディングエージェントを試すベンチマークです。17のシステムすべてが成績を落とし、首位でも成功率は約25%でした。テストが通っても他人の作業を壊す例もあり、運用とCIの設計で補う必要があります。
参考リンク
アイキャッチ画像: Photo by Christina @ wocintechchat.com M on Unsplash
