Azure から「.NET 6 の廃止（Retirement）」通知が届くと、IIS で動く .NET Framework（4.5.2 / 4.8.1）の Web アプリまで .NET 8 へ作り直しが必要なのか不安になります。結論から、サーバーで事故らない確認手順と現実的な対応策まで整理します。
結論：.NET 6 の廃止通知＝.NET Framework アプリの .NET 8 移行必須ではない
まず押さえたいのは、「.NET 6（= .NET / .NET Core 系）」と「.NET Framework（4.x 系）」は別系統の実行基盤だという点です。Azure の “.NET 6 廃止” は基本的に .NET 6 で動くアプリ（例：ASP.NET Core 6、.NET 6 で作ったバッチ、サービスなど）に向けた話で、.NET Framework で動くアプリは同じ通知の文脈で “自動的に .NET 8 へ移行必須” になるわけではありません。
ただし注意点もあります。サーバー内に「.NET 6 をターゲットにして動いている何か」が残っている場合は、通知を放置するとセキュリティ更新が止まった状態を引きずることになります。つまり“移行必須か？”ではなく、“サーバー上で .NET 6 が何に使われているか？”が先です。
そもそも Azure の「.NET 6 廃止通知」は何を指しているのか
「Azure から通知が来た」といっても、対象は環境によって変わります。Windows Server 2022 上で受け取った場合、代表的には次のどれかです（実際の通知文面や対象リソース名で判断します）。
- Azure App Service / Azure Functions などの “ランタイム スタック” が .NET 6：PaaS 側の設定が .NET 6 を指しているケース。アプリ自体が .NET 6 のため、.NET 8 への更新（移行）が必要になることが多い。
- Azure VM（IIS サーバー）に .NET 6 ランタイム／Hosting Bundle が入っている：脆弱性管理や推奨事項（Advisor など）が “サーバーに EOL ランタイムがある” ことを検知しているケース。
- 別製品（バックアップ、監視エージェント等）が内部で .NET 6 を利用：自社アプリとは無関係でも、サーバー上の他ソフトが .NET 6 依存のことがある。
あなたの Web アプリが .NET Framework 4.8.1 / 4.5.2（Web Forms を含む）で、.NET 6 を参照していないなら、通知の“主語”はアプリではなくサーバーに残っている .NET 6 実行環境である可能性が高いです。まずはそこを切り分けましょう。
.NET Framework と .NET（6/8）を混同しないための整理
混乱の元は「.NET」という名前が同じでも、製品として別物が並走している点です。運用判断に必要な差分を表で整理します。
| 観点 | .NET Framework（4.x） | .NET（6/8 など / 旧 .NET Core） |
|---|---|---|
| 主な用途 | Windows / IIS での従来型アプリ（ASP.NET Web Forms、WCF など） | クロスプラットフォーム、コンテナ、最新の ASP.NET Core など |
| IIS での Web | ASP.NET（System.Web）を Windows 機能として提供 | ASP.NET Core（Kestrel + IIS 連携は Hosting Bundle/ANCM） |
| 更新の入り方 | OS の更新（Windows Update）と一体で提供されることが多い | OS とは独立製品として Microsoft Update などで更新 |
| インストール | 4.x は基本 “上書き（インプレース）” で 1 系統 | メジャー/マイナー単位で “サイドバイサイド（共存）” が基本 |
| サポートの考え方 | OS のサポート期間に連動（ただし一部古い版は退役） | 各バージョンごとに EOS がある（LTS/STS） |
.NET（6/8）は「OS とは独立した製品」で、インストーラーはサイドバイサイド（SxS）を前提です。また、更新チャネルも OS コンポーネント（.NET Framework）とは別であることが明記されています。
サポート期限の現実：.NET 6 は EOS、でもそれは “.NET Framework の話” ではない
運用担当として重要なのは「サポートが切れたものを残さない」ことです。ここで注意したいのは、通知に出てくる EOS は “.NET 6（.NET）” の期限であり、.NET Framework の期限とは別という点です。
| 対象 | 位置付け | 主な影響 | 覚えておきたい期限 |
|---|---|---|---|
| .NET 6 | LTS | .NET 6 をターゲットにしたアプリに影響 | 2024-11-12 に EOS |
| .NET 8 | LTS | .NET 8 をターゲットにしたアプリに影響 | 2026-11-10 に EOS |
| .NET Framework 4.5.2 | 退役（Retired） | 4.5.2 ランタイム自体は更新されない | 2022-04-26 に退役 |
ポイントはこうです。
- .NET 6 の EOS は 2024 年 11 月 12 日で、以降はセキュリティ修正も原則止まります。
- .NET 8 は LTS として 2026 年 11 月 10 日までサポート対象です。
- .NET Framework 4.5.2 は 2022 年 4 月 26 日に退役しており、少なくとも 4.6.2 以上、できれば 4.8 系へ引き上げるべきと案内されています。
あなたのケースで優先すべき現実的対応
「.NET 8 へ移行（作り直し）しなければならないのか？」に対しては、まず“アプリの種類”と“現状のバージョン分布”で判断します。
Web Forms を含む .NET Framework アプリなら、まずは .NET Framework 4.8/4.8.1 に揃える
ASP.NET Web Forms は .NET Framework（System.Web）を前提とするため、大きく作り直さない限り .NET 8（ASP.NET Core）へそのまま移行できません。したがって現実的な第一手は、同じ .NET Framework の範囲でバージョンを揃え、サポートされる状態に寄せることです。
特に「4.5.2 のまま動いている」状態は、サポート面でも監査面でも弱点になります。4.5.2 は退役しているため、運用継続するならターゲット/実行環境を 4.8 系へ寄せるのが王道です。
Windows Server 2022 なら .NET Framework 4.8 が標準、4.8.1 も導入可能
Windows Server 2022 は .NET Framework 4.8 が OS にプレインストールされており、さらに .NET Framework 4.8.1 を追加で導入できます。つまり「サーバー側の実行環境を 4.8 系にする」こと自体は比較的取り組みやすいです。
.NET Framework 4.8.1 は Windows Server 2022（Desktop / Azure Editions を含む）向けの提供も明記されています。
| やりたいこと | サーバー（Windows Server 2022） | 開発（Visual Studio） | ポイント |
|---|---|---|---|
| 実行環境を最新の .NET Framework に | .NET Framework 4.8.1 を適用（4.8 は既に搭載） | 不要（サーバーの話） | OS 更新と合わせて計画的に |
| アプリのターゲットを 4.5.2 → 4.8 系へ | 実行は可能でも、まずテスト環境で検証 | プロジェクトのターゲットフレームワークを変更 | 外部ライブラリ互換性を確認 |
| .NET 6 通知への対処 | サーバー上の .NET 6 利用有無を調査し、必要なら .NET 8 へ | .NET 6 アプリがあるなら移行計画が必要 | “自社Webアプリが Framework”でも別製品が依存し得る |
「.NET 6 をアンインストールして .NET 8 を入れる」と .NET Framework へ影響する？
結論から言うと、一般的には.NET 8 を入れても .NET Framework 4.8 系（OS 機能としての ASP.NET を含む）を置き換えません。理由は次の 2 つです。
- .NET（6/8）は OS とは独立した製品として提供され、.NET Framework（OS コンポーネント）とは更新チャネルも別です。
- .NET のインストーラーはメジャー/マイナーを跨いだサイドバイサイド（SxS）を前提にしています。
一方で、.NET 6 をアンインストールすると “.NET 6 を必要とするアプリ” は動かなくなります。これは自社アプリだけでなく、同居しているツールやエージェントも含みます。
また Microsoft Learn でも、古い .NET ランタイムをアンインストールすると、共有フレームワークで動くアプリが選択するランタイムが変わる可能性がある旨が説明されています。つまり「消しても平気か」は “何を動かしているか” 次第です。
影響が出る/出ないパターンを表で把握する
| サーバーに存在するもの | .NET 6 を削除したら？ | .NET 8 を追加したら？ | 現場でのよくある結論 |
|---|---|---|---|
| .NET Framework（Web Forms / MVC5 など）だけ | 基本的に直接影響しない | 基本的に直接影響しない | .NET 6 の通知は “別件” の可能性が高い |
| ASP.NET Core 6（フレームワーク依存でホスト） | 起動できなくなる可能性が高い | .NET 8 に移行すれば解消（ただしアプリ更新が必要） | アプリを .NET 8 へ上げるまで .NET 6 は残す |
| ASP.NET Core 6（自己完結: self-contained） | アプリによっては影響が小さい | 影響しないことが多い | IIS 連携のモジュール要件に注意 |
| 他社製ツール/エージェントが .NET 6 依存 | ツールが壊れる/更新が必要 | .NET 8 対応版に更新できる場合あり | ツール側のサポート情報が最優先 |
最短で判断するためのチェックリスト
「.NET 6 を消していいか」「.NET 8 を入れるべきか」を、机上の推測ではなく事実ベースで判断するためのチェック手順です。運用チームだけでできる範囲に絞っています。
サーバーに入っている .NET（6/8）を列挙する
まずはインストール済みのランタイム一覧を見ます。サーバーに dotnet コマンドが入っていれば次で確認できます。
dotnet --list-runtimes
dotnet --list-sdks
dotnet --infodotnet コマンドが見つからない場合でも、サーバーに “.NET Runtime” だけ入っているケースがあります。その場合は「アプリと機能」や「プログラムと機能」で “Microsoft .NET Runtime 6.x / 8.x” や “ASP.NET Core Runtime” を確認します。
IIS 上に ASP.NET Core（.NET 6/8）アプリが混在していないか確認する
IIS のサイト配下にある web.config を見て、次の要素があれば ASP.NET Core アプリの可能性が高いです。
<system.webServer>
<aspNetCore processPath="dotnet" ... />
</system.webServer>一方で、Web Forms / 旧 ASP.NET MVC（System.Web 系）の場合は <system.web> や <compilation targetFramework="4.x"> といった設定が中心で、<aspNetCore> は出てきません。ここが最初の大きな分岐点です。
“実は .NET 6 を使っている” 典型例を潰す
Web アプリが .NET Framework でも、同じサーバーに次のようなものがあると .NET 6 が入っていることがあります。
- バックアップソフト、監視エージェント、インベントリ収集ツール
- IIS 以外で動く社内ツール（Windows サービス、コンソール、タスクスケジューラ）
- API や別サイトだけ ASP.NET Core で動かしている（管理画面だけ新しい、など）
運用上のコツは「IIS だけ見て安心しない」ことです。タスクスケジューラ、サービス、常駐プロセスに .NET 6 依存が潜むのはよくあります。
.NET Framework の実行環境（4.8/4.8.1）を確認する
Windows Server 2022 は .NET Framework 4.8 が標準搭載で、4.8.1 も導入できます。
インストール状態の確認は、レジストリの Release 値（.NET Framework 4.x の判定方法として Microsoft が案内している方法）を PowerShell で見るのが手堅いです。
Get-ItemProperty 'HKLM:\\SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full' |
Select-Object Release, Versionこの確認が重要なのは、アプリが「4.5.2 をターゲットにしている」場合でも、実際にサーバーで動いているランタイムは 4.8/4.8.1 であることが多いからです（4.x はインプレース更新）。サーバー側が最新化されていれば、セキュリティ更新の観点でのリスクはかなり下げられます。
.NET 8 へ移行するべきかを決める判断軸
.NET Framework を継続するか、ASP.NET Core（.NET 8）へ再設計するかは、“正解が 1 つ” ではありません。現場で後悔しにくい判断軸を挙げます。
| 判断軸 | .NET Framework 継続が向く | .NET 8（ASP.NET Core）移行が向く |
|---|---|---|
| アプリ構造 | Web Forms が中心、画面数が多い、改修頻度が低い | API 化しやすい、機能単位で切り出せる、改修頻度が高い |
| 運用制約 | Windows/IIS を前提にする、社内基盤が固定 | コンテナ化、Linux も視野、スケールアウト要求が強い |
| セキュリティ/監査 | OS サポート期間内で .NET Framework 4.8/4.8.1 を維持できる | EOL 追従をアプリ単位で素早く回したい |
| 開発体制 | 既存保守が中心、コストを抑えたい | 中長期で内製強化、モダン化を投資できる |
“Azure から通知が来た” という理由だけで Web Forms を全面改修するのは、コストに対して得られるリターンが薄いことがあります。逆に、今後も機能追加が続くプロダクトなら、どこかで ASP.NET Core に寄せる判断が合理的になることもあります。
Web Forms を .NET 8 に「そのまま」移行できない理由と、現実的な落としどころ
Web Forms は System.Web 上に成り立つため、ASP.NET Core（.NET 8）へ “アップグレード” というより“移植/再設計”になります。ここを誤解すると計画が破綻しやすいので、現実的な落としどころを整理します。
落としどころの例
- 短期：.NET Framework 4.8/4.8.1 + 最新パッチで運用を固める（まず監査・セキュリティ要件を満たす）
- 中期：新機能は API として切り出し、ASP.NET Core（.NET 8）側に実装する（段階的モダン化）
- 長期：画面を Razor Pages / MVC / Blazor などへ置き換え、Web Forms 領域を縮小していく
この “二段構え” は、既存資産を活かしながら .NET 8 のメリット（性能、クラウド適性、最新ライブラリ、将来の人材確保など）も取りにいけるため、実務では採用されやすいパターンです。
IIS で ASP.NET Core を動かす場合の注意点（Hosting Bundle）
もしサーバー上に ASP.NET Core（.NET 6/8）アプリが存在するなら、IIS 連携のために “.NET Hosting Bundle” の理解が必要です。Hosting Bundle は .NET Runtime と ASP.NET Core Module をまとめて導入するインストーラーで、IIS で ASP.NET Core を動かすための基本部品です。
ここでよくある誤解が「Hosting Bundle を入れると IIS の ASP.NET（= .NET Framework）まで置き換わるのでは？」という不安ですが、実際には役割が異なります。
- Web Forms / MVC5：IIS 上で .NET Framework（System.Web）が動く
- ASP.NET Core：IIS とは別プロセス（Kestrel など）を IIS が仲介する
そのため、Hosting Bundle の導入は “ASP.NET Core 側の実行基盤を追加する” 行為であり、従来 ASP.NET の機能を上書きするものではありません。ただしインストール後は IIS 再起動やサーバー再起動が必要になることがあるため、メンテナンス枠で実施してください。
おすすめの対応手順（事故を避ける運用フロー）
最後に、現場でトラブルになりにくい順序で「やること」をまとめます。ポイントは “アプリ移行” と “サーバーの EOL 実行環境除去” を混ぜないことです。
- 棚卸し：サーバーで動いているアプリ/サービス/タスクを一覧化し、.NET 6 依存の有無を確認する（IIS だけ見ない）。
- テスト環境で検証：.NET Framework アプリは 4.8/4.8.1 の環境で総合テスト（特に帳票、暗号/TLS、外部 DLL 連携）。
- サーバーの .NET Framework を最新化：Windows Server 2022 なら 4.8.1 適用を検討し、OS 更新と同じ手順で管理する。
- .NET（6/8）を整理：.NET 6 をターゲットにしたものが残っているなら、アプリ側を .NET 8 へ上げてから .NET 6 を撤去。撤去時は影響範囲を明確にし、戻せる手順を用意する。
- 監査対応：“EOL ランタイムなし” を証跡化（インストール一覧、dotnet –list-runtimes のログなど）。
この流れで進めれば、Azure の通知に過剰反応して Web Forms を急いで作り直す必要はなく、必要なところだけを確実に更新できます。特に Windows Server 2022 では .NET Framework 4.8 が標準で、4.8.1 も導入できるため、まずは .NET Framework 側の土台を固めるのが堅実です。
コメント