「WSUSからIntuneに移行したけど、あのポリシーはどこで設定するんだ？」
WSUS管理者がIntune移行後に最初に戸惑うのが、この問題だ。私も最初のIntune移行プロジェクトで、設定場所が分からず3時間も画面を彷徨った経験がある。
WSUSではグループポリシーでWindows Updateの動作を細かく設定できたが、Intuneでは管理画面の構成がまったく異なる。「あの設定はどこ？」「この機能はIntuneにあるの？」と混乱するのは、誰もが通る道だ。
本記事では、WSUSで使っていたWindows Updateポリシーが、Intuneのどこに対応するのかを、設定項目別に詳しく解説する。実際の移行作業で迷わないよう、具体的な設定手順とよくある失敗事例も含めて説明する。
WSUSではグループポリシー（GPO）でWindows Updateの設定を管理していた。慣れ親しんだgpmc.mscを開いて、「コンピューターの構成」→「管理用テンプレート」と辿っていく、あのUIだ。
Intuneでは、MDM（Mobile Device Management）ポリシーを使う。これは「Windows Update for Business」と呼ばれる仕組みで、従来のグループポリシーとは根本的にアプローチが異なる。
設定場所は：
Intune管理センター（endpoint.microsoft.com）
→ デバイス
→ Windows
→ Windows 10以降の更新リング
ここで「更新リング」を作成し、Windows Updateのポリシーを設定する。更新リングとは、要するに「どの端末グループに、どういう更新ポリシーを適用するか」を定義するものだ。
WSUSに慣れていると、「更新プログラムを一つひとつ承認する」という作業が当たり前だった。毎月第2火曜日にMicrosoftから更新プログラムがリリースされると、WSUS管理コンソールで「このKBは承認、このKBは様子見」と判断していた。
Intuneにはその概念がない。「延期期間」を設定すると、あとは自動でインストールされる。最初は「え、これで本当に大丈夫なの？」と不安だったが、運用してみると圧倒的に楽だった。
WSUSでの設定（グループポリシー）：
コンピューターの構成 → 管理用テンプレート → Windowsコンポーネント → Windows Update → 自動更新を構成する
Intuneでの設定：
更新リング → 品質更新プログラムの延期期間
WSUSでは「自動ダウンロードして通知」「自動ダウンロードしてスケジュールインストール」などを選べたが、Intuneでは「延期期間」を設定する。
例えば、「品質更新プログラムを7日延期する」と設定すると、Microsoftがリリースした更新プログラムが7日後に自動でインストールされる。
設定手順：
私の失敗談：最初の移行プロジェクトで、延期期間を「0日」に設定してしまい、リリース直後の更新プログラムが全社に配信された。結果、既知の不具合があるKBで一部のPCが起動しなくなり、緊急対応に追われた。延期期間は最低でも7日は設定すべきだ。
WSUSでの設定：
自動更新を構成する → スケジュールインストール日: 毎日、曜日指定など
Intuneでの設定：
更新リング → アクティブ時間 + 再起動の猶予期間
Intuneでは「アクティブ時間」を設定することで、業務時間中の再起動を防げる。
例えば、アクティブ時間を「8:00〜18:00」に設定すると、この時間帯は再起動が行われず、18:00以降に再起動される。
設定手順：
注意点：アクティブ時間は最大18時間まで設定できる。それ以上の時間を指定すると、「再起動のタイミングがない」という状態になり、更新プログラムが適用されなくなる。
WSUSでの設定：
Windows Update → 機能更新プログラムの遅延期間を選択する
Intuneでの設定：
更新リング → 機能更新プログラムの延期期間
Intuneでは最大365日まで延期できる。
例えば、「機能更新プログラムを180日延期する」と設定すると、Windows 11 23H2がリリースされても、半年間は適用されない。
私の推奨設定：
私の経験上、機能更新プログラムは初期不具合が多い。Windows 11 22H2も、リリース直後は印刷不具合やネットワーク接続問題が報告されていた。90日程度延期すれば、そうした不具合が修正された後に適用できる。
WSUSでの設定：
Windows Update → Windows Update でドライバーを含めない
Intuneでの設定：
更新リング → ドライバーの更新 → 除外
Intuneでは、ドライバーを「含める」「除外する」のいずれかを選べる。
業務PCでドライバー更新による不具合を避けたい場合は、「除外する」を選ぶ。
実際の失敗事例：ある製造業の企業で、ドライバー更新を「含める」に設定していたところ、特定のプリンタードライバーが自動更新されて印刷できなくなった。製造ラインの帳票が印刷できず、半日の生産停止に繋がった。業務PCでは基本的にドライバー更新は除外すべきだ。
WSUSでの設定：
Windows Update → スケジュールされた自動更新のインストールで、ログオン中のユーザーに対して自動的に再起動しない
Intuneでの設定：
更新リング → 再起動の猶予期間
Intuneでは、再起動の猶予期間を1〜14日の範囲で設定できる。
例えば、猶予期間を7日に設定すると、更新プログラムのインストール後、7日以内にユーザーが手動で再起動すればOK。7日経過後は強制再起動される。
私の推奨：営業職や外勤が多い企業では、猶予期間を「7日」に設定するのが適切。デスクワーク中心なら「3日」でも問題ない。
WSUSでの設定：
自動更新を構成する → スケジュールインストール時刻: 03:00など
Intuneでの設定：
更新リング → 自動再起動の期限 + アクティブ時間
Intuneでは、「アクティブ時間外に自動再起動する」という動作になる。特定の時刻を指定することはできないが、アクティブ時間を適切に設定すれば、実質的に同じ効果が得られる。
例えば、「アクティブ時間: 8:00〜18:00」「自動再起動の期限: 3日」と設定すると、3日以内に18:00以降の時間帯で自動再起動される。
WSUSでの設定：
イントラネットのMicrosoft更新サービスの場所を指定する → http://wsusserver:8530
Intuneでの設定：
設定不要（自動的にMicrosoft Updateサービスに接続）
Intuneでは、クライアントPCがインターネット経由でMicrosoft Updateサービスに直接接続する。WSUSサーバーの指定は不要。
オフライン環境では利用できないため、工場や研究施設などインターネット接続が禁止されている環境では、WSUSを継続する必要がある。
WSUSでは「KB5012345は承認するが、KB5012346は除外する」という個別管理ができた。
Intuneではできない。すべての品質更新プログラムを一律に扱う。
ただし、「品質更新プログラムの一時停止」機能を使えば、問題のある更新プログラムが配信された場合に、全体を一時停止できる。
対処法：
WSUSではクライアントがWSUSサーバーから更新プログラムをダウンロードしていた。これにより、インターネット帯域を節約できた。
Intuneでは、クライアントがインターネット経由でMicrosoft Update サービスからダウンロードする。
オフライン環境では利用できない。
対処法：
配信の最適化の設定：
Intune管理センター → デバイス → Windows → 構成プロファイル → 配信の最適化 → 「ダウンロードモード: LAN」を設定
WSUSでは「どのPCにどのKBがインストールされたか」を詳細に確認できた。
Intuneのレポート機能は、WSUSほど詳細ではない。「更新プログラムの適用状況」はグラフで確認できるが、KBごとの適用状況は見づらい。
対処法：
WSUSではVPN接続が必要だったが、Intuneではインターネットに接続していれば管理できる。
リモートワーク中の端末も、自動でWindows Updateが適用される。
実体験：コロナ禍でリモートワークに移行した際、WSUSではVPN接続時しか更新プログラムが配信されず、セキュリティリスクが高まっていた。Intuneに移行したことで、在宅勤務の社員も自動でパッチが適用され、セキュリティレベルが向上した。
Intune + Azure Log Analyticsを連携させることで、「Windows Update for Business レポート」が利用できる。
これにより、更新プログラムの適用状況、エラー発生率、遵守状況などを可視化できる。
有効化手順：
有効化後、24〜48時間でデータが表示される。
Intuneは、Windows Autopilot（PCの自動セットアップ機能）と連携できる。
新しいPCを配布する際、ユーザーが自分でセットアップし、自動でIntuneに登録される。
導入効果：私が担当した企業では、新入社員のPC配布作業が1台あたり2時間から30分に短縮された。IT部門の作業負荷が大幅に削減された。
複数の更新リングを作成する場合、GUIで一つひとつ設定するのは面倒だ。PowerShellを使えば、一括設定できる。
前提：Microsoft.Graph.Intune モジュールをインストール
Install-Module Microsoft.Graph.Intune -Force Connect-MSGraph
更新リングの作成スクリプト：
$updateRing = @{
"@odata.type" = "#microsoft.graph.windowsUpdateForBusinessConfiguration"
displayName = "標準更新ポリシー"
qualityUpdatesDeferralPeriodInDays = 7
featureUpdatesDeferralPeriodInDays = 90
deliveryOptimizationMode = "httpWithPeeringNat"
driversExcluded = $true
businessReadyUpdatesOnly = "all"
automaticUpdateMode = "autoInstallAtMaintenanceTime"
}
$uri = "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations"
Invoke-MSGraphRequest -HttpMethod POST -Url $uri -Content $updateRing
このスクリプトを使えば、品質更新プログラム7日延期、機能更新プログラム90日延期、ドライバー除外の設定が一括で適用できる。
アクティブ時間を設定していないと、業務時間中に再起動が発生する。
症状：営業会議中に社長のPCが再起動し、プレゼン資料が消えた。
対処法：
更新リング → アクティブ時間を「8:00〜18:00」に設定する。
延期期間を長く設定すると、セキュリティパッチの適用が遅れる。
症状：ゼロデイ脆弱性が公開されてから1ヶ月後に適用されるため、攻撃リスクが高まる。
対処法：
品質更新プログラムの延期期間は、7日以内にする。機能更新プログラムは30〜90日程度が適切。
ドライバー更新を含めると、業務PCで不具合が発生するリスクがある。
症状：グラフィックドライバーが自動更新され、社内システムの画面が正しく表示されなくなった。
対処法：
更新リング → ドライバーの更新 → 除外する。
オンプレActive Directoryのグループポリシーと、IntuneのMDMポリシーが両方適用されている場合、競合が発生する。
症状：Intuneの更新リングを設定したのに、Windows Updateが実行されない。
対処法：
MDM優先レジストリ：
HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update ControlPolicyConflict = 1
更新リングの割り当てグループを誤ると、意図しないPCに更新プログラムが配信される。
症状：テスト用の更新リングを全社PCに割り当ててしまい、リリース直後の不具合のある更新プログラムが全社に配信された。
対処法：
更新リングの作成時に、必ず割り当てグループを確認する。テスト環境・本番環境で別々の更新リングを作成する。
WSUSからIntuneに一気に移行するのではなく、段階的に移行することを推奨する。私が実際に200台規模の企業で実施した移行手順を紹介する。
10台程度のテストグループを作成し、Intuneの更新リングを適用する。
作業内容：
確認ポイント：
問題がなければ、第1グループ（30〜50台）に展開する。
作業内容：
第1グループで問題がなければ、全社に展開する。
作業内容：
全端末がIntuneで管理されるようになったら、WSUSサーバーを廃止する。
作業内容：
合計期間：5ヶ月
クライアントPCで、Intuneの更新ポリシーが正しく適用されているか確認するコマンド：
Get-MpComputerStatus | Select-Object ComputerState, AntivirusEnabled, RealTimeProtectionEnabled
Intuneのポリシーを即座に同期させるコマンド：
Get-ScheduledTask | Where-Object {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask
過去にインストールされた更新プログラムの一覧を取得：
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
デバイスがIntuneに正しく登録されているか確認：
dsregcmd /status
出力結果で「MDMUrl」が表示されていればOK。
Intuneの更新リングを設定したのに、Windows Updateが実行されない場合、以下を確認する：
□ デバイスがIntuneに登録されているか（dsregcmd /status で確認）
□ 更新リングが正しいグループに割り当てられているか
□ グループポリシーと競合していないか
□ アクティブ時間が適切に設定されているか（18時間以内）
□ デバイスがインターネットに接続されているか
□ Windows Updateサービスが起動しているか（services.msc で確認）
□ ファイアウォールでMicrosoft Updateサービスへの接続がブロックされていないか
WSUSで使っていたWindows Updateポリシーは、ほとんどIntuneの「Windows 10以降の更新リング」で設定できる。
主な対応：
Intuneでは特定のKBを個別に承認・除外できないが、運用工数が大幅に削減できる。私の経験では、月次のパッチ適用作業が「4時間」から「30分」に短縮された。
移行の成功ポイント：
Intune移行は最初は戸惑うが、慣れればWSUSよりもはるかに楽だ。リモートワーク端末の管理、運用工数の削減、Autopilotとの連携など、メリットは大きい。
この記事で紹介した設定項目の対応表とトラブルシューティング方法を参考に、段階的な移行を進めてほしい。
IT管理者としてクラウド管理のスキルを磨きたいなら、レバテックキャリアでIntune・Azure経験者向けの求人をチェックしてみよう。Intuneの実務経験は、転職市場で年収600万円〜800万円の求人に繋がる貴重なスキルだ。