SWE-Touch：ユーザーが同じコードを編集したとき、コード生成エージェントは耐えられるか

導入

従来のコーディングエージェント向けベンチマークは、多くの場合、エージェントが静的なコードベースを単独で修正する状況を前提にしている。タスクを受け取り、リポジトリを読み、パッチを書き、最終結果で評価されるという流れだ。しかし実際の開発では、ユーザーが作業中にファイルを確認し、修正し、場合によってはエージェントが触ろうとしている箇所を直接変更する。

SWE-Touch は、この現実的なずれに焦点を当てた評価フレームワークである。問いは単純だが重要だ。ユーザーが途中でコードを変更したとき、エージェントは現在のワークスペース状態を正しく把握し、タスク達成に向けて適応できるのか。

論文では、SWE-chat データの分析から、59% のセッションにユーザー自身によるリポジトリ変更が含まれていたと報告されている。つまり、共有ワークスペースでの共同編集は例外ではなく、実運用に近い状況だと言える。

主なポイント

• 評価対象を静的環境から共有環境へ拡張：SWE-Touch は、エージェントが作業している最中にユーザーがコードを変更する状況を扱う。
• Counter-Edit を導入：タスクの成功と衝突するが、一見もっともらしい小さなコード変更を注入する。
• 重要領域を狙って編集を生成：複数の修復軌跡からタスク上重要なコード領域を抽出し、別の User Patch Generator がユーザー編集を作成する。
• 文脈付きで途中注入：エージェントが関連コードに到達したタイミングで、編集とユーザーメッセージを加える。
• 解決率が低下：SWE-bench Verified 上で、9つのコーディングモデルの平均解決率は 7.7 ポイント下がった。

何が分かったのか

SWE-Touch が示すのは、静的ベンチマークでの高性能が、そのまま共同開発での信頼性を意味しないという点である。多くのエージェントは、ユーザーがコードを変更した後も古いリポジトリ理解を前提に処理を続けてしまう。

失敗した実行の分析では、63.3% がユーザーによる衝突コードをそのまま残していた。これは、モデルが変更の存在を十分に検知できていない、あるいは検知してもタスク目標との矛盾を整理できていない可能性を示している。

また、性能低下は SWE-Bench Pro や DeepSWE のような長いタスクでも続いた。長期タスクでは、ファイル探索や段階的な修正が増えるため、ワークスペース状態のずれはさらに深刻になりやすい。

アブレーションでは、性能低下の主因は付随するメッセージではなく、コード編集そのものだと示されている。つまり課題は会話理解だけではない。エージェントには、リポジトリを再確認し、編集の衝突を判断し、対象動作をテストで検証する能力が求められる。

意義と影響

SWE-Touch は、コーディング AI の評価軸を一段現実に近づける。今後のエージェントは、単に正しいパッチを書く存在ではなく、人間と同じ作業空間で変化を追跡し、意図の衝突を調整し、修正後の挙動を確認する存在でなければならない。

開発ツール側では、ファイル変更の監視、コンテキストの更新、ユーザー編集の扱い、衝突時の検証フローがより重要になる。研究面では、静的スナップショットでは見えにくい「状態認識」と「適応行動」を測るための有効なストレステストになるだろう。

出典：Hugging Face Daily Papers