Windows 11 version 26H1 deployment model で最も重要なのは、「既存PCへ通常の機能更新として配るものではない」という点です。Microsoft は、Windows 11 version 26H1 を一部の新しいハードウェア向けに提供されるプリインストール前提のリリースと位置付けており、既存の Windows 11 デバイスには Windows Update 経由で提供しない方針を示しています。つまり、現場の管理者がすぐにやるべきことは、26H1 を全社展開の次期ターゲットにすることではなく、調達・検証・管理ポリシーの中で「例外的な新ハードウェア枠」として扱うことです。(Microsoft Learn)
この記事では、2026年4月19日時点の更新として注目された「Windows 11 version 26H1 will not be offered through Windows Update to existing devices」という再確認を、Power users、IT 管理者、ソリューションオーナーの実務フローに引き付けて解説します。ニュースとして知るだけでなく、Intune、Windows Autopatch、Configuration Manager、購買ルール、アプリ検証、社内説明をどう変えるべきかまで整理します。
Windows 11 version 26H1 deployment model の最新動向
Windows 11 version 26H1 deployment model は、従来の「次の年次機能更新を全社へ段階展開する」という考え方とは異なります。
Microsoft は 26H1 について、次世代シリコンを搭載する一部の新デバイス向けに設計されたハードウェア最適化リリースと説明しています。既存の Windows 11 version 24H2 / 25H2 デバイスに対して、Windows Update から機能更新として配布されるものではありません。企業向けの標準展開先としては、引き続き Windows 11 version 24H2 と 25H2 が推奨されています。(Microsoft Learn)
現場での結論は明確です。
26H1 は「全社展開するOS」ではなく、「特定の新ハードウェアを受け入れるための管理対象OS」として扱うべきです。
たとえば、次のような判断になります。
| 現場の状況 | 26H1 の扱い | 実務上の判断 |
|---|---|---|
| 既存の 24H2 / 25H2 PC を管理している | 配布対象にしない | 既存の展開リング、更新ポリシー、ユーザー案内は大きく変えない |
| PC更改で新しい Snapdragon X2 世代の端末を検討している | 検証対象にする | 先行評価、アプリ互換性、デバイス管理、サポート体制を確認する |
| 標準化された大規模端末群を運用している | 原則として標準OSにしない | 24H2 / 25H2 を標準イメージや調達条件に残す |
| Power user が個人利用で新型PCを購入する | 仕様確認が必要 | 「新しいから全員が更新できる」と誤解しない |
| ソリューションオーナーが業務アプリを管理している | テストマトリクスに限定追加 | 全端末向けではなく、新ハードウェア利用部門を中心に検証する |
26H1 は通常の Windows Update 展開ではない
従来の Windows 11 運用では、管理者は次の年次リリースを見据えて、段階的な展開リングを設計してきました。
たとえば、まず IT 部門と検証ユーザーへ展開し、その後に一部部門、最後に全社へ広げるという流れです。Intune の機能更新ポリシーや Windows Autopatch のリング設計も、この考え方に沿って運用されることが多いでしょう。
しかし 26H1 では、この前提をそのまま当てはめると誤ります。
Microsoft の Windows IT Pro Blog では、26H1 は broad channels ではなく、新しいデバイスを購入した場合に意図されるリリースであり、24H2 や 25H2 からの in-place update としては提供されないと説明されています。また、26H1 は 2026年後半の次期年次機能更新へ更新できず、将来の Windows リリースで更新パスが用意されるとされています。(aka.ms)
つまり、26H1 の rollout は「既存端末に配る作業」ではありません。実務では、次のようなフローに変わります。
| 従来の機能更新 rollout | 26H1 deployment model での rollout |
|---|---|
| 既存PCを対象に段階展開する | 新規調達端末を対象に受け入れ検証する |
| Windows Update / Intune の機能更新ポリシーで配布を制御する | OEMプリインストール端末を資産管理・構成管理に取り込む |
| アップグレード失敗率やロールバックを監視する | デバイス種別、シリコン、ドライバー、アプリ互換性を検証する |
| 全社標準OSへの移行計画を作る | 例外OSまたは新ハードウェア枠として管理する |
| 「いつ展開するか」が中心 | 「どの端末を受け入れるか」が中心 |
ここを取り違えると、管理者は不要な展開計画を作り、調達担当者は「26H1 搭載機を標準機にしてよいのか」と迷い、ソリューションオーナーは業務アプリ検証の優先順位を誤ります。
現場のワークフローはどう変わるか
端末調達フローは「OSバージョン」だけで判断しない
26H1 の影響が最も出やすいのは、IT 部門よりも先に購買・調達部門です。
これまでの調達条件では、「Windows 11 Pro」「Windows 11 Enterprise 対応」「Windows 11 25H2 以降」など、OS名やバージョンだけで仕様を指定していた企業もあるでしょう。しかし 26H1 では、同じ Windows 11 でも運用上の位置付けが異なります。
調達仕様書には、少なくとも次の確認項目を追加するべきです。
| 確認項目 | 確認する理由 |
|---|---|
| プリインストールOSのバージョン | 26H1 搭載機か、24H2 / 25H2 搭載機かを区別する |
| 搭載シリコン | 26H1 が必要な新ハードウェアかを確認する |
| 既存標準イメージの適用可否 | 既存の展開手順がそのまま使えるとは限らないため |
| ドライバー・ファームウェア提供元 | OEM更新、Windows Update、管理ツールでの適用方法を確認する |
| 業務アプリの動作要件 | Arm64、エミュレーション、周辺機器ドライバーの影響を見る |
| サポート窓口の切り分け | OS、ハードウェア、アプリの責任分界点を決める |
特に注意したいのは、「新しい Windows だから標準候補に入れる」という単純な判断です。26H1 は新しいものの、企業の標準展開先として推奨されているのは 24H2 / 25H2 です。標準化を重視する企業では、26H1 搭載機をすぐに全社標準端末へ入れるのではなく、先行評価端末、PoC端末、特定部門向け端末として扱うほうが安全です。
Intune や Autopatch のリング設計は「配布」より「分類」が重要になる
Windows 11 version 26H1 は、月例のセキュリティ更新や品質更新については一般的な管理ツールで扱えます。Microsoft は、26H1 のセキュリティ更新は Windows Autopatch、Microsoft Intune、Microsoft Configuration Manager など通常のツールで管理できるとしています。(aka.ms)
ただし、ここで重要なのは「管理できる」と「既存リングに混ぜてよい」は同じではない、という点です。
26H1 搭載端末が入ってきたら、まずは既存の更新リングに自動的に流し込むのではなく、次のように分類します。
| 管理単位 | 推奨アクション |
|---|---|
| 既存の 24H2 / 25H2 端末 | 従来の更新リングを維持する |
| 26H1 搭載の新端末 | 専用のデバイスグループに分ける |
| 検証ユーザー端末 | 26H1 専用のパイロットリングに入れる |
| 業務重要端末 | 検証完了まで 26H1 端末を割り当てない |
| ヘルプデスク用端末 | 問い合わせ再現用に1台以上確保する |
Intune を使っている場合は、OSバージョン、デバイスモデル、メーカー、プロセッサ情報、所有者部門などでフィルターや動的グループを設計します。特に、Windows feature update policy の対象に 26H1 が混ざる前提で考えるのではなく、「26H1 は配る対象ではなく、入ってきた端末を識別する対象」として設計することが重要です。
Autopatch を使っている企業でも、26H1 端末が既存のリングに入った場合に、サポート担当が端末の性質を理解できるように、デバイス名、グループ名、タグ、管理台帳で明確に区別しておくべきです。
Configuration Manager 環境ではコレクション設計を見直す
Configuration Manager を併用している企業では、26H1 を「OSバージョンが新しい端末」として雑に拾ってしまうクエリに注意が必要です。
たとえば、「Windows 11 の最新バージョン以上を対象にする」「ビルド番号が一定以上なら次期標準端末とみなす」といった条件を使っている場合、26H1 搭載機が意図しないコレクションに入る可能性があります。
見直すべきポイントは次の通りです。
| 見直し対象 | ありがちな失敗 | 修正の方向性 |
|---|---|---|
| デバイスコレクション | ビルド番号だけで最新端末扱いする | OSバージョンとモデル情報を組み合わせる |
| アプリ配布条件 | Windows 11 なら一律配布する | 26H1 検証済みアプリだけを対象にする |
| コンプライアンス判定 | 25H2 より新しければ合格にする | 企業標準OSと例外OSを分けて判定する |
| レポート | 26H1 を移行成功端末として数える | 26H1 は新規ハードウェア枠として別集計する |
特に、経営層や監査向けのレポートでは「Windows 11 最新化率」に 26H1 を混ぜると、現場の実態が見えにくくなります。26H1 は最新化の成果ではなく、特定ハードウェアの導入結果として集計するほうが正確です。
Power users が知っておくべきポイント
Power users にとって重要なのは、「自分のPCにも 26H1 が来るのか」という疑問です。
結論として、既存の Windows 11 24H2 / 25H2 PC に 26H1 が通常の Windows Update として表示されることは想定されていません。26H1 は、対象となる新しいデバイスにプリインストールされる形で入ってくるリリースです。Microsoft のリリース情報ページでも、26H1 は既存デバイス向けの機能更新として設計されておらず、24H2 や 25H2 からの in-place update として提供されない旨が示されています。(Microsoft Learn)
Power users が取るべき行動は、次の3つです。
| やること | 具体例 |
|---|---|
| 現在のバージョンを確認する | 設定アプリの「システム」→「バージョン情報」で 24H2 / 25H2 / 26H1 を確認する |
| 新型PC購入時にプリインストールOSを確認する | 仕様表や販売ページで OSバージョン、CPU、アーキテクチャを確認する |
| 業務アプリ・周辺機器の互換性を見る | VPN、セキュリティソフト、開発環境、プリンタ、計測機器などを事前に確認する |
開発者や検証担当者の場合は、26H1 を「Windows の次の一般機能更新」としてではなく、「新しいハードウェア環境のテスト対象」として扱うと混乱しにくくなります。
たとえば、Visual Studio、Docker、WSL、VPNクライアント、EDR、ブラウザ拡張、社内証明書、USBドングルなどを使っている場合、OS名だけでなくデバイスのCPUやドライバー構成も確認しましょう。
IT 管理者が変更すべき業務フロー
更新管理フローでは 26H1 を既存計画に入れない
多くの企業では、Windows 11 25H2 への移行計画や、24H2 の維持計画を進めているはずです。26H1 の登場によって、その計画を止める必要はありません。
Microsoft は、Windows 11 の年次機能更新は暦年後半の cadence を継続し、26H1 によって既存の enterprise rollout plans を変更する必要はないと説明しています。企業展開向けには 24H2 / 25H2 が引き続き適切な選択肢とされています。(aka.ms)
したがって、更新管理フローでは次のように切り分けます。
| 作業 | 26H1 による変更要否 |
|---|---|
| 24H2 / 25H2 の月例パッチ運用 | 原則変更なし |
| 25H2 への標準移行計画 | 原則変更なし |
| Windows Update for Business の既存ポリシー | 26H1 配布を前提にした変更は不要 |
| 新型端末の受け入れ検証 | 変更が必要 |
| 資産管理・レポート分類 | 変更が必要 |
| ユーザー向けFAQ | 変更が必要 |
ここでのポイントは、26H1 を「更新管理の主役」にしないことです。主役は引き続き 24H2 / 25H2 の安定運用であり、26H1 は新規調達端末の例外管理として扱います。
購買・資産管理・ヘルプデスクを同じ認識にそろえる
26H1 で起きやすい混乱は、IT管理ツールの問題よりも、人とプロセスの問題です。
購買担当者は「新しいPCに入っているなら問題ない」と考えがちです。ヘルプデスクは「Windows 11 だから既存手順で対応できる」と判断しがちです。アプリ担当者は「26H1 という名前なら 25H2 の次」と理解するかもしれません。
そのため、管理者は次のような短い説明を社内向けに用意しておくと効果的です。
Windows 11 version 26H1 は、既存PCへ配布する通常の機能更新ではありません。一部の新しいハードウェアにプリインストールされるリリースです。既存の社内標準端末は引き続き 24H2 / 25H2 を基準に運用します。26H1 搭載端末を購入・配布する場合は、事前にIT部門の検証対象とします。
この説明を、購買申請フォーム、端末標準仕様書、ヘルプデスクFAQ、ITポータルに掲載しておくと、無用な問い合わせを減らせます。
アプリ検証は「OS差分」より「デバイス差分」を重視する
26H1 の検証では、OSバージョンだけに注目すると見落としが出ます。実際のリスクは、新しいシリコン、ドライバー、ファームウェア、周辺機器、セキュリティ製品、業務アプリの組み合わせにあります。
検証対象は次の順に絞ると効率的です。
| 優先度 | 検証対象 | 理由 |
|---|---|---|
| 高 | VPN、EDR、認証、証明書、MDM登録 | ログオンや業務接続に失敗すると利用開始できない |
| 高 | 基幹業務アプリ、ブラウザベース業務、Officeアドイン | 日常業務への影響が大きい |
| 中 | プリンタ、スキャナ、会議デバイス、USB機器 | 部門ごとに影響が出やすい |
| 中 | 開発環境、仮想化、WSL、Docker | Power users や開発者に影響しやすい |
| 低 | 個人設定、UI差分、軽微な操作感 | 代替手段があることが多い |
特にソリューションオーナーは、「Windows 11 対応済み」とだけ書かれたアプリ要件を見直すべきです。26H1 搭載端末で使う可能性があるなら、OSバージョン、CPUアーキテクチャ、エージェント、ドライバー、認証方式まで含めて確認しましょう。
ソリューションオーナーが見るべき影響
ソリューションオーナーにとって、26H1 は「IT部門のOS更新ニュース」ではありません。業務システムの利用端末が増える可能性があるなら、サービス提供責任に関わります。
たとえば、営業部門が軽量な新型PCを先行導入する、役員向けにバッテリー駆動時間の長い端末を採用する、現場部門が新しいAI PCを検討するといったケースでは、26H1 搭載端末が業務フローに入り込む可能性があります。
このとき、ソリューションオーナーは次の観点で判断します。
| 観点 | 確認すべきこと |
|---|---|
| 利用者範囲 | どの部門・役割が 26H1 端末を使うのか |
| 業務重要度 | 障害時に業務停止するシステムか |
| 認証方式 | Entra ID、証明書、VPN、条件付きアクセスが正常に動くか |
| ブラウザ互換性 | Edge、Chrome、社内ポータル、SaaS が問題なく動くか |
| エージェント | EDR、DLP、資産管理、ログ収集ツールが対応するか |
| サポート手順 | 問い合わせ時に 26H1 端末だと識別できるか |
独自性のある実務ポイントとして、26H1 端末は「OSの例外」ではなく「利用者体験の例外」として扱うと管理しやすくなります。OS管理だけでなく、ユーザーがどのシステムに接続し、どの周辺機器を使い、どこでサポートを受けるかまで含めて検証するべきです。
具体的な利用シナリオ別の判断
シナリオ：既存の全社PCを 25H2 に移行中
この場合、26H1 のために計画を止める必要はありません。
既存PCには 26H1 が通常の Windows Update として配布されないため、全社移行計画のターゲットは 25H2 のままで構いません。むしろ、26H1 を待つことで移行計画が遅れるほうがリスクになります。
実務では、次の対応で十分です。
| 対応 | 内容 |
|---|---|
| 移行計画 | 25H2 への段階展開を継続 |
| 社内説明 | 「26H1 は既存PC向けの次期更新ではない」と明記 |
| レポート | 26H1 を移行完了率に混ぜない |
| 問い合わせ対応 | 「自分のPCに 26H1 が来ないのは異常ではない」と案内 |
シナリオ：新しい Snapdragon 搭載PCを評価する
この場合は、26H1 を無視できません。
Microsoft は、少なくとも記事公開時点で Qualcomm Snapdragon X2 Series processors 搭載デバイスが 26H1 とともに提供されると説明しています。新しいハードウェアの性能、バッテリー、AI機能、モバイル利用に期待する部門では、26H1 搭載端末が評価対象になります。(aka.ms)
ただし、評価では「速いか」「軽いか」だけを見ないでください。企業利用では、次の順に検証するのが現実的です。
| 検証段階 | 確認内容 |
|---|---|
| 受け入れ | Autopilot 登録、Intune 登録、Entra ID 参加、BitLocker、EDR |
| 基本業務 | Microsoft 365、Teams、ブラウザ、VPN、プリンタ |
| 部門業務 | 業務アプリ、SaaS、ローカルツール、Officeアドイン |
| 障害対応 | リモート支援、ログ取得、初期化、交換手順 |
| 展開判断 | どの部門に何台まで許可するかを決める |
シナリオ：標準端末を厳密に統一している
金融、製造、医療、公共系など、端末標準化の重要度が高い環境では、26H1 は慎重に扱うべきです。
標準化された環境では、1つの例外端末がヘルプデスク、監査、パッチ管理、アプリ検証の負担を増やします。26H1 端末を導入する場合は、標準端末ではなく例外端末として、承認フローを別にするほうが安全です。
おすすめの運用は次の通りです。
| ルール | 内容 |
|---|---|
| 標準端末 | 24H2 / 25H2 搭載モデルを維持 |
| 例外端末 | 26H1 搭載機はIT承認制にする |
| 台帳 | OSバージョン、CPU、利用部門、用途を記録 |
| サポート | ヘルプデスクの一次対応範囲を明確化 |
| 更新 | 月例更新は管理対象にするが、機能更新の扱いは別管理 |
シナリオ：MSP が複数顧客を管理している
MSP や情シス代行の現場では、26H1 の命名が特に混乱を生みやすいです。顧客ごとに調達経路が違い、ある顧客では 25H2、別の顧客では 26H1 搭載新型機が突然入ってくる可能性があります。
MSP では、顧客共通の管理基準に次の文言を入れると実務が安定します。
| 項目 | 推奨ルール |
|---|---|
| 標準OS | 原則 24H2 / 25H2 |
| 26H1 | 新ハードウェア向けの個別承認対象 |
| レポート | 26H1 は標準移行率から分離 |
| サービス範囲 | 26H1 搭載端末のサポート可否を契約・SLAに明記 |
| 顧客説明 | 「Windows Updateで配られる次期版ではない」と説明 |
26H1 でやってはいけない判断
26H1 の rollout で失敗しやすいのは、技術的な作業そのものより、前提の置き方です。
| やってはいけない判断 | なぜ危険か | 正しい判断 |
|---|---|---|
| 25H2 の次は 26H1 だから全社計画に入れる | 26H1 は既存端末向けの通常更新ではない | 24H2 / 25H2 の標準運用を継続する |
| 新しいOSだから標準端末にする | 管理・互換性・更新パスの例外が増える | 新ハードウェア評価枠として扱う |
| Windows Update に出ないので無視する | 新規購入端末として入ってくる可能性がある | 調達・資産管理で検出する |
| 月例更新が管理できるので既存リングに混ぜる | レポートや問い合わせで混乱する | 専用グループやタグで分類する |
| アプリ検証を省略する | デバイス差分やドライバー差分が影響する | 重要アプリから優先検証する |
| ユーザー説明をしない | 「自分のPCだけ更新できない」という問い合わせが増える | FAQやITポータルで先に説明する |
特に注意したいのは、「Windows Update に出ないなら何もしなくてよい」という誤解です。既存端末への配布はなくても、新規調達端末として組織に入ってくる可能性はあります。管理者の仕事は、26H1 を配ることではなく、26H1 搭載端末を見落とさず、適切に分類することです。
実務で使える 26H1 対応チェックリスト
26H1 対応は、大がかりなプロジェクトにする必要はありません。まずは次のチェックリストを使って、既存ワークフローに不足している項目を確認しましょう。
| チェック項目 | 完了の目安 |
|---|---|
| 26H1 が既存PC向け Windows Update 配布ではないことをIT部門内で共有した | 管理者、ヘルプデスク、購買担当が同じ説明をできる |
| 標準OSを 24H2 / 25H2 として明記した | 端末標準仕様書や展開計画に反映されている |
| 26H1 搭載端末の調達ルールを作った | 購入前にIT承認または検証が入る |
| Intune / Autopatch / Configuration Manager で 26H1 端末を識別できる | グループ、タグ、フィルター、レポートで分離できる |
| 重要アプリの検証優先順位を決めた | VPN、EDR、認証、基幹アプリから確認できる |
| ユーザー向けFAQを作成した | 「なぜ自分のPCに 26H1 が来ないのか」に答えられる |
| 経営・監査向けレポートで 26H1 を別集計にした | 標準移行率と新ハードウェア評価を混同しない |
| 26H1 端末のサポート範囲を決めた | ヘルプデスクが一次対応できる範囲が明確 |
これから取るべき行動
Windows 11 version 26H1 deployment model の rollout は、既存デバイスへ一斉に展開するプロジェクトではありません。現場で必要なのは、26H1 を「特定の新ハードウェアに紐づく例外的な管理対象」として、調達・資産管理・更新管理・アプリ検証・ユーザー説明に組み込むことです。
まずは、既存の 24H2 / 25H2 展開計画を止めずに進めてください。そのうえで、新規購入端末の仕様確認、26H1 搭載機の識別、専用グループ化、重要アプリの検証、社内FAQの整備を行います。
26H1 を「配るべきOS」と見ると混乱します。
26H1 を「入ってくる可能性のある新ハードウェア環境」と見れば、現場のワークフローは整理できます。
コメント