Edge 152からメジャー更新が2週間周期に｜企業の検証運用とExtended Stableの選び方

Microsoft EdgeのStableチャネルは、Edge 152からメジャーバージョンの公開周期が約4週間から2週間へ短縮されました。2026年8月27日にStable版のEdge 152が公開され、以後は約2週間ごとに新しいメジャーバージョンが提供されます。一方、企業向けのExtended Stableは従来どおり8週間周期を維持します。(Windows Blog)

企業や自治体の管理者は、Stableを継続するなら、従来の月次確認ではなく、Betaチャネルを使った常時検証と段階展開へ移行する必要があります。社内Webシステム、業務用拡張機能、RPA、キオスク端末などの検証に時間がかかる組織は、Extended Stableへの切り替えも有力な選択肢です。

ただし、Extended Stableは「更新されないEdge」ではありません。機能更新は8週間ごとになりますが、セキュリティ更新や重要な修正は必要に応じて配信されます。更新を止めるのではなく、機能変更の受け入れ頻度を調整する仕組みとして考えることが重要です。(Microsoft Learn)

Edge 152からメジャー更新が2週間周期に変更

Microsoft Edgeは、これまでStableチャネルのメジャーバージョンをおおむね4週間ごとに更新していました。Edge 152以降は、この周期が約2週間になります。

公開時点の公式スケジュールでは、次のようなリリース計画が示されています。

バージョン	Stableの公開日・予定週	Extended Stable
Edge 152	2026年8月27日	2026年8月27日
Edge 153	2026年9月10日の週	対象外
Edge 154	2026年9月24日の週	対象外
Edge 155	2026年10月8日の週	対象外
Edge 156	2026年10月22日の週	2026年10月22日の週

Extended Stableは、Stableの4回に1回だけメジャーバージョンが更新されます。Edge 152から利用した場合、次の機能更新はEdge 156、その次はEdge 160となる想定です。なお、公式スケジュールの公開日はビルド状況によって前後する可能性があります。(Microsoft Learn)

2週間になるのは「メジャーバージョン」の更新周期

Edgeの2週間リリース周期について、最も間違えやすいのが「Edgeの更新が2週間に1回だけになる」という解釈です。

今回変更されるのは、主に次のような変更を含むメジャーバージョンの公開周期です。

新機能の追加
Webプラットフォームの仕様変更
管理ポリシーの追加や廃止
ブラウザーUIや標準動作の変更
Chromium基盤の更新

セキュリティ修正や品質修正は、メジャーバージョンの公開日とは別に、必要に応じて配信されます。重大な脆弱性が見つかった場合に、次の2週間後まで修正されないという意味ではありません。StableとExtended Stableの両方に、重要なセキュリティ修正が提供されます。(Microsoft Learn)

変更量が単純に2倍になるわけではない

Microsoftは、新しいリリース周期について、1回のリリースに含まれる変更量を従来より小さくし、それを高頻度で届ける方針を示しています。

そのため、毎月の総変更量が単純に2倍になるというより、従来は月に1回まとめて届いていた変更が、2回に分散されるイメージです。1回当たりの検証範囲を小さくできる可能性がある一方、リリースノートの確認、動作検証、問い合わせ対応といった作業の発生頻度は高くなります。(Windows Blog)

StableとExtended Stableの違い

StableとExtended Stableの主な違いは、機能更新を受け取る頻度です。

比較項目	Stable	Extended Stable
メジャーリリース周期	約2週間	約8週間
機能更新	すべてのメジャーバージョン	Stableの4回に1回
想定用途	一般利用、幅広い組織への展開	検証期間を長く確保したい管理対象環境
セキュリティ・重要修正	必要に応じて配信	必要に応じて配信
新機能の導入速度	速い	遅い
利用条件	通常のStableとして利用可能	管理対象環境のみ
Assisted Supportの目安	最新3リリース、約6週間	最新2リリース、約16週間

Microsoftは、多くの利用者にはStableを推奨しつつ、複雑な業務環境で長い検証期間が必要な組織向けにExtended Stableを提供しています。Extended Stableは別のブラウザーアプリではなく、既存のMicrosoft Edge Stableが8週間周期で更新される企業向けオプションです。(Microsoft Learn)

サポート期間を更新延期期間と誤解しない

MicrosoftのAssisted Supportは、Stableでは最新3メジャーバージョン、Extended Stableでは最新2メジャーバージョンが対象です。期間に換算すると、それぞれ約6週間と約16週間になります。

ただし、修正プログラムのサービス対象は基本的に各チャネルの現行リリースです。古いバージョンを意図的に固定し続けても、最新の品質修正やセキュリティ修正を受けられるとは限りません。

「約6週間サポートされるから、Stableを6週間固定してよい」という運用にはしないでください。(Microsoft Learn)

Edgeの2週間リリース周期が企業運用に与える影響

個人利用では、自動更新を有効にしていれば大きな作業は必要ありません。影響が大きいのは、Edgeの更新前に社内システムや端末を検証している企業、自治体、教育機関です。

Stable公開後に検証を始める運用では間に合いにくい

これまで月に1回、Stableの公開を確認してから検証していた組織では、検証が終わる頃に次のメジャーバージョンが公開される可能性があります。

例えば、次の工程をすべてStable公開後に実施している場合は、14日間に収まりにくくなります。

リリースノートの確認
管理ポリシーの変更点確認
社内システム担当者への検証依頼
複数部門での受け入れテスト
障害発生時のベンダー問い合わせ
承認会議
全端末への段階配布

今後は、Stableが公開されてから検証を始めるのではなく、Betaチャネルの段階から次期バージョンを確認する運用が必要です。

Microsoftも、組織を代表する一部の端末やユーザーをBetaチャネルに割り当て、Stable公開前に互換性を確認する方法を推奨しています。(Microsoft Learn)

ポリシー変更の確認頻度も増える

Edgeのメジャーアップデートでは、新しい管理ポリシーが追加されるだけでなく、既存ポリシーが非推奨になったり、削除されたりすることがあります。

そのため、EdgeをグループポリシーやIntuneで管理している組織では、次の確認を月次作業のままにしないことが重要です。

StableおよびBetaのリリースノート
新規ポリシー
非推奨ポリシー
廃止ポリシー
Webプラットフォームの互換性変更
Microsoft Edgeの既知の問題
ADMXテンプレートの更新要否

すべてのメジャーバージョンでADMXを入れ替える必要があるわけではありません。しかし、新しいポリシーを利用する場合や、廃止予定の設定を使っている場合は、管理テンプレートと現在の設定内容を照合する必要があります。

同じバージョンでも機能の見え方が異なることがある

Microsoft Edgeの一部機能は、全端末へ同時に有効化されるとは限りません。段階的なロールアウトが行われる機能では、同じEdge 152を使用していても、端末やテナントによって機能の表示状態が異なる場合があります。

そのため、問い合わせや障害の記録では、バージョン番号だけでなく、次の情報も残す必要があります。

Edgeの完全なバージョン番号
適用されている管理ポリシー
Microsoft Entra IDへのサインイン状態
対象ユーザーとテナント
拡張機能の一覧
発生日時
再現した端末数
機能の段階展開が疑われるか

Edge 152のリリースノートでも、複数の機能について段階的に展開されることが案内されています。(Microsoft Learn)

StableとExtended Stableのどちらを選ぶべきか

すべての企業がExtended Stableへ移行する必要はありません。新機能の導入速度だけでなく、業務システムの構成、検証体制、障害時の影響を基準に判断します。

Stableを継続しやすい組織

次の条件に多く当てはまる場合は、2週間周期のStableを継続しやすい環境です。

Microsoft 365や一般的なSaaSの利用が中心
独自開発の社内Webシステムが少ない
Edge Betaを利用する代表ユーザーを確保できる
主要機能のスモークテストを自動化できる
問題発生時に影響端末を切り分けられる
新しいブラウザー機能やセキュリティ改善を早く利用したい
部門単位、端末グループ単位で段階展開できる

Stableを利用する場合、すべての項目を毎回ゼロから確認するのではなく、業務停止につながる重要機能へ検証を集中させることがポイントです。

Extended Stableを検討したい組織

次の条件に当てはまる場合は、Extended Stableを検討する価値があります。

ブラウザーのバージョンごとにベンダーの動作保証が必要
独自開発の社内システムが多い
IEモードを利用するレガシーシステムが残っている
RPAやブラウザー自動操作を広範囲で利用している
キオスク端末や受付端末を多数運用している
更新の承認に複数部門や会議体が関わる
四半期や月次の変更可能日が決まっている
障害が住民サービス、製造、決済、医療などへ直接影響する

ただし、Extended Stableでは、Stableの4回分に相当する機能変更が8週間ごとの更新に集約されます。更新回数は減りますが、1回の機能更新で確認する変更範囲は広くなりやすいため、検証作業そのものが不要になるわけではありません。(Microsoft Learn)

組織全体で一つのチャネルに統一する必要はない

端末の用途によってチャネルを分ける方法も有効です。

端末・ユーザー	推奨候補
IT管理者、Web担当者	Beta
一般的な事務端末	Stable
新機能を早く利用したい部門	Stable
基幹システム専用端末	Extended Stable
RPA専用端末	Extended Stable
キオスク、受付、製造端末	Extended Stable
検証用端末	BetaとStableの併用

例えば、一般職員の端末はStableを維持し、基幹業務専用端末だけExtended Stableにする構成が考えられます。

この方法なら、組織全体のセキュリティ改善や新機能導入を過度に遅らせず、障害リスクの高い端末だけ検証期間を延ばせます。

2週間周期に対応する推奨アップデート運用

Stableを利用する組織では、14日間を一つの運用単位として設計します。

次の表は、管理対象端末を段階展開する場合の一例です。日数や端末割合は、組織の規模やリスクに応じて調整してください。

タイミング	実施内容
常時	代表ユーザーをBetaチャネルで運用
Stable公開前	Betaで基幹システム、拡張機能、認証、印刷を確認
公開日	Stableリリースノートと既知の問題を確認
1～2日目	IT部門と検証端末へ展開
3～5日目	各部門の代表ユーザーへ展開
6～9日目	対象端末を拡大
10～12日目	全体展開と例外端末の処理
13～14日目	障害記録を整理し、次のリリースへ移行

Microsoftも、自動更新と手動配布のどちらを採用する場合でも、代表ユーザーから全体へ広げるリング方式を推奨しています。(Microsoft Learn)

リリース日ではなく公開検知を起点にする

公式リリーススケジュールの日付は予定であり、ビルド状況によって変わる場合があります。

「毎月第2木曜日に検証開始」といった固定日運用ではなく、次のいずれかを検知した時点で作業を開始する仕組みにします。

Stableリリースノートの更新
管理ツールでの新バージョン検出
パイロット端末のバージョン更新
Microsoft 365メッセージセンターの通知
Edgeの既知の問題ページの更新

リリースの有無を人が不定期に確認するのではなく、担当者、確認日、判断結果をチケットや管理表に記録できる状態にしておくと、2週間周期でも作業が属人化しにくくなります。

Edge更新前に確認すべきテスト項目

すべてのWebサイトを網羅的に確認するのは現実的ではありません。業務停止やデータ損失につながる操作を優先してテストします。

分類	具体的な確認内容	優先度
認証	Microsoft Entra ID、SSO、MFA、証明書認証でログインできるか	高
基幹操作	登録、更新、承認、削除、検索が完了するか	高
ファイル	アップロード、ダウンロード、CSV出力が動作するか	高
印刷・PDF	帳票印刷、PDF表示、保存、電子署名が動作するか	高
拡張機能	業務用拡張機能が有効で、必要な画面へ作用するか	高
ネットワーク	プロキシ、PAC、VPN、閉域網で接続できるか	高
IEモード	対象サイトがIEモードで開き、認証や印刷が動作するか	高
RPA	要素取得、クリック、入力、ファイル保存が成功するか	高
ブラウザー設定	ホームページ、ダウンロード先、ポップアップ制御が維持されるか	中
周辺機器	ICカード、バーコード、カメラ、ローカルサービスと連携できるか	中

テスト環境を本番と近づける

Beta端末を1台用意するだけでは、十分な検証にならない場合があります。

テスト端末には、本番端末と同じ条件をできるだけ適用してください。

同じグループポリシー
同じIntune構成プロファイル
同じセキュリティ製品
同じ業務用拡張機能
同じプロキシとPAC
同じMicrosoft Entra IDの条件付きアクセス
同じ端末権限
同じネットワーク経路

管理者の高性能PCでは問題がなくても、共有端末、低スペック端末、VDI、Citrix環境などでだけ問題が発生することがあります。代表端末は、利用者数だけでなく、端末構成や業務内容が偏らないように選ぶ必要があります。

Extended Stableへ切り替える方法

WindowsでMicrosoft Edgeの自動更新を使用している場合は、グループポリシーのTarget Channel overrideでExtended Stableを指定できます。

グループポリシーで設定する手順

最新のMicrosoft Edge管理用テンプレートを用意します。
グループポリシーエディターを開きます。
次の場所へ移動します。

コンピューターの構成
  └ 管理用テンプレート
     └ Microsoft Edge Update
        └ Applications
           └ Microsoft Edge

Target Channel overrideを開きます。
設定を「有効」にします。
チャネルとしてExtended Stableを選択します。
対象端末へポリシーを適用します。
edge://settings/helpでバージョンとチャネルを確認します。

Intuneで管理している場合も、Microsoft Edge Update配下にある同名の設定を検索し、Extended Stableを指定します。(Microsoft Learn)

設定してもすぐにバージョンが下がるとは限らない

Extended Stableを設定しても、現在インストールされているStableより古いバージョンへ自動的にダウングレードされるわけではありません。

現在のStableが最新のExtended Stableより新しい場合は、現在のバージョンを維持したまま、より新しいExtended Stableが公開されるまで機能更新を待つ動作になります。その間も、対象となるセキュリティ修正や品質修正は引き続き提供されます。(Microsoft Learn)

例えば、Edge 153へ更新済みの端末でExtended Stableを指定しても、自動的にEdge 152へ戻るとは限りません。次のExtended StableであるEdge 156が公開された時点で、Extended Stableの更新系列へ合流する形が基本です。

特定のExtended Stableへ強制的に戻す必要がある場合は、MSIとロールバック機能を使う方法があります。ただし、通常のチャネル変更よりリスクが高いため、障害対応など必要な場面に限定してください。

Configuration ManagerやMSI利用時の確認に注意

Configuration ManagerやMSIパッケージでExtended Stableを配布した場合、edge://settings/helpにExtended Stableというチャネル名が表示されないことがあります。

公式ドキュメントでは、チャネル名が表示されるのはMicrosoft Edge Updateを使ってExtended Stableへ更新した場合と説明されています。表示だけで判断せず、配布したパッケージのバージョン、適用ポリシー、管理ツール上の展開状況を併せて確認してください。(Microsoft Learn)

Betaチャネルを検証に使う際の注意点

Betaチャネルは、次のStableで予定されている変更を、組織内の代表ユーザーで先行確認するためのサポート対象チャネルです。約2週間周期で新機能が公開され、Stableより先に互換性問題を発見できます。(Microsoft Learn)

ただし、Betaを単にIT管理者のPCへ入れるだけでは不十分です。経理、人事、受付、営業、開発など、異なる業務を実際に行うユーザーを含めます。

BetaからStableへ戻す操作にも注意する

BetaやDevは、Stableより大きいメジャーバージョン番号になることがあります。

この状態でTarget Channel overrideをStableへ戻しても、現在の端末より大きいStableが公開されるまで更新されない場合があります。すぐにStableへ戻す必要がある場合は、Microsoft Edgeのロールバック機能が必要です。(Microsoft Learn)

業務ユーザーをBetaへ参加させる際は、問題が発生したときの代替端末やStable環境も用意しておくと安全です。

更新後に問題が起きた場合の対応

2週間周期では、問題を発見してから次の展開判断までの時間も短くなります。更新前に対応手順を決めておきます。

まず全体展開を止めて影響範囲を確認する

障害が発生した場合は、すぐに全端末を古いバージョンへ戻すのではなく、次の順序で確認します。

パイロット以外への展開を一時停止する
完全なEdgeバージョンを確認する
edge://policyで適用ポリシーを確認する
拡張機能を一時的に無効化して切り分ける
InPrivateウィンドウや新規プロファイルで再現を確認する
Edgeの既知の問題を確認する
サイト側、認証側、ネットワーク側の変更も確認する
回避策がない場合にロールバックを検討する

バージョン更新と同時期に問題が発生しても、原因がEdgeとは限りません。業務システム側の更新、証明書の期限切れ、プロキシ変更、拡張機能更新なども切り分けます。

ロールバックは一時的な緊急措置として使う

Microsoft Edgeには、MSIまたはグループポリシーを使って以前のバージョンへ戻す機能があります。

グループポリシーを使う場合は、主に次の設定を組み合わせます。

Rollback to target version
Target version override
Update policy override

ただし、ロールバックしたバージョンには既知の脆弱性が残っている可能性があります。また、ユーザーデータが失われるリスクもあるため、Microsoftは事前に同期を有効化することを推奨しています。恒久的なバージョン固定には使わず、問題解消後はサポートされる最新バージョンへ戻します。(Microsoft Learn)

2週間周期への移行で起こりやすい失敗

従来どおり月1回だけ確認する

月次会議で更新可否を決める運用では、確認している間に次のメジャーバージョンが公開される可能性があります。

リリースごとに大規模な会議を行うのではなく、事前に判断基準を決め、問題がない場合は担当者判断で段階展開を進められる形にします。

Extended Stableなら検証不要と考える

Extended Stableでも機能更新は行われます。更新間隔が長い分、機能変更がまとまって入る可能性があります。

8週間の間にBetaで継続確認し、Extended Stable公開後には少数端末で最終確認を行ってください。

更新を無期限に停止する

旧バージョンを固定すれば、見かけ上は従来の検証周期を維持できます。しかし、最新のセキュリティ更新や品質修正を受けられなくなる可能性があります。

検証期間が足りない場合は、バージョン固定ではなくExtended Stableを使用するのが基本です。

バージョン番号だけで正常性を判断する

段階展開される機能、テナント単位の設定、ポリシー、拡張機能によって、同じバージョンでも動作が異なることがあります。

障害管理表には、バージョン番号以外の環境情報も記録します。

パイロットユーザーがIT部門に偏っている

IT部門では、経理帳票の印刷、住民情報システム、販売管理、電子申請など、実際の業務操作を再現できない場合があります。

各業務から代表者を選び、通常業務の中でBetaまたは先行Stableを使用してもらう方が、短時間で実用的な検証結果を得られます。

企業が今すぐ実施すべきこと

Edgeの2週間リリース周期へ対応するため、まず次の作業を進めます。

edge://settings/helpで現在のバージョンとチャネルを確認する
edge://policyで更新ポリシーの適用状況を確認する
Edgeを利用する基幹システム、拡張機能、RPAを一覧化する
障害時の影響が大きいシステムを特定する
部門を代表するBetaユーザーを選定する
StableとExtended Stableを端末用途ごとに選択する
14日以内に完了する段階展開ルールを作成する
ロールバック手順と責任者を文書化する

一般的な事務端末まで一律にExtended Stableへ変更する必要はありません。Stable、Extended Stable、Betaを用途ごとに使い分け、重要な端末ほど慎重な更新経路に配置することが現実的です。

Edge 152以降は、「更新を遅らせる運用」よりも、早い段階で問題を見つけ、小さい範囲から安全に展開する運用が重要になります。現在の検証工程が14日間に収まらない場合は、工程を短縮するだけでなく、Extended Stableを含めたチャネル設計そのものを見直してください。

この記事を書いた人

佐藤健司

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

Edge 152からメジャー更新が2週間周期に｜企業の検証運用とExtended Stableの選び方