SCCM（Configuration Manager）＋Intuneのco-managementへ移行した後、品質更新やドライバー更新は入るのに、一部端末だけWindows 10 1909のままで「2004 機能更新」が表示されない――そんな現象の多くはSafeguard Hold（互換性保留）が原因です。確認方法と対処を実務目線で解説します。
まず押さえる：起きている現象を正しく言語化する
問い合わせでよくあるのが「Intuneで更新を管理しているはずなのに、特定端末だけ機能更新が降ってこない」というパターンです。ここで重要なのは、“品質更新（CU）は入る”のに“機能更新（Feature Update）だけが出ない”という差分です。これは、配信経路の不備よりも、端末固有の互換性判定で止まっている可能性が高いサインになります。
| 更新の種類 | 代表例 | 目的 | 「出る／出ない」の切り分けに効くポイント |
|---|---|---|---|
| 機能更新（Feature Update） | Windows 10, version 2004 | OSバージョンの更新（大きい） | 互換性問題があるとSafeguard Holdで“そもそも提示されない”ことがある |
| 品質更新（Quality Update / CU） | 2020-xx 累積更新プログラム | セキュリティ／不具合修正（小さい） | 互換性保留の影響を受けにくく、機能更新だけ止まるときに正常に入りがち |
| ドライバー更新 | オーディオ／GPU／NICドライバー | ハードウェア制御の更新 | ドライバー自体が保留原因のこともある（更新でHold解除に繋がる） |
つまり「CUもドライバーも入るのに、2004だけ来ない」は、WUfB（Windows Update for Business）やIntuneの配信が壊れているというより、“2004をその端末に出してはいけない”という判定が働いている可能性が高い、という読みになります。
co-management移行後に“更新の見え方”が変わる理由
co-managementでは、同じWindows 10端末でも「どのワークロードをどちらが管理するか」によって、更新の挙動が変わります。特に影響が大きいのがWindows Updateの管理（Windows Update policies）です。
- Configuration Manager（SCCM）側で管理：SUP/WSUS（またはMicrosoft Update）を使った配信。承認や展開スケジュールを細かく制御できる。
- Intune側で管理：基本はWUfBのポリシー（更新リング／機能更新ポリシー）で制御。端末はWindows Updateサービスと通信し、Microsoftの段階的ロールアウトやSafeguard Holdの影響を受ける。
移行直後に混乱しやすいポイントを、実務でよく見る形にまとめます。
| 観点 | SCCM中心 | Intune（WUfB）中心 |
|---|---|---|
| 機能更新の“提示” | 管理者が展開すれば基本的に提示される | Microsoft側の提供可否（段階配信・Safeguard Hold）に左右される |
| 更新の制御方法 | 展開・期限・メンテナンスウィンドウなど | リング（延期/一時停止/再起動体験）＋機能更新ポリシー（バージョン固定など） |
| “更新が来ない”時の見方 | SCCMクライアント・WSUS・境界/証明書など | Safeguard Hold／ポリシー競合（WSUS/GPO）／ネットワーク到達性 |
今回のように「ログ上もIntune管理に見える」「CUは入る」場合、まずは端末がWindows Updateと正常に通信できている可能性が高いので、次に疑うべきは端末固有のブロックです。
結論に直結：Safeguard Hold（互換性保留／安全策のブロック）とは
Safeguard Holdは、Microsoftが既知の互換性問題を検知した構成に対して、機能更新を“意図的に提示しない”仕組みです。端末側から見ると「更新が来ない」ように見えますが、実際は来ないのではなく、止められている状態です。
Safeguard Holdが効いているときの“典型パターン”は次のとおりです。
- 特定のバージョン（例：1909）から、特定の機能更新（例：2004）だけが出ない
- 品質更新（CU）は通常どおり入る
- 同一リングの別端末では機能更新が提示される
- ISO/メディアでの互換性チェックでは“致命的なブロッカーが見えない”こともある（ただし実際の問題はドライバーや特定アプリ）
現場メモ：Safeguard Holdは「アップグレード開始後に失敗する」タイプではなく、そもそも機能更新が提示されないタイプのため、SetupDiagやWindows10アップグレードログを追っても“材料が出てこない”ことが多いです。最初からHoldの有無を確認した方が早く解けます。
Safeguard Holdを可視化して“更新が来ない理由”を端末単位で特定する
対処を最短にするコツは、「なぜ来ないのか」を端末単位で見える化することです。ここで役に立つのがUpdate Compliance（更新コンプライアンス）や、IntuneのWindows Update for Businessレポートです。
確認手段の比較
| 方法 | 強み | 弱み | おすすめ度 |
|---|---|---|---|
| Update Compliance（Log Analytics） | Safeguard Holdの有無や理由を端末ごとに追える | 初期セットアップが必要（診断データ、ワークスペース連携など） | 高 |
| IntuneのWUfBレポート | 管理者が普段使う画面で状況を把握しやすい | 詳細理由まで深掘りできないケースがある | 中 |
| 端末のWindows Update画面 | ユーザー端末だけで確認できる | “それっぽいメッセージ”止まりで、原因特定に届かない | 中 |
| イベントログ／WindowsUpdateClientログ | 通信やスキャン状況の切り分けに使える | Holdの理由そのものは掴みにくい | 中 |
Update Complianceで見るべきポイント
Update Complianceを使う目的はシンプルで、「機能更新が適用可能なのに未適用」なのか、「適用可能と判定されていない（Hold）」のかを切り分けることです。運用上は、次のような情報が見えると強いです。
- 対象端末の現在バージョン（1909など）
- 機能更新の提供状況（Offer/Not Offered）
- Safeguard Holdの有無
- Holdの理由（特定ドライバー／特定アプリ等の互換性）
この「Hold理由」まで追えると、SCCMクライアント修復や再インストールのような“更新経路の治療”に時間を溶かさず、原因コンポーネントの更新に直行できます。
事例で理解：Conexant ISST Audioが原因で2004が保留されるパターン
実際によくあるのが、特定のオーディオドライバーやストレージ/グラフィックス関連ドライバーが原因で、Microsoftが機能更新をブロックするケースです。代表例の一つがConexant ISST Audioです。
このパターンでは、端末にConexant系のオーディオドライバーが入っていることがトリガーとなり、Windows 10 2004へのアップグレードがSafeguard Holdで保留されます。結果として、Intune経由でいくら更新を見に行っても、2004が“提示されない”状態になります。
Conexant系ドライバーが入っているかを確認する
ユーザーに負担をかけずに確認するなら、まずは端末側で次を見ます。
- デバイスマネージャー → 「サウンド、ビデオ、およびゲーム コントローラー」
- 対象デバイスのプロパティ → 「ドライバー」タブ（プロバイダー名、バージョン）
- アプリ一覧（「Conexant」「ISST」「SmartAudio」などの名称がないか）
管理者がリモートで確認する場合は、PowerShellでPnPデバイスやドライバー情報を棚卸しし、Conexant関連が含まれていないかを確認します。
pnputil /enum-drivers | findstr /i "conexant"
wmic sounddev get name,manufacturer
基本方針：原因コンポーネントの更新／置き換え／削除
Safeguard Holdは“安全策”なので、原則は原因が解消され、Holdが解除されるのを待つのが最も安全です。とはいえ業務都合で急ぐこともあるため、実務での選択肢を優先度順に整理します。
| 優先度 | 対処 | 狙い | 注意点 |
|---|---|---|---|
| 高 | OEM/ベンダー提供の最新オーディオドライバーへ更新 | 互換性問題を解消し、Hold解除を促す | 同型番でもモデル/世代でドライバーが異なる場合がある |
| 中 | Windows Updateの「オプションの更新」やドライバー更新で置き換え | 既知問題の回避版に差し替える | ベンダー提供版より古い/合わないこともある |
| 中 | 該当ドライバーのアンインストール（可能ならドライバー削除）→汎用ドライバーにフォールバック | Holdトリガーを外す | 音が出ない等の影響が出る可能性。検証端末で段階実施 |
ポイントは、“2004が出ない”という症状に対して、OS側の設定より先にドライバー側を疑うことです。ドライバー更新が完了すると、端末が次回スキャンで2004を提示されるケースがあります（ただし判定反映にはタイムラグが出ることがあります）。
Safeguard Hold以外に見落としやすい原因
Holdが最有力とはいえ、現場では複数要因が重なることもあります。次のチェックリストは、Holdと並行して潰しておくと“迷子”になりにくい項目です。
設定・ポリシーの競合チェック
| チェック項目 | よくある状態 | 確認場所 | 対処の方向性 |
|---|---|---|---|
| 機能更新の延期/一時停止 | 延期日数が大きい／Pauseが残っている | Intune更新リング、端末のWindows Update詳細オプション | リング設定を見直す（特にパイロットと本番で差がないか） |
| バージョン固定（Target Release） | 1909固定ポリシーが残っている | GPO/MDMポリシー、レジストリ（WindowsUpdateポリシー） | 固定を解除する／目標バージョンを更新する |
| WSUSポリシーの残骸 | WUServerが設定され、クラウドWUへ行けない | GPO、レジストリ（WUServer/WIStatusServer） | co-management方針に合わせてWSUS設定を整理する |
| ネットワーク到達性 | プロキシ/SSL検査でWindows Update通信が不安定 | プロキシログ、WindowsUpdateClientイベントログ | 許可リスト・TLS・プロキシ例外を見直す |
co-managementの“思い込み”を外す
「co-managementにした＝更新は全部Intune」という認識になりがちですが、実際はワークロードの切り替え状態（Pilot/Intune/SCCM）が大きく影響します。次は現場での鉄板確認です。
- Configuration Managerコンソールで、対象コレクションが更新ワークロードの切り替え対象になっているか
- 端末側のWindows Update画面で「組織によって管理されています」等の表記が出ているか
- 同じリングにいる“正常端末”と“問題端末”で、適用されているポリシーが一致しているか
ポリシーが一致しているのに機能更新だけ差が出るなら、やはり端末固有（Hold）の可能性が上がる、という順番で考えると合理的です。
推奨のトラブルシュート手順（最短ルート）
ここからは、実際に手を動かす順番を“やることが増えすぎない”形でまとめます。1台の問題端末で手順を確立し、同型番に横展開するのがコツです。
- 症状の固定化：同一リングの別端末では2004が提示されること、問題端末では提示されないことを確認する
- 更新経路の確認：端末がWUfB（Intune管理）でスキャンしていることを確認する（Windows Update画面、イベントログ）
- Safeguard Holdの確認：Update ComplianceやレポートでHoldの有無・理由を確認する
- 原因コンポーネントの対処：ドライバー/アプリを更新・削除・置き換え（Conexant系ならまずここ）
- 再スキャンと経過観察：ポリシー適用とスキャンを回し、提示状況を確認する（判定反映にタイムラグが出ることがある）
- 横展開：同一要因の端末へ同じ対処を適用し、Hold解除→提示の再現性を確認する
特に3番を飛ばすと、SCCMクライアント修復やSoftwareDistributionのリセットなど“効きにくい施策”を延々回しがちです。機能更新が出ない問題では、Hold確認が最短距離になりやすいです。
例外対応：Safeguard Holdを無効化して強制アップグレードする前に
業務要件で「どうしても今すぐ2004に上げたい」という相談は必ず出ます。ただし、Safeguard Holdは“実害が起きる確率が高い”構成を守る仕組みでもあるため、本番一括での無効化は基本的に非推奨です。まずは、次の条件を満たした検証端末1台で評価してください。
| 確認観点 | 最低ライン | 理由 |
|---|---|---|
| 戻し方（ロールバック） | 復旧手順と期限を把握している | 音が出ない、BSODなどが起きた場合に業務影響を最小化する |
| 原因候補の対処 | ドライバー更新などを先に試している | “Holdを踏み抜く”前に、正攻法で解ける可能性が高い |
| 対象範囲 | パイロット（少数）に限定 | 互換性問題は端末単位で顕在化するため、影響範囲を限定する |
無効化は、グループポリシーやMDM（Intune）設定で「Safeguard Holdを無効化」する形が一般的です。実装方法はいくつかありますが、概念としては「WUfBのSafeguardを無視して機能更新を提示させる」動きになります。
（検証用の例）Safeguard Hold無効化のレジストリ設定
HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate
DisableWUfBSafeguards (DWORD) = 1
ただし、無効化してもすべてのブロックを突破できるわけではありません。また、Conexant系のように“実際に不具合が起きる”既知問題が背景にある場合、アップグレード後に音が出ない等のトラブルが起きる可能性があります。検証で問題が出た場合は、無効化を拡大せず、ドライバー更新やベンダー対応を優先してください。
運用のコツ：同じトラブルを繰り返さないために
co-management＋Intuneで機能更新を安定配信するには、“更新ポリシー”と“端末互換性（ドライバー/アプリ）”を別物として管理するのがポイントです。最後に、再発防止に効く実務的な施策をまとめます。
- Update Complianceやレポートを常設：機能更新の停滞端末を早期検知し、「Holdなのか設定なのか」を即判定できる状態にする
- ハードウェアモデル別にパイロットを設計：型番・世代によってHold要因が変わるため、部署別よりも機種別の方がトラブルを拾いやすい
- ドライバーの基準化：特に音声・GPU・ストレージはHold要因になりやすい。OEMの推奨版を定期的に棚卸しする
- GPO/WSUSの整理：SCCM時代のWSUSポリシーが残ると、WUfBとの競合で“更新が来ない”別の問題を生む
- 段階展開＋戻し手順の整備：機能更新は一定確率で例外が出るため、ロールバック手順を含めて運用設計する
よくある質問
品質更新が入っているなら、機能更新も同じ経路で来るはずでは？
WUfBでは、品質更新と機能更新で“提示の条件”が異なります。機能更新は互換性の影響を強く受け、Safeguard Holdがかかると提示そのものが止まるため、品質更新だけが先に進む状況が起こり得ます。
ISOで互換性チェックは通ったのに、なぜHoldになる？
メディアのチェックは有用ですが、Microsoftがテレメトリや既知問題から判断するHoldは、より細かい条件（特定ドライバーの特定バージョンなど）に基づくことがあります。そのため、ISOチェックで“重大問題なし”でも、WU側では“提供保留”となることがあります。
SCCMクライアントの修復・再インストールは意味がない？
更新経路が壊れている場合には有効ですが、今回のような“機能更新だけ提示されない”症状では、原因がSafeguard Holdや互換性問題であることが多く、優先度は高くありません。まずHoldの有無を確認し、原因コンポーネントに当たる方が解決が早いです。
コメント