リファクタリングの修正漏れを防ぐ VS Codeの編集提案機能「NES」拡張：不要な提案を強化学習で抑制 より実用的に？

Visual Studio Code向け「GitHub Copilot」の編集提案機能「Next Edit Suggestions」が拡張された。リファクタリング時などの修正漏れを未然に防ぐことが可能になるという。

[＠IT]

　Microsoftは2026年2月26日（米国時間）、「Visual Studio Code」（以下、VS Code）向け「GitHub Copilot」の編集提案機能「NES」（Next Edit Suggestions）を拡張した。

　新たに提供が開始された、ファイル全体を対象とする「長距離NES」（long-distance NES）により、予測範囲がファイル全体へと広がり、リファクタリング時の修正漏れなどを未然に防げるようになるという。

ファイル内の離れた場所で編集を提案する「長距離NES」の動作イメージ（提供：Microsoft）

リファクタリング時に直面　従来の編集提案機能の課題

　典型的なリファクタリング作業の場合、関数名を変更すると同じファイル内の全ての呼び出し箇所も更新が必要になり、パラメーターの型を変更すれば200行離れた検証ロジックも修正が必要になることがある。従来のNESは有効範囲が狭く、こうした離れた編集箇所には対応できなかった。

　Microsoftがこの問題を解決するには、検索範囲をカーソル付近の数行からファイル全体に拡大する必要があり、モデリング上の困難が伴っていた。さらに、正確なジャンプは作業効率を上げる一方、不要なジャンプは作業の流れを中断させ、次の提案に対する信頼を損なう。「どこに移動するか」だけでなく「いつ移動しないか」もシステムに学習させる必要があった。

長距離NESの開発方法

マルチモデルアプローチ

　そこでMicrosoftは、既存の編集生成モデルを修正するのではなく、マルチモデルアプローチを採用した。次の編集がどこで発生すべきかを予測する専用の「位置モデル」をトレーニングし、有効な位置が選択された後、従来のNESモデルが編集提案を生成する仕組みだ。

　この分離には2つの利点がある。

• 役割分担によるモデル性能の最適化
• 位置モデルは、「どこにジャンプするか」という空間的な意図を学習し、NESモデルはローカルウィンドウ内で編集内容を生成する。各モデルが特定のタスクに集中できるため、編集提案の精度向上が期待できる

• 位置予測の独立性
  • 位置予測と編集生成を分離したことで、位置モデルを独立して改善できる。これにより、コアNESモデルへの継続的な改善を中断することなく、機能拡張が可能になる

位置予測と編集生成を分けたマルチモデルアプローチの仕組み（提供：Microsoft）

編集ジャンプの評価フレームワークの設計

　Microsoftは、位置モデルのトレーニングに先立ち、3段階の構造化された評価プロセスを設計した。実際の編集シナリオで機能するかどうかを測定するためだ。

• 一般的なマルチ編集ワークフローの特定
• 代表的なカーソルジャンプ例の構築
• ジャンプ精度と非ジャンプ精度の両方を測定

　開発者が編集履歴を分析したところ、名前変更やシグネチャ変更、ドキュメント更新などの操作では、編集がファイル内の複数の隣接していない場所に波及するケースが多いことが分かった。

　「重要なのは、ジャンプ精度と非ジャンプ（ジャンプしない判断）の精度の両方を測定した点だ。多くの例では新しい位置の予測が必要だったが、現在の行にとどまることが正解となる例も相当数あった。頻繁にジャンプし過ぎるモデルは、重要な遷移を見逃すモデルと同様に作業を妨げる可能性がある」（Microsoft）

教師ありファインチューニングによるトレーニング

　位置モデルのトレーニングには、ターゲットを絞ったハイパーパラメーター検索による教師ありファインチューニング（SFT）を使用した。既存のNESモデルで実績のある値をベースに、構造化グリッド検索を実行することで、効率的に組み合わせを探索し、高性能な構成を特定した。

UI設計

　モデルが優れていても、提案に気付かなかったり信頼しなかったりすれば意味がない。標準NESでは提案がカーソル付近の変更を扱うため自然に発見できたが、長距離NESでは視界の外にある変更を提案する場合がある。作業の流れを中断させずに離れた編集を表示するために、以下の3点を重視したUI（ユーザーインタフェース）を設計した。

• 信頼の構築
  • UIは完全なコンテキスト（背景情報）スイッチを要求することなく、提案を評価するのに十分なコンテキストを伝える
• コンテキストの維持
  • 画面を強制的にジャンプ（コンテキストスイッチ）させるのではなく、カーソル付近にコンパクトなウィジェットを表示する
• 軽量プレビューの提供
  • 変更箇所の全文を表示するのではなく、影響を受ける行の抜粋をdiff形式でハイライト表示し、情報の過負荷を防ぐ

A/Bテストによる検証

　Microsoftでのドッグフーディング（社内利用）の結果、モデルがジャンプ提案を出し過ぎる傾向が明らかになった。原因はデータセットの不均衡で、学習データにおいて、ジャンプ例に比べて「非ジャンプ」例がはるかに少なかったためだ。

　そこで、データセットを調整し、現在の行にとどまることが正しいアクションとなるサンプル（変数名を途中まで入力している場合など）を拡張した。再トレーニング後、ジャンプ精度と非ジャンプ精度の両方が向上し、提案意図がより明確に感じられるようになった。

　大規模な検証のため、長距離NESと標準NESを比較するA/Bテストも実施した。結果は、NESを通じて書かれたコードが23％増加し、他のエンゲージメント（利用度）指標も改善したものの、カーソル位置から大きく離れた場所の編集提案はは標準NESよりも頻繁に拒否されるという課題が残った。

強化学習による改善

　この課題に対処するために、新たに検証済み報酬を用いた強化学習（RLVR）フェーズを導入した。この手法では、開発者のカーソル移動を基準として、次のようにモデルへ報酬やペナルティーを与える。

• 実際のカーソル移動と一致する予測に報酬を与える
• 不要または不適切なタイミングのジャンプにはペナルティーを課す

　この結果、積極的なジャンプ提案と不要なジャンプの抑制というバランスが改善され、提案の拒否率も低下した。

今後の展望と利用方法

　今後の展望として、Microsoftは予測範囲を現在のファイル外へ広げる「クロスファイル提案」を計画している。また修正すべき場所と内容を同時に予測する統合モデルも検討中で、実現すれば開発者への提案精度が飛躍的に高まることが期待される。

　長距離NESは、GitHub Copilotサブスクリプションを持つVS Codeユーザー向けに利用可能だ。VS Codeで「Next Edit Suggestions」（NES）と「Extended Range」（github.copilot.nextEditSuggestions.extendedRange）を有効化することで使用できる。