2026年4月7日にMicrosoftが公開したメッセージの核心は明快です。.NET移行を成功させたいなら、先にコード修正へ入るのではなく、まず最新化評価（Modernization Assessment）を基準文書にするべきだ、ということです。GitHub Copilot modernization for .NET は、コードベース全体を分析して評価レポートを生成し、その結果をもとに移行計画を作り、修正や Azure への展開までつなぐ Assess → Plan → Execute の流れを取ります。 (Microsoft for Developers)
つまり、最新化評価は単なる診断結果ではありません。移行先の候補比較、修正優先順位、担当者へのタスク分解、さらに IaC やコンテナ化の方向性まで、下流の判断をそろえる「移行の信頼できる情報源」として使うのが、今回Microsoftが強調したポイントです。 (Microsoft for Developers)
Microsoftが4月7日に強調したのは「評価を先に固める」こと
今回の .NET Blog では、GitHub Copilot modernization を単なるコード提案ツールではなく、コードベース全体を分析し、評価文書を作成し、移行計画を作り、必要に応じて Azure の実行基盤準備まで支援するエンドツーエンドの仕組みとして説明しています。しかも各段階で文書が生成され、利用者は途中でフィードバックや修正を差し込めます。つまり、AIに丸投げする話ではなく、評価レポートを起点に人が進路を修正できる設計だということです。 (Microsoft for Developers)
Microsoft Learn の概要でも、GitHub Copilot modernization は .NET のアップグレード、Azure への移行、コード・設定・依存関係の評価、適切な Azure リソース計画、修正、検証までを支援すると整理されています。今回の発信は、その中でも特に「assessment document が最重要アーティファクトである」と明言した点に意味があります。 (Microsoft Learn)
最新化評価で何が分かるのか
公式情報を実務目線で読み替えると、最新化評価で確認すべきポイントは次の通りです。 (Microsoft Learn)
| 確認項目 | 何が見えるか | 実務での使い道 |
|---|---|---|
| Application Information | ランタイム、フレームワーク、ビルドツール、ターゲット Azure サービス | 現行把握の漏れを防ぎ、前提を関係者でそろえる |
| Issue Summary | ドメイン別の課題数、Criticality の比率 | 工数感をつかみ、移行先候補を比較する |
| Issues | 影響ファイル、行番号、説明、既知の解決策、関連ドキュメント | チケット化、担当割り当て、修正方針の具体化 |
| 履歴・共有 | 評価ごとの独立レポート、Export / Import | ビフォーアフター比較、設計レビュー、他担当との共有 |
特に実務で効くのは Issue Summary と Issues です。Issue Summary では移行難易度を俯瞰でき、Issues では「どのファイルのどの問題を、どう直すか」まで追えます。評価レポートが“読むだけの資料”ではなく、そのまま作業指示に落ちるのはこのためです。 (Microsoft for Developers)
最初の評価は Recommended、意思決定は Custom が基本
Microsoft の記事では、評価の始め方として Recommended Assessment と Custom Assessment の2つが紹介されています。最初から細かく設定しなくても全体像をつかめる一方、移行先がある程度見えているなら、ターゲットを絞ってより精密な判断ができます。 (Microsoft for Developers)
| 評価方式 | 向いている場面 | 主な設定 | 実務での使い方 |
|---|---|---|---|
| Recommended Assessment | まず現状をざっくり把握したいとき | ドメイン選択中心 | 初回トリアージ向き |
| Custom Assessment | App Service / AKS / Container Apps など候補を比較したいとき | ドメイン、分析範囲、ターゲット Compute、OS、コンテナ化有無 | 本番の移行方式決定向き |
迷ったら、1回目は Recommended Assessment、2回目以降は Custom Assessment で候補サービスを比較するのが堅実です。特にターゲットが未確定なら、App Service、AKS、Azure Container Apps を複数選んで比較できる点が大きいです。初回評価で全体像をつかみ、次の評価で判断材料を絞る。この順番だと、いきなり設計論争に入らずに済みます。 (Microsoft for Developers)
なぜ最新化評価が「信頼できる情報源」になるのか
ファイル単位で修正タスクに落ちるから
評価レポートの Issues では、影響ファイルや行番号、問題の説明、既知の解決策、関連ドキュメントまで確認できます。ここまで揃っていると、開発者は「どこから直すか」で止まりにくくなりますし、レビュアーも優先順位をつけやすくなります。移行でありがちな「問題は分かったが、誰がどこを直すかが曖昧」という状態を減らせます。 (Microsoft for Developers)
ホスティング判断に直結するから
Microsoft は、複数の Azure サービスターゲットを設定した場合、ダッシュボード上で切り替えてサービスごとの差分を比較できると説明しています。ブログ記事でも、App Service では mandatory が少なく、AKS では多いといった差がホスティング判断を左右しうる例が示されています。移行先を「慣れているから」で決めるのではなく、評価結果で決めやすくなるわけです。 (Microsoft Learn)
下流の計画がこの評価結果を読むから
ここが今回いちばん重要です。Microsoft は、インフラ計画、IaC 生成、コンテナ化判断、デプロイ先選定が、いずれも評価結果をもとに進むと説明しています。つまり、最新化評価を雑に済ませると、あとで生成される plan や manifest までズレます。逆に、評価をきちんと整えると、その後の設計・実装・デプロイがブレにくくなります。 (Microsoft for Developers)
最新化評価を .NET移行計画に組み込む実践フロー
Quickstart では、assessment 実行後にレポート UI と移行タスク一覧が表示され、そこから migration task を開始できます。タスク開始後は plan.md と progress.md が生成され、依存関係管理、設定変更、コード修正、ビルド修正、セキュリティ修正まで流れで進められます。 (Microsoft Learn)
| フェーズ | 最新化評価の役割 | 現場でやること |
|---|---|---|
| 現状把握 | 現行ランタイム・構成の基準を作る | 影響範囲を確認し、関係者の認識をそろえる |
| 移行先選定 | Azure サービスごとの差分を可視化する | App Service / AKS / Container Apps を比較する |
| 修正計画 | Criticality と issue 詳細で優先順位を決める | Mandatory → Potential → Optional の順で整理する |
| 実装 | 推奨タスクと計画ファイルを生成する | plan.md をレビューしてから実行する |
| インフラ・デプロイ | 評価結果をもとにインフラ計画へ渡す | 開発・インフラで同じレポートを参照する |
| 再評価 | 修正後の変化を測定する | mandatory 件数の減少を確認する |
見落としやすいのが、ファイルの置き場所がフェーズで変わることです。最新化評価そのものはプロジェクト配下の .github/modernize/assessment/ に保存され、コード移行では .appmod/.migration/plan.md と progress.md が生成されます。さらに Azure インフラ計画の段階では .github/modernize/{plan-name}/plan.md と tasks.json が作られます。つまり、同じ評価結果を起点にしながら、コード移行用の計画とインフラ実行用の計画が分かれていく構造です。ここを理解しておくと、ファイルが増えても迷いません。 (Microsoft for Developers)
実務では、この流れを1回で終わらせないことが大切です。Microsoft の記事でも、各評価は独立レポートとして保存され、履歴として比較できます。修正後に再評価し、mandatory の減り方を見ながら計画を更新していくと、移行は“感覚”ではなく“進捗が見える作業”になります。 (Microsoft for Developers)
失敗しやすいポイント
移行先を先に決め打ちする
最初から「今回は AKS で行く」と決め打ちすると、あとで mandatory issue が増えたときに設計ごとやり直しになりやすいです。ターゲットが固まっていない段階では、複数サービスで比較し、issue 数と criticality の差を見てから選ぶほうが失敗しにくいです。 (Microsoft Learn)
Mandatory と Potential を同じ重みで扱う
公式上、Mandatory は移行に必須の修正、Potential は影響可能性があり要レビュー、Optional は低影響で推奨レベルです。ここを同列に並べると、緊急度の高い課題が埋もれます。まず Mandatory を潰し、Potential はアーキテクト判断、Optional は別スプリントで扱うくらいに分けると整理しやすくなります。 (Microsoft Learn)
評価結果を別資料に転記してしまう
評価レポートは Export / Import でき、他の担当者が再実行しなくても同じ内容を見られます。にもかかわらず、Excel や別の台帳に転記し直すと、元レポートとの差分管理が崩れやすいです。設計レビュー、開発タスク、インフラ判断の基準は、できるだけ評価レポートそのものに寄せたほうがブレません。 (Microsoft for Developers)
一度の評価で終わったことにする
評価は“開始前の儀式”ではなく、進捗確認の基準です。修正前後で再評価しないと、本当に blockers が減ったのか、別の候補サービスのほうが現実的なのかが見えません。独立レポートとして履歴が残る設計は、まさにこの再評価を前提にしたものです。 (Microsoft for Developers)
複数アプリを抱えるなら、評価をポートフォリオ単位で使う
単一アプリの移行だけでなく、複数リポジトリをまとめて見るときも、最新化評価は効きます。Modernize CLI の modernize assess --multi-repo では、各アプリの詳細レポートに加えて、全体を横断した aggregated report も生成できます。そこでは Azure サービス推奨、ターゲットプラットフォーム、アップグレードパス、移行ウェーブまで俯瞰できるため、「どのアプリから着手するか」を決めやすくなります。 (Microsoft Learn)
特にレガシー資産が多い組織では、この aggregated report の価値が大きいです。アプリごとに個別最適で移行先を決めるのではなく、共通依存関係や共通課題をまとめて見て、先に片付けるべきパターンを発見できます。なお、クラウド側へ委任して大規模評価を回す場合、.NET Framework アプリでは Windows 環境の考慮が必要です。ここまで含めて、source of truth をアプリ単位からポートフォリオ単位へ拡張するのが、次の実務段階です。 (Microsoft Learn)
まず次にやること
- 移行対象の代表アプリを1本決め、Visual Studio なら Modernize、VS Code なら Start Assessment か
@Modernize Migrate to Azureで、まず1回 assessment を実行します。 (Microsoft Learn) - 移行先が未確定なら、次は Custom Assessment で App Service、AKS、Azure Container Apps を比較し、mandatory の差を見ます。 (Microsoft for Developers)
- レポートが出たら、Mandatory だけを先に抜き出して担当を割り振るところまで一気に決めます。Potential と Optional は混ぜないほうが進みます。 (Microsoft Learn)
- 移行タスク開始後に生成される
plan.mdとprogress.mdは、そのまま実行せず、必ずチームでレビューします。人がここで方向修正できるのが、この仕組みの強みです。 (Microsoft Learn) - 最初の修正サイクルが終わったら再評価し、前回レポートと比べて blockers が減ったかを確認します。ここまで回せて初めて、最新化評価が“信頼できる情報源”として機能し始めます。 (Microsoft for Developers)
Microsoft が今回強調したのは、「どれだけAIに直させるか」よりも、「どの評価を正として全員が動くか」が移行成功を左右するという点です。最新化評価を基準文書にできれば、.NET移行は場当たり的な改修ではなく、判断可能で再現性のあるプロジェクトに変わります。 (Microsoft for Developers)
コメント