Windows 10 のサポートは 2025 年 10 月 14 日で終了し、企業環境では計画的な Windows 11 への移行が必須になりました。この記事では、既存の WSUS(Windows Server Update Services)を使って、Windows 10 クライアントを Windows 11 へ段階的かつ安全にアップグレード展開するための実践的な手順と運用のポイントを詳しく解説します。
WSUSでWindows 10 → 11 を展開できるのか
結論から言うと、WSUS だけで Windows 10 から Windows 11 へのインプレースアップグレード配布は可能です。キーになるのは次の 2 点です。
- WSUS の 製品 に「Windows 11」および「Windows 11 Client, version XXH2 and later」などを有効化すること
- WSUS の 分類 で「Upgrades(機能更新プログラム)」を有効化して同期し、該当の Windows 11 アップグレードを承認すること
この設定を行うと、WSUS 上には「Upgrade to Windows 11 (business editions), version 23H2, x64」のような、Windows 10 から 11 への機能更新プログラムが「Upgrades」ビューに現れます。あとは従来の Windows 10 機能更新と同様に、コンピューターグループ単位で承認すれば配布可能です。
全体の流れを整理すると、以下のステップになります。
- 事前準備:ハードウェア要件の確認・OS/アーキテクチャ整理・WSUS 健全性チェック
- WSUS で「製品と分類」を設定(Windows 11 / Upgrades 有効化)
- 同期を実行し、Windows 11 関連のアップグレードを取得
- アップグレードをパイロットグループから順に承認(リング展開)
- GPO でクライアントに WSUS の URL・自動更新ポリシーを配布
- 展開状況を WSUS レポートとクライアントログで監視し、トラブルを切り分け
事前確認と環境整理
Windows 11 ハードウェア要件の確認
WSUS で配布できても、端末のハードウェアが Windows 11 要件を満たしていないとアップグレードはブロックされます。Windows 11 の主な要件は以下の通りです。
| 項目 | 最低要件の目安 | 代表的な確認方法 |
|---|---|---|
| CPU | 1GHz / 2 コア以上かつ Microsoft 公開の対応 CPU 一覧に含まれる CPU | デバイス マネージャー、winver+メーカー一覧、資産管理ツール |
| メモリ | 4GB 以上(実運用では 8GB 以上推奨) | システムのプロパティ、資産管理ツール |
| ストレージ | 64GB 以上の空き容量(アップグレードではさらに余裕を確保) | エクスプローラー、ストレージレポート |
| TPM | TPM 2.0 が有効化されていること | tpm.msc、PC Health Check アプリ |
| Secure Boot | UEFI+Secure Boot が有効 | msinfo32(セキュア ブートの状態)、ファームウェア設定 |
少数台なら PC Health Check アプリで個別確認も可能ですが、企業環境では PowerShell スクリプトや Intune / Endpoint Analytics などで 「Windows 11 対応可否レポート」を作る方が現実的です。
対象 OS・エディション・アーキテクチャの棚卸し
次に、現状のクライアント OS と最低限どこまで上げたいかを整理します。
| 項目 | 例 | 備考 |
|---|---|---|
| 現行 OS | Windows 10 Enterprise 22H2 x64 | ESU で延命するか、すべて Windows 11 に移行するか方針を決める |
| 移行先 OS | Windows 11 Enterprise 23H2 / 24H2 / 25H2 など | サポート期間を踏まえ、できるだけ新しいバージョンへ |
| エディション | Pro / Enterprise / Education 等 | 同一エディション間でのインプレースアップグレードが基本 |
| アーキテクチャ | x64 / ARM64 | WSUS で承認するパッケージのアーキテクチャと一致させる |
たとえば「Windows 10 Enterprise 22H2 x64 → Windows 11 Enterprise 23H2 x64」のように、現状とターゲットをセットで定義しておくと、WSUS 上で探すべきアップグレード名を迷わず選べます。
WSUS サーバーの健全性チェック
長年運用している WSUS は、不要な更新やインデックス肥大で著しく遅くなっていることが多く、そのまま大型の機能更新を同期すると失敗やタイムアウトの原因になります。WSUS 専門ベンダーのベストプラクティスでも、定期的なデータベースの最適化や不要な更新の整理が推奨されています。
| チェック項目 | ポイント | 代表的な対策 |
|---|---|---|
| 最新更新プログラムの適用 | WSUS サーバー OS の累積更新を最新に | Windows Update / オフラインパッケージで更新 |
| 不要な製品・分類 | 使っていない OS / Office / ドライバー を外す | 製品と分類の見直し、不要なものを削除 |
| DB・コンテンツの肥大 | 古い更新やドライバーが大量に残っている | WSUS クリーンアップウィザード、専用メンテナンスツールの活用 |
| バックアップ | 大きな変更前にスナップショットを取得 | 仮想基盤のスナップショット、DB バックアップ |
Windows 11 アップグレード用の同期を開始する前に、最低限これらのメンテナンスを済ませておくと、後のトラブルを大きく減らせます。
WSUS の「製品と分類」設定
準備ができたら、WSUS に Windows 11 のアップグレードを流し込むための基本設定を行います。
Products(製品)の設定
- WSUS 管理コンソールを開きます。
- 左ペインでサーバー名を選択し、右ペインの [Options] をクリックします。
- [Products and Classifications] を開き、[Products] タブを選択します。
ここで、少なくとも次の製品にチェックが入っていることを確認します。
- Windows 11
- Windows 11 Client, version 22H2 and later
- 必要に応じて、Windows 11, version 23H2 / 24H2 / 25H2 など、特定バージョン向けの製品
- ドライバーも WSUS で管理する場合のみ、Windows 11 Client, version XXH2 and later, Upgrade & Servicing Drivers
Windows 11 向けの新しいバージョン(例:24H2、25H2)がリリースされると、対応する製品が追加されます。最小限必要なものだけに絞ることで、同期とデータベース負荷を抑えられます。
Classifications(分類)の設定
同じダイアログの [Classifications] タブで、少なくとも次の分類にチェックします。
- Security Updates(日常運用)
- Critical Updates(日常運用)
- Update Rollups(任意)
- Upgrades(Windows 11 への機能更新に必須)
- ドライバーも配布する場合のみ Drivers
特に重要なのは Upgrades で、これを有効化しないと Windows 11 へのアップグレードが WSUS に一切現れません。
| 用途 | 必須の製品 | 必須の分類 |
|---|---|---|
| 日常パッチ管理(Windows 10/11) | Windows 10, Windows 11 | Security Updates, Critical Updates, Update Rollups など |
| Windows 10 → 11 アップグレード | Windows 11, Windows 11 Client, version 22H2 and later など | Upgrades |
同期(Sync)で Windows 11 アップグレードを取得
製品と分類を設定したら、WSUS に最新の更新情報を取りに行かせます。
- WSUS コンソール左ペインでサーバー名を右クリックし、[Synchronizations] を選択します。
- 右ペインの [Synchronize Now] をクリックします。
初回の全同期は時間がかかることがあります。サーバーの CPU / I/O 負荷が高まるため、夜間・休日などに実行するのがおすすめです。
同期が完了したら、[Updates] → [Upgrades] ビューを開き、「Windows 11」関連のアップグレードが取得できているか確認します。
Windows 11 アップグレードを承認し、リング展開を設計する
対象アップグレードの選定
[Updates] → [Upgrades] ビューで、検索ボックスに Windows 11 や Upgrade to Windows 11 などを入力して対象のパッケージを絞り込みます。
典型的な名前の例:
Upgrade to Windows 11 (business editions), version 23H2, x64Upgrade to Windows 11 (business editions), version 24H2, x64
企業環境では通常、「business editions」かつ x64 のパッケージを使用します(ARM64 端末がある場合は ARM64 も別途)。
重要:1 台のクライアントに対して 複数の機能更新(Upgrades)を同時に承認しないでください。Microsoft のガイドでも、1 コンピューターあたり 1 つの機能更新のみを承認することが推奨されています。複数を承認すると、クライアント側でエラーや意図しないバージョンへのアップグレードが発生し得ます。
パイロット → 段階展開(リング方式)の設計
いきなり全台に承認するのではなく、WSUS のコンピューターグループを使って リング展開を行うのが安全です。
| リング | グループ名の例 | 対象台数の目安 | 承認タイミング |
|---|---|---|---|
| Ring 0 | Pilot-Win11-IT | IT 部門・情シスの PC 数台〜十数台 | 最初に承認。全工程と不具合傾向を確認 |
| Ring 1 | Pilot-Win11-Business | 主な部門から数台ずつ(合計 5〜10%) | Ring 0 で問題がなければ 1〜2 週間後 |
| Ring 2 | Win11-Broad | 全体の 60〜80% | 業務影響がなければ数週間後に承認 |
| Ring 3 | Win11-LongTail | 特殊アプリ・拠点・役員端末 | 最後に個別調整しながら承認 |
各リングは WSUS のコンピューターグループで事前に整理しておき、「Upgrade to Windows 11 ~」を グループ単位で順番に承認していきます。
クライアント側のグループポリシー(GPO)設定
ドメイン環境では、GPO を使ってクライアントが確実に WSUS を向くように設定します。ここが曖昧だと、一部の端末がインターネットの Windows Update から直接 11 に上がってしまう…といったことが起こり得ます。
社内の Microsoft 更新サービスの場所を指定する
ポリシー パス:
- コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → Windows Update → Windows Server Update Service から提供される更新プログラムの管理(または同等の名称)
| ポリシー名 | 推奨設定 | ポイント |
|---|---|---|
| 社内の Microsoft 更新サービスの場所を指定する | 有効 / Intranet 更新サービスと統計サーバーに http(s)://wsusサーバーFQDN:ポート | IP ではなく FQDN を使用し、末尾のスラッシュは付けないのがベストプラクティス |
| イントラネットの Microsoft 更新サービスの検出頻度を指定する | 3~6 時間ごとなど、環境に合わせて | テスト期間中は短め、本番ではサーバー負荷と相談 |
自動更新の動作(インストールタイミング)
ポリシー パス:
- コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → Windows Update
| ポリシー名 | 推奨値の一例 | 説明 |
|---|---|---|
| 自動更新を構成する | 有効 / 「4 – 自動ダウンロードしインストールをスケジュール」 | 夜間など、業務に支障の少ない時間帯にインストールを集中させる |
| 自動メンテナンスの有効時刻を指定する | 02:00〜04:00 など | 再起動を伴うアップグレードがこの時間帯に走るよう調整 |
| 再起動の自動実行を許可する(ログオン中ユーザーあり) | ユーザー通知を行い、再起動延期の回数上限を決める | 役員端末や会議室 PC などは別ポリシーでより慎重に制御 |
Windows Update for Business(WUfB)との関係
WUfB を併用している環境では、「更新の取得元」と「ターゲットバージョン指定」のポリシー競合に注意が必要です。たとえば、次のようなポリシーは WUfB 向けの設定です。
- 対象とする機能更新プログラムのバージョンを選択する(Select the target Feature Update version)
- プロダクト バージョン(Windows 10 / Windows 11)の指定
WSUS による承認配布をメインにする場合は、これら WUfB ポリシーを無効化するか未構成にし、WSUS の承認状況だけで配布を制御する構成がシンプルです。
展開と監視:現場で確認すべきポイント
クライアント側の動作イメージ
WSUS から Windows 11 アップグレードが配布されると、クライアントは大まかに次の流れで動作します。
- WSUS に対して更新の検出(Scan)
- 該当する Upgrades のダウンロード
- インストールの準備(互換性チェック・ファイル展開)
- 再起動を伴うセットアップ(Windows 11 への切り替え)
- 初回サインイン後の最終構成
ユーザー視点では「更新が溜まっていると思ったら、大型アップデートがかかって再起動が増えた」という見え方になるため、事前の周知と再起動タイミングの説明が重要です。
WSUS コンソールでの進捗確認
WSUS 側では、次のビューで大まかな進捗が把握できます。
- [Computers]:グループごとに「Needed / Installed / Failed」などの状態を確認
- [Reports]:更新ステータスのレポートを出力(グループ単位や特定アップデート単位)
| 項目 | 確認内容 | 想定されるアクション |
|---|---|---|
| Needed が多い | 対象端末がアップグレードを検出しているが未インストール | GPO 配布・検出頻度・ディスク容量・業務時間帯の調整 |
| Failed が増えている | 互換性エラーやセットアップエラーが発生 | クライアントログ(後述)でエラーコードを特定 |
クライアントログと SetupDiag の活用
アップグレードに失敗した場合は、クライアント側のログを確認します。Windows 10/11 では、Microsoft が提供している SetupDiag ツールを使うと、失敗理由を自動解析できます。
| 確認場所 | パス / ログ | 用途 |
|---|---|---|
| イベントログ | アプリケーションとサービス ログ → Microsoft → Windows → WindowsUpdateClient / Setup など | 更新の検出状況、エラーコードの確認 |
| セットアップログ | C:\$Windows.~BT\Sources\Panther\setupact.log / setuperr.log など | アップグレードのどのフェーズで失敗したかを確認 |
| SetupDiag | SetupDiag.exe を実行し SetupDiagResults.log を確認 | 既知の失敗パターンと照らし合わせたエラー理由の要約 |
「インストールは失敗しました – エラー 0xC1900101」のような典型的なエラーは、ドライバーやストレージなど原因がある程度パターン化されているため、SetupDiag の結果と Microsoft のドキュメントを併せて確認すると対処方針を立てやすくなります。
手動で検出・インストールを促すコマンド
テスト環境や一部端末で動作を急いで確認したい場合は、クライアント上で次のようなコマンドを実行します(管理者権限の PowerShell / コマンド プロンプト)。
| コマンド | 用途 | 備考 |
|---|---|---|
UsoClient StartScan | 更新の検出を即時実行 | Windows 10/11 で使われる内部 API。将来仕様変更の可能性あり |
UsoClient StartDownload | 検出済み更新のダウンロードを開始 | テスト時の動作確認に有用 |
UsoClient StartInstall | ダウンロード済み更新のインストールを開始 | ユーザーへの影響に注意して使用 |
wuauclt /reportnow | 旧来のクライアントで WSUS への状態報告を促す | レガシーコマンドだが一部シナリオで有効 |
これらのコマンドはあくまでテスト用の補助と考え、本番運用では GPO と自動スケジュールを基本にする方が安定します。
よくあるつまずきと対処の考え方
アップグレードが WSUS に一覧表示されない
次のポイントを順番に確認します。
- 「製品と分類」で Windows 11 / Upgrades が有効化されているか
- 同期が正常に完了しているか(Synchronizations の結果を確認)
- Windows 11 24H2 / 25H2 など、新しいバージョンの製品チェックが不足していないか
- WSUS データベースの肥大によりパフォーマンスが極端に低下していないか(メンテナンスの実施)
- サーバーのプロキシやファイアウォールで Microsoft Update への通信がブロックされていないか
クライアントがアップグレードを検出しない
- クライアントが正しく WSUS を参照しているか(レジストリ
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateの URL を確認) - コンピューターグループの割り当てが正しいか(自動割り当てを使うか、手動か)
- 対象の Upgrades がそのグループに「承認」されているか
- ハードウェア要件を満たしており、互換性ブロックが発生していないか(PC Health Check やレポートで確認)
TPM / Secure Boot / CPU 互換性エラー
Windows 11 は TPM 2.0 や Secure Boot、対応 CPU を必須要件とする方針が再確認されており、今後も緩和されない見込みです。
- BIOS/UEFI で TPM 2.0 と Secure Boot を有効化できるか確認(MBR→GPT 変換が必要な場合もあり)
- どうしても要件を満たせない旧式端末は、Windows 10 の ESU 契約や買い替えを含めた運用方針を検討
- 非公式なバイパスツールはマルウェア混入リスクも報告されているため、企業環境では利用しないのが安全
帯域・時間が足りない(ネットワーク負荷)
- グループポリシーで BITS の帯域制限を行い、業務時間帯のダウンロード速度を絞る
- ブランチオフィスには下流 WSUS を置き、WAN 帯域の節約を図る
- リング展開を細かく分け、同時にアップグレードする台数を抑える
- ノート PC などは VPN 接続時の挙動を考慮し、社内接続時のメンテナンス時間を案内する
ドライバー絡みのトラブル
Windows 11 へのアップグレードと同時にドライバーも大幅更新すると、特定機種だけブルースクリーンや不安定さが出ることがあります。
- 最初は「Drivers」分類を外し、OS アップグレードだけを承認して様子を見る
- 問題のないことが確認できたら、必要なドライバーだけをピンポイントで承認
- GPU や NIC のように業務影響が大きいドライバーは、ベンダー提供ツールで別管理する選択肢も検討
運用のコツと中長期的な設計
製品・分類は「足るを知る」設定にする
WSUS には非常に多くの製品と分類がありますが、実際に社内で使っている OS / Office / ブラウザだけに絞り込むほど動作が軽くなり、トラブルも減ります。特に Windows 11 移行フェーズでは、次のような運用が現実的です。
- Windows 10 / 11 以外の OS は段階的に対象から外す
- テスト後に不要になった旧バージョンの Upgrades は期限を決めて非承認・削除
- 言語パックも、実際に利用する言語だけに限定(ja-JP と en-US など)
Windows 11 内でのバージョンアップも WSUS で継続管理
Windows 10 から 11 へのアップグレードが完了しても、Windows 11 内部での 23H2 → 24H2 → 25H2 といった機能更新は今後も継続します。これらは引き続き「製品:Windows 11」「分類:Upgrades」で WSUS から配布可能です。
一部のバージョンでは、既存の Windows 11 に対して「イネーブルメントパッケージ」で短時間に機能更新が行われるケースもあり、これも WSUS と連携するよう設計されています。
WSUS メンテナンスを定期タスクに組み込む
Windows 11 への移行プロジェクトをきっかけに、WSUS のメンテナンスを 月次 or 四半期タスクとしてルーチン化しておくと、長期的な安定運用につながります。
- クリーンアップ(不要な更新の削除・期限切れ更新の整理)
- データベースのインデックス最適化とサイズ確認
- ディスク容量監視(特に
WSUSContentフォルダー) - レポートを活用した「パッチ未適用端末」の洗い出し
Intune / WUfB との棲み分けを明確にする
クラウド管理への移行が進んでいる環境では、「Windows 11 の今後の機能更新は Intune(WUfB)で、当面の Windows 10 → 11 移行だけ WSUS で」といったハイブリッド構成もよくあります。
- どのデバイスが WSUS 管理で、どのデバイスが WUfB 管理かを CMDB などに明示
- 同じデバイスに対し、WSUS 用 GPO と WUfB 用ポリシーを重複適用しない
- 将来的にクラウド側へ全面移行する際は、WSUS の役割を「オンプレのみ」または「退役」に集約
参考になるガイド
- Microsoft 公式:WSUS での更新展開手順とベストプラクティス
- Prajwal Desai 氏:WSUS で Windows 11 を有効化し、最新バージョン(24H2 / 25H2)を同期する具体的手順
- AJ Tek:WSUS の自動メンテナンスとパフォーマンス最適化に関する詳細なガイド
- Windows 11 アップグレード失敗時のトラブルシューティング(SetupDiag / ログ解析)
まとめ:WSUS だけで Windows 11 へ安全に移行する
本記事で紹介したように、
- Windows 11 のハードウェア要件を満たしている端末を洗い出し
- WSUS の「製品:Windows 11」「分類:Upgrades」を有効化して同期
- 「Upgrade to Windows 11 (business editions)」をリング単位で承認
- GPO で WSUS の URL と自動更新ポリシーを配布
- WSUS レポートと SetupDiag でトラブルを監視・解析
という流れを守れば、WSUS だけで Windows 10 から 11 への大規模アップグレードを段階的かつ安全に実施できます。Windows 10 のサポート終了を機に、WSUS の整理とあわせて Windows 11 時代の更新管理体制を再設計してみてください。

コメント