「Install GitHub Copilot modernization – .NET Core」の更新で押さえるべき点は、GitHub Copilotによる.NETアプリのモダナイゼーション機能が、複数の開発環境から導入・実行できるエージェントとして整理されたことです。
これは、既存の.NETアプリが自動的に書き換えられる強制更新ではありません。インストールしただけではソースコードは変更されず、開発者がエージェントを起動してアップグレードを開始した時点で、評価、計画、実行のワークフローが動きます。
Visual Studioで利用する場合は、Visual Studio 2026、またはVisual Studio 2022 バージョン17.14.17以降が必要です。Visual Studio Code、GitHub Copilot CLI、GitHub Copilot appから利用する導入経路も用意されています。(Microsoft Learn)
なお、Microsoft Learnに表示される最終更新日は2026年7月8日で、GitHub上の主要な変更履歴も7月8日です。日本時間では7月9日付の更新情報として扱われる場合があるため、本稿では「2026年7月9日前後の実質更新」として整理します。(Microsoft Learn)
結論：今回の更新で対応が必要な人
対応要否は、現在の開発環境と.NETアプリの更新計画によって変わります。
| 現在の状況 | 対応要否 | 取るべき対応 |
|---|---|---|
| Visual Studio 2022が17.14.17未満 | 必要 | Visual Studioを更新する |
| 対応済みVisual Studioだがオプション機能がない | 必要 | Visual Studio Installerからコンポーネントを追加する |
| Visual Studio Codeで.NET更新を行いたい | 必要 | 専用拡張機能を追加する |
| GitHub Copilot CLIで実行したい | 必要 | Microsoftのプラグインマーケットプレイスを登録する |
| GitHub Copilot appから利用したい | 必要 | upgrade-agentプラグインを追加する |
| 当面.NETのアップグレード予定がない | 緊急性なし | 情報収集のみでよい |
| オフライン環境、閉域環境で利用したい | 原則不向き | ネットワーク要件を確認する |
| C#・Visual Basic以外のプロジェクト | 対象外 | 別の移行手段を検討する |
GitHub Copilotのサブスクリプションも必要です。公式FAQではCopilot Free、Pro、Pro+、Business、Enterpriseが対象として挙げられています。ただし、Visual StudioでCopilot Freeを利用する場合は、Visual Studio 2026 バージョン18.1以降という条件があります。(Microsoft Learn)
GitHub CopilotのAI更新で変わったのは「モデル」ではなく導入経路
今回の公式情報では、基盤となるAIモデルの変更や、コード生成精度の向上は案内されていません。
主な変更点は、GitHub Copilot modernizationのインストール方法、対応環境、起動方法、対応シナリオの整理です。「新しいAIモデルが自動適用される更新」と捉えるのではなく、.NET更新エージェントを複数の開発環境で利用するための仕様整備と考えるのが適切です。
| 項目 | 2026年7月9日前後の変更内容 | 実務への影響 |
|---|---|---|
| 対応環境 | Visual Studio、Visual Studio Code、Copilot CLI、Copilot appの手順を整理 | 開発者が普段使う環境を選びやすくなった |
| Visual Studio | 正式なコンポーネント名を「GitHub Copilot app modernization」に修正 | Visual Studio Installerで選ぶ項目が明確になった |
| Visual Studio Code | 拡張機能として導入し、Copilot Chatにエージェントを登録 | Visual Studioを使わないチームでも導入可能 |
| .NET SDK | Visual Studio Code拡張機能が、不足しているSDKを自動取得 | プロキシやソフトウェア配布ルールの確認が必要 |
| Copilot CLI | マーケットプレイス経由のプラグイン導入に対応 | ターミナル中心の作業に組み込みやすい |
| Copilot app | upgrade-agentプラグインを追加して利用 | IDE外からもアップグレード作業を開始できる |
| 対応シナリオ | .NET更新以外にもSDK形式変換、依存関係更新、Azure移行などを整理 | 単純なTargetFramework変更以上の用途に使える |
公式ドキュメントの変更履歴では、Visual Studioのコンポーネント名修正、対応プラットフォームの追加、Aspire統合、Web FormsからBlazorへの移行、.NET Framework 4.8.1への更新経路などが明示されています。(GitHub)
Visual Studio Codeの名称に注意
2026年7月9日前後のドキュメントでは、Visual Studio Codeのエージェント名として
modernize-dotnet、起動方法として@modernize-dotnetが案内されていました。その後、7月16日の公式ドキュメントソースで、拡張機能の検索名が「GitHub Copilot upgrade」、エージェント名が「Upgrade」、起動方法が@upgradeへ変更されています。Microsoft Learnの表示と拡張機能の配信タイミングに差がある可能性があるため、見つからない場合はCopilot ChatのAgent pickerに表示される名称を確認してください。(GitHub)
GitHub Copilot modernizationでできること
GitHub Copilot modernizationは、.NETアプリを評価し、移行計画を作り、コード変更と検証を進める対話型エージェントです。
単にプロジェクトファイルのTargetFrameworkを書き換えるだけではありません。プロジェクト構成、NuGet依存関係、非推奨API、互換性問題を調査し、次のようなシナリオを扱います。
- 古い.NETから.NET 8、.NET 9、.NET 10以降への更新
- 旧形式のプロジェクトからSDK形式への変換
- Newtonsoft.JsonからSystem.Text.Jsonへの移行
- System.Data.SqlClientからMicrosoft.Data.SqlClientへの更新
- Azure Functionsのインプロセスモデルから分離ワーカーモデルへの移行
- ASP.NET Web FormsからBlazorへの移行
- Aspireの追加やバージョン更新
- Azure向けのデータベース、ストレージ、認証、メッセージング構成への移行
処理は、基本的に「評価」「計画」「実行」の3段階で進みます。評価結果や作業計画は、リポジトリ内の.github/upgrades/{scenarioId}にMarkdownファイルとして保存されます。(Microsoft Learn)
対応する.NETプロジェクトとアップグレード経路
GitHub Copilot modernizationは、C#とVisual Basicのプロジェクトに対応します。
主な対応プロジェクトは次のとおりです。
| 分類 | 対応プロジェクトの例 |
|---|---|
| Web | ASP.NET Core、MVC、Razor Pages、Web API、Blazor、ASP.NET Web Forms |
| デスクトップ | WPF、Windows Forms、WinUI |
| クラウド | Azure Functions |
| クロスプラットフォーム | .NET MAUI、Xamarin |
| 共通プロジェクト | クラスライブラリ、コンソールアプリ |
| テスト | MSTest、NUnit、xUnit |
対応する主なアップグレード経路は次のとおりです。
| 更新元 | 更新先 |
|---|---|
| .NET Frameworkの各バージョン | .NET 8以降 |
| .NET Frameworkの各バージョン | .NET Framework 4.8.1 |
| .NET Core 1.x～3.x | .NET 8以降 |
| .NET 5以降 | .NET 8以降 |
.NET Core 1.x～3.xから更新する場合、古い.NET Coreの範囲内で段階的に上げるのではなく、モダン.NETである.NET 8以降への移行が基本ルートになります。(Microsoft Learn)
開発環境別の導入条件とインストール方法
Visual Studioで利用する場合
Visual Studioでは、独立した拡張機能を別途ダウンロードするのではなく、Visual Studio Installerのオプションコンポーネントとして追加します。
必要な条件は次のとおりです。
- Windows
- Visual Studio 2026、またはVisual Studio 2022 バージョン17.14.17以降
- 「.NET デスクトップ開発」ワークロード
- 「GitHub Copilot」オプションコンポーネント
- 「GitHub Copilot app modernization」オプションコンポーネント
- Copilotを利用できるGitHubアカウント
- C#またはVisual Basicのコード
Webアプリのアップグレードで利用する場合でも、公式手順では「.NET デスクトップ開発」ワークロード内のオプションコンポーネントを有効にします。
インストール後はソリューションを開き、次のどちらかで確認します。
- ソリューションエクスプローラーでプロジェクトを右クリックする
- 「Modernize」が表示されることを確認する
または、GitHub Copilot Chatで次を入力します。
@Modernizeエージェントが応答すれば導入は完了です。(Microsoft Learn)
Visual Studio Codeで利用する場合
Visual Studio Codeでは、GitHub Copilot拡張機能に加えて、モダナイゼーション用の拡張機能を追加します。
基本条件は次のとおりです。
- Visual Studio Code
- GitHub Copilot拡張機能
- GitHub Copilotの利用権
- インターネット接続
拡張機能ビューをCtrl+Shift+Xで開き、現行の公式ソースでは「GitHub Copilot upgrade」を検索してインストールします。配信段階によっては「GitHub Copilot modernization」など、以前の名称で表示される可能性があります。
インストール後は、Copilot ChatのAgent pickerで「Upgrade」を探すか、次のように入力します。
@upgrade以前の配信バージョンでは、次の名称が表示される場合があります。
@modernize-dotnetVisual Studio Code拡張機能は、必要な.NET SDKが見つからない場合にSDKを自動取得します。企業ネットワークでは、ダウンロード先への接続、プロキシ、許可するSDKバージョン、端末へのソフトウェア導入ルールを事前に確認しておく必要があります。(Microsoft Learn)
GitHub Copilot CLIで利用する場合
GitHub Copilot CLIでは、Microsoftのプラグインマーケットプレイスを追加し、upgrade-agentをインストールします。
Copilot CLIのチャット画面で、次のコマンドを実行します。
/plugin marketplace add microsoft/upgrade-agent-plugins続けてプラグインをインストールします。
/plugin install upgrade-agent@upgrade-agent-pluginsインストール後に次のコマンドを実行します。
/agentエージェント一覧にupgrade-agentが表示されれば導入できています。(Microsoft Learn)
GitHub Copilot appで利用する場合
GitHub Copilot appでは、設定画面の「Plugins」からMicrosoftのマーケットプレイスを追加します。
手順は次のとおりです。
- GitHub Copilot appの「Settings」を開く
- 「Plugins」を選択する
upgrade-agent-pluginsマーケットプレイスを追加するupgrade-agentをインストールする- Agent pickerで「Upgrade」を選択する
/agentを実行し、upgrade-agent:upgradeが表示されることでも確認できます。(Microsoft Learn)
既存実装との互換性はどうなるのか
インストールしただけでは既存コードは変わらない
GitHub Copilot modernizationを追加しただけでは、TargetFramework、NuGetパッケージ、ソースコード、設定ファイルは変更されません。
コード変更が始まるのは、対象プロジェクトを開き、アップグレード内容を指定してエージェントの実行を開始した後です。したがって、拡張機能やコンポーネントの配布自体が、既存システムの動作に直接影響する可能性は低いと考えられます。(Microsoft Learn)
互換性の判定はアップグレード開始後に行われる
エージェントはアップグレード開始時に、プロジェクト構成、依存関係、コードパターンを調査します。
評価結果はassessment.mdに記録され、主に次の情報が整理されます。
- 破壊的変更
- API互換性の問題
- 非推奨となった実装
- 更新が必要なNuGetパッケージ
- プロジェクト間の依存関係
- 更新対象となるファイルやプロジェクト
- アップグレード全体の範囲
ただし、評価結果は自動生成です。公開APIの互換性、外部システムとの通信仕様、データベースの暗黙的な前提など、コードから完全には判断できない条件は人が追加する必要があります。(Microsoft Learn)
アップグレード状態はリポジトリ内に保存される
エージェントの評価、計画、進行状況は、次のようなファイルとして保存されます。
.github/upgrades/{scenarioId}/
├─ assessment.md
├─ upgrade-options.md
├─ plan.md
├─ tasks.md
├─ scenario-instructions.md
└─ tasks/このフォルダーが残っていれば、IDEを閉じた後でも作業を再開できます。Visual Studio Codeで開始し、後からVisual Studioに切り替えて続行することも想定されています。
.github/upgrades/を作業ブランチにコミットしておくと、途中状態のバックアップやチーム内レビューにも利用できます。(Microsoft Learn)
Gitリポジトリの扱いには公式ドキュメント上の差がある
公式FAQでは「ローカルGitリポジトリが必要」とされています。一方、ベストプラクティスとトラブルシューティングでは、Git管理されていないフォルダーでも動作するものの、ブランチ作成やコミットを行わず、ファイルを直接変更すると説明されています。
このため、実務ではGitを事実上の必須条件として扱うのが安全です。Gitを利用すれば、タスク単位の変更確認、個別コミットの取り消し、必要な変更だけのcherry-pickが可能になります。(Microsoft Learn)
導入前に確認するチェックリスト
本番システムや重要な業務アプリで利用する前に、次の条件を確認します。
| 確認項目 | 判断基準 |
|---|---|
| Visual Studioのバージョン | 2022の場合は17.14.17以降 |
| Copilot利用権 | 対象アカウントでCopilot Chatを利用できる |
| ネットワーク | Copilotと必要なSDK・NuGetフィードへ接続できる |
| Gitの状態 | 未コミット変更がなく、作業ブランチを作成できる |
| 現行ビルド | アップグレード前の状態でビルドが成功する |
| 現行テスト | 既知の失敗を除き、テストが成功する |
| NuGetフィード | プライベートフィードの認証が完了している |
| SDK | 更新先の.NET SDKをCIと開発端末で利用できる |
| テスト範囲 | API、DB、認証など影響範囲を検証できる |
| ロールバック | 元ブランチまたは旧リリースへ戻せる |
特に重要なのは、アップグレード前のビルドとテストを成功させておくことです。開始時点で失敗しているテストがあると、エージェントが「元から存在した失敗」と「変更によって発生した失敗」を区別できません。
既知のテスト失敗がある場合は、scenario-instructions.mdに明記してから開始します。(Microsoft Learn)
テスト時に注意すべきポイント
タスク完了と本番利用可能は同じではない
GitHub Copilot modernizationでは、コード変更後にビルドとテストを実行し、成功したタスクを完了として扱います。
しかし、既存テストが確認していない仕様までは保証されません。tasks.mdが100％になっていても、それだけで本番移行可能とは判断しないことが重要です。公式ドキュメントも、完了後に失敗したテストやコンパイルエラーを確認し、NuGetパッケージの互換性とアプリ全体の動作を検証するよう求めています。(Microsoft Learn)
アップグレード前後で比較すべきテスト
| テスト対象 | 確認例 |
|---|---|
| ビルド・復元 | 全プロジェクト、全構成でrestoreとbuildが成功する |
| 単体テスト | 更新前後で成功件数と結果が一致する |
| API契約 | HTTPステータス、JSON構造、必須項目、エラー形式が変わっていない |
| シリアライズ | 日付、列挙値、null、循環参照などの出力が変わっていない |
| データアクセス | 主要検索、登録、更新、削除、トランザクションが正常に動く |
| 認証・認可 | ログイン、権限、トークン、セッションの動作を確認する |
| バックグラウンド処理 | ジョブ、タイマー、キュー、Functionsのトリガーを確認する |
| OS依存処理 | ファイルパス、証明書、レジストリ、環境変数を確認する |
| UI | 主要画面、入力チェック、画面遷移を確認する |
| 性能 | 起動時間、応答時間、メモリ使用量を更新前と比較する |
| デプロイ | ステージング環境への配置とロールバックを確認する |
テストカバレッジを100％にする必要はありません。ただし、移行で変更されやすいAPI境界、シリアライズ、データベースアクセス、認証処理は優先的にテストすべき領域です。(Microsoft Learn)
private NuGetフィードは事前に認証する
社内パッケージやAzure ArtifactsなどのプライベートNuGetフィードを利用している場合は、エージェントを実行する前に認証を完了させます。
パッケージ復元が失敗すると、依存関係の評価やビルド検証が停止します。まず手動で次のコマンドが成功する状態を作ってください。
dotnet restoreその後にモダナイゼーションを開始することで、認証問題と互換性問題を切り分けやすくなります。(Microsoft Learn)
カスタムMSBuild処理は明示する
独自の.targetsファイル、条件付きインポート、コード生成、特殊なビルドスクリプトを利用している場合、エージェントが依存関係を正しく判断できないことがあります。
次のような制約は、開始時にscenario-instructions.mdへ記録します。
Generatedフォルダーのコードは直接変更しない。
Company.Build.targetsは全プロジェクトで必須。
PublicApiプロジェクトの公開インターフェースは変更しない。
LegacyReportsプロジェクトは今回の更新対象から除外する。アーキテクチャ上の暗黙的なルールを文章化して渡すことが、AIによる誤変更を減らす有効な管理策になります。(Microsoft Learn)
企業や開発チームで必要な管理策
GitHub Copilot modernizationは、「インストール」「実行」「マージ」を分けて管理することが重要です。
インストールの管理
拡張機能やプラグインを自由に導入させるのではなく、次の項目を標準化します。
- 利用を認めるVisual Studio、Visual Studio Codeのバージョン
- 配布する拡張機能とプラグイン
- Copilotを利用できるアカウント
- 自動取得を許可する.NET SDK
- プロキシやファイアウォールの接続先
- テレメトリの設定
Visual Studio Codeでは不足している.NET SDKが自動取得されるため、端末管理が厳しい組織では、先に承認済みSDKを配布しておく運用が適しています。
実行の管理
初回から重要システム全体を自動モードで更新するのは避けます。
実務では、次のルールが有効です。
- 小規模なクラスライブラリや社内ツールで試行する
- 専用のアップグレードブランチを作る
- 最初はGuidedモードを利用する
assessment.mdを人が確認するplan.mdとtasks.mdを承認してから実行する- タスク単位で変更内容とテスト結果を確認する
公式のベストプラクティスでも、初回は小規模で低リスクなプロジェクトを選び、Guidedモードから始めることが推奨されています。(Microsoft Learn)
マージの管理
エージェントが作成したコミットを、そのままメインブランチへ反映しない運用にします。
最低限、次のゲートを設けます。
- Pull Requestによるレビュー
- アプリ担当者によるコードレビュー
- CIでのビルドと自動テスト
- 依存パッケージと脆弱性の確認
- ステージング環境での結合テスト
- ロールバック手順の確認
- 変更された公開APIと設定項目の確認
エージェントはタスク単位で細かくコミットできるため、必要な変更だけをcherry-pickし、問題のある変更を除外する運用も可能です。(Microsoft Learn)
データとテレメトリの管理
公式FAQでは、GitHub Copilot modernizationエージェントはコードベースを保存せず、モデルの学習にも使用せず、アップグレード完了後にセッションデータを削除すると説明されています。
収集されるテレメトリは、プロジェクトの種類、アップグレードの意図、処理時間などで、ユーザーを特定する情報は含まれないとされています。Visual Studioではプライバシー設定からテレメトリを無効化できます。(Microsoft Learn)
一方、.github/upgrades/には、依存関係、移行方針、アーキテクチャ上の制約などが記録される可能性があります。このフォルダーを共有リポジトリへプッシュする場合は、機密情報や内部構成が含まれていないか確認してください。
GitHub Copilot modernizationを導入すべきか判断する基準
| 判断 | 該当する状況 |
|---|---|
| 今すぐ試行する | 古い.NET Coreや.NET Frameworkからの更新を計画しており、Gitと自動テストを利用できる |
| 小規模なPoCから始める | 大規模ソリューション、複雑な依存関係、独自MSBuild処理がある |
| 準備後に導入する | テスト不足、未整理のNuGet依存関係、プライベートフィードの認証問題がある |
| 当面見送る | オフライン環境、変更凍結期間、本番相当の検証環境がない |
| 対応不要 | .NETアップグレードやAzure移行を予定していない |
特に、50を超えるプロジェクトを含む大規模ソリューションでは、一括更新よりも代表的な1プロジェクトで試行し、問題点を確認してから対象を広げる方法が適しています。(Microsoft Learn)
まず小規模プロジェクトで評価してから展開する
「Install GitHub Copilot modernization – .NET Core」の更新は、既存アプリに強制適用されるものではありません。Visual Studio、Visual Studio Code、Copilot CLI、Copilot appから、必要なチームだけが導入できます。
対応を進める場合は、次の順序が安全です。
- Visual StudioやCopilotの利用条件を確認する
- Gitの作業ブランチと正常なビルド・テスト結果を用意する
- 小規模なプロジェクトへインストールする
- Guidedモードで評価結果と移行計画を確認する
- エージェントの変更をPull Requestとしてレビューする
- API、データベース、認証、性能、デプロイを検証する
- 問題がなければ対象プロジェクトを段階的に広げる
導入価値が高いのは、古い.NET Coreや.NET Frameworkからの移行を控えている一方で、依存関係の調査や移行計画の作成に時間がかかっているチームです。反対に、テストがほとんどなく、元の仕様も整理されていないシステムでは、先にテストとGit運用を整備する必要があります。
GitHub Copilot modernizationはアップグレード作業を支援する「Copilot」であり、互換性を完全に保証する「Autopilot」ではありません。AIに変更を任せる範囲と、人が判断・承認する範囲を明確にすることが、安全な導入のポイントです。
コメント