WSUS担当者がIntuneを触る前に知っておくべき概念の違い5つ

※本記事は2026年3月時点の一般的な情報です。実際の運用はMicrosoft公式ドキュメントを確認の上、検証環境でテストしてから実施してください。

「Intuneって、結局WSUSのクラウド版でしょ？」

そう思っているWSUS管理者は多い。かつての私もそうだった。

しかし、これは大きな誤解だ。IntuneとWSUSは、同じ「Windows Updateの管理」という目的を持つが、根本的な設計思想が異なる。

この記事では、WSUS担当者がIntuneを触る前に知っておくべき5つの概念の違いを解説する。事前に知っておけば、「なんでこれができないんだ？」という戸惑いを避けられる。

移行の全体像についてはWSUSからIntuneへの移行ロードマップを参照してほしい。

違い1: 「承認」の概念がない

WSUSでの運用

WSUSでは、管理者が更新プログラムを「承認」することで、初めてクライアントに配信される。

承認したものだけがインストールされる
承認しなければ、永遠にインストールされない
コンピューターグループごとに承認を分けられる

「この更新は問題があるから承認しない」という運用ができた。これはWSUS管理者にとって当たり前の機能だった。

Intuneでは延期期間を設定する

Intuneには「承認」という概念が存在しない。代わりに、延期期間（Deferral）を設定する。

Microsoftがリリースした更新プログラムは、延期期間後に自動的に配信される
個別の更新プログラムを承認・拒否することはできない（基本的に）
「配信を止める」のではなく「配信を遅らせる」という発想

例えば、「品質更新プログラムをリリースから7日後に配信」と設定すると、すべての品質更新が7日遅れで自動配信される。

実務上の影響

WSUSのように「この更新プログラムだけ承認しない」という運用はできない。

問題のある更新プログラムが出た場合、以下のいずれかの対応が必要だ。

延期期間を延ばして、Microsoft側の修正を待つ
一時的に更新ポリシーを無効化する
Configuration Managerと併用する

この点は、WSUS管理者にとって最も戸惑うポイントかもしれない。

違い2: 「サーバー」がない

WSUSはオンプレミスサーバー

WSUSはWindows Server上で動作する。

Windows Serverにインストール
データベース（WID or SQL Server）が必要
ディスク容量が肥大化する
定期的なクリーンアップが必須

「また容量不足のアラートか」と、サーバーの面倒を見るのに疲れた経験はないだろうか。

Intuneは完全なクラウドサービス

Intuneは完全なクラウドサービス（SaaS）だ。

サーバーの構築・運用が不要
ディスク容量を気にする必要がない
クリーンアップ作業が不要
アップデートは自動

サーバー運用から解放されるのは大きなメリットだ。

実務上の影響

サーバー運用の工数は削減されるが、以下の点に注意が必要だ。

インターネット接続が必須（社内ネットワークだけでは動かない）
クラウドサービスのため、障害時に自社では対処できない
オンプレミスのような「ローカルキャッシュサーバー」的な使い方はできない

完全オフライン環境では使えないため、要件によってはWSUSを残す必要がある。詳しくはWSUS残すべきケース vs 完全廃止できるケースの判断基準を参照してほしい。

違い3: 「コンピューターグループ」ではなく「Azure ADグループ」

WSUSのコンピューターグループ

WSUS管理コンソールで「コンピューターグループ」を作成し、端末を手動または自動で割り当てる。

WSUSサーバー側でグループ管理
グループポリシーでクライアント側から自己申告も可能
WSUSの中だけで完結

IntuneはAzure ADグループを使う

Azure AD（最近はMicrosoft Entra IDと呼ばれる）のグループを使う。

Azure AD管理センターでグループ作成
ユーザーグループまたはデバイスグループ
動的グループ（条件に応じて自動メンバー追加）も可能

例えば、「OSバージョンがWindows 11のデバイスを自動的にグループに追加」といった設定ができる。

実務上の影響

グループ管理の場所が変わるため、以下の対応が必要だ。

Azure AD管理センターの操作を習得
既存のWSUSコンピューターグループをAzure ADグループに再作成
グループポリシーベースの自己申告グループは使えない

オンプレミスADとの統合についてはオンプレActive Directoryが残っている環境でIntuneを使う方法で詳しく解説している。

違い4: 配信経路が異なる

WSUSの配信経路

WSUSサーバーがMicrosoft Updateから更新プログラムをダウンロードし、クライアントはWSUSサーバーから取得する。

Microsoft Update → WSUSサーバー → クライアントPC

社内ネットワークだけで完結できる。これがWSUSの大きなメリットだった。

Intuneの配信経路

Intuneは「ポリシーのみ」を配信し、実際の更新プログラムはクライアントが直接Microsoft Updateから取得する。

Intune（ポリシー配信） → クライアントPC ← Microsoft Update（更新プログラム）

クライアントPCはインターネット接続が必須だ。

実務上の影響

帯域幅の問題が発生する可能性がある。全端末が一斉にMicrosoft Updateからダウンロードすると、インターネット回線が圧迫される。

対策として、以下を活用する。

配信の最適化（Delivery Optimization）: ピアツーピアで社内LAN内で共有
BranchCache: 拠点間でキャッシュを共有
段階的配信: 更新リングを複数作成して時間差で配信

具体的な設定方法はWSUS→Intune移行の実務ガイドで解説している。

違い5: 更新プログラムの分類が異なる

WSUSの詳細な分類

WSUSでは更新プログラムを以下のように細かく分類できる。

重要な更新
セキュリティ更新
更新プログラムのロールアップ
Service Pack
ツール
ドライバー
機能更新プログラム

それぞれ個別に承認・拒否できた。

Intuneは2種類のみ

Intuneでは更新プログラムは大きく2種類に分類される。

品質更新プログラム: セキュリティ更新、累積更新など（月次）
機能更新プログラム: 22H2、23H2などのバージョンアップ

この2種類に対して、それぞれ延期期間を設定する形になる。

実務上の影響

WSUSほど細かい制御はできない。

例えば、「セキュリティ更新だけ即座に配信、その他の更新は7日延期」といった運用は基本的にできない。

詳しい設定方法についてはWSUSで管理していたWindows Updateポリシー、Intuneではどこで設定するのかを参照してほしい。

比較表でまとめると

項目	WSUS	Intune
承認	手動承認	延期期間で自動配信
サーバー	オンプレミス	クラウド（SaaS）
グループ	コンピューターグループ	Azure ADグループ
配信経路	WSUS経由	直接Microsoft Update
分類	細かく分類可能	品質/機能の2種類

IntuneはWSUSの代替ではなく「別物」

ここまで読んで、「Intuneって不便じゃない？」と思った人もいるかもしれない。

しかし、IntuneはWSUSの代替ではなく、モダンな管理手法への移行と捉えるべきだ。

WSUS的な細かい制御を求めるなら、Configuration Managerとの併用も検討する価値がある。完全にIntuneだけで運用する必要はない。

詳しくは「IntuneはWSUSの代替ではない」——移行前に誤解を解いておくを参照してほしい。

※免責事項: 本記事の内容は一般的な情報提供を目的としており、特定の環境における動作を保証するものではありません。実際の運用はMicrosoft公式ドキュメントを確認の上、検証環境でテストしてから実施してください。