WSUS／ConfigMgr（SCCM）で新しい Microsoft Edge（Chromium）を配布・更新しようとしたのに、WSUS に「Stable Channel Version 更新」が出ず、「The new Microsoft Edge…」で始まる更新ばかり見える——。これは“更新が消えた”というより、WSUS に流れてくる更新の役割が変わった（見え方が変わった）ケースがほとんどです。本記事では、タイトルの違いを整理しつつ、現実的な運用設計と確認ポイントを具体的に解説します。
まず押さえるべき結論：「The new Microsoft Edge…」は“移行（置き換え）”用の更新
WSUS に表示される「The new Microsoft Edge…（The new Microsoft Edge is here…）」といった更新は、旧 Microsoft Edge（Legacy）を新 Microsoft Edge（Chromium）へ置き換えることを目的とした“移行用”の更新です。つまり、この更新が適用される設計になっている環境では、少なくとも旧→新への切り替えという観点では、「Stable Channel Version 更新」を毎回追いかけなくても前へ進みます。
一方、「Microsoft Edge-Stable Channel Version XXX Update for …」のような更新は、すでに新 Edge が入っている端末のバージョン更新（継続更新）に関わる更新です。こちらは運用方針（自動更新を許すか、WSUS／ConfigMgr で握るか）によって必要度が変わります。
WSUS に並ぶ“Edge関連更新”を見分ける（表で整理）
| WSUSで見える更新タイトル（例） | 役割 | 主な対象 | ここが重要 |
|---|---|---|---|
| The new Microsoft Edge… / The new Microsoft Edge is here… | 旧Edge（Legacy）を削除し、新Edge（Chromium）を導入する“移行用” | 主にWindows 10（旧Edgeが存在する世代） | 一度入れば目的は達成。その後の細かなバージョン追従は別ルートになることが多い |
| Microsoft Edge-Stable Channel Version XXX Update（x64/x86/ARM64） | 新Edgeの安定版（Stable）のバージョン更新 | 新Edgeが入っている端末 | WSUSで管理したいなら製品：Microsoft Edge／分類：Updatesが同期対象になっている必要がある |
| Microsoft Edge-Extended Stable Channel Version XXX Update | 更新頻度を抑えた“拡張安定版（Extended Stable）”のバージョン更新 | 更新頻度を下げたい組織 | 「更新を止める」より現実的な選択肢になりやすい |
| Microsoft Edge WebView2 Runtime … | アプリが組み込みWeb表示に使う実行基盤の更新 | WebView2を使うアプリがある端末 | Edge本体とは別物。混同すると更新設計が破綻しやすい |
ポイントは、WSUS に“Edgeっぽい更新”が見えていても、それが移行（置き換え）用なのか、継続更新用なのかで意味がまったく違うことです。WSUS 再構築のタイミングで「Stable Channel Version 更新」が見えなくなった場合、次のどれかが起きていることが多いです。
- そもそも「Stable Channel Version 更新」が同期されていない（製品／分類の設定、上流WSUSの設定、同期失敗など）。
- クライアント側は「The new Microsoft Edge…」で新Edgeに置き換わった後、Edge自身の更新機構でアップデートしている（WSUSで追いかける前提ではなくなった）。
- WSUS コンソールの検索・フィルタ条件（未承認のみ表示、期限切れ除外、置換済み非表示など）で見えていない。
「The new Microsoft Edge…」更新が“バージョン更新”に見えない理由
移行用更新は、あくまで旧Edge（Legacy）を置き換えることがゴールです。実際、Microsoft は Edge Legacy の置き換えを Windows 10 の月例累積更新（いわゆる Update Tuesday の “B” リリース）で提供する方針を示しています。したがって WSUS で「The new Microsoft Edge…」が入った端末は、まず“新Edgeの導入”が達成され、以後は継続的なアップデート経路（Edge Update / WSUS / ConfigMgr / Intune など）を別途どう設計するか、という話になります。
このため「WSUS でインストールはできるが、アップグレード（バージョン更新）ができないのか？」という疑問は、次のように言い換えると整理しやすいです。
- 移行（Legacy→Chromium）は「The new Microsoft Edge…」更新で進む。
- 導入後の追従（Chromium Edge の定期更新）は、WSUS で配るか、Edge の自動更新に任せるか、SCCM/Intune で配るかを決める必要がある。
新しい Microsoft Edge の更新経路は2本立てになりやすい
新 Edge（Chromium）は、基本的に定期的に更新される前提で設計されています。そのため、企業環境での更新は大きく次の2パターンに分かれます。
Edge 自身の更新メカニズム（自動更新）に任せる
多くの環境では、Microsoft Edge Update（サービス／タスク）により、端末が定期的に更新を確認して最新化します。管理者がすべてのバージョンを WSUS で配る運用は、Edge の更新頻度（セキュリティ修正がこまめに入る）と噛み合わないことがあります。
自動更新を採る場合の現場的メリットは、“最新版への追従コスト”が小さいことです。反対に、変更管理（いつ上がるかを固定したい）や、インターネットに出られない閉域網では課題が残ります。
WSUS／ConfigMgr（SUP）で更新を配布・承認して握る
「配布と更新の主導権を握りたい」「閉域網で端末がインターネットへ出られない」などの要件があるなら、WSUS（または ConfigMgr の Software Update Point）で Microsoft Edge の更新を同期し、承認・展開する設計が現実的です。その場合は、WSUS／SUP 側の同期設定（製品・分類）が要になります。
ただし“全部を握る”発想のまま自動更新を止めると、検証・展開が間に合わずに脆弱性対応が遅れやすい点には注意が必要です。後述する更新リング（パイロット→段階展開）や、Extended Stable チャネルなども含めて設計すると破綻しにくくなります。
運用設計で迷ったときのおすすめパターン（比較表）
| パターン | 更新の主導権 | おすすめ環境 | メリット | 注意点 |
|---|---|---|---|---|
| 自動更新（Edge Update）中心 | 端末側（ポリシーで制御） | 端末がインターネットへ出られる／運用負荷を下げたい | 追従が速い、運用が軽い | 「いつ上がるか」を完全固定しにくい |
| WSUS／SUP で Edge 更新を承認して配布 | サーバー側（承認・展開） | 閉域網／変更管理が厳格／月次パッチ運用に統合したい | 展開タイミングを管理できる | 更新頻度が高く運用が増えがち。リング設計が重要 |
| ConfigMgr／Intune で“アプリ配布”として管理 | 管理ツール側（パッケージ／アプリ展開） | バージョン固定が必須／特定版で動作保証が必要 | 検証済みバージョンを配りやすい | パッケージ作成・検証の工数が重い。セキュリティ対応の遅延リスク |
「Stable Channel Version 更新が見えない／追えない」という悩みは、突き詰めると運用パターンを決め切れていないことが原因になりがちです。まずは“どの更新経路を正とするか”を決め、その前提で WSUS／ConfigMgr／ポリシーを揃えるのが近道です。
WSUS／ConfigMgr（SCCM）側で確認すべきポイント
WSUS を再構築した直後に「Stable Channel Version 更新」が見えなくなった場合、最初に疑うべきは同期対象の設定です。とくに ConfigMgr を使っている場合、裏側の WSUS（SUP）設定が噛み合っていないと、コンソール上に Edge 更新が出ません。
製品と分類の基本（まずここ）
- 製品：Microsoft Edge
- 分類：Updates（環境によっては Security Updates も併用）
この設定が外れていると、「The new Microsoft Edge…」のような Windows 10 側の更新は見えても、Edge 本体の「Stable Channel Version 更新」は同期されません。
上流／下流 WSUS 構成なら“上流”が鍵
下流 WSUS（レプリカやダウンストリーム）を使っている場合、下流側で頑張っても上流が同期していなければ Edge 更新は降りてきません。次の観点で切り分けます。
- 上流 WSUS にも「Stable Channel Version 更新」が出ていない：上流側の製品／分類／同期失敗、あるいは表示フィルタが原因の可能性。
- 上流には出ているが下流に出ない：同期・承認・置換済み更新の扱い（上流→下流）の問題を疑う。
表示フィルタの落とし穴（“無い”のではなく“見えていない”）
WSUS はフィルタ条件によって見え方が大きく変わります。再構築後は既定値が変わっていることもあるため、次を確認します。
| 確認項目 | 典型的な症状 | 対処の方向性 |
|---|---|---|
| 未承認のみ表示 | 検索しても出ない／少ない | 「すべての更新」を対象に検索し、承認済み・期限切れも含めて確認 |
| 置換済み（Superseded）の非表示 | 最新以外が一切見えない | まずは“最新の1件”が存在するか確認。自動却下（Decline）を入れている場合は運用を見直す |
| アーキテクチャ条件 | x64だけ欲しいのにx86しか見ていない | x64/x86/ARM64 の更新が別れている点を意識して検索 |
クライアント側で確認すべきポイント（“更新できていない”の早期発見）
サーバー側の同期だけ確認しても、端末が更新できていなければ意味がありません。端末側では次の3点を押さえると切り分けが速くなります。
Edge が本当に新Edge（Chromium）になっているか
- 端末に msedge.exe が存在するか（例：Program Files 配下）。
- Edge を起動して edge://settings/help でバージョンが表示されるか。
Edge Update（サービス／タスク）が動作しているか
自動更新を前提にするなら、端末側で Microsoft Edge Update の仕組みが止まっていないか確認します。PowerShell で最低限の状況確認をする例です。
Get-Service edgeupdate, edgeupdatem | Select-Object Status, Name, StartType
# インストールされているmsedgeのバージョン確認例（環境によりパスは調整）
(Get-Item "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe").VersionInfo.ProductVersion 更新ポリシー（GPO/Intune）が意図せず“更新停止”になっていないか
「主導権を握るためにポリシーを入れたつもりが、結果的に更新が止まって脆弱になっていた」という事故は珍しくありません。Edge には更新制御のポリシー（Microsoft Edge Update ポリシー）が用意されているため、edge://policy で適用状況を確認し、必要に応じて見直します。
「Stable Channel Version 更新」がWSUSに出ないときの切り分け手順
状況別に“次に何を見るべきか”をまとめます。ポイントは、移行が目的なのか、継続更新が目的なのかを最初に決めることです。
| 目的 | いまWSUSに見えているもの | 次に確認すること | 判断の目安 |
|---|---|---|---|
| 旧Edgeを新Edgeへ置き換えたい | 「The new Microsoft Edge…」がある | 対象OSに合った更新が承認・適用されているか、端末にmsedgeが入ったか | 置き換えが完了すれば次は“更新方針”の話 |
| 新Edgeのバージョン更新もWSUSで管理したい | 「The new Microsoft Edge…」しか無い | 製品：Microsoft Edge／分類：Updates が同期対象か、上流WSUSでも同様か | 同期設定が外れているケースが最多 |
| 閉域網で端末がインターネットに出られない | Edgeが古いまま | WSUS/SUPでEdge更新を同期できるか、もしくはConfigMgrでアプリ配布に切るか | “自動更新に任せる”は成立しにくい |
なお、Edge のリリースはタイミングによって、ダウンロード提供（企業向け配布ページ）と WSUS／Update Catalog 側の反映に差が出ることがあります。WSUS だけを唯一の真実として見すぎると「更新が出ない」と勘違いしやすいため、運用上は検証リングと展開遅延を前提にした方が安全です。
更新頻度が高すぎると感じるなら「Extended Stable チャネル」を検討する
「自動更新は怖い、でもWSUSで毎週追うのは無理」という現場は多いです。その場合、更新を無理に止めるよりも、Edge のExtended Stable チャネル（更新頻度を抑えるチャネル）を検討すると運用が落ち着きます。これは Edge のチャネル設計として公式に案内されており、ポリシーで切り替える運用も可能です。
もちろん、Extended Stable でもセキュリティ修正は提供されますが、組織のセキュリティ基準や利用状況に応じて判断してください。少なくとも「更新を完全停止」よりは、リスクと運用負荷のバランスを取りやすい選択肢です。
よくある質問
「The new Microsoft Edge…」更新を入れたのに、Edge のバージョンが最新にならない
移行用更新は“新Edgeの導入”が目的なので、導入時点のビルドが最新とは限りません。その後の更新をどの経路で行うか（自動更新、WSUS/SUP、ConfigMgr/Intune）を決め、経路に合った設定・ポリシーに揃える必要があります。
WSUS で Edge を更新管理するなら、自動更新は止めるべき？
“二重管理”を避けたい気持ちは分かりますが、更新を止める＝脆弱性対応が遅れる、というリスクも増えます。現実的には「パイロット端末で先行適用→問題なければ全社展開」というリング運用を組み、WSUS/SUP で展開する場合でも遅延を前提に設計するのが安全です。ポリシーでの更新制御は、止めるより“制御する”方向（チャネル、ターゲットバージョン、ロールバック）を意識すると破綻しにくくなります。
ConfigMgr（SCCM）で「最初はMSI配布、更新はWSUS/SUP」という考え方はもう使えない？
考え方自体は使えます。ただし、WSUS に見える更新が「移行用（The new Microsoft Edge…）」なのか「継続更新用（Stable Channel Version）」なのかで、設計の前提が変わります。移行が完了した後、継続更新を WSUS/SUP で握るなら、Microsoft Edge の更新が同期・展開できる状態（製品・分類・承認ルール）が必要です。一方、継続更新を端末の自動更新に任せるなら、WSUS 側で追いかける必要は薄れます。
まとめ：見え方が変わっただけ、というケースが多い。次にやるべきは“更新方針”の確定
WSUS に「Stable Channel Version 更新」が出なくなり、「The new Microsoft Edge…」が表示されるようになったときは、まずそれが旧Edge（Legacy）から新Edge（Chromium）への移行用更新であることを押さえましょう。移行が目的なら、その更新が適用されれば前に進みます。
そのうえで、導入後の Edge をどう更新するか（自動更新／WSUS/SUP／ConfigMgr/Intune）を決め、WSUS／SUP の同期設定や Edge 更新ポリシーを一貫させることが、運用を安定させる最短ルートです。
コメント