.NET 10 runtime and ASP.NET Core の rollout で現場が一番変わるのは、新機能そのものよりも更新の運び方です。2026年4月の 10.0.6 は、4月14日の servicing update として .NET Blog で案内され、リリースノートでは SDK、.NET Runtime、ASP.NET Core Runtime、Docker images、Windows Server 向け Hosting Bundle まで同じ更新対象として整理されました。さらに GitHub では 4月20日に dotnet/runtime と dotnet/aspnetcore の v10.0.6 リリースタグが揃って公開されており、Runtime と ASP.NET Core を別々に追うより、ひとつの servicing wave として扱う方が実務に合います。(Microsoft for Developers)
実務の結論を先に言うと、開発端末は SDK、IIS サーバーは Hosting Bundle、Linux/コンテナはベースイメージまたは配布パッケージ、アプリ側は回帰テストを同じ変更票で回すべきです。なお、2026年4月23日現在の .NET 10 の最新 patch は 10.0.7 で、4月21日に ASP.NET Core DataProtection 向けの OOB セキュリティ更新が出ています。つまり、10.0.6 は rollout の考え方を学ぶ好例ですが、今から適用するなら 10.0.7 を基準に設計するのが安全です。(Microsoft)
2026年4月の .NET 10 runtime and ASP.NET Core rollout を日付で整理する
- 2026年4月14日: .NET Blog で April 2026 の servicing update が公開され、10.0.6 の release notes、installers and binaries、container images、Linux packages への導線がまとめて案内されました。(Microsoft for Developers)
- 2026年4月20日: GitHub の dotnet/runtime と dotnet/aspnetcore で v10.0.6 の release tag が公開されました。(GitHub)
- 2026年4月21日: Microsoft は 10.0.7 を OOB セキュリティ更新として公開し、DataProtection の問題に対する早急な更新を案内しました。(Microsoft for Developers)
この並びから分かるのは、.NET 10 runtime and ASP.NET Core の rollout は「ニュースを読む作業」ではなく、月例 servicing wave と OOB 対応の2本立てで運用する作業だということです。.NET の公式ドキュメントでも、servicing updates はほぼ毎月出荷され、システムは公開済み patch に追従し続ける必要があるとされています。(Microsoft)
最初に分けるべきは framework-dependent か self-contained か
ここを曖昧にすると、.NET 10 runtime and ASP.NET Core の rollout はほぼ確実に現場で噛み合いません。公式ドキュメントでは、framework-dependent deployment は実行環境に入っている最新の .NET security patch へ自動的にロールフォワードし、self-contained deployment は最新 patch に自動追従せず、ランタイム更新にはアプリの再リリースが必要だと明記されています。(Microsoft Learn)
実務では、次のように分けると判断しやすくなります。
- framework-dependent: IIS サーバー、共有 VM、ランタイムが事前導入されている社内サーバー。更新の主役はホスト側です。(Microsoft Learn)
- self-contained / ランタイム同梱系: コンテナ、RID 指定 publish、単体配布実行ファイル。更新の主役は成果物そのものです。再 build・再 publish・再配布が必要です。(Microsoft Learn)
この違いを先に棚卸ししておくと、どのチームが何を更新するかがはっきりします。逆に、配布形態を見ずに「とりあえず NuGet を上げる」「とりあえずサーバーの runtime を上げる」と進めると、更新したつもりなのに本番の実体が古いまま、というズレが起きやすくなります。(Microsoft Learn)
シナリオで見る .NET 10 runtime and ASP.NET Core の rollout impact
IIS で社内Webアプリを運用している
Windows Server で ASP.NET Core を IIS 配下に載せているなら、10.0.6 rollout の中心は Hosting Bundle です。10.0.6 のリリースノートでは Hosting Bundle が Windows Server 向けの配布物として明示されており、これは .NET Runtime と IIS support を含む構成です。さらに ASP.NET Core 10.0.6 の changelog には、IIS で Preload Enabled=true のときにシャットダウンがハングする問題の修正が含まれています。PR 説明では、w3wp の停止と再起動がループして、マシンの shutdown が終わらなくなる可能性があるとされています。(GitHub)
現場で変えるべきワークフロー
サイトが起動するかだけを見るテストでは足りません。IIS 環境では、更新手順にアプリプール再起動だけでなくOS の再起動・停止確認も入れるべきです。特に Preload Enabled=true、in-process hosting、定期再起動を運用に組み込んでいる環境では、ステージングで shutdown path まで確認してから本番へ進める方が安全です。修正内容を見る限り、10.0.6 は「動くか」だけでなく「止まれるか」を見る patch です。(GitHub)
失敗しやすいポイント
- 開発端末の SDK だけ更新して、サーバーの Hosting Bundle を後回しにする
- アプリプール recycle だけで合格にして、サーバー再起動を試さない
- IIS の Preload 設定を把握していないまま一括展開する
Linux VM やコンテナで API を運用している
10.0.6 の release notes では .NET Docker images が更新対象として明記され、April 2026 の release feedback issue でも Installers/Binaries、Linux Container Images、Windows Container Images が 10.0.6 向けに揃っていることが示されています。Microsoft 配布の Linux installer も Debian 12、OpenSUSE 15、Rocky 9、Ubuntu 20.04 / 22.04 が同 wave で案内されました。(GitHub)
現場で変えるべきワークフロー
Linux VM 上の framework-dependent アプリなら、配布パッケージ更新が主役です。逆に、コンテナや self-contained なら、ホストを更新しても成果物に同梱された runtime は変わらないので、image rebuild または republish が必須です。つまり、同じ 10.0.6 rollout でも、VM チームとコンテナチームでやることは違います。(Microsoft Learn)
実務では、base image 更新 → build → integration test → canary → 本番 rollout を monthly servicing の標準レーンにしておくと、毎月の patch を無理なく回せます。digest pin を使っているならタグ更新だけでは不十分ですし、self-contained publish を使っているなら dotnet publish の再実行なしに patch は入りません。(GitHub)
Worker や連携バッチも同じ wave に乗せる
10.0.6 は ASP.NET Core だけの話ではありません。.NET 10.0.6 の release notes には、System.Security.Cryptography.Xml の複数の DoS 関連問題と、System.Net.Mail に関する問題が notable changes として並んでいます。メール送信ジョブ、XML 署名・暗号化を扱う連携バッチ、夜間集計 worker も、同じ runtime family の patch 対象です。(GitHub)
ここでの実務上のコツは、.NET 10 runtime and ASP.NET Core の rollout をWeb チームの作業として閉じないことです。社内では Web API と worker service の担当者が分かれていることが多いですが、patch 適用票は分けすぎない方が安全です。runtime patch は横断インフラとして扱い、Web・batch・連携を同じ一覧で管理した方が漏れが減ります。(GitHub)
JSON Patch を使う API は smoke test の作り方が変わる
ASP.NET Core 10.0.6 の changelog と関連 PR を見ると、今回の rollout で一番“現場のテスト設計”に影響するのは JSON Patch まわりです。10.0.6 には、Newtonsoft JsonPatch で application/json が 415 になる回帰、Blazor WASM で package 参照時に build が壊れる問題、さらに /items/0/name のような nested array property traversal が失敗する bug の修正が含まれています。後者は valid な RFC 6902 の path でも JsonPatchException になり、回避策なしと説明されています。(GitHub)
現場で変えるべきワークフロー
PATCH を使う API チームは、monthly servicing の回帰テストに最低でも次を入れるべきです。
application/json-patch+jsonだけでなくapplication/jsonも送る- nested array の path を含む PATCH を通す
- minimal APIs と MVC の両方で受け方を確認する
- Blazor WASM や SPA クライアントの build を合わせて見る
GET/POST の疎通だけで「ASP.NET Core 更新完了」と判断すると、今回のような regression は見落としやすいです。特に admin 画面や業務 API で PATCH を多用するチームほど、10.0.6 rollout はアプリ本体よりテストメニューの更新が重要です。(GitHub)
Blazor Web App を雛形から立ち上げるチームは EF migration を1回入れる
Blazor Web App の Individual authentication テンプレートを使っているなら、10.0.6 は PoC や内製ポータルの初動にも効きます。修正 PR では、テンプレートに同梱される app.db の __EFMigrationsHistory と migration source files の ID が一致しておらず、dotnet ef database update が失敗していたことが説明されています。10.0.6 ではこの app.db を作り直し、回帰テストも追加されました。(GitHub)
これは単なるテンプレートの小修正ではありません。現場では「PoC 用だから」「社内ツールだから」とテンプレート直後の確認を省きがちですが、実際には最初の 30 分でつまずくと、そのまま古い workaround を社内テンプレートへ焼き込んでしまいがちです。Blazor を雛形から使うチームは、starter repo の CI に dotnet ef database update を1回流す だけでも再発防止効果が高いです。(GitHub)
2026-04-23時点の実務判断は「10.0.6を理解し、10.0.7を入れる」
.NET 10 は LTS で、公式 support policy では 2028年11月14日まで Active とされています。ただし同じ policy で、システムは released patch updates に追従し続ける必要があるとも明記されています。さらに .NET の support / releases ドキュメントでは、servicing updates はほぼ毎月出荷され、support は次の servicing update が出るまでと説明されています。長期サポートだから更新を遅らせてよい、という運用にはなりません。(Microsoft)
特に今は、10.0.6 をそのまま新規基準にするのはおすすめしにくい局面です。4月21日に公開された advisory では、Microsoft.AspNetCore.DataProtection 10.0.0〜10.0.6 の NuGet packages に問題があり、認証 cookie の forgery や protected payload の decrypt につながり得ると説明されています。patched version は 10.0.7 です。(GitHub)
さらに重要なのは、誰が影響を受けるかが一律ではないことです。公式 advisory では、非 Windows の net10.0 アプリで Microsoft.AspNetCore.DataProtection 10.0.6 の NuGet 実体を実行時に読み込む構成や、net462 / netstandard2.0 asset を使う構成が影響対象として挙げられています。一方で、framework-dependent の net10.0 アプリが Windows 上で shared framework のコピーを使う構成は not affected とされています。つまり、「Windows だから大丈夫」でも「ASP.NET Core だから危険」でもなく、実際にどの binary が load されるかで判断が変わります。(GitHub)
もし影響しうる構成なら、やるべきことは patch 適用だけでは終わりません。公式 advisory は、10.0.7 以上への更新に加え、必要に応じて DataProtection key ring の rotation、長寿命トークンや password reset link の棚卸し、保護 payload を受ける endpoint のログ確認まで案内しています。認証、antiforgery、OIDC state、TempData に関わるアプリでは、運用チームとアプリチームが別々に動くと抜けやすいので、ここは共同で扱った方が安全です。(GitHub)
現場でそのまま使える rollout checklist
役割を分けるなら、Power users は SDK とテンプレートの検証、admins は runtime / Hosting Bundle / container image の展開、solution owners は monthly と OOB の承認ルールを持つ形が回しやすいです。10.0.6 のような coordinated wave と、10.0.7 のような OOB の両方がある以上、承認フローも2段階に分けておくのが現実的です。(Microsoft Learn)
- 配布形態を棚卸しする
framework-dependent、self-contained、container、IIS Hosting Bundle 依存のどれかを、アプリごとに分けます。ここが曖昧だと、誰が何を更新するか決まりません。(Microsoft Learn) - 目標 patch version を決める
2026年4月23日時点なら 10.0.7 が基準です。10.0.7 の release notes では SDK 10.0.107 と 10.0.203 が 10.0.7 runtimes を含むとされ、10.0.6 では 10.0.106 と 10.0.202 が対応していました。Windows の開発端末は Visual Studio 18.4 推奨です。(GitHub) - ホスト更新と成果物更新を分けて実行する
IIS / framework-dependent は runtime や Hosting Bundle の更新、コンテナ / self-contained は rebuild・republish・redeploy を行います。両者を同じ手順で扱わないことが大切です。(GitHub) - 最低限の回帰テストを固定化する
起動確認だけでなく、IIS の停止・再起動、認証 cookie / antiforgery / OIDC state、PATCH endpoint、Blazor WASM build、dotnet ef database updateを標準メニューにします。今回の 10.0.6 は、まさにこの項目で差が出る patch です。(GitHub) - 適用後にバージョンを見える化する
dotnet --info、dotnet --version、dotnet --list-runtimesを build 端末とサーバーで記録しておくと、後から「SDK は更新済みだが shared framework は古い」といったズレを潰しやすくなります。10.0.7 の OOB 案内でもdotnet --infoによる確認が推奨されています。(Microsoft for Developers)
dotnet --info
dotnet --version
dotnet --list-runtimes- OOB 用の短い承認レーンを持つ
10.0.7 のように、月例 patch の直後にセキュリティ更新が出ることがあります。monthly wave を本番投入する仕組みと、OOB を同日または短期間で流す仕組みは、分けて持っておく方が実務的です。(Microsoft for Developers)
.NET 10 runtime and ASP.NET Core の rollout をうまく回すコツは、patch を「開発者の作業」「サーバー担当の作業」「セキュリティ担当の作業」に分断しすぎないことです。10.0.6 が教えてくれるのは、SDK、runtime、ASP.NET Core、IIS、コンテナ、テストをひとつの更新単位として扱うべきだということです。次にやるべきことは明確で、まず配布形態を棚卸しし、今なら 10.0.7 を基準に揃え、IIS 停止確認・PATCH テスト・認証まわり・EF migration を固定化することです。そこまでできれば、monthly servicing も OOB も「臨時対応」ではなく、定常運用に変えられます。(Microsoft)
コメント