.NET 10 runtime and ASP.NET Core の 10.0.6 servicing wave が来たとき、管理者が最初にやるべきことは明確です。自分の環境がフレームワーク依存か自己完結か、IIS/ANCM を使うか、ビルドが SDK 固定かを先に切り分け、そのうえで SDK、runtime、ASP.NET Core runtime、Hosting Bundle、container image のどれを更新するか決めます。.NET 10.0.6 の公式 release notes は 2026-04-14 付で、SDK 10.0.202 と 10.0.106、runtime、ASP.NET Core runtime、Hosting Bundle、Docker images の更新が案内されています。さらに runtime と ASP.NET Core の GitHub release tag は 2026-04-20 に公開されました。(GitHub)
ただし、2026-04-23 時点の実運用では 10.0.6 だけを見て終わりにしてはいけません。.NET 10 の最新 patch は 10.0.7 で、4月21日に ASP.NET Core DataProtection の問題へ対応する OOB update が公開されています。この記事は 10.0.6 の coordinated servicing wave を前提に、導入・設定・周知の管理チェックリストを整理しつつ、いま現場で必要な 10.0.7 への再判断ポイントまで含めてまとめます。(GitHub)
すぐ使える導入・設定・周知チェックリスト
まずはここだけ押さえれば、発表直後の初動を外しにくくなります。根拠は .NET 10.0.6 release notes、April 2026 update の status issue、Hosting Bundle/ANCM の公式ドキュメント、global.json の仕様をベースに整理しています。(GitHub)
| 領域 | すぐ確認する項目 | 完了の目安 |
|---|---|---|
| 発表確認 | 10.0.6 wave の対象が SDK / runtime / ASP.NET Core runtime / Hosting Bundle / container / Linux packages のどれか整理する | 自チームで使う配布チャネルが一覧化されている |
| 配置モデル | FDD / SCD / container / IIS を資産台帳で分ける | 各アプリに更新方式が紐付いている |
| ビルド | global.json、agent image、Visual Studio 固定を確認する | 10.0.202 / 10.0.106 に追随できるか判断済み |
| Windows / IIS | Hosting Bundle の過去オプション、x86 必要性、IIS 再起動要否、ANCM 版数を確認する | canary 1台で検証済み |
| 回帰試験 | 起動、認証、app pool recycle、JSON Patch、Blazor 初期表示を試す | 5〜10分で回せる smoke test がある |
| 周知 | 開発、運用、ヘルプデスク、CSIRT 向け連絡文を用意する | 影響範囲と失敗時対応が共有済み |
| 追加判断 | DataProtection を使うなら 10.0.7 前提で見直す | key ring / token 対応まで含めて判断済み |
.NET 10.0.6 servicing wave で管理者が把握すべき事実
.NET 10 は LTS で、2028年11月14日までサポートされます。monthly servicing wave を後回しにしすぎると、セキュリティ修正・非セキュリティ修正の両方で差分が蓄積しやすくなります。しかも 2026-04-23 時点の latest patch はすでに 10.0.7 です。10.0.6 は「4月の基準パッチ」、10.0.7 は「その直後の追加是正」と理解しておくと判断しやすいです。(GitHub)
日付が少し分かりにくいので、時系列だけ整理すると次の通りです。
- 2026-04-14: .NET 10.0.6 release notes 公開。SDK 10.0.202 / 10.0.106、runtime、ASP.NET Core runtime、Hosting Bundle、Docker images が更新対象として並びます。(GitHub)
- 2026-04-20:
dotnet/runtimeとdotnet/aspnetcoreの GitHub release tag が公開され、component 単位でも 10.0.6 の差分確認がしやすくなりました。(GitHub) - 2026-04-21: .NET 10.0.7 OOB security update が公開され、DataProtection 利用環境は追加対応が必要になりました。(Microsoft for Developers)
ここで重要なのは、repo tag だけを監視していると初動が遅れることです。4月分は release notes / monthly update 側が 4月14日、runtime / aspnetcore の component tag 側が 4月20日でした。発表直後に展開判断したい管理者は、dotnet/core の release notes と status issue を一次情報、component repo の release tag を二次確認として運用した方が安定します。(GitHub)
配布チャネルの同期度にも差があります。April 2026 update issue では、Installers/Binaries、Linux / Windows の container images、Debian 12、OpenSUSE 15、Rocky 9、Ubuntu 20.04 / 22.04 の Linux installers は完了マークでしたが、Winget Packages の行は空欄でした。「Patch Tuesday 当日に全部の配布チャネルが同時に揃う」とは限らないため、社内標準が winget や特定 distro package に偏っている場合は、公開確認を rollout 条件に含めるべきです。(GitHub)
10.0.6 自体は security / non-security fixes を含み、release notes では System.Security.Cryptography.Xml に関する DoS 系 3件と System.Net.Mail の spoofing 1件が notable changes として挙がっています。単なる保守パッチではなく、運用側が計画的に当てにいくべき更新です。(GitHub)
ASP.NET Core 側の 10.0.6 release tag には、IIS での shutdown hang 修正、JsonPatchDocument 関連修正、Blazor の metadata / migration 修正など、運用テストで拾いたい項目が見えています。IIS hosted app、JSON Patch を使う API、Blazor ベースの UI を持つサービスは、generic なヘルスチェックだけで終わらせず、機能別の smoke test を足した方が安全です。(GitHub)
発表直後に切り分ける3つの観点
最初に見るべきなのは、配置モデル、ホスト方式、SDK 固定の有無です。ここを曖昧にしたまま「とりあえず 10.0.6 を入れる」と進めると、Build は更新されたのに本番 host が古い、または runtime は上がったのに self-contained app が古いまま、というズレが起きます。Windows の framework-dependent deployment は Microsoft Update の恩恵を受けやすい一方、self-contained deployment は再ビルド・再配布しない限り変わりません。さらに global.json があると、ホストに新しい SDK が入っていても build が古い SDK のまま残ることがあります。(Microsoft)
| 観点 | 管理者が見る場所 | 最優先の判断 |
|---|---|---|
| 配置モデル | csproj、publish profile、release pipeline | FDD は host patch、SCD は再 publish、container は base image rebuild が必要 |
| ホスト方式 | IIS/ANCM、Kestrel+reverse proxy、App Service | Hosting Bundle/ANCM の要否と restart 方法を決める |
| SDK 固定 | global.json、build agent image、Visual Studio | 10.0.202 / 10.0.106 へ進めるか、pin が邪魔していないか確認する |
Build 側では、SDK だけ入れれば matching runtime も入るので、build agent に runtime と ASP.NET Core runtime を別々に追加する必要はありません。一方、実行 host や IIS server は deployment model に応じて runtime / ASP.NET Core runtime / Hosting Bundle を分けて見る必要があります。Windows 開発端末や self-hosted build machine を使う組織は、release notes が最新 Visual Studio 18.4 を推奨している点も確認しておくと、SDK だけ先に上げて IDE 側で差分が出る事故を防ぎやすくなります。(GitHub)
導入前の実務チェック
配布チャネルと version 確認
現場では「何をどこまで上げるか」を asset 単位で分けて確認します。build agent は SDK、run-only host は runtime / ASP.NET Core runtime、IIS host は Hosting Bundle、container workload は base image という切り方にすると漏れにくいです。特に 10.0.6 release notes は SDK 10.0.202 と 10.0.106 の両 feature band を明示しているため、build farm が複数 band をまたいでいる組織は片方だけ更新して終わりにしないことが大切です。(GitHub)
導入後の実機確認は、少なくとも次のコマンドを押さえておくと早いです。.NET 10 以降は --arch が使えるので、x86 / x64 を分けて確認できます。IIS で 32-bit app pool を使う可能性がある環境では、この差が実務上かなり重要です。(Microsoft Learn)
dotnet --version
dotnet --list-sdks
dotnet --list-runtimes
dotnet --list-runtimes --arch x64
dotnet --list-runtimes --arch x86dotnet --version は実際に使われる SDK version を返すため、global.json の影響確認にも向いています。dotnet --list-runtimes は host に入っている shared framework の棚卸しに使えます。x86 の dotnet は x86 runtime だけ、x64 の dotnet は x64 runtime だけを見るので、bitness を取り違えないようにしてください。(Microsoft Learn)
IIS / Hosting Bundle / ANCM の確認
IIS host では、Hosting Bundle が runtime、ASP.NET Core runtime、ASP.NET Core Module をまとめて扱う中心になります。しかも ANCM は in-support release 間で forward / backward compatible とされているため、mixed-version の IIS server でも運用しやすい一方、どの component を opt-out して入れたかを忘れるとトラブルになります。(Microsoft Learn)
| 項目 | 確認すること | 失敗しやすい点 |
|---|---|---|
| インストール順 | IIS のあとに Hosting Bundle を入れたか。逆なら repair 済みか | Hosting Bundle を先に入れて IIS 後に修復し忘れる |
| 過去の opt-out | OPT_NO_ANCM / OPT_NO_RUNTIME / OPT_NO_SHAREDFX / OPT_NO_X86 を使っていないか | 以前の silent install の意図を誰も覚えていない |
| x86 | 32-bit app pool の有無 | OPT_NO_X86=1 で x86 runtime が入らず一部サイトだけ落ちる |
| 再起動 | IIS 再起動手順を rollout に含める | インストール成功だけ見て worker process を再起動しない |
| 版数確認 | aspnetcorev2.dll / aspnetcore.dll の File version を確認する | MSI 成功で満足し、ANCM 実体を見ない |
| 共有構成 | IIS Shared Configuration を使っていないか | installer が access denied で失敗する |
この表の背景にある公式ドキュメント上の注意点は重いです。Hosting Bundle を IIS より先に入れた場合は repair が必要で、installer の opt-out 値は 同じ Major.Minor band では registry に保存され、後続 install にも引き継がれます。また OPT_NO_X86=1 は「将来も 32-bit app を載せない」と確信できるときだけ使う前提です。IIS Shared Configuration を使っている場合は、shared config を一時的に無効化して installer を実行し、更新済み applicationHost.config を共有先へ戻す必要があります。(Microsoft Learn)
Hosting Bundle 適用後は、IIS を明示的に再起動する運用手順を入れておくと安全です。Microsoft Learn でも、WAS と W3SVC の再起動が必要になる場合があると案内しています。(Microsoft Learn)
net stop was /y
net start w3svcANCM の版数確認は、%PROGRAMFILES%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll や %windir%\System32\inetsrv\aspnetcore.dll のプロパティを見れば足ります。Hosting Bundle の installer log はユーザープロファイル配下の temp に残るので、silent install の成否確認も含めて canary で一度確認しておくと、本番トラブルの切り分けが早くなります。古い Windows Server では Visual C++ Redistributable が不足して失敗することもあるため、旧 OS をまだ含む環境はここも忘れないでください。(Microsoft Learn)
web.config と環境変数の差分
IIS hosted app では、published な web.config の既定と現行 web.config の差分を比較した方が確実です。公式サンプルでは AspNetCoreModuleV2、hostingModel="inprocess"、stdoutLogEnabled="false" が基本で、さらに <location path="."> と inheritInChildApplications="false" を使って child app への継承を止めています。1サイト配下に複数 app をぶら下げる構成では、この継承制御が抜けていると想定外の影響が出やすいです。(Microsoft Learn)
| 差分ポイント | 先に見る理由 |
|---|---|
hostingModel | in-process / out-of-process の動きが変わる |
stdoutLogEnabled / stdoutLogFile | 起動確認には便利だが、常時有効は危険 |
environmentVariables | 一時的な Development 指定や独自変数の混入を見つけやすい |
inheritInChildApplications | サブアプリに設定が伝播していないか確認できる |
stdout ログは便利ですが、起動トラブルの調査用に限定すべきです。公式 docs でも、log rotation は host 側の責任であり、一般的なアプリ logging 用ではないと案内しています。さらに web.config の環境変数は system-level の同名変数と競合すると app 起動に失敗することがあり、ASPNETCORE_ENVIRONMENT=Development は internet に晒された server では使うべきではありません。調査で一時的に有効化したら、検証後に必ず戻してください。(Microsoft Learn)
Build / CI の SDK pin
Build 系では global.json の見落としが典型的なハマりどころです。global.json は 完全な SDK version を要求し、最初に見つかったファイルが使われます。しかも rollForward を書かない場合の既定は patch で、.NET 10 SDK からは paths を使って repo-local SDK を参照できます。つまり、machine に 10.0.202 を入れても、repo 側の global.json や custom path のせいで build だけ古い SDK のまま残ることがあります。(Microsoft Learn)
| 確認点 | 見る場所 | 判断基準 |
|---|---|---|
| exact pin | global.json の sdk.version | 10.0.100 など古い固定が残っていないか |
| roll forward | global.json の rollForward | patch だけでよいか、latestFeature が必要か |
| repo-local SDK | global.json の paths | machine update が効かない構成になっていないか |
| build image | agent template / container image | SDK 10.0.202 または 10.0.106 まで上がっているか |
CI では「サーバーに新しい SDK を入れたから build も新しくなるはず」という思い込みが危険です。特に monorepo と self-hosted runner の組み合わせでは、カレントディレクトリから上へ辿って最初に見つかった global.json が効くため、job の working directory が変わるだけで使用 SDK が変わることがあります。(Microsoft Learn)
推奨する展開順序
10.0.6 wave の展開は、build / host / app を同時に触るより、順序を分けた方が安全です。理由は単純で、framework-dependent、self-contained、container、IIS がそれぞれ別の failure mode を持つからです。(Microsoft)
| 順番 | 実施内容 | この順が安全な理由 |
|---|---|---|
| 1 | build agent / CI image / global.json を先に確認する | build できない状態で host だけ先に上げる事故を防げる |
| 2 | 非本番の host を hosting pattern ごとに 1台ずつ更新する | IIS / Linux package / container の差を分けて見られる |
| 3 | 最小 smoke test を実行する | 起動、認証、JSON Patch、Blazor、IIS recycle の異常を早く見つけられる |
| 4 | 低クリティカル本番へ canary 展開する | rollout blast radius を小さくできる |
| 5 | ring 方式で本番拡大する | channel / config 差分を見ながら進められる |
| 6 | 24時間程度は auth / startup / recycle 系の異常を監視する | patch 直後に出やすい session・起動・終了処理の問題を拾いやすい |
smoke test は generic なヘルスチェックだけでは不足しがちです。ASP.NET Core 10.0.6 tag に IIS shutdown hang 修正、JsonPatchDocument 修正、Blazor 関連修正がある以上、最低でも app pool recycle、app_offline.htm を使う停止手順、PATCH endpoint、Blazor の初回表示と遷移、認証 cookie / antiforgery の確認までは入れた方がよいです。ANCM は app_offline.htm 検出時の graceful shutdown や shutdownTimeLimit も扱うため、IIS 側の停止確認は特に省略しない方が安全です。(GitHub)
周知で最低限伝えること
技術的に正しい rollout でも、周知が弱いと現場は混乱します。少なくとも、次の4方向に内容を分けて伝えると運用しやすくなります。
- 開発者向け: 使用 SDK、global.json、container base image、再 build 要否
- 運用担当向け: Hosting Bundle / runtime / image のどれを上げるか、再起動要否、canary 対象
- ヘルプデスク / CSIRT 向け: 予想される問い合わせ内容、異常ログの見方、認証系の監視強化
- サービスオーナー向け: 予定時間、想定影響、失敗時の戻し方
そのまま使いやすい文面にすると、たとえば次の形です。
本日、.NET 10 runtime / ASP.NET Core の月例 servicing update を適用します。
対象は build agent、IIS host、container base image です。
先行 canary 後に段階展開し、起動・認証・IIS recycle・主要 API を確認します。
認証まわりに異常が出た場合は session / antiforgery / token 関連を優先確認してください。
DataProtection 利用サービスは 10.0.7 まで含めて判断します。
2026-04-23時点の追補: DataProtection を使うなら 10.0.7 まで見る
ここは別枠で見た方が安全です。Microsoft は 4月21日に .NET 10.0.7 OOB update を公開し、Microsoft.AspNetCore.DataProtection 10.0.0〜10.0.6 に入り込んだ問題に対応しました。きっかけは 10.0.6 適用後の decryption failure 報告で、調査の結果、権限昇格につながる vulnerability も確認されたと説明されています。DataProtection を使うサービスは、10.0.6 の rollout checklist をそのまま 10.0.7 へ引き上げて再判定すべきです。(Microsoft for Developers)
| 条件 | 影響の見方 | 追加対応 |
|---|---|---|
Microsoft.AspNetCore.DataProtection 10.0.0〜10.0.6 を direct / transitive に参照し、実際にその NuGet binary が runtime で読み込まれる | 影響あり得る | 10.0.7 以上へ更新して再配布する |
非 Windows で動く net10.0 app、または net462 / netstandard2.0 asset を消費するケース | 要注意 | key ring と token 発行履歴まで見る |
Windows の framework-dependent net10.0 app で、installed shared framework version が PackageReference 以上 | この特定問題は影響対象外として案内されている | ただし latest patch 追随は継続する |
| 8.0.x / 9.0.x の DataProtection package | この regression は backport されていない | 通常の patch 管理を継続する |
特に重要なのは、更新して終わりではないことです。Microsoft の advisory では、影響がある環境は 10.0.7 以上へ上げて再 deploy したうえで、internet-exposed endpoint を持っていた期間があるなら DataProtection key ring を rotate するよう案内しています。key ring を全 revoke すると、全ユーザーの再 sign-in や antiforgery token の再発行が起き得ます。さらに、脆弱な期間に発行された refresh token、API key、password reset link などの長寿命 artifact は key rotation 後も生き残るため、アプリ層での無効化・再発行が必要です。(GitHub)
ログ確認も忘れないでください。advisory では、auth cookie、antiforgery token、state parameter など protected payload を受ける endpoint に対して、通常よりはるかに多いリクエストが継続していたかを見るよう推奨しています。4月中に 10.0.6 を internet-facing な形で運用していたサービスは、単なる version 確認ではなく、アクセスログ・セキュリティログ・token 発行履歴まで見る運用に切り替えた方が安全です。(GitHub)
最後に実行すること
迷ったら、今日は次の順で動けば十分です。資産を FDD / SCD / container / IIS で分ける → build pin と Hosting Bundle opt-out を確認する → canary で起動・認証・IIS recycle・JSON Patch / Blazor を試す → DataProtection が絡むなら 10.0.6 で止めず 10.0.7 と key ring / token 対応まで決める。 これで「導入したのに効いていない」「効いたが一部だけ落ちた」「更新後の認証事故を見逃した」という典型的な失敗をかなり減らせます。(GitHub)
コメント