GitHub Copilot アプリのアップグレードキャンバス — .NET の移行を1画面で追えるようにする

Microsoft は 2026 年 7 月 9 日、GitHub Copilot アプリに アップグレードキャンバス を搭載したことを発表しました。.NET アプリケーションの評価から計画、実行、進捗の追跡までを 1 つの画面で扱えるようにするもので、エージェントとの対話と、その結果として何が起きているのかを並べて確認できます。

移行作業で困るのは、エージェントが何をしたのかが会話ログの中に埋もれてしまうことです。どのプロジェクトが評価済みで、どのタスクが終わっていて、どのファイルが書き換わったのか。キャンバスはこれらを構造化して見せることで、AI に任せた作業を人間がレビューできる形に保ちます。本記事では、公式発表とプラグインのリポジトリをもとに、この仕組みが何を変えるのかを整理します。

会話ログではなく、状態を見せる

従来のエージェント型の移行支援は、チャットの流れとして進みます。指示を出し、応答を読み、次の指示を出す。作業自体は進みますが、全体がどこまで来ているのかは、過去のやり取りを遡らないとわかりません。長い移行になるほど、この確認コストが効いてきます。

アップグレードキャンバスは、画面を左右に分けます。左側はエージェントとの対話、右側が Code Upgrade と名付けられたキャンバスです。キャンバスには概要・シナリオ・タスク・プロジェクト・依存関係・評価・オプション・アクティビティといったタブが並び、上部には全体の進捗が数値で表示されます。会話を追わなくても、いま何が終わっていて何が残っているかが一目で掴めます。

概要タブに並ぶ数値は、そのまま移行の見積もり材料になります。公式デモでは、評価済みプロジェクト数、評価で検出された指摘の件数、アップグレード完了前に必ず解消しなければならないルールの件数、ソリューション全体で使われている NuGet パッケージ数、そのうち移行先のフレームワークと互換性のないパッケージ数が、それぞれカードとして表示されています。とくに「必ず直すべきルール」と「非互換パッケージ」の 2 つは、着手前に工数を左右する要素なので、最初に確認しておきたい数字です。

評価・計画・実行・追跡という4つの段階

キャンバスが扱う流れは 4 つに分かれています。最初の評価では、対象がどの .NET バージョンを目指すべきか、更新すべき NuGet パッケージはどれか、破壊的な API 変更が含まれていないか、プロジェクトを個別に更新できるかといった点を洗い出します。概要タブに出る「評価で見つかった指摘の件数」「アップグレード前に必ず直すべきルールの件数」は、この段階の出力です。

次の計画では、評価結果を構造化されたアップグレード計画に変換します。計画は Markdown として生成され、シナリオの設定を記す scenario-instructions.md や、選択肢を定義する upgrade-options.md といったファイルが作られます。人が読んで直せる形式である点は、判断の根拠を残すうえで重要です。

続く実行では、計画から起こしたタスクを段階的に進めます。そして追跡のフェーズで、キャンバスがコードの変更内容、ビルドの失敗、最終的な結果を表示します。アクティビティタブには、どのファイルがいつ作成・変更・削除されたかが時系列で並びます。

タブの構成にも意味があります。プロジェクトのタブでは対象ソリューションに含まれる各プロジェクトの状態を、依存関係のタブでは NuGet パッケージと互換性の判定を、評価のタブでは検出されたルール違反の内訳を確認できます。オプションのタブでは、移行の方針にあたる選択肢を切り替えられます。会話の中で「いまどのプロジェクトを触っているのか」を聞き返さなくても、キャンバス側を見れば済むという設計です。

対応する移行シナリオ

想定されているシナリオは、.NET Framework から .NET Core 系への移行、パッケージのバージョン更新、ASP.NET / ASP.NET Core プロジェクトの変換、System.Web Adapters の取り扱い、そして依存関係の整理と互換性問題への対応です。公式のデモでは dotnet-version-upgrade というシナリオで、対象プロジェクトを net10.0 へ引き上げる流れが示されています。

System.Web Adapters が明示されている点は実務上ありがたいところです。ASP.NET から ASP.NET Core への移行では、System.Web に依存したコードをどう扱うかが最初の関門になります。アダプターを挟んで段階的に移すのか、直接書き換えるのか。この判断がシナリオとして用意されていれば、方針を決めたうえで作業に入れます。

シナリオはプラグインとして提供される仕組みになっています。つまり、対応する移行パターンは固定ではなく、追加されていく前提の設計です。自社に固有の移行パターンがある場合に、それをシナリオとして持ち込める余地があるかどうかは、長期的に見ると効いてくる部分でしょう。

どこから使えるのか

利用できる入口は 1 つではありません。GitHub Copilot アプリにはアップグレードのダッシュボードが載っており、Visual Studio ではソリューションエクスプローラーの右クリックメニューから「Modernize」を選べます。Visual Studio Code では Upgrade Agent 拡張機能を入れ、ターミナル派には GitHub Copilot CLI からプラグイン経由という選択肢があります。

いずれの入口でも、microsoft/upgrade-agent-plugins のマーケットプレイスから upgrade-agent プラグインを入れる必要があります。CLI であれば次のコマンドでマーケットプレイスを追加します。

/plugin marketplace add microsoft/upgrade-agent-plugins

環境面では、Visual Studio の Insider または最新版が前提になります。また実行には Copilot のクレジットを消費します。長い移行を回す場合は、この点も見積もりに入れておいた方がよいでしょう。

実務で使うときに意識したいこと

キャンバスの価値は、AI に任せた作業をレビュー可能な状態に保つことにあります。生成された計画が Markdown で残り、変更されたファイルがアクティビティとして並ぶため、あとから「なぜこの順序で進めたのか」「どこで何が壊れたのか」を追えます。移行はやり直しが効きにくい作業なので、この追跡可能性は効いてきます。

一方で、公式記事のコメント欄では利用者から課題も報告されています。ASP.NET / ASP.NET Core の移行における複雑さ、承認を求められる回数の多さ、セッションの安定性といった点です。エージェントが一気通貫で片付けてくれるというより、判断を挟みながら伴走させる道具だと捉えた方が実態に近いと思われます。

実務で導入するなら、いきなり基幹システム全体にかけるのではなく、まず小さめのプロジェクトで評価だけを走らせ、出てくる指摘の粒度と量を確かめるところから始めるのが現実的です。そのうえで、どこまでをエージェントに任せ、どこから人が引き取るかの線を引きます。段階移行の設計そのものについては、.NET Framework から .NET 10 への移行プレイブックもあわせてご覧ください。

まとめ

アップグレードキャンバスは、エージェントによる .NET 移行を「会話」から「状態」へと引き上げる仕組みです。評価で何が見つかり、計画がどう組まれ、いまどのタスクが動いていて、結果としてどのファイルが変わったのか。それらが 1 画面に揃うことで、AI に作業を任せながらも判断の主導権を手放さずに済みます。まずは小さな対象で評価を回し、自社のコードでどの程度使えるかを確かめるところから始めるのが有効です。

エンハンスド株式会社では、レガシー .NET 資産の評価から移行計画の策定、実装、Azure への移行と運用までを一貫して支援しています。エージェント型ツールをどこまで活用し、どこを人が担保するかの設計も含めてご相談いただけます。レガシーシステム モダナイゼーションのページもあわせてご覧ください。

参照元

• Modernize .NET applications in the GitHub Copilot app（Microsoft DevBlogs）
• microsoft/upgrade-agent-plugins（GitHub）
• GitHub Copilot app modernization for .NET のインストール（Microsoft Learn）

このテーマの全体像は .NET モダナイゼーション 完全ガイド にまとめています。