KB5071546/1543/1544適用後のMSMQエラー対策ガイド：IIS停止の原因とは

2025年12月のWindowsセキュリティ更新を適用した直後から、MSMQ（Message Queuing）が突然停止し、IISが500エラーで落ちるなど、企業システムに深刻な影響を及ぼすトラブルが多数報告されています。

この問題は一見「リソース不足」に見えるものの、実際の原因はMSMQのストレージフォルダーに対する権限変更による書き込み失敗です。

本記事では、発生しているエラーの詳細、影響を受けるOSとKB、問題の切り分け方法、そして現実的な対応策としての「ロールバック」と「ACL調整」の2パターンについて、具体的な手順と注意点を解説します。

MSMQを使っているかどうか分からない方や、IISが突然落ちて困っている方も、自分の環境を確認し、最小限のリスクで復旧するための参考にしてください。

MSMQが突然止まる？12月更新後の異常に注意
1. 2025年12月のWindowsアップデートが原因？
2. 企業システムで見逃されがちなMSMQの影響とは
「Insufficient resources」エラーの正体とは
1. 実際に表示されるエラーメッセージ一覧
2. 見た目はリソース不足、実際は書き込み権限の問題
原因は「MSMQの権限変更」による書き込み失敗
1. MSMQのセキュリティモデル変更とは？
2. IISや特定アカウントで動くサービスが影響を受ける理由
どのKBが対象？影響を受けるOSとバージョン一覧
1. KB5071546 / 1543 / 1544の詳細とビルド番号
2. 影響を受ける代表的な環境例（Windows 10、Server 2016/2019）
今すぐできる！影響の確認方法と切り分け手順
対応策は2つ「ロールバック」か「ACL修正」
Microsoftの公式対応状況と今後の見通し
1. 現在のステータスとパッチ対応の有無
2. フォーラムやユーザーの声から読み取る動向
まとめ：静かに止まるMSMQ、今こそ定期チェックを
1. 今後も役立つ監視と更新管理のポイント
2. MSMQを使っているかどうかの確認も大切

MSMQが突然止まる？12月更新後の異常に注意

2025年12月のWindowsセキュリティ更新を適用した直後から、静かに動いていたMSMQが突然停止する事例が相次いでいます。

これにより、IISが500エラーで落ちたり、業務アプリが使えなくなるなど、現場では混乱が広がっています。

2025年12月のWindowsアップデートが原因？

問題の発端は、2025年12月9日に公開されたWindowsの月例セキュリティ更新です。

特に以下の3つの更新プログラム（KB）が該当し、それぞれの環境で異なる影響が出ています。

OSバージョン	更新プログラム	ビルド番号
Windows 10 22H2（ESU）	KB5071546	19045.6691
Windows Server 2016	KB5071543	14393.8688
Windows Server 2019	KB5071544	17763.8146

これらの更新を適用した直後から、MSMQに異常が発生するという共通のトラブルが報告されています。

企業システムで見逃されがちなMSMQの影響とは

MSMQは裏方の通信手段として使われることが多く、目立ちません。

そのため、障害が発生しても原因特定に時間がかかるケースがほとんどです。

特に、IISのバックエンドでMSMQを使っているような業務システムでは、突然の停止が大きな業務影響を及ぼします。

「気づいたときには止まっていた」という報告も多く、早期のチェックが重要です。

「Insufficient resources」エラーの正体とは

今回の障害で頻発している「Insufficient resources to perform operation」というエラーは、見た目とは裏腹に“リソース不足”が原因ではありません。

この章では、実際に表示されるメッセージと、それが示す本当の問題点を解説します。

実際に表示されるエラーメッセージ一覧

以下は、報告されている代表的なエラーメッセージです。

メッセージ内容	意味・状況
System.Messaging.MessageQueueException: Insufficient resources to perform operation	最も多く報告されたMSMQの送信失敗
The message file ‘…storage*.mq’ cannot be created	MSMQの内部ファイル生成ができない
There is insufficient disk space or memory	実際には空きがあるのに誤表示される

「空き容量があるのに落ちる」というのが、トラブルの難しさを物語っています。

見た目はリソース不足、実際は書き込み権限の問題

この「Insufficient resources」エラーの根本原因は、MSMQが利用するストレージフォルダーにアクセスできないことです。

具体的には、C:\Windows\System32\MSMQ\storageフォルダーに対するNTFS権限（ACL）の変更により、アプリケーションが書き込みに失敗しています。

その結果、「リソース不足」と誤認識されるエラーが発生しているのです。

つまり、本当の問題は「権限」だったというわけです。

このような“見かけと実態のズレ”が、原因特定を難しくしています。

原因は「MSMQの権限変更」による書き込み失敗

では、なぜ今回の更新でMSMQが書き込みに失敗するようになったのでしょうか。

鍵となるのは「セキュリティモデルの変更」と「フォルダー権限（ACL）の変更」です。

MSMQのセキュリティモデル変更とは？

Microsoftは2025年12月の更新で、MSMQのセキュリティ強化を目的に内部モデルを変更しました。

その一環で、MSMQが使用するストレージフォルダーのNTFS権限が一部変更され、従来とは異なるアクセス制御が適用されています。

この変更により、既存のアカウント（例：IIS_IUSRSやLocalServiceなど）が必要な書き込み権限を持たないケースが増えました。

変更内容	影響を受けるケース
MSMQのフォルダーACLがより厳格に	IISやカスタムアプリがMSMQを使う場合
ローカルサービスアカウントでのアクセスが制限	バックエンドでMSMQに書き込む処理がある場合

サービスは正常に見えても、裏で詰まっているのが、今回の問題のややこしいポイントです。

IISや特定アカウントで動くサービスが影響を受ける理由

IISで動作するWebアプリケーションは、通常IIS_IUSRSという制限付きアカウントで動作しています。

また、MSMQを利用する他のサービスもLocalServiceやNetworkServiceといった特権の低いアカウントを使うことが一般的です。

これらのアカウントがC:\Windows\System32\MSMQ\storageに書き込めない構成になったため、アプリは内部的に失敗します。

「管理者アカウントなら動くのに、IISでは失敗する」といった現象は、まさにこの権限設定が原因です。

どのKBが対象？影響を受けるOSとバージョン一覧

ここでは、影響が報告されている具体的な更新プログラム（KB）と、それが適用されるWindowsバージョンを整理します。

自分の環境が該当するかどうかを確認するために、正確なOSバージョンとビルド番号を把握しておくことが重要です。

KB5071546 / 1543 / 1544の詳細とビルド番号

2025年12月の月例アップデートで公開されたMSMQ関連の更新は、以下の3つです。

KB番号	適用OS	ビルド番号
KB5071546	Windows 10 22H2（ESU対象）	19045.6691
KB5071543	Windows Server 2016／Windows 10 ver.1607	14393.8688
KB5071544	Windows Server 2019／Windows 10 ver.1809	17763.8146

これらのKBがインストールされていると、MSMQのセキュリティ設定が更新され、前述のような権限問題が発生します。

影響を受ける代表的な環境例（Windows 10、Server 2016/2019）

この問題は、主に以下のような構成でMSMQを使用している環境で発生しています。

業務用アプリケーションがIISでホストされており、MSMQを使って非同期処理を行っている
バックエンドでMSMQを使ったデータ連携やワークフロー制御をしている
Windows 10端末をベースにしたローカル開発環境でMSMQを使っている

特に企業利用では“いつの間にか使っていた”MSMQが影響を受けているケースが多く見られます。

意識して使っていないと、MSMQ障害に気づきにくいのもリスクの一つです。

今すぐできる！影響の確認方法と切り分け手順

MSMQの不具合が発生しているかどうかを確認するには、いくつかのステップを踏んで切り分けを行う必要があります。

ここでは、現場ですぐに試せるチェック方法を順を追って解説します。

OSとインストールKBの確認方法

まずは自分のPCやサーバーに問題の更新（KB）が適用されているかを確認しましょう。

確認手順	方法
OSバージョン確認	`winver`コマンドを実行
インストールKB確認	[設定] → [更新とセキュリティ] → [更新履歴]
詳細確認	「インストールされた更新プログラム」一覧でKB番号をチェック

対象KB（5071546、5071543、5071544）が入っていれば、MSMQの問題に該当する可能性があります。

イベントログとアプリログでのエラー確認方法

次に、具体的なエラーメッセージが出ているかをログから確認します。

[イベントビューアー]で「アプリケーション」「システム」ログを確認
「MSMQ」「MessageQueueException」などのキーワードで検索
「Insufficient resources」や「storage*.mq cannot be created」といった記述があるかチェック

このエラーが出ていれば、高確率で今回の問題が関係しています。

MSMQの実行アカウントとフォルダー権限のチェックポイント

MSMQが利用しているアカウントが正しく権限を持っているかを確認します。

対象フォルダーは、C:\Windows\System32\MSMQ\storageです。

確認項目	方法
実行ユーザーの特定	サービス構成／IISアプリプールのIDを確認
フォルダー権限の確認	右クリック → [プロパティ] → [セキュリティ]タブ
書き込み権限の有無	対象ユーザーが「書き込み」可能かを確認

ここで書き込み不可になっていれば、権限変更が原因の可能性大です。

対応策は2つ「ロールバック」か「ACL修正」

問題が確認された場合、現実的な対応策は以下の2つに絞られます。

それぞれの方法にメリットと注意点があるので、状況に応じて選択しましょう。

ACL（アクセス権）を調整する場合の注意点

更新は維持したまま復旧するには、MSMQのストレージフォルダーに必要最小限のアクセス権を設定する方法があります。

しかし、これはセキュリティ方針に影響する重要な変更になるため、必ず組織内の承認を得るべきです。

アクセス権を付与するのは本当に必要なアカウントのみに限定
「Everyoneにフルアクセス」などの安易な設定は絶対NG
更新によって設定が上書きされる可能性がある点にも注意

ACL調整は“慎重に検証しながら”実施する必要があります。

KBのロールバック方法と注意点

一方で、もっとも手軽で即効性のある手段は「更新プログラムの削除（ロールバック）」です。

対象OS	ロールバック手順
Windows 10	[設定] → [更新とセキュリティ] → [更新履歴] → [更新プログラムをアンインストール]
Windows Server	「コントロールパネル」→「プログラム」→「インストールされた更新の表示」

ロールバック後は再起動が必要ですが、すぐにMSMQが復旧するケースが多く報告されています。

ただし、これはセキュリティパッチを一時的に外す行為なので、恒久的な運用には向きません。

どちらを選ぶ？組織内の判断基準とは

ACL調整とロールバック、どちらを選ぶかは以下の基準を参考にしましょう。

選択肢	推奨されるケース	注意点
ACL調整	セキュリティ方針を維持しつつ復旧したい	社内稟議や影響調査が必要になる
ロールバック	早急な復旧が最優先	再度の更新が必要になる可能性あり

どちらを選んでも「原因と対応履歴を記録しておく」ことが、今後の備えになります。

Microsoftの公式対応状況と今後の見通し

MSMQの問題に対して、Microsoftはどのような対応をしているのでしょうか。

この章では、公式の見解と今後の見通しを整理しつつ、ユーザー側でできる対策もあわせて紹介します。

現在のステータスとパッチ対応の有無

2025年12月16日時点で、Microsoftはこの問題を「確認済み」として認識していますが、恒久的な修正パッチはまだ提供されていません。

各KB（KB5071546/1543/1544）には、「既知の問題」として情報が追記されています。

KB番号	ステータス	備考
KB5071546	Confirmed / Investigating	Windows 10 22H2
KB5071543	Confirmed / Investigating	Windows Server 2016
KB5071544	Confirmed / Investigating	Windows Server 2019

つまり、現時点ではユーザー自身での対応が必須ということになります。

フォーラムやユーザーの声から読み取る動向

Microsoft Q&AやRedditなど、ユーザー投稿の場では多数の現場報告が挙がっています。

「ロールバックで復旧した」という声が多数
「IIS_IUSRSやLocalServiceの書き込み権限が外れていた」との報告が共通
「ACL調整しても、再起動や再更新で戻される」との懸念

今後の更新で修正される可能性は高いですが、それまでの間は自衛的な対応が求められます。

まとめ：静かに止まるMSMQ、今こそ定期チェックを

今回のMSMQ障害は、パッと見では分かりにくく、かつ業務に大きな影響を及ぼす厄介なトラブルです。

しかし、原因が分かれば対応は十分可能です。

今後も役立つ監視と更新管理のポイント

再発を防ぐためには、以下のような対応を日常的に行うことが大切です。

対策	理由
定期的なログチェック	静かにエラーが蓄積する前に気づける
更新適用前のテスト	業務停止のリスクを未然に防ぐ
MSMQ使用状況の可視化	使っているのに把握していないリスクを減らす

裏で使っている機能ほど、監視と理解が重要です。