2026年4月19日時点の更新として注目された Microsoft の 26H1 ドキュメントから読み取れる結論は、Windows 11 enterprise deployment guidance における標準展開の軸は 26H1 ではなく、25H2 と 24H2 のままという点です。26H1 は既存端末へ広く配布する機能更新ではなく、特定の新しいハードウェア向けに位置づけられたリリースです。Microsoft Learn でも、Windows 11 バージョン 25H2 と 24H2 は引き続き enterprise deployment の推奨リリースとされています。(Microsoft Learn)
この記事では、単発ニュースとしてではなく、Product owners、IT decision-makers、technical strategists が今後の Windows 11 展開計画をどう読むべきかを整理します。ポイントは、26H1 を「次に全社展開すべき新バージョン」と見ないことです。むしろ、25H2/24H2 を標準環境として管理しながら、26H1 は新世代デバイスの評価枠として切り分けるのが現実的です。
Windows 11 enterprise deployment guidance の最新動向
今回の論点は、英語圏では “Microsoft’s updated 26H1 documentation keeps Windows 11 versions 25H2 and 24H2 as the recommended releases for enterprise deployment” という文脈で読まれています。つまり、26H1 の存在そのものよりも、Microsoft が企業向けの標準展開先として 25H2 と 24H2 を維持している点が重要です。
Microsoft の Windows 11 release health ページでは、26H1 は「次世代シリコン向けに設計されたハードウェア最適化リリース」と説明されています。さらに、既存デバイス向けの機能更新ではなく、Windows Update 経由で既存の Windows 11 端末に提供されるものでもないとされています。(Microsoft Learn)
この情報を企業ITの視点で読むと、次のようになります。
| 論点 | 実務上の読み方 |
|---|---|
| 26H1 が登場した | 既存PCの全社アップグレード計画を変更する理由にはならない |
| 25H2/24H2 が推奨リリースのまま | 標準OSイメージ、Intuneポリシー、展開リングはこの2系統を中心に設計する |
| 26H1 は特定デバイス向け | 新世代ハードウェアの評価・調達計画に紐づけて扱う |
| 年次のH2更新サイクルは継続 | ロードマップは「H2を軸にした標準展開」として読む |
26H1を「次の標準版」と読んではいけない理由
26H1 は、名称だけを見ると 25H2 の次に来る通常の機能更新のように見えます。しかし、Microsoft の説明では、26H1 は 25H2 の機能更新ではなく、広範なチャネルで提供されるものでもありません。Microsoft の Windows IT Pro Blog では、26H1 は新しいデバイスイノベーションを支える対象限定のリリースであり、現時点では Qualcomm Snapdragon X2 Series 搭載デバイスに 26H1 が搭載されると説明されています。(Aka.ms)
企業展開で重要なのは、名称の新しさではなく、次の3点です。
| 判断軸 | 25H2 / 24H2 | 26H1 |
|---|---|---|
| 既存PCへの展開 | 標準展開の候補 | 既存PC向けの機能更新ではない |
| Windows Updateでの配布 | 管理対象端末へ段階展開しやすい | 既存端末には提供されない前提 |
| 調達計画への影響 | 標準PCのOS選定に直結 | 特定の新世代デバイス評価に限定 |
| 運用設計 | Intune、Autopatch、Configuration Managerで通常管理 | 別枠の検証グループで扱うべき |
| リスク | アプリ互換性、段階展開、サポート期限の管理 | ハードウェア依存、将来の更新経路、機能差分の管理 |
特に注意したいのは、Microsoft が「26H1 を理由にデバイス購入やOS展開を止める必要はない」と明示している点です。新しいシリコンを必要とするデバイス導入を狙っている場合を除き、26H1 待ちで 25H2/24H2 の展開を遅らせるメリットは小さいと考えるべきです。(Aka.ms)
25H2・24H2・26H1の位置づけを整理する
Windows 11 の企業展開では、「最新版だから採用する」ではなく、「どのバージョンを標準環境として維持できるか」で判断する必要があります。Microsoft の Windows 11 release information では、Windows 11 は年1回の機能更新サイクルで、Enterprise/Education エディションは一般提供日から36か月サポートされると説明されています。(Microsoft Learn)
| バージョン | 企業展開での位置づけ | 向いているケース | 注意点 |
|---|---|---|---|
| Windows 11 25H2 | 今後の標準展開の有力候補 | 新規PC展開、長めのサポート期間を確保したい環境、グローバル標準化 | 既存アプリ、EDR、VPN、周辺機器の検証は必要 |
| Windows 11 24H2 | 安定運用中の標準環境として有効 | 24H2検証が完了している環境、移行コストを抑えたい部門、既存展開リングを維持したい場合 | 25H2よりサポート終了が早いため、次回移行計画を早めに置く |
| Windows 11 26H1 | 特定新デバイス向けの評価枠 | 新世代シリコン搭載PCの先行評価、ハードウェア刷新プロジェクト | 既存端末の標準アップグレード先ではない。ホットパッチ非対応などの差分にも注意 |
| Windows 11 23H2以前 | 残存端末の移行計画対象 | 短期的な延命、アプリ改修待ち | サポート期限とセキュリティ基準を確認し、25H2または24H2への移行計画を具体化する |
26H1 については、2026年後半の次の年次機能更新へそのまま更新できないと Microsoft が説明しています。これは、26H1 が 24H2/25H2 や次期年次更新とは異なる Windows コアを基盤にしているためで、将来の Windows リリースで更新パスが用意されるとされています。(Aka.ms)
ロードマップから読むべき3つの方向性
H2の年次更新サイクルは引き続き企業展開の基準になる
Windows 11 enterprise deployment guidance を読むうえで最も重要なのは、H2の年次更新サイクルを前提にした計画を崩さないことです。Microsoft は、Windows 11 の機能更新を年1回、暦年の後半に提供する方針を示しています。(Microsoft Learn)
そのため、IT部門は「次のH2で標準を更新するか」「既存のH2を何か月維持するか」「サポート終了の何か月前に移行を完了するか」をロードマップの中心に置くべきです。26H1 はこの標準サイクルを置き換えるものではなく、ハードウェアに紐づいた例外的な流れとして扱うのが安全です。
標準OSとハードウェア評価を分ける必要がある
26H1 の意味は、OS展開とPC調達を完全に同じ軸で考えると誤解しやすい、という点にあります。
従来は「新しいWindowsバージョンが出るので、全社の更新計画を見直す」という発想が自然でした。しかし 26H1 では、OSバージョンが新しくても、対象は特定の新デバイスに限定されます。したがって、標準OSのロードマップと新世代ハードウェアの評価ロードマップを分離する必要があります。
たとえば、次のように分けると判断がぶれにくくなります。
| 管理対象 | 主な判断者 | 判断基準 |
|---|---|---|
| 標準業務PC | IT運用責任者、セキュリティ責任者 | 25H2/24H2のサポート期限、アプリ互換性、展開リングの安定性 |
| 新世代デバイス | 技術戦略担当、デバイス調達担当 | CPU/SoC、バッテリー、AI機能、ドライバー、周辺機器互換性 |
| 業務アプリ | Product owner、業務部門 | LOBアプリ、ブラウザ、Office、VPN、認証、印刷の検証結果 |
| グローバル拠点 | IT decision-maker | 地域ごとのネットワーク、言語、サポート体制、段階展開期間 |
「バージョン固定」と「段階展開」が運用の中心になる
Microsoft Intune では、Feature update policy によって対象デバイスを特定の Windows バージョンに固定したり、指定バージョンを超えて更新されないように制御したりできます。これにより、想定外のメジャーアップグレードを避けながら、アプリ検証や部門ごとの展開計画と合わせた管理がしやすくなります。(Microsoft Learn)
一方、update rings は主に延期日数、期限、再起動動作、ユーザー体験などを制御するためのものです。Intune のドキュメントでも、Feature update policy はバージョン制御、update rings は展開タイミングや体験制御という役割分担が示されています。(Microsoft Learn)
企業が取るべき今後の運用方針
基本方針は「25H2を第一候補、24H2を安定運用枠」
これから新規展開やPCリフレッシュを計画する組織では、25H2 を第一候補として検証するのが自然です。サポート期間の観点でも、25H2 は 24H2 より長い運用余地を確保できます。既に 24H2 の検証と展開が完了している組織では、24H2 を安定運用枠として維持しつつ、次の移行先として 25H2 を評価する形が現実的です。
判断の目安は次のとおりです。
| 状況 | 推奨される考え方 |
|---|---|
| 新規PCを大量導入する | 25H2を標準候補にする |
| 24H2展開が完了したばかり | 24H2を維持し、25H2は次期リングで検証する |
| 23H2以前が多数残っている | サポート期限を確認し、25H2または24H2への移行を優先する |
| 新世代シリコン搭載PCを評価する | 26H1端末を別グループで評価する |
| LTSC端末を使っている | 通常のFeature update policyではなく、LTSC向けの更新・更改計画を別途立てる |
なお、Windows Autopatch は LTSC デバイスについて品質更新の管理はサポートしますが、LTSC デバイス向けの機能更新は提供しないとされています。LTSC端末を通常の Windows 11 半期・年次展開と同じ運用に混ぜると、移行計画が複雑化します。(Microsoft Learn)
26H1は「例外管理」する
26H1 を完全に無視する必要はありません。ただし、扱いは標準展開ではなく、例外管理です。
26H1端末を導入する場合は、少なくとも次の項目を検証対象にしてください。
| 検証項目 | 確認内容 |
|---|---|
| 管理基盤 | Intune登録、Autopilot、Configuration Manager連携、Autopatch対象可否 |
| セキュリティ | EDR、DLP、VPN、証明書、条件付きアクセス、BitLocker |
| 業務アプリ | LOBアプリ、Office、ブラウザ拡張、電子署名、帳票、RPA |
| 周辺機器 | プリンター、スキャナー、会議機器、ドッキングステーション |
| ユーザー体験 | 日本語IME、多言語環境、アクセシビリティ、リモートワーク時の安定性 |
| 更新運用 | 品質更新、ドライバー更新、再起動制御、将来の更新パス |
26H1 はホットパッチをサポートしないとも説明されています。もし組織が再起動回数の削減やホットパッチを運用上の重要要件にしている場合、26H1端末は通常の管理リングとは分けて評価すべきです。(Aka.ms)
IntuneとAutopatchで実装する展開ステップ
Windows 11 enterprise deployment guidance を実際の運用に落とし込むなら、以下の順で進めると混乱しにくくなります。
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | OSバージョン、ハードウェア、拠点、アプリ、管理方式を棚卸しする | 端末インベントリ、バージョン別台数 |
| 標準バージョン決定 | 25H2を標準候補、24H2を安定運用枠、26H1を例外枠として分類する | OS標準化方針 |
| Feature update policy設定 | Intuneで対象バージョンを指定し、意図しない上位更新を防ぐ | バージョン固定ポリシー |
| Update ring設計 | パイロット、本番前、広範展開、例外端末のリングを分ける | 展開リング設計書 |
| アプリ検証 | LOBアプリ、認証、VPN、印刷、セキュリティ製品を確認する | 互換性チェック結果 |
| 段階展開 | IT部門、代表部門、地域別、本番全体の順に展開する | 展開スケジュール |
| 監視と是正 | レポート、失敗端末、safeguard hold、再起動未完了を確認する | 更新コンプライアンスレポート |
Intune の Feature update policy では、サポート中の Windows バージョンのみを選択でき、複数ポリシーが同一デバイスに当たる場合は Windows Update が適用対象を評価します。Microsoft は、Feature update policy を使う場合、update ring の機能更新延期設定を併用し続けると不要な複雑さや意図しない遅延につながるため、Feature update policy を主要なバージョン制御手段にすることを推奨しています。(Microsoft Learn)
特に Configuration Manager と Intune の共同管理環境では注意が必要です。Windows Update workload を Intune に切り替える前に、Feature update policy を作成して対象デバイスが OfferReady 以降の状態になっているか確認する手順が示されています。切り替えの順序を誤ると、意図より新しいバージョンが提供される可能性があります。(Microsoft Learn)
役割別に見る意思決定ポイント
Product ownersが見るべきこと
Product owners は、Windows のバージョン名よりも、担当プロダクトや業務アプリがどのバージョンで安定稼働するかを重視すべきです。
確認すべき項目は次のとおりです。
| 項目 | 判断基準 |
|---|---|
| 業務アプリ | 25H2/24H2で主要機能が動くか |
| ユーザー体験 | UI変更、通知、再起動、既定アプリの変化が業務に影響しないか |
| 障害時対応 | 更新後に切り戻し、代替端末、既知問題の共有ができるか |
| グローバル展開 | 言語、タイムゾーン、地域ごとの業務カレンダーに合うか |
Microsoft は Windows 11 計画ドキュメントで、アプリケーションテストや準備基準の定義を展開計画に含めることを示しています。つまり、Product owner は「ITが展開するまで待つ」のではなく、検証観点を早い段階で提供する役割を持ちます。(Microsoft Learn)
IT decision-makersが見るべきこと
IT decision-makers は、25H2/24H2のどちらを標準化するか、どの部門をいつ移行するか、26H1端末を調達対象に含めるかを決める必要があります。
判断基準は次の3つです。
| 判断基準 | 見るべき内容 |
|---|---|
| リスク | アプリ互換性、更新失敗率、サポート体制、拠点ごとの差異 |
| コスト | 検証工数、ヘルプデスク負荷、PC刷新時期、ライセンス・管理基盤 |
| 時間 | サポート期限、展開ウィンドウ、繁忙期、監査・規制対応 |
特にグローバル企業では、全拠点を同じ週に更新するより、地域・業務重要度・ネットワーク条件でリングを分けた方が失敗時の影響を抑えられます。
Technical strategistsが見るべきこと
Technical strategists は、26H1 を「Windowsの方向性を示すシグナル」として読むとよいでしょう。26H1 は、Windows が特定ハードウェアの機能を取り込むために、従来の標準展開サイクルとは別のリリースを使う可能性を示しています。
ただし、これは「企業標準をすぐ26H1へ寄せるべき」という意味ではありません。むしろ、今後のアーキテクチャ戦略では次のような分離が必要になります。
| 領域 | 戦略 |
|---|---|
| 標準業務端末 | 25H2/24H2を軸に、安定性とサポート期間を重視 |
| AI PC・新世代端末 | 26H1のような対象限定リリースを検証枠で評価 |
| 管理基盤 | Intune、Autopatch、Windows Update for Businessを中心にクラウド管理へ寄せる |
| アプリ基盤 | Arm対応、ドライバー依存、セキュリティ製品の互換性を継続確認 |
失敗しやすいポイント
26H1を全社展開の次期候補にしてしまう
最も大きな誤解は、26H1 を 25H2 の後継標準リリースとして扱うことです。26H1 は既存デバイス向けの通常の機能更新ではありません。標準OS計画にそのまま組み込むと、Intuneポリシー、アプリ検証、調達計画が不必要に複雑になります。
25H2/24H2の展開を止めてしまう
26H1の情報を見て「次が出るなら待つ」と判断するのも危険です。Microsoft は、26H1 が現在の Windows 展開や購入戦略に影響しないと説明しています。既存PCの標準化、Windows 10/古いWindows 11からの移行、サポート期限対応は止めずに進めるべきです。(Aka.ms)
Feature update policyと延期設定を混ぜすぎる
Intune運用では、Feature update policy と update ring の役割を混同しがちです。Feature update policy で対象バージョンを制御し、update ring で再起動や期限などの体験を制御する、と切り分けると設計が明確になります。両方で機能更新を複雑に制御すると、なぜ端末が更新されないのか、なぜ想定外の更新が見えるのかを追いにくくなります。(Microsoft Learn)
ハードウェア調達とOS標準化を同一視する
26H1端末が調達可能になっても、それは全社標準OSを26H1へ変える理由にはなりません。新しいPCを買う判断と、標準OSを定める判断は分けるべきです。特に新世代シリコン搭載端末では、ドライバー、セキュリティ製品、周辺機器、業務アプリの検証結果が採用可否を左右します。
次に取るべき行動
Windows 11 enterprise deployment guidance を踏まえると、次にやるべきことは明確です。
| タイミング | やること |
|---|---|
| 今日 | 端末のOSバージョン別台数、23H2以前の残存数、24H2展開状況を確認する |
| 今週 | 25H2を次期標準候補にするか、24H2を継続標準にするかを決める |
| 今月 | IntuneのFeature update policyとupdate ringsを見直し、意図しない上位更新や延期設定の重複をなくす |
| 今四半期 | 26H1搭載デバイスを導入する可能性がある場合、標準端末とは別の評価リングを作る |
| 次回PC刷新前 | 調達仕様書に、対象OS、管理方式、検証要件、例外デバイスの扱いを明記する |
今回の 26H1 ドキュメント更新は、Windows 11 の企業展開ロードマップを大きく変えるニュースではありません。むしろ、Microsoft が 25H2 と 24H2 を引き続き enterprise deployment の推奨リリースとして扱っていることを確認する材料です。
標準展開は 25H2/24H2 を中心に進め、26H1 は新世代ハードウェアの評価枠として分離する。この方針を明文化し、Intune や Autopatch のポリシーに落とし込むことが、今後の Windows 11 運用で最も実務的な対応です。
コメント