長距離次の編集候補の構築
2026年2月26日 執筆者: Vikram Duvvur、Gaurav Mittal、Benjamin Simmonds
昨年2月、GitHub Copilotに次の編集候補（NES）をリリースしました。NESは、カーソル位置にコードを挿入するだけでなく、近くの編集を提案し、次に変更する内容を予測することで、ゴーストテキストを拡張します。これは強力な前進でしたが、カーソル周辺の小さな範囲でしか機能しませんでした。実際の編集ワークフローでは、次に加えるべき変更が数画面離れていることがよくあります。
これが、私たちが長距離次の編集候補で解決しようとしたことです。つまり、NESを拡張して、現在のカーソル位置の近くに限らず、ファイル内のどこにでも編集を予測し、提案できるようにすることです。
近くの編集からファイル内のどこへでも
典型的なリファクタリングセッションを考えてみてください。関数名を変更すると、ファイル内の他のすべての関数呼び出しも更新する必要があります。または、パラメーターの型を変更すると、200行下にある検証ロジックが不正になります。これらはまさにNESが役立つと期待する瞬間ですが、残念ながら、次に意味のある編集は有効な範囲をはるかに超えています。
これは難しいモデリング問題を生み出します。検索空間は、近くの数行からファイル内のすべての行へと爆発的に拡大します。そして、間違いのコストは均等に分配されません。正しいジャンプは実際の労力を省きますが、不必要なジャンプはフローを中断させ、次の候補を信頼しにくくさせます。システムは、どこに移動するかだけでなく、いつ移動しないかも学習する必要があります。
既存の編集生成モデルを修正するのではなく、マルチモデルアプローチを採用することにしました。私たちは、次に編集が行われるべき場所を予測することだけを責務とする専用ロケーションモデルを訓練しました。有効な場所が選択されると、元のNESモデルが編集候補を生成します。
この分離には2つの利点があります。第一に、各モデルが1つのタスクに特化できることです。1つのモデルは空間的な意図（どこへジャンプするか）を学習し、もう1つのモデルはローカルウィンドウ内で高品質な編集を生成します。さらに、これにより、コアNESモデルへの継続的な改善を妨げることなく、ロケーション予測について独立して反復処理を行うことが可能になります。
評価フレームワークによる成功の測定
ロケーションモデルを訓練する前に、それが実際の編集シナリオで実際に機能しているかどうかを測定する方法が必要でした。
構造化された3段階の評価プロセスを設計しました
- 一般的な複数編集ワークフローを特定する
- 代表的なカーソルジャンプの例を構築する
- ジャンプと非ジャンプの両方の精度を測定する
私たちは、開発者が実際のシナリオ（名前変更、シグネチャ変更、ドキュメント更新など）でどのように編集を連鎖させているかを分析することから始めました。各編集を独立したイベントとして扱うのではなく、です。共通のテーマは、編集がファイル内の複数かつ隣接しない場所に波及することです。
これらのワークフローから、各例にジャンプすべき正解の次の行、最近の編集履歴、およびカーソルのコンテキストを含む評価データセットを構築しました。
重要なことに、私たちはジャンプと非ジャンプの両方の精度を測定しました。多くの例では新しい場所の予測が必要でしたが、意味のあるサブセットでは現在の行に留まる必要がありました。頻繁にジャンプしすぎるモデルは、重要な遷移を見逃すモデルと同じくらい邪魔になる可能性があります。変数名の入力を半分まで終えたところで、毎回ジャンプの候補が表示されることを想像してみてください。
評価を現実的なワークフローに基づいて行い、ジャンプと非ジャンプの両方のケースを測定することで、オフラインの指標が人工的なシナリオではなく、開発者が実際にどのように編集するかを反映していることを確認しました。
トレーニングデータセットの構築
評価の準備が整い、次にトレーニングデータに取り掛かりました。評価データセットは手作業で構築できるほど小さかったものの、トレーニングにははるかに大規模なデータが必要でした。私たちは、開発者がファイルをどのように移動し、編集するかという軌跡を含む、コアNESモデルのトレーニングのために厳選したのと同じデータセットから始めました。
これらの軌跡を再生することで、すべてのカーソル移動をトレーニングサンプルに変換しました。ジャンプ位置がプロンプトに表示されることを確認するなどのフィルターを適用した後、トレーニングデータセットが完成しました。
教師ありファインチューニングによるトレーニング
ロケーションモデルをトレーニングするために、私たちはターゲットを絞ったハイパーパラメーター探索を伴う教師ありファインチューニング（SFT）を使用しました。最も強力な結果は、既存のNESモデルのハイパーパラメーターを中心とした構造化グリッドサーチからもたらされました。検索空間を関連する設定で既に優れたパフォーマンスを示すことが知られている値に制限することで、組み合わせを効率的に探索し、高性能な構成を特定することができました。
このアプローチに落ち着く前に、私たちは高価なブラックボックス関数を最適化するために設計された技術であるベイズ最適化も試しました。私たちの場合、各評価にはモデルをゼロからトレーニングする必要があり、実験は計算コストが高くなりました。理論的には魅力的でしたが、このアプローチは、より焦点を絞ったグリッドサーチと比較して改善をもたらしませんでした。
最終的に、構造化グリッドサーチは、私たちの最高のパフォーマンスを発揮する教師ありモデルを生成し、その後の反復のための安定した基盤を提供しました。
遠隔編集のためのUX設計
モデルがどれほど優れていても、その生成する候補に気づかなかったり、信頼しなかったりすれば不十分です。標準のNESでは、候補はカーソル近くの視界に入る範囲に表示されるため、自然に発見できます。しかし、長距離NESでは、最も関連性の高い編集がすぐ近くにない場合があります。そのため、UXはより難しい問題を解決する必要があります。つまり、フローを中断させることなく、遠隔の編集を表面化させることです。
これは、候補をコンパクトに保ち、読みやすくし、コードをどれだけ隠すかを最小限に抑えるという3つの懸念事項のバランスを取ることに帰着します。
これは発見性の問題にとどまりません。信頼性の問題です。システムがカーソルを別の場所に移動することを提案するとき、そのジャンプが関連性があり、注意を払う価値があるかどうかを迅速に評価する必要があります。UIは、完全なコンテキスト切り替えを要求することなく、候補を評価するための十分なコンテキストを伝える必要があります。
大きな差分をインラインでレンダリングしたり、強制的に注意を切り替えさせたりするのではなく、カーソル近くに表示され、利用可能な場合は空白スペースを優先するコンパクトなウィジェットを設計しました。このウィジェットは周囲のエディターレイアウトに適応し、行の末尾やコードブロックの間などの空白スペースに自然に収まるように縮小または拡大します。
完全な編集は遠く離れていて、かつ大規模である可能性があるため、ウィジェットは候補全体をレンダリングしようとはしません。代わりに、影響を受ける行の抜粋である軽量なプレビューを、差分スタイルのハイライト表示で提供します。これにより、関連性を判断し、行動するかどうかを決定するのに十分なコンテキストが得られます。
プレビューが有用であると判断した場合、提案された場所にジャンプして、そこで完全な編集を確認または適用することができます。そうでない場合は、中断することなく編集を続けることができます。
検証：ドッグフーディングからA/Bテストまで
新しい機能をリリースする前には常に社内でドッグフーディングを行っており、長距離NESも例外ではありませんでした。初期のフィードバックでは明確なパターンが明らかになりました。モデルはジャンプしたがる傾向が強すぎたのです。その予測が方向的には正しかったとしても、頻繁な候補表示は注意散漫の原因となりました。根本的な原因はデータセットの不均衡でした。ジャンプの例に比べて、「ジャンプしない」例がはるかに少なかったのです。モデルは自信を持ってジャンプすることを学習しましたが、いつその場に留まるべきかを学習していませんでした。
私たちは、ジャンプすることが意味をなさない部分的に入力された識別子など、正しい行動が現在の行に留まることであるサンプルを増やして、データセットのバランスを取り直しました。再トレーニング後、ジャンプと非ジャンプの両方の精度が向上し、候補は著しく意図的であると感じられるようになりました。
大規模な検証を行うため、長距離NESを標準NESと比較するA/Bテストを実施しました。結果は有望でした。NES経由で書かれたコードが23%増加し、他のエンゲージメント指標も改善しました。しかし、この実験ではトレードオフも浮き彫りになりました。遠く離れた候補は、標準NESよりも頻繁に却下されました。これは新しいインタラクションパターンを考えるとある程度予想されたことですが、モデルがジャンプを提案するタイミングについて、より選択的である必要があることを示唆していました。
これは純粋なモデリング問題でも、純粋なUX問題でもありませんでした。その両方でした。長距離NESを改善するには、モデルのジャンプ予測をより厳密にすると同時に、インターフェースが関連する候補を評価し、受け入れやすいようにすることも必要でした。
強化学習：いつジャンプしないかを学ぶ
検証結果は明確な結論を指し示していました。教師ありモデルは、より抑制的である必要があったのです。
これに対処するため、私たちは検証済み報酬による強化学習（RLVR）を用いた強化学習段階を導入しました。教師ありラベルのみに頼るのではなく、モデルが予測したジャンプ位置が最終的なカーソル移動とどれだけ一致したかに基づいて、評価シグナルを追加しました。実際の編集行動と密接に一致する予測はより強く報酬を与えられ、不要またはタイミングの悪いジャンプはペナルティを受けました。
これにより、新しい手動アノテーションやUXインストゥルメンテーションを必要とせず、モデルが実際の編集条件に直接最適化できるようになりました。
その結果、イニシアチブと抑制のバランスが改善されました。更新されたモデルはオフラインの指標を改善し、その成果をオンラインパフォーマンスに変換し、NES経由で書かれたコードを増やしつつ、拒否率を低下させました。これらのシグナルが揃ったことで、私たちは翌月には改善されたバージョンの提供を開始しました。
次は何？
今後、私たちはこの作業をファイル間候補にまで拡張し、モデルが現在のファイルを超えて推論できるようにする予定です。また、次の編集の場所と内容の両方を一緒に予測する統合モデルも検討しており、これにより全体的な候補の関連性が向上する可能性があります。
ぜひお試しください
長距離次の編集候補は、GitHub Copilotサブスクリプションをお持ちのユーザー向けに、VS Codeで利用可能です。次の編集候補と拡張NES範囲 github.copilot.nextEditSuggestions.extendedRange がVS Codeで有効になっていることを確認してください。変数の名前変更、関数シグネチャの更新、ファイル全体に波及する変更など、次にリファクタリング作業を行う際にぜひお試しください。皆様からのフィードバックをお待ちしております！
ハッピーコーディング！💙
謝辞
VS CodeとGitHub Copilotで最高の体験を提供するために、継続的なフィードバックをくださる開発者コミュニティに心から感謝いたします。また、トレーニングデータの厳選、トレーニングパイプライン、評価スイート、提供スタックの構築に携わったGitHubとMicrosoftの研究者、エンジニア、プロダクトマネージャー、デザイナーの皆様、そしてスムーズなモデルリリースを実現してくださったVS CodeとGitHub Copilotチームに深く感謝申し上げます。