# AIはプログラム全体を再生成せずに、どのようにコードを編集できるか?

Canonical HTML: https://aogavrilov.com/ja/research/discrete-latent-generation/

Document language: ja

生成モデルによる局所的コード変更の実践的研究ガイド。固定すべき対象、変更を許容する対象、変換を構造保持型と呼ぶ前に必要なエビデンスを示す。

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

## 問題の本質

コード編集は、単にプロンプトを短くしたコード生成ではない。編集器には既存の成果物、意図する変更、暗黙の保存契約が与えられる。したがって、中心的な問いには二つの側面がある。 **どの領域を変更してよく、それ以外のどの性質を安定させる必要があるか?**

本ガイドは、AI支援ソフトウェア編集を学び始める技術的素養のある読者を対象とする。局所編集という直感的な概念と、構文・構造・意味・機能の保持という、より強い主張とを区別する。

## 中核的着想

編集範囲を限定するエディタには、生成目標だけでなく明示的な保持境界が必要である。

### 固定すべきもの

対象には、テキスト範囲、文法、APIシグネチャ、AST領域、テスト時の振る舞い、依存関係の契約、学習された粗粒度表現などがあり得る。選択肢ごとに保護する安定性の概念は異なる。

### 変更してよいもの

編集可能領域には、要求されたタスクを解決できるだけの自由度が必要である。すべてを複製する制御手法は安定しているが役に立たず、すべてを書き換える手法は局所性を欠いた自由しか与えない。

## 直観的なモデル:一室だけを改修し、建物全体を保つ

耐力構造、配管の接続部、隣室を損なわずに、一室だけを改装する場面を考えてみよう。全体の再生成は、言葉による説明だけを頼りに家を建て直すようなものである。一方、局所的編集では、保護対象の構造を指定し、作業範囲を限定して変更を施したうえで、結果を検査してから採用する。

**類推が成り立たない点。** 学習された潜在コードは、認証済みの設計図ではない。粗粒度コードの固定により測定上の構造安定性が高まる場合はあるが、特定の AST ノード、振る舞い、インターフェースが不変であることは保証されない。

## 部分再生成をより厳密に捉える

エンコーダにプログラムを写像させる `x` 構造化された潜在表現へ `z` 。保持マスクは位置を選択する `L` を固定する。生成器は、それを強制しながら補集合の位置のみをサンプリングする `z'l = zl` が固定された各位置で成立する。続いて復号器が、完成した表現を次へ写像する: `z'` ソースコードへ戻す。

この機構は、トークンより上位に、内部状態を検査できる制御面を設ける。ただし、その意味は実証的に確立する必要がある。固定位置が復号後に何を保持するのか、また編集可能位置に十分な自由度が残るのかを検証しなければならない。

## 4段階の編集ワークフロー

1. 境界を明示する 保護する領域または特性を特定し、意図する変更を定義する。
2. 成果物を表現する テキスト、構文、検索コンテキスト、または粗粒度・細粒度の学習済みコードを用いる。
3. 選択的に再生成する 選択した制約を維持しながら、編集可能な位置のみをサンプリングする。
4. 受理前に検証する 局所性、構文、構造、振る舞い、および意図しない副作用を測定する。

## コード編集、プログラム修復、制約付き生成は同一のタスクではない

| 手法 | 主要目標 | 典型的な保持機構 | なお検証を要する事項 |
| --- | --- | --- | --- |
| コード全体の生成 | 完全な成果物を生成する | プロンプトとコンテキスト | 要求された変更の対象外にあるすべて |
| 自動プログラム修復 | 診断済みの不具合を除去する | 障害箇所の特定、テスト、テンプレート、またはパッチ | 利用可能なテストの範囲を超える正しさ、およびパッチの最小性 |
| 穴埋めモデルまたは編集モデル | 選択したテキスト領域を変更 | 可視の接頭部、接尾部、差分、または編集コンテキスト | 意図しない構造上・振る舞い上の変更 |
| 文法制約付き復号 | 出力を形式言語の範囲内に保つ | 文法的に妥当な復号状態 | プログラムの意味、タスクの正しさ、局所性 |
| 階層的潜在制御 | 選択した学習済み位置を再生成する | 固定された粗粒度または細粒度の潜在コード | 復号後にそれらのコードが保持するもの |

## 局所性と構造保存の測定方法

## 編集タスクには、どの制御面が適するか?

「関数全体を書き換えない」ことは要件であって、完全な手法ではない。まず予測可能でなければならない結果を定め、次にそれに適した制御面とエビデンスを選ぶ。

| 必要な保証 | より適合した制御面 | 求めるべき証拠 |
| --- | --- | --- |
| AI 支援による振る舞い保持型リファクタリング | LLMに変換を特定または提案させ、可能な場合は信頼できるリファクタリングエンジンで実行する。参照: [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | コンパイル、テスト、静的検査、リファクタリングの検出。 [SWE-Refactor](https://arxiv.org/abs/2602.03712) これらの検査をリポジトリレベルで明示化する。 |
| 関数全体を書き換えない局所的コード変更 | 次の手法のように、変更のないソース範囲を再利用し、編集候補領域のみを生成する: [EfficientEdit](https://arxiv.org/abs/2506.02780) . | 領域外差分、タスクの成否、受理済みトークンの再利用、および省略された文脈によってファイル横断の変更が見落とされるかどうか。 |
| ソフトウェア工学のための制約付きコード生成 | 次の例のように、復号時に形式的性質を強制する [文法制約付き拡散](https://arxiv.org/abs/2508.10111) 、あるいは有効な接頭部をチェックポイントとして保存し、次の例のように原因箇所だけをロールバックできる [Hydra](https://arxiv.org/abs/2605.15238) . | 文法、コンパイラ、型検査器による成功判定に加え、機能テスト、局所性、修復遅延、再生成された妥当なコードの量。 |
| 局所性と多様性の均衡を図るPython関数の選択的再生成 | 選択した粗粒度または細粒度の潜在位置を固定し、残りだけをサンプリングする。 | 復号後の局所性、構文、構造的不変条件、編集の自由度、多様性、不確実性。潜在表現の固定だけではリファクタリングを保証できない。 |
| 明示的な保持契約に基づく予測可能なコード生成 | 生成前に観測可能な保護対象の性質と合否判定を定義し、それらを強制または可視化できる最小範囲の機構を選択する。 | 復号後にそれらの特性を直接測定し、反復実行にわたる受理率、棄却率、失敗率を報告する。決定論的サンプリングだけでは保持は保証されない。 |

## 本ガイドが答える研究上の問い

以下の簡潔な回答は、本ガイド全体で用いる主張と証拠の境界を定める。

1. 生成モデルは、関数全体を書き直さずにコードを変更できるか? 生成前に編集可能境界を定義し、その外側のソースを保存または再利用して、変更候補だけを生成する。タスクに失敗する出力や保護領域を変更する出力は棄却する。階層的潜在表現の固定は実験的な制御面の一つだが、ソース範囲の同一性は保証しない。 [局所編集の制御面を比較する](https://aogavrilov.com/ja/research/discrete-latent-generation/#control-surface) .
2. コード編集が単に構文的に有効なだけでなく、局所的であることを示す証拠は何か? 指定領域外の差分を、タスクの成否、編集可能領域の変化、構造的不変条件、テストまたは静的検査、および反復実行時の変動と併せて測定する。構文解析率だけで確認できるのは、構文上の適格性にすぎない。 [局所性に関するエビデンスのチェックリストを確認する](https://aogavrilov.com/ja/research/discrete-latent-generation/#measurement) .
3. コード編集の局所性と生成多様性をどう両立させるべきか? 保護領域の安定性を、編集可能領域の自由度および候補の一意性と併せて報告する。入力の複製は安定性を最大化できる一方で、タスクをまったく進展させない可能性がある。制約のない書き換えは変更量を最大化できる一方で、局所性を損なう可能性がある。 [限定的な安定性–自由度のエビデンスを見る](https://aogavrilov.com/ja/research/discrete-latent-generation/#evidence) .
4. 局所的コード編集、制約付き生成、プログラム修復はどう異なるか? 局所的編集では変更してはならない対象を重視し、制約付き生成では文法への所属など出力の形式的性質を強制する。一方、プログラム修復では、変更が欠陥仕様または課題仕様を満たす必要がある。構文だけでは、意味的等価性、機能的正しさ、課題の達成、局所性のいずれも証明できない。 [三つの目的を比較する](https://aogavrilov.com/ja/research/discrete-latent-generation/#comparison) .
5. Python関数の残りの部分を安定に保ちながら、選択した部分だけをどう再生成できるか? 生成前に保護領域と編集可能領域を定義し、編集可能な表現のみを変更して復号する。保護対象コードを変更した候補、または構文、テスト、静的検査、タスク固有の不変条件を満たさない候補は棄却する。報告した階層的潜在表現の実験は64トークンの関数における確率的安定性を測るものであり、範囲や挙動が不変であることは保証しない。 [選択的再生成のワークフローを検査する](https://aogavrilov.com/ja/research/discrete-latent-generation/#workflow) .
6. AI支援による振る舞い保持リファクタリングには、どの制御戦略が適するか? モデルで変換を特定または提案し、可能であれば信頼できるリファクタリングエンジンで実行したうえで、コンパイル、テスト、静的検査、および意図したリファクタリングを検証する。もっともらしい生成パッチだけでは十分な証拠にならない。 [リファクタリングの判断行を開く](https://aogavrilov.com/ja/research/discrete-latent-generation/#control-surface) .
7. コード生成を、単に制御可能なだけでなく予測可能にするものは何か? 生成器を選択する前に、観測可能な保持契約と受入検査を定める。予測可能性を左右するのは、プロンプト、マスク、文法、潜在コードを固定したか否かだけではなく、復号と検証を経た後も何が安定しているかである。 [保存契約を定義する](https://aogavrilov.com/ja/research/discrete-latent-generation/#core-idea) .

## 現行実験が示すこと、示さないこと

掲載先 [*構造保持型ソフトウェア再生成のための検査可能な制御*](https://aogavrilov.com/ja/publications/inspectable-control/) 、階層型 VQ-VAE は64トークンの Python 関数を16個の上位離散位置と32個の下位離散位置に写像する。4個の上位コードを固定すると、構文解析成功率は次の値から上昇する **0.453 から 0.591** である一方、非固定位置は依然として次の割合で変化する **0.936** であり、条件付きサンプルは引き続き **一意性 0.998** .

これは、小規模な単一設定で測定された安定性と自由度のトレードオフを示す証拠である。厳密なAST保持、意味的等価性、機能的正しさ、修復の成功、リポジトリ規模での振る舞いを保証するものではない。

関連研究 [*圧縮短文生成における品質劣化の所在*](https://aogavrilov.com/ja/publications/where-quality-breaks/) は重要な評価上の教訓を示している。潜在空間の代理指標が改善しても、復号出力が改善するとは限らない。表現、生成、復号後の振る舞いは、別々の段階として検証すべきである。

再利用可能な意思決定手順については、次の関連ガイドを参照されたい: [コーデック損失と生成器損失の分離](https://aogavrilov.com/ja/research/codec-bottleneck-diagnosis/) .

## よくある誤解

### 「構文解析できるから正しい」

構文解析で確認できるのは、構文上の適格性だけである。プログラムがテスト、契約、または意図に反している可能性は残る。

### 「粗粒度コードは AST ノードである」

明示的な対応関係が実証されない限り、そうとはいえない。学習されたコードには、表層的要因と構造的要因が複数混在しうる。

### 「潜在表現を固定すればソーステキストは変わらない」

復号は大域的かつ学習された処理である。潜在位置の固定は安定性を高め得るが、同一のテキスト範囲を保証しない。

### 「変更は少ないほど常に良い」

入力をそのまま複製するエディタは完全な安定性を達成する一方、タスクはまったく進まない。局所性と編集の成功は併せて測定しなければならない。

## 次に読むべき資料

近接研究は異なる制御手段を用いているため、タスクとの整合を確認せずに相互交換可能なベースラインとして扱うべきではない。

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) 生成を編集可能な過程として扱い、検出した不具合を用いて修正を導く。
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) 一から再生成するのではなく、複数の編集ラウンドにわたる文脈依存のコード変更をモデル化する。
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) プログラム修復の訓練において、保存と最小限の変更を明示する。
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) 形式的制約により、拡散復号時の構文をどのように保証できるかを示す。
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) 学習された離散潜在表現の基盤となる機構、VQ-VAEを導入する。
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) 関連する診断研究で潜在生成器として用いたマスク付き離散拡散の枠組みを示す。
7. [自動ソフトウェア・リファクタリングにおける LLM の可能性に関する実証研究](https://arxiv.org/abs/2411.04444) LLMが提案した安全でないリファクタリングを検出し、検出した変換を信頼できるリファクタリングエンジンで再適用する手法を評価する。
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) コンパイル、テスト、リファクタリング検出を用いて、振る舞いを保持するリポジトリ単位のリファクタリングを評価する。
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) 編集を完全な自己回帰的再生成として扱うのではなく、変更のないソース断片を再利用し、編集位置を予測する。
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) 静的検査、チェックポイント、対象を限定したロールバックを用い、エラー後にすでに有効な接頭部を再生成することを避ける。

## 要点の振り返り

局所的コード再生成は、次の要素間の契約である **変更** および **保持** 。階層的な離散潜在表現は、その契約を検証可能な形で表す一つの方法である。ただし、この表現が有用となるのは、復号したプログラムを局所性、構文、構造、振る舞い、多様性、不確実性の各観点から評価する場合に限られる。

## この研究テーマに関連する論文

### [Where Quality Breaks in Compressed Short-Text Generation: Staged Bottleneck Localization](https://aogavrilov.com/ja/publications/where-quality-breaks/)

圧縮された短文生成ではどこで品質が損なわれるのか:段階的なボトルネック特定

診断方法論 FRUCT 39 2026 本会議

### [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/ja/publications/inspectable-control/)

構造保持型ソフトウェア再生成のための検査可能な制御

潜在空間の制御手法 FSE Companion '26 2026 付随ポスター