Windows 11 環境で「Microsoft 倉頡（Changjie）入力」の不具合を修正する KB5062663／KB5062660 を導入しようとしても、「Microsoft のドキュメント上は WSUS から配布可能と書いてあるのに、WSUS でいくら同期しても更新が見つからない」という相談が増えています。本記事では、その原因となる WSUS の分類設定とプレビュー更新の扱いを整理しつつ、実際の対処手順と運用上の注意点を、管理者目線で詳しく解説します。
WSUSでKB5062663／KB5062660が見つからない状況とは
まず、どのような環境・前提で「KB5062663／KB5062660がWSUSに出てこない」問題が起きやすいのかを整理します。
- 対象クライアントは主に Windows 11（22H2 / 23H2 / 24H2）
- 中国語入力で使われる「Microsoft 倉頡（Changjie）入力」に不具合があり、修正パッチを適用したい
- Microsoft のドキュメントやサポート情報には「WSUS / Windows Update for Business 経由で配布可能」と記載されている
- しかし WSUS コンソール上で KB5062663／KB5062660 を検索してもヒットしない
- WSUS の同期自体は成功しており、通常のセキュリティ更新や累積更新（LCU）は問題なく流れている
見た目上は「WSUS の同期は正常なのに、特定の KB だけ見えない」ため、ネットワークやプロキシ、WSUS データベースの不具合を疑いがちですが、多くの場合は WSUS の分類（Classifications）設定が原因です。
発生している症状の典型例
典型的には、以下のようなパターンがよく見られます。
- 「製品と分類」は以前から変更しておらず、長年同じポリシーで運用している
- 「セキュリティ更新」「重要な更新」だけにチェックを入れて同期している
- Windows 11 の累積更新（セキュリティ含む）は問題なく WSUS に現れている
- しかし KB5062663／KB5062660 を検索しても 0 件のまま
- Microsoft Update カタログから個別に .msu をダウンロードすると、対象端末には適用できる
この時点で分かることは、「Microsoft Update カタログ上には更新が存在するが、自社 WSUS ではそれが同期対象になっていない」という点です。
Changjie入力不具合と修正パッチの位置づけ
問題となっている KB5062663／KB5062660 は、いずれも Windows 11 向けの更新プログラムで、「Microsoft 倉頡（Changjie）入力」で発生していた不具合を修正する目的で公開されています。中国語入力を日常的に利用するユーザーにとっては業務に直結するため、早期適用が求められる一方で、これらの更新はプレビュー品質更新（オプションの C/D 週アップデート）として提供されています。
つまり、月例パッチ（B 週のセキュリティ／品質ロールアップ）ではなく、任意で適用するテスト的な位置づけの更新であることがポイントです。この「プレビューであること」が、そのまま WSUS の分類設定に影響し、結果として「見つからない」原因になっています。
原因：プレビュー品質更新は「更新プログラム（Updates）」分類で配布される
結論から言うと、KB5062663／KB5062660 が WSUS 上で見つからない直接の原因は、これらが WSUS の分類上「更新プログラム（Updates）」扱いのプレビュー更新だからです。多くの企業環境の WSUS では、初期構築時に次のような方針が取られていることがよくあります。
- セキュリティリスクを抑えるため、配布対象は「セキュリティ更新」「重要な更新」に限定する
- 「更新プログラム（Updates）」や「プレビュー」は検証負荷が高いため、同期対象外にする
- ドライバーや Feature on Demand なども原則同期しない
このようなポリシー自体は珍しいものではなく、むしろ一般的なベストプラクティスの一つと言えます。しかし、今回のように特定機能の不具合修正がプレビュー更新として先行提供されるケースでは、WSUS 側で「更新プログラム（Updates）」の分類が同期対象になっていないと、そもそも KB が降りてきません。
Microsoftの月例更新サイクルとプレビュー更新の位置づけ
Microsoft が提供する Windows 更新プログラムのおおまかなサイクルと、WSUS 上の分類との対応イメージを以下の表に整理します。
| 週 | 更新の種類 | 内容の例 | WSUSの分類の傾向 |
|---|---|---|---|
| A 週（第1週） | 通常は大きなリリースなし | まれに緊急の Out-of-band 更新 | セキュリティ更新 / 更新プログラム |
| B 週（第2週） | 月例セキュリティ更新（Patch Tuesday） | 累積更新（LCU）、.NET 更新など | セキュリティ更新、重要な更新、更新プログラムのいずれか |
| C 週・D 週（第3・第4週） | プレビュー品質更新 | 来月の LCU に先行して入る修正群 | 更新プログラム（Updates）で出ることが多い |
KB5062663／KB5062660 はまさにこの「C/D 週のプレビュー品質更新」に位置づけられており、WSUS ではセキュリティ更新ではなく「更新プログラム（Updates）」として分類されるため、既定設定のままでは同期されていないことが多いのです。
WSUSの分類マッピングのイメージ
WSUS の「製品と分類」で選択できる主な分類と、実際の用途イメージを簡単にまとめます。
| 分類 | 代表的な更新 | 企業WSUSの典型的な扱い |
|---|---|---|
| セキュリティ更新 | 月例セキュリティ修正、Zero-day 対応など | ほぼ必ず同期・配布対象 |
| 重要な更新 | 安定性向上のための重要な修正 | 多くの環境で同期対象 |
| 更新プログラム（Updates） | プレビュー品質更新、通常の品質改善 | 意図的に外している環境が多い |
| 更新プログラムのロールアップ | ロールアップ型のパッチ (主に Server / 古い OS) | 環境によりけり |
| ドライバー | Windows Update 経由のデバイスドライバー | 多くの企業では同期対象外 |
このように、プレビュー更新は多くの場合「更新プログラム（Updates）」に分類されるため、ここを同期対象に含めない限り、KB5062663／KB5062660 は WSUS には現れません。
WSUSでKB5062663／KB5062660を取得するための設定手順
ここからは、実際に WSUS の設定を見直して KB5062663／KB5062660 を取得するまでの具体的な手順を順を追って説明します。
分類（Classifications）の見直し
まず最初に確認すべきは、WSUS の「分類」設定です。
- WSUS サーバー上で WSUS 管理コンソール を開く。
- 左ペインでサーバー名を選択し、[オプション] をクリック。
- [製品と分類] を開く。
- [分類] タブを選択。
- 既にチェックされている「セキュリティ更新」「重要な更新」に加えて、「更新プログラム（Updates）」にチェックを付ける。
- 必要に応じて、「更新プログラムのロールアップ」にもチェックを付ける（サーバー OS や古いクライアント OS も運用している場合は推奨）。
- [OK] をクリックして設定を保存する。
ポリシー上、「更新プログラム（Updates）をすべて恒常的に同期するのは避けたい」という場合は、KB5062663／KB5062660 を取得し終えた後に再度チェックを外す、という運用も考えられます。ただし、その場合は今後も同様のプレビュー更新を適用したいときに同じ作業が必要になる点を念頭に置きましょう。
製品（Products）の見直し
次に、対象となる Windows バージョンが正しく「製品」として選択されているかを確認します。特に、Windows 11 のみを運用しているつもりでも、実際には Windows 10 端末が混在しているケースがあるため注意が必要です。
- 同じく [製品と分類] の画面で、今度は [製品] タブを選択。
- 以下のように、環境に応じてチェックを確認・追加する。
- Windows 11（Windows 11 22H2 / 23H2 / 24H2 を含む）
- 必要に応じて Windows 10（倉頡入力を利用する Windows 10 22H2 クライアントがある場合など）
- サーバー OS で同様の不具合修正が必要な場合は、該当する Windows Server の製品にもチェック
特に、クリーンインストールした Windows 11 24H2 端末と、22H2 からのアップグレード端末が混在している環境では、KB の適用対象が OS ビルドによって変わる点に注意してください。
同期（Synchronization）の実行と確認
分類と製品の設定を変更したら、WSUS の同期を実行して更新を取得します。
- WSUS コンソール左ペインでサーバー名を選択。
- [同期] をクリックし、[今すぐ同期] を実行。
- 初回はフル同期に近い処理となるため、環境によっては時間がかかる場合があります。
- 同期の進行状況は、[同期の状態] や [レポート] から確認可能です。
同期に時間がかかること自体は異常ではありませんが、プロキシやファイアウォール設定の変更により、途中でエラーとなっていないかは必ず確認しておきましょう。
更新の検索と承認
同期が完了したら、実際に KB5062663／KB5062660 が取得できているかを確認します。
- WSUS コンソール左ペインで [更新] を選択。
- 右上の検索ボックスに 「KB5062663」 あるいは 「KB5062660」 を入力し、検索を実行。
- 該当更新が表示されたら、言語・アーキテクチャ（x64 / ARM64 など）を確認。
- 対象となるコンピュータグループに対して [承認] を実施し、配布を開始。
環境によっては、プレビュー更新をいきなり全端末に承認するのではなく、「検証」「パイロット」「本番」などのグループに段階的に承認するリング方式が推奨されます（これについては後述します）。
Microsoft Updateカタログからの直接インポート
WSUS の分類を見直してもなお KB5062663／KB5062660 が表示されない場合、Microsoft Update カタログからの直接インポートという代替手段があります。
WSUSへのインポート手順
WSUS コンソールから直接 Microsoft Update カタログを開き、必要な KB を WSUS に追加する手順は次の通りです。
- WSUS コンソールを開き、左ペインでサーバー名を選択。
- 右ペインの「関連リンク」や「ツール」から [更新のインポート] をクリック。
- 既定のブラウザーで Microsoft Update カタログのサイトが開く。
- 検索ボックスに 「KB5062663」 あるいは 「KB5062660」 を入力して検索。
- 表示された一覧から、環境に合った項目（OS バージョン、アーキテクチャ、言語など）を確認。
- 目的の更新を選択し、[かごに追加] → 右上のカートアイコンから [インポート] をクリック。
- インポートが完了すると、該当の更新が WSUS の [更新] 一覧に追加される。
- 追加された更新に対して、通常通り [承認] を行う。
この方法は、何らかの理由で通常の同期経由では KB が降りてこない場合に有効です。ただし、インポート後もやはり WSUS 内部では「更新プログラム（Updates）」として扱われるため、今後類似のプレビュー更新を利用する予定があるなら、分類設定自体を見直しておく方が運用負荷は少なく済みます。
スタンドアロンインストーラー（.msu）の利用
検証目的で一部端末にのみ先行適用したい場合や、WSUS とは別にオフラインで対応したい場合は、Microsoft Update カタログから .msu ファイルをダウンロードして、スタンドアロンで適用することも可能です。
- Microsoft Update カタログで KB5062663／KB5062660 を検索。
- 対象となる OS / アーキテクチャの項目から [ダウンロード] をクリックし、.msu ファイルを取得。
- 検証用端末に .msu をコピーし、ダブルクリックでインストール。
- コマンドラインで適用する場合は、管理者権限のコマンドプロンプトで以下のように実行。
wusa.exe <KB5062663_x64.msu> /quiet /norestart
ただし、スタンドアロンでの適用はバージョン管理やロールバックの観点から運用が煩雑になりがちです。本番環境への広範な展開は、可能であれば WSUS もしくは Windows Update for Business 経由に統一するのが望ましいでしょう。
対象OSごとのKB整理と確認ポイント
KB5062663／KB5062660 と、関連する Windows 10 向けの KB5062649 を含め、対象 OS と KB の対応を整理しておきます。
| KB番号 | 対象OS / バージョン | 想定OSビルド | WSUSでの分類 |
|---|---|---|---|
| KB5062663 | Windows 11 22H2 / 23H2 | OS ビルド 22621 / 22631 系 | プレビュー品質更新（更新プログラム） |
| KB5062660 | Windows 11 24H2 | OS ビルド 26100 系 | プレビュー品質更新（更新プログラム） |
| KB5062649 | Windows 10 22H2 | OS ビルド 19045 系 | プレビュー品質更新（更新プログラム） |
クライアント PC の OS ビルドは、以下のようにして確認できます。
winver
あるいは PowerShell から次のコマンドで詳細を取得することもできます。
Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber
WSUS で KB を承認する前に、実際に配布対象となるクライアントの OS ビルドを把握しておくことで、適用漏れや想定外の適用を防ぐことができます。
プレビュー更新を安全に運用するためのベストプラクティス
KB5062663／KB5062660 はプレビュー更新であるため、本番環境への展開は慎重に行う必要があります。ここでは、一般的な WSUS 運用におけるベストプラクティスを、今回の KB を例に整理します。
リング方式（パイロット → 段階展開）のすすめ
プレビュー更新をいきなり全社展開するのではなく、段階的に承認することで、もし想定外の不具合が発生した場合の影響を最小限に抑えることができます。代表的な例を表にまとめます。
| リング | 対象グループ | 役割 | KB承認のタイミング |
|---|---|---|---|
| Ring 0 | IT 部門検証端末 | 技術検証、ログ取得、既知不具合の洗い出し | KB公開直後～数日以内 |
| Ring 1 | 一部部門のパワーユーザー | 業務アプリとの組み合わせ検証 | Ring 0 で問題なしと判断後 |
| Ring 2 | 全社の一般ユーザー | 本番展開 | Ring 1 の結果を踏まえて承認 |
WSUS では、コンピュータグループを「検証」「準本番」「本番」といった名称で構成し、それぞれに対して承認タイミングをずらすことで、このリング方式を簡単に実現できます。
既知のリスクとロールバック方針
プレビュー更新全般に言えることですが、一部の環境では予期しない副作用が発生する可能性があります。今回の KB5062663 などでも、一部の環境で Windows 検索（スタートメニューの検索やタスクバー検索）が正しく動作しなくなる報告があるため、以下のような対策を事前に検討しておくと安心です。
- 更新適用前に、影響範囲が大きいサーバーやミッションクリティカル端末にはすぐ適用しない
- 検証用端末で、業務アプリ・検索機能・IME などの基本動作をチェックするテスト項目を用意
- 問題が出た場合に備え、システムの復元ポイントや バックアップの取得を事前に確認
- WSUS から承認を取り消しただけでは既に適用された更新は戻らないため、ロールバック方法（アンインストールの可否）を事前に確認
プレビュー更新はあくまで「任意」の更新です。業務影響を踏まえ、どうしても早期に倉頡入力の不具合を解消する必要がある端末にのみ適用するなど、メリットとリスクのバランスを見ながら展開計画を立てましょう。
本番累積更新（LCU）との関係と「置き換え」の考え方
プレビュー更新で提供された修正は、翌月以降の本番累積更新（LCU）に取り込まれるのが一般的です。そのため、ある程度時間が経つと、プレビュー更新単体を配布しなくても、次の月例パッチを適用することで同じ修正が入るケースがほとんどです。
WSUS では、プレビュー更新が後続の LCU によって置き換え（Superseded）されると、既定では表示が省略されることがあります。履歴確認の観点から、次のようなポイントを押さえておくと便利です。
- [更新] ビューのオプションで 「置き換えられた更新を表示」を有効にする
- 特定期間に適用されたプレビュー更新を調査するときは、フィルター条件に「状態」や「分類」を含める
- 「この KB はいつ、どの LCU に取り込まれたのか」をインシデント記録に残しておく
これにより、「検証では KB5062663 を適用したが、本番では翌月の LCU で取り込んだ」といった経緯を後から振り返りやすくなります。
よくある質問・トラブルシューティング
Q1. 分類を変更して同期しても KB が見つからない
A. 次のポイントを順に確認してみてください。
- 「更新プログラム（Updates）」にチェックを入れた後、同期を実行しているか
- 同期がエラーなく完了しているか（プロキシ設定や証明書エラーなど）
- 対象 OS（Windows 11 / Windows 10）が「製品」として選択されているか
- 検索条件で、状態や承認状況によるフィルターをかけて絞りすぎていないか
それでも見つからない場合は、Microsoft Update カタログからのインポートを試し、それでも WSUS 上に表示されない場合は、WSUS データベースの整合性チェックやサーバーログの詳細な確認を検討します。
Q2. クライアントが KB を受け取らない／インストールしない
A. WSUS に KB が表示されており承認もされているのに、クライアントが更新を受け取らない場合、以下の可能性が考えられます。
- クライアントの OS ビルドが KB の適用条件を満たしていない（別バージョンの KB が必要）
- すでに後続の LCU を適用しており、プレビュー更新が「不適用」扱いになっている
- クライアントが WSUS ではなくインターネット側の Windows Update に接続している（ポリシー競合）
- グループポリシーやローカルポリシーでプレビュー更新の受信が制限されている
まずはクライアント側で次のコマンドを実行し、更新検出状況を確認するとよいでしょう。
wuauclt.exe /detectnow
あるいは、Windows 11 では次の PowerShell コマンドを用いて Windows Update の診断情報を参照する方法もあります（環境によりコマンドは異なりますが、代表的なものの一例です）。
Get-WindowsUpdateLog
Q3. WSUSでプレビュー更新を恒常的に同期しても大丈夫？
A. 技術的には問題ありませんが、次のような点を考慮する必要があります。
- 同期される更新の件数が増え、WSUS データベースやディスク使用量が増加する
- 管理者が承認対象を見極める手間が増える
- 誤ってプレビュー更新を全社に展開してしまうリスクが高まる
対策としては、次のような運用が考えられます。
- 同期は有効にしつつ、自動承認ルールからプレビュー更新を除外する
- 「プレビュー検証用のビュー」や「検索フォルダー」を作成し、確認しやすくする
- 検証用のコンピュータグループに対してのみ承認する運用ルールを明文化する
まとめ：WSUSでKB5062663／KB5062660が見つからないときのチェックリスト
最後に、本記事で取り上げたポイントをチェックリストとして整理します。KB5062663／KB5062660 に限らず、今後のプレビュー更新でも同じ考え方が役立ちます。
- KB5062663／KB5062660 はプレビュー品質更新であり、WSUS上は「更新プログラム（Updates）」分類として扱われる
- WSUS の [製品と分類] で、「更新プログラム（Updates）」にチェックが入っているか確認する
- 対象 OS（Windows 11 22H2 / 23H2 / 24H2、必要なら Windows 10 22H2）が「製品」として選択されているか確認する
- 設定変更後は同期を実行し、エラーなく完了していることを確認する
- [更新] 画面で KB 番号（KB5062663 / KB5062660）で検索し、該当する更新を承認する
- どうしても WSUS で見つからない場合は、Microsoft Update カタログから WSUS へのインポート、もしくは .msu によるスタンドアロン適用を検討する
- プレビュー更新は任意であり、本番展開前にパイロット環境で十分な検証を行う
- 一部環境で Windows 検索が動作しなくなるなどの報告もあるため、影響評価とロールバック方針を事前に決めておく
- プレビュー更新で取り込まれた修正は、後続の本番累積更新（LCU）で置き換えられるため、「置き換えられた更新を表示」設定を活用して履歴を整理する
WSUS の分類設定は一度構築すると長年触らないことも多く、今回のように「プレビュー更新を通じて初めて必要になる」ケースで初めて問題として顕在化しがちです。この記事をきっかけに、自社環境の WSUS 設計ポリシーを見直し、「いつ、どのような条件でプレビュー更新を利用するか」をチーム内で共有しておくと、今後のトラブルシューティングもスムーズになります。
コメント