2025年12月のWindowsセキュリティ更新を入れた直後から、古めのWindows環境でMSMQ（Message Queuing：メッセージ キュー）が突然コケる事例が増えています。しかも厄介なのが、ログが「ディスク不足」「メモリ不足」っぽい顔をして嘘をつくこと。IIS（Internet Information Services：Webサーバー）や、昔から動いてる業務アプリ、POS（Point of Sale：販売時点情報管理）みたいな“止まると売上が止まる系”が直撃しやすいです。 (Microsoft サポート)
結論から言うと、原因はC:\Windows\System32\MSMQ\storageのNTFS permissions（アクセス許可）がセキュリティ変更で変わり、MSMQ側が書き込めなくなること。現時点でMicrosoftは「調査中」で、一般公開の万能な修正パッチはまだ出ていません。 (Microsoft サポート)
- 何が起きたのか
- 発生日時と対象OS・KB・ビルド
- 症状とエラー文言
- 原因はどこ？なぜ権限でMSMQが死ぬ？
- 公式の対応状況
- 他ユーザーの報告事例
- で、どうする？現実的な選択肢
- 手順：まず影響確認→最小復旧まで
- コメント欄をフォーラム化：あなたの環境を教えて
何が起きたのか
MSMQがキューに書けず、結果としてアプリ間連携が詰まって“連鎖停止”します。 (Microsoft サポート)
The Registerの報道はズバッと「フォルダー権限変更が原因、しかも決定打の修正はまだ」というトーンでした。古いWindowsほど影響が出やすく、しかもESU（Extended Security Updates：拡張セキュリティ更新）で“お金を払って更新している層”が踏みがち、という皮肉も刺さります。 (ザ・レジスター)
発生日時と対象OS・KB・ビルド
2025年12月9日公開の複数KBで、MSMQ既知の問題としてMicrosoftが公式に認めています。 (Microsoft サポート)
まず「いつから？」ははっきりしていて、2025年12月9日のセキュリティ更新（いわゆるPatch Tuesday）適用後です。Windowsのリリースヘルス（Release Health：既知の問題情報）でもKB5071546は「Confirmed（確認済み）」扱いで、2025年12月16日に更新が入っています。 (Microsoft Learn)
該当しやすい更新は、ざっくりこうです（環境が近いほど要注意）。
Windows 10系：2025年12月9日—KB5071546（OS Builds 19045.6691 / 19044.6691） (Microsoft サポート)
Windows 10 Enterprise LTSC 2019相当：2025年12月9日—KB5071544（OS Build 17763.8146） (Microsoft サポート)
Windows 10 Enterprise LTSB 2016相当：2025年12月9日—KB5071543（OS Build 14393.8688） (Microsoft サポート)
Windows Server 2012 R2 ESU：2025年12月9日—KB5071503（※2025年12月16日にMSMQ既知の問題を追記） (Microsoft サポート)
Windows Server 2012 ESU：2025年12月9日—KB5071505（※2025年12月16日にMSMQ既知の問題を追記） (Microsoft サポート)
「対象ユーザー層」はかなり偏っていて、Microsoft自身も“個人のHome/Proで踏む確率は低い、主に企業・管理されたIT環境”と明言しています。つまり、社内の裏方サーバーや、店舗端末、レガシー連携が中心の人ほど刺さるやつです。 (Microsoft サポート)
症状とエラー文言
いちばんの罠は「容量不足に見えるログ」で、実態はpermission（権限）問題です。 (Microsoft サポート)
現場で目印になりやすい症状は、Microsoftの既知の問題欄にまとまっています。
MSMQキューがinactive（非アクティブ）になる。 (Microsoft サポート)
IISサイトが「Insufficient resources to perform operation（操作を実行するためのリソース不足）」で落ちる。 (Microsoft サポート)
アプリがキューに書き込めない。 (Microsoft サポート)
「The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created（メッセージファイルを作成できない）」が出る。 (Microsoft サポート)
「There is insufficient disk space or memory（ディスク領域またはメモリが不足）」が出るけど、実際は十分空いてる。ここで沼ります。 (Microsoft サポート)
エラーコード（error code：エラー番号）としては、アプリ側で0x80004005（E_FAIL：汎用失敗）っぽく見える、という報告もあります。ただし環境と実装（.NETのSystem.Messaging等）で見え方が揺れるので、「文言＋storageフォルダ」が一番確度の高い判断材料です。 (エラー大全集)
原因はどこ？なぜ権限でMSMQが死ぬ？
C:\Windows\System32\MSMQ\storageのNTFSアクセス許可の変更で、MSMQユーザーが書き込めなくなるのが本体です。 (Microsoft サポート)
Microsoftの説明はかなりストレートで、今回の更新で「MSMQのセキュリティモデル（security model：権限モデル）」と、storageフォルダの権限が変わりました。その結果、MSMQユーザーは本来“管理者だけが触る場所”に書き込みが必要になり、API経由の送信がresource error（リソースエラー）として失敗しうる、という流れです。 (Microsoft サポート)
リリースヘルス側の表現だと、かなり強く「フル管理者権限がないとMSMQ操作が失敗する」ニュアンスで書かれています。つまり、権限の付け方をミスると、直ったように見えても負荷時に再発…みたいな最悪のパターンがありえます。 (Microsoft Learn)
公式の対応状況
Microsoftは“調査中”で、回避策は「Microsoft Support for business経由で提供」とされています。 (Microsoft サポート)
各KBの既知の問題欄には「Next step（次の対応）：under investigation（調査中）」が明記されています。いまのところ、誰でも読めるページに“この手順でOK”みたいな固定の解決策は載っていません。 (Microsoft サポート)
一方で「workaround（回避策）はある、適用はMicrosoft Support for business（法人サポート）に連絡して」と書いてあるのも事実。MSMQど真ん中の企業ほど、ここが悔しいポイントですね…。 (Microsoft サポート)
他ユーザーの報告事例
「KBをロールバックしたら復旧した」という報告が、Microsoft Q&Aでも具体的に出ています。 (Microsoft Learn)
Microsoft Q&Aでは、Windows Server 2019でKB5071544を戻すと直る、Server 2016でKB5071543を戻すと直る、という報告が投稿されています。 (Microsoft Learn)
また別スレでは、Windows 10 LTSC端末のPOSがMSMQ依存で“レシートがバックエンドに飛ばず、店舗の日次締めが止まる”といった切実な声も出ています。サービスアカウントがNT AUTHORITY\NETWORK SERVICE（ネットワークサービス）で動いていて、storageフォルダの権限調整を試しているけど決め手がない、という流れ。こういう「現場の焦り」が今回の障害のリアルです。 (Microsoft Learn)
メディア側も、IISの500や業務システム停止まで含めて影響を強調しています。つまり“PCが落ちる”より、“裏の連携が詰まってデータが死ぬ”タイプ。こわい。 (CSO Online)
で、どうする？現実的な選択肢
「業務復旧を優先して一時ロールバック」か「法人サポート経由の回避策」か、二択に寄りがちです。 (Microsoft サポート)
まず、緊急度が高いならロールバック（rollback：更新の取り消し）がいちばん再現性が高い、という報告が揃っています。ただし当然、セキュリティ更新を外すのでリスクが残ります。だから“いつまで戻すか”と“代替防御（ネットワーク分離やWAF等）をどうするか”をセットで決めたい。 (Microsoft Learn)
もう一方の道が、Microsoftが言う「法人サポートから提供される回避策」を取りにいくルート。Q&Aでも「公開配布ではなくサポート経由」と説明されていて、環境ごとに調整が必要、という建て付けになっています。正直めんどいけど、ここが公式ルートです。 (Microsoft Learn)
そして三つ目の“弱い選択肢”として、storageフォルダのACL（Access Control List：アクセス制御リスト）を自力でいじる案。ただ、まちがえると権限を広げすぎて別の事故になります。やるなら検証環境で、最小権限で、監査ログ込み。ここ、疲れる。
手順：まず影響確認→最小復旧まで
「KB特定→症状一致→復旧→再発防止（再インストール阻止）」の順で動くのが早いです。 (Microsoft サポート)
(1) 影響端末/サーバーで、対象KBが入っているか確認します。KB5071546 / KB5071544 / KB5071543 / KB5071503 / KB5071505あたりです。 (Microsoft サポート)
(2) ログを確認します。「Insufficient resources to perform operation」や「storage*.mq cannot be created」や「disk space or memory」が混ざっていないか見ます。 (Microsoft サポート)
(3) いったん業務復旧が最優先なら、該当KBをアンインストールして再起動します（再起動しないと直ったように見えて残ることがあります）。 (Microsoft Learn)
(4) 同じKBが夜中に戻ってくると地獄なので、WSUS/Intune/GPO等でそのKBの再配布を止めます（ここを忘れる人が多い…）。
(5) 公式ルートで行くなら、Microsoft Support for businessに「既知のMSMQ不具合の回避策を適用したい」と伝えて進めます。 (Microsoft サポート)
※もし検証でACLを触るなら、「Everyoneにフルコントロール」はやめてください。NETWORK SERVICEやアプリの実行主体だけに、必要最小限の書き込み権限を検証しながら付ける、が最低ラインです（でも“これで確実に直る”とは言い切れません。今回そこがキツい）。 (Microsoft Learn)
コメント欄をフォーラム化：あなたの環境を教えて
コメント欄で「OS/KB/症状/回避できた方法」を共有すると、同じ沼の人が救われます。
書くときは、このテンプレでOKです。短くていいです、雑でもいいです。ちょっとtypoがあっても伝われば勝ち。
環境：Windows（例：Server 2016 / Win10 LTSC 2019 など）
KB：KB50715xxx（複数なら全部）
実行主体：IIS AppPool / サービスアカウント / NETWORK SERVICE など
症状：inactive / IIS 500 / storage*.mq / “disk space or memory” の有無
回避：ロールバックで復旧した？ サポート回避策は取れた？ ACL調整は効いた？
「うちはクラスターで負荷時だけ死ぬ」とか、「POSだけ詰まる」とか、その一言がいちばん価値あります。
