3行まとめ
このテーマをもう少し広げて見るなら、Windows 11 Release Preview 26100.8728/26200.8728：Point-in-time Restore、Widgets静音化、IPP既定化の確認ポイント と Windows Secure Boot証明書は2026年6月から期限切れ：2023 CA更新と管理者の確認ポイント も合わせて確認してください。Edgeの更新検証とあわせて、Windows側のRelease Previewや配布前確認も押さえると運用計画を立てやすくなります。
Microsoft Edge 152のStableから、メジャーリリースが約2週間ごとのリズムになります。予定週は2026年8月27日週です。
管理された環境向けのExtended Stableは2週間化せず、4回に1回のStable相当として約8週間の機能更新リズムを保ちます。
Beta代表検証、段階的なStable展開、リリースノート確認、WebView2や業務Webアプリの互換性確認を短い間隔で回します。
2026年8月27日週はStableの予定週として扱い、全端末へ同日に届く前提ではなく段階的な展開として確認します。
- Microsoftは2026年6月11日、Microsoft EdgeのStableチャネルをEdge 152から2週間のメジャーリリースサイクルへ移行すると発表しました。Microsoft Learnの予定表では、Edge 152 Stableは2026年8月27日週に並んでいます。
- Extended Stableは2週間化しません。管理された環境向けの選択肢として約8週間の機能更新リズムを維持し、Edge 152以降は4回に1回のStable相当、たとえば156、160、164のように進むと説明されています。
- Stableを使う組織は、Beta代表検証、段階的なStable展開、リリースノート確認、WebView2や業務Webアプリの互換性確認を、月1回前提からより短い運用へ寄せる必要があります。
Microsoft Edgeの更新は、普段は利用者があまり意識しない領域です。ただし、企業、学校、開発チームでは話が変わります。社内ポータル、SaaS、拡張機能、SSO、PDF、印刷、WebView2 Runtimeを使う業務アプリがEdgeに依存している場合、リリースサイクルの変化は変更管理そのものに影響します。
今回の発表は「Edgeが速くなる」という単純な話ではありません。Stableで新機能や改善が届く間隔は短くなる一方、Extended Stableという長めの検証リズムも残ります。管理者が見るべきなのは、どちらが優れているかではなく、自社の業務、検証体制、サポート窓口、セキュリティ更新の受け取り方に合うチャネルをどう選ぶかです。
確認日は2026年6月12日JSTです。国内の専門メディアでも同日から話題になっていますが、この記事で仕様や予定の根拠にするのはMicrosoft Edge BlogとMicrosoft Learnの一次情報です。Microsoft Watch JapanはMicrosoft Corporationおよび関係会社とは非提携の独立サイトであり、本記事は製品利用と導入判断の補助を目的としています。
Edge 152から何が変わるのか
- Edge 150
Betaは2026年6月11日週、StableとExtended Stableは2026年7月2日週に並びます。
- Edge 151
Betaは2026年7月7日週、Stableは2026年7月30日週、Extended Stableは対象外です。
- Edge 152
Betaは2026年8月6日週、StableとExtended Stableは2026年8月27日週です。Stable 2週間サイクルの開始点として扱います。
- Edge 153
Betaは2026年8月25日週、Stableは2026年9月10日週、Extended Stableは対象外です。
- Edge 154
Betaは2026年9月8日週、Stableは2026年9月24日週、Extended Stableは対象外です。
予定はリリース週として読み、Microsoft Learnの表が更新された場合は社内カレンダーも合わせて見直します。
Microsoft Edge Blogは、2026年6月11日の記事で、Edgeが2週間リリースサイクルへ移行すると発表しました。具体的には、Microsoft Edge 152のStable、Microsoftの表現ではStable on August 27から、Stableのメジャーリリースが2週間ごとになります。
ここで大事なのは、発表文だけでなくMicrosoft Learnのリリース予定表を合わせて読むことです。Learnの表では、Edge 150、151、152、153、154のBeta、Stable、Extended Stableの予定週が並んでおり、Edge 152以降のStableが短い間隔で続くことが見えます。
| バージョン | Beta Channel予定週 | Stable Channel予定週 | Extended Stable予定週 |
|---|---|---|---|
| 150 | 2026年6月11日週 | 2026年7月2日週 | 2026年7月2日週 |
| 151 | 2026年7月7日週 | 2026年7月30日週 | Not applicable |
| 152 | 2026年8月6日週 | 2026年8月27日週 | 2026年8月27日週 |
| 153 | 2026年8月25日週 | 2026年9月10日週 | Not applicable |
| 154 | 2026年9月8日週 | 2026年9月24日週 | Not applicable |
Microsoft Edge Blogの発表で見るべき点
Edge Blogの発表でまず確認するのは3つです。1つ目は、Stableが2週間サイクルになる開始点がEdge 152であること。2つ目は、Extended Stableのタイミングが変わらないこと。3つ目は、Stable利用組織には小さく頻繁な変更が届き、Extended Stable利用組織には8週間の計画リズムが残ることです。
Microsoftは、Stableでは変更単位が以前より小さくなり、セキュリティやプラットフォーム改善がより早く届くと説明しています。一方で、Extended Stableも重要です。Extended Stableでは新機能の到着を8週間の枠に置き、複雑な環境を持つ組織が検証時間を確保しやすくなります。
予定日は「週」として扱う
Microsoft Learnのrelease scheduleは、release weekを示しています。つまり、表にある日付を「全端末で同日更新される日」と読まない方が安全です。ビルド状況や段階的ロールアウトにより、端末や環境ごとの到着時期はずれる可能性があります。
この記事では、2026年8月27日をEdge 152 Stableの予定週として扱います。社内の変更管理カレンダーに入れる場合も、8月27日に全員が更新される前提ではなく、8月下旬から9月上旬にかけて確認するくらいの幅を持たせたいところです。
確認のしかた
管理者は、まず自社が現在StableなのかExtended Stableなのか、または混在しているのかを確認します。そのうえで、Edge 150から154までの表を自社の変更管理カレンダーに落とし込み、Beta検証、先行Stable、標準展開、慎重部署の扱いを分けておきます。
Microsoftの発表会やWindows関連の更新は6月に集中しています。Windows端末全体の更新文脈も合わせて追うなら、月次ページの<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>に戻ると、Edge以外のWindows、Copilot、GitHub、Surface関連の確認点も見渡せます。
Stable、Extended Stable、Betaの違いをどう読むか
短いStableサイクルはBeta検証を不要にするものではなく、短い変更単位で代表検証を回す運用に近づけます。
Edgeのチャネルは、名前だけで判断すると少し紛らわしいです。Stableは一般的な広範展開向け、Extended Stableは管理された環境で長い機能更新リズムを選ぶための企業向けオプション、BetaはStableより前に代表ユーザーで確認するためのSupported channelとして読むと整理しやすくなります。
| チャネル | 主な用途 | 新機能のリズム | 管理者の使いどころ |
|---|---|---|---|
| Stable | 広範な本番利用 | Edge 152から約2週間ごと | 標準展開。先行リングを作り、短い変更単位で確認する |
| Extended Stable | 管理された環境で長めに検証 | 約8週間ごと | 基幹業務、学校、検証負荷が大きい部署で使う |
| Beta | Stable前の代表検証 | 約2週間ごと | 業務アプリ、SSO、拡張機能、WebView2影響を先に見る |
| Dev / Canary | さらに早い先行確認 | より頻繁 | 開発者や検証担当向け。一般展開の根拠にしない |
Stableは広範な展開向けの基本チャネル
Stableは、多くの利用者が日常的に使う標準のEdgeです。Edge 152以降は、このStableのメジャーリリース間隔が短くなります。機能変更が小分けになるなら検証しやすくなる面もありますが、確認回数は増えます。
たとえば、月1回の変更管理会議でEdgeのメジャー更新を見ていた組織は、2週間ごとの確認へ運用を近づける必要があります。すべてを重い承認プロセスにかけるのではなく、見る項目を絞った軽い確認を定例化する方が現実的です。
Extended Stableは企業向けの長い計画リズム
Microsoft LearnのChannel overviewでは、Extended Stableは別のブラウザーアプリではなく、Microsoft Edge Stableアプリに対する企業向けのリリース選択肢として説明されています。機能更新は約8週間ごとで、Edge 152以降は4回に1回のStable相当がExtended Stableとして扱われます。
Extended Stableは、古いバージョンを放置するためのものではありません。Microsoftの説明では、セキュリティ更新や重要修正は必要に応じて届けられます。違いは、新機能を受け取るタイミングです。業務影響が大きく、検証や周知に時間が必要な部署では、Extended Stableを方針として選ぶ意味があります。
Betaは代表ユーザーでの検証チャネル
Edge Blogの推奨アクションでは、どのチャネルを使っていてもBetaのpilot groupを追加し、初日から検証することが勧められています。BetaはDevやCanaryとは違い、IT管理者が本番に近い代表ユーザーで検証する場として使いやすいチャネルです。
Betaを全社展開する必要はありません。むしろ、代表ユーザーを絞ることが重要です。人事、経理、営業、校務、開発、ヘルプデスクなど、使うWebアプリや拡張機能が違う部門から少人数を選び、Stable公開前に問題を拾えるようにします。
注意点
Stableが2週間サイクルになるからといって、Beta検証が不要になるわけではありません。変更単位が小さくなる分、短いサイクルで「どこを見るか」を決める必要があります。Beta代表検証、Stable先行リング、標準展開の順番を作っておくと、変更の速度に追いつきやすくなります。
管理者は検証リングをどう組み替えるか
- 1Beta代表ユーザー
業務Webアプリ、SSO、拡張機能、印刷、PDF、WebView2を実際に使う部門から少人数を選びます。
- 2IT先行リング
管理者、ヘルプデスク、端末管理担当が更新適用、ポリシー、既知問題、問い合わせ手順を確認します。
- 3業務先行リング
重要な部門や業務アプリ利用者で、SaaS、社内ポータル、証明書認証、プロキシなどの影響を見ます。
- 4標準展開
一般利用者へ広げながら、問い合わせ量、利用者告知、残っている既知問題を確認します。
- 5Extended Stable判断
基幹業務、授業、試験、規制業務など、長い検証期間が必要な部署はExtended Stableを方針として選びます。
Extended Stableは古いバージョンを放置するためではなく、管理された環境で機能更新の間隔を長く取るための選択肢です。
Edgeのリリースサイクル変更で一番影響を受けるのは、チャネルそのものより、組織内の検証リングです。いまStableを全社一斉に入れている組織は、Edge 152の前に少なくとも先行リングを作る価値があります。
Betaリングは代表ユーザーを絞る
Betaリングには、単にIT部門だけを入れるのではなく、実際に業務Webアプリを使う代表者を入れます。確認したいのは、Edgeの見た目が少し変わったかどうかだけではありません。社内ポータル、SaaS、SSO、拡張機能、印刷、PDF、証明書認証、プロキシ、DLP、WebView2を使う業務アプリが、次のStableで問題なく動くかです。
代表ユーザーは多すぎる必要はありません。部門ごとに1人から数人でも、検証観点が分かれていれば十分なシグナルになります。重要なのは、Betaで何を確認したかを記録し、Stable先行リングへ渡すことです。
Stableリングは段階的に広げる
Stableの更新が短くなると、全社一斉展開はリスクを増やしやすくなります。おすすめは、Stableでも段階を分けることです。
| リング | 対象 | 見ること |
|---|---|---|
| IT先行 | 管理者、ヘルプデスク、端末管理担当 | 更新適用、ポリシー、既知問題、問い合わせ手順 |
| 業務先行 | 代表部門、重要Webアプリ利用者 | SSO、拡張機能、印刷、PDF、SaaS、社内ポータル |
| 標準展開 | 一般利用者 | 問い合わせ量、利用者告知、既知問題の残り |
| 慎重部署 | 基幹業務、授業、試験、規制業務 | Extended Stable候補、展開延期、個別承認 |
このリング設計は、Windows端末管理全体にも近い考え方です。Windowsの起動基盤や証明書更新も並行して見ている組織は、<a href="https://msft-watch.blog.mo-gmo.com/msft-39-windows-secure-boot-2026-certificates-2023-ca-checkpoints/">Windows Secure Boot証明書は2026年6月から期限切れ：2023 CA更新と管理者の確認ポイント</a>も合わせて確認しておくと、端末側の基盤更新とブラウザー更新を別々に扱いやすくなります。
Extended Stableは例外ではなく方針として選ぶ
Extended Stableを、更新できない部署の逃げ道として扱うと運用が崩れます。選ぶなら、理由を明確にして方針として使うべきです。たとえば、学期中の端末環境、試験期間、基幹業務の繁忙期、規制対象業務、社外監査が絡むWebアプリなど、検証や周知に時間が必要な場所ではExtended Stableが合う場合があります。
ただし、Extended Stableを選んでもセキュリティ更新の確認は必要です。Microsoft Edge Lifecycle Policyは、古いリリースの利用は推奨されず、最新の品質とセキュリティ更新を逃す可能性があると説明しています。Extended Stableは計画的な長い機能更新リズムであり、古いEdgeを放置する運用ではありません。
評価基準
チャネル選択は、利用者数、業務停止リスク、検証できる人数、ヘルプデスク容量、社内告知の頻度、セキュリティ更新をどれだけ早く受けたいかで決めます。StableかExtended Stableかの二択ではなく、部署や端末グループごとに分ける設計も現実的です。
展開と更新管理で確認すること
リリースノート確認、ポリシー確認、互換性確認を同じ表で回すと、2週間ごとの変更でも見落としを減らせます。
2週間サイクル化で、管理者の確認対象は増えます。ただし、毎回すべてを深掘りする必要はありません。Edgeのリリースノートを読む型を作り、変更が大きい箇所だけ深く見る運用にした方が続きます。
リリースノート確認の頻度を上げる
Microsoft EdgeのStable release notesでは、StableとExtended Stableのバージョン、リリース日、修正、ポリシー更新などが確認できます。2026年6月12日時点では、Stable 149.0.4022.52が2026年6月4日のStableとして表示され、同じページにはマイナー更新も並んでいます。
Edge 152以降は、メジャー更新のリズムが短くなるため、リリースノート確認も月1回では遅くなる可能性があります。毎回すべてを詳細レビューするのではなく、次の項目だけでも短く確認できるようにしておくとよいです。
| 見る項目 | 確認する理由 | 担当の例 |
|---|---|---|
| メジャー/マイナーのバージョン | 端末群がどの波にいるかを把握する | 端末管理 |
| Policy Updates | Intune、グループポリシー、管理テンプレートへの影響を見る | IT管理 |
| Security Updates | 緊急対応の要否を判断する | セキュリティ |
| Feature updates | 利用者告知やサポート記事の更新要否を見る | ヘルプデスク |
| Platform notes | Windows、macOS、Linux、WebView2影響を分ける | アプリ担当 |
ポリシー変更と拡張機能を重点的に見る
Edge管理で見落としやすいのがポリシーです。新しい機能が入ったとき、管理者は利用者向けUIだけでなく、管理ポリシーが追加されたか、既存ポリシーの既定値が変わったか、非推奨が出たかを確認する必要があります。
拡張機能も同じです。社内標準のパスワード管理、DLP、翻訳、SaaS連携、電子署名、業務支援ツールがEdge拡張機能として入っている場合、Edge本体の更新で挙動が変わることがあります。Betaリングで拡張機能の基本操作を確認しておくと、Stable展開後の問い合わせを減らせます。
WebView2と業務Webアプリの影響を分ける
Microsoft Edgeの更新は、Edgeブラウザーだけの話に見えます。しかし組織によっては、WebView2 Runtimeを使う業務アプリやサードパーティ製品の方が影響を受けやすい場合があります。Edge本体で問題がなくても、埋め込みブラウザーを使うアプリで認証、印刷、ファイルダウンロード、ポップアップ、証明書確認に差が出ることがあります。
このため、検証表には「EdgeでWebアプリを開く」と「WebView2を使う業務アプリを操作する」を分けて入れるべきです。開発チームがいる組織では、Beta Channelを使った先行検証や、自動テストのブラウザー確認を短いサイクルに寄せることも検討できます。
古いリリースを残し続けない
Lifecycle Policyでは、古いMicrosoft Edgeリリースを使い続けると最新の品質更新やセキュリティ更新を逃す可能性があり、推奨されないと説明されています。更新を止めるのではなく、StableとExtended Stableを使い分け、必要な修正を受けながら検証時間を確保する、という考え方に寄せたいところです。
企業、学校、開発チームで影響が出やすい場所
どの選択肢が常に優れているという比較ではなく、業務の止めにくさ、検証負荷、説明責任に合わせて選びます。
Edgeの2週間サイクル化は、すべての組織で同じ形の負担になるわけではありません。影響が出やすい場所は、企業、学校、開発チームで少し違います。
企業では変更管理と監査説明が短い間隔になる
企業では、変更管理の頻度が論点になります。Stableを使い続けるなら、更新内容の確認、社内告知、ヘルプデスク準備、問い合わせ傾向の確認を短い間隔で回す必要があります。大規模企業では、部門ごとの業務WebアプリやSaaS依存も異なるため、全社一律の確認表だけでは足りません。
一方で、変更単位が小さくなれば、問題の切り分けがしやすくなる可能性もあります。月1回の大きな変更より、2週間ごとの小さな変更の方が、影響範囲を説明しやすい組織もあるでしょう。
学校では授業端末と試験期間を考慮する
学校や教育機関では、授業端末、端末室、試験期間、BYOD、フィルタリング、アクセシビリティ設定を考慮する必要があります。EdgeのUIやポリシーが変わるだけでも、授業中の問い合わせや試験運用に影響する場合があります。
この領域では、Stableを常に最新にする部署と、Extended Stableで学期や試験期間をまたぐ部署を分ける運用が考えられます。重要なのは、Extended Stableを選んだ部署でも、セキュリティ更新と重要修正の確認を止めないことです。
開発チームではブラウザー互換とCI確認を寄せる
開発チームにとっては、Edge 152以降の2週間サイクルは、社内WebアプリやSaaS連携の検証サイクルを見直すきっかけになります。Betaで代表的な画面を確認し、Stable先行リングで社内利用者に試してもらうだけでも、公開後の障害を拾いやすくなります。
Windowsを開発基盤として見直しているチームなら、<a href="https://msft-watch.blog.mo-gmo.com/msft-25-coreutils-for-windows-ga-winget-wsl-container/">Coreutils for Windowsが一般提供：winget導入、PowerShell競合、WSLコンテナの確認ポイント</a>も近い文脈です。Edgeの更新管理と同じく、開発端末に入る基盤ツールの更新をどう扱うかが論点になります。
上振れと下振れ
上振れは、変更が小さくなり、セキュリティやプラットフォーム改善が早く届くことです。下振れは、検証、告知、問い合わせ対応の頻度が上がり、運用が追いつかなくなることです。自社にとってどちらが大きいかは、Edgeの機能そのものより、変更管理の成熟度で決まります。
8月27日週までのチェックリスト
- 6月中旬
現在のEdgeチャネル、対象端末、例外部署を確認し、端末管理台帳とポリシーを照合します。
- 6月下旬
Beta代表ユーザー候補と業務Webアプリ一覧を作り、部門ごとに1人から数人を選びます。
- 7月上旬
Edge 150 StableとExtended Stableの予定週を見て、既存の更新リングで問題がないか確認します。
- 7月下旬
Edge 151 Stable予定週を、2週間化前の最終確認として運用負荷の見直しに使います。
- 8月前半
Edge 152 Betaを目安に、業務Web、SSO、拡張機能、PDF、印刷、WebView2アプリを代表ユーザーで確認します。
- 8月下旬
Edge 152 StableとExtended Stableの予定週に合わせ、Stableへ進む部署とExtended Stableを選ぶ部署を確定します。
未完了の項目が残る場合は、対象端末、担当、承認者、延期部署を明確にしてから展開判断に進みます。
Edge 152 Stableの予定週は2026年8月27日です。いまから見るなら、6月から7月に棚卸し、8月前半にEdge 152 Betaで代表検証、8月下旬にStableとExtended Stableの選択を確定する流れが現実的です。
6月から7月はリリース表と現行運用を棚卸しする
まず、現在のチャネル設定を確認します。全端末がStableなのか、Extended Stableが混ざっているのか、部署ごとの例外があるのかを洗い出します。Intune、グループポリシー、Microsoft Edge Updateポリシー、更新延期設定、対象グループ、管理テンプレートの版も合わせて確認します。
| 時期 | 確認すること | 未完了なら |
|---|---|---|
| 6月中旬 | 現在のEdgeチャネル、対象端末、例外部署 | 端末管理台帳とポリシーを照合する |
| 6月下旬 | Beta代表ユーザー候補、業務Webアプリ一覧 | 部門ごとに1人から数人を選ぶ |
| 7月上旬 | Edge 150 Stable/Extended Stable予定週 | 既存の更新リングで問題がないか見る |
| 7月下旬 | Edge 151 Stable予定週 | 2週間化前の最終確認として運用負荷を見る |
8月前半はEdge 152 Betaで代表検証する
Microsoft Learnの予定表では、Edge 152 Betaは2026年8月6日週です。この週を目安に、Betaリングの代表ユーザーで業務Web、SSO、拡張機能、PDF、印刷、WebView2アプリを確認します。
検証結果は、問題が出たかどうかだけでなく、問い合わせの内容も残します。利用者が迷いやすいUI変更、ヘルプデスクが説明しにくい挙動、管理ポリシーで抑えるべき機能が見つかれば、Stable展開前に告知や設定を調整できます。
8月下旬はStableとExtended Stableの選択を確定する
Edge 152のStableとExtended Stableは、予定表上ではどちらも2026年8月27日週です。ここで、Stableへ進む部署、Extended Stableを選ぶ部署、展開を遅らせる部署を決めます。
Stableを選ぶ部署では、2週間ごとの小さな更新を受ける前提で、軽い確認サイクルを作ります。Extended Stableを選ぶ部署では、約8週間ごとの機能更新を前提に、セキュリティ更新や重要修正の確認を続けます。どちらも「何もしない」ではなく、運用を選ぶ話です。
最低限の確認表
| 確認項目 | 具体的に見ること | 担当 |
|---|---|---|
| チャネル | Stable、Extended Stable、Betaの対象端末 | 端末管理 |
| 業務アプリ | 社内ポータル、SaaS、WebView2、PDF、印刷 | アプリ担当 |
| 認証 | SSO、証明書、条件付きアクセス、プロキシ | ID/セキュリティ |
| 拡張機能 | 必須拡張、DLP、パスワード管理、電子署名 | IT管理 |
| 周知 | 利用者告知、ヘルプデスクFAQ、既知問題 | サポート |
| 例外 | 延期部署、Extended Stable候補、承認者 | 変更管理 |
公開後に追うべき更新
- 1Release schedule
Edge 152、153、154のBeta、Stable、Extended Stableの予定週が変わったら、社内カレンダーも更新します。
- 2Stable release notes
Edge 152 Stable公開後は、新機能よりもポリシー変更、既知問題、セキュリティ修正、プラットフォーム別の注意を優先して見ます。
- 3Edge Blog
企業向けFAQ、Extended Stableの補足、段階的ロールアウトの追加説明が出た場合は判断材料として反映します。
- 4Message Center
テナント向けの案内が出た場合は、一般公開情報だけではなく自社環境向けの通知として扱います。
この記事の確認日は2026年6月12日です。予定情報は公開後も変わる可能性があるため、一次情報の更新に合わせて見直します。
この記事は、2026年6月12日時点の一次情報をもとにしています。Edgeのリリース予定表は、ビルド状況によって変わる可能性があります。記事を社内資料に使う場合は、公開時点の説明として扱い、Microsoft Learnの更新を追ってください。
Microsoft Learnのリリース表を更新履歴で追う
Edge 152、153、154のBeta、Stable、Extended Stableの予定週が変わった場合、社内カレンダーも変える必要があります。特にEdge 152は、新サイクルの開始点として扱われるため、Beta検証とStable展開の間隔を見直す可能性があります。
Stable release notesでポリシー変更を追う
Edge 152 Stableが出た後は、新機能よりもポリシー変更と既知問題を優先して確認したいところです。新しい管理ポリシー、非推奨、既定値変更、セキュリティ修正、プラットフォーム別の注意は、利用者影響に直結します。
Microsoft Edge BlogとMessage Centerの追加説明を見る
Microsoft Edge Blogでは、今後も追加説明が出る可能性があります。企業向けFAQ、Extended Stableの補足、Enterprise PreviewやBeta pilotの案内、Microsoft 365 Message Centerでのテナント向け通知が出た場合は、自社の運用メモを更新します。
Edgeの変更は、WindowsやMicrosoft 365の管理者向け更新ともつながります。端末管理、Intune、Entra IDの観点まで広げて見るなら、<a href="https://msft-watch.blog.mo-gmo.com/msft-30-project-solara-agent-first-devices-mdep-intune-entra/">Project SolaraはBuild 2026で初公開：MDEP、Intune、Entra IDでAIエージェント端末を読む確認ポイント</a>も隣接テーマとして読めます。
次に読むなら
参照した主な情報源
- Microsoft Edge Blog, "Faster updates, enterprise-friendly schedule: the new Microsoft Edge release cycle"。2026年6月12日JST確認。https://blogs.windows.com/msedgedev/2026/06/11/faster-updates-enterprise-friendly-schedule-the-new-microsoft-edge-release-cycle/
- Microsoft Learn, "Microsoft Edge release schedule"。2026年6月12日JST確認。https://learn.microsoft.com/en-us/deployedge/microsoft-edge-release-schedule
- Microsoft Learn, "Microsoft Edge channel overview"。2026年6月12日JST確認。https://learn.microsoft.com/en-us/deployedge/microsoft-edge-channels
- Microsoft Learn, "Microsoft Edge Lifecycle Policy"。2026年6月12日JST確認。https://learn.microsoft.com/en-us/deployedge/microsoft-edge-support-lifecycle
- Microsoft Learn, "Microsoft Edge release notes for Stable Channel"。2026年6月12日JST確認。https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel
- 窓の杜, "Microsoft Edgeもメジャーアップデート周期が短縮、2週間ごとに"。需要シグナルとして2026年6月12日JST確認。https://forest.watch.impress.co.jp/docs/news/2116563.html
更新履歴
- 2026年6月12日
Microsoft Edge Blog、Microsoft Learnのrelease schedule、channel overview、Lifecycle Policy、Stable release notesを確認し、Edge 152からのStable 2週間サイクル、Extended Stableの8週間維持、管理者の検証リング見直しを整理しました。
今後、予定週、対象バージョン、ポリシー変更、既知問題が変わった場合は、この履歴に追記して判断の前提を残します。
- 2026年6月12日: Microsoft Edge Blog、Microsoft Learnのrelease schedule、channel overview、Lifecycle Policy、Stable release notesを確認し、Edge 152からのStable 2週間サイクル、Extended Stableの8週間維持、管理者の検証リング見直しを整理しました。