GitHub Copilotは、単なるコード補完の枠を超え、アプリケーション全体のモダン化をエンドツーエンドで支援するエージェント型ソリューションへと進化を遂げました。

特に.NETやJavaといったエンタープライズアプリケーションの移行プロジェクトにおいて、最も困難かつ重要な工程は「現状の把握」と「移行戦略の策定」です。

GitHub Copilotのモダン化機能は、ソースコード全体を詳細に分析し、移行の指針となるアセスメント・ドキュメントを自動生成することで、この課題に対する強力な解答を提示します。

この機能が提供する体験は、Assess(アセスメント)→ Plan(計画)→ Execute(実行)という3フェーズのモデルに基づいています。

すべてはこの最初のステップであるアセスメントから始まり、そこで得られた洞察が後のインフラ構築やコード変換の基礎となります。

本記事では、2026年現在の最新ツールセットを用いた、.NETアプリケーション移行における「モダン化アセスメント」の活用方法とその重要性について詳しく解説します。

モダン化ワークフローの全体像とアセスメントの役割

GitHub Copilotによるモダン化ワークフローは、開発者がエディタ上で対話しながら進められるように設計されています。

その中心にあるのがVS Codeの「GitHub Copilot Modernization」拡張機能です。

このツールは単にコードの問題を指摘するだけでなく、移行先のAzureインフラのプロビジョニングや、コンテナ化、デプロイメント・マニフェストの作成までをシームレスに繋ぎます。

3つのフェーズ:Assess、Plan、Execute

モダン化のプロセスは、以下の3つの段階を経て完了します。

  1. Assess(アセスメント):既存のコードベースをスキャンし、依存関係、技術スタック、クラウド対応状況を分析します。
  2. Plan(計画):アセスメント結果に基づき、具体的な移行ステップや必要なAzureリソースの構成案を作成します。
  3. Execute(実行):計画に沿って、実際にライブラリのアップグレードやインフラのデプロイ、コードの修正を実行します。

これらすべての土台となるのが、今回フォーカスするアセスメント・ドキュメントです。

このドキュメントには、アップグレードが必要な箇所、プロビジョニングされるAzureリソース、アプリケーションのデプロイ方法などが網羅されています。

下流工程のInfrastructure as Code (IaC) 生成やコンテナ化の判断も、すべてこのアセスメント結果をトリガーにして行われるため、アセスメントを正しく構成し、理解することが移行成功の最大の 鍵となります。

アセスメントを開始するための2つのアプローチ

VS Code拡張機能を使用すると、プロジェクトの状況や目的に応じて2種類の開始方法を選択できます。

どちらの方法を選んでも最終的には対話型のダッシュボードにたどり着きますが、事前の構成の細かさが異なります。

「まず何から手をつければいいかわからない」という場合に最適な、迅速なスタート方法です。

複雑な設定は不要で、Copilotが推奨する標準的なシナリオに沿ってスキャンが実行されます。

  1. VS Codeの「GitHub Copilot modernization」ペインを開く。
  2. クイックスタートセクションから「Start Assessment」を選択する。
  3. 「Recommended Assessment」を選ぶ。
  4. 対象とするドメイン (例:.NET Upgrade、Cloud Readiness、Security) をリストから選択する。

このパスは、アプリケーションが現在どのような状態にあるのか、本格的な移行戦略を立てる前のクイックチェックとして非常に有効です。

カスタムアセスメント (Custom Assessment)

移行先がすでに明確な場合(例:Linux上のAzure Kubernetes Service (AKS) への移行など)は、カスタムアセスメントを使用します。

分析対象やターゲット環境を詳細に絞り込むことが可能です。

設定項目選択肢・内容
Assessment Domains.NET Upgrade, Cloud Readiness, Security から一つ、または複数選択
Analysis CoverageIssue only(問題点のみ), Issues & Technologies(技術目録を含む), Issues, Technologies & Dependencies(全項目)
Target ComputeAzure App Service, Azure Kubernetes Service (AKS), Azure Container Apps (ACA)
Target OSLinux または Windows
Containerizationコンテナ化分析の有効/無効

複数のAzureサービスをターゲットに指定した場合、ダッシュボード上でそれぞれのサービスに移行した際の推奨事項をサイドバイサイドで比較できるため、ホスティング先の最終決定を支援する強力な材料となります。

アセスメント・ドキュメントの構造と見方

アセスメントが完了すると、プロジェクトディレクトリ内の特定の場所にレポートが生成されます。

デフォルトの保存先は以下の通りです。

.github/modernize/assessment/

各レポートは独立したファイルとして保存されるため、時間の経過とともに移行の進捗を履歴として管理することが可能です。

レポートの構造は、大きく分けて「アプリケーション情報」と「4つの分析タブ」で構成されています。

アプリケーション情報のスナップショット

レポートの冒頭には、現在のアプリケーションの状態が要約されます。

これには、検出された.NETランタイムのバージョン、使用されているフレームワーク (ASP.NET MVC, WCF等) 、ビルドツール、プロジェクト構造、および設定された移行先ターゲットが含まれます。

これが移行のベースラインとなります。

課題の要約(Issue Summary)

移行の準備がどの程度整っているかを俯瞰するためのダッシュボードです。

ドメインごとに課題がカテゴリ分けされ、緊急度に応じた割合が表示されます。

複数のターゲットサービスを設定している場合、ここでサービス間の「移行コスト」を比較検討できます。

課題詳細タブ(Issues Tab)

ここが実務上のメインとなる「ToDoリスト」です。

検出された課題は、以下の3つの重要度レベルで分類されます。

  • Mandatory(必須):解決しなければ移行が不可能な、重大なブロッカー。
  • Potential(潜在的):移行に影響を与える可能性があるもの。デプロイシナリオにより判断が必要。
  • Optional(任意):推奨される改善。移行自体を妨げないが、品質向上のために推奨される。

各課題を展開すると、影響を受けるソースコードの行番号へのリンク、問題の詳細な説明、そして単なる指摘に留まらない「具体的な修正手順」が表示されます。

公式ドキュメントや移行ガイドへの参照リンクも含まれており、開発者は即座に修正作業に着手できる仕組みになっています。

.NETアプリケーションのアップグレードパス

アセスメント機能は、単なるクラウド対応チェックに留まらず、フレームワークやランタイムのアップグレードパスも精緻に評価します。

2026年時点では、以下のような移行シナリオに対して専用の検出ルールが提供されています。

  • .NET Framework から .NET 10 への移行
  • ASP.NET から ASP.NET Core への移行

例えば、JDKや.NETのバージョン間で削除されたAPIの使用や、ASP.NET Coreで直接的な代替手段がない古いパターンの検出など、「知識が必要な障壁」を自動的に洗い出してくれるのがこのツールの強みです。

また、大規模な組織で何十ものアプリケーションを同時に評価する必要がある場合、CLIツールを活用した一括処理も可能です。

C#
// 複数のリポジトリを一括で評価するためのマニフェスト(repos.json)のイメージ
[
  {
    \"name\": \"LegacyBillingApp\",
    \"path\": \"https://github.com/org/billing-app\",
    \"target\": \"AzureContainerApps\"
  },
  {
    \"name\": \"CustomerPortal\",
    \"path\": \"https://github.com/org/customer-portal\",
    \"target\": \"AKS\"
  }
]

このようなマニフェストを用意し、modernize assess --multi-repo コマンドを実行することで、ポートフォリオ全体のアセスメント結果を集計できます。

アセスメントからAzureデプロイメントへの架け橋

アセスメントが「現在の立ち位置」を示すものだとすれば、続く「Plan」と「Execute」は「目的地への道」を作るプロセスです。

これらもすべてVS Code上のCopilot Chatを介してシームレスに連携します。

インフラ構築の自動化

Copilot Chatのモダン化エージェントに対し、「アセスメントレポートに基づいてAzureインフラの計画を作成して」と依頼するだけで、ソースコードの依存関係やセキュリティ要件を読み取ったプラ ンが生成されます。

エージェントは以下の2つの重要なファイルを生成します。

  • プランファイル (.github/modernize/{plan-name}/plan.md):提案されるアーキテクチャやリソースのリストを含む戦略文書。
  • タスクリスト (.github/modernize/{plan-name}/tasks.json):エージェントが実行する具体的な作業手順。

これらを確認・編集した上で実行を指示すると、BicepまたはTerraformによるIaCコードが生成されます。

コンテナ化と継続的デプロイ

インフラが整った後は、アプリケーション自体のコンテナ化です。

アセスメント時に行われた「コンテナ化分析」の結果を元に、最適なDockerfileが自動生成されます。

dockerfile
# GitHub Copilotが生成する.NET 10向けDockerfileの例
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY [\"MyLegacyApp.csproj\", \".\"]
RUN dotnet restore \"MyLegacyApp.csproj\"
COPY . .
RUN dotnet build \"MyLegacyApp.csproj\" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish \"MyLegacyApp.csproj\" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT [\"dotnet\", \"MyLegacyApp.dll\"]

さらに、ターゲットとなるAzureサービス(AKSやContainer Apps)に応じたデプロイメント・マニフェストも生成され、CI/CDパイプラインへの統合準備が整います。

常に人間がコントロールを握る設計

このモダン化ワークフローにおいて一貫しているのは、「エージェントが提案し、人間が承認する」という原則です 。

各フェーズは独立しており、インフラ準備だけを先に行うことも、コンテナ化だけを試すことも可能です。

また、生成されたプランやコードはすべてGitで追跡可能な形で提供されるため、開発者は「何が変更されるのか」をデプロイ前に完全に把握し、必要に応じて修正を加えることができます。

このHuman-in-the-loopの設計により、AIによる自動化の恩恵を受けつつ、エンタープライズレベルの厳格な管理体制を維持することができます。

まとめ

GitHub Copilotによるモダン化アセスメントは、単なる解析ツールではなく、アプリケーション移行の「信頼できる唯一の情報源(Source of Truth)」を構築するための基盤です。

このドキュメントが正しく生成されることで、その後のインフラ計画、IaC生成、コンテナ化、デプロイメントの精度が劇的に向上します。

手動で行えば数週間を要することもある依存関係の調査やクラウド対応チェックを数分で完了させ、具体的な修正アクションへと繋げられるこのツールは、.NETアプリケーションをモダンなクラウド環境へと導く最短のルートを提供します。

まずはVS Codeの拡張機能をインストールし、自身のアセットに対する最初のアセスメントを実行することから、モダン化への第一歩を踏み出してみてはいかがでしょうか。