テストを通っても十分ではない：コードモデルが編集しすぎる理由

導入

大規模言語モデルにコードを修正させる場合、テストを通過することは最低限の条件にすぎない。実際の開発現場では、パッチが小さく、レビューしやすく、元の実装意図を保っていることも重要になる。局所的なバグを直すだけなのに、モデルが関係のない処理まで書き換えれば、レビュー、回帰テスト、将来の保守に余計な負担が生じるからだ。

Hugging Face Daily Papersで紹介された研究は、このような「過剰編集」を調べている。ここでいう過剰編集とは、バグ修正に必要な範囲を超えてコードを変更する傾向である。

正しさ以外をどう測るか

研究者は400件のBigCodeBench問題を出発点に、参照解答へASTレベルの制御された破損を注入した。破損の内容が分かっているため、元の解答を復元するために必要な最小パッチも特定できる。これにより、モデルの出力を「動くかどうか」だけでなく、最小修正からどれほど離れているかという観点で比較できる。

評価では、Pass@1に加えて次の点を確認した。

• 関係のないコードまで変更していないか
• 生成パッチと最小パッチの距離はどの程度か
• 修正によって認知的複雑性が増えていないか
• 正しさを回復しながら元の実装を保てているか

結果として、過剰編集は能力の低いモデルだけの問題ではなかった。GPT-5.5を含むフロンティアモデルでも、高いPass@1と不必要に大きな変更が同時に現れた。つまり、機能的な正しさと編集の忠実度は、別々に評価すべき品質である。

保全を求める指示の効果

研究では、既存コードを維持し、必要な変更だけを行うよう明示する指示も検証した。この指示を加えると、平均の余分なLevenshtein距離は0.195から0.131へ低下し、追加された認知的複雑性は26.6%減少した。一方、Pass@1は2.3ポイント上昇した。

この結果は、モデルを大型化したり推論予算を増やしたりすれば、自然に編集が慎重になるとは限らないことを示す。書き換える能力が高くても、変更の境界を見極める能力が同じように高いとは限らない。修正タスクでは、抑制的に振る舞うことを指示するか、訓練で学習させる必要がある。

後訓練への示唆

後訓練の比較では、教師あり微調整は学習時に見た破損パターンに対しては有効だったものの、未知のパターンには過適合の傾向を示した。強化学習は、分布外での編集忠実度と修正性能の維持を両立する点で、より良いトレードオフを示した。

コードエージェントの開発者にとって、示唆は明確だ。テストの成功だけでなく、パッチの大きさ、不要な変更、認知的複雑性、そして人間によるレビューコストも評価目標に含めるべきである。利用者側でも、「最小限の修正にとどめ、無関係なリファクタリングはしない」と指定することが、単に推論時間を増やすより有効な場合がある。

この研究の重要な点は、最小限の編集をコード修正能力の独立した軸として示したことだ。大規模なリファクタリングを否定するものではない。局所的なバグ修正では、変更しない部分を見極めること自体が、測定可能な能力だと明らかにしたのである。

出典：Hugging Face Daily Papers