# 生成モデルによる局所的コード変更

Canonical HTML: https://aogavrilov.com/ja/research-notes/localized-code-modification-generative-models/

Document language: ja

研究ノート

生成モデルが要求されたコード変更を行うのに十分な自由度を確保しつつ、不要な関数全体の書き換えを防ぐ方法。

公開済み 2026年7月30日 [Alexey Gavrilov](https://aogavrilov.com/about/)

端的な回答

## 生成モデルは、関数全体を書き直さずにコードを変更できるか?

生成前に保護領域と編集可能領域を定義し、保護対象の表現を再利用または制約して、変更候補だけを生成する。保護対象コードを変更した出力や、タスク固有の検査に不合格となる出力は棄却する。局所性とタスク成功は併せて測定しなければならない。

## 区別が重要である理由

手法と主張する保証には、同一の観測可能な境界が必要である。

局所的なコード変更は編集の問題であり、コード生成用のプロンプトを短くしただけのものではない。入力にはすでに保持すべき成果物が含まれるため、変更を許す領域と、安定して保持すべき性質との境界を明示する必要がある。

境界には、ソースコードの範囲、構文ノード、APIシグネチャ、テスト時の振る舞い、依存関係の契約、または学習された潜在位置を選びうる。これらは相互に置換できない。それぞれが異なる観測可能な特性を保護し、対応する検証手順を必要とする。

## 実践的な手順

1. 保持契約を明示する 編集可能領域と、変更してはならないテキスト、構造、インターフェース、または振る舞いを厳密に特定する。
2. 有用性を満たす最小範囲の制御面を選択する 変更のないソース範囲を再利用し、補完または編集指向の復号を用い、形式的制約を適用するか、必要な特性に応じて選択した潜在位置を固定する。
3. 変更が許可された箇所のみを生成する 課題を解決できるだけの自由度を編集可能領域内に確保する。入力全体の複製は局所的ではあるが、何の進展ももたらさない。
4. 局所性と成功を併せて検証する 保護領域を変更する候補、構文解析またはコンパイルに失敗する候補、構造的不変条件に違反する候補、あるいは要求された変更を満たさない候補を棄却する。

## 必須とすべき証拠

主張の強さは、生成または復号後に測定した性質によってのみ裏付けられる。

- 領域外差分、または保護領域の安定性を直接測る別の指標。
- 編集可能領域内でのタスク成功。
- 必要に応じた構文解析、コンパイル、テスト、静的検査、またはタスク固有の不変条件。
- コピーを制御と誤認しないための、編集可能領域における変更率。
- 局所性をモード崩壊と取り違えないよう、候補の一意性と反復実行時の変動を評価する。

### リンク先の研究が報告する内容

- リンク先の実験では、64トークンのPython関数を階層的な離散位置へ圧縮し、部分制約下で選択した潜在位置を再生成する。
- 上位コード4個を固定すると、構文解析成功率は0.453から0.591へ向上し、非固定位置は0.936の割合で変化し、条件付きサンプルの一意率は0.998を維持した。
- これらの測定は、トークンより上位における安定性と自由度のトレードオフを明らかにするが、ソース範囲、AST、意味、振る舞いの厳密な保持を証明するものではない。

[出版物の概要を読む](https://aogavrilov.com/ja/publications/inspectable-control/) [論文全文を検索](https://aogavrilov.com/publications/inspectable-control/full-text/)

## 対象範囲の境界

- 固定された潜在コードが、自動的に AST ノード、保護されたソース範囲、形式的不変条件になるわけではない。
- 構文解析率が示すのは構文上の適格性であり、機能的な正しさや修復の成功ではない。
- 報告されたエビデンスは前処理済みの短いPython関数に由来し、リポジトリ規模での挙動を確立するものではない。

## 主要文献と近接文献

原手法、測定結果、明記された制約については、リンク先の論文を参照されたい。

1. [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/ja/publications/inspectable-control/) 主要論文および階層的潜在表現を用いた境界付き実験。
2. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) 変更されないソース領域を再利用する編集指向の復号。
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) プログラム修復の訓練において、保存と最小限の変更を明示する。

管理者 Alexey Gavrilov 。本ページは既存のエビデンスを要約したものであり、引用文献を超える実験結果は追加していない。