WSUS 2016でMicrosoft Edge 84.0.522.52が見つからない／84.0.522.49が承認できない原因と対処法

WSUS 2016 で Microsoft Edge Stable Update（84.0.522.52）が見つからず配布できない、さらに 84.0.522.49 が置換表示されるのに承認エラーになる――そんな状況は、WSUS の不具合というより“更新の撤回/期限切れ”が原因で起きることがあります。現場で取れる確認手順と運用上の落としどころをまとめます。

現象の整理：WSUS 2016 で Edge の特定ビルドが扱えない

まずは、いま起きていることを「ビルド番号」と「WSUS 上の挙動」で整理します。ここが曖昧だと、不要な切り分け（DB修復や再同期の繰り返し）に時間を取られがちです。

Edge Stable ビルド	WSUS 上の見え方	起こりがちな挙動	現実的な打ち手
84.0.522.48	承認・配布できる（最後に正常に使えた）	クライアントが正常に更新される	正常系の比較対象として保持
84.0.522.49	置換/後継のように見えるが、承認でエラー	承認が成立しない／承認後すぐ未承認に戻る等	撤回・期限切れを疑い、無理に承認しない
84.0.522.52	WSUS に存在しない（検索しても出ない）	当然配布できない	Update Catalog に存在するか確認。無ければ待つ
84.0.522.50	最新として見えることがある	.40/.44/.48 を置換するが .49 は含まれないケースがある	運用を止めないため、まず .50 を承認して前進

今回のポイントは、「84.0.522.49 が承認できない」と「84.0.522.52 が見つからない」が同時に起きると、管理者は WSUS の障害を疑いがちですが、実務的には更新の撤回（公開後の取り下げ）や期限切れで説明できるケースが多い、という点です。

対処の全体像：まず“配れるもの”で前へ進む

結論だけ先にまとめると、対応は次の順番が最短ルートになりやすいです。

優先度	やること	狙い	判断の目安
高	WSUS に存在する最新（例：84.0.522.50）を承認して配布	業務・セキュリティ更新を止めない	.49 の承認に固執しない
中	84.0.522.52 が Update Catalog に存在するか確認	手動インポートの可否を確定	カタログに無いならインポート不可
中	WSUS ログ（Change.log 等）で“承認が取り消される”根拠を残す	社内説明・エビデンス確保	障害ではなく撤回である説明材料
状況次第	急ぎなら MSI など WSUS 以外の配布も検討	緊急回避	WSUS 反映を待てない場合

まず押さえる前提：WSUS は“公開されている更新”しか配れない

WSUS は Microsoft Update から更新のメタデータとコンテンツを同期し、管理者が承認したものだけを社内に配布します。つまり、次のどちらかに当てはまると、管理者が望んでも WSUS で配布できません。

そもそも更新が公開されていない（WSUS/Update Catalog に出ていない、同期対象になっていない）
一度公開されたが撤回・期限切れになった（WSUS で「期限切れ（Expired）」相当の扱いとなり承認できない）

今回の状況は、前者が 84.0.522.52、後者が 84.0.522.49 に該当している可能性が高い、という整理になります。

なぜ 84.0.522.49 が承認できないのか：撤回・期限切れの典型パターン

Edge の更新は、重大な不具合や配布上の問題が見つかった場合に、公開後まもなく取り下げられることがあります。WSUS 側ではこの取り下げが「期限切れ（Expired）」に近い状態として扱われ、承認操作そのものが成立しない、または承認できたように見えて直後に元へ戻る挙動になることがあります。

現場でよくある誤解と、実際に起きている可能性を対比しておきます。

WSUS の表示・挙動	誤解しやすい解釈	実際に起きている可能性
承認しようとするとエラーになる	WSUS のDBが壊れている／同期が失敗している	更新が撤回され、承認不可の状態になっている
承認できたように見えるがすぐ未承認に戻る	コンソールの表示バグ	承認→直後にサーバ側で無効化（期限切れ/撤回）されている
「84.0.522.48 が 84.0.522.49 に置換」と見える	なら 84.0.522.49 を承認すればよい	置換チェーン途中のビルドが撤回され、実務上は飛ばして次を使う必要がある

「期限切れ（Expired）」「拒否（Decline）」「置換（Superseded）」の違い

WSUS で混乱しやすい用語を、運用目線でまとめます。

状態	意味（運用目線）	承認できるか	対処の方向性
Superseded（置換）	より新しい更新が同じ目的を満たすため、通常は新しい方を使う	可能（ただし推奨は薄い）	基本は後継を承認。古い更新は整理対象
Expired（期限切れ）	Microsoft 側で無効化された更新。配布対象として成立しない	原則不可	諦めて後続ビルドへ。原因は WSUS ではなく更新撤回が多い
Declined（拒否）	管理者が意図的に「配らない」と決めた状態	拒否を戻せば可能	誤って拒否していないか確認（撤回更新の場合は戻しても解決しないことが多い）
Not Applicable（適用外）	対象OS/アーキテクチャ/前提条件が一致せず、その端末には刺さらない	承認自体は可能	対象グループ、x86/x64、Stable かどうかを再確認

今回の「84.0.522.49 を承認できない」は、WSUS の内部エラーというよりExpired 相当の状態に近い挙動として説明できます。管理者ができることは限られるため、実務的には撤回ビルドは飛ばして、配れるビルドで前に進むのが最短です。

84.0.522.52 が見つからない理由：Update Catalog に無いものはインポートできない

「Microsoft Update Catalog から手動インポートできるか？」という発想は正しいのですが、前提としてそのビルドが Update Catalog 上に存在している必要があります。Update Catalog に無い更新は、WSUS の「更新のインポート」でも、オフライン取り込みでも持ち込めません。

このタイプのズレは、次のような事情で起きます。

特定ビルド（例：84.0.522.52）が公開予定のまま取り下げになり、WSUS でもカタログでも見えない
別ビルド（例：84.0.522.50）が安定版として再公開され、結果として「.52 を待つより .50 を使う」のが最短になる
WSUS 上の置換関係が直線にならず、撤回された中間ビルドだけが穴抜けになる

質問にあるように「カタログ上では 84.0.522.50 が最新として見える」状況なら、手動インポートの結論はシンプルで、“存在する .50 を承認して配布する”が現実解です。

実務対応：84.0.522.50 を承認して運用を止めない

Edge は更新頻度が高く、セキュリティ修正も多い製品です。撤回ビルドを追いかけ続けるより、WSUS 上で扱える最新の Stable を選び、段階配布で確実に更新する方が事故が少なくなります。

推奨する承認フロー（テスト→本番）

段階	対象	承認のしかた	確認ポイント
テストリング	IT部門端末／検証端末	84.0.522.50 を「インストール」で承認	起動可否、主要業務サイト、拡張機能、社内プロキシ/証明書
パイロット	一部部署（影響が小さい範囲）	同更新を段階的に承認	問い合わせ増加がないか、例外端末がないか
本番	全端末	必要に応じて期限付きで承認	未適用端末の残数、失敗理由、適用外判定

WSUS コンソールでの確認ポイント（見落とし防止）

すでに 84.0.522.48 が見えている環境なら基本設定は整っているはずですが、次の“見落とし”は意外と効きます。

表示フィルタ：更新プログラムの一覧が「未承認のみ」「期限切れを除外」などになっていないか
検索語：「84.0.522.50」「Edge-Stable」「Stable Channel」など、表記ゆれを変えて検索する
列の追加：可能なら「承認」「期限切れ」「置換」の関連列を表示して俯瞰する
グループ承認先：テスト用グループと本番グループを取り違えていないか

承認後にクライアントで更新が進まない場合は、後述のクライアント側の観点も合わせて確認します。

手動インポートの可否：Update Catalog から取り込める条件と落とし穴

結論をはっきりさせると、Update Catalog に存在しないビルド（例：84.0.522.52 が見当たらない状態）を WSUS に手動で持ち込むことはできません。一方で、カタログに存在し、かつ「Import」可能な更新であれば WSUS コンソールから取り込めます。

「インポートできる」状態の判断基準

確認項目	OK の状態	NG の状態	NG の場合の結論
Update Catalog に検索で出るか	該当ビルドが表示される	検索しても見つからない	公開されていない／撤回の可能性。待つか別ビルドへ
「Import」ボタンがあるか	Import が表示される	Download のみ／Import が無い	WSUS 取り込み対象ではない。別の配布手段を検討
対象アーキテクチャが一致するか	x64/x86 が端末と一致	端末と不一致	適用外が増える。正しいパッケージを探す

インポート手順（カタログに存在する場合）

Update Catalog から WSUS にインポートする場合、環境によってはブラウザ要件やコンポーネント要件で詰まることがあります。実務としては次の流れを押さえておくと迷いません。

WSUS 管理コンソールで 「更新のインポート」 を開く（Update Catalog の入口）
カタログで対象更新（例：84.0.522.50）を検索し、Import を実行する
インポート後、WSUS の更新一覧に取り込まれたことを確認して通常どおり承認する

ただし今回の状況では、84.0.522.52 自体がカタログに無いならこのルートは使えません。インポートで解決しようとして停滞するより、WSUS に存在する最新ビルド（例：84.0.522.50）を承認して更新を進める方が、現場の損失が小さくなります。

置換（Supersedence）で混乱しないための考え方

置換は便利な仕組みですが、「撤回されたビルドがある」状況では見え方が直感に反します。今回のように .48 → .49 → .52 の連続性を期待すると、次のような違和感が起きます。

.48 が .49 に置換されたように見えるのに、.49 を承認できない
.52 が見つからない
結果として .50 が最新として見える（.49 が事実上スキップされる）

このときの運用判断はシンプルで、「承認できる最新の Stable を配る」へ寄せるのが正解です。置換チェーンの“穴”を埋めようとしても、撤回更新は戻ってこないことが多く、管理者の操作で復活させることはできません。

例：.50 が .40/.44/.48 を置換し、.49 が置換チェーンに含まれないケース

質問で触れられているパターンを、運用イメージとして整理すると次のようになります。

古いビルド	置換関係（WSUSメタデータ上）	運用上の扱い
84.0.522.40 / 84.0.522.44 / 84.0.522.48	84.0.522.50 が置換（Supersede）	.50 を承認して更新する
84.0.522.49	撤回・期限切れにより、置換の対象外のように扱われることがある	無理に承認せずスキップする

「置換に入っていない＝不完全」というより、“撤回された中間ビルドはなかったことになる”に近い挙動、と捉えると現場判断が早くなります。

ログで確認するならここを見る：WSUS 側の根拠づけ

今回の本質は更新の撤回である可能性が高いものの、「承認を押した瞬間に何が起きているか」を把握しておくと、社内説明や切り分けに役立ちます。WSUS 2016 では、代表的に次のログが確認ポイントになります。

ログ	場所の例	見たい内容
Change.log	C:\Program Files\Update Services\LogFiles\Change.log	承認/拒否など、更新オブジェクトの状態変更の履歴
SoftwareDistribution.log	C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log	同期や更新メタデータ処理のエラーの有無
イベントログ	イベントビューアー（アプリケーション/サービス）	WSUS サービスや IIS、DB接続の問題

承認直後に「配布対象が作成されてすぐ消える」ような履歴が見える場合、承認操作が成立しない理由（期限切れ/撤回）の説明材料になります。逆に WSUS 全体の同期失敗や DB/IIS エラーが大量に出る場合は WSUS 健全性の問題も疑うべきですが、今回のように「特定ビルドだけ承認不可」という症状では、まず更新側の撤回を疑うのが合理的です。

クライアント側の確認：承認したのに Edge が更新されないとき

84.0.522.50 を承認しても端末が上がらない場合、WSUS 以前に「端末側の条件」で止まっている可能性があります。特に Edge は同一端末に複数チャネル（Stable/Beta/Dev/Canary）が混在すると、狙った更新が刺さらないことがあります。

対象チャネル：WSUS で配っているのが Stable 更新で、端末が別チャネルになっていないか
アーキテクチャ：x64 端末に x86 向けを承認していないか（またはその逆）
ポリシー：Edge 更新をブロックする GPO/レジストリ設定が入っていないか
承認先グループ：端末が想定グループに所属しているか（未割り当てに落ちていないか）

運用としては、WSUS の「コンピューター」画面で対象端末の状態を確認し、必要なら端末側で Edge のバージョン（設定画面のヘルプ等）も併せて確認すると原因が絞れます。

急ぎで最新版が必要な場合の代替策：WSUS 以外で Edge を更新する

「セキュリティ上、どうしても早く最新版へ寄せたい」「WSUS に出るのを待てない」局面では、Edge を別ルートで配布する判断も現実的です。代表的には、エンタープライズ向けのオフラインインストーラ（MSI）を使って配布します。

MSI 配布の例（サイレントインストール）

配布ツール（SCCM/Intune/スクリプト配布/ソフトウェア配布機能）を使う場合、次のようなコマンドラインが基本形になります。

msiexec /i MicrosoftEdgeEnterpriseX64.msi /qn /norestart

緊急回避として MSI で止血し、WSUS 側に安定版の更新（例：84.0.522.50 以降）が並んだ段階で、通常の承認運用へ戻す――という二段構えにすると、業務停止とセキュリティ遅延の両方を抑えられます。

再発防止：撤回ビルドに強い WSUS 運用の作り方

Edge のように更新頻度が高い製品を WSUS で扱うときは、「すべてを即時全社展開」よりも、段階展開と保守ルーチンの方が効きます。次のチェックリストを運用に組み込むと、今回のような“承認できない更新”に遭遇しても混乱が減ります。

運用チェックリスト

頻度	やること	目的
毎週	Edge 更新の新着をテストリングへ承認	早期検知（業務影響・互換性）
毎週	期限切れ/拒否/置換の状態を俯瞰	撤回ビルドの混入を把握
毎月	WSUS サーバークリーンアップ（不要更新の整理）	DB/コンテンツ肥大化の抑制
随時	「必要な更新が見当たらない」場合は Update Catalog を確認	公開有無の判定を早める

「承認できない」を“障害”にしないための判断基準

次の条件が揃う場合、WSUS 自体の故障ではなく更新の撤回/期限切れが原因である可能性が高いです。

特定のビルドだけ承認できず、それ以外は通常どおり承認・配布できる
Update Catalog でも該当ビルドが見つからない、またはインポートできない
WSUS の同期やDBに関する広範なエラーが出ていない

この場合は「WSUS を直す」より、配布可能な次のビルドを選び、段階展開で適用するのが現場の正解になります。

まとめ：今回の最短ルート

84.0.522.49 は一時公開後に撤回された可能性が高く、WSUS では承認できない
84.0.522.52 が WSUS/Update Catalog に出ていないなら、手動インポートもできない
運用を止めないために、WSUS に存在する最新（例：84.0.522.50）を承認して配布
どうしても急ぐ場合は、MSI など WSUS 以外の配布も一時的に検討

「なぜ承認できないのか」を追い詰めるより、撤回ビルドが出る前提で段階配布を回す方が、結果として安定した運用につながります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。