.NETアプリのアップグレードでは、依存関係の調査、移行方針の決定、コード修正、ビルドエラーの解消、テストまでを継続的に管理する必要があります。GitHub Copilot appの今回の更新では、これらの工程を一つの画面で確認・操作できる「対話型アップグレードキャンバス」が追加されました。
結論として、既存の.NETアプリが自動的に変更されたり、従来のVisual StudioやVisual Studio Codeでの運用が使えなくなったりする更新ではありません。すぐに対応が必要なのは、.NET Frameworkや旧.NETからの移行を予定している組織、またはCopilotによる変更内容をチャットだけでなく視覚的に管理したいチームです。既にGitHub Copilot modernizationを利用している場合も、強制的な移行は不要で、GitHub Copilot appを追加の操作画面として評価できます。(Microsoft for Developers)
GitHub Copilot appの.NETモダナイゼーション更新とは
Microsoftの.NET Blogでは、公式ページ上で2026年7月9日付として「Modernize .NET applications in the GitHub Copilot app」が公開されました。本記事では、指定された2026年7月10日の実質更新として内容を整理します。(Microsoft for Developers)
今回追加された中心機能は、GitHub Copilot app内で利用できるInteractive Upgrade Canvasです。画面上では「Upgrade Dashboard」として開き、次の情報を一つのビューで確認できます。
- 対象アプリケーションの評価結果
- NuGetパッケージやAPIの互換性問題
- アップグレード方針
- 実装タスクと進捗
- 変更されたコード
- ビルドエラー
- 実行結果と残作業
これまでのGitHub Copilot modernizationでは、チャット、生成されたMarkdownファイル、ソースコードの差分を行き来しながら状況を把握する必要がありました。新しいキャンバスでは、評価から実行までの状態をライブ表示し、作業の確認と方向修正を行いやすくしています。(Microsoft for Developers)
名称の違いを整理
公式情報では似た名称が使われているため、次のように整理すると理解しやすくなります。
| 名称 | 意味 |
|---|---|
| GitHub Copilot modernization | .NETアップグレードやAzure移行を支援する機能全体 |
| GitHub Copilot upgrade | アップグレード処理を担当するエージェントまたはプラグイン |
| Upgrade | GitHub Copilot appなどのAgent Pickerに表示されるエージェント名 |
| Upgrade Dashboard | 対話型アップグレードキャンバスを開く画面 |
.github/upgrades/ | 評価結果、計画、タスク、進捗を保存するリポジトリ内フォルダー |
名称は異なりますが、評価、計画、実行という基本ワークフローは共通です。(GitHub)
今回の更新で何が変わったのか
主な変更点は、アップグレードエンジンそのものよりも、進捗確認と人間による介入方法の改善です。
| 項目 | 従来の運用 | GitHub Copilot appの新しい運用 |
|---|---|---|
| 評価結果 | assessment.mdを開いて確認 | キャンバス上で確認 |
| 移行方針 | チャットとupgrade-options.mdで確認 | キャンバスから全体像を確認 |
| 計画 | plan.mdを個別に開く | 評価結果と関連付けて確認 |
| タスク進捗 | tasks.mdを開いて追跡 | ライブ表示で追跡 |
| ビルドエラー | チャットや出力ログを確認 | アップグレードの流れの中で確認 |
| コードレビュー | エディターやGit差分へ移動 | レビューパネルと連携して確認 |
| 操作の修正 | チャットで追加指示 | キャンバスとチャットを使って方向修正 |
従来のMarkdownファイルが廃止されたわけではありません。キャンバスは、リポジトリ内に保存される評価・計画・タスク情報を見やすくし、操作しやすくするための追加インターフェースです。(Microsoft for Developers)
変わらない点と既存実装への影響
今回の更新によって、運用中の.NETアプリケーションや本番環境が自動的に書き換えられることはありません。利用者がリポジトリを開き、Upgradeエージェントを選択してアップグレードを開始した場合にのみ、評価やコード変更が行われます。(Microsoft for Developers)
また、次の基本仕様は従来どおりです。
- 評価、計画、実行の3段階で進む
- アップグレード方針を人間が確認・変更できる
- Gitのブランチとコミットを利用して変更を分離できる
- 状態は
.github/upgrades/{scenarioId}/に保存される - Visual Studio、Visual Studio Code、GitHub Copilot CLIでも利用できる
- ビルドとテストを実行して変更を検証する
- エージェントが解決できない問題では利用者の判断を求める
GitHub Copilot appを導入しても、既存のVisual StudioやVisual Studio Code中心の開発手順を置き換える必要はありません。キャンバスによる可視化が必要なメンバーだけがアプリを利用し、実装担当者は従来のIDEを使い続ける構成も可能です。(Microsoft for Developers)
既存のアップグレード状態は引き継げるのか
GitHub Copilot modernizationは、評価結果や計画、進捗をリポジトリ内の.github/upgrades/{scenarioId}/に保存します。Microsoft Learnでは、この状態を利用してセッションを終了した後に再開したり、Visual Studio CodeからVisual Studioへ開発環境を切り替えたりできると説明されています。(Microsoft Learn)
GitHub Copilot appも同じUpgradeワークフローを利用するため、設計上は既存の状態ファイルを活用できます。ただし、初回導入時は次の点をテストブランチで確認してください。
- 既存の
scenarioIdが正しく認識されるか tasks.mdの完了状態がキャンバスに反映されるか- 手動編集した
plan.mdやscenario-instructions.mdが読み込まれるか - 利用中のプラグインとアプリのバージョンが一致しているか
- IDE側とアプリ側で同じブランチを同時編集していないか
特に並行編集は、タスク状態や計画ファイルの競合につながります。一つのアップグレードシナリオを複数の環境で同時実行するのではなく、作業担当と使用環境を明確に分けるのが安全です。
対応が必要かを判断する基準
| 利用状況 | 対応要否 | 推奨対応 |
|---|---|---|
| .NETアップグレードの予定がない | 原則不要 | 情報収集のみでよい |
| Visual StudioのModernizeを利用中 | 任意 | キャンバスの必要性を評価する |
| Visual Studio CodeやCLIでアップグレード中 | 任意 | 既存状態を複製した検証ブランチで試す |
| .NET Frameworkから現行.NETへ移行予定 | 対応を推奨 | 小規模プロジェクトで先行検証する |
| 大規模ソリューションを移行予定 | 段階導入 | 代表的な1プロジェクトから試す |
| テストが少ないレガシーシステム | 慎重に導入 | 先に回帰テストを追加する |
| 金融、医療、行政など変更管理が厳しい | 管理策が必要 | Guidedモードと人手レビューを必須にする |
| 非Git管理のソースコード | 事前対応が必要 | ローカルGitを初期化してベースラインを保存する |
この機能は「移行作業を完全自動化するツール」ではなく、AIエージェントと人間が評価・計画・修正を分担するためのワークフローです。テストが少ないシステムや、仕様を把握している担当者がいないシステムでは、導入前の準備に時間をかける必要があります。(Microsoft Learn)
利用条件
GitHub Copilot appで.NETモダナイゼーションを利用するには、アプリ本体に加えてUpgradeエージェントのプラグインを追加します。
GitHub Copilot app側の条件
- GitHub Copilot appがインストールされていること
- GitHubアカウントでサインインできること
- GitHub Copilotを利用できるプランがあること
- BusinessまたはEnterpriseでは、管理者がCopilot CLIポリシーを有効にしていること
microsoft/upgrade-agent-pluginsマーケットプレイスを追加できることupgrade-agentプラグインをインストールできること
GitHub公式ドキュメントでは、GitHub Copilot appはすべてのCopilotプランで利用でき、Windows、Linux、macOSをサポートしています。一方、Copilot BusinessとCopilot Enterpriseでは、管理者によるCopilot CLIポリシーの有効化が必要です。(GitHub Docs)
.NETプロジェクト側の条件
GitHub Copilot modernizationは、C#およびVisual Basicのプロジェクトを対象としています。主な対応プロジェクトは次のとおりです。
- ASP.NET Core、MVC、Razor Pages、Web API
- ASP.NET Web Forms
- Blazor
- Azure Functions
- WPF
- Windows Forms
- WinUI
- .NET MAUI、Xamarin
- クラスライブラリ
- コンソールアプリ
- MSTest、NUnit、xUnitのテストプロジェクト
主なフレームワークアップグレード経路は、.NET Frameworkから.NET 8以降、.NET Core 1.x～3.xから.NET 8以降、.NET 5以降から.NET 8以降です。.NET Frameworkを維持しながら4.8.1へ更新する経路も示されています。(Microsoft Learn)
Gitリポジトリに関する公式情報の差
Gitの扱いについては、公式ドキュメント内に記述の差があります。
GitHub Copilot modernizationのFAQでは、制限事項として「ローカルGitリポジトリが必要」と記載されています。一方、ベストプラクティスとトラブルシュートでは、Git管理されていないフォルダーでも動作するものの、ブランチやコミットを作成せず、ファイルへ直接変更を適用すると説明されています。(Microsoft Learn)
実務では、この差を「非Gitでも安全に使える」と解釈しない方がよいでしょう。次のように、Gitを事実上の必須条件として扱うことを推奨します。
git init
git add .
git commit -m "Baseline before Copilot modernization"Gitを使えば、タスクごとの変更確認、問題のあるコミットの取り消し、元ブランチへの復帰が容易になります。
Visual Studio、VS Code、CLIとの違い
| 利用環境 | 導入方法 | 主な特徴 |
|---|---|---|
| GitHub Copilot app | マーケットプレイスとUpgradeプラグインを追加 | Upgrade Dashboardを利用できる |
| Visual Studio | プロジェクトを右クリックしてModernizeを選択 | ソリューションエクスプローラーと統合 |
| Visual Studio Code | GitHub Copilot upgrade拡張機能を導入 | エディター内でUpgradeエージェントを利用 |
| GitHub Copilot CLI | マーケットプレイスとプラグインをコマンドで追加 | ターミナル中心で操作できる |
Visual Studioで利用する場合、公式ドキュメントではWindows、Visual Studio 2026またはVisual Studio 2022 17.14.17以降、GitHub CopilotとGitHub Copilot app modernizationのオプションコンポーネントが条件として示されています。Visual Studio CodeではGitHub Copilot拡張機能とGitHub Copilot upgrade拡張機能、CLIではGitHub Copilot CLIが必要です。(Microsoft Learn)
GitHub Copilot app固有の価値は、コードを直接編集しやすいことではなく、評価から実行までをキャンバスで追跡できる点です。コードの細かな修正はIDE、全体進捗の確認やレビューはアプリという役割分担も考えられます。
GitHub Copilot appでUpgrade Dashboardを導入する手順
事前にビルドとテストを成功させる
アップグレード前に、現在のソースコードで次を実行します。
dotnet restore
dotnet build
dotnet test
git status既存のビルドエラーやテスト失敗が残っていると、エージェントが「もともとの問題」と「アップグレードで発生した問題」を区別できません。既知のテスト失敗を残す場合は、scenario-instructions.mdに明記します。(Microsoft Learn)
Upgradeプラグインを追加する
- GitHub Copilot appをインストールしてサインインします。
- 公式のUpgradeマーケットプレイス追加リンクを開きます。
- 「Add plugin marketplace?」で「Allow」を選択します。
- Plugins画面で「Add marketplace」を選択します。
upgrade-agent-pluginsを展開します。upgrade-agentの「Install」を選択します。- リポジトリを開き、新しいエージェントセッションを開始します。
- Agent Pickerで「Upgrade」を選択します。
GitHub Copilot appのバージョンが1.0.3より前の場合、プラグインをインストールした後にアプリの再起動が必要とされています。Upgradeエージェントが表示されない場合は、最初にアプリの更新と再起動を確認してください。(GitHub)
Upgrade Dashboardを開く
- GitHub Copilot app右上のレビューパネルアイコンを選択します。
- レビューパネル内の「＋」を選択します。
- 「Upgrade Dashboard」を選択します。
- 対象フレームワークやアップグレード内容を指示します。
例えば、.NET 6から.NET 10へ更新する場合は、次のように対象を具体化します。
Upgrade the DataAccess and WebApi projects from .NET 6 to .NET 10.
Keep the public API backward compatible.
Do not modify generated files.
Use guided mode and commit after each completed task.単に「全部アップグレードして」と指示するより、対象プロジェクト、目標バージョン、互換性要件、変更禁止ファイルを指定した方が、計画の精度を高めやすくなります。(Microsoft Learn)
生成されるファイルと確認ポイント
アップグレードを開始すると、.github/upgrades/{scenarioId}/に状態ファイルが作成されます。
| ファイル | 確認する内容 |
|---|---|
assessment.md | 対象プロジェクト、依存関係、非互換API、対象範囲 |
upgrade-options.md | 移行順序、インプレースか並行移行か、互換性方針 |
plan.md | 作業順序、パッケージ更新、リスク対策 |
tasks.md | 実装タスク、検証条件、現在の進捗 |
scenario-instructions.md | チーム固有の制約、禁止事項、設計方針 |
tasks/{taskId}/task.md | 個別タスクの対象範囲 |
tasks/{taskId}/progress-details.md | 実行内容、エラー、修正結果 |
これらは単なるログではなく、エージェントが次の作業を判断するための状態情報です。削除すると作業を再開できなくなる可能性があるため、アップグレード用ブランチへコミットして管理します。(Microsoft Learn)
ただし、scenario-instructions.mdには機密情報や接続文字列を書かないでください。保存するのは「このモジュールは変更しない」「認証方式は維持する」「公開APIを壊さない」といった設計上の制約に限定します。
企業で導入するときの管理策
最初はGuidedモードを使う
GitHub Copilot modernizationには、主に次の進行方法があります。
- Automatic：重大な問題が発生するまで自動的に進行する
- Guided：評価、計画、実行の区切りで停止し、利用者の確認を求める
初回導入や複雑なシステムではGuidedモードを選択し、assessment.md、upgrade-options.md、plan.md、tasks.mdを段階ごとに承認する運用が適しています。公式のベストプラクティスでも、最初のアップグレードではGuidedモードが推奨されています。(Microsoft Learn)
本番ブランチへ直接変更させない
次の運用ルールを設定します。
- mainやreleaseブランチでは実行しない
- アップグレード専用ブランチを作る
- タスク単位でコミットする
- プルリクエストを必須にする
- CIの成功だけで自動マージしない
- パッケージ更新は担当者がバージョンとライセンスを確認する
- 認証、データベース、公開APIは専門担当者をレビュアーに指定する
小さなコミットに分けることで、正常な変更だけをcherry-pickし、問題がある変更を破棄できます。
プラグインを全社一斉導入しない
最初は次のような小規模な対象が適しています。
- 依存関係が少ないクラスライブラリ
- 社内向けの小規模API
- 十分な単体テストがあるユーティリティ
- 本番データへ接続しない検証用リポジトリ
公式のベストプラクティスでも、初回は低リスクの小規模プロジェクトを選び、大規模ソリューションでは代表的な1プロジェクトを先に検証することが推奨されています。(Microsoft Learn)
プライバシーとテレメトリを確認する
Microsoft LearnのFAQでは、GitHub Copilot modernizationはコードベースを保存せず、モデルの学習にも利用せず、アップグレード完了後にセッションデータを削除すると説明されています。また、収集するテレメトリは、プロジェクト種別、アップグレード意図、処理時間などの集約情報とされています。(Microsoft Learn)
ただし、企業利用ではこの説明だけで判断せず、契約中のCopilotプラン、組織ポリシー、ネットワーク経路、社内のソースコード持ち出し基準を確認してください。テレメトリは開発環境側のプライバシー設定から無効化できる場合があります。
テスト時に注意すべきポイント
GitHub Copilot upgradeがビルドとテストを成功させても、アプリケーションの動作が完全に維持されたとは限りません。公式FAQでも、提案が常にベストプラクティスに従う保証はなく、トラブルシュートではAIがコンパイルできないコードを生成する可能性が示されています。(Microsoft Learn)
ビルド前の基準値を保存する
アップグレード前に、次の結果を保存しておきます。
dotnet --infodotnet restoreの結果- ビルド警告とエラー件数
- 単体テスト件数と成功数
- APIの応答例
- 主要画面のスクリーンショット
- パフォーマンステスト結果
- NuGetパッケージ一覧
- データベーススキーマとマイグレーション状態
変更後の結果を基準値と比較することで、単純なテスト成功だけでは見つからない差を確認できます。
テスト対象を機能別に分ける
| テスト領域 | 主な確認内容 |
|---|---|
| API互換性 | URL、HTTPメソッド、ステータスコード、JSON構造 |
| シリアライズ | null、列挙型、日付、プロパティ名、既定値 |
| 認証・認可 | Cookie、トークン、ロール、セッション、有効期限 |
| データベース | SQL、トランザクション、文字コード、NULL処理 |
| 設定 | web.config、appsettings.json、環境変数 |
| DI | サービスのライフタイム、循環参照、起動順序 |
| ロギング | ログレベル、構造化ログ、例外情報 |
| ファイル処理 | パス、権限、改行、大小文字、共有フォルダー |
| UI | DPI、フォント、入力、レイアウト、印刷 |
| 性能 | 起動時間、メモリ、CPU、スループット |
| セキュリティ | 脆弱なパッケージ、秘密情報、認可漏れ |
特に、Newtonsoft.JsonからSystem.Text.Jsonへの変更、System.Data.SqlClientからMicrosoft.Data.SqlClientへの変更、ASP.NET Web FormsからBlazorへの移行は、コンパイルが成功しても実行時の挙動が変わる可能性があります。GitHub Copilot modernizationにはこれらの専用シナリオが用意されていますが、業務仕様に沿った回帰テストは別途必要です。(Microsoft Learn)
プライベートNuGetフィードを事前確認する
プライベートNuGetフィードを利用している場合は、アップグレード開始前に手動でdotnet restoreを成功させます。認証トークン、Credential Provider、NuGet.config、プロキシ設定が不完全だと、パッケージ互換性ではなく認証エラーで処理が停止します。(Microsoft Learn)
カスタムMSBuild処理を明示する
次のような構成は、エージェントが依存関係を正しく判断できないことがあります。
- 独自の
.targetsや.props - 条件付きImport
- ビルド時コード生成
- 外部スクリプトの実行
- 社内専用SDK
- 非標準の出力ディレクトリ
- プロジェクトファイル外で管理する依存関係
該当する場合は、scenario-instructions.mdに「変更してよいファイル」「実行してはいけない処理」「必要なビルド手順」を記載します。(Microsoft Learn)
大規模ソリューションは分割する
50以上のプロジェクトを含むソリューションでは、評価、パッケージ復元、ビルド、修正の反復に時間がかかります。公式ドキュメントでは、関連するプロジェクトをグループ化し、複数回に分けてアップグレードする方法が推奨されています。(Microsoft Learn)
実務では、次の順序が比較的管理しやすくなります。
- 共通ライブラリ
- データアクセス層
- 業務ロジック
- Web API
- UIプロジェクト
- バッチや周辺ツール
- テストプロジェクト
- デプロイ設定
ただし、依存方向によっては順序を変える必要があります。Upgradeエージェントが提案するBottom-up、Top-down、All-at-onceの方針をそのまま承認せず、実際の依存関係とリリース単位に照らして判断してください。
よくある失敗と対処法
Upgradeエージェントが表示されない
- GitHub Copilot appを更新する
- アプリを再起動する
upgrade-agentがInstalledになっているか確認する- BusinessまたはEnterpriseのCopilot CLIポリシーを確認する
- Agent Pickerを再度開く
アプリのバージョンが1.0.3より前の場合は、インストール後の再起動が必要です。(GitHub)
「利用できるシナリオがない」と表示される
ワークスペースのルートに.sln、.csproj、.vbprojのいずれかがあるか確認します。サブディレクトリにある場合は、そのディレクトリをワークスペースとして開くか、対象ファイルを明示します。(Microsoft Learn)
以前の作業を再開できない
.github/upgrades/が削除、破損、Git管理対象外になっていないか確認します。状態ファイルを復元できない場合は、再評価と再計画が必要です。(Microsoft Learn)
同じ修正を繰り返して進まない
エージェントが同じ修正を繰り返す場合は処理を停止し、直前のコミットへ戻します。その上で、問題のAPI、期待する実装方法、使用禁止のパッケージを具体的に指示します。
Stop the current task.
Revert the last change.
Do not use System.Web adapters.
Replace the affected code with native ASP.NET Core APIs.
Show the proposed changes before applying them.AIによる修正は決定的な変換ではありません。何度実行しても同じ結果になるとは限らないため、再実行前に条件を明文化することが重要です。
対応方針のまとめ
GitHub Copilot appの対話型モダナイゼーションワークフローは、.NETアップグレードの評価、計画、実装、ビルド、テストを一つのキャンバスで追跡できるようにする更新です。既存アプリへ自動適用されるものではなく、Visual Studio、Visual Studio Code、CLIでの従来運用も継続できます。
現時点で.NETアップグレードの予定がなければ、急いで導入する必要はありません。一方、.NET Frameworkやサポート期限が近い.NETからの移行を予定している場合は、次の順序で評価すると安全です。
- 現行コードのビルドとテストを成功させる
- 小規模で低リスクなプロジェクトを選ぶ
- Gitの専用ブランチを作成する
- GitHub Copilot appとUpgradeプラグインを導入する
- Guidedモードで評価と計画だけを実行する
- 人間が計画を修正してからコード変更を許可する
- CIに加えて業務機能の回帰テストを実施する
最初の評価では、コード変更の速さよりも、依存関係の検出精度、計画の妥当性、ロールバックの容易さを確認してください。その3点を満たせる場合に、対象プロジェクトと利用者を段階的に拡大するのが現実的です。
コメント