SCCM/ConfigMgrで「All Software Updates」には更新が出るのに、「Windows 10 Servicing → All Windows 10 Updates」が空で困るケースがあります。原因の多くはSUP/WSUSの“分類”設定です。機能更新プログラムを表示・配布できるように、最短で直す手順をまとめます。
起きている現象と、混乱しやすいポイント
ConfigMgr（SCCM）では、ソフトウェア更新の見え方が複数のノードに分かれています。そのため「同期自体はできているのに、目的の場所だけ空」という状況が起こりえます。
- Software Library → Software Updates → All Software Updates：月例更新（累積更新、品質更新、Defender定義など）を含む、いわゆる“通常の更新”が中心
- Software Library → Windows 10 Servicing → All Windows 10 Updates：Windows 10 の機能更新プログラム（Feature Update / OSアップグレード）が中心
ここで重要なのは、これらのノードが「同じ更新を違う見せ方で表示している」わけではない点です。裏側のWSUS分類（Classification）が違うため、設定次第で片方だけ空になります。
| ノード | 主に見えるもの | WSUS/ConfigMgr上の分類 | 代表例 | 用途 |
|---|---|---|---|---|
| All Software Updates | 品質更新・セキュリティ更新・定義更新など | Updates / Security Updates / Critical Updates など | Windows 10 の累積更新（LCU） | 月例運用、ADRでの自動展開 |
| All Windows 10 Updates | 機能更新（OSのバージョンアップ） | Upgrades | Feature update to Windows 10, version 22H2… | バージョン移行、段階展開 |
結論：空になる原因は「Upgrades（アップグレード）分類」が無効
「All Windows 10 Updates」に出てこない最大の原因は、SUP/WSUSで“Upgrades（アップグレード）”分類が選択されていないことです。
Windows 10 の機能更新プログラムは、月例パッチのような“更新（Updates）”ではなく、OSを別バージョンへ引き上げる“アップグレード（Upgrades）”として配信されます。そのため、Updates分類だけを有効にしても、機能更新のメタデータが同期されず、結果としてノードが空のままになります。
仕組みを理解すると迷わない：製品（Product）と分類（Classification）の役割
WSUS/SUPの同期は、ざっくり言うと「製品」と「分類」の掛け算で対象が決まります。
- 製品（Products）：Windows 10、Windows 10 version 1903 and later、Windows 11…など“どの製品の更新か”
- 分類（Classifications）：Updates、Security Updates、Definition Updates、Upgrades…など“どの種類の更新か”
つまり、Windows 10 製品を選んでいても、Upgrades分類が無効なら機能更新の行だけが丸ごと対象外になります。逆に、Upgradesを有効にしても製品側が未選択なら同様に出ません。
対処手順：ConfigMgr（Software Update Point）で Upgrades を有効化する
ConfigMgrでSUPを使っている場合、コンソール側で分類を有効化し、同期を回せば解消することがほとんどです。以下は現場で事故が少ない順序で整理した手順です。
事前確認：どのSUP設定が“有効”なのかを押さえる
- 複数SUPがある環境では、実際に同期しているSUP（上流/下流、アクティブな役割）をまず確認します。
- CAS/Primaryの構成、WSUSが別サーバーか同居かで、設定箇所が変わることがあります。
手順
- Administration → Site Configuration → Sites を開きます。
- 対象サイトを右クリック → Configure Site Components → Software Update Point を開きます。
- Classifications（分類） タブで Upgrades（アップグレード） にチェックを入れます。
- 必要に応じて Products（製品） タブで Windows 10 関連（例：Windows 10 / Windows 10, version 1903 and later）も確認します。
- 保存後、Software Library → Software Updates から Synchronize Software Updates を実行します。
| 操作 | 目的 | 失敗しやすい点 | チェック方法 |
|---|---|---|---|
| Upgrades分類を有効化 | 機能更新メタデータを同期対象に含める | UpdatesだけONで安心してしまう | SUPのClassifications画面 |
| 同期（Sync）を実行 | 設定変更を反映し、更新カタログを取得 | 同期完了前に「まだ空だ」と判断 | Monitoringの同期ステータス、wsyncmgr.log |
| 表示確認 | All Windows 10 Updatesに出現したか確認 | コンソールの検索条件/フィルタで見落とす | タイトルに「Feature update」を含めて検索 |
「フル同期が必要？」の判断基準
分類や製品の追加直後は、環境によって同期が長くなったり、一部のメタデータが揃うまで時間がかかったりします。まずは通常同期を待ち、同期がエラーなく完了していることを確認してください。
もし同期状態が「成功」にならない、またはログにカテゴリ取得失敗が見える場合は、WSUS側の健全性や上流接続を含めて確認します。
対処手順：WSUS単体で Upgrades を有効化する
ConfigMgrではなくWSUS単体運用、または「上流WSUSで分類が絞られている」構成の場合は、WSUS側でUpgradesを有効にしないと下流（SUP）に降りてきません。
- WSUSコンソールを開きます。
- Options → Products and Classifications を開きます。
- Classifications タブで Upgrades にチェックします。
- Products タブで Windows 10 の対象製品を確認します。
- 同期（Synchronizations）を実行し、完了を待ちます。
上流/下流がある場合、一番上流のWSUSでUpgradesが無効だと、下流はどう頑張っても取得できません。構成図を一度書き出して「どこで分類を絞っているか」を可視化すると早いです。
同期後の確認手順：どこを見れば“直った”と言い切れるか
「同期を押したけど、表示が増えたのか分からない」状態を避けるため、確認ポイントを具体化します。
コンソールでの確認
- Software Library → Windows 10 Servicing → All Windows 10 Updates に移動
- 検索ボックスで Feature update を入力（英語タイトルが多いため）
- フィルタで「Superseded（置き換え済み）」を非表示にしている場合は、一時的に解除して確認
ログでの確認（代表例）
サーバー側の代表的なログは以下です。環境で場所が異なることがありますが、困ったらまずこの2つを見ます。
- wsyncmgr.log：同期の進捗、カテゴリ/分類の処理状況
- WCM.log：SUPコンポーネント設定の反映、WSUS接続
例えば、Upgradesを有効化した直後は「同期対象カテゴリが追加された」旨の記録が出ることが多いです。逆に、HTTP/証明書/プロキシなどの通信問題があると、分類以前に同期が止まります。
それでも空のままのときに疑うこと（追加チェックリスト）
Upgradesを有効にして同期も回したのに出てこない場合、原因は“設定漏れ”より“同期できていない/見えていない”に寄ります。よくある順に並べます。
| 症状 | よくある原因 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| 同期が成功にならない | WSUS接続エラー、証明書、プロキシ、上流未同期 | wsyncmgr.log / WCM.log のエラー行 | 通信・証明書・上流WSUSの健全性を先に解決 |
| 同期は成功だが件数が増えない | 上流WSUSでUpgrades無効、製品未選択 | 上流のProducts/Classifications | 上流から順に設定を統一 |
| 一部だけ見える/期待より少ない | 言語や製品を絞りすぎ、同期タイミング未完了 | SUPのLanguages/Products設定 | 必要な範囲まで緩めて再同期 |
| 表示はあるが展開に失敗 | コンテンツ未配布、DP不足、境界/境界グループ | Deployment Status、Content Status | DP配布とクライアント到達性を確認 |
製品選択の落とし穴：Windows 10 の“世代”で製品名が変わる
現場で意外と多いのが、製品の選択が「Windows 10」だけになっており、Windows 10, version 1903 and later（など、より新しい枝）を選んでいないケースです。環境の対象バージョンに合わせて製品を見直してください。
ただし、製品を増やすほど同期対象が増えます。最小限にしたい場合は「実際に使う機能更新（例：22H2への移行）に必要な範囲だけ」に絞るのがコツです。
運用上の注意：Upgrades を有効化すると増える“負荷”と、その抑え方
Upgrades分類を有効にすると、同期するメタデータが増えます。環境によっては「同期時間が伸びた」「WSUS DBが膨らんだ」と感じることがあります。機能更新は1件あたりの情報量も大きいため、次の点を押さえると安定します。
- 不要な製品・言語を増やさない：WSUS/SUPは“選んだ分だけ”重くなります。
- 同期スケジュールを業務時間外に寄せる：初回や設定変更直後は特に時間がかかります。
- WSUSメンテナンス（クリーンアップ/インデックス）：長期運用では必須。同期が遅い・失敗しやすいときはまず疑う。
- コンテンツの置き場所を設計する：機能更新を展開するならDP容量、配布先WAN帯域も含めて考える。
「機能更新を扱う予定がない」ならUpgradesを無理に有効にし続ける必要はありません。逆に、いずれ移行するなら“見える状態”にしておくだけでも計画が立てやすくなります。
実践：機能更新（Feature Update）をConfigMgrで展開する基本の流れ
All Windows 10 Updatesに表示されるようになったら、次は配布です。機能更新は“月例パッチと同じ感覚”で進めると詰まることがあるので、流れを整理します。
手順の全体像
- All Windows 10 Updates で目的の「Feature update to Windows 10, version ○○」を見つける
- 対象を右クリックし、ダウンロード（Download）して更新パッケージを作成
- 配布ポイントへ配布（Distribute Content）
- コレクションへ展開（Deploy）し、段階的に適用
- 準拠状況（Compliance）と失敗要因を監視
月例更新との違い（ここを押さえると失敗が減る）
| 観点 | 月例更新（LCU等） | 機能更新（Feature Update） |
|---|---|---|
| 更新の性質 | 同一バージョン内の品質改善 | OSバージョンの移行（例：21H2→22H2） |
| サイズ/配布 | 比較的小さめ〜中 | 大きい（DP容量・帯域設計が重要） |
| 再起動/所要時間 | 短〜中 | 長くなりやすい（ユーザー体験に配慮） |
| 失敗時の影響 | パッチ未適用 | OS移行失敗（再試行や復旧設計が必要） |
展開方法の選び方：Servicing Plan とタスクシーケンス、どれを使う？
ConfigMgrでは機能更新を「ソフトウェア更新として展開」する以外にも、タスクシーケンスでインプレースアップグレードする方法があります。現場の要件で選び分けるのが現実的です。
| 方式 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Windows 10 Servicing（機能更新を更新として展開） | 標準的なPC群を段階的に上げたい | 比較的シンプル、準拠状況が追いやすい | 前提条件（空き容量など）で失敗しやすい |
| タスクシーケンス（インプレースアップグレード） | 事前/事後処理（アプリ制御、BIOS更新、暗号化制御）が必要 | 制御性が高い、細かい分岐が可能 | 設計・テスト工数が大きい |
| 段階的展開（Phased Deployment） | パイロット→本番へ安全に進めたい | 失敗時に止めやすい | コレクション設計が重要 |
よくある質問
「All Software Updates」にも機能更新は出ますか？
環境によっては検索で見つかることもありますが、基本的には機能更新はUpgrades分類のため、Windows 10 Servicing配下で探すほうが確実です。管理者が“更新の種類”を意識して運用できるようにノードが分かれています。
Upgradesを有効にするとWSUSに巨大なファイルが溜まりますか？
ConfigMgrと連携している場合、WSUSは主にメタデータ管理を担い、実際のコンテンツ配布はConfigMgrの仕組みで行うのが一般的です。ただし、WSUS側の設定や運用ポリシーによってはコンテンツを保持する構成もあり得ます。自環境のWSUS設定（更新ファイルの保存方針）を確認したうえで、ディスク設計を行ってください。
Windows 11でも同じ考え方ですか？
はい。Windows 11の機能更新も同様に“Upgrades”分類で扱われます。Windows 10/11を併用している環境では、製品の選択と分類の設計を整理しておくと、同期対象が増えすぎずに済みます。
以前は見えていたのに、急に空になりました
多いのは次のパターンです。
- SUP/WSUSの分類設定を見直した際に、Upgradesのチェックが外れた
- 上流WSUSの設定変更で、下流にUpgradesが降りなくなった
- WSUSの不調で同期が失敗している（成功に見えても更新が増えていない）
まずは設定差分と同期ログを確認し、Upgradesが“今も有効で、同期が完了している”状態を取り戻すのが近道です。
まとめ：空の原因は“分類”の違い。Upgradesを有効化して同期すれば解決する
「All Windows 10 Updates」が空でも、All Software Updatesに更新が並ぶなら、基本的なSUP動作はしている可能性が高いです。機能更新が見えない場合は、Upgrades（アップグレード）分類を有効化し、同期完了まで待ってから表示確認してください。
機能更新は“月例更新とは別物”です。見えるようになった後も、段階展開・ユーザー影響・配布容量を意識して設計すると、トラブルを大きく減らせます。
コメント