Microsoftは2026年4月8日、ASP.NET Core 2.3のサポートを2027年4月7日に終了すると発表した。以後はセキュリティパッチ、バグ修正、技術サポートを提供しない。アプリケーションがその日を境に停止するわけではないが、運用を続ける条件は大きく変わる。

この告知が分かりにくいのは、.NET Framework自体が終了するわけではないからだ。.NET FrameworkはWindowsのコンポーネントとして引き続きサポートされる。一方で、その上で最後まで支えられてきたASP.NET Core 2.3系パッケージは、独立した期限を迎える。レガシー資産を抱える企業にとっては、「まだ動く」と「もう保守されない」が同時に成立する局面に入ることを意味する。

AD

.NET Frameworkの継続サポートと2.3終了が両立する理由

今回の発表では、.NET Framework上でサポートされてきたASP.NET Core 2.3パッケージは、最新の修正版に限ってサポート対象とされていると説明されている。そして2027年4月7日を過ぎると、利用中の.NET Frameworkのバージョンにかかわらず、この扱いが終わる。対象にはEntity Framework 2.3パッケージも含まれる。

実務で厄介なのは、「.NETはまだサポート中だ」という理解が、そのままアプリケーション全体の安全性を意味しない点にある。OSと.NET Frameworkの保守が続いていても、その上に載るWebスタックの一部が非サポート化すれば、脆弱性対応や監査時の説明は一気に難しくなる。特にインターネット公開系、個人情報や取引情報を扱う業務システム、外部ベンダーの部品を多く抱える構成では、そのずれがそのまま運用リスクになる。

Microsoftは今回の終了を、Support Lifecycle Policyで「Tools」に分類される製品に適用される12カ月の事前通知要件に沿ったものだと位置付けている。手続き上はルール通りである。ただ、利用企業の側から見れば、本番運用を支えてきたコンポーネントが「ツール」という分類で期限を切られることに違和感が残るのも無理はない。

2.3が企業に残り続けた理由

ASP.NET Coreは初期には.NET Frameworkでも動作していたが、ASP.NET Core 3.0以降は.NET Frameworkをターゲットにしなくなった。Microsoftの戦略としては自然な整理であり、以後の重心はクロスプラットフォームの現行.NETに移った。問題は、その切り替えの途中にいた企業にとって、完全移行までの足場が細くなったことである。

ASP.NET Core 2.3は、この文脈でかなり特殊な位置にあった。提供資料では、2.3は2.1系を再度サポート対象として整理し直したもので、2.2系の破壊的変更やサポート切れで行き場を失いかけた利用者に、公的な着地点を用意する意味合いが強かったと説明されている。通常のバージョン前進というより、移行を急ぎ切れない企業向けの延長線だったわけだ。

そのため2.3には、単なる旧版以上の重みがあった。Windows中心の業務システムを抱える企業では、ASP.NETから一足飛びに最新.NETへ移るのが難しい案件が少なくない。周辺ライブラリ、認証方式、IIS前提の構成、古いWindows Server、社内運用手順が絡み合うからだ。2.3はそうした環境で、「今すぐ全面移行は無理だが、完全に見放されたくもない」という現実的な需要を受け止めてきた。

AD

企業が先に向き合うべきは無保守運用の説明責任だ

Microsoftは、サポート終了後もアプリケーション自体は動き続けると明言している。この一文は安心材料に見える半面、判断を遅らせる要因にもなりやすい。止まらない以上、予算化や優先順位付けが後ろに回りやすいからだ。しかし、セキュリティ更新が来ない状態での継続運用は、安定稼働とは別の問題である。

公開サービスであれば、未修正の脆弱性を抱えたまま外部に面することになる。社内向けシステムでも、認証、通信、ログ、周辺パッケージの更新停止が積み重なれば、事故発生時の説明は苦しくなる。サポート契約を結べない、ベンダーに問い合わせても対象外になる、監査部門から改善計画を求められるといった形で、運用負荷はむしろ増えやすい。

しかも問題はASP.NET Core 2.3だけで閉じない。古いアプリケーションは、Webフレームワーク、NuGetパッケージ、設定ファイル、認証基盤、デプロイ手順など、複数の古い前提に支えられていることが多い。ひとつの部品が非サポート化すると、全体の安全性は最も弱い部分に引っ張られる。今回の告知が重いのは、この依存関係の連鎖を企業に再認識させるからである。

移行先は.NET 10でも、作業は単純な更新では終わらない

Microsoftは、現在サポートされる.NETへの移行を推奨し、例として.NET 10のLTSを挙げている。方向性は明快である。Windows専用の枠に残り続けるより、現行の.NETへ寄せた方が、今後のサポート、性能改善、開発体験の面で合理的だからだ。Linuxやコンテナを含む運用選択肢が広がる点も長期的には効いてくる。

ただし、現場の作業は単なるターゲット変更では済まない。一般的な移行手順としては、プロジェクトファイルのSDKスタイル化、NuGet依存の更新、互換性のないライブラリの置き換え、web.config や app.config 由来の設定整理、Windows依存APIの見直し、単体テストと統合テストの再整備が必要になる。古い認証方式や独自ミドルウェア、業務固有のバッチ処理が絡めば、難所はさらに増える。

この文脈で、MicrosoftがGitHub Copilot modernizationのようなAI支援を前面に出しているのは理解しやすい。反復的なコード変換、古いAPIの洗い出し、依存関係の棚卸しには有効だろう。ただし、AIが担えるのは最初の加速までである。業務ルールの妥当性、障害時の振る舞い、監査証跡、性能劣化の有無までは、人間の設計判断と検証を省けない。移行支援は工数圧縮には役立つが、移行の責任そのものを肩代わりするわけではない。

AD

今回の終了が示すMicrosoftのメッセージ

Microsoftは、ASP.NET Core 2.3 on .NET Frameworkの維持が、現行.NETへの投資からリソースを引き離すと説明している。企業として見れば筋の通った判断であり、旧系統を長く抱え込めば、新しいランタイムやツールへの投資は鈍る。今回の終了は、同社が例外的な互換措置よりも、現行プラットフォームへの集中を優先する姿勢をはっきり示した形だ。

一方で、利用企業の現場では、過去に用意された救済策や互換レイヤーが「一時しのぎ」ではなく「当面の前提」として運用に組み込まれがちである。今回の発表は、その前提に明確な終点を与えた。期限が見えたことで計画は立てやすくなったが、猶予があることと移行が軽いことは同じではない。

2027年4月7日までに必要なのは、まずASP.NET Core 2.3を使うシステムの棚卸しである。外部公開系か、社内限定か、代替不能な業務を担うか、周辺パッケージはどこまで古いかを把握しなければ、移行方針も優先順位も決められない。次に必要なのは、コード修正費だけでなく、テスト費と運用切り替え費を含めた現実的な予算化である。レガシー案件では、書き換えそのものより検証の方が重くなりやすい。

今回のニュースは、ASP.NET Core 2.3の終了告知であると同時に、.NET Framework上に残されていた例外措置の寿命が見えたという知らせでもある。.NET Frameworkがまだサポート中であっても、その上のアプリケーション群が将来まで安全に維持できる保証にはならない。Microsoftが支える範囲と、利用企業が自分で背負う範囲の境界が、2027年4月7日という日付でいっそう明確になった。その境界を越える前に動けるかどうかが、Windows中心の旧来資産を抱える企業の次の差になる。

Sources