※本記事は2026年3月時点の一般的な情報です。実際の運用はMicrosoft公式ドキュメントを確認の上、検証環境でテストしてから実施してください。
「Intuneって、結局WSUSのクラウド版でしょ？」
そう思っているWSUS管理者は多い。かつての私もそうだった。
しかし、これは大きな誤解だ。IntuneとWSUSは、同じ「Windows Updateの管理」という目的を持つが、根本的な設計思想が異なる。
この記事では、WSUS担当者がIntuneを触る前に知っておくべき5つの概念の違いを解説する。事前に知っておけば、「なんでこれができないんだ？」という戸惑いを避けられる。
移行の全体像についてはWSUSからIntuneへの移行ロードマップを参照してほしい。
私が初めてIntuneを触ったとき、最初に探したのは「承認」ボタンだった。
WSUS管理コンソールでは毎週見ていた「更新プログラムの承認」画面。Intune管理センターを開いても、それらしいものが見つからない。
「承認しないと配信されないのでは？」と焦って、Microsoft Docsを読み漁った。そこで初めて知った。
Intuneには「承認」という概念が存在しない。
この事実を知ったとき、10年近くWSUSで培った運用方法が通用しないことを痛感した。
同じような戸惑いを感じる前に、5つの重要な違いを押さえておこう。
WSUSでは、管理者が更新プログラムを「承認」することで、初めてクライアントに配信される。
「この更新は問題があるから承認しない」という運用ができた。これはWSUS管理者にとって当たり前の機能だった。
Intuneには「承認」という概念が存在しない。代わりに、延期期間（Deferral）を設定する。
例えば、「品質更新プログラムをリリースから7日後に配信」と設定すると、すべての品質更新が7日遅れで自動配信される。
WSUSのように「この更新プログラムだけ承認しない」という運用はできない。
問題のある更新プログラムが出た場合、以下のいずれかの対応が必要だ。
この点は、WSUS管理者にとって最も戸惑うポイントかもしれない。
移行初期、私は「延期期間0日」で設定してしまった。WSUSと同じ感覚で「承認するまで配信されない」と勘違いしていたからだ。
結果、Microsoftがリリースした直後の更新プログラムが即座に全端末に配信され、一部の端末で業務アプリが起動しなくなった。
その日の午後は全端末の状態確認と問題切り分けに追われた。最終的に、延期期間を7日に変更し、社内テスト端末で先行検証する運用に切り替えた。
教訓: 延期期間は最低でも3〜7日は設けるべき。
WSUSはWindows Server上で動作する。
「また容量不足のアラートか」と、サーバーの面倒を見るのに疲れた経験はないだろうか。
Intuneは完全なクラウドサービス（SaaS）だ。
サーバー運用から解放されるのは大きなメリットだ。
サーバー運用の工数は削減されるが、以下の点に注意が必要だ。
完全オフライン環境では使えないため、要件によってはWSUSを残す必要がある。詳しくはWSUS残すべきケース vs 完全廃止できるケースの判断基準を参照してほしい。
私の環境では、WSUSサーバーの運用に月平均8時間を費やしていた。内訳は以下の通りだ。
Intuneに完全移行後、これらの作業がゼロになった。空いた時間でセキュリティポリシーの見直しやゼロトラストアーキテクチャの検討に時間を使えるようになった。
サーバー運用からの解放は、想像以上に大きかった。
WSUS管理コンソールで「コンピューターグループ」を作成し、端末を手動または自動で割り当てる。
Azure AD（最近はMicrosoft Entra IDと呼ばれる）のグループを使う。
例えば、「OSバージョンがWindows 11のデバイスを自動的にグループに追加」といった設定ができる。
グループ管理の場所が変わるため、以下の対応が必要だ。
オンプレミスADとの統合についてはオンプレActive Directoryが残っている環境でIntuneを使う方法で詳しく解説している。
WSUSでは、新しい端末が追加されるたびに手動でグループに振り分けていた。100台規模なら問題ないが、200台を超えると手間が無視できない。
Intuneの動的グループを使うと、以下のような自動振り分けが可能だ。
例1: Windows 11デバイスを自動グループ化
(device.deviceOSType -eq "Windows") -and (device.deviceOSVersion -startsWith "10.0.22")
例2: 部門別に自動グループ化
(device.department -eq "営業部")
この設定により、新しい端末がAzure ADに登録されると、条件に合致するグループに自動追加される。管理の手間が大幅に減った。
WSUSサーバーがMicrosoft Updateから更新プログラムをダウンロードし、クライアントはWSUSサーバーから取得する。
Microsoft Update → WSUSサーバー → クライアントPC
社内ネットワークだけで完結できる。これがWSUSの大きなメリットだった。
Intuneは「ポリシーのみ」を配信し、実際の更新プログラムはクライアントが直接Microsoft Updateから取得する。
Intune（ポリシー配信） → クライアントPC ← Microsoft Update（更新プログラム）
クライアントPCはインターネット接続が必須だ。
帯域幅の問題が発生する可能性がある。全端末が一斉にMicrosoft Updateからダウンロードすると、インターネット回線が圧迫される。
対策として、以下を活用する。
具体的な設定方法はWSUS→Intune移行の実務ガイドで解説している。
Intune移行直後のPatch Tuesday（毎月第2火曜日の更新プログラム公開日）、社内のインターネット回線が異常に遅くなった。
原因は、全200台の端末が一斉にMicrosoft Updateから更新プログラムをダウンロードしたこと。WSUSではサーバーがキャッシュしていたため問題なかったが、Intuneでは直接ダウンロードする。
回線速度100Mbpsの環境で、累積更新プログラム（約500MB）×200台=約100GB。これが一斉にダウンロードされた。
対策として実施したこと:
この設定により、次回以降は回線のパンクを回避できた。
WSUSでは更新プログラムを以下のように細かく分類できる。
それぞれ個別に承認・拒否できた。
Intuneでは更新プログラムは大きく2種類に分類される。
この2種類に対して、それぞれ延期期間を設定する形になる。
WSUSほど細かい制御はできない。
例えば、「セキュリティ更新だけ即座に配信、その他の更新は7日延期」といった運用は基本的にできない。
詳しい設定方法についてはWSUSで管理していたWindows Updateポリシー、Intuneではどこで設定するのかを参照してほしい。
| 項目 | WSUS | Intune |
|---|---|---|
| 承認 | 手動承認 | 延期期間で自動配信 |
| サーバー | オンプレミス | クラウド（SaaS） |
| グループ | コンピューターグループ | Azure ADグループ |
| 配信経路 | WSUS経由 | 直接Microsoft Update |
| 分類 | 細かく分類可能 | 品質/機能の2種類 |
| 運用工数 | サーバー運用が必要 | サーバー運用不要 |
| インターネット接続 | 不要（社内LAN完結） | 必須 |
A: 基本的にはない。ただし、以下の回避策がある。
A: 使える。Azure AD ConnectでオンプレミスADとAzure ADを同期すれば、ハイブリッド構成で運用可能。詳しくはオンプレActive Directoryが残っている環境でIntuneを使う方法を参照。
A: 一般的には3〜6ヶ月。移行計画によって異なる。詳細はWSUSとIntuneの併用期間はどのくらい必要か？を参照。
A: 以下のケースではWSUSを残す価値がある。
詳しくはWSUS残すべきケース vs 完全廃止できるケースの判断基準を参照。
A: WSUS経験者であれば、基本操作の習得に1〜2週間、実運用レベルで1〜2ヶ月が目安。Azure ADの知識がない場合は、さらに1ヶ月程度の学習期間を見ておくと良い。
ここまで読んで、「Intuneって不便じゃない？」と思った人もいるかもしれない。
しかし、IntuneはWSUSの代替ではなく、モダンな管理手法への移行と捉えるべきだ。
WSUS的な細かい制御を求めるなら、Configuration Managerとの併用も検討する価値がある。完全にIntuneだけで運用する必要はない。
詳しくは「IntuneはWSUSの代替ではない」——移行前に誤解を解いておくを参照してほしい。
WSUS担当者がIntuneを触る前に押さえておくべき5つの概念の違いを解説した。
重要なポイント:
次のステップ:
移行は一朝一夕にはいかない。焦らず、段階的に進めることが成功の鍵だ。
※免責事項: 本記事の内容は一般的な情報提供を目的としており、特定の環境における動作を保証するものではありません。実際の運用はMicrosoft公式ドキュメントを確認の上、検証環境でテストしてから実施してください。