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

IT, Windows11, WSUS

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

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

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

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

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

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

【実体験】Intune初日に感じた違和感

私が初めてIntuneを触ったとき、最初に探したのは「承認」ボタンだった。

WSUS管理コンソールでは毎週見ていた「更新プログラムの承認」画面。Intune管理センターを開いても、それらしいものが見つからない。

「承認しないと配信されないのでは？」と焦って、Microsoft Docsを読み漁った。そこで初めて知った。

Intuneには「承認」という概念が存在しない。

この事実を知ったとき、10年近くWSUSで培った運用方法が通用しないことを痛感した。

同じような戸惑いを感じる前に、5つの重要な違いを押さえておこう。

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

WSUSでの運用

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

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

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

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

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

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

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

実務上の影響

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

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

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

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

【失敗談】延期期間を0日にして後悔した話

移行初期、私は「延期期間0日」で設定してしまった。WSUSと同じ感覚で「承認するまで配信されない」と勘違いしていたからだ。

結果、Microsoftがリリースした直後の更新プログラムが即座に全端末に配信され、一部の端末で業務アプリが起動しなくなった。

その日の午後は全端末の状態確認と問題切り分けに追われた。最終的に、延期期間を7日に変更し、社内テスト端末で先行検証する運用に切り替えた。

教訓: 延期期間は最低でも3〜7日は設けるべき。

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

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

WSUSはWindows Server上で動作する。

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

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

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

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

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

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

実務上の影響

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

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

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

【体験談】WSUSサーバー廃止で得られた時間

私の環境では、WSUSサーバーの運用に月平均8時間を費やしていた。内訳は以下の通りだ。

  • ディスク容量監視: 月2時間
  • クリーンアップ作業: 月3時間
  • 同期エラー対応: 月2時間
  • 承認作業: 月1時間

Intuneに完全移行後、これらの作業がゼロになった。空いた時間でセキュリティポリシーの見直しやゼロトラストアーキテクチャの検討に時間を使えるようになった。

サーバー運用からの解放は、想像以上に大きかった。

違い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を使う方法で詳しく解説している。

【実践例】動的グループで運用を自動化する

WSUSでは、新しい端末が追加されるたびに手動でグループに振り分けていた。100台規模なら問題ないが、200台を超えると手間が無視できない。

Intuneの動的グループを使うと、以下のような自動振り分けが可能だ。

例1: Windows 11デバイスを自動グループ化

(device.deviceOSType -eq "Windows") -and (device.deviceOSVersion -startsWith "10.0.22")

例2: 部門別に自動グループ化

(device.department -eq "営業部")

この設定により、新しい端末がAzure ADに登録されると、条件に合致するグループに自動追加される。管理の手間が大幅に減った。

違い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移行の実務ガイドで解説している。

【失敗談】Patch Tuesday当日に回線がパンクした話

Intune移行直後のPatch Tuesday（毎月第2火曜日の更新プログラム公開日）、社内のインターネット回線が異常に遅くなった。

原因は、全200台の端末が一斉にMicrosoft Updateから更新プログラムをダウンロードしたこと。WSUSではサーバーがキャッシュしていたため問題なかったが、Intuneでは直接ダウンロードする。

回線速度100Mbpsの環境で、累積更新プログラム（約500MB）×200台=約100GB。これが一斉にダウンロードされた。

対策として実施したこと:

  1. 配信の最適化を有効化（ピアツーピアで社内LAN内共有）
  2. 更新リングを3つに分割（早朝組・午前組・午後組）
  3. 延期期間を段階的に設定（0日/3日/7日）

この設定により、次回以降は回線のパンクを回避できた。

違い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種類
運用工数 サーバー運用が必要 サーバー運用不要
インターネット接続 不要（社内LAN完結） 必須

よくある質問（FAQ）

Q1: WSUSの「承認」に相当する機能は本当にないのか？

A: 基本的にはない。ただし、以下の回避策がある。

  • Configuration Managerとの併用: より細かい制御が可能
  • Windows Update for Businessの「一時停止」機能: 最大35日間停止できる
  • 更新リングの段階的配信: テスト端末で先行検証後、本番展開

Q2: オンプレミスADの環境でもIntuneは使えるのか？

A: 使える。Azure AD ConnectでオンプレミスADとAzure ADを同期すれば、ハイブリッド構成で運用可能。詳しくはオンプレActive Directoryが残っている環境でIntuneを使う方法を参照。

Q3: WSUSとIntuneを併用する期間はどのくらい必要か？

A: 一般的には3〜6ヶ月。移行計画によって異なる。詳細はWSUSとIntuneの併用期間はどのくらい必要か？を参照。

Q4: Intuneだけで運用するのが不安。WSUSを残すべきか？

A: 以下のケースではWSUSを残す価値がある。

  • 完全オフライン環境の端末がある
  • 帯域幅に制約がある
  • 個別の更新プログラム承認が業務上必須

詳しくはWSUS残すべきケース vs 完全廃止できるケースの判断基準を参照。

Q5: Intuneの学習コストはどのくらいか？

A: WSUS経験者であれば、基本操作の習得に1〜2週間、実運用レベルで1〜2ヶ月が目安。Azure ADの知識がない場合は、さらに1ヶ月程度の学習期間を見ておくと良い。

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

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

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

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

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

まとめ: 次にやるべきこと

WSUS担当者がIntuneを触る前に押さえておくべき5つの概念の違いを解説した。

重要なポイント:

  1. 「承認」ではなく「延期期間」で管理する
  2. サーバー運用が不要になる代わりに、インターネット接続が必須
  3. Azure ADグループの理解が必須
  4. 配信経路が変わるため、帯域幅対策が重要
  5. 更新プログラムの分類が2種類に簡素化される

次のステップ:

  1. WSUSからIntuneへの移行ロードマップで全体像を把握する
  2. 検証環境でIntuneを触ってみる（Microsoft 365 E3/E5試用版でも可能）
  3. 社内のテスト端末10台程度で小規模運用を開始する
  4. 問題がなければ段階的に本番展開する

移行は一朝一夕にはいかない。焦らず、段階的に進めることが成功の鍵だ。

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