2025年12月のWindows 10延長セキュリティ更新（ESU: Extended Security Updates／延長セキュリティ更新）を当てた直後から、企業システムでMSMQ（Microsoft Message Queuing／メッセージキュー）が突然死ぬ、という地味に最悪な不具合が出ています。IIS（Internet Information Services／Webサーバー機能）配下のアプリが500を吐いたり、バックグラウンド処理が止まったり、「サーバーは動いてるのに仕事が進まない」系のやつ。影響が大きいのは“MSMQを使ってる環境だけ”なので、家庭用PCだと気づかない人がほとんどです。
- いつ起きた？どの更新がトリガー？
- どんなエラーが出る？“それっぽい嘘”をつくのが厄介
- 原因は何？Microsoftが言ってる“核心”
- 公式の対応状況は？直った？まだ？
- 影響を受けやすいユーザー層
- まず確認：自分の環境が該当するか
- 対処は2択：いったん戻すか、権限を触るか
- みんなの報告：他ユーザーはどんな状況？
- コメント欄テンプレ：あなたの環境を教えて
いつ起きた？どの更新がトリガー？
発端は2025年12月9日公開のセキュリティ更新で、既知の問題としてMicrosoftが「確認済み（Confirmed／確認済み）」扱いにしています。 (Microsoft Learn)
今回の主役は、Windows 10 22H2向けの累積更新プログラム（LCU: Latest Cumulative Update／累積更新）です。
Windows 10 22H2: KB5071546（OSビルド 19045.6691 / 19044.6691） (マイクロソフトサポート)
Windows Server 2019 / Windows 10 1809系: KB5071544（OSビルド 17763.8146） (マイクロソフトサポート)
Windows Server 2016 / Windows 10 1607系: KB5071543（OSビルド 14393.8688） (マイクロソフトサポート)
なお、Windowsリリースヘルス（Release Health／既知の問題ダッシュボード）側の記載更新は「2025年12月12日 17:13 PT（日本時間だと12月13日10:13頃）」が目安になっています。 (Microsoft Learn)
どんなエラーが出る？“それっぽい嘘”をつくのが厄介
典型例は System.Messaging.MessageQueueException: Insufficient resources to perform operation. で、資源不足に見せかけて実は権限（permission／アクセス許可）問題です。 (Windows Latest)
Windows Latestなどの報告だと、影響を受けた環境で見えやすいのはこのへん。
まずキューが「inactive（非アクティブ）」になって処理が流れない。IISサイトが「Insufficient resources to perform operation（操作を実行するためのリソースが不足）」で落ちる。アプリがキューに書き込めない。さらにログがややこしくて、「ディスクやメモリが足りない」みたいなミスリード（misleading／誤誘導）まで出ることがあります。 (マイクロソフトサポート)
もう一段いやらしいのが、ファイル生成エラーです。
The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created といった形で、MSMQの保存領域に作れないログが出ます。 (マイクロソフトサポート)
原因は何？Microsoftが言ってる“核心”
原因はMSMQのセキュリティモデル変更に伴う、C:\Windows\System32\MSMQ\storage のNTFS権限変更で、書き込み権限が足りないアカウントが爆死します。 (マイクロソフトサポート)
Microsoftの説明はかなりストレートで、更新後は「MSMQを使うユーザー（サービスやアプリ実行アカウント）が storage フォルダに書き込みできないと失敗する」としています。 (マイクロソフトサポート)
現場的には、IISのアプリプールID、LocalService（ローカルサービス）、NetworkService（ネットワークサービス）、あるいは権限を絞ったサービスアカウントが、このフォルダに書き込みを持っていなくて詰む、というパターンが多いはず。で、例外の見え方が「リソース不足」なので、最初にディスク増設とかメモリ増設を疑って時間が溶ける…うう、あるある。
公式の対応状況は？直った？まだ？
現時点（2025年12月16日）では「調査中（under investigation／調査中）」で、恒久的な修正パッチや明確な回避策はまだ出ていません。 (マイクロソフトサポート)
BleepingComputerも「12月の更新でMSMQが壊れる」こと、影響がWindows 10 22H2 / Server 2019 / Server 2016に広がることを報じています。 (bleepingcomputer.com)
つまり、組織側はしばらく「守りたいのはセキュリティか、稼働か」の二択を迫られます。しんどいね…。
影響を受けやすいユーザー層
一般ユーザーより、MSMQ依存の業務アプリやIIS連携を持つ企業・自治体・SI環境が直撃しやすいです。 (Windows Latest)
家庭用PCだとMSMQ自体を入れてない（Windowsの機能で有効化してない）ケースが多く、そもそも踏まない。逆に、オンプレの古参システムや、.NETの System.Messaging（システム.メッセージング）でキュー送受信している仕組みが残っていると、アップデート直後に一気に症状が表面化します。
まず確認：自分の環境が該当するか
該当KBとOSビルドを先に押さえると、切り分けが一気に速くなります。 (マイクロソフトサポート)
確認の近道は「更新履歴（Update history／更新の履歴）」です。コマンド派なら、たとえば wmic qfe | find "5071546" みたいにKB番号を拾ってもOK。
そして、MSMQを使っているプロセスが“誰として動いているか”。ここが次の対処の分岐点になります。
対処は2択：いったん戻すか、権限を触るか
一番安全に“今すぐ復旧”しやすいのは該当更新のアンインストール（ロールバック）ですが、セキュリティ面の代償もセットです。 (Windows Latest)
(1) 設定 → 更新とセキュリティ → Windows Update → 更新の履歴 を開きます。 (Windows Latest)
(2) 「更新プログラムをアンインストールする」を開きます。
(3) 該当KB（例：KB5071546 / KB5071544 / KB5071543）を選んでアンインストールします。 (Windows Latest)
(4) 再起動して、MSMQとIISアプリの復旧を確認します。
もう一つの道が、C:\Windows\System32\MSMQ\storage のアクセス許可（ACL: Access Control List／アクセス制御リスト）を、MSMQを使うアカウントに合わせて調整する方法です。Microsoftも原因としてここを名指ししています。 (マイクロソフトサポート)
ただし、権限を広げすぎるとセキュリティ上の意味が逆転します。おおむに「最小権限（least privilege／最小特権）」で、必要な主体だけに書き込みを付けるのが前提。ここは運用チームとセキュリティ担当の合意がいるやつです。
みんなの報告：他ユーザーはどんな状況？
「ロールバックしたら直った」という報告が複数出ていて、再起動や機能の入れ直しでは戻らないケースが目立ちます。 (Microsoft Learn)
Microsoft Q&Aでは、KB5071544（Server 2019）やKB5071543（Server 2016）を戻すと動作が復旧する、という具体的な投稿が出ています。 (Microsoft Learn)
X（旧Twitter）でも、この不具合を話題にする投稿が流れていて、「IISが巻き添えで落ちる」点が強調されています。 (X (formerly Twitter))
ここ、コメント欄が一番役に立つところなので、あなたの環境もぜひ置いていって。再現条件が集まると、回避策の精度が上がります。たぶん、ほんとに。
コメント欄テンプレ：あなたの環境を教えて
「OSビルド」「KB番号」「MSMQの実行主体（誰の権限で動くか）」の3点があると、話が早いです。
(1) OS（例：Windows 10 22H2 / Windows Server 2019 など）
(2) OSビルド（例：19045.6691 / 17763.8146 / 14393.8688）
(3) 該当KB（例：KB5071546 / KB5071544 / KB5071543）
(4) 症状（例：IIS 500、キューがinactive、Insufficient resources など）
(5) MSMQ利用形態（例：System.Messaging、クラスタ有無、アプリプールID等）
(6) いまの対処（ロールバックした／ACL触った／様子見、など）
