GPT-4やClaudeのような自己回帰型の巨大モデルは、ファイルを左から右へとトークンごとに生成していきます。短いスニペットなら得意ですが、開発者が大規模なコードベースの奥深くにある行を編集しようとすると、つまずいてしまいます。モデルは後続のすべてのトークンを再評価しなければならず、ファイル全体の整合性を保つことが困難になります。

拡散モデルは、ランダムなトークンの塊から始まり、一貫性のあるプログラムが現れるまで反復的にデノイズ（ノイズ除去）を行います。洗練のプロセスがシーケンス全体に同時に作用するため、モデルは末尾を再計算することなく、コードのどの部分でも挿入、削除、または書き換えを行うことができます。

なぜ現在のパラダイムはソフトウェアエンジニアリングにおいて苦戦しているのか

自己回帰はモデルにコードを線形ストリームとして扱うことを強いるため、以下の問題が生じます。

  • 過去のみを見る。 未来のトークンを見ることができないため、変更が後の行にどのように影響するかを予測できません。
  • 後続のテキストを再計算する。 一度の編集が新しい予測の連鎖を引き起こし、リファクタリングやバグ修正の際のレイテンシを増大させます。
  • 長距離のエラーが蓄積する。 初期の不一致が雪だるま式に増え、最終的なファイルが構文的に壊れたり、論理的に矛盾したりします。

関数の本体をファイルの中間に挿入したり、APIのシグネチャを更新したりといったインフィル（穴埋め）が必要な場合、自己回帰モデルの逐次的な性質は扱いにくく、エラーが発生しやすくなります。

拡散モデルという選択肢：ステップバイステップの予測ではなく、反復的な洗練

コードファイルをノイズの混じった信号として扱います。生成は以下の数ラウンドで行われます。

  1. 純粋なノイズで初期化。 特殊なプレースホルダーで表されることが多い、ランダムなトークンのシーケンスをモデルに投入します。
  2. 段階的なデノイズ。 各ステップでモデルは、トークンを妥当なコードへと近づけるように、わずかにクリーンなバージョンを予測します。
  3. 完成したプログラムへの収束。 一定のステップを経てノイズが消え、完全に形成されたスニペットが残ります。

各ステップでシーケンス全体を再検討するため、モデルはどの段階でも任意のトークンを微調整できます。このグローバルな視点により、不足しているインポートの追加、変数の名前変更、ブロックのインデント調整などを、それ以降のすべてを再生成することなく行うことが可能になります。

コードに特化した拡散モデルの設計

拡散モデルを画像からテキストへと移植するのは、単純な作業ではありません。3つの技術的な転換が重要になります。

1. 離散拡散

画像のピクセルは分数的なノイズを受け入れますが、コードのトークンはカテゴリカル（離散的）です。つまり、特定のキーワード、識別子、または記号のいずれかです。そのため、シーケンスが実質的にランダムになるまで、トークンを中立的なプレースホルダー（多くの場合 [MASK]）で繰り返し置き換えるマルコフ連鎖を使用します。逆プロセスでは、元のトークンをステップバイステップでどのように復元するかを学習します。

2. 構造的な認識

プログラミング言語は厳格な構文規則を課しています。Pythonではインデントがスコープを定義し、Cスタイルの言語では中括弧がブロックを区切ります。また、変数は使用前に宣言されている必要があります。コードを単なるテキストとして扱う拡散モデルは、構文的に無効な出力を生成してしまいます。これを防ぐため、研究者はトークン間のアテンション（注意）の仕方を制限する「構文認識アテンションマスク」を追加し、モデルが階層、ネスト、および言語固有の制約を尊重するように強制します。

3. 階層的な洗練

拡散の初期ステップでは、関数のシグネチャ、クラス定義、モジュールの構成といった大まかな構造をスケッチします。後のステップでは、句読点、空白、命名規則などの細かい詳細を磨き上げます。この「粗いものから細かいものへ（coarse-to-fine）」という戦略は、人間が内部を磨き上げる前にプログラムの概要を作成するプロセスを反映しており、各段階で最も重要な部分に計算リソースを集中させることができます。

自己回帰 vs. 拡散：比較

側面 自己回帰型 拡散型
生成フロー 逐次的、左から右へ 並列的、反復的なデノイズ
グローバルな整合性 長い実行においてドリフトしやすい 全トークンにわたる全体的な視点
典型的なユースケース チャット、解説、短いスニペット リファクタリング、バグ修正、大規模なコード合成

この表は、なぜそれぞれのパラダイムが異なる文脈で力を発揮するのかを示しています。速度や対話的なやり取りが重要な場合は、自己回帰モデルが優れています。一方で、計算コストがかかったとしても、最終的な成果物が構文的に正しく、構造的に一貫している必要がある場合は、拡散モデルが優れています。

次に注目すべきこと

  • ハイブリッド・パイプライン. 将来のシステムでは、自己回帰モデルが素早く初稿を作成し、それを拡散モデルに渡してブラッシュアップさせるという手法が可能になるかもしれません。
  • 構造的マスクのためのツール. 研究者は、拡散モデルが言語固有の制約を遵守できるよう、構文を意識したアテンション・マスクの改良を続けています。

まとめ

拡散モデルは、コード生成の常識を覆します。トークンを一つずつ生成していくのではなく、反復的なデノイジングを通じてプログラム全体を形作っていくのです。このアプローチは、自己回帰システムの核心的な弱点、すなわち大規模で変更可能なコードベースにおけるグローバルな一貫性の維持という問題に対処します。速度や計算負荷の面では劣るものの、拡散モデルは、リファクタリングやバグ修正、あるいは単なる処理速度よりも、クリーンで構文的に正しい出力が重視されるあらゆるシナリオにおいて、非常に強力なツールとなります。最も有望な進むべき道は、自己回帰モデルの素早いドラフト作成能力と、拡散モデルの全体的なブラッシュアップ能力を組み合わせた、ハイブリッドなワークフローであると考えられます。