Windows 11 enterprise deployment guidance を確認している管理者が最初に押さえるべき結論は、26H1を全社標準展開のゴールにしないことです。2026年4月19日更新の Microsoft Learn では、Windows 11 version 26H1 は一部の新しいデバイス向けのハードウェア最適化リリースであり、既存の Windows 11 環境に対する機能更新としては提供されないと説明されています。そのうえで、企業展開では Windows 11 version 25H2 と 24H2 が引き続き推奨リリースとされています。(Microsoft Learn)
つまり今回の rollout は、「最新バージョンへ一斉に上げる」話ではありません。現場のワークフローとしては、標準PC群は 25H2 または 24H2 にターゲットを固定し、新規ハードウェアで 26H1 が入ってくるケースだけを別レーンで検証する形に変わります。Power users、admins、solution owners は、OS展開計画・アプリ検証・調達・サポート運用を分けて考える必要があります。
Windows 11 enterprise deployment guidance の最新動向
今回の Windows 11 enterprise deployment guidance で重要なのは、26H1が「次の標準アップグレード先」ではなく、「特定の新規デバイス向けリリース」と位置付けられている点です。Microsoft は 26H1 について、次世代シリコンを搭載する一部の新しいデバイスにプリインストールされるリリースであり、Windows Update 経由で既存デバイスに提供される機能更新ではないと説明しています。(Microsoft Learn)
現場目線では、次のように整理すると判断しやすくなります。
| リリース | 現場での扱い | 主な利用シナリオ | 注意点 |
|---|---|---|---|
| Windows 11 26H1 | 例外レーン | 新しいハードウェアにプリインストールされた端末の受け入れ検証 | 既存端末向けの標準機能更新として扱わない |
| Windows 11 25H2 | 標準展開候補 | 新規展開、長期的な更新計画、グローバル展開の次期ベース | アプリ互換性と業務部門の受け入れ確認が必要 |
| Windows 11 24H2 | 標準展開候補 | すでに検証済みの端末群、段階展開中の組織、安定運用重視の環境 | サポート期限と次期移行計画を同時に管理する |
| Windows 11 23H2以前 | 移行対象 | 未移行端末の棚卸し、例外端末の削減 | サポート期限を見ながら計画的に減らす |
Microsoft の Windows 11 release information では、Windows 11 は年1回の機能更新サイクルで、Enterprise と Education エディションは通常36か月のサポート期間が設定されると説明されています。また、25H2 と 24H2 のサポート終了日はエディションごとに異なります。たとえば Enterprise/Education 系では、25H2 は 2028年10月10日、24H2 は 2027年10月12日が更新終了日として掲載されています。(Microsoft Learn)
rollout が現場のワークフローをどう変えるか
従来の機能更新では、「新バージョンが出たので、検証して段階展開する」という流れが基本でした。しかし 26H1 の扱いでは、ワークフローの中心が「新バージョンの追従」から「標準レーンと例外レーンの分離」に変わります。
特に変わるのは、以下の4点です。
| これまでの考え方 | 26H1以降に必要な考え方 |
|---|---|
| 最新リリースを次期標準候補として検証する | まず Microsoft の enterprise deployment guidance で標準展開対象か確認する |
| OSバージョン単位で展開計画を作る | OS、ハードウェア世代、ドライバー、アプリ互換性をセットで見る |
| Intune の update ring で延期日数を調整する | Feature update policy で 25H2/24H2 のターゲットを明示する |
| 新規PCも既存PCと同じ運用に入れる | 26H1搭載デバイスは受け入れ検証・サポート手順を別管理する |
この変更は、特にグローバル企業で影響が大きくなります。日本、米国、欧州、アジア拠点で調達モデルが異なる場合、一部拠点だけ 26H1 プリインストール端末が先に入る可能性があります。その端末を既存の 24H2/25H2 前提の標準運用へ無理に入れると、ドライバー、VPN、EDR、周辺機器、業務アプリの検証順序が崩れます。
管理者がまず変更すべき展開計画
管理者が最初に行うべき作業は、「26H1対応」ではなく、25H2と24H2のどちらを標準ターゲットにするかを明文化することです。
Microsoft Intune の Feature update policies は、デバイスがインストール可能な Windows バージョンを指定し、そのポリシーを変更または削除するまで対象バージョンを維持する仕組みです。すでにより新しいバージョンを実行している端末を古いバージョンへ戻すものではなく、サポート中のバージョンだけを選択できます。(Microsoft Learn)
実務では、次のようなポリシー設計が扱いやすくなります。
| デバイス群 | 推奨する方針 | ポリシー例 |
|---|---|---|
| IT部門・パワーユーザー | 25H2を先行検証 | FUP-W11-25H2-Pilot-Required |
| 一般オフィスPC | 25H2または24H2を標準化 | FUP-W11-25H2-Broad または FUP-W11-24H2-Standard |
| 工場・店舗・共有端末 | 24H2を維持し、業務停止リスクを抑える | FUP-W11-24H2-SharedDevices |
| 新規ハードウェア | 26H1搭載の有無を調達時に確認 | 通常のFeature update policyとは別に受け入れ検証 |
| 例外端末 | 理由・期限・責任者を記録 | Exception-W11-Version-Control |
ここで重要なのは、update ring だけで機能更新をコントロールしようとしないことです。Intune のドキュメントでは、Feature update policies を使う場合、update ring 側の機能更新延期と組み合わせると複雑化し、意図せず更新が遅れたりブロックされたりする可能性があると説明されています。update ring は再起動通知、アクティブ時間、品質更新の延期、期限設定などのユーザー体験制御に寄せ、OSバージョンの指定は Feature update policy に寄せるのが実務的です。(Microsoft Learn)
利用シナリオ別に見る実務への影響
既存の24H2端末を運用している場合
すでに 24H2 を標準展開している組織は、26H1の発表を理由に展開計画を大きく変える必要はありません。むしろ、やるべきことは次の3つです。
- 24H2 のサポート期限を管理台帳に反映する
- 25H2 へ移行する時期を業務カレンダーに合わせて決める
- 26H1 を既存端末向け展開候補に入れない
たとえば、四半期決算、繁忙期、入試、年度末処理などがある組織では、25H2への移行を「技術的に可能になった時点」ではなく、「サポート部門が障害対応できる時期」に合わせて設定します。Windows 11 enterprise deployment guidance を読む目的は、単に推奨バージョンを知ることではなく、展開時期の意思決定に使うことです。
25H2を次期標準にしたい場合
25H2を次期標準にする場合は、最初から全社展開せず、パイロット、先行部門、広域展開の順に進めます。
| フェーズ | 対象 | 確認すること |
|---|---|---|
| パイロット | IT部門、Power users、業務アプリに詳しいユーザー | サインイン、VPN、EDR、プリンター、主要アプリの動作 |
| 先行展開 | 情報システムと協力しやすい部門 | 問い合わせ件数、再起動タイミング、業務影響 |
| 広域展開 | 一般ユーザー | 展開成功率、失敗端末、サポート負荷 |
| 例外整理 | 未更新端末 | ブロック理由、代替策、期限 |
このとき、Power users は単なる「早く試す人」ではありません。業務アプリのショートカット、マクロ、VPN接続、認証フロー、外部ディスプレイ、会議デバイスなど、管理者が見落としやすい実利用の確認役です。フィードバックの粒度を上げるために、「動いた・動かない」ではなく、アプリ名、再現手順、端末モデル、ドライバー、更新前後のOSビルドを記録してもらう運用にします。
26H1搭載の新規PCを調達する場合
26H1が入った新しいデバイスを調達する場合、標準展開とは別の受け入れワークフローを作ります。Microsoft は 26H1 を既存の 24H2/25H2 端末からのインプレース更新として提供しないと説明しているため、調達部門や現場責任者に「26H1端末が混在する可能性」を事前に共有する必要があります。(Microsoft Learn)
実務で確認すべき項目は次の通りです。
| 確認項目 | 具体的な確認内容 |
|---|---|
| デバイス登録 | Autopilot、Intune登録、Entra ID参加、コンプライアンスポリシー |
| セキュリティ | EDR、Defender設定、ディスク暗号化、証明書、条件付きアクセス |
| ドライバー | Wi-Fi、Bluetooth、カメラ、指紋認証、GPU、周辺機器 |
| 業務アプリ | VPN、会計、人事、CRM、RPA、社内ポータル、ブラウザ拡張 |
| サポート | ヘルプデスクの切り分け手順、FAQ、既知の制限、交換時のOS差分 |
| 調達 | 同一型番でもOSプリインストール状況が変わる可能性の確認 |
ここで失敗しやすいのは、26H1端末を既存の標準イメージへ無理に戻そうとすることです。新しいハードウェアは、そのOSとドライバーの組み合わせを前提に出荷される場合があります。まずはOEMのサポート情報、ドライバー提供状況、社内管理ポリシーとの整合性を確認し、必要なら「26H1端末用の暫定サポート範囲」を定義します。
Configuration Manager と Intune の共同管理環境
Configuration Manager と Intune を併用している環境では、更新ワークロードの切り替え順序が重要です。Intune のドキュメントでは、共同管理デバイスで Windows Update policies workload を Intune に切り替える前に、Feature update policy を作成して対象バージョンを指定し、レポートで OfferReady 以降の状態を確認してから切り替える流れが説明されています。(Microsoft Learn)
現場では、次の順序が安全です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 現在のOSバージョン、管理方式、更新ソースを棚卸し | WSUS、Configuration Manager、Intuneの混在を可視化 |
| 2 | 25H2または24H2のFeature update policyを作成 | 意図しない新バージョンへの移動を防ぐ |
| 3 | 対象グループを小さく割り当てる | 影響範囲を限定する |
| 4 | レポートで状態を確認 | ポリシーがWindows Update側で処理されたかを見る |
| 5 | ワークロードを段階的にIntuneへ移す | 更新管理の責任範囲を明確にする |
この順序を飛ばすと、端末が「管理されているように見えるが、実際には期待した更新制御になっていない」状態になりやすくなります。特にグローバル拠点では、地域ごとに古いGPO、WSUS設定、ネットワーク制限が残っていることがあります。
Release health を運用フローに組み込む
Windows 11 enterprise deployment guidance を実務で活かすには、Release health の確認を月例作業に組み込む必要があります。Microsoft 365 admin center の Windows release health では、Windows の月例更新や機能更新に関する既知の問題を確認でき、組織でいつ、どの規模で更新を展開するかの判断にも使えると説明されています。(Microsoft Learn)
おすすめは、月例更新の前後で確認ポイントを分けることです。
| タイミング | 確認内容 | 判断 |
|---|---|---|
| 月例更新前 | 対象バージョンの既知の問題、safeguard hold、影響アプリ | 展開延期、パイロット継続、広域展開の可否 |
| パイロット後 | 問い合わせ、失敗率、再起動トラブル、アプリ不具合 | 次リングへ進めるか |
| 広域展開中 | 新しい既知の問題、地域別障害、端末モデル別失敗 | 一時停止、除外、サポート通知 |
| 展開後 | 未更新端末、例外理由、サポート期限 | 次期移行計画へ反映 |
大規模環境では、Microsoft Graph の Windows updates API も検討できます。Microsoft は、Windows release health の既知の問題や製品ライフサイクル情報を Microsoft Graph から取得できると説明しています。ただし、このデータセットは Microsoft Graph REST API の beta endpoint 配下にあるため、運用自動化に使う場合は仕様変更の可能性を前提に設計します。(Microsoft Learn)
Power users と solution owners の役割
今回の rollout では、Power users と solution owners の関与がこれまで以上に重要になります。理由は、26H1が全社一律のアップグレード先ではないため、現場ごとに「何を標準とするか」「どの端末を例外にするか」を判断する必要があるからです。
Power users は、次の観点で検証に参加します。
| 役割 | 具体的な確認内容 |
|---|---|
| 業務アプリ検証 | 日常的に使うアプリ、マクロ、ブラウザ拡張、認証連携 |
| 周辺機器確認 | プリンター、スキャナー、Web会議機器、外部モニター |
| ユーザー体験確認 | 再起動通知、更新にかかる時間、業務中断の有無 |
| 問い合わせ削減 | よくある質問、画面差分、操作手順の共有 |
Solution owners は、アプリ単体の動作だけでなく、業務プロセス全体を見ます。たとえば、経費精算システムが起動するだけでは不十分です。SSO、証明書、Excel連携、PDF出力、承認通知、スマートフォン連携まで含めて、実際の業務が完了するかを確認します。
失敗しやすいポイントと回避策
Windows 11 enterprise deployment guidance の読み違いで起きやすい失敗は、次の通りです。
| 失敗パターン | なぜ問題か | 回避策 |
|---|---|---|
| 26H1を次期標準と誤解する | 既存端末向けの機能更新ではない | 標準展開は25H2/24H2で設計する |
| update ringだけでOSバージョンを制御する | 期限、延期、ユーザー体験とバージョン制御が混ざる | Feature update policyで対象バージョンを固定する |
| 複数のFeature update policyを同じ端末に当てる | Windows Updateは適用可能な最新の機能更新を1つ提示する | グループ設計を見直し、重複割り当てを減らす |
| Windows 10端末の設定を見落とす | 「最新のWindows 11へアップグレード」設定で意図しない移行が起きる可能性がある | Windows 10移行用とWindows 11維持用のポリシーを分ける |
| 新規ハードウェアを既存標準PC扱いにする | 26H1、ドライバー、OEM仕様の差分を見落とす | 調達・検証・サポートを別レーン化する |
| Release healthを障害発生後だけ見る | 既知の問題を事前に避けられない | 月例更新前の確認をチェックリスト化する |
Intune の update ring では、品質更新の延期、機能更新の延期、Windows 10端末を最新のWindows 11へ上げる設定、再起動通知、期限、アクティブ時間などを制御できます。便利な反面、目的の違う設定を1つのポリシーに詰め込むと、トラブル時の切り分けが難しくなります。(Microsoft Learn)
現場で使える rollout チェックリスト
最後に、今回の guidance を受けてすぐ実行できるチェックリストを整理します。
| チェック | 実施内容 |
|---|---|
| 標準リリースを決める | 25H2を標準にするか、24H2を継続するかを明文化する |
| 26H1の扱いを決める | 新規ハードウェア専用の例外レーンとして扱う |
| Intuneポリシーを確認する | Feature update policy と update ring の役割が混ざっていないか見る |
| グループ割り当てを確認する | 同一端末に複数の機能更新ポリシーが重複していないか確認する |
| 新規PC調達ルールを更新する | 見積もり・調達時にプリインストールOSを確認する項目を追加する |
| アプリ検証表を更新する | 25H2、24H2、必要に応じて26H1搭載端末の検証列を分ける |
| Release healthを定例化する | 月例更新前、パイロット後、広域展開中に確認する |
| 例外端末を期限付きで管理する | 例外理由、責任者、解消予定日を記録する |
今回の Windows 11 enterprise deployment guidance は、管理者に「最新へ追従する」よりも「標準を固定し、例外を管理する」ことを求めています。まずは 25H2 と 24H2 のどちらを自社の標準にするかを決め、Intune の Feature update policy でターゲットを明示します。そのうえで、26H1搭載の新規デバイスだけを別レーンで検証し、調達・アプリ互換性・サポート手順に反映することが、現場で混乱を起こさない rollout の進め方です。
コメント