こんにちは、インフラエンジニアのryuです。
社内のWebシステムや業務アプリで、.NETが動いているサーバーを担当していませんか？
その.NETが8か9なら、あと1か月ほどでサポートが終わります。
Microsoftの.NETのサポートポリシーでは、.NET 8と.NET 9は、どちらも2026年11月10日にサポート終了になります。LTSとSTSという種類の違うバージョンが、同じ日に終わるのは珍しいことです。
この記事では、なぜ2つが同じ日に終わるのか、サーバーに入っている.NETをどう調べるか、.NET 10へ移る前にインフラエンジニアが確認しておきたいことを順番に整理します。
アプリの書き換えは開発チームの仕事になることが多いですが、どのサーバーに何が入っているかを把握するのはインフラエンジニアの役割です。そこから一緒に見ていきましょう。
.NET 8と.NET 9のサポート終了日は？¶
まずは、Microsoftの公式ページに載っている現在のサポート状況を表にまとめます。
| バージョン | リリース | 種類 | サポート終了日 |
|---|---|---|---|
| .NET 10 | 2025年11月11日 | LTS | 2028年11月14日 |
| .NET 9 | 2024年11月12日 | STS | 2026年11月10日 |
| .NET 8 | 2023年11月14日 | LTS | 2026年11月10日 |
.NET 8と.NET 9は、どちらもすでにメンテナンス期間に入っています。メンテナンス期間は、サポート最後の6か月のことで、この間はセキュリティ修正だけが提供されます。
2026年9月の時点でも、.NET 8と.NET 9には月例のパッチが出ています。ただし、11月10日を過ぎると、それも止まります。
LTSとSTSの違い¶
.NETには、LTSとSTSという2種類のリリースがあります。LTSは長期サポート、STSは標準期間のサポートという意味です。
| 種類 | サポート期間 | 該当するバージョン |
|---|---|---|
| LTS（Long Term Support） | 3年 | .NET 8、.NET 10 |
| STS（Standard Term Support） | 2年 | .NET 9 |
もともとSTSのサポートは18か月でした。それが2年（24か月）に延びたため、2024年11月に出た.NET 9の終了日が、2023年11月に出た.NET 8と同じ2026年11月10日にそろいました。
公式ページでは、STSについて次のように説明しています。
STS releases are supported for one year after a subsequent release. Releases happen every 12 months so the support period for STS is two years.
つまり、.NET 8から.NET 9に上げていたチームも、上げずに.NET 8のままだったチームも、同じタイミングで次のバージョンへ移る必要があります。
サポートが終わると何が起きる？¶
サポートが終わっても、.NET 8や.NET 9で作ったアプリが急に動かなくなるわけではありません。サーバーを再起動しても、アプリはそのまま起動します。
問題になるのは、脆弱性が見つかっても修正が出なくなることです。公式ページでも、サポート外のバージョンを使い続けると、アプリやデータ、環境全体がリスクにさらされると書かれています。
.NETはWebアプリの土台になることが多いので、外部に公開しているサーバーなら放置はおすすめできません。ASP.NET CoreやKestrelまわりの脆弱性は、毎年のように修正が出ています。
サーバーに入っている.NETの調べ方¶
移行の計画を立てる前に、どのサーバーにどのバージョンの.NETが入っているかを洗い出します。
ここで知っておきたいのは、.NETには配布物がいくつかあることです。
| 配布物 | 中身 | 主に入っている場所 |
|---|---|---|
| .NET Runtime | コンソールアプリなどを動かすランタイム | アプリを動かすサーバー |
| ASP.NET Core Runtime | Webアプリを動かすランタイム | Webサーバー |
| Hosting Bundle | ASP.NET Core Runtime＋IIS用のモジュール | IISで動かすWindows Server |
| .NET SDK | ビルドに使う開発キット | 開発PC、ビルドサーバー、CI |
本番サーバーにはランタイムだけ、ビルドサーバーにはSDKが入っている、という分かれ方が多いです。どちらも調べる対象になります。
dotnetコマンドで確認する¶
WindowsでもLinuxでも、dotnet コマンドが使えるなら、次の2つで入っているランタイムとSDKが分かります。
# 入っているランタイムの一覧
dotnet --list-runtimes
# 入っているSDKの一覧
dotnet --list-sdks
出力の例は次のような形です。Microsoft.AspNetCore.App 8.0.x や Microsoft.NETCore.App 9.0.x が出てきたら、今回のサポート終了の対象です。
Microsoft.AspNetCore.App 8.0.20 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.20 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
1台のサーバーに複数のバージョンが同時に入っていることもあります。.NET 10が入っているから大丈夫、とは限らないので、一覧を最後まで見てください。
パッケージで入れた場合の確認¶
Linuxでディストリビューションのパッケージとして入れている場合は、パッケージ管理コマンドでも確認できます。
# Ubuntu / Debian 系
dpkg -l | grep -E 'dotnet|aspnetcore'
# RHEL / Amazon Linux 系
rpm -qa | grep -E 'dotnet|aspnetcore'
Windows Serverなら、「アプリと機能」で Microsoft .NET や Hosting Bundle を探すほか、C:\Program Files\dotnet\shared の下にあるフォルダ名でもバージョンが分かります。
アプリがどのバージョンを使っているかを見る¶
ランタイムが入っているかどうかと、アプリがそれを使っているかどうかは別の話です。アプリ側は、発行先のフォルダにある *.runtimeconfig.json を見るのが手軽です。
{
"runtimeOptions": {
"tfm": "net8.0",
"framework": {
"name": "Microsoft.AspNetCore.App",
"version": "8.0.0"
}
}
}
tfm が net8.0 や net9.0 になっていれば、そのアプリは対象です。
注意したいのは、自己完結型（self-contained）で発行されたアプリです。この形式だとランタイムがアプリのフォルダに同梱されるので、dotnet --list-runtimes には出てきません。サーバーに.NETが入っていないように見えても、アプリの中に.NET 8が入っていることがあります。
コンテナで動かしている場合は、Dockerfileのベースイメージも確認します。
FROM mcr.microsoft.com/dotnet/aspnet:8.0
8.0 や 9.0 のタグを使っているイメージは、サポート終了後は新しいパッチが入らなくなります。Dockerの学び方はdocker入門の記事でまとめています。
イメージのタグを 10.0 に変えるだけで済むように見えますが、アプリ側が net10.0 でビルドし直されていないと、コンテナの中でも起動に失敗します。理由は次の章で説明します。
.NET 10を入れるだけでは動かない理由¶
ここが、インフラエンジニアが勘違いしやすいところです。
サーバーに.NET 10のランタイムを入れても、.NET 8向けに作られたアプリは、基本的に.NET 10では動きません。
.NETには、アプリが要求するバージョンが見つからないときに、どこまで新しいランタイムで代わりに動かすかを決める設定（ロールフォワード）があります。この既定値は Minor です。
| 設定値 | 動き |
|---|---|
Minor（既定） |
同じメジャーバージョンの中で、新しいマイナーバージョンへ移る |
Major |
要求したメジャーバージョンが無ければ、新しいメジャーバージョンで動かす |
LatestMajor |
入っている中でいちばん新しいバージョンで動かす |
既定の Minor では、8から10のようにメジャーバージョンをまたぎません。そのため、.NET 8のランタイムを消して.NET 10だけにすると、アプリは起動時にエラーになります。
この設定は、*.runtimeconfig.json の rollForward のほか、環境変数 DOTNET_ROLL_FORWARD や、起動時の --roll-forward オプションでも変えられます。後から指定したものが優先され、オプションがいちばん強くなります。
# 環境変数で一時的にメジャーバージョンをまたがせる例（検証用）
DOTNET_ROLL_FORWARD=Major dotnet MyApp.dll
rollForward を Major にすれば動かすこと自体はできますが、テストしていない新しいランタイムで本番を動かすことになります。一時しのぎにはなっても、正式な移行の代わりにはなりません。
本来の移行は、開発チームがアプリの対象フレームワークを
net10.0に変えてビルドし直し、テストしてから入れ替える流れです。インフラエンジニアは、新しいランタイムの導入と、古いランタイムの撤去のタイミングを合わせます。
OSのパッケージで入れた.NETはどうなる？¶
Linuxでは、.NETをMicrosoftのリポジトリから入れる方法と、ディストリビューション自身のパッケージから入れる方法があります。
Ubuntuの開発者向けドキュメントを見ると、Ubuntuのバージョンごとに.NETの提供のされ方が違います。
| Ubuntu | .NET 8 | .NET 9 | .NET 10 |
|---|---|---|---|
| 26.04 LTS | backports PPA | backports PPA | main |
| 24.04 LTS | main | backports PPA | main |
| 22.04 LTS | main | backports PPA | backports PPA |
backports PPAについては、Canonicalのメンテナンスは.NETの本家のサポート期間か、Ubuntuのサポート期間に限られると書かれています。つまり、PPAから入れた.NET 8や.NET 9は、11月10日以降は更新を期待できないと考えておくのが安全です。
mainアーカイブに入っている.NET 8がその後どう扱われるかは、Ubuntuの公式情報を個別に確認してください。少なくとも、Microsoftの更新が止まることに変わりはありません。
RHELでも dnf install dotnet-sdk-8.0 のようにパッケージで入れられますが、Red Hatの案内でも.NET 8のサポートは2026年11月までとされています。
古いパッケージを放置しないという点では、OpenSSL 3.0のサポート終了やPython 3.10のサポート終了と同じ考え方です。OSの標準パッケージなのか、自分で追加したものなのかで、誰がパッチを出すのかが変わります。
11月10日までにやっておきたいこと¶
最後に、インフラエンジニアの立場で、11月10日までに進めておきたいことをまとめます。
1. 対象のサーバーとアプリを一覧にする¶
先ほどのコマンドで、.NET 8と.NET 9が入っているサーバーを洗い出します。ビルドサーバーやCIのランナー、コンテナのベースイメージも忘れずに入れます。
一覧には、サーバー名、入っているランタイムとSDK、動いているアプリ、アプリの担当者を書いておくと、開発チームとの相談がスムーズになります。
2. 開発チームと移行の順番を決める¶
アプリを net10.0 にするのは開発チームの作業です。インフラエンジニアは、検証環境に.NET 10のランタイムを先に入れて、テストできる状態を用意します。
IISで動かしている場合は、.NET 10用のHosting Bundleを入れる必要があります。Hosting Bundleを入れたあとはIISの再起動が必要になることがあるので、作業時間を決めておきます。
Windows Server自体のサポート期限も近いなら、あわせて確認しておきましょう。たとえばWindows Server 2016のサポート終了は2027年1月です。
3. 間に合わないアプリを決めておく¶
全部のアプリを11月10日までに移せるとは限りません。間に合わないアプリは、外部に公開していないか、どこからアクセスされるかを確認して、いつまでに移すかを決めておきます。
サポート終了後も、最後に出たパッチまでは当てておくことが大切です。11月10日に最後の更新が出る可能性もあるので、その日の月例パッチも確認してください。
4. 移行が終わったら古いランタイムを消す¶
アプリの移行が終わったら、.NET 8と.NET 9のランタイムやSDKをサーバーから削除します。使っていないランタイムが残っていると、脆弱性スキャンで毎回指摘されることになります。
ただし、同じサーバーで別のアプリがまだ.NET 8を使っていないかは、削除前に必ず確認してください。
まとめ¶
.NET 8と.NET 9は、2026年11月10日に同じ日にサポートが終わります。STSのサポートが2年に延びたことで、LTSの.NET 8とSTSの.NET 9の終了日がそろいました。
インフラエンジニアがまずやることは、dotnet --list-runtimes や *.runtimeconfig.json、Dockerfileを見て、どこに.NET 8と.NET 9が残っているかを洗い出すことです。
.NET 10のランタイムを入れるだけでは、.NET 8向けのアプリは動きません。 アプリの移行は開発チームと順番を決めて進め、終わったら古いランタイムを片付けましょう。
サポート終了の対応では、Linuxのパッケージ管理やサービスの再起動、ログの確認など、基本的な操作が何度も出てきます。Linuxを基礎から体系的に学び直したい方は、InfraAcademyのLinuxロードマップも使ってみてください。
1か月あればまだ間に合います。まずは一覧づくりから始めてみてください。
参考¶
- .NET and .NET Core Support Policy（Microsoft）
- .NET 8 and .NET 9 will reach End of Support on November 10, 2026（.NET Blog）
- End of support looms for .NET 8 and .NET 9（InfoWorld）
- Available .NET versions（Ubuntu for Developers）
- Install .NET SDK or .NET Runtime on Ubuntu（Microsoft Learn）
- Select the .NET version to use（Microsoft Learn）
- .NET 8 on RHEL and OpenShift（Red Hat Developer）
