はじめに
Windows Update for Business（WUfB）はリング設計で段階展開を制御します。
最小構成は「パイロット→限定展開→全社（定常）」の3層。
さらに延期（deferral）・一時停止（pause）・期限（deadline）・迅速化（expedite）を組み合わせ、安全性と速度のバランスを取ります。
本稿は、Intune/グルポリのいずれでも応用できる実務の型を解説します。
基本の3リング（推奨比率）
- パイロット（5%）：代表機種・主要業務アプリを含め、更新の“地雷”を早期検知。
- 限定展開（20〜30%）：部門横断で分散。
想定外の相互作用（ドライバー・VPN・セキュリティ製品）を洗い出す。 - 全社（残り）：安定確認後に自動拡大。夜間の自動再起動ウィンドウで適用。
品質更新と機能更新でリングを分ける理由
- 品質更新は小粒で頻度高。延期は短く（7〜14日）、期限を有効にして停滞を防止。
- 機能更新は大粒で互換影響大。延期90〜120日とし、パイロットの滞在期間を長めに確保。
延期・一時停止・期限の使い分け
- 延期（Deferral）：通常運転の“遅らせ”。検証時間の確保が目的。
- 一時停止（Pause）：問題が見つかった際の緊急ブレーキ。
最長35日を想定して運用手順に明記。 - 期限（Deadline）：ユーザー再起動の先送りを抑止し、停止端末の山積みを防ぐ。
勤務時間・通知文面の見直しとセットで。
迅速化（Expedite）の活用
ゼロデイや重要脆弱性で通常リングを待てない場合、Expedite政策で既存の延期/一時停止を一時的に無視し、対象KBの即時適用を指示します。
手順は通常ポリシーと独立させ、適用後は速やかに撤回するのが安全です。
ガバナンス設計
- 責務分担：ポリシー変更権限、停止・再開の決裁ライン、通知テンプレを明文化。
- 変更管理：リング配分・延期値の変更はチケット起票と差分ログで管理。
- 例外端末：医療/製造など変更凍結が必要な端末は別リングに分離し、年数回の例外審査を行う。
運用KPIと可視化
- 適用率（7日/14日/30日）、未適用端末の上位理由（再起動未実施、到達不可、失敗コード）を定点観測。
- 部門別のばらつきをダッシュボードで共有し、期限や通知の調整につなげる。
- 重大不具合検知時は“一時停止→影響評価→拡大/再開”を標準手順化。
よくある失敗と処方箋
- 延期を長くし過ぎて未適用山積み → 期限を併用し、夜間メンテ枠で再起動を促す。
- 一時停止の解除忘れ → 解除予定を運用カレンダーに登録。解除確認のペアレビューを導入。
- Expediteの常用 → 緊急時限定。常用は運用負債を増やす。
設定ヒント（Intune）
- Update rings：再起動期限7日、アクティブ時間は業務帯。品質更新延期7〜14日、機能更新延期90〜120日。
- Feature updates：目標バージョンで足並みを揃え、リングごとに展開開始日をずらす。
- 重複設定の排除：Feature updatesとUpdate ringsの延期を併用すると複雑化。片側に寄せる。
FAQ（よくある質問）
Q. 停止端末が減らない。どこから手を付けるべき？
A. まずは到達不可と再起動未実施を切り分ける。前者はネットワークや電源管理、後者は期限と通知の見直しが有効。
Q. 一時停止の解除タイミングは？
A. 影響範囲の把握と代替パスの確認が済み、KPIが下げ止まったと判断できた時点で段階再開する。
Q. 例外端末の扱いは？
A. 医療・製造など稼働停止リスクが高い端末は別リングで凍結し、年数回の審査で計画的に更新する。
コメント