オンプレ×Windowsアプリ開発でもCopilotは効く：ローカル編集の安心感と手順

概要

「AIコーディング」と聞くと、クラウド前提だったり、GitHub上で勝手にPRが飛んできたり、そういう“別世界の開発”を想像しがちです。ですが、Windowsアプリ開発のいつもの形——Visual Studio / VS Codeでソリューションを開いて、ローカルで編集して、ビルドして、デバッグする——この流れの中でも、Copilotは十分に戦えます。

むしろローカルのGUI上で差分を見ながら進められるので、心理的にも取り入れやすいです。

この記事では、VS CodeのDIYさゆえに最初に整備すべきこと（ビルド/ツール情報）と、Visual Studio側の強み（デバッグ情報をコンテキストに渡せる）を対比しつつ、私が「これがないと成果物になりにくい」と感じている2つの前提（テスト、設計メモ）をまとめます。

最初に結論まとめ

• Visual Studio / VS CodeのGitHub Copilotは、「コードエディタ上での作業を代わりにやってくれる」というイメージなので取り入れやすい。「issueからPRまで全自動」というイメージではない
• VS Code は安定していて軽量で最新機能のアップデートも早く、ツール（MCP 等）も足しやすい。反面、初期状態ではビルドやテストなどの基本的なツールすら揃わず、msbuildのコマンドを用意するなどしてちゃんとツールを整備する必要がある
• Visual Studio はデバッガ統合が強く、デバッガやダンプの状態をコンテキストに渡しやすいので、バグの原因追及に強い。ビルドなどの基本的なツールも最初から揃っている
• 動くコードを書かせるのに重要なポイントは、次の2つ
  • テスト等の“コードがちゃんと動くと証明できるもの”とセットでやらせる
  • 実装前にドキュメント（設計メモ）を書かせる

説明

ローカルのコードを編集するGitHub Copilot

Windowsアプリ開発の環境としては、VisualStudio・VSCodeでローカルでコーディングというのが多数派でしょう。そこでコーディングエージェントを選ぶなら、まず第一選択肢はGitHub Copilotだと思います。

※この記事では、Visual Studio・VSCodeのGitHub Copilot Chatを扱います。GitHub上で使うCopilot Coding Agentは扱いません。

これはワークスペースを開いたGUI上の、チャットウインドウで動きます。つまり、ローカルでそのまま動作します。次の画面のように、チャットウインドウで指示を出すと、ファイルをそのまま変更して差分を表示してくれる感じになります。

作業をしている様子がローカルで見えていて、勝手にサーバー側で何かが変わるようなこともないので、気軽に試せると思います。分担してくれる開発メンバーが一人増えたくらいのイメージで、いまの開発の延長で使えます。

処理自体はクラウドで行うのでローカル完結ではないですが、ローカルに編集対象があるという分かりやすさが強みです。

GitHubのアカウントは必要ですが、GitHubにリポジトリを置く必要はありません。例えばオンプレの共有フォルダのgitリポジトリであっても問題ありません。

VSCodeでGitHub Copilot

VSCodeは良くも悪くもDIY (Do It Yourself) です。

軽くて安定していますし、使えるモデルも次のように多く、プレビュー扱いの機能もどんどん使えるようになります。（2025/12時点の画像、一部のモデルを設定でOFFにしてあります）

反面、msbuildなどのツール情報を与えないとソリューションのビルドすら苦戦します。次のようにexecuteのツールがあってPowerShellを実行出来るのでデフォルトでも何とかやってはくれますが、毎回msbuildなどのビルドツールやビルド対象のプロジェクトを探し回って試行錯誤する動きになります。

このToolsへ追加するMCPの準備までは行かずとも、最低でもビルド方法を Instructions や Agent Skills に書いておかないと始まりません。

VisualStudioでGitHub Copilot

Visual Studioは重い代わりに全部入りです。デフォルトのままでもGitHub Copilotはビルド・テストを迷わず実行出来ます。

特に大きな強みは、デバッグ実行中にデバッガの情報をコンテキストへ渡せることです。例えば次のように例外が出たところでデバッガを止めた場合に、例外のCopilotアイコンを押すと、その例外の解析が始まります。

なぜか公式ドキュメントに記載が見つからないのですが、 #Debugger をチャットに含めるだけでも同じことが出来ます。デバッガ上の変数・スレッド等の情報へGitHub Copilotがアクセス出来ます。ここでは簡単な例ですが、「例外」としか言っていないのに例外の内容や発生した変数などを理解して返答している様子です。

こうした統合で、デバッグはもちろん、ダンプ解析やパフォーマンス分析もやりやすいので、実装済みのソフトの改善や障害解析で特に役に立ちます。

上手く使うポイント

GitHub Copilotさえあれば後は全てエージェントにお任せ・・・とは行きません。そこそこ何でもやってくれますが、良い成果を出すには色々工夫が必要です。今のところ次の2つが最重要だと思います。

1. 書いたコードを証明できるもの（テストなど）とセットでやらせる
2. ドキュメントを書かせてからコーディングさせる

書いたコードを証明できるもの（テストなど）とセットでやらせる

ソースコードが正しく書けているかをチェックする手段をGitHub Copilotに渡しておく、ということです。dotnet,msbuildコマンドなどのコンパイラがあるものはもちろん、スクリプトの類であってもそれをチェック出来る手段（チェック用のソフト、テスト用のパラメータを渡して実行出来る用に作ったコードなど）を最初に用意します。

それがあれば、それが合格を出すところまで修正を繰り返させることができます。逆にこれが無いと、コンパイルすら通らないものを完成品として出してくることが頻繁に起きます。これは個別に整備するのみですが、ここでは概要だけ。プロジェクトに合わせた工夫は別の記事で深掘りする予定です。

ドキュメントを書かせてからコーディングさせる

いきなりコーディングさせるのではなく、作ろうとしているものをいったんMarkdownのドキュメントファイルに書かせてから、それを実装させます。少し大きめの作業だと、これだけでも質が上がります。コンテキストが失われたり圧縮されても、全体像を確認出来るドキュメントが残っていることで、迷走を避けやすくなるのだと思います。これについては工夫の余地がたくさんありますが、ここでは概要だけ。また別の記事で深掘りする予定です。

まとめ

Visual Studio・VSCodeを使ったWindowsアプリ開発でも、AIエージェントでのコーディングは現実的に使っていけます。むしろメリットが大きいのでどんどん使った方が良いと思います。

実際に使いながら、紹介したような工夫を色々やってノウハウも溜まってきました。今後の記事で連載的に紹介していこうと思います。