Microsoft Edge 149 Stableは、単なるブラウザー更新ではなく、企業管理者が確認すべきポリシー変更、機能削除、Copilot関連の制御変更、WebView2 Runtimeのダウングレード対応を含む実務上の重要アップデートです。特に注意したいのは、Collectionsの削除、Copilot Chat制御方法の変更、カスタムプライマリパスワードの廃止、WebView2の一時的なバージョン戻しに関する新ポリシーです。
Microsoft公式リリースノートでは、Microsoft Edge Stable 149.0.4022.52が2026年6月4日のStable版として掲載されています。今回の「Microsoft Edge 149 Stable release adds enterprise policy and feature changes」は、IT管理者、情シス担当者、WebView2利用アプリの開発・運用担当者、CopilotやEdgeポリシーを管理している組織にとって、更新前に確認すべき内容が多いリリースです。(Microsoft Learn)
Microsoft Edge 149 Stableでまず押さえるべき変更点
Microsoft Edge 149 Stableの変更点は、大きく分けると以下の5つです。
| 変更領域 | 主な内容 | 影響を受けやすい対象 |
|---|---|---|
| ユーザー機能 | Collectionsの削除、Workspaces移行、外観更新 | 一般ユーザー、社内ナレッジ整理にEdgeを使う部門 |
| 認証・パスワード | Passkey Sync、カスタムプライマリパスワード廃止 | セキュリティ管理者、ID管理担当者 |
| Copilot制御 | Copilot Chatとアドレスバー候補の管理ポリシー変更 | Microsoft 365管理者、Edgeポリシー管理者 |
| WebView2 | アプリ単位の一時的なRuntimeダウングレード | 業務アプリ開発者、運用保守担当者 |
| ポリシー | 新規ポリシー追加、非推奨ポリシー、対応OS変更 | Intune、GPO、MDM管理者 |
今回のアップデートで最も避けたいのは、「自動更新後にユーザーから問い合わせが来て初めて変更に気づく」状態です。特にCollectionsを業務メモや調査リンクの保存に使っている場合、更新前の退避が必要です。
Collectionsは削除、必要なデータは更新前に退避する
Microsoft Edge 149 Stableでは、Collectionsが削除され、ユーザーは同機能にアクセスしたり利用したりできなくなります。Microsoftは、保存済みコンテンツを保持したい場合、Edge Stable 149へ更新する前にエクスポートするか、すべてのページをお気に入りへ移動するよう案内しています。(Microsoft Learn)
これは、単なるUI変更ではありません。Collectionsを以下のように使っていた組織では、更新前に移行手順を周知する必要があります。
- 調査中のWebページを一時保存している
- 部門内のナレッジ収集に使っている
- 営業資料、競合情報、採用候補者情報などのリンクをまとめている
- 個人の作業メモとしてCollectionsを使っている
代替先として最も現実的なのは、お気に入り、OneNote、SharePoint、Teamsのチャネル投稿、社内Wikiです。単に「お気に入りへ移動してください」と案内するだけでは、後で探しにくくなる可能性があります。部署単位で使っていたCollectionsは、SharePointページやTeamsの固定投稿に整理した方が運用しやすくなります。
更新前にユーザーへ案内したい移行手順
| 作業 | 推奨タイミング | 補足 |
|---|---|---|
| Collectionsの利用有無を確認 | 更新前 | 利用者が少なくても、特定部門で依存している場合がある |
| 必要なページをお気に入りへ移動 | 更新前 | フォルダー名を決めておくと後で探しやすい |
| 業務共有リンクはSharePointやTeamsへ移す | 更新前 | 個人ブラウザー内に閉じた情報を減らせる |
| 移行後にEdge 149を展開 | 検証後 | 問い合わせ削減につながる |
失敗しやすいのは、IT部門側でCollectionsの利用実態を把握していないケースです。Edgeの利用ログだけでは、Collectionsに保存された内容までは通常分かりません。社内告知では「使っている人だけ対応してください」ではなく、「Edge右上メニューやサイドバーからCollectionsを使っていた人は必ず確認してください」と具体的に書くと伝わりやすくなります。
WorkspacesはV2アーキテクチャへ移行、共有機能の扱いに注意
Microsoft Edge Workspacesは、保存済みタブのセットを作成し、必要に応じて他者と共有できる機能として提供されてきました。Edge 149では、信頼性とパフォーマンス向上を目的として、保存済みWorkspacesのデータがOneDriveまたはSharePointからEdge Syncサービスへ移行され、コラボレーションおよび共有機能が削除されます。(Microsoft Learn)
管理者が注意すべきポイントは、Syncをポリシーで無効化している組織でも、既存のv1 Workspaceデータは新しいアーキテクチャへ移行されるという点です。一方で、移行後に新しく作成されるv2 Workspacesはデバイス間で同期されず、各デバイスのローカルに残ると説明されています。(Microsoft Learn)
つまり、Workspacesを「複数端末で同じ作業セットを開く機能」として使っていたユーザーと、「チームで同じタブセットを共有する機能」として使っていたユーザーでは影響が異なります。
| 利用方法 | Edge 149での確認ポイント |
|---|---|
| 個人のタブ整理 | 既存データが移行されるか、主要端末で確認する |
| 複数端末での作業継続 | Sync無効環境では新規v2 Workspacesが端末間同期されない点を案内する |
| チーム共有 | 共有機能削除の影響が大きいため、Teams、SharePoint、OneNoteなどへ移す |
| プロジェクトごとのリンク集 | Edge内の作業領域ではなく、社内で管理できる場所へ移行する |
現場で混乱しやすいのは、「Workspacesが消える」のではなく、「共有や同期の前提が変わる」点です。ユーザー向け告知では、機能名だけでなく「他の人と同じタブセットを共有していた場合は代替手段が必要」と説明すると問い合わせを減らせます。
Passkey Syncが企業ユーザー向けに追加、ただし段階的ロールアウト
Edge 149では、企業ユーザー向けにPasskey Syncのサポートが導入されます。これにより、Edgeで作成したパスキーをデバイス間で同期し、パスワードレス認証の利用体験を改善できるとされています。ただし、この機能は制御されたロールアウトのため、すべての環境で同時に表示されるとは限りません。(Microsoft Learn)
管理者が確認すべきなのは、次の3点です。
1つ目は、社内の認証方針です。パスキーを推進している組織では、Edge 149を機に利用範囲やサポート手順を見直す価値があります。
2つ目は、ネットワーク要件です。Microsoft Edgeのエンドポイント許可リストには、パスキー認証に関連するクラウド認証サービスとして wss://edgepasskeysenclave.microsoft.com が掲載されています。ファイアウォールやプロキシで通信を厳格に制御している環境では、公式ドキュメントを確認しながら必要な通信を許可する必要があります。(Microsoft Learn)
3つ目は、問い合わせ対応です。段階的ロールアウトでは、「同じバージョンなのに自分の端末では見えない」という問い合わせが起きやすくなります。ヘルプデスク向けには、機能の有無をバージョンだけで判断しないよう共有しておくと安全です。
WebView2 Runtimeはアプリ単位で一時的にダウングレード可能に
Edge 149の管理者向け変更で特に実務的なのが、WebView2 Evergreen Runtimeの一時的なダウングレードに関する新ポリシーです。Microsoftは、msedgewebview2.admx の新しい DowngradeVersion ポリシーにより、管理者が特定アプリを以前のWebView2 Evergreen Runtimeバージョン、具体的にはN-1またはN-2へ一時的に戻せると説明しています。(Microsoft Learn)
WebView2を使う業務アプリでは、Edge本体では問題がなくても、埋め込みブラウザー部分だけで表示崩れ、認証画面の不具合、JavaScriptの挙動差、印刷やPDF表示の問題が起きることがあります。従来は、Runtime更新に起因する障害が発生した場合、修正を待つか、アプリ側で回避するか、端末単位で調整する必要がありました。今回のポリシーは、特定アプリに絞って一時退避できる点が実務上のメリットです。
Microsoft Edge WebView2ポリシー文書では、DowngradeVersion はWindowsのEdge 149以降でサポートされ、値名にアプリケーションユーザーモデルIDまたは実行ファイル名、値に対象のメジャーバージョン番号を数字のみで指定すると説明されています。フルバージョン文字列やワイルドカード、数字以外を含む値はサポートされません。(Microsoft Learn)
WebView2 DowngradeVersionを使うべき場面、使うべきでない場面
| 判断 | 具体例 | 対応 |
|---|---|---|
| 使うべき | 特定の業務アプリだけがWebView2更新後に起動しない | 対象exeに限定して一時的にN-1またはN-2へ戻す |
| 使うべき | 認証画面や帳票画面だけが特定バージョンで壊れる | 影響範囲を確認し、暫定回避として設定する |
| 慎重に使う | 原因がWebView2かアプリ側コードか未確認 | 先にログ、再現条件、Runtimeバージョンを確認する |
| 使うべきでない | すべての端末を恒久的に古いRuntimeへ固定したい | セキュリティと保守性の面で避ける |
| 使うべきでない | 問題がWebサイト側の仕様変更である | アプリ修正やサイト側対応を優先する |
このポリシーは「更新を止めるための仕組み」ではなく、「重大な回帰を一時的に回避するための仕組み」と考えるべきです。Microsoftのリリースノートでも、ダウングレードはリリースごとに自動期限切れの考え方があり、N-1やN-2に固定したアプリは次のリリースで更新側へ戻る流れが説明されています。(Microsoft Learn)
開発・運用チームでは、以下のような確認項目を用意しておくと対応が速くなります。
| 確認項目 | 見るポイント |
|---|---|
| 影響アプリ | exe名、配布形態、利用部門 |
| 再現条件 | 画面、操作、認証、印刷、ファイルアップロードなど |
| Runtimeバージョン | 正常端末と異常端末で差があるか |
| 回避対象 | 全社ではなく、対象アプリ・対象端末に限定できるか |
| 恒久対応 | アプリ修正、ライブラリ更新、ベンダー修正の予定 |
Copilot Chatの制御は拡張機能ブロックから専用ポリシー中心へ
Edge 149では、Copilot Chat関連の管理方法にも重要な変更があります。Microsoftは、Copilot Chatの標準的な構成ポリシーとして Microsoft365CopilotChatIconEnabled を示し、従来のようにCopilot拡張機能を明示的にブロックしたり、ExtensionSettings や ExtensionInstallBlockList で * ワイルドカードを使ったりして制御していた方法は、Copilot Chatの表示や機能に影響しなくなると説明しています。(Microsoft Learn)
さらに、Edge 149からはアドレスバーのCopilot候補を CopilotAddressBarSuggestionsEnabled ポリシーで管理できます。公式ポリシー文書では、このポリシーはWindowsおよびmacOSのEdge 149以降でサポートされ、無効化するとMicrosoft EdgeのアドレスバーにCopilot Chat候補が表示されなくなると説明されています。(Microsoft Learn)
この変更の実務上の意味は明確です。Copilotを禁止または制限したい場合、拡張機能ブロックやサイドバー関連の設定に頼るのではなく、Copilot用に用意されたEdgeポリシーを確認する必要があります。
管理者が確認すべきCopilot関連設定
| 確認対象 | 見直す理由 |
|---|---|
| Microsoft365CopilotChatIconEnabled | Copilot Chat表示制御の標準ポリシーとして扱われる |
| CopilotAddressBarSuggestionsEnabled | アドレスバーのCopilot候補表示を制御する |
| ExtensionSettings | Copilot制御目的で使っていた場合、期待どおり効かない可能性がある |
| ExtensionInstallBlockList | ワイルドカードで拡張機能を一括ブロックしている環境は要確認 |
| サイドバー関連ポリシー | Copilot Chatの表示・機能制御とは切り分けて確認する |
Copilot関連の設定は、ユーザー体験と情報管理の両方に関係します。利用を許可する場合も禁止する場合も、「表示されるかどうか」だけでなく、どのプロファイルで有効にするか、業務アカウントと個人アカウントで挙動が異なるか、ネットワークやDLPのポリシーと矛盾しないかを確認しておくべきです。
カスタムプライマリパスワードは廃止、デバイス認証へ移行
Edge 149では、ユーザーがEdge設定画面から新しいカスタムプライマリパスワードを作成できなくなります。既にカスタムプライマリパスワードを使っているユーザーは、デバイス認証へ自動的に移行されます。また、PrimaryPasswordSetting ポリシーは WithCustomPrimaryPassword オプションをサポートしなくなります。(Microsoft Learn)
PrimaryPasswordSetting の公式ポリシー文書でも、Custom Primary Password機能はEdge 149で削除され、現在この設定を有効にしているユーザーは「デバイスのサインインオプションを求める」認証方式へ自動移行されると説明されています。(Microsoft Learn)
管理者が特に確認すべきなのは、以下のような環境です。
- パスワード自動入力時に追加認証を必須化している
- Windows Hello、PIN、顔認証、指紋認証を使っている
- 共有PCやVDI環境でEdgeのパスワード保存を制御している
PrimaryPasswordSettingをGPO、Intune、MDMで配布している
ポリシー文書では、WithDevicePassword を設定した場合、ユーザーは保存済みパスワードの自動入力前に、Windows Hello、PIN、顔認証、指紋などのデバイス側の認証方法で本人確認すると説明されています。(Microsoft Learn)
実務上は、カスタムパスワード廃止そのものよりも、ユーザーが「Edgeのパスワード入力時に求められる認証が変わった」と感じることが問い合わせにつながります。ヘルプデスクには、「Edge独自のカスタムパスワードではなく、端末のサインイン認証に移る」と説明できるよう準備しておきましょう。
新規ポリシーと変更ポリシーの確認ポイント
Edge 149では、複数の新規ポリシーが追加されています。公式リリースノートでは、以下のポリシーが新規ポリシーとして掲載されています。(Microsoft Learn)
| ポリシー | 用途 |
|---|---|
| CopilotAddressBarSuggestionsEnabled | Copilotのアドレスバー候補を有効化または無効化 |
| CpuPerformanceTierOverride | CPUパフォーマンス階層の上書き |
| DataUrlInWebWorkerOpaqueOriginEnabled | Web Worker内のdata URLに対するopaque originを有効化 |
| DefaultLocalFontsSetting | ローカルフォント権限の既定設定 |
| ForceForegroundPriorityForUrls | 特定URLをフォアグラウンド優先にする |
| LocalFontsAllowedForUrls | 指定サイトでローカルフォント権限を許可 |
| LocalFontsBlockedForUrls | 指定サイトでローカルフォント権限をブロック |
追加ポリシーの中で、一般的な企業管理者が特に確認しやすいのは CopilotAddressBarSuggestionsEnabled とローカルフォント関連ポリシーです。
ローカルフォント権限は、デザインツール、帳票システム、社内DTP系Webアプリなどに影響する可能性があります。ローカルPCにインストールされたフォントをWebアプリが利用する業務がある場合、許可・ブロックの対象URLを明確にしておくと、セキュリティと業務要件のバランスを取りやすくなります。
また、Edge 149では WalletDonationEnabled と EdgeWalletEtreeEnabled が非推奨ポリシーとして掲載されています。さらに、ForceForegroundPriorityForOrigins は ForceForegroundPriorityForUrls へ名称変更され、OnSecurityEventEnterpriseConnector にはmacOS対応が追加される一方、ProtectedContentIdentifiersAllowed はmacOS対応が削除されます。(Microsoft Learn)
ポリシー更新で失敗しやすいのは、ADMXテンプレートの更新漏れです。新しいポリシーをIntuneやGPOで設定しようとしても、管理テンプレートや設定カタログ側に反映されていなければ運用に乗せにくくなります。Edge 149の検証では、ブラウザー本体の更新だけでなく、管理テンプレート、Intuneプロファイル、既存のレジストリ設定も合わせて確認してください。
開発者が確認したいWeb Platform変更
Microsoft Edge 149では、Web Platform側にも複数の変更があります。公式のWeb Platformリリースノートでは、Edge 149のWebプラットフォーム更新として、CSS、Web API、PWA、Service Worker、Clipboard API、WebSocketとbfcache関連の変更などが掲載されています。(Microsoft Learn)
企業のWebアプリやSaaSをEdge前提で検証している場合、特に以下を確認するとよいでしょう。
| 変更 | 確認したいシステム |
|---|---|
image-rendering: crisp-edges 対応 | ドット絵、QRコード、図面、低解像度画像を拡大表示する画面 |
<table> の既定 border-color 変更 | CSSを明示していない古い帳票・一覧画面 |
accent-color: auto の挙動変更 | フォーム部品の色をOSテーマ前提にしているWebアプリ |
| cross-origin iframeやPDFへのSVG filter無効化 | iframe埋め込み、PDF表示、装飾効果を使う画面 |
| PWAの同一サイト内origin移行 | PWAのドメイン変更やサブドメイン移行を予定しているサービス |
scrollBy / scrollTo のPromise対応 | スムーススクロール完了後に処理するUI |
| WebSocketのbfcache対応 | チャット、リアルタイム監視、管理画面 |
特に注意したいのは、開発者がCSSを明示していない古い画面です。Edge 149では、<table> に対するユーザーエージェントスタイルシートの誤った border-color: gray ルールが削除され、テーブル罫線の既定が仕様に沿う形へ変わります。見た目の差が小さくても、帳票や社内管理画面では「線の色が変わった」と指摘される可能性があります。(Microsoft Learn)
また、WebSocket接続を開いたページがbfcacheに入る際、従来のようにキャッシュを妨げるのではなく、WebSocket接続が閉じられるようになります。ページ復帰時には pageshow イベントで event.persisted を確認し、必要に応じて再接続する設計が求められます。(Microsoft Learn)
Edge 149の展開前チェックリスト
Microsoft Edge Stable Channelの更新は、環境によって配信タイミングが異なります。MicrosoftはStable Channelのメジャー更新について、段階的ロールアウトを数日かけて行う仕組みを説明しています。Intuneで自動更新を管理している企業では段階的ロールアウトの影響を受けますが、WSUSやConfiguration Managerで配布している企業では管理者が更新を適用する流れになります。(Microsoft Learn)
Edge 149を展開する前に、以下を確認しておくと安全です。
| チェック項目 | 確認内容 |
|---|---|
| Collections利用者 | 必要データを更新前に退避したか |
| Workspaces利用状況 | 共有機能削除、Sync無効環境での挙動を案内したか |
| Copilotポリシー | 拡張機能ブロックではなく専用ポリシーで制御しているか |
| パスワード設定 | PrimaryPasswordSetting の古い値に依存していないか |
| WebView2アプリ | 主要業務アプリで表示、認証、印刷、PDF、ファイル操作を確認したか |
| ADMX・Intune | 新規ポリシーを管理画面で扱える状態か |
| macOS端末 | macOS対応が追加・削除されたポリシーの影響を確認したか |
| ヘルプデスク | ユーザー向けFAQを更新したか |
おすすめは、いきなり全社展開するのではなく、以下の順序で進めることです。
- 情シス部門と開発部門の検証端末へ先行適用する
- Collections、Workspaces、Copilot、パスワード認証、WebView2アプリを重点確認する
- 問い合わせが出そうな変更点をFAQ化する
- 部門単位または端末グループ単位で段階展開する
- 展開後にWebView2利用アプリとCopilot関連の問い合わせを監視する
特にWebView2を使うアプリがある組織では、ブラウザーの見た目だけを確認して完了にしないことが重要です。Edge本体が正常でも、業務アプリ内の埋め込みWeb画面で問題が出る可能性があります。
ユーザー向け告知に入れるべき内容
管理者向けの変更点をそのままユーザーへ伝えても、理解されにくい場合があります。社内告知では、影響がある人にだけ必要な行動が伝わるように書くのがポイントです。
たとえば、以下のように案内すると実務に落とし込みやすくなります。
| 対象者 | 告知内容の例 |
|---|---|
| Collections利用者 | Edge更新前に必要な保存ページをお気に入りや社内共有場所へ移してください |
| Workspaces利用者 | 共有機能の扱いが変わるため、チーム共有リンクはTeamsやSharePointへ移してください |
| Copilot利用者 | 表示場所や候補表示が管理ポリシーにより変更される場合があります |
| パスワード保存利用者 | 保存済みパスワードの自動入力時に、端末のサインイン認証が求められる場合があります |
| 業務アプリ利用者 | 更新後に画面表示、印刷、認証で問題があれば、アプリ名と操作手順を添えて連絡してください |
重要なのは、「Edgeが更新されます」だけで終わらせないことです。ユーザーが取るべき行動を1つか2つに絞り、問い合わせ時に必要な情報も示しておくと、初動対応が速くなります。
Microsoft Edge 149 Stableは管理ポリシーと移行確認が重要
Microsoft Edge 149 Stableは、見た目の更新や新機能追加だけでなく、企業運用に関わる変更がまとまって入るリリースです。特に、Collectionsの削除、WorkspacesのV2移行、Copilot Chat制御の変更、カスタムプライマリパスワードの廃止、WebView2の DowngradeVersion ポリシーは、更新前に確認しておきたいポイントです。
管理者はまず、CollectionsとWorkspacesの利用者を洗い出し、必要なデータ退避や代替手段を案内しましょう。次に、Copilot関連ポリシーと PrimaryPasswordSetting を見直し、古い制御方法に依存していないか確認します。WebView2利用アプリがある場合は、Edge本体とは別に主要業務アプリの動作検証を行い、問題発生時の一時回避策として DowngradeVersion を使えるか検討しておくと安心です。
Edge 149は、更新後に慌てて対応するより、事前に「どの機能を誰が使っているか」「どのポリシーを配布しているか」「どの業務アプリがWebView2に依存しているか」を確認することで、トラブルを大きく減らせるリリースです。
コメント