2025年12月のWindowsセキュリティ更新で、Message Queuing（メッセージ キューイング。以下MSMQ）が突然死んだ、IIS（Internet Information Services／Webサーバー）が「リソース不足」と言い出した、キューが動かない……そんな報告が一気に増えています。とくに企業システムだと「裏側の基盤」になってることが多く、気づいた時には業務が詰まるタイプの不具合です。この記事は、Windows 10 22H2／Windows Server 2019／Windows Server 2016で、MSMQやIISを使っている人向けに、何が起きていて、どこを見れば切り分けできるか、そして現実的な回避策（ただし副作用あり）までまとめます。 (bleepingcomputer.com)
- 何が起きてる？症状のパターンがやたら広い
- 発生日時と対象バージョン（ビルド番号／KB）
- 原因は何？「セキュリティ強化」が権限を変えた
- 公式の対応状況：修正は「調査中」、回避策は実質2択
- いますぐできる切り分け（ログと現象をつなぐ）
- 回避策：KBアンインストール手順（まず復旧したい人向け）
- 「権限を足して凌ぐ」はアリ？ナシ？コメント欄で揉めがちな話
- みんなの報告掲示板：あなたの環境、当てはまる？
- 今後どうなる？“修正パッチ待ち”の間にやるべきこと
何が起きてる？症状のパターンがやたら広い
見た目は「空き容量不足」「メモリ不足」っぽいのに、実はMSMQの書き込み権限まわりでコケているのが今回のポイントです。 (Microsoft Learn)
現場で出ている症状は、ひとことで言うと「MSMQが送れない・作れない・動かない」。具体的には、MSMQのキューがinactive（非アクティブ）になったり、IISサイトが “Insufficient resources to perform operation”（操作を実行するためのリソース不足）で落ちたり、アプリがキューへ書き込めなくなったりします。さらに紛らわしいのが、「There is insufficient disk space or memory（ディスク領域またはメモリ不足）」みたいなログが出るのに、実際は余裕があるケースがあること。 (Microsoft Learn)
エラーの例としては、メッセージファイル作成時に “The message file 'C:\Windows\System32\MSMQ\storage*.mq' cannot be created”（メッセージファイルを作成できない） が出る、という報告も公式に載っています。 (Microsoft Learn)
発生日時と対象バージョン（ビルド番号／KB）
2025年12月9日（Patch Tuesday）配信の更新プログラム適用後から発生し、Microsoftが既知の問題（Known issue／既知の不具合）として確認済みです。 (Microsoft Learn)
時系列はこうです。2025年12月9日に各OS向けの累積更新が配信され、その後12月12日にRelease Health（リリース正常性）側で問題が「Confirmed（確認済み）」として掲載されています。メディア側（BleepingComputer）が大きく報じたのは12月15日です。 (bleepingcomputer.com)
影響が明記されている主な対象は次のとおりです（括弧内はOS Build／ビルド番号とKB）。
Windows 10 22H2：OS Build 19045.6691、KB5071546
Windows Server 2019：OS Build 17763.8146、KB5071544
Windows Server 2016：OS Build 14393.8688、KB5071543 (Microsoft Learn)
なおWindows 10は2025年10月14日にサポート終了（End of support）なので、12月の更新が来ている環境はESU（Extended Security Updates／拡張セキュリティ更新）や延命枠の可能性が高いです。 (マイクロソフトサポート)
原因は何？「セキュリティ強化」が権限を変えた
MSMQのsecurity model（セキュリティモデル）変更で、C:\Windows\System32\MSMQ\storage のNTFS permissions（NTFSアクセス許可）が変わり、通常のサービスアカウントが書けなくなった——これが公式説明です。 (Microsoft Learn)
今回のややこしさは、「脆弱性対策っぽい変更」なのに、実運用だとIIS_IUSRS（IISの実行グループ）やLocalService／NetworkServiceなど、よくある構成が巻き込まれる点です。Microsoft Q&Aでも「更新でACL（アクセス制御）が変わって、ロールバックすると直る」といった報告が複数見えます。 (Microsoft Learn)
そして皮肉なのが、管理者（Administrator）権限で動かしてる環境だと影響しにくい、ということ。逆に言うと「ちゃんと権限分離してる環境ほど死ぬ」構図になりがちで、現場はしんどいです…たぶん。 (bleepingcomputer.com)
公式の対応状況：修正は「調査中」、回避策は実質2択
Microsoftの現時点のスタンスは「Investigating（調査中）」で、恒久修正の配布時期はまだ明言されていません。 (Microsoft Learn)
じゃあ運用側は何をするか。現実的には「(A)該当KBをアンインストール（uninstall／削除）」「(B)MSMQが書けるように権限を付与する」の2択に寄ります。
(A)は即効性が高い一方、セキュリティ更新を戻すのでリスクは残ります。とはいえ「業務が止まる」ほうが重大なら、まず復旧優先で戻して、ネットワーク境界やEDRで守りを厚くする判断もあり得ます。 (bleepingcomputer.com)
(B)は「C:\Windows\System32\MSMQ\storage」へ書き込み権限を足す方向ですが、環境によっては権限が戻されたり、セキュリティ的に嫌われたりしがち。実際、Microsoft Q&Aでは「手で変えても永続しないっぽい」といった話が出ています。 (Microsoft Learn)
いますぐできる切り分け（ログと現象をつなぐ）
“Insufficient resources…”が出たら、ディスクやメモリより先に「MSMQのstorageフォルダへ誰が書けるか」を疑うのが近道です。 (Microsoft Learn)
まず「いつから？」を合わせます。2025年12月9日以降にKB5071546／KB5071544／KB5071543のどれかを入れたか。次に症状の一致。IISサイトが落ちる、キューがinactive、System.Messaging（.NETのメッセージング）系の例外で送信が失敗する、メッセージファイル作成エラーが出る。この並びなら今回の既知の問題とかなり合致します。 (Microsoft Learn)
クラスタ（clustered MSMQ／クラスタ構成のMSMQ）で負荷がかかった時に顕在化する、とも明記されているので、単体だと「たまにしか出ない」ように見える環境もありそうです。 (Microsoft Learn)
回避策：KBアンインストール手順（まず復旧したい人向け）
最短で業務を戻したいなら、該当KBを削除して再起動、が一番わかりやすい復旧ルートです。 (bleepingcomputer.com)
(1) 対象の更新プログラム番号を確認します（KB5071546／KB5071544／KB5071543）。 (Microsoft Learn)
(2) Windowsの「設定」→「Windows Update」→「更新の履歴」→「更新プログラムをアンインストール」を開きます。
(3) 該当KBを選んで「アンインストール」を実行します。
(4) 再起動します。再起動しないと直ったように見えても裏で残ります。
(5) 復旧確認として、IISのサイト応答、MSMQ送受信、イベントログのエラー消失を一気に見ます。
注意点として、アンインストール後は自動で再適用されないよう、一時的に更新の一時停止（pause／停止）や展開制御を入れないと、同じ地雷を踏みます。ここ、地味に多いです。 (Microsoft Learn)
「権限を足して凌ぐ」はアリ？ナシ？コメント欄で揉めがちな話
権限付与で動いても、それが“正しい復旧”かどうかは別問題で、セキュリティと運用の綱引きになります。 (Microsoft Learn)
「サービスをLocalSystemに上げれば動いた」「storageに書けるようにACLを追加したら直った」という報告は出やすい。でも、それって“権限分離を崩して復旧した”だけ、になりがちです。しかも更新でACLが再生成される挙動があるなら、恒久対応としては不安定。ここは環境の要件次第で、正解が割れます。 (Microsoft Learn)
あなたの現場だとどっち派ですか？「セキュリティ優先でロールバックは避けたい」派と、「業務優先、まず戻す」派。どっちもわかるんだよなあ、ってなるやつ。
みんなの報告掲示板：あなたの環境、当てはまる？
同じKBでも「どのアカウントでMSMQを使ってるか」で症状が変わるので、環境情報の共有がいちばん価値あります。 (Microsoft Learn)
コメント欄に貼る用テンプレ置いときます。コピペでOKです、don’t worry（心配しないで）。
(1) OS：Windows 10 22H2／Server 2019／Server 2016（エディションも）
(2) ビルド番号：例 19045.6691
(3) 該当KB：KB5071546／KB5071544／KB5071543
(4) MSMQの使い方：IIS経由／Windowsサービス／クラスタ有無（under load＝高負荷時に出る？）
(5) エラーメッセージ： “Insufficient resources to perform operation”／storage*.mq cannot be created 等
(6) 取った対応：アンインストール／権限付与／サービスアカウント変更
(7) 結果：完全復旧／一時復旧／再発／まだ調査中
ちなみに海外の管理者コミュニティでも同時期に報告がまとまっていて、「パッチ当てたらMSMQが死んだ」系の流れは確認できます。自分だけじゃないのは救いだけど、早く直して…ってなる。 (Reddit)
今後どうなる？“修正パッチ待ち”の間にやるべきこと
恒久修正が出るまでは「更新の展開制御」と「影響範囲の見える化」を同時に回すのが現実的です。 (Microsoft Learn)
まずは影響のあるサーバー／アプリを洗い出して、MSMQ依存の処理がどこにあるか（夜間バッチだけなのか、APIの非同期処理なのか）を言語化しておくと、対処の優先順位がつけやすいです。次に、該当KBを本番へ広げるのを止める。すでに入ってるなら、ロールバック対象を段階化する。ここまでやると、コメント欄でよくある「うちは平気だった」の理由も見えます。たまたま管理者で動いてただけ、みたいな。 (bleepingcomputer.com)
最後に、公式の更新（Release HealthやKBの既知の問題欄）が動いたら、それが実質のゴールです。直った報告が出たら、ここも追記していきます……と言いたいところですが、まずはあなたの現場の“生ログ”が知りたい。再発条件、あります？ちょっとしたヒントでも助かります。 (Microsoft Learn)
