WSUS 適用率99%で黄色い三角が消えない原因と対処法｜コンプライアンス率を100%に戻す手順

WSUSで端末の適用率が99%のまま、クライアント名の左に黄色い三角（警告）が出ると「閾値を下げてOKにできないの？」と感じがちです。ですがこの表示は“未適用更新が残っている”事実を示す仕組みです。本記事では仕様を整理し、未適用の特定から解消までを実務目線でまとめます。

WSUSで「適用率99%」と黄色い三角が出る状況を整理

WSUSコンソールのコンピューター一覧には、端末ごとの更新状態がパーセンテージとアイコンで表示されます。ここで表示される黄色い三角は、単なる“見た目の注意喚起”ではなく、その端末に「未適用（要対応）」と判定されている更新が残っていることを示します。

まずは、WSUSのアイコンが何を意味するのかをざっくり整理しておくと、状況の切り分けが速くなります。

表示（例）	意味（実務上の解釈）	最初に確認すべきこと
緑（OK）	未適用として残っている更新が基本的にない（またはWSUS上で“要対応”が検出されていない）	本当に最新かは「最終ステータス報告日時」も併せて確認
黄色い三角（警告）	要対応（Needed）・失敗（Failed）・未評価/未報告（No status/Unknown）等が残っている可能性	当該端末で「何がNeeded/Failed扱いなのか」を特定
赤（重大）	失敗が多い、または深刻な状態（更新失敗が継続、疎通不良など）	エラーコード、Windows Update関連サービス、WSUS疎通
灰（不明）	WSUSへの報告が古い／そもそも報告が上がっていない	端末の最終報告、WSUS設定（GPO/レジストリ）、ネットワーク

今回のテーマは「黄色い三角を消したい」「適用率100%未満でもOKにしたい」ですが、結論から先に言うと、“表示だけを都合よく変える”方向では解決しません。WSUSは“端末が報告した状態”を集計しているため、未適用扱いの更新が残っている限り、黄色い三角が出るのは正常です。

結論：コンプライアンス率の閾値（100%基準）は変更できない

「100%未満でもOK扱いにする」「90%を合格ラインにする」といった、コンプライアンス率の閾値を変更する機能はWSUSにはありません（仕様）。WSUSコンソールの“OK/警告”は、監視ツールのように任意のしきい値で切り替えるタイプではなく、“未適用が残っているかどうか”を端末の状態報告に基づいて判定しています。

やりたいこと	WSUS標準機能で可能？	実務上の答え
適用率が99%でも「OK」にしたい（合格ラインを90%にしたい）	不可	仕様上できない。未適用を減らして100%に寄せるしかない
黄色い三角（警告）を“機能として無効化”したい	不可	アイコンの判定ロジック自体は変えられない
画面上で警告端末を見えにくくしたい（非表示にしたい）	条件付きで可	フィルター/グループ運用で「表示しない」は可能だが、見落としの温床なので非推奨
運用上の“合格ライン”を90%にしたい	WSUS単体では限定的	外部レポート（Power BI/監視製品/独自集計）で運用指標を作るのが現実的

「見た目だけ消す」よりも、何が未適用扱いなのかを特定して潰す方が、結局いちばん早く安全です。次章からは、WSUSの“適用率”がどう計算され、なぜ99%で止まりがちなのかを具体的に解説します。

なぜ99%で止まるのか：WSUSの適用率（コンプライアンス率）の考え方

WSUSが表示する適用率は、端末がWSUSに対して報告した更新ごとの状態（インストール済み／必要／失敗／不明など）を集計した結果です。細かな計算式は画面やレポート種別で見え方が異なることがありますが、実務上は次の理解でほぼ困りません。

• 100%＝その端末に「要対応（Needed）」扱いの更新が残っていない状態
• 99%＝何か1つ以上が「要対応」または「失敗」または「未評価/未報告」等として残っている状態
• 「適用外（Not Applicable）」は“その端末には関係ない更新”なので、基本的に未適用としては扱われません

イメージが掴めるよう、単純化した例を表にします。

状態	件数（例）	実務上の扱い	適用率への影響
インストール済み（Installed）	495	対応済み	上がる
適用外（Not Applicable）	0〜大量	対象外なので問題なし	（多くの表示では）下げ要因になりにくい
必要（Needed）	5	未適用で要対応	下がる（警告の主因）
失敗（Failed）	0〜数件	対応が必要（再試行・原因調査）	下がる（赤/黄の主因）
未報告/不明（No status/Unknown）	0〜数件	そもそも端末が評価できていない	下がる（黄/灰の主因）

「たった数件のNeededで黄色い三角が出続ける」のは、WSUSの思想が“全台の更新状態を揃える”に寄っているからです。特に累積更新や.NET系、SSU（サービシング スタック更新）や前提更新などが絡むと、1件の未適用が芋づる式に表示へ影響します。

まずやるべきこと：その端末で未適用扱いの更新を特定する

黄色い三角を消す最短ルートは、精神論でも設定変更でもなく、「WSUSが“未適用”と判定している更新の正体」を特定することです。ここが曖昧なままだと、再起動やサービス再起動を繰り返して時間だけが溶けます。

WSUSコンソールで端末単位に「Needed/Failed」を見る

WSUSコンソールで対象端末を開き、更新の一覧を「必要（Needed）」や「失敗（Failed）」で絞り込むのが基本です。ここで重要なのは、“何が残っているか”を更新プログラム名（KB番号）で把握することです。

確認ポイント	見るべき項目	判断のコツ
未適用の正体	Neededになっている更新（KB）	累積更新、.NET、Defender定義、Office系など種類をまず分類
失敗の有無	Failedになっている更新	失敗があるなら“なぜ失敗したか”が最優先
報告が古い	最終ステータス報告日時、最終接続	報告が古い端末は、そもそも数字が信用できない
再起動待ち	端末側の状況（後述）	再起動待ちは「必要が残る」典型。WSUS側だけ見ていても消えない

レポート機能（Report Viewer等）があるなら“端末の詳細レポート”が最速

レポートが使える環境では、端末ごとの詳細レポート（コンピューター別の更新状態）を出すと、必要な更新が一覧で見えるため調査が一気に楽になります。運用の現場では、次のような使い分けが効果的です。

レポートの使い方	向いている場面	得られるもの
端末1台の詳細	黄色い三角の原因を潰したい	Needed/Failedの更新一覧、KB番号、概要
グループ全体の概要	テスト→本番の承認運用を見直したい	グループ別の未適用件数、傾向（特定KBの偏りなど）
更新プログラム別の詳細	特定KBが大量に未適用/失敗している	どの端末で失敗しているか、対象範囲

「WSUSの画面だと追いづらい」と感じる場合、レポートがあるだけで調査時間が体感1/3になります。もしレポート基盤がないなら、最低限でも“端末の更新一覧でNeededを抽出”できる運用にしておくのがおすすめです。

よくある原因と対処：黄色い三角（警告）が消えないパターン集

未適用扱いが残る原因は多岐にわたりますが、現場で遭遇頻度が高い順に並べると、だいたい次のどれかです。

よくある原因	WSUS上の見え方	端末側の実態	代表的な対処
再起動待ち	Neededが残る／適用率が微妙に上がらない	インストールは進んでいるが再起動で完了するタイプの更新	再起動→再評価（スキャン）→報告
更新のインストール失敗	Failedが残る、警告/重大が消えない	前提不足、破損、競合、ディスク不足など	エラーコード確認→原因に応じた修復（DISM/SFC等）
承認のねじれ（承認漏れ/誤承認）	特定KBだけNeededが残り続ける	テスト環境では承認済みだが本番で未承認、または分類/製品の取りこぼし	承認手順を見直し、グループ別承認を再設計
端末がスキャン/報告していない	No status/Unknownが混ざる、数字が古い	Windows Updateサービス停止、WSUS疎通不良、GPO未適用	WSUS設定確認→スキャン/報告の強制→疎通確認
WSUS側のメンテ不足	不要な更新が多く管理が破綻し、判断が遅い	期限切れ/置き換え済み更新が溜まり、DB/コンテンツが肥大化	クリーンアップ、置き換え済みの拒否、整合性確認

ここからは各パターンについて、具体的な確認方法と手順を掘り下げます。

再起動待ち：いちばん多いのに見落とされやすい

WSUSで99%が延々と続く原因として多いのが、端末が再起動待ちのまま止まっているケースです。WSUSは端末からの報告が更新されない限り、状態を“完了”にできません。

特にサーバーは再起動が慎重になりがちで、「更新は入れたつもり」でも、最後の再起動が保留されていることがよくあります。

• 更新適用後に再起動していない
• 自動再起動が抑止されていて、メンテナンスウィンドウまで待っている
• 再起動はしたが、スキャン/報告が走っておらずWSUS側に反映されていない

対処としては、再起動→スキャン→報告の順に一度“状態を確定”させるのがコツです（スキャン/報告の具体コマンドは後述）。

更新のインストール失敗：Failedが残っているなら最優先

WSUSで黄色い三角が消えない端末にFailedがある場合、そこを放置して“表示だけ消す”方向に進むのは危険です。Failedはセキュリティ更新の欠落につながりやすく、監査でも突っ込まれやすいポイントです。

失敗時は、まず「どのKBが失敗しているか」を特定し、次に端末側で失敗の理由（エラーコード）を掴みます。代表的なアプローチは次の通りです。

確認場所	何が分かるか	ポイント
イベントビューアー（WindowsUpdateClient）	失敗した更新、エラーの傾向	まずは“失敗の種類”を掴む（ダウンロード失敗/適用失敗など）
Windows Updateログ	より詳細な内部処理ログ	原因特定が必要なときに掘る（環境により取得方法が異なる）
WSUS側の更新詳細	WSUS上の端末ステータス	WSUSの見え方と端末実態がズレていないか確認

汎用的な修復としては、システム整合性の修復（DISM/SFC）や、Windows Updateコンポーネントのリセットが効く場面が多いです。例えば次のような手順は、原因が特定できない場合の“安全な第一手”として使われます。

REM （管理者で実行）Windows Update関連サービス停止
net stop wuauserv
net stop bits
net stop cryptsvc

REM キャッシュ退避（削除ではなくリネーム推奨）
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

REM サービス再開
net start cryptsvc
net start bits
net start wuauserv

この後にスキャンを実行し、WSUSに再報告させることで、Needed/Failedの表示が更新されます。もちろん、サーバーでは業務影響があるため、変更前にスナップショット/バックアップ、メンテ時間の確保など、運用ルールに沿って実施してください。

承認のねじれ：テストはOKなのに本番だけ99%が残る

運用で地味に多いのが、承認（Approvals）の設計や手順のズレです。WSUSは「同期している更新」と「承認して配布対象にしている更新」を分けて考える必要があります。

• テストグループには承認したが、本番グループへの承認を忘れている
• 自動承認ルールが想定と違い、必要な分類（例：更新プログラム、セキュリティ更新、定義更新など）が漏れている
• 製品カテゴリの取りこぼし（例：OSは見ているが、.NETやEdgeなどが対象外になっている）
• 期限切れ/置き換え済み更新の扱いが整理されておらず、現場が迷子になっている

このタイプは、端末単体で頑張るよりも、承認運用の棚卸しが効きます。特に「テスト→本番」の承認フローがある場合、次のような“事故防止の型”に寄せると、99%が常態化しにくくなります。

運用の型	狙い	チェックポイント
承認はグループ単位で明確に分ける	誤承認/承認漏れを減らす	テスト承認→本番承認の手順が文書化されているか
「自動承認に任せる範囲」を決める	意図しない配布を防ぐ	自動承認は定義更新のみ、などルール化
承認前に“対象KBの影響範囲”を見る	配布事故を減らす	更新プログラム別レポートで失敗率/対象台数を確認

端末がスキャン/報告していない：WSUSは“報告が上がらない限り”変わらない

WSUSの表示は、端末が「検出（スキャン）」し、「状態をWSUSに報告」して初めて更新されます。つまり、端末が何らかの理由でスキャン/報告できていないと、実際には更新済みでもWSUS上は未適用に見えることがあります。

端末側で最低限確認したい項目を表にまとめます。

確認項目	見る場所	よくある問題
WSUSの参照先	GPO/レジストリ（WUServer等）	別のWSUSを見ている、ポリシー未適用
Windows Updateサービス	services.msc	停止/無効、依存サービス停止
疎通（ネットワーク）	プロキシ/FW/名前解決	HTTP/HTTPS遮断、名前解決不良
最終報告	WSUSの最終ステータス報告日時	何日も報告がない端末はまずここを直す

スキャン/報告を促すコマンドはOS世代で差があります。現場で使われがちなものを“目的別”に整理します（どれも管理者権限での実行が前提です）。

目的	例（コマンド）	注意点
ポリシー再適用	gpupdate /force	WSUS参照先の設定ズレがあるときの第一手
更新スキャン（新しめのOS）	usoclient StartScan	環境により挙動が異なる場合あり。実行後はログ/イベントで確認
更新ダウンロード/インストール（必要に応じて）	usoclient StartDownload usoclient StartInstall	サーバーではメンテ時間を確保して実施
古典的な検出/報告（古い手順として残っていることが多い）	wuauclt /detectnow wuauclt /reportnow	新しいOSでは効果が限定的な場合あり。効かないなら別手段へ
状態更新のきっかけ作り（汎用）	net stop wuauserv net start wuauserv	“報告が止まっている”疑いがある場合の簡易確認

大事なのは、コマンドを打って終わりではなく、WSUS側の表示が更新されるまで「スキャン→インストール→再起動→報告」のどこで止まっているかを追うことです。

WSUS側でできる改善：クリーンアップと承認設計の見直し

クライアント側を直しても、WSUS自体が肥大化していたり、置き換え済み更新が大量に残っていると、管理が難しくなり「未適用の特定」に時間がかかります。黄色い三角を“消しやすい状態”にするには、WSUS側の整備も重要です。

WSUSクリーンアップ（メンテ）で“不要なノイズ”を減らす

WSUSにはクリーンアップ（不要更新の整理、古いコンピューターの整理など）の考え方があり、定期的に手を入れると運用が安定します。実施内容の例と狙いをまとめます。

施策	狙い	注意点
置き換え済み更新の整理	対象が分かりやすくなり、誤対応が減る	運用ポリシーにより“いつ拒否するか”は要検討
期限切れ更新の整理	不要な更新が減り、検索や承認が速くなる	一部環境では例外があり得るため、急に大量整理しない
未使用コンピューターの整理	「古い端末がずっと99%」を見なくて済む	資産管理と整合を取り、誤削除を避ける
コンテンツ整合（必要に応じて）	ダウンロード不整合を減らす	時間がかかることがあるため計画的に

WSUSが“更新が多すぎて何が必要か分からない”状態になると、99%が増えます。クリーンアップの目的は、見た目を綺麗にすることではなく、未適用の特定を速くして、対応の質を上げることです。

承認（Approvals）運用を整えると、黄色い三角は減る

黄色い三角が頻発する組織は、端末の問題だけでなく、承認運用の設計が“現場の実態”に合っていないことが多いです。例えば次のような設計は、現実的に回りやすく、かつ未適用を減らしやすいです。

• グループ設計をシンプルに（テスト／本番／例外の3層から始め、増やしすぎない）
• 期限（Deadline）を使うなら、再起動ポリシーとセット（期限だけ設定して再起動が抑止されると、未適用が溜まる）
• 例外端末は“例外グループ”へ隔離（特殊用途・オフライン・検証機など）

これだけでも、「本番にだけ99%が残り続ける」現象が起きにくくなります。

“警告を隠す”という選択肢と、そのリスク

質問の中にある「警告（三角）を消したい」というニーズは理解できます。例えば、経営層向けにスクリーンショットを出す場面で“黄色があると印象が悪い”など、見た目を整えたい動機は現場でよく出ます。

ただし、WSUSの設計思想として、黄色い三角は「未適用が残っている」ことを気づかせるための表示です。これを非表示にする運用は、次のリスクが大きくなります。

隠した場合に起きやすいこと	なぜ危険か	代替案
未適用更新の見落とし	セキュリティ更新の欠落が長期化する	“例外グループ”として別枠で監視し、理由を記録する
失敗端末の放置	一度失敗すると繰り返し失敗し続けることがある	Failed端末だけを抽出する日次チェックを作る
数字だけ追って実態が悪化	運用が“表示合わせ”になり、根本改善が進まない	WSUS外で運用指標（期限超過端末数など）を設計する

もし「どうしても一覧で見せたくない」という事情がある場合は、アイコンを消すのではなく、例外端末を例外グループへ分けることで、日常の運用画面からノイズを減らすのが現実的です。見えなくするのではなく、“見る場所を分ける”発想にすると、安全性と業務都合の両立がしやすくなります。

どうしても100%に寄せられない端末の扱い：例外運用の作り方

現実の現場では、全端末を常に100%へ揃えるのが難しいケースもあります。たとえば次のような端末です。

• 製造装置など、アプリ/ドライバ制約で更新を止めている端末
• ネットワーク分離・オフライン運用で、更新適用が定期作業になっている端末
• 検証用・ラボ環境で、意図的に更新を固定している端末

この場合も、WSUSの表示を都合よく「OK」に変えることはできません。代わりに、例外として扱うルールを明確化し、監査や引き継ぎで困らない形にします。

例外運用で決めておくと良いこと	具体例	メリット
例外グループの定義	「装置系」「オフライン」「検証」など	通常運用と分離でき、黄色い三角が“ノイズ化”しにくい
例外理由と期限	「ベンダー未対応のため」「次回停止日に適用」など	属人化を防ぎ、放置が減る
代替の監視指標	期限超過端末数、Failed台数、最終報告が古い台数	“100%”に縛られず、リスクに基づく運用ができる

「黄色い三角を消す」ではなく、例外として管理し、必要なときに必ず拾える状態にするのが、長期的に安全で運用も回ります。

FAQ：WSUSの適用率・黄色い三角でよくある質問

適用率99%は“誤差”だから無視して良い？

無視はおすすめしません。99%は、WSUSが“要対応”と判定している更新が何かしら残っているサインです。まずはその1%（実体は数件）を特定し、再起動待ちなのか、失敗なのか、未報告なのかを切り分けてください。

更新を拒否（Decline）したのに、端末がNeededのままになることがあるのはなぜ？

端末の状態は、端末が再評価してWSUSに報告するまで更新されません。拒否の操作をした直後に表示が変わらないのは珍しくありません。スキャン/報告が止まっている端末だと、いつまでも古い状態のまま残ります。

黄色い三角はいつ消える？

基本的には、未適用扱い（Needed/Failed等）が解消され、端末が状態を再報告したタイミングで消えます。更新適用や再起動を行ったら、端末側のスキャンと報告もセットで考えてください。

まとめ：黄色い三角を消す最短ルートは「未適用の特定→解消」

WSUSのコンプライアンス率が100%未満で黄色い三角が出る状態は、WSUSの仕様として「未適用が残っている」ことを示すものです。閾値を90%に下げてOK扱いにする、といった設定変更はできません。また、表示を隠すことは画面運用で可能でも、未適用更新の見落としにつながるためおすすめしません。

現実的で安全な対処は、次の流れです。

• 対象端末でNeeded/Failedの更新（KB）を特定
• 再起動待ち／失敗／未報告など原因を切り分け
• 端末側のスキャン→報告まで含めて状態を更新
• 承認（Approvals）運用とWSUSメンテ（クリーンアップ）を整える

この手順を回せるようになると、適用率99%の“沼”から抜けやすくなり、WSUS運用の安定度も上がります。