この記事は、生成AIを活用した自動生成フローで作成しています。
Windows Autopatchとは？M365 E3/E5で更新運用を段階化する仕組み
この記事について
Microsoft公式情報を2026年9月18日時点で確認し、Windows Autopatchの利用条件、Intuneとの関係、段階展開を初心者向けに整理しています。検証ステータス：📘 Microsoft公式情報確認済み・実機未確認
Windows Autopatchは、Windows、Microsoft 365 Apps、Microsoft Edge、Microsoft Teamsなどの更新を、Microsoft Intuneを中心に管理・段階展開するクラウドサービスです。
「Windows Updateそのものを別製品へ置き換える」のではなく、どの端末へ・どの順番で・いつ更新を届け、失敗端末をどう把握するかを標準化する仕組みと考えると分かりやすくなります。
最初に覚えたい用語
| 用語 | 初心者向けの意味 |
|---|---|
| update ring | 更新を届けるタイミングが異なる端末グループ |
| quality update | 毎月のセキュリティ修正などを含む更新 |
| feature update | Windowsのバージョンを更新する大きな機能更新 |
| deferral | 更新開始を一定日数遅らせる設定 |
| deadline | 更新を完了させる期限 |
| grace period | deadline後に利用者へ与える猶予期間 |
| co-management | Configuration ManagerとIntuneでWindows管理を分担する構成 |
| Hotpatch | 一部のセキュリティ更新を再起動回数を抑えて適用する仕組み |
E3/E5の利用資格
Microsoft公式の2026年2月26日更新の前提条件では、Windows Autopatchは次のライセンス群を対象にしています。
Microsoft 365 Business Premium
Windows 10/11 Education A3/A5
Windows 10/11 Enterprise E3/E5（Microsoft 365 F3/E3/E5に含まれるものを含む）
Windows 10/11 Enterprise E3/E5 VDA
つまり、Microsoft 365 E3/E5はいずれもAutopatchの対象になり得ます。ただしライセンスだけでは利用開始できず、Entra ID、Intune、端末登録、ネットワークなどの前提条件があります。
Autopatchの全体像
flowchart LR
A[管理者 / Intune] --> G[Autopatch Group]
G --> T[Test Ring]
G --> R1[Ring 1]
G --> L[Last Ring]
T --> U[Windows Update Service]
R1 --> U
L --> U
U --> D[管理対象Windows端末]
D --> REP[更新状態 / Alert / Report]
REP --> A
最初の少数端末へ先行配信し、問題がなければ後続リングへ広げることで、全端末が同時に問題を受けるリスクを下げます。
前提条件を確認する
代表的な要件は次のとおりです。
Microsoft Entra ID P1/P2とMicrosoft Intune。
対象端末がIntuneへ登録済み。
corporate-owned端末。BYODはAutopatch登録の前提チェックでブロックされる。
IntuneまたはConfiguration Managerとのco-managementで管理されている。
Configuration Managerのみで管理している端末は対象外。
端末が最近Intuneと通信している。
Microsoftサービスの必要endpointへ通信できる。
対応するWindows edition/buildを利用している。
LTSC端末は登録可能なケースがありますが、Autopatchが管理するworkloadに制約があり、通常のfeature updateを同じようには扱いません。
まず試す：変更せず状態を見る
Microsoft Intune admin centerでWindows updates / Windows Autopatch周辺を開き、次だけを確認します。
登録端末数。
Autopatch groupとdeployment ring。
Quality update / Feature updateの状態。
失敗・保留・Not up to date端末。
ここを見る
対象端末数が資産台帳と大きくずれていないか。
Testなど先行リングに適切な検証端末がいるか。
更新失敗が特定機種・拠点・アプリ利用者へ偏っていないか。
端末がIntuneへ長期間チェックインしていない状態ではないか。
成功の目安
任意の1台について「どのAutopatch group / ringに所属し、どの更新がどの状態か」を説明できることです。
1か所変える
本番ポリシーを変えず、レポートの表示フィルターだけをFailedやNot up to dateへ変更します。問題端末を安全に絞り込む練習になります。
段階展開はどう動くか
sequenceDiagram
participant M as Microsoft/Autopatch
participant T as Test端末
participant R as Ring 1端末
participant L as Last端末
M->>T: 更新を先行配信
T-->>M: 成功/失敗シグナル
M->>R: 次のリングへ展開
R-->>M: 状態報告
M->>L: 後続へ展開
Autopatch groupではdeployment ringごとにUpdate Ring policyが作られ、deferral、deadline、grace periodなどを使って段階的に展開します。
Microsoftはfeature updateについて、より安全に展開するためcustom Windows feature update releaseの利用を推奨しています。進行中に最低versionを不用意に変更すると、group全体へ即時rolloutが始まる場合があるため注意します。
実務例：基幹アプリ利用PCを最後にする
たとえば全社500台で、会計ソフトの互換性が重要な場合です。
Test: 情シスの数台。
Ring 1: ITに詳しい協力ユーザー。
中間ring: 一般事務PC。
Last: 月末処理など影響が大きい重要端末。
ただしLastを「永久に更新しないグループ」にしてはいけません。段階展開は問題発見の時間差を作るためであり、セキュリティ更新を無期限延期する仕組みではありません。
Hotpatchは別途前提を確認する
Hotpatchは再起動負担を減らせる場合がありますが、対応ライセンスだけでなく、Windows 11 24H2以降、対象edition/architecture、baseline、Intuneポリシーなど個別要件があります。Autopatchを使えることと、全端末でHotpatchを使えることは同義ではありません。
一般利用者・事務職・情シスの確認点
| 立場 | 確認すること |
|---|---|
| 一般利用者 | 再起動通知、deadline、業務時間への影響 |
| 事務職 | 月末・締め日・繁忙期と更新スケジュールの衝突 |
| 情シス | Intune登録、ring、update policy、alert、例外、互換性、Hotpatch |
管理者が確認する項目
対象ライセンスがAutopatch要件を満たすか。
Entra ID P1/P2とIntuneが利用できるか。
対象端末がcorporate-ownedか。
Intune enrollmentが正常か。
co-managementならWindows Update/Device configuration workloadの担当が適切か。
必要なMicrosoft endpointへの通信が許可されているか。
Test ringに実際の業務アプリを検証できる端末があるか。
deadlineやgrace periodを長くしすぎていないか。
Feature updateをcustom releaseで段階展開するか。
Hotpatch対象端末の個別前提を満たすか。
よくある誤解
「Autopatchを有効にすればMicrosoftへ全部丸投げできる」
端末・アプリ・業務都合を知るのは組織側です。ring設計、例外判断、障害対応は引き続き必要です。
「E3/E5があればIntune登録していないPCも自動管理される」
AutopatchにはIntune enrollmentなどのインフラ要件があります。
「Last ringなら更新しなくてよい」
Lastは後段で安全性を高めるためのリングです。恒久的な未更新端末を作る目的ではありません。
Microsoft公式情報
Windows Autopatchは、Intuneを土台に、少数検証 → 段階展開 → 状態監視 → 問題対応を繰り返しやすくする更新運用の仕組みです。
