.NET 8・9のサポート終了、.NET 10へ移行する手順【2026年版】

.NET 8・9のサポート終了、.NET 10へ移行する手順【2026年版】
IT Picks編集部

2026年11月10日、.NET 8 と .NET 9 のサポートが終わりました。同じ日に新しい .NET 11 が公開され、いま Microsoft のサポートを受けられるのは .NET 10(LTS)と .NET 11(STS)の2つだけです。

.NET 8 は3年サポートの LTS として多くのアプリに使われてきました。11月の月例更新(8.0.34)が最後のパッチになり、これから見つかる脆弱性は直されません。

.NET and .NET Core official support policy
.NET and .NET Core official support policy

この記事では、自分のアプリが対象かの確かめ方、.NET 10 と .NET 11 の選び方、そして TargetFramework・global.json・NuGet・Docker イメージの直し方を順に紹介します。テスト用の Linux 環境(Docker)で .NET 8 の Web API を実際に .NET 10 へ移したときに出たエラーと、その直し方も載せています。

「動いているから後回し」にしやすい .NET の更新を、半日で終わる作業に分解する——という位置づけの手順ガイドです。

この記事はこんな人向けです

  • .NET 8 や .NET 9 で作ったアプリを、サーバーや Docker で動かしている
  • .NET 10(LTS)と .NET 11(STS)のどちらに上げるか決めたい
  • TargetFramework・global.json・NuGet・Docker のどこを直せばいいか、順番に知りたい

.NET 8・9のサポート終了とは?一言でまとめると

一言でいうと、.NET 8 と .NET 9 は、2026年11月10日から Microsoft の修正が届かない「古いランタイム」になったということです。

.NET は毎年11月に新しいメジャー版が出ます。偶数の版は3年サポートの LTS、奇数の版は2年サポートの STS です。品質に差はなく、違うのはサポートの長さだけです。今回は、2023年に出た LTS の .NET 8 と、2024年に出た STS の .NET 9 が、同じ日に期限を迎えました。

版 種類 公開日 最新のパッチ サポート終了 状態
.NET 8 LTS(3年) 2023年11月14日 8.0.34 2026年11月10日 終了
.NET 9 STS(2年) 2024年11月12日 9.0.23 2026年11月10日 終了
.NET 10 LTS(3年) 2025年11月11日 10.0.15 2028年11月14日 サポート中
.NET 11 STS(2年) 2026年11月10日 11.0.0 2028年11月14日 サポート中

※ 2026年11月14日時点の .NET 公式サポートポリシーの表をもとに、IT Picks が並べ直したものです。

.NET 9 は STS なのに .NET 8 と同じ日に終わるのは、STS のサポートが2年だからです。今のポリシーでは、STS は「次の版が出てから1年」、毎年11月に新しい版が出るので合わせて2年になります。

.NET 8〜11 のサポート期間のタイムライン
2026年11月14日時点の .NET 公式サポートポリシーをもとに IT Picks 編集部が作成

公式サイトのサポート中の版の表は次のとおりです。

.NET 公式サポートポリシーのサポート中の版の表
2026年11月14日時点(出典: .NET「.NET and .NET Core official support policy」)

サポートが切れると何が困る?

サポートが切れても、アプリが急に止まるわけではありません。ただし、次のことが起きます。

  • セキュリティ修正が出ない: 11月10日の月例更新では、ASP.NET Core のサービス拒否・権限昇格などの脆弱性が 8・9・10・11 にまとめて直されました。これから同じような脆弱性が見つかっても、8 と 9 には修正版が出ません
  • 不具合の修正・技術支援も無い: Microsoft のサポート窓口に問い合わせても、対象外になります
  • 自動の更新にも頼れない: Windows では Microsoft Update で .NET を自動で更新できますが、それはサポート中の版の話です

公式のポリシーも、サポートが切れた版はアプリやデータ、動かしている環境を危険にさらすので使わないよう強く勧めています。インターネットに公開している Web API・Web サイトは、特に急いだほうがよいと IT Picks は考えています。

サポートが切れた版の一覧は、公式サイトの「Out of support versions」の表にあります。

.NET 公式サポートポリシーのサポート終了の版の表
2026年11月14日時点(出典: .NET「.NET and .NET Core official support policy」)

ほかのソフトのサポート終了の対応は、PostgreSQL 14 の記事でも同じ流れでまとめています。

あわせて読みたい
PostgreSQL 14のサポート終了はいつ?確認と移行手順【2026年版】
PostgreSQL 14のサポート終了はいつ?確認と移行手順【2026年版】

自分のアプリは対象?バージョンの確認方法

確かめる場所は4つあります。サーバーに入っているものと、アプリが使うと決めているものは別なので、両方を見ます。

① 入っている SDK とランタイムを見る

サーバーや開発用の PC で、次の2つを実行します。dotnet --info なら、SDK・ランタイム・OS の情報をまとめて表示できます。

ターミナル(サーバー・開発用の PC)

dotnet --list-sdks
dotnet --list-runtimes

Microsoft.NETCore.App 8.0.x や Microsoft.AspNetCore.App 9.0.x が出たら、そのサーバーにはサポートが切れたランタイムが入っています。

② プロジェクトの TargetFramework を見る

アプリがどの版を対象にしているかは、プロジェクトファイル(.csproj)の TargetFramework で決まります。

ターミナル(リポジトリの中)

grep -rn "<TargetFramework" --include=*.csproj .

net8.0 か net9.0(net8.0-windows なども同じ)なら移行の対象です。

③ Dockerfile のイメージのタグを見る

Docker で動かしているなら、FROM mcr.microsoft.com/dotnet/aspnet:8.0 のようなタグを見ます。ホストに何が入っていても、コンテナの中はタグの版で動きます。

ターミナル(リポジトリの中)

grep -rn "mcr.microsoft.com/dotnet" --include=Dockerfile* .

④ global.json を見る

リポジトリに global.json があると、使う SDK の版がそこで固定されます。"version": "8.0.xxx" のままだと、新しい SDK だけを入れたマシンではビルドできません(あとの「実際に移行してみた」で起きたエラーです)。

確かめる場所 見る所 移行の対象の目印
サーバー・PC dotnet --list-runtimes 8.0.x・9.0.x のランタイム
プロジェクト .csproj の TargetFramework net8.0・net9.0
Docker Dockerfile の FROM sdk:8.0・aspnet:9.0 など
SDK の固定 global.json の version 8.0.xxx・9.0.xxx
CI ワークフローの .NET のセットアップ 8.0・9.0 の指定

.NET 10と.NET 11のどちらに移行する?選び方

移行先は .NET 10(LTS) か .NET 11(STS) です。2028年11月14日にどちらもサポートが終わるのが、今回の大きなポイントです。

.NET 10 .NET 11
種類 LTS(3年) STS(2年)
公開日 2025年11月11日 2026年11月10日
サポート終了 2028年11月14日 2028年11月14日
C# の既定の版 C# 14 C# 15(共用体型など)
出てからの期間 約1年(パッチ 10.0.15) 公開直後(11.0.0)
最小の CPU(x64) 変わらず x86-64-v2 に引き上げ
次の移行先 2028年11月までに次の版へ 2028年11月までに次の版へ

※ 2026年11月14日時点の公式サポートポリシー・.NET 11 の発表・.NET 11 のランタイムの新機能のページをもとに作成。

終わる日が同じなので、「長く使えるのは LTS」という普段の考え方は、今回は当てはまりません。どちらを選んでも、2028年11月14日までに次の版への移行が必要です。

IT Picks のおすすめは次のとおりです。

  • .NET 8 から上げる、いま動いている業務アプリ: .NET 10。1年分のパッチが積み重なっていて、ライブラリ(NuGet パッケージ)の対応も進んでいます。.NET 8 → 10 は LTS どうしの移行なので、情報も見つけやすいです
  • 新しく作るアプリ、C# 15 の機能を使いたいアプリ: .NET 11。サポートの終わりは 10 と同じなので、損はありません
  • .NET 9 から上げるアプリ: 9 の機能を使っているなら差は小さく、どちらでも。社内の決まりで「LTS だけ」とされているなら 10 です
.NET 10 と .NET 11 の選び方のチャート
2026年11月14日時点の .NET 公式サポートポリシーと .NET 11 の発表をもとに IT Picks 編集部が作成

.NET 10へ移行する手順

ここからは、.NET 8 → .NET 10 を例にします。.NET 11 に上げる場合も、10.0 を 11.0 に読み替えれば同じ流れです。

.NET 10 へ移行する手順の流れ図
Microsoft の .NET 11 の発表・global.json・バージョン選択のドキュメントをもとに IT Picks 編集部が作成

① .NET 10 の SDK を入れる

開発用の PC と、ビルドするマシン(CI・ビルドサーバー)の両方に .NET 10 の SDK を入れます。入れたら dotnet --list-sdks に 10.0.xxx が出るかを見ます。SDK を入れただけでは、アプリの対象は変わりません。

② global.json の SDK の版を直す

global.json があるリポジトリは、SDK の版を 10 に直します。rollForward を latestFeature にしておくと、10.0 の新しい機能バンド・パッチを自動で使います。

global.json

{
  "sdk": {
    "rollForward": "latestFeature",
    "version": "10.0.100"
  }
}

③ TargetFramework を net10.0 にする

.csproj の TargetFramework を書き換えます。net8.0-windows のようなプラットフォームの接尾辞は残します(net10.0-windows)。

HelloApi.csproj

<TargetFramework>net10.0</TargetFramework>

④ NuGet パッケージを 10 に合わせる

Microsoft.AspNetCore.* や Microsoft.EntityFrameworkCore.* など、.NET の版と番号がそろっているパッケージは 10.0.x にそろえます。古い版や脆弱性のある版は、次のコマンドで一覧にできます(.NET 9 以前の SDK では dotnet list package の形です)。

ターミナル(プロジェクトの中)

dotnet package list --outdated
dotnet package list --vulnerable

--outdated の「Latest」には、.NET 11 用の 11.0.0 が出ます。.NET 10 に移すなら、番号を指定して 10 の版を入れます。

ターミナル(プロジェクトの中)

dotnet package add Microsoft.AspNetCore.OpenApi --version 10.0.15

⑤ 破壊的変更を読む

.NET 8 から上げる場合は、.NET 9 と .NET 10 の両方の「破壊的変更(Breaking changes)」のページが対象です。ASP.NET Core・EF Core は別のページにまとまっています。ビルドの警告に出たものから順に見ていくと、読む量を減らせます。

⑥ Docker のイメージのタグを直す

Dockerfile の FROM を 10.0 にします。.NET 10 から、タグに OS を書かないイメージは Debian ではなく Ubuntu 24.04 になりました。Debian のイメージは .NET 10 では出ていません。

Dockerfile(変える所)

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
FROM mcr.microsoft.com/dotnet/aspnet:10.0

-bookworm-slim のような Debian のタグを書いている Dockerfile は、Ubuntu(-noble)などのタグに直す必要があります。apt-get install でパッケージを足している場合は、Ubuntu 24.04 でも同じ名前で入るかを確かめておくと安心です。

.NET 10 で既定のイメージが Ubuntu になったことを説明する公式ページ
2026年11月14日時点(出典: Microsoft Learn「Default .NET images use Ubuntu」)

⑦ CI とサーバーを直して、テストする

GitHub Actions などの CI の .NET のセットアップを 10.0 にし、テストを流します。サーバーに直接入れて動かしている場合は、.NET 10 のランタイム(ASP.NET Core Runtime)を入れてから新しいビルドを置きます。古い 8 のランタイムは、使うアプリが無くなってから消します。

CI を自分のマシンで動かしている場合の設定は、こちらの記事が参考になります。

あわせて読みたい
GitHub Actions self-hosted runnerを自宅で使う手順【2026年版】
GitHub Actions self-hosted runnerを自宅で使う手順【2026年版】

実際に .NET 8 のアプリを .NET 10 に移行してみた

2026年11月14日に、テスト用の Linux 環境(Docker)で次の手順を実際に動かしました。使ったのは公式のコンテナイメージ mcr.microsoft.com/dotnet/sdk:8.0(SDK 8.0.428)と sdk:10.0(SDK 10.0.404)、aspnet:8.0 と aspnet:10.0 です。

① .NET 8 の Web API を作って動かす

.NET 8 の SDK のイメージで、ひな形から Web API を作り、global.json で SDK を 8 に固定しました。

ターミナル(sdk:8.0 のコンテナ)

dotnet new webapi -o HelloApi --framework net8.0
cd HelloApi
dotnet new globaljson --sdk-version 8.0.428 --roll-forward latestFeature
dotnet build -c Release

実行結果

Build succeeded.
    0 Warning(s)
    0 Error(s)

ひな形の .csproj は net8.0 で、Microsoft.AspNetCore.OpenApi 8.0.34 と Swashbuckle.AspNetCore 6.6.2 を使っていました。起動して /weatherforecast を呼ぶと、200 OK と天気予報の JSON が返りました。Dockerfile で作ったイメージ(aspnet:8.0)の中は Debian 12 でした。

② .NET 10 だけの環境でビルドすると止まる

同じフォルダを .NET 10 の SDK のイメージでビルドしました。

global.json とランタイムのエラー
2026年11月14日時点(テスト用の Linux 環境・.NET SDK 10.0.404 と ASP.NET Core Runtime 10.0.15 の表示。一部を省略)

global.json が 8.0.428 を指したままなので、「A compatible .NET SDK was not found.」で止まりました。同じ状態では dotnet new globaljson --force で作り直すこともできなかったため、global.json は手で "10.0.100" に書き換えました。

もう1つ、.NET 8 でビルドしたアプリを .NET 10 のランタイムだけのイメージ(aspnet:10.0)で起動すると、「You must install or update .NET to run this application.」で起動しませんでした。ランタイムは既定でメジャー版を超えて動かないので、ランタイムだけ上げても移行にはなりません。

③ TargetFramework を net10.0 にしてビルドする

ターミナル(sdk:10.0 のコンテナ)

sed -i 's|<TargetFramework>net8.0</TargetFramework>|<TargetFramework>net10.0</TargetFramework>|' HelloApi.csproj
dotnet build -c Release

この時点ではパッケージが 8 のままでも、ビルドは警告0・エラー0で通りました。次に古いパッケージを調べました。

ターミナル(sdk:10.0 のコンテナ)

dotnet package list --outdated
dotnet package list --outdated と 11.0.0 を入れたときのエラー
2026年11月14日時点(テスト用の Linux 環境・.NET SDK 10.0.404 の表示。一部を省略)

「Latest」の列は 11.0.0 でした。試しに Microsoft.AspNetCore.OpenApi 11.0.0 を入れると、追加はできたのに、ビルドで CS9057 の警告と CS1061 のエラー(WithOpenApi が見つからない)が出ました。.NET 10 では 10.0.15 を指定して入れ直しました。

④ 警告を消して、起動してみる

10.0.15 にすると、.WithOpenApi() に ASPDEPR002(非推奨)の警告が1件出ました。ASP.NET Core 10 の破壊的変更の一覧にある変更で、Program.cs から .WithOpenApi() を消すと警告は0件になりました。

Swashbuckle 6.6.2 の起動時のエラーと、10.3.1 にしたあとの結果
2026年11月14日時点(テスト用の Linux 環境・ASP.NET Core 10.0.15 の表示。一部を省略)

ところが、ビルドは通るのに、起動すると System.TypeLoadException で落ちました。原因は Swagger の画面を作るパッケージ Swashbuckle.AspNetCore 6.6.2 です。古い版の Swashbuckle は ASP.NET Core 10 では動かず、新しい版に上げる必要がありました。

  • Swashbuckle を最新の 11.0.1 にすると、Microsoft.OpenApi の版が合わず NU1107(版の衝突)で復元できませんでした
  • 10.3.1 にすると、ビルド・起動とも通り、/weatherforecast は 200 OK、/swagger/v1/swagger.json も 200 を返しました

Microsoft 以外のパッケージは、最新版が .NET 11 向けのことがあるので、各パッケージの説明で対応する .NET の版を確かめてから上げると安心です。

⑤ Dockerfile を 10.0 にしてイメージを作る

Dockerfile は、Microsoft のチュートリアルと同じ「sdk でビルドして aspnet にコピーする」2段の形です。変えたのは FROM の2行だけです。

Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /App
COPY . ./
RUN dotnet restore
RUN dotnet publish -c Release -o out --no-restore

FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /App
COPY --from=build /App/out .
ENTRYPOINT ["dotnet", "HelloApi.dll"]

ターミナル

docker build -t helloapi:net10 .
docker run -d --name hello10 -p 8082:8080 helloapi:net10
curl -s -i http://127.0.0.1:8082/weatherforecast
.NET 10 のイメージで動かした結果
2026年11月14日時点(テスト用の Linux 環境・Docker 29.9.2 の表示。一部を省略)

コンテナは 8080 番で待ち受け、curl には 200 OK が返りました。コンテナの中の OS は Ubuntu 24.04.5 LTS、ランタイムは 10.0.15 でした。

この先の、本番のサーバーへの配置・CI の設定は、この記事の「.NET 10へ移行する手順」の⑦のとおり、それぞれの環境の手順で行ってください(ここでは試していません)。

Docker でアプリを動かす構成の全体は、こちらの記事で紹介しています。

あわせて読みたい
Docker Compose初心者入門:Node.jsをVPSで公開【2026年版】
Docker Compose初心者入門:Node.jsをVPSで公開【2026年版】

移行でつまずきやすい点と対策

実際に移したときに出たもの(上の4つ)と、公式の破壊的変更から起きやすいもの(下の3つ)を表にまとめました。

症状 原因 対策
「A compatible .NET SDK was not found.」 global.json が 8.0 の SDK を指している version を 10.0.100 に、rollForward を latestFeature に
「You must install or update .NET to run this application.」 net8.0 のアプリを 10 のランタイムだけで起動した TargetFramework を net10.0 にしてビルドし直す
NuGet の「最新」を入れたらビルドエラー 11.0.0 は .NET 11 用 10.0.x を番号で指定する
ビルドは通るのに起動で TypeLoadException 古い Swashbuckle と Microsoft.OpenApi 2.0 が合わない Swashbuckle を 10.x に上げる(または組み込みの OpenAPI に移る)
ASPDEPR002 の警告 WithOpenApi が .NET 10 で非推奨 .WithOpenApi() を消す
10.0-bookworm-slim などのタグが無い .NET 10 は Debian のイメージを出していない 10.0(Ubuntu 24.04)や 10.0-noble などに直す
.NET 11 で起動しない古いサーバー .NET 11 は x64 の最小要件が x86-64-v2 その環境は .NET 10 にする
移行で版をそろえる所の関係図
Microsoft Learn の global.json・バージョン選択・コンテナイメージのドキュメントをもとに IT Picks 編集部が作成

版の数字は「SDK・TargetFramework・NuGet・イメージのタグ」の4か所でそろえる——これを最初に一覧にしておくと、移行の漏れが減ります。

ほかのデータベースのサポート終了でも、確かめる所は似ています。MySQL 8.0 の移行の記事もあわせてどうぞ。

あわせて読みたい
MySQL 8.0は10月の修正対象外に:確認と8.4への移行【2026年版】
MySQL 8.0は10月の修正対象外に:確認と8.4への移行【2026年版】

よくある質問

Q. サポートが切れた .NET 8 のアプリは、すぐに止まりますか? A. 止まりません。動き続けますが、11月10日の 8.0.34 より後の修正は出ません。インターネットに公開しているアプリから順に移行するのがおすすめです。

Q. .NET 8 から .NET 10 へ、9 を飛ばして上げてもいいですか? A. はい、TargetFramework を直接 net10.0 にできます。ただし、.NET 9 と .NET 10 の両方の破壊的変更が対象になるので、2つのページを読みます。

Q. .NET 10 と .NET 11 のサポートが同じ日に終わるのはなぜですか? A. LTS は3年、STS は2年で、1年遅れて出た .NET 11 の終わりが .NET 10 と同じ2028年11月14日になるからです。終わる日は Patch Tuesday(毎月第2火曜)にそろえられます。

Q. .NET Framework 4.8 のアプリも対象ですか? A. 今回終わったのは .NET 8・9(旧 .NET Core の系列)です。.NET Framework は別の製品で、11月の月例更新でも別に扱われています。この記事の対象ではありません。

Q. Windows のサーバーなら自動で更新されますか? A. サポート中の .NET は Microsoft Update で更新できますが、8・9 から 10 への移行は自動ではありません。自己完結型(Self-Contained)で配っているアプリは、ランタイムがアプリに含まれるので、ビルドし直して配り直します。

まとめ

.NET 8・9 のサポート終了と移行のポイントをまとめます。

  • サポート終了日:2026年11月10日(.NET 8・.NET 9)
  • 最後のパッチ:8.0.34・9.0.23
  • 移行先:.NET 10(LTS)または .NET 11(STS)。どちらも2028年11月14日まで
  • おすすめ:動いている業務アプリは .NET 10、新規や C# 15 を使うなら .NET 11
  • 直す所:global.json・TargetFramework・NuGet パッケージ・Docker のイメージのタグ・CI
  • 注意点:既定のイメージは Ubuntu 24.04 に、NuGet の「最新」は 11 用のことがある

まずは dotnet --list-runtimes と grep TargetFramework で、どのアプリが対象かを一覧にするところから始めてみてください。

ABOUT ME
IT Picks 編集部
IT Picks 編集部
ITツール・Webサービス紹介メディア
IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。
記事URLをコピーしました