Windows Server 2016 のWSUSを最新化しているのに、Windows 11 クライアントがすべて「Windows 10」と表示されて困っていませんか？この現象は更新配信の失敗ではなく、WSUSの表示仕様が原因です。仕組みと影響、見分け方と安全な補正方法を実務目線で整理します。
WSUSでWindows 11がWindows 10と表示される現象
WSUS（Windows Server Update Services）のコンソールでは、クライアント一覧に「OS（オペレーティング システム）」や「バージョン」といった列が表示されます。しかし環境によっては、Windows 11 を展開しているにもかかわらず、該当端末が一律で「Windows 10」と表示されることがあります。
まず押さえておきたいのは、表示がWindows 10でも、更新配信が壊れているとは限らないという点です。焦ってレジストリ改変やWSUSの再構築に進む前に、WSUSが何を根拠に「OS名」を表示しているのかを理解すると、切り分けが一気に楽になります。
結論：多くは「WSUSの表示仕様（ProductName参照）」が原因
WSUSがコンソールに表示するOS名は、クライアントが報告する情報のうち、レジストリの ProductName（製品名）に強く依存します。Windows 11 は内部的にNTバージョンが「10.0」のまま（互換性維持のため）であることも多く、環境やイメージ作成方法によっては ProductName が「Windows 10 Pro」等のまま残るケースがあります。その結果、WSUSではWindows 11端末がWindows 10として見えてしまいます。
| WSUSコンソール上の項目 | 実際に表しているもの | よくある誤解 | 運用での使いどころ |
|---|---|---|---|
| OS（例：Windows 10） | クライアント報告のOS名（ProductName等） | 「Windows 11なら必ずWindows 11と表示される」 | 大まかな把握。正確なOS判別には補助情報が必要 |
| バージョン | Windows Update Agent（WUA）側の情報として扱われることが多い | 「OSのバージョン（22H2等）を示す」 | 更新エージェントの状態目安。OS判別目的には不向き |
| 最終状態報告時刻 | クライアントがWSUSへ報告した最終時刻 | 「ここが新しければ更新適用も最新」 | 疎通確認・死活監視の切り口として有用 |
原因を深掘り：WSUSはどこからOS名を拾っているのか
WSUSはクライアントの「自己申告」をデータベース（SUSDB）に蓄積し、その値をコンソール表示に使います。自己申告の材料のひとつが、次のレジストリです。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
- ProductName
- CurrentBuild（BuildNumber）
- DisplayVersion
- UBR（更新リビジョン）実務的には、ProductName がWindows 10表記のままだと、WSUSのOS列もWindows 10になりやすい、という理解で問題ありません。WSUS側が「Windows 10/11を判別して賢く表示を変える」仕組みは基本的に持っていないためです。
クライアントでの確認（PowerShell例）
まずは実機（Windows 11側）で ProductName と Build を確認します。以下はローカル確認用の例です。
$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
$cv.ProductName
$cv.DisplayVersion
$cv.CurrentBuild
$cv.UBR| 項目 | 例 | 読み取りのポイント |
|---|---|---|
| ProductName | Windows 10 Pro / Windows 11 Pro | WSUSの「OS」表示に影響しやすい。Windows 11でもWindows 10表記のことがある |
| CurrentBuild | 19045 / 22000 / 22621 / 22631 など | Windows 10/11の大枠判別に使いやすい（ただし将来の体系変更には注意） |
| DisplayVersion | 21H2 / 22H2 / 23H2 / 24H2 など | 機能更新プログラムの世代。レポート用途に便利 |
| UBR | 累積更新のリビジョン番号 | 同一Build内での更新レベル比較に使える（Build + UBRで概ね特定可能） |
ビルド番号での判別早見表（運用に使える目安）
WSUS画面だけで判別できない時は、ビルド帯を「実務上の目安」にすると現場は回ります。代表的な目安をまとめます（端末の更新状況や世代によって増減するため、定期的に見直してください）。
| OSの目安 | 代表的なBuild帯（例） | 現場での使い方 |
|---|---|---|
| Windows 10 | 1904x / 19045 など | 22000未満ならWindows 10として扱う、などのルール化に使う |
| Windows 11（初期〜） | 22000系 | 「Windows 11が混ざっているか」の一次判定に便利 |
| Windows 11（22H2/23H2世代の例） | 22621/22631系 | 同じWindows 11でも世代差（機能更新適用済みか）を見たい時に使う |
| Windows 11（さらに新しい世代の例） | 26000系など | 将来の世代で閾値が変わる可能性に備え、例外扱いの監視に使う |
「表示だけの問題」になりやすい理由：更新の適用判定は別ロジック
WSUSはコンソールの表示名とは別に、更新プログラムのメタデータ（適用条件）とクライアントの報告情報を突き合わせて、どの更新を提示するかを決めます。ここで重要なのは、Windows 11端末がWindows 10と表示されていても、内部的にはWindows 11用更新が適切に提案されるケースが多いことです。
| 観点 | 表示名がWindows 10のまま | 実際の更新配信への影響 |
|---|---|---|
| 品質更新（累積更新） | あり得る | 多くの場合、問題なく配信・適用される |
| 定義更新（Defender等） | あり得る | OS名表示に依存しにくく、通常は問題になりにくい |
| 機能更新（Windows 10→11） | あり得る | 製品/分類やUUP設定、前提更新が整っていないと別要因で詰まりやすい |
つまり、運用の悩みは「配信できない」よりも、管理画面でWindows 11が判別できない・レポートが混在するといった管理性の問題に寄りがちです。
対応方針A：仕様として受け入れ、見分け方を用意する（安全重視）
最も安全で、将来トラブルになりにくいのは「表示は割り切り、Windows 11を別軸で判別する」運用です。WSUSは更新の中継点であり、資産管理ツールではありません。表示の整合よりも、更新配信の健全性と運用の再現性を優先すると失敗しにくくなります。
WSUS上での現実的な見分け方
- ビルド番号（22000系/22621系など）で推測する
- コンピューターグループをWindows 11用に分ける（後述）
- レポートはWSUS単体に寄せず、PowerShellや資産管理で補完する
おすすめ：Windows 11専用の「コンピューターグループ」を作る
WSUSコンソールの表示名が当てにならないなら、グループ分けを「OS名」ではなく「所属ルール」で作るのが実務的です。代表例が、GPOの「クライアント側ターゲット」を使って端末を自動振り分けする方法です。
| 方法 | 概要 | メリット | 注意点 |
|---|---|---|---|
| GPOのクライアント側ターゲット | 端末側でWSUSグループ名を指定し、WSUSに自動登録 | WSUS上でWindows 11グループを簡単に作れる | グループ名の統一、GPO適用漏れの監視が必要 |
| WMIフィルター併用 | ビルド番号などでWindows 11端末だけにGPOを適用 | Windows 10/11混在でも自動で振り分けやすい | 将来のビルド規則変更に備え、見直し運用が必要 |
GPO設定例（クライアント側ターゲット）
クライアント側ターゲットを使う場合、WSUSサーバーURLの指定と合わせて、次のポリシーを押さえると運用が安定します（名称は管理用テンプレートの言語/バージョンで多少変わります）。
- 「イントラネットのMicrosoft更新サービスの場所を指定する」：WSUSのURLを設定
- 「クライアント側ターゲット」：有効にしてグループ名（例：Windows11）を指定
WSUS側のオプション（コンピューターの割り当て方法）も「グループ ポリシーまたはレジストリ設定を使用する」側に合わせておくと、意図どおりにグループが自動振り分けされます。
WMIフィルター例（Windows 11端末だけに適用）
「BuildNumberが22000以上」をWindows 11とみなす、よく使われるWMIフィルター例です。Windows 10のBuildが190xx帯である間は判別しやすい一方、将来の体系変更に備えたレビューは必須です。
SELECT * FROM Win32_OperatingSystem WHERE BuildNumber >= "22000"このWMIフィルターを紐づけたGPOで、WSUSのターゲットグループ（例：Windows11）を指定すれば、WSUS上では「OS名がWindows 10に見えていても」Windows 11端末だけをグルーピングできます。表示に振り回されず、承認運用（Approve）や段階展開（パイロット→本番）も設計しやすくなります。
レジストリ（ProductName）を書き換えない方がよい理由
ProductNameを「Windows 11」に変えればWSUS表示も直りそうに見えますが、OSの識別子に近い領域を直接変更するのはおすすめしません。
- 将来の機能更新や累積更新で上書き・巻き戻りが起きる可能性がある
- サポート調査時に「標準状態ではない」ことがノイズになる
- アプリ互換や社内スクリプトがProductNameを参照していると副作用が出る
「表示のためだけに、OSの中核情報を改変する」より、判別ロジックを別に持つ方が長期的に安定します。
対応方針B：サードパーティ製ツールで表示名を補正する
WSUSのメンテナンスを自動化する有償ツールの中には、WSUS内のOS表示名を補正（リネーム）できるものがあります。たとえば、WSUSのクリーンアップや同期後処理をまとめて面倒見たい組織では、こうした製品を導入するケースもあります。
- メリット：導入後は運用負荷が下がり、WSUSメンテが属人化しにくい
- デメリット：費用、導入審査、サポート窓口（Microsoft公式ではない）
「表示名だけ」目的だと費用対効果が合わないこともあるため、クリーンアップ自動化やDB最適化など、周辺課題もまとめて解決したい場合に検討すると納得感が出ます。
対応方針C：無償PowerShellでWSUSデータベース側のOS情報を更新する
「レジストリ改変は避けたい」「有償ツールも入れたくない」「それでもWSUS画面ではWindows 11と表示したい」という場合、WSUSデータベース（SUSDB）側のOS表示を補正するスクリプト運用が現実的です。代表例として、GitHubで公開されている Update-WSUSComputerOperatingSystems などのスクリプトが使われることがあります。
この方式の考え方（何を直しているのか）
ポイントは、クライアントのレジストリやOS自体をいじるのではなく、WSUSが保持している「表示用のOS情報」を更新する点です。WSUSはクライアントから再報告が来ると元に戻ることもあるため、安定運用には定期実行が向きます。
| 項目 | 内容 |
|---|---|
| 更新対象 | WSUSサーバー側（SUSDB）のコンピューターOS表示情報 |
| クライアント側への変更 | 基本なし（ProductName等は触らない運用が多い） |
| 効果 | WSUSコンソール上でWindows 11として見えやすくなる |
| 留意点 | DB直接更新のため、権限・バックアップ・検証が必須 |
作業手順の例（安全に進めるための流れ）
- WSUSサーバーのSUSDBをバックアップする（WID/SQLの方式に合わせる）
- 検証環境でスクリプトを実行し、表示が意図どおりに変わるか確認する
- 本番では、まず「読み取りのみ/レポートのみ」モードがあるならそれで実行し、変更対象を把握する
- 問題がないことを確認してから更新処理を実行し、ログを保全する
- 同期スケジュールに合わせてタスク化し、失敗通知まで作る
事前準備：SqlServer PowerShellモジュールの用意
多くのスクリプトは Invoke-Sqlcmd を使ってSUSDBへクエリを投げます。そのため、WSUSサーバーで SqlServer モジュールが必要になります。管理者PowerShellで次を実行し、導入・更新してください。
# インストール（未導入の場合）
Install-Module -Name SqlServer -Scope AllUsers -Force -AllowClobber
# 導入確認
Get-Module -ListAvailable SqlServer環境によっては、古いモジュールのままだと Invoke-Sqlcmd 実行時に「Optional を受け付けない」といった引数解釈エラーが出ることがあります。まずはSqlServerモジュールを最新化してから検証に入ると、無駄なハマりを減らせます。
WSUSがWIDかSQL Serverかで接続先が変わる
WSUSのデータベースは、Windows Internal Database（WID）かSQL Serverのどちらかで動いています。接続先の考え方が変わるため、まずは自環境がどちらかを確認してください。
| パターン | よくある構成 | 接続のイメージ |
|---|---|---|
| WID（Windows Internal Database） | 小〜中規模、WSUS単体サーバー | 名前付きパイプ（例：MICROSOFT##WID）で接続 |
| SQL Server | 規模が大きい、DBサーバー分離 | SQLインスタンス名（例：SQL01\INSTANCE）で接続 |
WID構成での接続文字列（例）として、次のような名前付きパイプが使われることがあります（環境依存のため、スクリプトのヘルプや既存設定と合わせて確認してください）。
np:\\.\pipe\MICROSOFT##WID\tsql\query実行前にやるべき3つの安全策
- SUSDBのバックアップ：少なくとも実行前スナップショット相当を確保
- 検証環境で試す：本番と同じWSUS構成（WID/SQL、同期設定）で再現確認
- 適切な権限で実行する：途中失敗→データ不整合を避ける（権限不足は失敗の元）
タスクスケジューラでの定期実行（運用テンプレ）
「一度直して終わり」ではなく、同期・状態報告のたびに表示が戻る可能性を考えると、定期実行が向きます。以下はよくある運用例です。
| 項目 | 推奨例 | 理由 |
|---|---|---|
| 実行タイミング | 毎日1回（WSUS同期後） | 新規端末や再報告で混在する前に補正 |
| 実行アカウント | WSUS管理者＋DBアクセス権を持つ専用アカウント | 権限不足による失敗を防ぎ、監査もしやすい |
| ログ | 標準出力をファイルへ、イベントログへ記録 | 「いつから表示が戻ったか」を追える |
| 失敗時の通知 | タスク失敗を監視（監視ソフト/メール/Teams等） | サイレント失敗で混在が進むのを防ぐ |
3つの対応パターンを比較（どれを選ぶべきか）
| パターン | コスト | 安全性 | 表示の正確さ | おすすめの状況 |
|---|---|---|---|---|
| A：仕様として受け入れる（判別を工夫） | 低 | 高 | 表示は割り切り | 更新配信が安定しており、運用トラブルを増やしたくない |
| B：有償ツールで補正 | 中〜高 | 中（製品品質次第） | 高 | WSUSメンテを自動化したい、属人化をなくしたい |
| C：無償スクリプトでWSUS DBを補正 | 低 | 中（DB更新リスクあり） | 高 | 表示を整えたいがコストはかけたくない。検証とバックアップ運用が可能 |
補足：表示問題と混同しやすい「Windows 11更新が当たらない」ケースの切り分け
今回のテーマは「OS名がWindows 10に見える」表示の話ですが、現場では「Windows 11 と表示されない＝Windows 11用更新が来ていないのでは？」と混同されがちです。もし実際に更新配信がうまくいっていないなら、表示問題とは別に次を確認してください。
| 症状 | まず疑うポイント | 確認の具体例 |
|---|---|---|
| Windows 11向け累積更新が配信されない | 製品/分類の選択漏れ | WSUSオプションで「Windows 11」が有効か、分類（セキュリティ更新等）が有効か |
| 機能更新（10→11）が出てこない | 機能更新の分類、前提更新、UUP関連 | 機能更新カテゴリを許可しているか、必要な前提（SSU等）が適用済みか |
| 端末がWSUSに出てこない/更新状態が古い | GPO設定、通信、WUAサービス | WSUSサーバーURL、プロキシ、ファイアウォール、Windows Updateサービスの状態 |
| 承認してもインストールされない | クライアント側のポリシーと検出 | 更新の検出タイミング、アクティブ時間、再起動制御、エラーコードの確認 |
クライアントの「報告が止まっている」時の最低限チェック
- WSUSサーバーへHTTP/HTTPS到達できるか（名前解決・証明書・プロキシ含む）
- Windows Update関連サービス（wuauserv、BITS）が停止していないか
- イベントログ（WindowsUpdateClient）に致命的エラーが出ていないか
- 必要に応じて
Get-WindowsUpdateLogでログを生成して原因を特定する
運用の落とし穴：Windows 10/11混在環境で「表示」に依存した承認をしない
表示名が混在している環境で、WSUSのOS列だけを根拠に承認（Approve）を行うと、意図しない端末へ更新を当てたり、逆に当てたい端末を漏らしたりします。特に段階展開をしている場合は、次のようなルールを決めておくと事故を防げます。
- 承認は「コンピューターグループ」に対して行い、OS列は参考情報に留める
- Windows 11グループはGPO/WMI等の客観的条件で自動振り分けする
- 月例の前後で「グループ内のBuild分布」を確認し、想定外の端末が混ざっていないか監査する
まとめ：表示に振り回されず、運用で勝つ
- WSUSでWindows 11がWindows 10と表示されるのは、クライアント報告の ProductName に依存するため起きやすい
- 多くの場合、更新配信自体は問題なく動作し、困るのは主に管理性（判別・レポート）
- 安全第一なら、レジストリ改変は避け、Build番号やGPOのターゲットでWindows 11を切り分ける
- どうしても表示を整えたい場合は、有償ツールか無償PowerShellスクリプト＋SqlServerモジュールでWSUS側表示を補正する
「表示が直らない＝更新が失敗している」と短絡せず、まずは配信の健全性（同期・承認・適用）を確認しつつ、必要に応じて表示補正の手段を選ぶのが、Windows 10/11混在環境のWSUS運用では最も堅実です。
コメント