2025年12月の月例セキュリティ更新を入れた直後から、IIS（Internet Information Services：Webサーバー機能）配下のアプリや業務システムで、MSMQ（Message Queuing：メッセージ キュー）への書き込みが突然コケる──そんな報告が一気に増えました。GBHackersでも「IIS上のMSMQ機能が壊れる」として取り上げられています。citeturn5search0
困るのは、ログがわりと平然と嘘をつくこと。「リソース不足」「ディスク/メモリ不足」って出るのに、実際は余裕がある。え、どっちなの…と、現場がざわつくタイプです。citeturn1view0turn1view2
- 何が起きてる？いちばん多い症状はこれ
- 影響範囲：どのKB・ビルドが危ない？
- 原因：MSMQの“セキュリティ強化”が、権限周りで裏目った
- 公式対応状況：いまは「調査中」、確定回避策は自己防衛フェーズ
- いますぐできる対処：現実的には2択、ただし片方は“守り”が必要
- 他ユーザーの報告：似た人、います（あなたの環境だけじゃない）
- フォーラム風：あなたの状況、どれに近い？（書き込み歓迎）
何が起きてる？いちばん多い症状はこれ
**MSMQのキューが非アクティブ化し、IISサイトやアプリがキューに書けず落ちます。**citeturn1view0turn1view1turn3view1
典型例は .NET の System.Messaging.MessageQueueException で、文言が「Insufficient resources to perform operation（操作を実行するためのリソースが不足しています）」になります。citeturn1view2turn3view2
さらに厄介なのが、イベントログ等で「There is insufficient disk space or memory（ディスク領域またはメモリが不足）」みたいな“それっぽい”誤誘導が混じる点。空き容量もメモリもあるのに、ですよ。citeturn1view0turn1view2
もう一つの目印として、「C:\Windows\System32\msmq\storage*.mq を作れない」系のメッセージが出るパターンも確認されています。citeturn1view0turn1view2
影響範囲：どのKB・ビルドが危ない？
**Microsoftが“既知の問題”として明示しているのは、主に次の12月9日配信分です。**citeturn1view2turn1view0turn1view1turn3view0turn3view1
Windows 10 22H2：KB5071546（OS Build 19045.6691 / 19044.6691）citeturn1view0turn1view2
Windows Server 2019：KB5071544（OS Build 17763.8146）citeturn1view1turn1view2
Windows Server 2016：KB5071543（OS Build 14393.8688）citeturn3view0turn3view1
ポイントは「一般家庭」より「企業・検証環境」に刺さりやすいこと。そもそもMSMQを使っているのが、基幹/連携/バッチ/オンプレIIS…みたいな世界なので、静かに致命傷になりがちです。citeturn2search3turn2search6
あと、クラスタ構成（clustered MSMQ：クラスタ化されたMSMQ）で負荷がかかったときにも影響が出る、とMicrosoft側の説明に含まれています。citeturn1view0turn1view2
原因：MSMQの“セキュリティ強化”が、権限周りで裏目った
**原因は、MSMQのセキュリティモデル変更と C:\Windows\System32\MSMQ\storage のNTFS権限変更です。citeturn1view0turn1view2
ざっくり言うと、これまで普通に動いていた「IISアプリの実行ユーザー」や「LocalService / NetworkService（ローカルサービス/ネットワークサービス）」が、キューの実体ファイルを書き込む場所にアクセスできなくなって、送信APIが失敗します。結果、例の“リソース不足”に化ける。citeturn3view2turn1view2
Windows Release Health（Windowsの既知の問題ダッシュボード）側には、“MSMQユーザーはstorageフォルダへの書き込みが必要になったが、通常そこは管理者にしか許可されていない”**と、かなり踏み込んだ説明が載っています。citeturn1view2
だから「管理者権限だと動く/一般権限だと死ぬ」という、いかにも権限っぽい挙動になります。citeturn1view2turn3view1
公式対応状況：いまは「調査中」、確定回避策は自己防衛フェーズ
**Microsoftのステータスは現時点で“Under investigation（調査中）”です。**citeturn1view0turn1view1turn3view1
サポート記事（各KB）とRelease Healthの両方に「追加情報は準備でき次第共有する」とあり、恒久修正（たとえばOut-of-band更新）を待つ形になります。citeturn1view2turn3view1
一方で、現場の声はすでにかなり揃っていて、Microsoft Q&Aでも「KB5071544適用後にIIS_IUSRSが C:\Windows\System32\msmq に書けない。ロールバックで直る」と具体例が出ています。citeturn3view2
いますぐできる対処：現実的には2択、ただし片方は“守り”が必要
**最優先は“影響を止血する”こと。次に“セキュリティの穴”をどう埋めるか、です。**citeturn1view2turn1view0
対処A：該当KBをアンインストール（止血として強い）
(1) 影響端末で、直近適用のKBが KB5071546 / KB5071544 / KB5071543 のどれか確認します。citeturn1view2turn1view0turn1view1turn3view1
(2) 可能なら同一構成の検証機で先にアンインストールし、MSMQ送受信とIISサイトが復活するか確認します。
(3) 本番で実施する場合は、業務影響の窓を確保してからアンインストール→再起動→疎通確認、の順で進めます。
(4) ロールバック後は、同じ更新が戻ってこないよう一時的に更新配布を止めます（WSUS/Intune/自動更新ポリシーの見直し）。
「戻すと直る」は複数ソースで一致しています。とはいえ、セキュリティ更新を外すのは怖い。なので“止血期間を短くする前提”で使うのが無難です。citeturn2search3turn3view2turn2search6
対処B：storageフォルダのACL（アクセス権）を最小限で見直す
(1) C:\Windows\System32\MSMQ\storage に対して、実際にMSMQ送信を行うアカウント（例：IIS_IUSRS、該当アプリのサービスアカウント）が書き込みできるか確認します。citeturn1view2turn3view2
(2) 書き込み不可なら、**“必要な主体だけ”**に最小限の権限を付与する方針を検討します（Full Control（フルコントロール）を雑にばらまくのは、正直おすすめしません）。citeturn1view2turn3view2
(3) 変更後、MSMQの送信・キュー生成・IISの該当機能をまとめてテストします。
(4) もし権限が勝手に戻る/維持されない挙動があるなら、その挙動自体が今回の問題の一部なので、変更履歴と差分を控えておきます。citeturn3view2
このルートは「更新を外さずに済む」可能性がある反面、セキュリティ設計に踏み込みます。セキュリティ担当と握らずに突っ走るのは、あとで揉めがち…なので、ここは慎重に。
他ユーザーの報告：似た人、います（あなたの環境だけじゃない）
**IISアプリ（IIS_IUSRS）や LocalService / NetworkService が書けなくなった、という声が具体的に出ています。**citeturn3view2
Microsoft Q&Aでは、KB5071544適用後に C:\Windows\System32\msmq への書き込みが失敗し、ロールバックで即復旧したと書かれています。さらに「同様の報告がRedditにもある」とまで言及されています。citeturn3view2
別回答でも、KB5071543 / KB5071544 適用後に System.Messaging 経由の送信が「Insufficient resources…」で落ち、KBを戻すと直る、という流れが一致しています。citeturn3view2
ニュース側でも、Microsoftが“MSMQ既知の問題”として認めたこと自体が報じられており、いま起きてる現象が局所事故じゃないのは確定です。citeturn2search6turn5search0
フォーラム風：あなたの状況、どれに近い？（書き込み歓迎）
コメントするなら「KB番号」「OSビルド」「実行アカウント」「ログ文言」まであると、同じ沼の人が助かります。
たとえば、こんな感じで十分です。
2025年12月9日更新のどれを入れたか（KB5071546/KB5071544/KB5071543）
OSビルド（19045.6691、17763.8146、14393.8688 など）citeturn1view2turn1view1turn3view1
IIS上のアプリか、Windowsサービスか
実行アカウント（IIS_IUSRS、LocalService、NetworkService、独自ドメインアカウント等）citeturn3view2
出たエラー文言（“Insufficient resources…” / “disk space or memory…” / storage*.mq作成失敗）citeturn1view2turn1view0
最後にひとこと。今回の問題って、「セキュリティ強化で権限を締めたら、古参の連携基盤が息できなくなった」匂いが強いんですよね。だからこそ、場当たり的に管理者権限で逃げると、あとで別の事故を呼ぶ。うーん、つらい。
あなたの現場では、アンインストールで逃げました？ それともACL最小化で耐えました？ どっちが安全に回ったか、ぜひ残していってください。
