GitHubの公式ドキュメント更新「Add GHCP modernization tip to upgrade」は、GitHubや.NETの仕様が突然変わったというより、サポート切れの.NETを使うプロジェクトに対して、GitHub Copilot modernizationを使った移行・アップグレードを促す導線が追加された更新です。
開発者、クラウド管理者、ソリューションアーキテクトがまず確認すべきなのは、「自社の.NETプロジェクトがNETSDK1138の対象になっていないか」「警告を抑制して放置していないか」「Copilot modernizationを移行計画に組み込めるか」の3点です。
2026年4月29日のコミットでは、docs/core/tools/sdk-errors/netsdk1138.md に対して3行が追加され、NETSDK1138の解決策としてGitHub Copilot modernizationへの案内が追記されました。対象は.NETのサポート切れターゲットフレームワークに関するドキュメントであり、CI/CD、セキュリティ運用、Azure移行計画に影響しやすい更新です。(GitHub)
GitHubの公式ドキュメント更新「Add GHCP modernization tip to upgrade」で何が変わったか
今回の更新は、GitHub上の dotnet/docs リポジトリにあるMicrosoft Learn向けドキュメントへの変更です。コミット名は「Add GHCP modernization tip to upgrade」で、変更対象は.NET SDKエラー NETSDK1138 の説明ページです。(GitHub)
追加された内容は、要点だけ見ると次の通りです。
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年4月29日 |
| 対象ファイル | docs/core/tools/sdk-errors/netsdk1138.md |
| 変更量 | 3行追加、削除なし |
| 追加内容 | GitHub Copilot modernizationを使って、.NETプロジェクトを評価・計画・アップグレードできるというTip |
| 直接の影響 | SDKの挙動変更ではなく、移行支援手段への案内追加 |
重要なのは、NETSDK1138のエラー仕様そのものが変わったわけではないという点です。
.NET SDKが新しい自動修復機能を追加した、GitHubが既存プロジェクトを自動で書き換える、といった更新ではありません。
ただし、公式ドキュメントがNETSDK1138の解決策としてGitHub Copilot modernizationを明示したことで、サポート切れ.NETの移行を「手作業だけで進める課題」ではなく、「AIエージェントを使って評価・計画・実行できる課題」として扱う流れが強くなっています。
NETSDK1138とは何か
NETSDK1138は、プロジェクトがサポート切れの.NETターゲットフレームワークを対象にしている場合に表示される.NET SDKの警告・エラーです。Microsoft Learnの該当ページでは、NETSDK1138は「プロジェクトがサポート外のフレームワークを対象にしている」ことを示すものとして説明されています。(Microsoft Learn)
たとえば、次のようなターゲットフレームワークを含むプロジェクトは確認対象になります。
<TargetFramework>net6.0</TargetFramework>または、古い.NET Coreを使っているプロジェクトです。
<TargetFramework>netcoreapp3.1</TargetFramework>Microsoft LearnのNETSDK1138ページでは、サポート外のバージョンとして.NET Core 1.x、2.x、3.x、.NET 5、.NET 6、.NET 7などが挙げられています。解決策としては、プロジェクトのターゲットをサポート中の.NETバージョンへ変更することが示されています。(Microsoft Learn)
警告を抑制するだけでは根本解決にならない
NETSDK1138のページには、CheckEolTargetFramework を false にすることでメッセージを抑制する方法も記載されています。(Microsoft Learn)
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<CheckEolTargetFramework>false</CheckEolTargetFramework>
</PropertyGroup>
</Project>または、ビルド時に次のように指定できます。
dotnet build /p:CheckEolTargetFramework=falseただし、これは警告表示を抑える設定であり、サポート切れの.NETをサポート中に戻すものではありません。
本番運用の観点では、次のようなリスクが残ります。
| 抑制で残るリスク | 実務上の問題 |
|---|---|
| セキュリティ更新の対象外になる | 脆弱性対応の説明責任を果たしにくい |
| CI/CDで古いSDKに依存し続ける | ビルドエージェントやコンテナ更新時に突然失敗する |
| 依存パッケージ更新が進まない | NuGetパッケージやフレームワークAPIの互換性問題が後回しになる |
| 監査で指摘されやすい | EOLソフトウェア利用として扱われる可能性がある |
一時的に抑制する場合でも、チケット、期限、移行先バージョン、責任者をセットで管理するべきです。
GHCP modernizationとは何を指すのか
今回のコミットでは「GHCP modernization」という表現が使われていますが、追加されたリンク先は「GitHub Copilot modernization」です。文脈上、GHCPはGitHub Copilotを指す略称として読むのが自然です。(GitHub)
GitHub Copilot modernizationは、.NETプロジェクトを新しい.NETバージョンへアップグレードしたり、.NETアプリケーションをAzureへ移行したりするためのGitHub Copilotエージェントです。Microsoft Learnでは、評価、ソリューション提案、コード修正、検証を支援するものとして説明されています。(Microsoft Learn)
対応する利用環境としては、Visual Studio、Visual Studio Code、GitHub Copilot CLI、GitHub.comが挙げられています。(Microsoft Learn)
つまり今回の更新は、単なるリンク追加ではなく、次のようなメッセージとして読むべきです。
NETSDK1138が出る古い.NETプロジェクトは、手作業でターゲットフレームワークを変更するだけでなく、GitHub Copilot modernizationで評価・計画・実行の流れに乗せられる。
開発者がまず確認すべきポイント
開発者は、ソースコード上のターゲットフレームワーク、依存関係、ビルド結果を確認します。特に複数プロジェクトを含むソリューションでは、アプリ本体だけを更新しても、クラスライブラリやテストプロジェクトが古いままだと移行が止まりやすくなります。
対象フレームワークを洗い出す
まず、リポジトリ内の .csproj、.vbproj、.fsproj を検索します。
find . -name "*.csproj" -o -name "*.vbproj" -o -name "*.fsproj"ターゲットフレームワークの指定を確認します。
grep -R "<TargetFramework" .
grep -R "<TargetFrameworks" .Windows環境でPowerShellを使う場合は、次のように確認できます。
Get-ChildItem -Recurse -Include *.csproj,*.vbproj,*.fsproj |
Select-String "<TargetFramework"複数ターゲットの場合は、TargetFrameworks に古いフレームワークが混在していないかを確認します。
<TargetFrameworks>net6.0;net8.0</TargetFrameworks>このようなケースでは、net8.0 が含まれていても net6.0 が残っていれば、運用上の確認対象です。
CheckEolTargetFramework の有無を確認する
警告抑制が入っていないかも確認します。
grep -R "CheckEolTargetFramework" .見つかった場合は、次のように判断します。
| 状態 | 判断 |
|---|---|
| 一時的な検証ブランチだけで使用 | 許容できる場合がある |
| 本番ブランチで恒久的に使用 | 改善対象 |
| CI/CDのビルド引数で指定 | 見落としやすいため要注意 |
| いつ設定したか分からない | 移行計画に必ず入れる |
警告抑制は「移行しない理由」ではなく、「移行までの猶予を作るための一時措置」として扱うのが安全です。
依存パッケージとテストを同時に確認する
.NETのターゲットだけを変更しても、古いNuGetパッケージや非推奨APIが原因でビルドが通らないことがあります。
最低限、次のコマンドで確認します。
dotnet --list-sdks
dotnet --list-runtimes
dotnet restore
dotnet build
dotnet test
dotnet list package --outdated特に注意したいのは、次のようなプロジェクトです。
| プロジェクト種別 | 失敗しやすいポイント |
|---|---|
| ASP.NET Core | ミドルウェア、認証、ホスティングモデル、設定ファイル |
| Azure Functions | ランタイム、in-process / isolated worker model、拡張機能 |
| WPF / Windows Forms | Windows固有API、ターゲットフレームワークの -windows 指定 |
| クラスライブラリ | 参照元プロジェクトとの互換性 |
| テストプロジェクト | テストSDK、モックライブラリ、古いアサーションライブラリ |
GitHub Copilot modernizationのドキュメントでは、ASP.NET Core、Blazor、Azure Functions、WPF、Windows Forms、WinUI、.NET MAUI / Xamarin、クラスライブラリ、コンソールアプリ、テストプロジェクトなどがアップグレード対象として挙げられています。(Microsoft Learn)
クラウド管理者が確認すべき運用影響
クラウド管理者は、ソースコードだけでなく、ビルド環境、実行環境、監視、セキュリティ例外まで確認する必要があります。
.NETのターゲットフレームワークを上げると、次の領域に影響します。
| 領域 | 確認内容 |
|---|---|
| CI/CD | ビルドエージェントに対象SDKが入っているか |
| コンテナ | ベースイメージの.NET runtime / SDKタグが古くないか |
| Azure App Service | ランタイムスタックが移行先.NETに対応しているか |
| Azure Functions | Functionsランタイムと.NETバージョンの組み合わせ |
| 監視 | ログ形式、OpenTelemetry、Application Insightsの設定 |
| セキュリティ | 脆弱性スキャン、EOLソフトウェア検出、例外申請 |
| デプロイ | Blue-Green、カナリア、ロールバック手順 |
.NETのサポートポリシーでは、LTSとSTSでサポート期間が異なります。2026年4月22日更新の公式サポートポリシーでは、.NET 10はLTSとして2028年11月14日まで、.NET 9と.NET 8は2026年11月10日までのサポートとされています。(Microsoft)
2026年時点で新たに移行計画を立てるなら、長期運用の候補として.NET 10 LTSを優先的に検討する価値があります。ただし、既存ライブラリ、ホスティング環境、顧客要件によっては、段階的な移行が現実的な場合もあります。
ソリューションアーキテクトが見るべき設計上の論点
ソリューションアーキテクトにとって、今回の更新は「古い.NETをどう直すか」だけでなく、「アプリケーションモダナイゼーションをどの単位で進めるか」を考えるきっかけになります。
特に確認すべき論点は次の通りです。
| 論点 | 判断基準 |
|---|---|
| 一括移行か段階移行か | ソリューション規模、依存関係、リリース頻度 |
| .NET移行だけにするか | Azure移行、認証刷新、監視刷新も含めるか |
| Copilotに任せる範囲 | 評価のみ、計画作成まで、コード修正まで |
| 人間のレビュー範囲 | API互換性、セキュリティ、性能、業務仕様 |
| ブランチ戦略 | 専用ブランチ、タスク単位コミット、段階的マージ |
| 成功条件 | ビルド成功だけでなく、テスト・性能・運用監視まで含める |
GitHub Copilot modernizationは、評価、計画、実行の3段階でアップグレードを進め、.github/upgrades/{scenarioId} 配下にMarkdownファイルを生成します。評価結果、アップグレード方針、計画、タスク、実行ログをレビューできるため、アーキテクトやテックリードが判断を差し込む余地があります。(Microsoft Learn)
GitHub Copilot modernizationを使うべきケース
GitHub Copilot modernizationは便利ですが、すべてのプロジェクトで無条件に使えばよいわけではありません。次のように判断すると実務に落とし込みやすくなります。
| 状況 | 使うべきか | 理由 |
|---|---|---|
| .NET 6 / .NET 7の業務アプリが複数ある | 使う価値が高い | 評価と計画の標準化に向いている |
| .NET Frameworkから.NET 10へ移行したい | 使う価値が高い | 影響範囲が広く、手作業の見落としが起きやすい |
| 小規模なコンソールアプリ1本だけ | 必須ではない | 手作業の方が早い場合がある |
| テストがほとんどない | 評価用途から使う | 自動修正より先にリスク把握が重要 |
| 独自フレームワークや古い社内ライブラリが多い | 慎重に使う | Copilotの提案を人間が強くレビューする必要がある |
| 監査対応でEOL一覧が必要 | 使う価値がある | 評価レポートを移行説明の材料にできる |
特に大規模ソリューションでは、Copilotに「すぐ修正させる」より、まず評価結果と計画をレビューする使い方が安全です。
実務でのおすすめ確認手順
GitHubの公式ドキュメント更新「Add GHCP modernization tip to upgrade」を受けて、開発・運用チームが取るべき手順は次の通りです。
対象リポジトリを棚卸しする
まず、組織内の.NETリポジトリを一覧化します。GitHub EnterpriseやAzure DevOpsを使っている場合は、リポジトリ単位で次の情報を集めます。
| 項目 | 例 |
|---|---|
| リポジトリ名 | customer-portal-api |
| アプリ種別 | ASP.NET Core Web API |
| 現在のターゲット | net6.0 |
| 移行候補 | net10.0 |
| 本番稼働有無 | あり |
| テスト状況 | 単体テストあり、E2Eなし |
| 優先度 | 高 |
棚卸しでは、最初から完璧な移行計画を作る必要はありません。
まず「どこにEOLリスクがあるか」を見える化することが目的です。
NETSDK1138をCIで検出する
ローカル開発者の環境だけでなく、CIでもNETSDK1138が出るか確認します。
dotnet build --warnaserrorすでに警告抑制が入っている場合は、CIで見えなくなっている可能性があります。.csproj だけでなく、ビルドスクリプト、GitHub Actions、Azure Pipelines、Dockerfileも確認します。
GitHub Actionsなら、次のような箇所を見ます。
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: '6.0.x'Dockerfileでは、次のような古いイメージタグを確認します。
FROM mcr.microsoft.com/dotnet/aspnet:6.0
FROM mcr.microsoft.com/dotnet/sdk:6.0ターゲットフレームワークだけを変えても、CIやコンテナが古いままだと本番移行で詰まります。
Copilot modernizationで評価を作る
GitHub Copilot modernizationを使う場合は、いきなり本番ブランチで実行せず、専用ブランチで始めます。
git checkout -b upgrade/dotnet-modernizationVisual Studioでは、ソリューションまたはプロジェクトを右クリックして「Modernize」を選択するか、GitHub Copilot Chatで @Modernize を使います。Visual Studio CodeではCopilot Chatで @modernize-dotnet を使います。GitHub Copilot CLIやGitHub.com上のcoding agentからも開始できます。(Microsoft Learn)
最初のプロンプト例は、具体的に書くと精度が上がります。
Upgrade this solution from .NET 6 to .NET 10.
Prioritize build compatibility, keep public APIs stable, and do not change authentication behavior unless required.
Use guided mode and generate an assessment before making code changes.日本語で運用ルールを補足しても構いません。
このソリューションを.NET 6から.NET 10へ移行したいです。
まず評価レポートを作成し、コード変更前に破壊的変更、NuGet更新、テスト影響を整理してください。
認証・認可と外部APIの仕様は変更しない方針です。生成されたMarkdownをレビューする
Copilot modernizationは、アップグレードの状態を .github/upgrades/{scenarioId} 配下に保存します。Microsoft Learnでは、assessment.md、upgrade-options.md、plan.md、tasks.md、scenario-instructions.md、execution-log.md などが説明されています。(Microsoft Learn)
レビューでは、次の観点を確認します。
| ファイル | 見るべきポイント |
|---|---|
assessment.md | 破壊的変更、非推奨API、依存関係の問題 |
upgrade-options.md | 一括移行か段階移行か、移行戦略が妥当か |
plan.md | タスク順序、リスク対策、依存プロジェクトの扱い |
tasks.md | 検証条件が具体的か、テストが含まれているか |
execution-log.md | どの変更がなぜ行われたか追跡できるか |
ここで重要なのは、生成された計画を「AIが出した正解」として扱わないことです。
業務仕様、性能要件、セキュリティ基準、リリース制約は、チーム側で補足する必要があります。
実行前に受け入れ条件を決める
アップグレード作業を始める前に、成功条件を明文化します。
| 受け入れ条件 | 具体例 |
|---|---|
| ビルド | すべてのプロジェクトが警告なし、または許容済み警告のみでビルドできる |
| テスト | 単体テスト、統合テスト、主要E2Eが成功する |
| セキュリティ | 既知の重大脆弱性が残っていない |
| 性能 | 主要APIのレスポンス時間が移行前と同等以上 |
| 運用 | ログ、メトリクス、アラートが移行後も機能する |
| ロールバック | 旧バージョンへ戻す手順が確認済み |
NETSDK1138の解消だけを成功条件にすると、運用上の問題を見落とします。
本番アプリでは、移行後に「動く」だけでなく、「監視できる」「戻せる」「説明できる」状態まで確認するべきです。
移行先.NETバージョンの選び方
移行先は、単に最新だから選ぶのではなく、サポート期間、互換性、運用計画で決めます。
2026年時点の公式サポートポリシーでは、.NET 10はLTS、.NET 9はSTS、.NET 8はLTSとして掲載されています。ただし、.NET 8と.NET 9はいずれも2026年11月10日にサポート終了予定とされているため、長期運用を前提に新規移行を計画する場合は.NET 10を有力候補として検討するのが自然です。(Microsoft)
| 移行先候補 | 向いているケース | 注意点 |
|---|---|---|
| .NET 10 | 長期運用、次期標準基盤への移行 | 依存ライブラリや実行環境の対応状況を確認する |
| .NET 9 | 短期的な検証、既存計画との整合 | サポート期間が短いため長期運用には向きにくい |
| .NET 8 | 既存環境との互換性を優先する暫定移行 | 2026年時点ではサポート終了時期が近い |
判断に迷う場合は、次の基準が実務的です。
- これから本格移行を始めるなら、.NET 10を第一候補にする
- 既に.NET 8移行が終盤なら、無理に計画を崩さず、次の.NET 10移行計画を作る
- サードパーティ製品が.NET 10未対応なら、暫定移行と最終移行を分ける
- 社内共通ライブラリが古い場合は、アプリより先にライブラリの移行計画を立てる
よくある失敗と回避策
アプリ本体だけをアップグレードしてしまう
複数プロジェクト構成では、Web API本体だけを net10.0 にしても、参照先ライブラリやテストプロジェクトが古いままだとビルドやテストが不安定になります。
回避策は、依存関係の下流から順に確認することです。
GitHub Copilot modernizationのアップグレード戦略でも、依存関係の深い大規模ソリューションではBottom-upの考え方が使われます。(Microsoft Learn)
DockerfileやCIの更新を忘れる
プロジェクトファイルを更新しても、Dockerfileが古い.NETイメージを参照していると、コンテナビルドで失敗します。
確認すべきファイルは次の通りです。
Dockerfile
docker-compose.yml
.github/workflows/*.yml
azure-pipelines.yml
global.json
Directory.Build.props
Directory.Packages.props特に global.json でSDKバージョンを固定している場合、ローカルでは新しいSDKを入れていても、リポジトリ設定で古いSDKが使われ続けることがあります。
{
"sdk": {
"version": "6.0.400"
}
}テストがない状態で自動修正を進める
Copilot modernizationはコード修正を支援できますが、テストがなければ正しく動いているか判断しにくくなります。
テストが不足しているプロジェクトでは、先に次のような最小テストを追加します。
| テスト種別 | 最低限確認する内容 |
|---|---|
| スモークテスト | アプリが起動するか |
| APIテスト | 主要エンドポイントが期待通り返るか |
| 認証テスト | ログイン、権限チェックが壊れていないか |
| DBテスト | マイグレーション、接続、主要クエリ |
| バッチテスト | 定期処理が例外なく完了するか |
.NET移行では、コンパイルが通っても実行時の挙動差が出ることがあります。テストなしでの自動修正は、レビュー負荷を増やす原因になります。
AIの提案をそのままマージする
GitHub Copilot modernizationが生成する評価や計画は有用ですが、最終判断は開発チームが行う必要があります。
特に次の変更は、必ず人間がレビューします。
- 認証・認可まわりの変更
- 暗号化、証明書、シークレット管理
- データベース接続とトランザクション
- 外部APIとの互換性
- ログ出力や監査ログ
- 例外処理とリトライ
- パフォーマンスに関わる変更
「AIが変更したから安全」ではなく、「AIが作業を分解し、人間が重要箇所をレビューする」と考えるのが現実的です。
技術責任者・意思決定者向けの判断ポイント
技術責任者や意思決定者は、今回の更新を「開発者向けTips」としてだけ見るのではなく、EOL対応とモダナイゼーションの優先順位付けに使うべきです。
確認すべき質問は次の通りです。
| 質問 | なぜ重要か |
|---|---|
| サポート切れ.NETで本番稼働しているアプリは何本あるか | リスクの全体量を把握するため |
| 警告抑制をしているプロジェクトはあるか | 見えないEOLリスクを発見するため |
| 2026年内にサポート期限を迎える.NETがあるか | 移行期限を逆算するため |
| 移行に必要なテスト基盤はあるか | 自動化だけでは品質を保証できないため |
| GitHub Copilot modernizationを誰がレビューするか | AI利用時の責任分界点を明確にするため |
| Azure移行や認証刷新も同時に行うか | 単純移行かモダナイゼーションかを分けるため |
EOL対応は後回しにされやすい一方で、期限が近づくほど選択肢が減ります。
今回のドキュメント更新は、サポート切れ.NETの棚卸しを始めるよいタイミングです。
今回の更新を受けた実務チェックリスト
最後に、チームでそのまま使えるチェックリストをまとめます。
| チェック | 確認内容 |
|---|---|
| 対象確認 | .csproj などで古い TargetFramework を洗い出した |
| 警告確認 | NETSDK1138がCI/CDで検出されるか確認した |
| 抑制確認 | CheckEolTargetFramework=false の有無を確認した |
| SDK確認 | global.json、ビルドエージェント、Dockerfileを確認した |
| 依存確認 | NuGetパッケージ、社内ライブラリ、外部SDKを確認した |
| 移行先確認 | .NET 10など、サポート期間を踏まえて候補を決めた |
| Copilot確認 | GitHub Copilot modernizationを評価・計画に使えるか確認した |
| レビュー確認 | AI生成の計画や修正を誰が承認するか決めた |
| テスト確認 | ビルド、単体テスト、統合テスト、主要業務フローを確認した |
| リリース確認 | ロールバック、監視、障害時対応を準備した |
今回の「Add GHCP modernization tip to upgrade」は、表面的には3行のドキュメント追加です。
しかし実務上は、NETSDK1138を見たときの対応方針が「警告を消す」から「サポート中の.NETへ計画的に移行する」へ変わるきっかけになります。
まずは自社リポジトリで古いターゲットフレームワークと警告抑制を洗い出し、影響の大きいプロジェクトからGitHub Copilot modernizationで評価レポートを作成してください。コード変更に進むのは、その評価結果をチームでレビューし、移行先バージョン、テスト範囲、リリース計画が固まってからで十分です。
コメント