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 です。

先の記事「Visual Studio 2026 AI 駆動開発」で書きましたように、Free (無償版) の GitHub Copilot を Visual Studio 2026 の Chat Window と IDE 全体で使えるようにしました。

GitHub Copilot には使用回数に制限がありますがそれについて調べたこと、および、それに関連するプレミアムリクエスト、プレミアムモデルについて調べたことを書きます。

注: この記事を書いた時点で GitHub のドキュメントなどを調べて得た情報です。プレミアムリクエストの導入が 2025 年 6 月とのことで、それ以前はどうなっていたかは不明です。また、生成 AI の世界は日進月歩で進化しているようですので、ここに書いたことも明日は違うかもしれません。ご注意ください。

まず、Free (無償版) の使用回数制限ですが、この記事を書いた時点では、チャットは 50 回/月、コード補完は 2,000 回/月に制限されています。

ちなみに、どのぐらい使用したかは、 Visual Studio 2026 では下の画像のようにの左上に表示されている GitHub Copilot のメニューを開いて、

赤枠で示した [Copilot Usage] をクリックすると、下の画像のように使用状況が表示されます (画像は Free 版の場合です)。

有償版でもプレミアムリクエストには制限があります。例えば Pro は 300 回/月、Pro+ は 1,500 回/月となっています。詳しくは GitHub のドキュメント「Plans for GitHub Copilot」の Comparing Copilot plans のセクションを見てください。

では、プレミアムリクエストとは何かですが、GitHub のドキュメント「GitHub Copilot プレミアム リクエスト」や「GitHub Copilot における要求」に詳しい説明があります。

いろいろなケースがあるようですが、自分に特に関係するのは上に挙げた前者のドキュメントの「Premium 要求とは」のセクションに書いてある "プレミアムモデルを使った Copilot チャットの使用" のようですので、それについて調べたことを書きます。

まず、どの AI モデルが GitHub Copilot のどのプランで利用できるかですが、それについては GitHub のドキュメント「Plans for GitHub Copilot」の Models のセクションを見てください。

Visual Studio 2026 では、下の画像のようにチャットウィンドウで赤丸印のアイコンをクリックすると、使用できる AI モデルが表示されます (画像は Free 版の場合です)。

そして、どの AI モデルがプレミアムモデルになるかですが、それについては GitHub のドキュメント「GitHub Copilot における要求」の Model multipliers のセクションを見てください。そのリストの中で Multiplier がゼロではない AI モデルが GitHub Copilot のチャットにおけるプレミアムモデルになります。（上の画像では Variable が Multiplier に該当します。Free 版なので全部 1 になっています）

有償版のチャットは無制限という記事を目にしますが、それは使用する AI モデルの Multiplier がゼロの場合 (AI モデルが Included Models の場合) に限ります。上に紹介した GitHub のドキュメントに "GPT-5 mini, GPT-4.1 and GPT-4o are the included models, and do not consume any premium requests if you are on a paid plan." と書いてある通りです。

一方、使用する AI モデルの Multiplier がゼロではない場合、1 回のチャットで Multiplier の数を掛けた回数のプレミアムリクエストが行われたことになります。GitHub のドキュメントに "Using Claude Opus 4.5 in Copilot Chat: With a 3× multiplier, one interaction counts as 3 premium requests." と書いてある通りです。

Copilot Free (無償版) の場合は、利用できるすべての AI モデルの Multiplier が 1 になっていますので、1 回のチャットで 1 回のプレミアムリクエストとなります。

数ある AI モデルの内どのモデルを使えばいいのかは、@IT の記事「GitHub CopilotのAIモデル、どれを選べばよいのか？」や GitHub の公式ドキュメント「AI model comparison」が参考になると思います。

上に挙げた記事には各 AI モデルのメリット・デメリットなどいろいろ書いてありますが、後者の記事を読んだ限りでは、Visual Studio 2026 + Copilot Free (無償版) でチャットを行う場合は現時点でのデフォルト GPT-5 mini でよさそうです。

特定の AI モデルを選択しないで、上の画像に選択肢がある Auto に設定する方法もあります。詳しくは Microsoft のドキュメント「Introducing Copilot auto model selection (preview)」を見てください。

有償版の場合は Auto に設定すると、10% の割引があるとか、プレミアムリクエストの上限を超えた場合は自動的に Multiplier がゼロの AI モデルを使うというメリットがあるようです。Free 版の場合はデフォルトの GPT-5 mini 固定で良いと思います。