コードはこの投稿で入手可能です。

AI 支援のコーディングが標準となり、Cursor や GitHub Copilot、Claude Code、Codex といったツールを用いることで、モデルによるコードへの介入が増えています。もし過去 1 年間にこれらのツールのいずれかを試したことがあるなら、おそらく以下の現象を経験されたことでしょう：単純なバグ（オフ・バイ・ワンエラーなど、あるいは演算子の誤用）の修正をモデルに依頼すると、モデルはバグを修正しますが、関数の半分まで書き換えられてしまいます。追加のヘルパー関数が出現します。本来問題ない変数名が改名されます。正当な入力検証ロジックが追加されます。結果として生じる差分（diff）は甚大です。

私はこの現象を**「過剰編集（Over-Editing）」問題**と呼んでいます。モデルが、実際には書き換え无须のコードまで書き換えてしまう傾向を示すことを指します。これは想像するよりも重要度の高い問題です。コードレビューはすでにボトルネックとなっており、レビュワーが「何が変化したか」「なぜ変化したのか」「変更が安全か」を理解する必要があります。正しい修正にもかかわらず関数の全体を書き換えてしまうモデルの場合、コードは完全に無識別となり、この作業は劇的に困難になります。

本投稿では、既存の大規模言語モデル（LLM）に過剰編集の傾向があるかどうか、そしてモデルをより忠実な編集者として訓練することはできるかを調査します。

過剰編集（Over-Editing）

図 1: 過剰編集問題の典型的な例です。GPT-5.4（高推論設定）は、正しい修正が単に

range(len(x) - 1)

を

range(len(x))

とすることだけであるにもかかわらず、関数全体を書き換えます。

過剰編集とは、手元の問題を解決するために厳密に必要なものを超える範囲でコードをモデルが変更することを指します。正確に言うと：モデルの出力が機能的に正しいものであっても、元のコードから構造的な乖離が、最小限の修正が必要とする度合いよりも大きい場合、モデルは過剰編集を行っているといいます。

図 1 の例はこの点をよく表しています。バグは

range()

呼び出しにおける単一のオフ・バイ・ワンエラー（

range(len(x) - 1)

は

range(len(x))

でなければならない）であり、正しい修正は一行だけです。GPT-5.4（高推論設定）は、関数全体を再記述することで応答します：明示的な

None

チェックの追加、

dtype=float

を伴う

np.asarray

変換の導入、有限値マスキングの追加、配列サイズの検証、

curve_fit

呼び出しシグネチャの変更、そしてプロットロジック全体の置換などです。出力がテストを通過し機能的に正しいものであっても、差分は膨大であり、それらの追加のうち一つも求められておらず、必要もありませんでした。

この問題は、行われている作業の種類から考えることで理解しやすくなります。ソフトウェア工学は広範にわたって 2 つのモードに分けられます：グリーンジールド（Green-field）（ゼロから新しいものを構築する）と ブラウンフィールド（Brown-field）（既存のコードベース内で働く）。特にブラウンフィールドにおいては、既存のコードはチームによって理解され、意図的にそのように記述されてきました。モデルの仕事は問題を修正し、それ以外をすることだけです。

AI コーディングツールを使う際の一般的なアドバイスとして、「テストを書けば書くほど良いので、テストが通ればコードは問題ない」と言われることがよくあります。しかし、過剰編集はブラウンフィールドにおける失敗であり、正しさの失敗とは異なり、テストスイートには見えないという特徴があります。モデルからより多くのコードが生み出されるとエンジニアのレビュー負荷が増大し、過剰編集はそのことを難しくします。解析すべき複雑な論理が増え、読み込むコード行数が増え、全体的なコードベースの品質が静かに低下する確率が上がります。

過剰編集の評価方法

過剰編集を研究するためには、ある程度の「最小性（minimality）」を持つ、「真実値（ground truth）」の編集が明確に定義されたコードエディットのデータセットが必要です。既存のベンチマークで行われている別の LLM を使ってバグを導入するというアプローチをとるのではなく、BigCodeBench から 400 の問題をプログラム的に破損させることで、より細粒度な制御を得られます：比較演算子を反転（

→

<=

）、

と

を入れ替えたり、ブール値を変更（

True

→

False

）したりするなどの処理です¹。各破損サンプルは構文的に有効であり、対応するテストケースを確実に破損させることを検証しています。これにより、真実値の編集は単なる破損の逆転であり何ら追加ものではないため、この編集は構築上として最小のものとなります。こうして、モデルがバグを修正したかどうかだけでなく、その過程で他にどの程度変更を加えたかを評価できます。

指標

多くのコーディングベンチマークは Pass@1 のあるバリエーションを用いて正しさをモデルで評価します。しかし、Pass@1 は必要ですが十分ではありません。モデルは Pass@1 で完璧なスコアを出しながら、触れたすべての関数を完全に書き換えることができます。この実験では、モデルが必要以上にどの程度変更したかを捉える指標が必要です。

トークンレベルの Levenshtein 距離通常の Levenshtein 距離が一つの文字列を他の文字列へ変形するために必要な文字挿入、削除、置換の最小数を数えるのに対し、ここでは Python のトークン化バリエーションを使用します。コードはまず Python のトークナイザーを通し、原子的な構文単位（
```
def
```
,
```
add
```
,
```
(
```
,
```
a
```
,
```
,
```
,
```
b
```
,
```
)
```
,
```
:
```
,
```
return
```
,
```
+
```
など）に分割されます。Levenshtein 距離はこのトークンシーケンス上で計算され、生字符レベルではなく行われます。例として、以下の 2 つの関数を考えます：
```
def add(a, b):
    return a + b

def someotherfunctionname(a, b):
    return a + b
```
文字レベルの Levenshtein は距離を 19 と与えます。トークンレベルの Levenshtein は
```
someotherfunctionname
```
が単一のトークンになるため距離を 1 と与えます。異なる長さの関数間でスコアを比較可能にするために、総トークン数で正規化します。

また、モデルの出力を真実値（ground truth）に単純に比較するのではなく、両方を破損した入力に対して比較します。$C$ を破損した解、$G$ を真実値、$M$ をモデルの出力としましょう。真の実在的な最小編集（単なる破損の逆転）は $D_{\text{true}} = d(G, C)$ であり、モデルの編集は $D_{\text{model}} = d(M, C)$ です。これにより相対パッチスコアが得られます：

$$S(M) = D_{\text{model}} - D_{\text{true}}$$

値がゼロに近いほど、モデルのパッチは真の最小修正に類似しています。直感的には、未破損の元の解を破損した解への最良の編集と解釈し、この最良パッチのスコアを計算し、それをモデルの出力と比較することができます。
**追加された認知複雑性（Added Cognitive Complexity）**認知複雑性（サイクルマティック複雑性の改善版）は、コードを理解する難易度を測ります。ネスティング（入れ子構造）、再帰、混合論理演算子、直感的でない制御フローをペナルティとします。例えば、分岐がない真っ直ぐなコード行よりも、ステートを保持する必要があるもの（
```
if
```
文、ループ、または
```
try/except
```
など）の方が読み取り難いです。例が下にあります：
```
def process(items):
    result = []
    for item in items:          # +1
        if item > 0:            # +2 (ネスティングペナルティ: ループ内で)
            if item % 2 == 0:   # +3 (ネスティングペナルティ: 二重に深い)
                result.append(item)
    return result
```
認知複雑性：6

私たちのすべての破損は値を変更するだけで構造を変えるものではないため、正しい修正は常に認知複雑性をゼロ追加する必要があります。モデルの出力で増加したあらゆるものは、依頼されずに導入されたもので不必要です。忠実な最小編集であればゼロであるべきオリジナルとの絶対差分を報告します。0 未満の値も望ましくありませんが、コードの不必要な単純化も好ましくないためです。

モデルは過剰編集しますか？

はい、最先端モデルでもそうしています。

モデル	Pass@1 ↑	正規化 Levenshtein ↓	追加認知複雑性 ↓	推論モード
GPT-5.4	0.723	0.395	2.313	はい
Claude Opus 4.6	0.912	0.060	0.200	はい
Gemini 3.1 Pro Preview	0.858	0.145	0.501	はい
GLM 5 High	0.859	0.099	0.320	はい
Qwen 3.6 Plus	0.858	0.145	0.048	はい
Kimi 2.5	0.835	0.151	0.770	はい
DeepSeek R1	0.820	0.232	0.673	はい
DeepSeek Chat V3.1	0.795	0.232	0.694	はい
GPT-5 High	0.713	0.438	3.832	はい
GPT-5.4 (非推論)	0.770	0.327	1.563	いいえ
Claude Opus 4.6 (非推論)	0.900	0.079	0.313	いいえ
Gemini 3.1 Pro Preview (非推論)	0.860	0.129	0.358	いいえ
GLM 5 (非推論)	0.840	0.097	0.235	いいえ
Qwen 3.6 Plus (非推論)	0.870	0.106	0.605	いいえ
Kimi 2.5 (非推論)	0.770	0.140	0.687	いいえ
DeepSeek V3 (非推論)	0.800	0.201	0.803	いいえ

表 1: 推論および非推論モデルのパフォーマンス比較。両方に登場するモデルはハイブリッドモデルです。各指標での最高スコアは太字で強調されています。

最新最先端モデルの間では、GPT-5.4 が最も過剰編集を行います。推論モードでは Levenshtein 距離が 0.39 で非推論では 0.33、追加認知複雑性がそれぞれ 2.31 と 1.56 です。にもかかわらずその Pass@1 は 0.723 と 0.770 であり、最弱の正しさパフォーマンスのモデルの一つでもあります。Claude Opus 4.6 は評価されたすべてのモデルで最高の Pass@1（推論で 0.912、非推論で 0.900）を達成し、Levenshtein 距離が 0.06 と 0.08 の最小の差分と、追加認知複雑性が 0.20 と 0.31 をもたらします。Gemini 3.1 Pro Preview は同様の領域にあり、GLM 5 はオープンウェイトモデルの中で最も保守的なモデルとして議論されています。

プロンプト化は役立ちますか？

新しい LLM の故障モードを開発すると主張する多くの論文は、最初にモデルが直接指示された場合のタスク実行能力をテストしていません。一つの設定では不可能に見える振る舞いが、明示的なプロンプトの下では簡単になる可能性があります。そのため、「IMPORTANT: できるだけ元のコードとその論理を保証すること」（重要：元のコードとその論理を可能な限り維持してください）を追加するプロンプトの影響を調査しました。

図 2: モデルが明示的に編集を最小限に保つよう促された場合の Pass@1 と Levenshtein 距離の変化。モデルは推論モードによって色分けされています。

明示的なプロンプト化により、すべてのモデルが改善し Levenshtein 距離を減少させます。DeepSeek R1/v3 を除き Pass@1 も改善します。一つの解釈として、最小限の編集という制約が結果的に可能となる修正の探索空間を狭め、より正確でターゲット指向の変更へモデルを誘導することに繋がります。Levenshtein 距離への影響は推論モデルにおいて顕著であり、これはおそらく強力な指示追従能力の結果です。

推論＝過考慮と過剰編集を意味しますか？

推論モデルは一般的にコーディングタスクにおいて優れていると考えられており、Pass@1 でも高スコアを得ます。しかし、これらの編集のスタイルに興味があるため、異なる視点から結果を検討する必要があります。

図 3: 推論および非推論モデルの Levenshtein 距離比較。モデルは家族ごとに一つの推論モデルと一つの子推論モデルのペアにグループ化されています。低い棒の方が良いです。各ペアの上のラベルは両方のモデルが正解を得た問題数を示しています。

図 3 では、各ペアに同じファミリーからの推論モデルと非推論モデルを含まるようにモデルをグループ化しています。各ペアについて、両方のモデルが正解を得たサンプルのみの Levenshtein 距離をプロットします。これにより、モデルが失敗する頻度が多い（過剰編集すべきサンプルが少ない）場合バイアスがかかることなどを分離し、編集最小性と正しさを分離することができます。

一般的な設定（上部）では、推論モデルは大多数のペアで非推論対応よりも過剰編集を行います。DeepSeek V3、GPT-5、GPT-5.4、Gemini 3.1 Pro Preview、Qwen 3.6 Plus、Kimi 2.5 はすべて推論棒が高いことを示します。推論モデルは自然により詳細な書き換えを行い、モデルが推論を通じて「より良い」実装へと至るのではなく最小限の修正へと達します。顕著な例外は Claude Opus 4.6 で、その非推論対応よりも大幅に少ない編集を行います。

明示的な設定（下部）では状況が大きく変わります。モデルが元のコードを保存するよう告げられると、推論モデルは非推論対応よりもずっと低い Levenshtein 距離を持ち、ほぼすべてのペアでそれらと一致または上回ります。Claude Opus 4.6（推論版）はこの設定で最低の Levenshtein 距離に低下します。GPT-5 と GPT-5.4 の両方とも推論バリエーションが大幅に低下しますが、GPT-5.4 の非推論モデルもわずかに優勢です。

したがって、要点としては、多くの推論モデルのデフォルト動作は過剰編集を行うことです。制限されていない場合、拡張された推論によりモデルには「改善」する必要があるコードに対してより多くの余地が与えられます。しかし、その同じ推論能力は、指示が与えられた際にそれらをより忠実に追うようにもさせます。一般的な設定と明示的な設定の間のギャップは常に推論モデルで大きくあり、過剰編集は根本的な制限ではなく、オーバーライド可能なデフォルト動作であることを示唆しています。

学習（トレーニング）

次の自然な質問：モデルをより忠実な編集者として訓練することはできるか？この実験では、Qwen3 4B 2507 Instruct を基盤モデルとして開始します。明示的な指示で元のコードを保存するだけでなく、0-shot と 8-shot プロンプティングを両方使用して基準を設定します。すべての他のメソッドは評価時に明示的な指示なしで一般的な設定でプロンプト化されます。

セットアップ

まず、前述のアプローチと同じ方法を使用して DeepCoder から破損された問題の合成データセットを作成します。このプログラム生成されたデータセットに加えて、基盤モデル Qwen3 4B 2507 Instruct も使用して自己蒸留を通じて合成データセットも作成します。具体的には、問題ごとに 8 つの完了を生成するようにモデルに促し、機能的に正しいサンプルのみを保持し、Levenshtein 距離でランク付けします。その後、明示的な指示なしでコンテキスト蒸留のようにトレーニングします。

4 つの違いする方法を評価します：

SFT（教師あり微調整）： プログラム的に生成されたデータセットに対して直接教師あり微調整を行います。
rSFT（棄却サンプリング SFT）： 自己蒸留データセットから各サンプルで最低 Levenshtein 距離の 3 つの完了を使用してトレーニングする棄却サンプリング SFT です。
DPO（直接最適化）： 自己蒸留データセットから各サンプルについて最高と最低 Levenshtein 距離の完了間の優先度最適化です。

RL（強化学習）： 機能的正しさと Levenshtein ベースの編集最小性を組み合わせた報酬を持つ強化学習です。報酬構造は Levenshtein 距離の加重和とテストケースを通過しないためのペナルティの合計です：

r = r_edit + 0.1   # 生成がすべてのテストケースを通過する場合
r = -0.2           # それ以外の場合

# r_edit は正規化された Levenshtein ベースの報酬

それは機能しますか？

モデル	Pass@1 ↑	正規化 Levenshtein ↓	追加 CC ↓
ベンチマーク (0-shot)	0.735	0.169	0.731
ベンチマーク (8-shot)	0.775	0.115	0.479
SFT	0.932	0.002	0.000
rSFT	0.782	0.100	0.435
DPO	0.752	0.021	0.113
RL	0.802	0.046	0.112

表 2: ドメイン内のデータにトレーニングされたさまざまな微調整方法のパフォーマンス比較：トレーニングセットとテストセットは同じ破損タイプを持っています。

最初の試みでは、SFT が疑わしすぎるほど良い結果であり、生成されたモデルが完全にタスクを学習したように見えます。これは非常に驚きで、この一連の破損に対して単に逆転を暗記しているだけではなく、一般的な最小編集動作を学習するのではなく、モデルがただ逆転を暗記していただけだと最初の仮説を持っていました。その結果、合成データセットを両方再作成しましたが、評価セットとは完全に異なる破損タイプを使用して汎化を検証するために使用しました。コアの仮説は、モデルが単に特定の一連の破損を逆転することを学習しているだけだということです。

それは汎化するでしょうか？

モデル	Pass@1 ↑	正規化 Levenshtein ↓	追加 CC ↓	LiveCodeBench の変化 ↓
ベンチマーク (0-shot)	0.735	0.169	0.731	—
ベンチマーク (8-shot)	0.775	0.115	0.479	—
SFT	0.458	-0.008	0.006	-0.149
rSFT	0.780	0.107	0.501	-0.069
DPO	0.787	0.092	0.348	-0.046
RL	0.782	0.050	0.185	+0.006

表 3: ドメイン外のデータにトレーニングされたさまざまな微調整方法のパフォーマンス比較：トレーニングセットとテストセットは異なる破損タイプを持っています。

SFT はドメイン外で完全に崩壊します。Pass@1 は 0.458 に低下し、モデルが何かを修正するかに関わらず特定の最小変化を生むことを学習したためです。rSFT と DPO の両方がより良いですが、8-shot ベンチマークと比較して全体的な改善はわずかであります。これは、基盤モデル自体から蒸留された痕跡のトレーニングが汎化の一定レベルを誘発するのに十分なことを示しています。RL はのみ一貫して汎化する手法であり、すべてのベンチマークで 3 つの指標を改善します。RL モデルが Levenshtein 距離と追加認知複雑性での改善が Pass@1 よりも大きいことは、単に破損の逆転を暗記しているのではなく、実際に最小編集へ汎化していることをさらに証拠として示しています。

SFT モデルがバグさえ修正できないため、 Catastrophic Forgetting（過酷な忘却）についても見ることも望みました。具体的には、最小編集のための微調整が一般的なコーディング能力を劣化させるかどうかです。すべての微調整されたモデルを LiveCodeBench v6 で評価し、元のアダプト済みモデルと比較します。理想的にはトレーニング後にパフォーマンスは似ているべきです。

SFT は 43% のパフォーマンス低下を示しており、基本的なバグを識別して修正できなくなるという私たちの以前の発見と一致します。rSFT と DPO モデルはわずかな劣化を経験し、元のモデルによって生成されたサンプルでトレーニングされていたにもかかわらず、タスクの性質が依然としてある程度の Catastrophic Forgetting を引き起こすことを示しています。RL モデルはどのような低下も経験しません。さらにそれが最高のパフォーマンスを出すという事実と組み合わせて、RL は以前獲得した能力を劣化させずにモデルに新しい動作を教えることが可能です。これは SFT が暗記し RL が汎化する広いワークを示すことと一致します。

他のワークで示されている RL の KL 最小化ソリューションへのバイアスにより忘却が減少することから、これらの結果を分布の視点から解釈できます。具体的には、プログラム的に生成されたデータセットの分布はモデルの元の分布とは非常に異なっています。その結果、SFT モデルの分布は大きく修正され、したがって Catastrophic Forgetting を被ります。対照的に、rSFT と DPO の両方の場合、自己蒸留データセットの分布はより整合しており、したがってトレーニングされたモデルの分布を形成する際により少しくわしい性質を持っています。したがって、Catastrophic Forgetting の程度は、モデルの元の分布とタスクトレーニングデータの分布との差に比例している可能性が高いです。

追加実験：LoRA を使用した RL

フルな微調整は必要でしょうか？ このタスクは新しい知識を教えることよりも、既存のタスクにおけるスタイルを調整することに少しかかるため、LoRA が十分かどうかも探りました。基盤モデルには既にコードを編集してバグを修正する能力があるため、フルな微調整は必要でない可能性があります。

ランク	Pass@1 ↑	正規化 Levenshtein ↓	追加 CC ↓	LiveCodeBench Δ ↑
1	0.738	0.166	0.676	-0.022
8	0.775	0.112	0.426	-0.022
16	0.805	0.087	0.328	-0.005
32	0.795	0.065	0.235	-0.011
64	0.797	0.051	0.160	+0.001
フル RL (最良)	0.802	0.050	0.185	+0.006

表 4: さまざまな LoRA ランクのパフォーマンス比較。

結果は仮説を支持します。ランク 64 の LoRA は Levenshtein 距離でフル RL にほぼ匹敵し、追加認知複雑性ではそれを上回ります。LiveCodeBench は低いランクでわずかに低下しますが、ランク 64 では実質的に平坦であり、フル RL が全体的に最良です。両方の Levenshtein と追加 CC はランク 1 からランク 64 まで steadily 減少する明確な単調な傾向があります。ただし、改善率は均一ではなく、最大の利得は早期に発生します。ランク 1 から 16 が Levenshtein の大部分の減少（0.166 → 0.087）を担当し、ランク 16 から 64 は残りのギャップをより段階的に閉じます（0.087 → 0.051）。ランク 1 と 8 も正しさを編集最小性と交換しますが、これは十分な容量で両方の報酬関数を学習できないことで説明できます。

これは、追加の少数のパラメータだけでモデルの編集動作を変更でき、ある点を超えた容量は減少するリターンをもたらすという考えに一致します。背後にある能力が既に存在するスタイルレベルの行動変化については、LoRA が十分に十分で実行のコストも大幅に安いです。

報酬ハッキングに関する注意

元の報酬関数のバージョンには、ロールアウトで実行に成功しなかったものはハードコードされた報酬 0 を得ていたバグがありました。Levenshtein 距離を否定して「高い方が良い」ようにするためでした。これは、実行に成功したロールアウトよりも高い報酬になった結果です。この buggy な報酬関数であっても、フル RL が依然としてタスクを学習できたことが興味深かったです。LoRA のみでモデルは学習に失敗し、明らかに機能正しいコードを出力するのを学んで報酬ハッキングを行い、環境への調査を促しました。修正された報酬関数では、フル RL の結果はわずかにのみ改善されました。

スケールはどうですか？

最後に、より大きなモデルで結果を検証するために、同じ RL レシピをアウト・オブ・ドメインのデータを使用して Qwen3 14B より大きなモデルに適用します。パラメータ数が増えたとしても、Pass@1 の高さ、Levenshtein 距離の低下、追加認知複雑性の低下、Catastrophic Forgetting の兆候なしに全方向でパフォーマンス向上があります。これは、最小コード編集タスクのためのこのようなレ시피が、さまざまな規模のモデルにも拡張できることを自信にさせてくれます。

モデル	Pass@1 ↑	正規化 Levenshtein ↓	追加 CC ↓	LiveCodeBench Δ ↑
ベンチマーク：14B	0.770	0.136	0.315	—
RL	0.833	0.059	0.165	+0.011

表 5: Qwen3 14B でトレーニングされた RL のパフォーマンス比較。

最終的な考察

GPT 5.4 と Opus 4.6 に関する注意

最先端モデルでありながら、過剰編集タスクで苦戦しており、特に一般的な設定と Opus 4.6 に対してであることが注目されます。図 3 では、明示的に推論モードで促された際に最大の利得の一つを見せ、その前の GPT 5 に次いでおり、強力な指示追従能力を示唆しています。対照的に、Opus 4.6 は最も小さい改善の一つを示しますが、それは単にすでに強力なベースラインパフォーマンスを反映している可能性があります。このパターンは、GPT 5.4 が往々にして過剰に長大なコード（「スlop」）をデフォルトにする一方、適切なプロンプティングで効果的に誘導できるという広い見方に一致します。

まとめると、結果は過剰編集が広く測定可能であることを示唆しています。同時に、プロンプティングの結果はこれが純粋な能力の制限ではないことを示します。特に推論モデルにとって、元のコードを保存するという単純な指示はるかに忠実な編集につながり、GPT 5.4 が過剰編集する際でも、より高品質なコードへと誘導できることを示す良い兆候です。

さらに、トレーニングの結果はこの動作が改善できることを示唆します。強化学習は一般的なコーディング能力の低下なしにより忠実な編集者を生み出し、その利得は 4B と 14B の両方の Qwen3 モデルで維持されました。

admittedly、コードベンチマークの分野は単純な単一関数評価から SWE-Bench Pro などのよりエージェント的な評価パラダイムへと進みました。それらと比較して、バグ修正の評価を孤立した関数で行うことは、バグの本質から見てまだ比較的収束されたタスクです。

それでも、私の経験において、今日すべての最先端コーディングモデルを通じて過剰編集が蔓延しているにもかかわらず、現実的な設定で定量化するのは長い間困難でした。このワークはコーディングモデルの最小編集能力の評価と改善の第一歩として機能することを願います、そして Ultimately AI 生成コードの全体的な品質向上に貢献します。

謝辞

私の監督者 A/P Min-Yen Kan とアドバイザー Tongyao Zhu の指導、そして Prime Intellect がこのプロジェクトのコストと API コストをスポンサリングしてくださり感謝いたします。

過剰編集とは、必要以上のコード改変を行うモデルの動作を指します。

Japanese Translation: