MENU

Azure App Serviceの.NET 8サポート終了日が決定：2026年4月更新の影響と移行手順

Azure

Azure App Serviceで.NET 8アプリを運用している場合、今回の結論は明確です。.NET 8 LTSのサポート終了日は2026年11月10日であり、App Service上の.NET 8アプリは早めに.NET 10 LTSへの移行計画を作るべきです。2026年4月24日にMicrosoft公式のAzure Updatesで「Retirement: Support for .NET 8 (LTS) ends on November 10, 2026—upgrade your apps to .NET 10 (LTS)」が公開され、Azure ID 558033としてロードマップに追加されました。(Microsoft Azure)

重要なのは、「サポート終了後もアプリが即停止するわけではない」一方で、「安全に運用できる状態とは言えなくなる」点です。App Serviceでは、サポート終了後も対象ランタイムのアプリが動き続ける場合がありますが、ランタイムに対するセキュリティパッチや関連するカスタマーサポートは期待できなくなります。開発者、DevOpsエンジニア、プラットフォームチームは、単なるバージョン更新ではなく、セキュリティ・CI/CD・運用責任の見直しとして対応する必要があります。(Microsoft Learn)

目次

Azure App Service / .NETの2026年4月更新ポイント

今回のAzure App Service / .NET更新は、新機能追加ではなく廃止・サポート終了の事前告知です。つまり、今すぐ本番環境が壊れる変更ではありません。しかし、2026年11月10日以降も.NET 8を使い続ける場合、セキュリティ修正やサポート面でリスクを抱えることになります。

更新ポイント実務上の意味取るべき対応
.NET 8 LTSのサポート終了日が2026年11月10日と案内されたApp Service上の.NET 8アプリも移行対象として扱う必要がある対象アプリを棚卸しし、移行期限をバックログに入れる
推奨移行先として.NET 10 LTSが示された.NET 9への移行は長期対策になりにくい本番アプリは原則.NET 10 LTSを移行先候補にする
アプリは停止しない可能性があるが、サポートとセキュリティ更新が問題になる「動いているから問題ない」という判断が危険になるセキュリティレビュー、監査、SLAへの影響を確認する
App Serviceのランタイムライフサイクルは言語コミュニティのサポートタイムラインに従うAzure側だけで延命できるとは限らない.NET公式サポートポリシーとApp Service設定をセットで確認する

Microsoftの.NETサポートポリシーでは、2026年4月時点で.NET 8と.NET 9はいずれも2026年11月10日にサポート終了、.NET 10はLTSとして2028年11月14日までサポート対象とされています。移行先を検討するなら、.NET 9ではなく.NET 10を優先するのが自然です。(Microsoft)

何が変わるのか：「動く」と「サポートされる」は別問題

Azure App Serviceの.NET 8サポート終了で最も誤解されやすいのは、サポート終了日を過ぎた瞬間にアプリが起動しなくなると考えることです。実際には、App Serviceのポリシー上、サポート終了後も既存アプリがそのまま動き続ける場合があります。

ただし、これは「安全に使い続けられる」という意味ではありません。

特に問題になるのは次の3点です。

リスク具体例影響を受ける担当
セキュリティ更新の停止.NET 8ランタイムに脆弱性が見つかっても修正を受けられない可能性があるセキュリティ担当、SRE、DevOps
サポート対象外障害調査時に「サポートされるランタイムへ移行してください」と案内される可能性があるプラットフォームチーム、運用チーム
監査・コンプライアンス上の指摘EOL済みランタイムの利用が内部統制や顧客監査で問題になる情報システム、監査対応担当
将来のApp Service設定変更への追随困難ポータル上で古いランタイムが選択しづらくなる、構成変更時に制約が出る開発者、インフラ担当

App Serviceの言語ランタイムサポートポリシーでは、サポート終了後のランタイムはセキュリティパッチや関連サポートを受けられず、問題が発生した場合はサポート対象バージョンへの移行が必要になると説明されています。(Microsoft Learn)

対象になるアプリの見分け方

まず確認すべきなのは、「Azure App Serviceにデプロイしている.NETアプリが、本当に.NET 8に依存しているか」です。App Serviceの画面だけを見て判断すると、見落としが発生します。

確認すべき場所

確認対象見るべきポイント注意点
.csproj<TargetFramework>net8.0</TargetFramework>複数プロジェクト構成ではWebアプリ以外のライブラリも確認する
global.json使用SDKバージョンCIとローカルでSDKがずれているとビルド結果が変わる
App ServiceのランタイムスタックLinuxの場合はlinuxFxVersionWindows App ServiceではKuduで実行環境を確認する
CI/CDパイプラインsetup-dotnet、Dockerイメージ、ビルドエージェントビルドだけ.NET 8、実行は別バージョンというケースもある
Dockerfilemcr.microsoft.com/dotnet/aspnet:8.0などカスタムコンテナはApp Service側の自動更新だけでは不十分
Self-contained deploymentアプリにランタイムを同梱しているかランタイム更新責任がアプリ側に寄る

特に注意したいのは、フレームワーク依存デプロイと自己完結型デプロイの違いです。フレームワーク依存デプロイではApp Service側のランタイム更新の影響を受けます。一方、自己完結型デプロイではアプリにランタイムを含めるため、開発チームが再ビルドと再デプロイでランタイムを更新する必要があります。Microsoftの.NETサポートポリシーでも、自己完結型デプロイではアプリ側がランタイム更新に責任を持つと説明されています。(Microsoft)

Azure App Serviceで.NETバージョンを確認する方法

Linux App Serviceで現在の.NETランタイムスタックを確認する場合は、Azure CLIで次のように確認できます。

az webapp config show \
  --resource-group <resource-group-name> \
  --name <app-name> \
  --query linuxFxVersion

利用可能なLinux向けランタイムは次のコマンドで確認できます。

az webapp list-runtimes --os linux | grep DOTNET

Microsoft Learnでも、App ServiceのLinux環境ではlinuxFxVersionで現在の.NET Coreバージョンを確認し、az webapp list-runtimes --os linuxで利用可能なランタイムを確認する方法が案内されています。Windows App Serviceでは、Kuduのコンソールでdotnet --infoを実行して、インストール済みランタイムとSDKを確認できます。(Microsoft Learn)

複数サブスクリプションにApp Serviceがある場合は、Azure Resource Graphで棚卸しするのが現実的です。

az graph query -q "
Resources
| where type =~ 'microsoft.web/sites'
| project
    subscriptionId,
    resourceGroup,
    name,
    kind,
    linuxFxVersion=tostring(properties.siteConfig.linuxFxVersion),
    netFrameworkVersion=tostring(properties.siteConfig.netFrameworkVersion)
"

この結果だけで完全に判断せず、各アプリのリポジトリ、CI/CD、Dockerfile、runtimeconfig.jsonも確認してください。App Serviceの設定上は.NET 8に見えなくても、ビルド成果物やコンテナイメージが.NET 8ベースになっている場合があります。

.NET 10 LTSへ移行すべき理由

今回の更新で実務上の移行先として最も現実的なのは.NET 10 LTSです。.NET 9はSTSですが、2026年4月時点の公式サポート表では.NET 8と同じ2026年11月10日にサポート終了します。つまり、.NET 8から.NET 9へ移行しても、サポート期限の延長効果はほとんどありません。(Microsoft)

.NET 10はLTSであり、ASP.NET Core 10.0ではBlazor、OpenAPI、Minimal API、診断、Identityのパスキー対応などの更新が含まれます。単にサポート期限を延ばすだけでなく、今後のWebアプリ基盤として整理し直すタイミングにもなります。(Microsoft Learn)

移行先判断向いているケース
.NET 10 LTS第一候補本番運用、長期保守、グローバル展開、監査対象システム
.NET 9原則おすすめしにくい短期検証、.NET 10移行前の一時的な互換性確認
.NET 8継続期限付きの例外対応移行不可の依存ライブラリがあり、リスクを明示して暫定運用する場合
カスタムコンテナ特定ランタイムやOS依存が強い場合App Service標準スタックでは要件を満たせない場合

移行作業の基本手順

.NET 8から.NET 10への移行は、単にApp Serviceのランタイムスタックを変更するだけでは不十分です。アプリのターゲットフレームワーク、SDK、NuGet、CI/CD、監視項目を一緒に更新する必要があります。

現実的な移行フロー

手順作業内容完了条件
棚卸しApp Service、リポジトリ、Dockerfile、CI/CDの.NET 8利用箇所を洗い出す対象アプリ一覧と責任者が決まっている
影響調査NuGet、EF Core、ASP.NET Core、認証、ログ、外部API連携を確認する破壊的変更や要修正箇所がチケット化されている
開発環境更新.NET 10 SDK、IDE、CIビルド環境を整えるローカルとCIで同じSDK系列を使える
ターゲット更新TargetFrameworkをnet10.0へ変更するビルドが通る
テスト単体、結合、E2E、負荷、セキュリティテストを実行する本番相当の検証環境で主要シナリオが通る
App Service設定更新Linuxランタイムスタックやコンテナベースイメージを更新するステージングスロットで正常起動する
段階リリースDeployment slots、カナリア、ロールバック手順を用意する影響を限定して本番反映できる
運用移行監視、アラート、Runbook、障害対応手順を更新する運用チームが.NET 10前提で対応できる

Microsoftの.NETアップグレード手順では、新しい.NETバージョンへ移行する際にSDKを更新し、プロジェクトファイルのTargetFrameworkを新しいバージョンへ変更してビルドする流れが説明されています。ただし、実務では警告、依存パッケージ、破壊的変更、テストの確認が不可欠です。(Microsoft Learn)

.csprojの変更例

.NET 8のプロジェクトは、たとえば次のようになっています。

<TargetFramework>net8.0</TargetFramework>

.NET 10へ移行する場合は、次のように変更します。

<TargetFramework>net10.0</TargetFramework>

複数ターゲットの場合は、TargetFrameworksも確認します。

<TargetFrameworks>net8.0;netstandard2.1</TargetFrameworks>

このような構成では、どのターゲットを残すかを決める必要があります。社内ライブラリやNuGetパッケージを配布している場合、利用側アプリの対応状況も確認してください。

App Service側で変更するときの注意点

Linux App Serviceで.NET 10のランタイムスタックへ変更する場合、利用可能な値を確認したうえで設定します。値は環境や公開状況によって変わる可能性があるため、先にaz webapp list-runtimes --os linuxで確認してください。

az webapp config set \
  --name <app-name> \
  --resource-group <resource-group-name> \
  --linux-fx-version "DOTNETCORE|10.0"

ただし、App Serviceのランタイムだけを変更しても、アプリ本体がnet8.0のままなら移行は完了していません。逆に、アプリをnet10.0へ変更しても、App Service側やコンテナ側が.NET 10を実行できない状態ならデプロイ後に起動エラーになります。

よくある失敗パターン

失敗パターン起きること防ぎ方
App Service設定だけを.NET 10にするアプリ本体が.NET 8のままで、移行完了と誤認する.csproj、ビルドログ、実行ログを確認する
CIのSDKが古いローカルでは成功するがCIでビルド失敗するglobal.jsonとCIのsetup-dotnetを更新する
Dockerfileのベースイメージを変更し忘れる本番だけ.NET 8のまま動くaspnet:8.0やsdk:8.0を検索する
ステージングスロットなしで本番反映する起動エラー時に即ユーザー影響が出るDeployment slotsで事前検証する
ログ・監視の確認を後回しにする起動後の性能劣化や例外増加に気づきにくいレスポンスタイム、例外率、依存先エラーを比較する
グローバル環境の時差を考慮しない期限直前の地域別リリースで混乱する2026年11月10日より前の共通凍結日を設定する

DevOpsとプラットフォームチームが今すぐやるべきこと

.NET 8のサポート終了対応は、開発チームだけに任せると漏れが出やすい作業です。App Service、CI/CD、コンテナ、監視、アラート、Service Health通知の受信者まで含めて、プラットフォーム全体で管理する必要があります。

App Serviceの通知は、サブスクリプション所有者や管理者などに送られますが、ContributorやReaderなどのロールは、Service Health Alertsに明示的に登録しない限り直接通知を受け取らない場合があります。移行担当者が通知を受け取れるよう、アラート設計も見直してください。(Microsoft Learn)

担当別チェックリスト

担当チェック項目
開発者TargetFramework、NuGet、EF Core、ASP.NET Core、認証・認可、API互換性を確認する
DevOpsCIのSDK、GitHub Actions / Azure Pipelines、Dockerfile、ビルドキャッシュ、デプロイスロットを更新する
プラットフォームチームApp Service一覧、ランタイムスタック、Service Health Alert、Azure Policy、タグ設計を整備する
セキュリティ担当EOLランタイム利用の例外承認、脆弱性管理、監査証跡を確認する
プロダクト責任者リリース凍結期間、ユーザー影響、移行期限、ロールバック判断基準を決める

移行スケジュールの目安

2026年11月10日がサポート終了日だからといって、11月に作業を始めるのは危険です。特にグローバル向けサービスでは、各地域のリリース凍結、年末商戦、監査、顧客レビューの時期と重なる可能性があります。

時期推奨アクション
2026年4月〜5月対象App Serviceと.NET 8利用箇所を棚卸しする
2026年6月〜7月.NET 10移行ブランチを作り、主要アプリからビルド検証を始める
2026年8月ステージング環境で結合テスト、負荷テスト、監視確認を行う
2026年9月優先度の高い本番アプリから段階移行する
2026年10月残タスク、例外承認、顧客影響のあるアプリを最終処理する
2026年11月前半期限直前の変更を避け、既に移行済みであることを確認する

大規模な組織では、App Serviceの数よりも「依存関係の数」がボトルネックになります。たとえば、共通認証ライブラリ、社内NuGet、ログ基盤、決済APIクライアント、古いEF Core依存が移行を遅らせることがあります。まず共通部品を.NET 10対応にし、その後に個別アプリを移行すると手戻りを減らせます。

ツール活用時の注意点

.NETの移行支援では、従来.NET Upgrade Assistantが使われてきました。ただし、2026年時点のMicrosoft Learnでは、.NET Upgrade Assistantは公式に非推奨とされ、Visual Studio 2026やVisual Studio 2022 17.14.16以降に含まれるGitHub Copilot modernization chat agentの利用が案内されています。(Microsoft Learn)

ツールを使う場合でも、以下は人間が判断すべきです。

判断項目なぜ重要か
破壊的変更の受け入れ可否自動修正でビルドが通っても、業務仕様が変わる可能性がある
NuGet更新の範囲依存パッケージのメジャー更新で挙動が変わることがある
認証・認可の確認Cookie、JWT、OpenID Connect周りは本番影響が大きい
パフォーマンス比較.NET 10で改善する箇所もあれば、設定変更が必要な箇所もある
ロールバック設計ランタイムとアプリを同時に戻せる状態にしておく必要がある

AIや移行支援ツールは、作業の入口としては有効です。しかし、本番App Serviceの移行では、最終的に「ビルドできる」ではなく「本番トラフィックで安全に運用できる」ことを基準にしてください。

移行できないアプリがある場合の考え方

すべての.NET 8アプリを短期間で.NET 10に移行できるとは限りません。古いライブラリ、ベンダー製SDK、業務上の凍結期間、リソース不足などで遅れることもあります。その場合でも、何もしないのではなく、例外管理として扱うべきです。

例外対応で最低限決めること

項目決める内容
例外理由どの依存関係が移行を妨げているのか
暫定期限いつまで.NET 8を使うのか
リスク所有者セキュリティリスクを誰が承認するのか
追加対策WAF、監視強化、アクセス制限、脆弱性管理の方法
最終移行計画.NET 10移行、リプレース、廃止のいずれか

「サポート終了後もApp Serviceで動くかもしれない」ことを延命策にしてはいけません。サポート対象外ランタイムを使い続ける場合、障害時の調査、セキュリティ説明、顧客監査のすべてで説明責任が発生します。

まず着手すべき具体的なアクション

今日から始めるなら、次の順番が現実的です。

  1. Azure Resource GraphまたはAzure CLIでApp Serviceを棚卸しする
  2. net8.0、DOTNETCORE|8.0、aspnet:8.0、sdk:8.0をリポジトリ全体で検索する
  3. 対象アプリに「移行責任者」「移行予定月」「影響度」を付ける
  4. 代表的な1アプリで.NET 10移行ブランチを作り、CIとステージングデプロイを検証する
  5. 共通ライブラリとベースDockerイメージを先に.NET 10対応する
  6. 2026年10月末より前に本番移行を完了する計画にする

Azure App Service / .NETの今回の更新は、緊急障害対応ではなく、計画的な技術負債解消の合図です。.NET 8アプリがあるなら、まず棚卸しを行い、.NET 10 LTSへの移行可否を確認してください。最も避けるべきなのは、2026年11月10日直前になって、アプリ本体、App Service設定、CI/CD、コンテナ、監視のすべてを同時に変更することです。

移行は早く始めるほど、通常の開発サイクルに組み込みやすくなります。まずは1つの代表アプリで.NET 10移行の手順を固め、その手順をテンプレート化して、残りのApp Serviceへ横展開するのが最も安全です。

Azure
DevOps サポート終了 Azure App Service .NET 10 .NET 8

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次