コード生成AIは「正しく削除する」ことが苦手なのか

導入

AI コーディング支援は、関数の生成やバグ修正では急速に実用化が進んでいる。しかし論文「To Add Is Machine, To Delete Is Human」は、より地味だが重要な問題を取り上げる。大規模言語モデルは、追加よりも「正しい場所を削除し、そこで止める」ことに弱いという問題だ。著者らはこれを deletion avoidance、つまり削除回避と呼ぶ。

主要ポイント

• テスト合格は品質保証ではない。 SWE-bench Verified の公式リーダーボードにある 5 つの主要モデルを調べたところ、全モデルが解けたタスクでも、開発者パッチに含まれる削除箇所の再現率は最大 71.7% にとどまった。モデルは必要な削除があるファイルには 92% 超の割合で到達するが、正確な行を削る割合は 52% 未満だった。
• 典型例は Guard-and-Go。 古いロジックを消す代わりに、guard、fallback、条件分岐の中に残すパターンが多い。研究では、テストに通ったパッチの 29.0% がこの形だった。既存テストには通っても、保守性の低いコードが残る。
• 既存テストは「消えたこと」を見ない。 研究チームが 34 の削除中心タスクに、対象コードが残っていれば失敗するテストを追加すると、4 つのフロンティアモデルの解決率は 63.2% から 41.9% に低下した。これは、ベンチマークが古いコードの温存を見逃している可能性を示す。
• CanItDelete は削除だけを測る。 実際の修正では追加と削除が混在するため、著者らは実コミットから、編集内容が削除のみである 200 タスクを集めた。追加作業を取り除いても、最良モデルでさえ約 5 件に 1 件は失敗した。
• 行番号を与えても十分ではない。 削除すべき正確な行を提示すると漏れは減るが、今度は範囲を超えて消したり、不要なコードを追加したりする問題が出る。

意味と影響

この研究の重要性は、コード生成AIの評価を「テストに通るか」から「保守可能な変更か」へ広げた点にある。人間のエンジニアにとって、不要な処理を消し、境界を守り、余計な迂回路を残さないことは修正の一部だ。AI エージェントが古いロジックを条件分岐の裏に隠すだけなら、本番コードにはまだ不安が残る。

一方で、改善の余地も示された。削除に焦点を当てた少量の後学習データにより、不完全な削除が減り、SWE-bench Verified の性能も改善したという。ただし過剰削除も増えたため、「最後まで削除する能力」と「削り過ぎない能力」は別々に鍛える必要がある。

今後のコードAI評価では、生成量だけでなく、消えるべきコードが本当に消えたかを検査する仕組みが重要になる。

出典：Hugging Face Daily Papers