2025年12月のWindowsセキュリティ更新（いわゆるPatch Tuesday（定例更新日））を入れた直後から、業務システムで「メッセージ キュー（Message Queuing／MSMQ）」が急に動かなくなる報告が増えています。しかも厄介なのが、ログには「ディスク容量やメモリ不足っぽい」文言が出るのに、実際は空きもRAMも余ってる……という“ミスリード型”な点。
対象は、IIS（Webサーバー）配下のアプリや、Windows Server上でMSMQを使っている企業環境が中心です。個人PCはMSMQを有効化していないことが多いので、体感する人は限られます。でも、刺さる人にはガチで刺さるやつ。今朝からキューが止まって、バッチも止まって、社内がザワつく、みたいな。
- 何が起きている？いちばん多い症状とメッセージ
- 影響する更新プログラム：KB番号とビルド
- 原因：ディスク不足じゃなく、NTFS権限の変更が本体
- 公式対応状況：Known issueとして認め、調査中
- まず切り分け：それ“今回のやつ”か見分けるコツ
- 回避策：現場で多い3ルート（※安全性の話も）
- なぜこんな壊れ方？ちょい考察（責めたい気持ちは置いとく）
- みんなの報告まとめ：あなたの環境はどれに近い？
何が起きている？いちばん多い症状とメッセージ
「リソース不足に見えるのに、実態はMSMQが書き込み不能で詰まっている」パターンが目立ちます。 (マイクロソフトサポート)
具体的には、MSMQのキューが非アクティブになったり、アプリがキューへ書き込めなくなったり、IISサイトが “Insufficient resources to perform operation（操作を実行するためのリソースが不足しています）” で落ちる、といった形で表面化します。(マイクロソフトサポート)
さらに「The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created（メッセージファイルを作成できない）」が出る例もあり、これがヒントになります。(マイクロソフトサポート)
そして問題の“誤解を招くログ”が「There is insufficient disk space or memory（ディスク領域またはメモリが不足しています）」系。ここで本気で増設を考えた人、たぶんいる。いや、わかる。(マイクロソフトサポート)
エラーコードは環境で揺れますが、.NET経由だと System.Messaging.MessageQueueException と一緒に 0x80004005 が見えることがあります（E_FAIL系）。(docs.particular.net)
“don’t 信じすぎて”ログだけ追うと、沼ります。
影響する更新プログラム：KB番号とビルド
今回の話は「2025年12月9日公開」の累積更新（LCU）を入れた環境で起きやすいです。 (マイクロソフトサポート)
いま確認されている代表例はこのあたりです。
Windows 10 22H2 系：KB5071546（OS Build 19045.6691／19044.6691）(マイクロソフトサポート)
Windows Server 2019／Win10 LTSC 2019 系：KB5071544（OS Build 17763.8146）(マイクロソフトサポート)
Windows Server 2016／Win10 LTSB 2016 系：KB5071543（OS Build 14393.8688）(マイクロソフトサポート)
Techzineも、これらのKB適用後にMSMQ関連の障害が出ているとして注意喚起しています。(Techzine Global)
原因：ディスク不足じゃなく、NTFS権限の変更が本体
原因は「MSMQのセキュリティモデル変更」と「C:\Windows\System32\MSMQ\storage のNTFS権限（permissions）が変わったこと」です。 (マイクロソフトサポート)
Microsoftの説明はかなりストレートで、MSMQユーザーが storage フォルダーへの書き込み権限を必要とするようになった一方、そこは通常“管理者に制限される”ので、結果としてMSMQ API経由の送信が失敗し、リソース系エラーとして見えてしまう、という流れです。(マイクロソフトサポート)
つまり「容量が足りない」のではなく、「書けない」。ここ、読み違えると復旧が遅れます。
公式対応状況：Known issueとして認め、調査中
Microsoftは既知の問題（Known issue）として掲載し、現時点では“調査中”としています。 (マイクロソフトサポート)
Windows 10 22H2のRelease Health（リリース正常性）にも、KB5071546適用後にMSMQが失敗する件が“Confirmed（確認済み）”として載っており、更新履歴の時刻まで明記されています（最終更新 2025-12-12）。(Microsoft Learn)
要するに、「気のせいでも設定ミスでもなく、今月の更新がトリガー」です。
まず切り分け：それ“今回のやつ”か見分けるコツ
「MSMQが絡む」「KB適用直後」「storage.mq作成失敗 or 誤誘導ログ」の3点セットなら疑い濃厚です。* (マイクロソフトサポート)
特に、IISで動くWebアプリがバックグラウンド処理をキューに投げてる構成だと、フロントは生きてるのに裏が死ぬ、みたいな半端に怖い状態になります。クラスタ（clustered MSMQ）や高負荷時に影響が強い、とMicrosoft自身も書いています。(マイクロソフトサポート)
回避策：現場で多い3ルート（※安全性の話も）
いちばん確実に戻る報告が多いのは「該当KBのアンインストール（rollback／ロールバック）」です。 (Microsoft Learn)
(1) 影響が出たサーバーで、直近の累積更新（例：KB5071546／KB5071544／KB5071543）をアンインストールします。(マイクロソフトサポート)
(2) 再起動後、MSMQの送受信と、IIS配下アプリのキュー投入が復旧するか確認します。
(3) 可能ならテスト環境で同条件を再現し、更新適用の順序と影響範囲をメモしておきます。
Microsoft Q&Aでは「KB5071544を戻したら動いた」という具体例が出ています。(Microsoft Learn)
一方で、セキュリティ更新を外すのは怖い。そこが悩みどころ。
次に多いのが「権限（ACL）を調整して storage に書けるようにする」ルートですが、これは組織のセキュリティポリシーと真っ向からぶつかる可能性があります。Microsoftの説明でも「通常は管理者に制限」と明言されているので、安易にフル権限をばら撒くのは危ないです。(マイクロソフトサポート)
やるなら、どのサービスアカウント（IISのAppPool ID、Network Serviceなど）が実際に必要なのかを最小限で見極めて、変更履歴も残して、暫定対応として扱うのが現実的。ここは“can't 適当”で。
最後に「管理者権限で動かす（全部adminに寄せる）」という雑な回避も話題になりますが、Release Healthには“管理者特権を与えないと失敗する”趣旨の記述があり、これも根本解決ではなく、監査的にもツラいはずです。(Microsoft Learn)
なぜこんな壊れ方？ちょい考察（責めたい気持ちは置いとく）
“セキュリティ強化の副作用が、エラー表示の設計ミスで何倍にも混乱を広げた”のが今回の地獄ポイントです。 (マイクロソフトサポート)
フォルダーに書けないなら、普通はAccess denied（アクセス拒否）を出してほしい。でも実際は「リソース不足」っぽいメッセージで返ってくるので、監視はディスクアラートを鳴らすし、担当は増設検討に走るし、復旧が遅れる。ここ、ほんとに損しかしない。BleepingComputerも、Microsoftの説明として“NTFS権限変更が原因”と報じています。(bleepingcomputer.com)
みんなの報告まとめ：あなたの環境はどれに近い？
コメント欄が一番役立つタイプの障害なので、再現条件を“そのまま”投下してほしいです。 (マイクロソフトサポート)
たとえば、あなたの現場はどっちですか。
IISサイトが落ちる派ですか、それともアプリだけ静かにキュー投入に失敗する派ですか。storage*.mq の作成失敗が出ましたか。クラスタ構成でしたか。更新を戻して復旧しましたか、それともACL調整で凌ぎましたか。
書ける範囲でOKなので、こんな感じで一行ずつ置いていってください。
「OSとバージョン（例：Windows Server 2019）」
「適用KB（例：KB5071544）」
「出た文言（例：Insufficient resources to perform operation）」
「MSMQの使い方（IIS配下／バッチ／クラスタなど）」
「やった対処（rollback／権限調整／未対応）」
同じ症状でも“刺さってるアカウント”が違うだけで挙動が変わること、あります。あなたの一例が、誰かの朝を救うかもしれない。ほんとに。
