「Intuneに移行すれば、WSUSと同じことができる」は誤解
WSUS→Intune移行を検討しているIT担当者から、「IntuneはWSUSの完全な代替になりますか?」という質問をよく受ける。
結論から言うと、IntuneとWSUSは設計思想が異なるため、「同じこと」はできない。
ただし、Intuneには「WSUSではできなかったこと」もできる。
この記事では、Intuneでできること・できないことを、WSUS担当者向けに具体的に解説する。
移行を検討している方は、まずWSUS担当者がIntuneを触る前に知っておくべき概念の違い5つも併せて読んでほしい。
【実体験】Intune移行初日に驚いたこと
私がIntune移行プロジェクトを始めた初日、最も驚いたのは「WSUSでできていたことができない」というギャップだった。
具体的には:
- 更新プログラムの個別承認ができない
- 社内サーバーからの配信ができない
- オフライン環境での管理ができない
「これじゃあWSUSより不便じゃないか」と思ったのが正直なところだ。
しかし、使い込んでいくうちに、Intuneには「WSUSではできなかったこと」が山ほどあることに気づいた。
- リモートワーク端末をVPNなしで管理できる
- iOSやAndroidも一元管理できる
- アプリケーションの自動配信ができる
- コンプライアンスポリシーでセキュリティを強化できる
Intuneは「WSUSの代替」ではなく、「次世代の端末管理」だと理解できた瞬間だった。
Intuneでできること(WSUSではできなかったこと)
1. リモート端末の管理(VPN不要)
WSUSは社内ネットワークに接続している端末しか管理できない。リモートワーク端末を管理するには、VPN接続が必要だった。
Intuneはクラウドベースのため、インターネットに接続していれば、どこからでも管理できる。
- 自宅からのリモートワーク
- カフェや新幹線での移動中
- 海外出張中
これらのシーンでも、VPN接続なしでWindows Updateを配信できる。
【実践例】リモートワーク端末のWindows Update配信
私の会社では、コロナ禍以降、従業員の70%がリモートワークに移行した。
WSUS時代は、VPN接続が前提だったため、以下の問題があった:
- VPN帯域が逼迫して業務に支障
- VPN接続を忘れる社員が多く、更新が適用されない
- VPN経由での更新プログラム配信に時間がかかる
Intune移行後、VPN接続なしで自動的にWindows Updateが配信されるようになり、これらの問題が一気に解決した。
IT担当者として、「VPN接続してください」という催促メールを送る必要がなくなったのは、地味だが大きな改善だった。
2. Windows以外のデバイス管理(iOS、Android、macOS)
WSUSはWindowsのみ対応。
Intuneは以下のOSに対応:
- Windows 10/11
- iOS/iPadOS
- Android
- macOS
BYOD(私物端末の業務利用)環境でも、Intuneなら一元管理できる。
【実践例】営業部のiPad管理
営業部に配布していたiPad(50台)は、これまでApple Configuratorで手動管理していた。
新規導入や設定変更のたびに、iPadを回収して手動で設定するのは非常に手間だった。
Intuneに移行後、以下が可能になった:
- 遠隔からアプリケーションを自動配信
- セキュリティポリシー(パスコード要求、自動ロック時間)を一括設定
- 紛失時のリモートワイプ(データ消去)
管理工数が月10時間から2時間に削減された。
3. アプリケーション配信(Microsoft StoreアプリやWin32アプリ)
WSUSはWindows Updateの配信のみ。
Intuneは以下のアプリケーション配信に対応:
- Microsoft Storeアプリ(Office、Teams等)
- Win32アプリ(.exe、.msi)
- Webアプリ(リンクのみ配信)
- LOBアプリ(社内専用アプリ)
例えば、新入社員の端末に「Office 365」「Teams」「Adobe Acrobat Reader」を自動インストールすることが可能だ。
【実践例】新入社員の端末セットアップ自動化
これまで、新入社員の端末セットアップには以下の手順が必要だった:
- Windows初期設定
- Active Directoryに参加
- Office 365をインストール
- Teamsをインストール
- Adobe Acrobat Readerをインストール
- 社内VPNクライアントをインストール
- ウイルス対策ソフトをインストール
これを1台あたり1時間かけて手動で実施していた。年間20名の新入社員がいるため、年間20時間の工数だった。
Intune + Autopilotを使うことで、以下のように自動化できた:
- 端末を新入社員に配送
- 新入社員が初回起動時にAzure ADアカウントでログイン
- 自動的にAzure ADに参加
- Intuneポリシーが自動適用
- 必要なアプリケーションが自動インストール
IT担当者の介入なしで、新入社員が自分で端末をセットアップできるようになった。年間工数が20時間から0時間になった。
4. コンプライアンスポリシーによる条件付きアクセス
WSUSにはない機能として、「コンプライアンスポリシー」がある。
例えば:
- 「最新のWindows Updateが適用されていない端末は、社内システムにアクセスできない」
- 「ウイルス対策ソフトが無効な端末は、SharePointにアクセスできない」
- 「脱獄(Jailbreak)されたiPhoneは、社内メールにアクセスできない」
このように、セキュリティ要件を満たさない端末を自動的にブロックできる。
【実践例】Windows Update未適用端末のアクセス制限
以前、ある社員が「Windows Updateが面倒」という理由で、半年間更新を無効にしていた。
その端末がマルウェアに感染し、社内システムに不正アクセスの痕跡が残った。幸い情報漏洩には至らなかったが、対応に丸一日かかった。
Intuneのコンプライアンスポリシーを導入後、以下のルールを設定した:
- Windows Updateが30日以上未適用の端末は、SharePoint・OneDriveへのアクセスをブロック
- ウイルス対策ソフトのリアルタイム保護が無効な端末は、社内メールへのアクセスをブロック
この設定により、社員は自然と更新を適用するようになった。IT部門が催促する必要もなくなった。
5. 自動登録(Autopilot)
WSUSでは、新規端末のActive Directory参加は手動で行う必要があった。
IntuneのAutopilot機能を使えば、端末が初回起動時に自動的にAzure ADに参加し、必要なアプリケーションやポリシーが自動適用される。
新入社員や拠点増設時の端末セットアップ工数を大幅に削減できる。
【実践例】Autopilotで拠点増設の工数を90%削減
地方拠点を新設した際、30台の端末をセットアップする必要があった。
WSUS時代は、以下の手順が必要だった:
- 本社でIT担当者が端末を開封
- Active Directoryに参加
- WSUSグループに登録
- 必要なアプリケーションをインストール
- 梱包して拠点に配送
これを30台分実施するのに、丸3日かかった。
Autopilot導入後は、以下のように変わった:
- メーカーから拠点に直送
- 拠点の社員が初回起動時にAzure ADアカウントでログイン
- 自動的にAzure ADに参加し、アプリケーションが自動インストール
IT担当者の介入時間は、シリアル番号の事前登録(30分)のみ。工数を90%削減できた。
Intuneでできないこと(WSUSならできたこと)
1. 更新プログラムの個別承認
WSUSでは、更新プログラムを1つずつ確認して承認できた。
Intuneは基本的に自動配信で、個別の更新プログラムを「この更新だけ拒否」といった細かい制御はできない。
ただし、以下の制御は可能:
- 品質更新プログラム(月例パッチ)の延期期間設定(0〜30日)
- 機能更新プログラム(大型アップデート)の延期期間設定(0〜365日)
- 特定のバージョン(例: Windows 11 24H2)への固定
「この更新プログラムだけは適用しない」という運用は、Intuneでは難しい。
【失敗談】問題のある更新プログラムを止められなかった話
2024年10月、Microsoftがリリースした品質更新プログラム(KB5006670)で、一部の業務アプリが起動しなくなる問題が報告された。
WSUS時代であれば、「この更新だけ承認しない」という対応ができた。
しかし、Intuneでは個別の更新プログラムを拒否できない。対応策として、以下を実施した:
- 品質更新プログラムの延期期間を7日から14日に延長
- Microsoftが修正版をリリースするまで待つ
- 一部の端末で問題が発生した場合は、手動でアンインストール
結局、Microsoftが修正版を10日後にリリースしたため、大きな問題にはならなかった。
教訓: Intuneでは「延期期間」を適切に設定し、問題のある更新プログラムを回避する猶予を作ることが重要。
2. 社内サーバーからの配信(帯域節約)
WSUSは社内サーバーから配信するため、インターネット帯域を消費しない。
Intuneはインターネット経由でMicrosoftから直接ダウンロードするため、帯域が不足すると遅延が発生する。
対策:
- 配信の最適化(Delivery Optimization)を有効にして、社内ピアツーピアでキャッシュ共有
- 帯域制限を設定(例: 営業時間中は1Mbps、夜間は無制限)
完全にインターネット経由を避けることはできないが、工夫次第で帯域消費を抑えられる。
【実践例】Delivery Optimizationで帯域問題を解決
Intune移行直後、Patch Tuesday当日にインターネット回線が異常に遅くなった。全200台の端末が一斉にMicrosoft Updateから累積更新プログラム(約500MB)をダウンロードしたためだ。
対策として、Delivery Optimizationを有効にした。
設定手順:
- Intune管理センター → デバイス → Windows → 構成プロファイル
- 「作成」→「新しいポリシー」→「Windows 10以降」→「テンプレート」→「配信の最適化」
- 「ダウンロードモード」を「HTTPとLANピアリング(1)」に設定
- 対象グループに「すべてのWindowsデバイス」を設定
この設定により、1台目がMicrosoftからダウンロードした後、残りの199台は社内LAN経由でその端末から取得するようになった。
次回のPatch Tuesdayでは、インターネット帯域の消費が約90%削減された。
3. オフライン環境での管理
WSUSは社内ネットワーク内で完結するため、インターネット接続がなくても管理できた(WSUSサーバー自体はインターネット接続が必要)。
Intuneはクラウドベースなので、端末がインターネットに接続していないと管理できない。
完全なオフライン環境(例: 工場の製造ライン端末)では、Intuneは使えない。
【実例】工場の製造ライン端末はWSUSを継続
私の会社には、工場の製造ライン端末が50台ある。これらはセキュリティ上の理由でインターネットに接続できない。
Intuneに移行できないため、これらの端末はWSUSで管理を継続している。
ハイブリッド運用(Intune + WSUS)で、それぞれの強みを活かした管理ができている。
詳しくはIntune移行後もWSUSを残すべきケースと、完全廃止できるケースの判断基準を参照してほしい。
4. 詳細なレポート機能
WSUSは以下のレポート機能が充実していた:
- 更新プログラムごとのインストール状況
- コンピューターごとの更新状況
- 承認済み・未承認の更新プログラムリスト
Intuneにもレポート機能はあるが、WSUSほど詳細ではない。
ただし、Microsoft 365管理センターやAzure ADのレポート機能と組み合わせることで、より広範な情報を取得できる。
IntuneとWSUSの機能比較表
| 機能 | WSUS | Intune |
|---|---|---|
| Windows Update配信 | ◯ | ◯ |
| 更新プログラムの個別承認 | ◯ | △(延期設定のみ) |
| リモート端末管理(VPN不要) | ✕ | ◯ |
| iOS/Android管理 | ✕ | ◯ |
| アプリケーション配信 | ✕ | ◯ |
| 社内サーバーからの配信 | ◯ | △(Delivery Optimization) |
| オフライン環境対応 | ◯ | ✕ |
| コンプライアンスポリシー | ✕ | ◯ |
| 自動登録(Autopilot) | ✕ | ◯ |
| 詳細レポート | ◯ | △ |
| サーバー運用工数 | 高い | 低い |
| ライセンスコスト | 無料(Windows Server CAL込み) | 有料(Microsoft 365 E3/E5など) |
Intuneに向いている組織・WSUSを残すべき組織
Intuneに向いている組織
- リモートワークが多い
- 複数拠点に端末が分散している
- iOS/Androidも管理したい
- クラウドファーストで運用したい
- IT担当者の工数を削減したい
- セキュリティポリシーを厳格に適用したい
WSUSを残すべき組織
- 完全にオフライン環境で運用している
- インターネット帯域が極端に狭い
- 更新プログラムを1つずつ確認してから適用したい
- クラウドサービスの利用が制限されている(規制業界など)
- Microsoft 365のライセンスコストが予算オーバー
「ハイブリッド運用」という選択肢
IntuneとWSUSは、必ずしもどちらか一方を選ぶ必要はない。
以下のようなハイブリッド運用も可能だ:
- リモート端末:Intuneで管理
- 社内固定端末:WSUSで管理
- 工場・製造ライン端末:WSUSで管理
- 営業部のiPad:Intuneで管理
詳しくはIntune移行後もWSUSを残すべきケースと、完全廃止できるケースの判断基準を参照してほしい。
Intune移行で「できなくなること」への対処法
対処法1: 更新プログラムの個別承認 → 延期期間で代替
個別承認はできないが、延期期間(0〜30日)を設定することで、検証期間を確保できる。
例えば:
- テストグループ:延期0日(すぐに適用)
- 営業部:延期7日(1週間後に適用)
- 全社展開:延期14日(2週間後に適用)
対処法2: 社内サーバーからの配信 → Delivery Optimizationで代替
完全に社内サーバーから配信することはできないが、Delivery Optimizationを有効にすることで、社内ピアツーピアでキャッシュ共有できる。
設定方法:
- Intune管理センター → デバイス → Windows → 構成プロファイル
- 「配信の最適化」を設定
- 「ダウンロードモード」を「HTTPとLANピアリング」に設定
対処法3: 詳細レポート → Microsoft 365管理センターと組み合わせ
Intune単体ではレポート機能が弱いが、Microsoft 365管理センターやAzure ADのレポート機能と組み合わせることで、より詳細な情報を取得できる。
よくある質問(FAQ)
Q1: IntuneとWSUS、どちらを選ぶべきか?
A: 以下の質問で判断できる。
- リモートワーク端末が多い → Intune
- iOS/Androidも管理したい → Intune
- 完全オフライン環境 → WSUS
- 個別の更新プログラム承認が必須 → WSUS
Q2: Intuneの導入コストはどのくらいか?
A: Microsoft 365 E3ライセンス(月額約3,000円/ユーザー)が必要。Intune単体ライセンス(約1,000円/ユーザー)もある。詳しくはIntune移行にかかる費用と工数の現実を参照。
Q3: Intune移行にかかる期間はどのくらいか?
A: 端末台数と既存環境による。100台規模で3〜6ヶ月が目安。詳しくはWSUSからIntuneへの移行ロードマップを参照。
Q4: Intuneでドライバー更新は配信できるか?
A: Windows Update経由でドライバー更新を配信できる。ただし、メーカー独自のドライバーは、Win32アプリとして配信する必要がある。
Q5: WSUS廃止後もWSUSサーバーは残すべきか?
A: 完全移行後は不要。ただし、ロールバックに備えて1〜3ヶ月は残しておくと安心。
ケーススタディ: 中小企業(従業員200名)のIntune移行事例
移行前の課題
- WSUSサーバーの運用工数が月8時間
- リモートワーク端末(70台)がVPN経由でしか更新できない
- 営業部のiPad(50台)が手動管理で工数がかかる
移行後の成果
- WSUSサーバー運用工数が0時間に
- リモートワーク端末がVPNなしで自動更新
- iPad管理工数が月10時間から2時間に削減
- コンプライアンスポリシーでセキュリティ強化
移行期間・コスト
- 期間: 4ヶ月
- 工数: IT担当者2名で80時間
- ライセンスコスト: Microsoft 365 E3(既存ライセンスに含まれていたため追加コストなし)
詳しくは中小企業がIntuneを導入してWSUSを廃止するまでの実録——3ヶ月の移行記録を参照してほしい。
まとめ:Intuneは「WSUSの代替」ではなく「次世代の端末管理」
IntuneとWSUSを比較すると、以下のことが分かる。
- Intuneでできること:リモート管理、マルチOS対応、アプリ配信、コンプライアンスポリシー、Autopilot
- Intuneでできないこと:更新プログラムの個別承認、完全なオフライン運用、WSUSレベルの詳細レポート
Intuneは「WSUSの代替」ではなく、「次世代の端末管理」だ。
WSUSの機能をそのまま置き換えるのではなく、Intuneの強みを活かした運用設計が必要だ。
次のステップ:
- WSUSからIntuneへの移行ロードマップで全体像を把握する
- WSUS担当者がIntuneを触る前に知っておくべき概念の違い5つで基礎知識を押さえる
- 検証環境でIntuneを触ってみる(Microsoft 365 E3/E5試用版でも可能)
- WSUS残すべきケース vs 完全廃止できるケースの判断基準で自社の方針を決定する
移行は一朝一夕にはいかない。焦らず、段階的に進めることが成功の鍵だ。
※免責事項: 本記事の内容は一般的な情報提供を目的としており、特定の環境における動作を保証するものではありません。実際の運用はMicrosoft公式ドキュメントを確認の上、検証環境でテストしてから実施してください。
