GitHub Copilot modernizationは、GitHub Copilotを使ってアプリケーションの評価、アップグレード、Azure移行、修正計画の作成までを支援するモダナイゼーション向けAIエージェントです。2026年6月3日の公式更新では、このGitHub Copilot modernization agentが一般提供されたことが案内されました。重要なのは、単なるコード補完の強化ではなく、複数リポジトリを対象に「評価 → 計画 → 修正 → 検証 → 展開」までを組織的に進めやすくなった点です。(Microsoft Azure)
開発者にとっては、Javaや.NETアプリのアップグレード、クラウド移行に必要なコード修正、ビルド検証を進めやすくなります。一方で、管理者はGitHub Copilotのポリシー、Copilot cloud agentの有効化、MCPサーバー、GitHub Actions権限、リポジトリアクセスを事前に確認する必要があります。GAになったからといって、いきなり本番リポジトリで自動修正を走らせるのではなく、まずは対象アプリを棚卸しし、評価レポートを作るところから始めるのが安全です。
GitHub Copilot modernizationとは何か
GitHub Copilot modernizationは、既存アプリケーションの最新化を支援するGitHub Copilotのエージェント機能です。一般的なCopilotのように「今書いているコードを補完する」だけではなく、古いランタイムやフレームワーク、依存関係、Azure移行時の修正点を分析し、計画を作り、必要に応じてコード変更や検証まで支援します。
MicrosoftのJava向けドキュメントでは、GitHub Copilot modernizationはアプリケーションモダナイゼーションをエンドツーエンドで支援するAIアシスタントとして説明されています。コード、構成、依存関係の評価、Azureリソース計画、移行を妨げる問題の修正を支援する位置づけです。(Microsoft Learn)
特に今回の一般提供で注目したいのは、個別開発者の便利ツールから、企業のアプリケーションポートフォリオ全体を扱うための仕組みに近づいた点です。複数リポジトリの一括評価、クラウドエージェントによる並列実行、Azure Migrateとの連携により、移行対象の優先順位付けや移行ウェーブの設計に使いやすくなっています。(Microsoft Learn)
今回の一般提供で何が変わるのか
今回の更新は「GitHub Copilot modernization agent is now generally available」という位置づけです。Azure Updates上の「Launched」は、一般提供済みで本番利用可能な状態を示すステータスとして定義されています。(Microsoft Azure)
ただし、ここでいう本番利用可能とは「すべてのコード変更を無審査で本番反映してよい」という意味ではありません。実務では、AIエージェントが作成した計画や差分を、従来の開発プロセスと同じようにレビュー、テスト、承認する前提で使うべきです。
| 観点 | 従来の見方 | 一般提供後に重視したい見方 |
|---|---|---|
| 利用目的 | 開発者が個別にアップグレードを試す補助ツール | 複数アプリの評価、優先順位付け、移行計画に使う基盤 |
| 対象範囲 | 1つのプロジェクトやローカル作業が中心 | 複数リポジトリ、アプリ単位、ポートフォリオ単位 |
| 実行方法 | IDEやローカル環境での対話 | CLI、設定ファイル、クラウドエージェント、CI/CD連携 |
| 管理ポイント | 開発者のCopilot利用可否 | 組織ポリシー、リポジトリアクセス、MCP、Actions権限 |
| 成果物 | コード修正案やアップグレード案 | 評価レポート、移行ウェーブ、PR、修正履歴、検証結果 |
主な機能と対象範囲
GitHub Copilot modernizationの中心は、評価、計画、実行、検証の流れです。CLIではmodernizeコマンドを使い、対話形式でも非対話形式でも実行できます。非対話モードはCI/CDや定期的な評価に組み込みやすい構成です。(Microsoft Learn)
アプリケーション評価
評価では、コード、構成、依存関係、クラウド移行の準備状況を分析します。バッチ評価ではJava、.NET、JavaScript/TypeScriptアプリケーションを複数まとめて分析でき、リポジトリ単位のレポートと集約レポートを生成できます。(Microsoft Learn)
評価結果には、技術スタック、依存関係、構成、API、業務フロー、データモデルなどの情報が含まれます。これにより、単に「このコードを直す」ではなく、「どのアプリから移行するべきか」「どの依存関係が複数アプリで共通しているか」を判断しやすくなります。
コード修正とアップグレード
.NET向けには、ASP.NET Core、ASP.NET Web Forms、Blazor、Azure Functions、WPF、Windows Forms、クラスライブラリ、コンソールアプリ、テストプロジェクトなどが対象として示されています。アップグレードパスとして、.NET Framework、.NET Core 1.x〜3.x、.NET 5以降から.NET 8以降への移行が案内されています。(Microsoft Learn)
Java向けには、MavenとGradleプロジェクト、Java 8、11、17、21、25間のアップグレード、Spring Bootを使うアプリケーションのモダナイゼーションが重視されています。ビルド検証、CVE確認、単体テストの移行や生成も機能として説明されています。(Microsoft Learn)
バッチ評価とバッチアップグレード
複数アプリを扱う組織では、バッチ評価とバッチアップグレードが重要です。repos.jsonに対象リポジトリを列挙し、まとめて評価できます。クラウドエージェントに委任すれば、複数リポジトリを並列で処理できます。(Microsoft Learn)
バッチアップグレードでは、同じアップグレード対象を複数リポジトリに適用できます。ただし、バッチアップグレードでは対象リポジトリが同じプログラミング言語である必要があります。Javaと.NETを混在させたまま一括アップグレードしようとすると失敗やスキップの原因になります。(Microsoft Learn)
Azure Migrateとの連携
Azure Migrateとの連携では、Azure Migrateプロジェクトからrepos.jsonを取得し、リポジトリURLを補完して評価を実行できます。評価完了後、レポートはAzure Migrateプロジェクトへ自動的にアップロードされます。(Microsoft Learn)
この連携は、移行プロジェクトの責任者にとって大きな意味があります。インフラ担当がAzure Migrateで把握した移行対象と、開発担当が見るコードレベルの課題をつなげられるためです。従来は「サーバーとしては移せるが、アプリコードがAzure向けに直っていない」というギャップが起きがちでした。GitHub Copilot modernizationは、そのギャップを埋めるための評価材料を提供します。
管理者が確認すべき設定
GitHub Copilot modernizationを組織で使う場合、最初に確認すべきなのはコードではなく管理設定です。AIエージェントがリポジトリ、依存関係、外部ツールにアクセスするため、利用範囲を曖昧にしたまま展開すると、権限過多や監査不備につながります。
| 確認項目 | 管理者が見るポイント | 放置した場合のリスク |
|---|---|---|
| Copilotライセンス | 対象ユーザーに必要なCopilotプランが割り当てられているか | 利用者によって機能差が出る |
| 組織ポリシー | Copilot機能、モデル、プレビュー機能の許可範囲 | 意図しない機能利用、管理外のAI利用 |
| Copilot cloud agent | Business/Enterpriseでは管理者による有効化が必要か | 開発者側で実行できない、または許可範囲が曖昧になる |
| リポジトリアクセス | 評価対象リポジトリへの読み取り・書き込み権限 | クローン失敗、PR作成失敗 |
| MCPサーバー | 使わせるツールを最小限に絞っているか | エージェントが外部ツールを自律実行する |
| GitHub Actions | Actionsの権限、クォータ、Windows runner要否 | クラウド委任や.NET Framework系で失敗 |
| ブランチ保護 | PRレビュー、必須チェック、rulesetとの整合性 | AI生成差分が承認フローを迂回する |
| Azure権限 | Azureサブスクリプション、Landing Zone、IaC方針 | インフラ計画が組織標準とずれる |
GitHub Copilot BusinessまたはEnterpriseでは、Copilot cloud agentは既定で無効で、管理者が有効化する必要があります。リポジトリ単位で利用を無効化することもできます。(GitHub Docs)
また、GitHubの組織またはEnterpriseでは、Copilotの機能やモデルの利用可否をポリシーで管理できます。Enterprise側でポリシーが定義されている場合、組織側では上書きできないことがあります。(GitHub Docs)
MCPサーバー設定では「許可しすぎ」に注意する
GitHub Copilot modernizationをクラウドエージェントと組み合わせる場合、MCPサーバーの設定が重要です。MCPは、Copilotが外部ツールやデータソースにアクセスするための仕組みです。
GitHub Docsでは、MCPサーバーを設定すると、Copilotはそのサーバーが提供するツールを自律的に使えるようになり、使用前に毎回承認を求めるわけではないと説明されています。さらに、toolsでは必要な読み取り専用ツールを明示的に許可することが推奨されています。(GitHub Docs)
実務では、最初から"*"ですべてのツールを許可するのは避けた方が安全です。特に、課題管理、デプロイ、クラウドリソース操作、外部API連携をMCPでつなぐ場合は、読み取り系、分析系、変更系を分け、変更系は検証環境から段階的に有効化するべきです。
開発者が事前に準備すべきこと
開発者側では、GitHub Copilot modernizationを「壊れたプロジェクトを魔法のように直すツール」と考えないことが重要です。精度を上げるには、入力となるリポジトリの状態を整える必要があります。
まず、対象ブランチでビルドが通る状態にします。Java向けのGitHub Docsでも、モダナイゼーションの前にプロジェクトが正常にビルドできることを確認するよう案内されています。(GitHub Docs)
次に、以下を準備します。
| 準備するもの | 具体例 | 目的 |
|---|---|---|
| 作業ブランチ | modernize/java21、modernize/dotnet10 | 本番ブランチへの直接変更を避ける |
| ビルド手順 | Maven、Gradle、dotnet build、CI定義 | エージェントの検証精度を上げる |
| テスト | 単体テスト、統合テスト、最低限の回帰テスト | AI生成差分の安全性を確認する |
| 依存関係情報 | package、NuGet、Maven、Gradle設定 | 非互換ライブラリやCVE確認に使う |
| 移行方針 | Azure App Service、Container Apps、AKSなど | 目的に合う修正計画を作らせる |
| 制約条件 | 認証方式、ネットワーク、DB、監査要件 | 組織ルールと矛盾する提案を減らす |
推奨される展開手順
GitHub Copilot modernizationを組織に展開するなら、いきなり全リポジトリをアップグレードするのではなく、評価中心の小さなパイロットから始めます。
小さく評価する
まず、影響範囲が限定されたJavaまたは.NETのリポジトリを数件選びます。理想は、ビルド手順が明確で、テストがあり、アプリ担当者がレビューできるものです。
gh auth login
modernize --version
modernize assess --source .github/modernize/repos.json --format markdownmodernize assessでは、現在のディレクトリ、ローカルパス、Git URL、repos.jsonを指定できます。評価結果はHTMLやMarkdownで出力できます。(Microsoft Learn)
評価レポートから移行順を決める
評価レポートでは、総アプリ数、アップグレードが必要なアプリ、ブロッカー、技術分布、工数感、推奨Azureサービス、移行戦略、移行ウェーブなどを確認できます。(Microsoft Learn)
ここで見るべきなのは、単に「問題が少ない順」ではありません。事業影響、保守期限、セキュリティリスク、チームの習熟度、リリース頻度を合わせて判断します。
例えば、以下のように分類すると実行しやすくなります。
| 分類 | 対象例 | 進め方 |
|---|---|---|
| Quick Win | 依存関係が少なく、テストもある内部アプリ | 早期にアップグレードして成功パターンを作る |
| 標準移行 | Web API、バッチ、管理画面など | 評価、計画、PRレビューを標準フロー化する |
| 高リスク | 認証、決済、基幹DB、独自フレームワークを含むアプリ | 手動設計レビューを先に行う |
| 保留 | ビルド不能、担当不明、仕様書なし | 棚卸しと復旧を先に行う |
計画を作り、PRでレビューする
評価後は、自然言語のプロンプトで計画を作れます。
modernize plan create "upgrade to .NET 10 and prepare deployment to Azure App Service" --plan-name dotnet-modernize
modernize plan execute --plan-name dotnet-modernizeCLIのplan createは、モダナイゼーションの目的を自然言語で指定して計画を作成します。生成されたplan.mdやタスク一覧は、実行前に手動で編集できます。(Microsoft Learn)
ここで重要なのは、AIエージェントの実行結果をそのままマージしないことです。通常の開発と同じように、差分、ビルド、テスト、セキュリティチェック、レビュー承認を通します。
git status
git diff main
gh pr create --title "Modernization: upgrade runtime" --body "Automated modernization by GitHub Copilot modernization agent"Microsoftのクイックスタートでも、エージェント実行後に変更内容を確認し、満足できる場合にPRを作成する流れが示されています。(Microsoft Learn)
クラウドエージェントを使う場合の注意点
大規模な評価やアップグレードでは、クラウドエージェント委任が便利です。ただし、クラウド委任には制約があります。
バッチ評価のドキュメントでは、クラウドエージェント委任はGitHub上のリポジトリURLが必要で、ローカルパスやGitLab、Azure DevOpsなどの非GitHubプロバイダーはサポートされないと説明されています。該当するリポジトリはローカル実行を使う必要があります。(Microsoft Learn)
また、Copilot cloud agentには、1回のタスクで変更できるのは指定リポジトリのみ、1回のタスクで1つのPR、セッション実行時間の上限、content exclusionsを考慮しないなどの制限があります。機密ファイルを「Copilotの除外設定に入れているから大丈夫」と考えるのは危険です。(GitHub Docs)
インフラ展開まで任せる場合の確認点
GitHub Copilot modernizationは、コード修正だけでなく、Azureインフラ計画やデプロイにも関わることがあります。Microsoft Learnでは、アプリケーションソースコード、評価レポート、アーキテクチャ図、コンプライアンスやセキュリティ要件を入力として、Azureインフラのプロビジョニング計画を作成できると説明されています。(Microsoft Learn)
ただし、インフラ計画は組織標準との整合性が特に重要です。Landing Zone、ネットワーク分離、マネージドID、Key Vault、ログ保管、タグ設計、コスト管理、リージョン方針が決まっている場合は、リポジトリ内のドキュメントやプロンプトに明示しておきます。
例えば、次のような条件を先に書いておくと、実務に近い計画になりやすくなります。
本番環境は既存のAzure Landing Zone上に配置する。
認証情報はKey Vaultに保存し、アプリからはManaged Identityで参照する。
外部公開はApplication Gateway経由とし、直接パブリックIPは付与しない。
ログは既存のLog Analytics workspaceへ送る。
まずはIaCファイルの生成のみ行い、リソース作成は手動承認後に実行する。AIに任せる範囲を「設計案まで」「IaC生成まで」「検証環境への展開まで」「本番展開前のPR作成まで」のように区切ると、統制しやすくなります。
よくある失敗と対策
GAになったので全リポジトリを一括修正してしまう
最初から一括アップグレードを実行すると、レビュー不能な量の差分が発生します。まずはassessで評価し、対象アプリを絞ってからplan createやupgradeを使います。
Javaと.NETを同じバッチアップグレードに混ぜる
バッチアップグレードでは、対象リポジトリが同じプログラミング言語である必要があります。Javaと.NETは分けて実行します。(Microsoft Learn)
GitHub以外のリポジトリをクラウド委任しようとする
クラウドエージェント委任はGitHub.com上のリポジトリURLが前提です。Azure DevOpsやGitLabのリポジトリは、ローカル実行や移行前の棚卸しを検討します。(Microsoft Learn)
MCPに強すぎる権限を与える
MCPサーバーはCopilotに外部ツールを使わせる強力な仕組みです。最初は読み取り系ツールに限定し、変更操作を含むツールは検証環境で確認してから有効化します。
テストがないままAI修正を信頼する
AIが作った差分は、正しそうに見えても業務仕様を満たしているとは限りません。最低限、既存テストの実行、主要APIの疎通、認証、DBアクセス、バッチ処理、例外系の確認は必要です。
利用に向いているケース、慎重に進めるべきケース
| ケース | 判断 |
|---|---|
| 古いJavaや.NETアプリが多数ある | 向いている。バッチ評価と移行ウェーブ設計の効果が大きい |
| Azure移行を検討している | 向いている。Azure Migrate連携やクラウド準備状況の評価に使いやすい |
| ビルド手順とテストが整っている | 向いている。AI生成差分を検証しやすい |
| 担当者不明、ビルド不能、仕様不明のアプリ | 先に棚卸しと復旧が必要 |
| 厳格な規制でクラウドエージェント利用が難しい | ローカル実行、権限制限、監査設計を優先 |
| 小さな一回限りの修正 | 通常のCopilot Chatや手動修正で十分な場合がある |
| GitHub以外でコード管理している | クラウド委任に制約があるため、運用設計が必要 |
まず何から始めるべきか
GitHub Copilot modernizationの一般提供を受けて最初にやるべきことは、全社展開ではなく、対象アプリの棚卸しと評価です。具体的には、次の順番で進めると失敗しにくくなります。
| 順番 | 実施内容 | 成果物 |
|---|---|---|
| 1 | 対象アプリをJava、.NET、その他に分類する | リポジトリ一覧 |
| 2 | Copilotポリシー、cloud agent、MCP、Actions権限を確認する | 管理設定チェックリスト |
| 3 | 影響の小さい3〜5リポジトリで評価を実行する | 評価レポート |
| 4 | レポートをもとに移行ウェーブを決める | 優先順位表 |
| 5 | 1つのアプリで計画作成とPR作成まで試す | 標準手順 |
| 6 | 成功パターンをrepos.jsonやCI/CDに組み込む | 横展開テンプレート |
GitHub Copilot modernizationは、レガシーアプリの更新作業をすべて自動化する魔法の機能ではありません。しかし、評価、計画、コード修正、検証を同じ流れで扱えるため、モダナイゼーションの初動を大きく短縮できます。管理者は権限とポリシーを整え、開発者はビルドとテストを整備し、まずは評価レポートから移行判断を始めるのが現実的な第一歩です。
コメント