.NET 8と.NET 9を利用している企業・開発チームは、2026年11月10日までに.NET 10 LTSへの移行計画を具体化する必要があります。Microsoftは2026年6月29日、.NET 8と.NET 9が同じ日にサポート終了を迎えると案内しました。サポート終了後もアプリケーション自体はすぐ停止しませんが、セキュリティ更新、修正プログラム、技術サポートは提供されなくなります。(Microsoft for Developers)
今回のポイントは、「.NET 8はLTSだからまだ安心」「.NET 9は新しいから後回しでよい」と考えないことです。.NET 8と.NET 9はいずれも2026年11月10日にサポート終了となるため、運用中のWebアプリ、API、バッチ、デスクトップアプリ、コンテナ、CI/CD、ホスティング環境をまとめて棚卸しし、.NET 10への移行を進める必要があります。
.NET 8／.NET 9のサポート終了で何が変わるのか
今回の更新で最も重要なのは、.NET 8と.NET 9のサポート終了日がどちらも2026年11月10日であるという点です。.NET 8はLTS、.NET 9はSTSという違いがありますが、結果として同じ日にサポートが終了します。Microsoftのサポートポリシーでは、LTSは3年、STSは2年のサポートが提供される仕組みです。(Microsoft)
| バージョン | リリース日 | 種別 | サポート終了日 | 管理者の判断 |
|---|---|---|---|---|
| .NET 8 | 2023年11月14日 | LTS | 2026年11月10日 | 既存システムで広く使われている可能性が高く、優先的に棚卸しする |
| .NET 9 | 2024年11月12日 | STS | 2026年11月10日 | 新しめの検証環境・一部本番で使われていないか確認する |
| .NET 10 | 2025年11月11日 | LTS | 2028年11月14日 | 移行先の第一候補として検討する |
.NET 10はLTSであり、公式サポートポリシー上は2028年11月14日までサポート対象です。長期運用を前提にする業務システムでは、短期的に.NET 9へ上げるよりも、.NET 10へ移行するほうが運用計画を立てやすくなります。(Microsoft)
サポート終了後もアプリは動くが「安全に使える」とは限らない
.NET 8または.NET 9で構築されたアプリケーションは、2026年11月10日を過ぎても自動的に停止するわけではありません。問題は、サポート終了後に新しいセキュリティ更新や不具合修正が提供されなくなることです。Microsoftは、サポート終了後はセキュリティ修正、サービス更新、技術サポートを提供しないと説明しています。(Microsoft for Developers)
実務上は、次のようなリスクが高まります。
| 影響領域 | 起こり得る問題 | 確認すべきこと |
|---|---|---|
| セキュリティ | 脆弱性が見つかっても修正パッチを受けられない | 脆弱性管理、監査、SOCの基準に抵触しないか |
| コンプライアンス | 「サポート対象外ソフトウェアの利用」と判断される | 金融、医療、公共、グローバル拠点のIT統制要件 |
| 運用保守 | 障害時に公式サポートを受けにくくなる | 保守契約、SLA、障害対応手順 |
| 開発環境 | Visual StudioやSDK更新時に警告・互換性問題が出る | 開発端末、ビルドサーバー、CI/CDのSDKバージョン |
| 調達・委託 | ベンダー製アプリが旧ランタイムに依存する | 利用中ソフトの.NET対応状況と更新予定 |
特に注意したいのは、「動いているから問題ない」という判断が通用しにくくなる点です。サポート終了後の.NETを使い続けると、アプリケーションだけでなく、アプリケーションデータや実行環境全体のリスクが高まるとMicrosoftのサポートポリシーでも説明されています。(Microsoft)
影響範囲はアプリ本体だけではない
.NETの移行では、TargetFrameworkを書き換えるだけで完了するケースもありますが、実務では周辺環境の確認が欠かせません。Microsoft Learnでは、新しい.NETバージョンへアップグレードする際、開発環境、ソースコード、CI、ホスティング環境など複数の観点を確認する必要があると説明しています。(Microsoft Learn)
確認すべき主な対象
まず、リポジトリ内のプロジェクトファイルを確認します。.csproj、.vbproj、.fsprojのTargetFrameworkまたはTargetFrameworksに、net8.0やnet9.0が指定されていれば移行対象です。
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
</PropertyGroup>移行後は、基本的に次のように.NET 10を指定します。
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>ただし、これだけで本番移行してはいけません。実際には、次の項目も合わせて確認します。
| 確認対象 | 具体例 | 見落としやすいポイント |
|---|---|---|
| 開発端末 | .NET SDK、Visual Studio、VS Code拡張 | 開発者ごとにSDKバージョンが違う |
| CI/CD | GitHub Actions、Azure Pipelines、Jenkins | setup-dotnetやDockerイメージが旧バージョンのまま |
| コンテナ | mcr.microsoft.com/dotnet/aspnet:8.0など | Dockerfileだけでなくベースイメージの脆弱性スキャンも必要 |
| ホスティング | Azure App Service、IIS、Linux VM、Kubernetes | 実行環境に.NET 10ランタイムが入っていない |
| NuGet | ASP.NET Core、EF Core、認証、ログ関連パッケージ | 依存パッケージが.NET 10に未対応の可能性 |
| テスト | 単体テスト、E2E、負荷試験 | ビルド成功だけではランタイム挙動の差を検出できない |
| ベンダー製品 | パッケージソフト、業務アプリ、社内共通部品 | ソースを直接変更できず、ベンダー対応待ちになる |
.NET 8または.NET 9で動いているアプリを利用しているだけの組織でも、開発元やベンダーに.NET 10対応版の提供予定を確認する必要があります。Microsoftも、利用者側はソフトウェア開発元やベンダーに更新版の有無を確認することを推奨しています。(Microsoft for Developers)
Visual Studio利用者が注意すべき変更点
Visual Studio 2022では、今後のサービス更新で.NET 8と.NET 9コンポーネントがサポート対象外として扱われる予定です。既存インストールが直ちに壊れるという意味ではありませんが、サポート外コンポーネントの整理や、.NET 10以降へのターゲット変更を前提に開発環境を整える必要があります。(Microsoft for Developers)
開発チームでは、次のような対応が現実的です。
| 状況 | 推奨対応 |
|---|---|
| Visual Studio 2022で.NET 8アプリを保守中 | .NET 10 SDKを導入し、ビルド・テストが通るか確認する |
| 複数案件を同じ端末で保守している | global.jsonでSDKバージョンを明示し、意図しないSDK切り替えを防ぐ |
| CIとローカルでビルド結果が違う | CI側のSDK、MSBuild、NuGetキャッシュ、ワークロードを確認する |
| MAUIやBlazorなどワークロードを使っている | dotnet workload restoreを含めて検証する |
Microsoft Learnでは、SDKのバージョン固定にglobal.jsonを使えること、またSDK更新時の新しいアナライザー警告や挙動変化を段階的に管理できることが説明されています。チーム開発では、各開発者の端末任せにせず、リポジトリ単位でSDK方針を決めることが重要です。(Microsoft Learn)
.NET 10へ移行する基本手順
.NET 10への移行は、単純な小規模アプリであれば比較的短期間で完了することもあります。一方、業務システム、マイクロサービス、共通ライブラリ、複数国・複数拠点で利用されるシステムでは、影響調査とリリース調整に時間がかかります。
以下の順序で進めると、抜け漏れを減らせます。
| 手順 | 作業内容 | 完了条件 |
| -: | ——————————– | ————————— |
| 1 | .NET 8／.NET 9利用箇所を棚卸しする | リポジトリ、サーバー、コンテナ、CIの対象一覧がある |
| 2 | 移行優先度を決める | インターネット公開、個人情報、決済、基幹業務を優先する |
| 3 | 開発環境に.NET 10 SDKを導入する | ローカルでdotnet --infoを確認できる |
| 4 | TargetFrameworkをnet10.0へ変更する | ソリューション全体がビルド対象になる |
| 5 | NuGetパッケージを更新する | 依存関係の競合や非対応パッケージが解消されている |
| 6 | 破壊的変更を確認する | .NET 10の互換性変更を踏まえた修正が完了している |
| 7 | CI/CDとDockerfileを更新する | 自動ビルド、テスト、イメージ作成が通る |
| 8 | ステージングで動作確認する | 認証、DB接続、ログ、外部API連携が確認済み |
| 9 | 本番リリースとロールバック手順を準備する | 障害時に旧版へ戻す判断基準が明確 |
| 10 | 旧ランタイムを削除または利用停止する | サポート外.NETの残存利用がない |
Microsoft Learnでは、アップグレード時の基本的なソースコード変更としてTargetFrameworkの更新を挙げています。ただし、その後に新しいSDKでビルドし、必要に応じて警告やエラーを修正する流れが前提です。(Microsoft Learn)
Docker、CI/CD、クラウド環境での設定変更ポイント
.NET移行で失敗しやすいのが、アプリのソースコードだけを更新し、実行環境やビルド環境を更新し忘れるパターンです。
Dockerfileの確認
Dockerを利用している場合、ベースイメージに.NET 8または.NET 9が残っていないか確認します。
FROM mcr.microsoft.com/dotnet/aspnet:8.0.NET 10へ移行する場合は、対応する.NET 10イメージへ変更します。
FROM mcr.microsoft.com/dotnet/aspnet:10.0SDKイメージを使うビルドステージも同様です。
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS buildMicrosoft Learnでも、コンテナではDockerfileのFROMステートメントに含まれるバージョン番号を更新する必要があると説明されています。(Microsoft Learn)
CI/CDの確認
GitHub Actionsなどで.NET SDKを指定している場合、設定ファイルに旧バージョンが残りやすいです。
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'.NET 10移行後は、次のように更新します。
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '10.0.x'Azure Pipelinesでも同様に、UseDotNet@2などのタスクで指定しているバージョンを確認します。
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '10.0.x'CI/CDでは、単にビルドが通るかだけでなく、テスト、コード解析、コンテナビルド、デプロイ、DBマイグレーションまで確認する必要があります。特にグローバル展開している企業では、リージョンごとのデプロイタイミング、メンテナンスウィンドウ、承認フローが異なるため、早めに移行スケジュールを分けておくと安全です。
.NET 10移行時に確認したい互換性変更
.NET 10への移行では、互換性変更の確認が欠かせません。Microsoft Learnの.NET 10破壊的変更ページでは、ASP.NET Core、コンテナ、Coreライブラリ、暗号化、Entity Framework Core、SDK／MSBuild、Windows Forms、WPFなど、技術領域ごとに変更点が整理されています。(Microsoft Learn)
すべてのアプリに影響するわけではありませんが、次のような観点は優先して確認してください。
| アプリの種類 | 特に確認したい領域 | 理由 |
|---|---|---|
| ASP.NET Core Webアプリ | 認証、ミドルウェア、HTTP、ホスティング設定 | 外部公開アプリでは挙動差が障害に直結しやすい |
| Web API | JSONシリアライズ、HTTPクライアント、ログ | クライアントアプリとの互換性に影響する |
| バッチ処理 | ファイルI/O、日時、LINQ、例外処理 | 夜間処理や大量データ処理で差が出やすい |
| コンテナアプリ | ベースイメージ、OS、ポート、ヘルスチェック | イメージ変更により実行環境が変わる |
| デスクトップアプリ | Windows Forms、WPF、COM連携 | UIやネイティブ連携の挙動差を確認する必要がある |
| ライブラリ | NuGetパッケージ、ターゲットフレームワーク | 利用側アプリへの影響が広がりやすい |
互換性確認では、ビルドエラーだけを見て判断しないことが重要です。ソース互換性、バイナリ互換性、実行時の挙動変更は別物です。Microsoft Learnでも、.NET 10の変更は「バイナリ非互換」「ソース非互換」「動作変更」に分類されています。(Microsoft Learn)
移行期限はいつに設定すべきか
公式のサポート終了日は2026年11月10日ですが、社内の移行期限はそれより前に置くべきです。理由は、直前に移行すると、互換性問題、ベンダー対応待ち、検証環境不足、リリース凍結期間に引っかかる可能性が高いからです。
現実的には、次のようなマイルストーンを設定すると進めやすくなります。
| 時期 | やるべきこと |
|---|---|
| 2026年上期〜夏 | .NET 8／.NET 9利用箇所の棚卸し、影響度分類、移行方針決定 |
| 2026年夏〜秋 | .NET 10対応ブランチ作成、ビルド修正、依存パッケージ更新、テスト |
| 2026年9月〜10月 | ステージング検証、負荷試験、セキュリティ確認、ベンダー確認 |
| 2026年10月末まで | 本番移行の完了を目標にする |
| 2026年11月10日まで | 例外的に残るシステムのリスク承認、隔離、代替策を確認 |
特に年末商戦、会計期末、グローバル拠点の休暇シーズンと重なる業務では、2026年11月ぎりぎりの移行は避けるべきです。サポート終了日を「作業開始日」ではなく、「すべての本番環境から旧バージョンを外す期限」として扱うのが安全です。
管理者が最初に確認すべきチェックリスト
.NET移行は開発者だけの作業に見えますが、実際にはIT管理者、セキュリティ担当、インフラ担当、プロダクトオーナー、外部ベンダーを巻き込む必要があります。
| チェック項目 | 確認方法 | 優先度 |
|---|---|---|
| 本番サーバーに.NET 8／.NET 9ランタイムがあるか | dotnet --list-runtimes、資産管理ツール | 高 |
| ビルドサーバーに.NET 8／.NET 9 SDKが残っているか | dotnet --list-sdks、CIログ | 高 |
リポジトリでnet8.0／net9.0を使っているか | 全文検索、依存関係スキャン | 高 |
| DockerfileやHelm Chartに旧タグがあるか | IaCリポジトリ検索 | 高 |
| Azure App Serviceなどのランタイム設定が旧版か | ポータル、CLI、IaC定義 | 高 |
| ベンダー製アプリが.NET 8／9依存か | ベンダー問い合わせ、製品仕様書 | 中〜高 |
| サポート外ソフト利用の社内例外申請が必要か | セキュリティポリシー確認 | 高 |
| .NET 10移行後のロールバック手順があるか | リリース計画、運用手順書 | 高 |
Windowsサーバーでランタイムを確認する場合は、次のコマンドが役立ちます。
dotnet --list-runtimes
dotnet --list-sdks
dotnet --infoLinuxサーバーやコンテナでも同様に、実行環境内で確認します。
dotnet --list-runtimes
dotnet --list-sdks
dotnet --infoこの確認で.NET 8や.NET 9が表示されたとしても、必ずしも即削除できるとは限りません。まず、どのアプリが利用しているかを確認し、移行完了後に不要なランタイムを削除する流れにしてください。
よくある失敗と回避策
LTSの.NET 8を使っているから後回しにする
.NET 8はLTSですが、サポート終了日は2026年11月10日です。LTSは「無期限に安全」という意味ではありません。長期サポートの期限が近づいているため、早めに.NET 10 LTSへの移行計画を立てる必要があります。(Microsoft for Developers)
.NET 9のほうが新しいので安心だと思い込む
.NET 9は.NET 8より後にリリースされていますが、STSです。公式情報では、.NET 9も.NET 8と同じ2026年11月10日にサポート終了となります。新しいバージョン番号だけで判断せず、サポートポリシーと終了日で判断しましょう。(Microsoft)
プロジェクトファイルだけ変更して終える
TargetFrameworkをnet10.0に変更してビルドが通っても、移行完了とは言えません。Dockerfile、CI/CD、App Service、IIS、Linuxパッケージ、監視エージェント、NuGetパッケージ、テストコードまで確認が必要です。
依存パッケージの対応状況を見ない
.NET 10へ移行しても、利用しているNuGetパッケージや社内共通ライブラリが対応していないと、ビルドエラーや実行時エラーが発生します。特に認証、ORM、PDF生成、帳票、メール、暗号化、レガシー連携系のライブラリは早めに確認しましょう。
グローバル拠点のリリース調整を後回しにする
多国籍企業では、リージョンごとの休日、監査基準、データ保護要件、メンテナンス時間帯が異なります。日本本社では移行できても、海外拠点の承認やベンダー調整で遅れるケースがあります。グローバル運用では、国・地域ごとの責任者、対象システム、移行予定日を一覧化して進めることが重要です。
今回の更新で取るべき次のアクション
.NET 8 and .NET 9 will reach End of Support on November 10, 2026という今回の案内は、単なるライフサイクル情報ではなく、2026年中に.NET 10 LTSへ移行するための実務的な期限を示すものです。
まずは、次の3つから始めてください。
1つ目は、net8.0とnet9.0を使っているアプリ、サーバー、コンテナ、CI/CDを棚卸しすることです。2つ目は、インターネット公開システム、個人情報を扱うシステム、基幹業務に関わるシステムを優先して.NET 10移行計画を作ることです。3つ目は、ソースコードだけでなく、Visual Studio、SDK、Dockerfile、ホスティング環境、NuGet、テスト、ベンダー製品まで含めて確認することです。
2026年11月10日を過ぎてもアプリは動く可能性があります。しかし、サポート対象外の.NETを本番で使い続けることは、セキュリティ、監査、障害対応の面で明確なリスクになります。余裕を持って.NET 10 LTSへ移行し、サポート期限を「追われるもの」ではなく「計画的に管理するもの」として扱うことが、開発チームとIT管理者の両方に求められます。
コメント