Visual Studio 2026 の AI 駆動開発において、GitHub Copilot が提供するエディタ上でのインライン提案には「入力候補 (Completions)」と「次の編集候補 (Next edit suggestions)」という 2 種類があります。この記事では後者の「次の編集候補」について書きます。

前者の「入力候補」については、先の記事「Visual Studio 2026 AI 駆動開発 - コード補完」に書きましたので、そちらを見てください。

「入力候補」と「次の編集候補」の何が違うかを簡単に書くと以下の通りです:

• 入力候補: 現在のカーソル位置で、ユーザー入力に基づき、続きのコードを予測して提案する
• 次の編集候補: ある行でのコードの変更に関連して、別の行で必要になる変更を予測して提案する。提案に従って、Tab キーを連続して押していくだけで、複数箇所にわたる修正が可能になる

詳しい説明は Microsoft のドキュメント「GitHub Copilot の入力候補を始めてみましょう」、「GitHub Copilot の次の編集提案を使い始める方法」にありますので見てください。

自分の環境の Visual Studio 2026 + GitHub Copilot Free で「次の編集候補」を有効にして使ってみましたので、その時の状況を以下に書いておきます。

まず、「次の編集候補」はデフォルトでは無効になっていますので、この記事の一番上の画像で示したように、GitHub Copilot のメニューを開いて Settings > Enable Next Edit Suggestions にチェックを入れて有効化します。

次に、Visual Studio 2026 のテンプレートを使ってターゲットフレームワーク .NET 10.0 でコンソールアプリを作成し、それに以下の Point クラスを書いて試してみました。（Microsoft のドキュメントの「意図の変更に合わせる」のコードとほぼ同じです）

上の Point クラスの private フィールド x, y を public プロパティ X, Y に変更してみます。113 行目で修正提案が出ているので Tab キーを押して提案を Accept します。

すると以下の画像のように表示されます。現在のカーソルは 113 行目にあり、「次の編集候補」は 117 行目にありますので、[Tab] の横に下向きの ↓ が表示されています。Tab キーを押すと「次の編集候補」の 117 行にカーソルが移動します。

117 行の修正案が OK なら再度 Tab キーを押して修正案を Accept します。118, 123, 124 行も修正が必要ですが、同様に Tab キーを押していけば下の画像のように修正が完了します。

以上が「次の編集候補」により、複数の行に渡って修正提案を受けながら、それらを順次適用していく場合の典型的な動きになるようです。

ただ、エディタ上でいろいろ変更しながら「次の編集候補」の出方を見ていると、同じことを繰り返しても結果が異なるということがありました。このことは気を付けた方が良さそうです。具体的にどういう事かを以下に書きます。

例えば、Microsoft のドキュメントの「ミスをキャッチして修正する」のセクションに書いてある bol ⇒ bool の修正提案ですが、最初はドキュメントに書いてある通りに提案されるものの、何度か同じことを試すと提案が出てこなくなります。bol としたのはユーザーの意図と誤解するのか、bol 型を新たに作るという提案がされます。

また、「意図の変更に合わせる」のセクションに書いてあるクラス Point を Point3D に変更する場合ですが、最初はドキュメントに書いてあるように、一行ずつ順に修正提案が出て、それを見ながら修正して行くという形になるものの、同じことを繰り返し試すと、Point ⇒ Point3D とタイプした時点で即以下の画像のようになります。

ネットの記事「GitHub Copilot NESの内部実装が公開」に "Copilot NESはユーザーのエディタ上の「操作履歴」を記録します。操作履歴のデータを専用モデルに送信して「続きの操作」を推論します" と書いてあるのを見つけました。それが正しいとすると、想像ですが、エディタ上でいろいろ変更しながら試していた時の「操作履歴」が影響していたのかもしれません。

Visual Studio 2026 で Docker コンテナー を使うため、Microsoft のドキュメント「Visual Studio コンテナー ツール」を参考に、環境を構築してみました。

簡単にできるのかと思いましたが、使えるようになるまでいろいろ紆余曲折がありました。将来同じ作業をすることがあるかもしれませんので、また無駄な労力と時間を使わないで済むよう、その顛末や色々調べたことを備忘録として残しておくことにしました。（自分は今まで Linux とか Docker とかは触ったこともない素人ですので間違いがあるかもしれませんのでご注意）

下の画像は、Docker Desktop を起動した後、Docker コンテナーのサポートを有効にした ASP.NET Core Razor Pages アプリを Visual Studio 2026 で開いた時の Docker Desktop の表示です。

上の画像の意味は、以下のレイヤーが構築されて、Linux の Docker コンテナーで RazorPagesDocker という名前の ASP.NET Core Razor Pages アプリを動かすための準備が整ったということです。

1. Windows 10
2. WSL2（Linux 仮想マシン）
3. Docker Desktop（Docker Engine を WSL2 上で動かす。Docker Engine が Linux イメージを使ってコンテナーを作成）
4. Docker コンテナー（ASP.NET Core アプリが動く場所）

この状態から Visual Studio を操作してアプリを実行すると、Windows OS 上で Kestrel を使った時と同様に、ブラウザが立ち上がってページが表示されます。

Visual Studio 2026 で Docker コンテナーを使うために必要なのは、(1) Docker Desktop をダウンロードしてインストールし動くように設定する、(2) プロジェクトにコンテナーのサポートを追加するという 2 点です。

WSL2 も必要ですが、これは自分の環境の Windows 10 Pro には含まれています。既定では無効になっていますが、Docker Desktop をインストールすると WSL2 を自動的に有効化し、Linux カーネルをセットアップするそうです。

Ubuntu などの Linux ディストリビューションをインストールする必要はありません。Docker Desktop をインストールすると WSL2 用の docker-desktop という専用の軽量ディストリビューションを自動生成するそうです。PowerShell からコマンド wsl --list --verbose でインストールされている Linux ディストリビューションを確認できます。下の画像のように docker-desktop と表示されるはずです。

Dockerfile → Docker Desktop → WSL2 → Docker コンテナー作成の流れは以下の通りです。Visual Studio で Docker サポートを有効にすると:

1. Visual Studio が Dockerfile を生成
2. Visual Studio が Docker Desktop にビルドを依頼。 Docker Desktop は WSL2 内の Docker Engine に処理を渡す（Docker Desktop 自体は Windows アプリですが、Docker Engine は WSL2 の Linux 上で動いています）
3. Docker Engine が Linux イメージを使ってコンテナーを作成
4. コンテナー内で ASP.NET Core アプリが実行される

無知な自分がトラブったのは、Docker Desktop をインストールし、起動しようとしたら "Virtualization support not detected" というエラーとなって、Docker Desktop を開始できなかったことでした。調べてみるとハードウェアと Windows OS レベルで仮想化支援機能を有効にする必要があるとのこと。以下のようにして解決しました。

(1) BIOS 設定

自分の Windows 10 Pro の BIOS 設定の場合ですが、Advanced / CPU Configuration 下の項目 Intel (VMX) Virtualization Technology を Enabled に設定します。（Intel VT-x が Supported と表示されていたので、デフォルトで設定済みかと誤解していたのですが、サポートされてはいても有効になってなかったということでした。お粗末）

(2) Windows の機能の有効化

Windows の機能の有効化または無効化で、以下の画像のように「Hyper-V」の全項目、「Linux 用 Windows サブシステム」、「仮想マシンプラットフォーム」にチェックを入れて有効化します。上の BIOS 設定ができてないと「Hyper-V Hypervisor」がグレーアウトされていてチェックできないはずです。

(3) WSL2 用 Linux カーネルの更新

自分の環境では WSL2 用 Linux カーネルを更新する必要がありました。管理者権限で立ち上げた PowerSell でコマンド wsl --update を実行します。

自分の環境では、コマンド wsl --update 実行後の WSL2 のバージョンは以下の通りとなりました。（実行前は不明）

この状態で、何故か Windows Update が Windows Subsystem for Linux Update 5.10.102.1 を適用しようとして失敗します。wsl --update で 6.6.87.2-1 にしたのに 5.10.102.1 を適当しようとして失敗した様子。wushowhide.diagcab を使って隠すことにしました。

以上の操作で仮想化支援機能は有効になり、Task Manager のパフォーマンス > CPU タブを開くと、仮想化が有効と表示されているはずです。

上記で仮想化支援機能を有効にできたら、Docker Desktop を立ち上げて、Docker コンテナーのサポートを有効にした ASP.NET Core アプリを Visual Studio 2026 で開くと、この記事の一番上の画像のように Docker Desktop に表示されます。

そうならない場合は、下の画像のように Visual Studio 2026 で「Container (Dockefile)」が選択されていることを確認してください。

上の画像の項目「Container (Dockefile)」は、プロジェクトのコンテナーサポートが有効になってないと表示されませんので注意してください。下の画像は Visual Studio のテンプレートを使ってプロジェクトを作成する際にコンテナーサポートを有効にするための設定です。

ここまでできれば、Visual Studio で Windows OS 上で Kestrel を使って開発しているときと同様に、Docker コンテナの Linux OS 上で ASP.NET Core アプリを開発できるはずです。

最後に、Docker Desktop を停止する方法を書いておきます。起動した Docker Desktop は、Visual Studio を閉じても Docker Desktop 画面を閉じても動いています。停止するには、下の画像のように、Windows タスクバーのメニューバーにあるクジラアイコンを右クリックし「Quit Docker Desktop」をクリックします。

先の記事「Visual Studio 2026 AI 駆動開発 - チャット」では、Visual Studio 2026 + GitHub Copilot で Ask Mode を使ってチャットを行う例を書きました。この記事では Agent Mode を試してみた時の話を書きます。

自分の環境の Visual Studio 2026 + GitHub Copilot Free ではデフォルトで Ask Mode になっていましたが、上の画像のようにしてチャットウィンドウで Agent Mode に設定できます。

Microsoft のドキュメント「GitHub Copilot エージェント モードを始めよう」などの説明を読むと、Ask Mode と Agent Mode は役割もできることも全く別物だそうで、概略以下の違いがあるようです。

• Ask Mode: 一問一答の形式で質問に答えるシンプルなモード。安全で軽量
• Agent Mode: プロンプトの目標に達するまで実行と調整の手順を続けるモード。強力だが影響範囲が大きい

バイブコーディングには、Google Cloud の記事「What is vibe coding?」によると、主に "Pure" vibe coding と Responsible AI-assisted development という 2 つの方法があるとのことです。Visual Studio 2026 + GitHub Copilot は Responsible AI-assisted development ですが、Agent Mode を利用すると、少し "Pure" vibe coding に近づくという感じがします。

具体的にどういうことができるのか、自分の手を動かして使ってみれば理解が深まると思って、自分の環境の Visual Studio 2026 v18.2.1 + GitHubCopilot Free で Agent Mode を使ってみました。その内容を以下に書きます。

Visual Studio のテンプレートを使って ASP.NET Core MVC アプリのプロジェクトを作成し、それに SQL Server の既存のデータベースのテーブルの CRUD を行うための Model、View、Controller を Agent Mode を使って追加してみます。

今回は LocalDB のデータベース TestDatabase に、下の画像の Movie テーブルを作って、それをベースに使うことにしました。

Visual Studio 2026 でスキャフォールディング機能を使って（GitHub Copilot を使わないで）行う場合は、(1) Package Manager Console を開いて Scaffold-DbContext コマンドを使ってコンテキストクラスとエンティティクラス (Model に該当) を作成し、(2) それらのクラスをベースにスキャフォールディング機能を使って Controller と View を生成します。その具体例は、先の記事「スキャフォールディング機能 (CORE)」を見てください。

上の (1), (2) に述べた方法でアプリを作成すると、実行結果は以下の画像のようになります。

GitHub Copilot の Agent Mode を使ってアプリを作成した場合はどのような結果になるか、上の (1), (2) に述べた方法で作成した場合とどのように異なるのかが興味のあるところです。

(1) プロジェクトの作成

Visual Stidio 2026 のテンプレートを使って .NET 10 の ASP.NET Core MVC のプロジェクトを新規作成します。設定は下の画像の通りです。

(2) プロンプト作成

あまり詳しく書かないで簡単な内容にしてみました。以下のプロンプトを作って、それをチャットウィンドウから GitHub Copilot に送信してみます:

SQL Server の既存の Movie テーブルの CRUD を行うための Model, View, Contoller を追加してください

Movie テーブルのスキーマ情報は絶対必要なのですが、試しに最初のプロンプトにはわざと含めずに GitHub Copilot に指示を出しました。（後述しますが、それが失敗だったようです）

(3) GitHub Copilot の回答

上のプロンプトでは Movie テーブルのスキーマ情報がないので、エンティティクラス (Model に該当) が作成できません。なので、まず、GitHub Copilot は作業を始める前にそれを聞いてくるかと思ったのですが、即 CRUD に必要なすべてのコードを作成してきました。

既存の Movie テーブルのスキーマと、GitHub Copilot が想像して作ったエンティティクラスが異なると、修正が多岐にわたって大変な手間になるので、GitHub Copilot は事前にスキーマを聞いてから作業を始めるべきだと思うのですが。生成 AI はプロンプトに質問を返すようなことはせず、とにかく回答を返すことを優先するということなのでしょうか？

上のプロンプトを受けて GitHub Copilot が行ったことまとめると、NuGet パッケージ Microsoft.EntityFrameworkCore.SqlServer の追加、コンテキストクラス、エンティティクラス、View、Controller のコードの作成、コンテキストクラスの DI 設定、_Layout.cshtml にナビゲーションリンクの追加です。

今回は偶然（？）既存の Movie テーブルのスキーマと GitHub Copilot が作ったエンティティクラスと整合していたので、そのまま Model として使えました。（Microsoft のチュートリアル「データ モデル クラスの追加」のコードが GitHub にあって、GitHub Copilot はそこから情報を取ってきたように思われます）

コードの生成・修正に加えて、下の画像のように GitHub Copilot が行なった追加・修正の説明、ビルド結果、次にユーザー側が行うことをチャットウィンドウに表示してくれます。

チャットウィンドウに "ソリューションはビルドに成功しました" とありましたので、GitHub Copilot の追加・修正をすべて受け入れてビルドしてみました。確かにビルドには成功します。

(4) ユーザーが行う作業

ユーザー側が行うこととしてチャットウィンドウに以下の 2 件が挙げられていました:

• appsettings.json に接続文字列を追加
• 既存の SQL Server の Movie テーブルのスキーマが Movie.cs と整合することを確認（カラム名、型が合致するように必要なら Movie クラスを調整）

前者はその通り既存のデータベースへの接続文字列を設定しました。後者は偶然整合していたので調整不要でしたが、違っていたらどうするのでしょうか？　「必要なら Movie クラスを調整」とありますが、それだけではダメで、View と Controller のコードも変更する必要があります。ユーザーが Movie クラスを変更してから、GihHub Copilot に他のコードの修正を行うようプロンプトで指示するのだと思いますが。

(5) NuGet パッケージのアップデート

GitHub Copilot が追加した NuGet パッケージ Microsoft.EntityFrameworkCore.SqlServer のバージョンが 8.0 と古く、脆弱性があるとのことなので最新版 10.0.2 にアップデートしました。

(6) SqlException の解決

リビルドして実行してみると、MoviesController.cs の _context.Movies.ToListAsync() で SqlException: Invalid object name 'Movies' というエラーが出ます。チャットウィンドウで解決策を聞いてみました。

GitHub Copilot の回答は "SQL Server が指定されたデータベース内に Movies という名前のテーブルを見つけられないためです" が原因ということです。確かに既存のテーブルの名前は Movies ではなく Movie です。

Movie.cs の Movie クラスに属性 [Table("Movie")] を付与することで解決できるのですが、最初にスキーマ情報を与えていれば、GitHub Copilot がエンティティクラスを作成する際 [Table("Movie")] を付与するでしょうから、このようなトラブルは起こらなかったと思います。（ちなみに、Scaffold-DbContext コマンドを使ってエンティティクラス（Movie クラス）を作成した場合は、自動的に Movie クラスに属性 [Table("Movie")] が付与されます）

上記の修正後アプリを実行すると以下の画像のように、スキャフォールディング機能を使って Controller と View を生成した場合とほぼ同じ結果となります。CRUD 操作も問題なく可能でした。

(7) Movie クラスの調整

最初の回答に "必要なら、次の作業を行います（指示ください）⇒ Movie クラスを実際のテーブルスキーマに合わせて調整" とあったので、GitHub Copilot にプロンプトでスキーマ情報を渡して、それをやってもらいました。GitHub Copilot の修正提案は以下の通りです。

内容 OK なのでキープしました。やはり最初から Movie テーブルのスキーマという絶対必要な情報は渡しておくべきでした。

GitHub Coplit が生成した Create, Edit のビューに、クライアント側で入力バリデーションを行うためのコードが無かったのですが、最初に Movie テーブルのスキーマ情報を渡していれば、そこも面倒を見てくれたのではなかろうかと思います。（未確認・未検証です）

(8) Html ヘルパーを使わない理由

最後にもう一つ、スキャフォールディング機能を使って生成した View には Html ヘルパーが使われてますが、GitHub Coplit が作成した View には Html ヘルパーは使われてない理由を聞いてみました。回答は以下の通りです。

• Visual Studio のスキャフォールディングはモデルのメタデータ（[Display]、型、データ注釈など）や表示テンプレート／ローカライズを尊重するため、Html.DisplayNameFor / Html.DisplayFor や EditorFor / ValidationMessageFor といった HTML ヘルパー（およびタグヘルパー）を使って自動生成します。これにより列見出しや表示形式、カスタムテンプレート、クライアント検証との連携が自動で行われます。
• 私が作成した簡易コードでは、最小限の可読な表示を優先して直接プロパティを出力（例：@item.Title や @item.ReleaseDate.ToShortDateString()）しました。これは動作が分かりやすく、依存するメタデータに依存しない一方で、スキャフォールディングが提供するメタデータ連携や自動フォーマット、ローカライズ、表示テンプレートの利点を利用していません。

これはちょっと問題かも。Movie クラスのプロパティに Display, Required, DisplayFormat 属性を追加して、それらが結果に反映されるよう GitHub Copilot に修正依頼を出せば面倒を見てくれるかもしれませんが (未検証・未確認)。

(9) 今回学んだこと

今回学んだことで一番重要なのは、生成 AI はプロンプトの情報が不備でも、とにかく回答を返すことを優先するようなので、Agent Mode でコードを生成させる場合は、必須情報は最初から与えておかないと、GitHub Copilot が勝手に想像して意図しない結果となる恐れがあるということだと思いました。

そのことを GitHub Copilot にチャットで質問してみました。下の画像がその時のプロンプトと回答です。その回答に書いてありますが "多くの生成系エージェントは「まず作業を進めて役に立つ出力を返す」ことを優先します。曖昧な点があっても、一般的な（最小限で動作する）仮定を置いてコードを生成することで、すぐに動かせる形を提供することが多いです"ということだそうです。

このあたりは使用する AI モデルによって異なるかもしれません。ちなみに、この記事で使った AI モデルは GitHub Copilot Free 版で現時点でデフォルトになっていた GTP-5 mini です。