2025年12月のWindowsセキュリティ更新で、企業システムの裏側を支えるMSMQ（Microsoft Message Queuing：メッセージ キュー）が突然止まり、IIS（Internet Information Services：Webサーバー）や業務アプリが連鎖的に落ちる事例が広がりました。しかも厄介なのが、ログが「ディスク不足」「メモリ不足」っぽい顔をして原因追跡を邪魔してくる点です。エンタープライズ運用者、情シス、SIer、そして「なんかWebが急に500で落ちた…」側のアプリ担当まで、まとめて刺さる話です。 (マイクロソフトサポート)
- 何が起きてる？MSMQが“静かに”止まる
- 発生日時と対象：どのKB・どのビルドが危ない？
- 症状：エラーがミスリードしてくる（ここが罠）
- 原因：MSMQのセキュリティ変更が“書けない”を生んだ
- 公式対応状況：12月18日の定例外（OOB）で修正済み
- いま現場でできる対処：止血から復旧までの順番
- 影響を受けやすいユーザー層：どんなシステムが刺さる？
- みんなの報告ログ：あなたの環境ではどう出た？
- ひとこと考察：なぜ“嘘つきログ”が一番危険だったのか
何が起きてる？MSMQが“静かに”止まる
2025年12月9日公開の累積更新を入れた後、MSMQが送受信できずキューが非アクティブになり、依存アプリが落ちる現象が確認されています。 (マイクロソフトサポート)
MSMQは既定で無効なことも多く、普段は存在感ゼロです。でも、古くからの業務システムやミドル層で生き残っていて、「非同期で確実に渡す」役を担うことがある。だから止まると、表面のWebやバッチが急に詰まって、現場は阿鼻叫喚になりがちなんですよね…。
発生日時と対象：どのKB・どのビルドが危ない？
トリガーになったのは2025年12月9日リリースの月例更新で、Microsoftが既知の問題として症状と原因を明記しています。 (マイクロソフトサポート)
まず押さえたい“当たりどころ”はここです（ビルド番号も合わせて見てください）。
Windows 10系では、2025年12月9日—KB5071546（OS Build 19045.6691 / 19044.6691）。 (マイクロソフトサポート)
Windows Server 2019系では、2025年12月9日—KB5071544（OS Build 17763.8146）。 (マイクロソフトサポート)
Windows Server 2016系では、2025年12月9日—KB5071543（OS Build 14393.8688）。 (マイクロソフトサポート)
さらに古いサーバー（Windows Server 2012 / 2012 R2 / 2008 / 2008 R2）にも波及しており、MicrosoftのWindowsメッセージ センター（Windows message center：更新告知）側で、定例外の修正（後述）が案内されています。 (Microsoft Learn)
そして「Server 2022でも起きたっぽい」という声はMicrosoft Q&A（フォーラム）で上がっていますが、少なくとも今回の“既知の問題”としては、上の系統のKBで明確化されているのが現状です。 (Microsoft Learn)
症状：エラーがミスリードしてくる（ここが罠）
代表的な症状は「Insufficient resources to perform operation（操作を実行するためのリソースが不足しています）」や、作成失敗ログが出てキューが止まることです。 (マイクロソフトサポート)
Microsoftが挙げている症状はかなり具体的です。MSMQキューが非アクティブになり、IISサイトが上の「Insufficient resources…」で失敗し、アプリがキューに書けなくなる。さらに「The message file 'C:\Windows\System32\msmq\storage*.mq' cannot be created（メッセージファイルを作れない）」系の文言も出ます。 (マイクロソフトサポート)
いやらしいのは、ログに「There is insufficient disk space or memory（ディスク領域またはメモリが不足しています）」みたいな、資源不足に見えるメッセージが出る点。実際は空きもメモリも十分、なのに。ここでストレージ増設に走ると時間が溶けます…。 (マイクロソフトサポート)
原因：MSMQのセキュリティ変更が“書けない”を生んだ
原因はMSMQのセキュリティモデル変更と、C:\Windows\System32\MSMQ\storage のNTFS権限変更で、MSMQが必要な書き込みに失敗することです。 (マイクロソフトサポート)
Microsoftの説明はかなりストレートで、「MSMQ users（MSMQ利用者）が storage フォルダーに書き込み権限を必要とするようになったが、通常そこは管理者に絞っているため、API経由の送信がresource errors（リソース系エラー）で落ちる」という流れです。 (マイクロソフトサポート)
そして「個人のWindows Home/Proでは起きにくい。主に企業や管理されたIT環境に影響」と明記されています。MSMQが入ってない・使ってないケースが多いから、まあ納得ではあります。 (マイクロソフトサポート)
公式対応状況：12月18日の定例外（OOB）で修正済み
Microsoftは2025年12月18日以降に出た定例外更新（out-of-band：OOB）で解消した、と案内しています。 (マイクロソフトサポート)
Windows 10系はKB5074976で修正、とKB5071546のページに明記されています。 (マイクロソフトサポート)
Server 2019系はKB5074975、Server 2016系はKB5074974。 (マイクロソフトサポート)
さらにESU（Extended Security Updates：延長セキュリティ更新）対象の古いサーバー向けにも、KB5074978（Server 2012 R2）やKB5074980（Server 2012）などが案内されています。 (Microsoft Learn)
「Microsoft Update カタログ（Microsoft Update Catalog：手動ダウンロードの配布庫）から入手可能」とされている点も、運用側は要注意です。いつもの自動配信に乗らない前提で動く場面が出ます。 (Microsoft Learn)
いま現場でできる対処：止血から復旧までの順番
結論は“ロールバックで止血”より先に、“OOB適用で前に進む”が一番きれいです（セキュリティも守れる）。 (マイクロソフトサポート)
(1) 影響端末で、2025年12月9日公開の該当KBが入っているか確認します。Windows 10ならKB5071546、Server 2019ならKB5071544、Server 2016ならKB5071543がまず疑いどころです。 (マイクロソフトサポート)
(2) 可能なら最優先で、12月18日以降のOOB更新を適用します。Windows 10系はKB5074976、Server 2019はKB5074975、Server 2016はKB5074974。古いサーバーはWindowsメッセージ センターに並んでいるKB（KB5074978/KB5074980/KB5074977/KB5074979など）を辿ります。 (Microsoft Learn)
(3) どうしてもOOB適用まで時間が空くなら、止血として該当KBのアンインストール（uninstall：削除）で復旧したという報告があります。ただし、そのKBに含まれていたセキュリティ修正も同時に外れるので、短期の暫定として扱うのが無難です。 (Reddit)
(4) 「権限が原因ならACLで直せるのでは？」という発想で、storageフォルダーの書き込み権限をサービスアカウントに付ける応急処置が語られています。これは環境依存かつリスク（本来絞っている場所を緩める）もあるので、やるなら検証機→影響範囲限定→すぐOOBへ、の順で。正直ここ、現場の知恵が出やすいので、成功・失敗どっちでもコメントで共有してほしいです。 (マイクロソフトサポート)
影響を受けやすいユーザー層：どんなシステムが刺さる？
MSMQを“機能として有効化して、業務アプリが依存している”企業環境が直撃します。 (マイクロソフトサポート)
POS（Point of Sale：販売時点）や、古くからの業務アプリ、IIS配下の連携処理、さらにはIoT系の制御まで「キューで渡す」設計は意外と残っています。Computerworldは、MSMQ依存のアプリが広く影響を受けうる、といった文脈で触れています。 (Computerworld)
そしてPetriも、主にエンタープライズで刺さる点と、影響範囲（古いServerまで）をまとめています。 (Petri IT Knowledgebase)
みんなの報告ログ：あなたの環境ではどう出た？
コミュニティではServer 2019のKB5071544での発生報告や、MSMQの“リソース不足”系エラーが相次いでいます。 (Reddit)
r/sysadminのPatch Tuesdayスレでは、KB5071544（Server 2019）でも「insufficient disk space or memory」系のエラーが出た、という話が見えます。 (Reddit)
Microsoft Q&A側でも「社内Webアプリが止まった。いつ直る？」という形で、切実な相談が上がっています。いや、これ…胃が痛いやつです。 (Microsoft Learn)
ここから先は、フォーラム的に盛り上げたいです。あなたの状況、どれに近いですか？
コメントで「OS（例：Server 2019）」「該当KB（例：KB5071544）」「MSMQが単体かクラスタ（cluster：クラスター）か」「出たエラー文言」「OOBで直ったか」を、そのまま貼ってください。たぶん同じ沼の人が助かります。※誤字っててもOK、スピード優先でいきましょ。
ひとこと考察：なぜ“嘘つきログ”が一番危険だったのか
今回の本質は“権限の拒否”なのに、表に出るのが“リソース不足っぽい例外”だったことです。 (マイクロソフトサポート)
ファイルを作れない＝I/O失敗、まではログで分かる。でも「ディスク/メモリ不足」方向に見せられると、監視も運用フローも別ルートに飛びます。結果、復旧までの時間が伸びる。しかも企業システムは、復旧が遅れるほど“二次障害”（滞留、再送、DB負荷、手作業リカバリ）が増えます。地味だけど破壊力は大きい…うーん、つらい。
最後にもう一回だけ。現時点ではOOBで修正済み、が公式の落とし所です。まずは該当KBとビルドを確認して、当てにいくのが最短距離だと思います。 (マイクロソフトサポート)
