Edge Beta 152.0.4191.10で最優先に確認すべきなのは、目立つ新機能ではありません。unloadイベントの段階的な無効化、Edge Dropなどの機能廃止、WebSocketとバックフォワードキャッシュの挙動変更、新しい管理ポリシーです。
特に、業務Webアプリが画面終了時の保存処理や接続解除をunloadに依存している場合、入力内容の消失、ログ送信漏れ、リアルタイム通信の停止につながる可能性があります。まず業務依存を洗い出し、その後にポリシーとユーザー向け機能を検証するのが効率的です。
Edge Beta 152.0.4191.10は2026年8月6日に公開され、Edge 152 Stableは2026年8月27日に公開されました。すでにStable 152を導入している環境では、本記事の検証項目を適用後の影響監査として利用してください。また、Edge 152からStableのメジャー更新間隔は2週間へ短縮されています。管理対象環境では8週間間隔のExtended Stableも選択できるため、検証体制に合わせて更新チャネルを見直すことも重要です。(Microsoft Learn)
Edge Beta 152.0.4191.10で最初に確認すべきポイント
変更点をすべて同じ優先度で確認する必要はありません。業務停止やデータ消失につながる項目から順番に検証します。
| 確認項目 | 影響を受けやすい環境 | 優先度 | 主な確認内容 |
|---|---|---|---|
unloadイベントの無効化 | 社内Webシステム、入力フォーム、SPA | 最優先 | 保存、ログ送信、セッション終了処理が失敗しないか |
| bfcacheとWebSocket | チャット、監視画面、ダッシュボード | 最優先 | 戻る操作後に自動再接続できるか |
| Local Network Access | localhost連携、プリンター、スキャナー、POS | 高 | ローカル機器への接続がブロックされないか |
| Edge Dropの廃止 | 端末間のファイル・メモ共有 | 高 | 必要なファイルとテキストメモを退避したか |
| 新しい管理ポリシー | Active Directory、Intune管理端末 | 高 | 対応OS、対応バージョン、適用結果を確認したか |
| Googleデータのインポート、Appleアカウント | 共有端末、業務用プロファイル | 中 | 個人アカウントや個人データを持ち込めない設定か |
| WebView2のダウングレード指定 | WebView2組み込み業務アプリ | 中 | 4桁の正確なランタイムバージョンを指定しているか |
| 動画のリアルタイム翻訳の廃止 | 研修、外国語動画、アクセシビリティ用途 | 中 | 代替手段を用意しているか |
最優先で調べるべきunload依存
Edge 152ではunloadが常に実行されるとは限らない
Edge 152と153では、ページ読み込みの60％でunloadハンドラーが既定で実行されなくなります。この割合はEdge 154で80％、Edge 155で100％へ拡大する予定です。
unloadは以前から、タブ終了、ブラウザー終了、モバイル端末のプロセス停止などで確実に実行されるイベントではありません。また、unloadの登録はバックフォワードキャッシュの利用を妨げる原因にもなります。Edge 152で突然始まった問題というより、信頼性の低い実装から移行するための段階的な変更と考えるべきです。(Microsoft Learn)
影響が出やすい実装
次の処理にunloadやonunloadを使っているWebアプリは、優先的な確認が必要です。
- 入力フォームの内容を画面終了時に保存する
- 勤怠、申請、受注などの操作ログを最後に送信する
- 「ユーザーが画面を閉じた」とサーバーへ通知する
- WebSocketやSignalRの接続を終了する
- 編集中フラグやロック情報を解除する
- 一時ファイルやブラウザー内データを削除する
- セッション終了処理を実行する
特に危険なのは、unloadが実行されることを前提に、サーバー側のロック解除や保存確定を行っているシステムです。処理されなかった場合にデータが失われるだけでなく、次の利用者が編集できなくなることもあります。
ソースコードと外部ライブラリを検索する
自社開発システムでは、少なくとも次の文字列を検索します。
addEventListener("unload"
addEventListener('unload'
window.onunload
body onunload
onunload=自社コードに見つからなくても、アクセス解析、チャット、帳票、認証、セッション管理用の外部ライブラリが登録している場合があります。Edge DevToolsのイベントリスナーやソース検索も併用し、実際に読み込まれたJavaScriptまで確認してください。
Beta環境で実行するテスト
通常の画面遷移だけでは不十分です。次の操作を組み合わせて確認します。
- フォームへ入力し、保存せず別ページへ移動する
- ブラウザーの「戻る」「進む」を実行する
- 別タブへ切り替えてから元のタブへ戻る
- ページを再読み込みする
- タブやブラウザーウィンドウを閉じる
- ネットワークを一時的に切断してから復旧する
- 同じデータを別ユーザーまたは別端末から開く
合格条件は、「イベントが実行されたように見えること」ではありません。保存後のデータ、サーバーログ、ロック状態、通信状態を確認し、業務結果が正しいことを判定します。
visibilitychangeとpageshowへ移行する
入力データは、画面終了時に一度だけ保存するのではなく、入力中に定期保存する設計が安全です。そのうえで、ページが非表示になったタイミングに未送信データを送ります。
function flushTelemetry() {
const payload = JSON.stringify({
page: location.pathname,
recordedAt: new Date().toISOString()
});
navigator.sendBeacon("/api/telemetry", payload);
}
document.addEventListener("visibilitychange", () => {
if (document.visibilityState === "hidden") {
flushTelemetry();
}
});
window.addEventListener("pageshow", (event) => {
if (event.persisted) {
reconnectRealtimeChannel();
refreshCurrentScreen();
}
});このコードは考え方を示す例です。重要な申請データや取引データをsendBeacon()だけに任せるべきではありません。入力時の自動保存、IndexedDBへの一時保存、サーバー側の冪等性、再送処理を組み合わせます。
visibilitychangeのhiddenは、最終終了時だけでなくタブ切り替えでも発生します。したがって、同じデータが複数回送られても重複登録されない設計が必要です。
beforeunloadは、保存されていない変更がある場合に離脱確認を表示する用途で条件付き登録します。unloadの代替となる確実な保存イベントではありません。バックフォワードキャッシュから復元されたかどうかは、pageshowイベントのpersistedで判定できます。(Chrome for Developers)
Permissions Policyは恒久対策にしない
Permissions Policyを使ってunloadを一時的に許可する方法もあります。しかし、これはアプリ改修までの移行措置です。
例外設定だけでStable展開を続けると、将来の無効化時期に同じ問題が再発します。例外を設定する場合は、対象サイト、担当者、改修期限、解除予定日を管理台帳へ記録してください。
bfcacheとWebSocketの復元処理を確認する
Edge 152では、新しいBackForwardCacheForWebSocketsAllowedポリシーが追加されています。
ポリシーが有効または未構成の場合、ページがバックフォワードキャッシュへ保存される際に、アクティブなWebSocket接続が切断されます。ユーザーが「戻る」でページを復元しても、WebSocketは切断された状態です。
ポリシーを無効にすると、アクティブなWebSocketがあるページはバックフォワードキャッシュへ保存されません。つまり、ポリシーを無効にすれば接続再開の実装が不要になるわけではなく、ページ高速復元の利点を失うことになります。(Microsoft Learn)
影響を受けやすいのは次のシステムです。
- 社内チャット
- コールセンターの着信画面
- 株価、在庫、稼働状況などのリアルタイム表示
- WebSocketを利用した帳票生成状況の通知
- ブラウザー上のリモート操作システム
- SignalRや独自プッシュ通信を使う業務アプリ
検証では、接続中の画面から別ページへ移動し、「戻る」で復元します。その後、次の点を確認してください。
- 自動的に再接続される
- 認証トークンの期限切れを処理できる
- 切断中のデータを再取得できる
- 同じチャンネルへ二重登録されない
- 古い画面情報が残らない
- エラー表示だけが残らない
単にWebSocketの接続ステータスが「接続済み」になればよいわけではありません。復元直後にサーバーから最新状態を再取得し、画面表示との整合性を確認する必要があります。
廃止機能はデータ退避まで確認する
Edge DropはEdge 152で廃止
端末間でファイルやメモを送受信できるEdge Dropは、Edge 152で廃止されました。
Dropで共有したファイルはOneDriveに保存されますが、Drop内に入力したテキストメモは別途ダウンロードしておく必要があります。Edge 151以前の端末が残っている場合は、更新前に必要なテキストを退避します。すでにEdge 152へ更新した場合は、OneDrive上のファイル、バックアップ、別端末に残っているデータを確認してください。(Microsoft Learn)
組織内でDropを業務利用していた場合は、単に「使えなくなる」と案内するだけでは不十分です。用途ごとに代替手段を決めます。
| Dropで行っていたこと | 代替候補 | 移行時の確認 |
|---|---|---|
| 自分の端末間でファイルを渡す | OneDrive | 同期対象、保存場所、容量 |
| チームへファイルを共有する | SharePoint、Teams | アクセス権、共有リンクの期限 |
| 一時的な文章を保存する | OneNote、Microsoft Loop | 保存先、検索性、保持期間 |
| スマートフォンへ業務ファイルを送る | 管理対象OneDrive | モバイル端末管理、持ち出し制御 |
個人向けOneDriveへ業務データを保存していなかったかも確認します。代替ツールを用意しても、保存先のアカウントが不適切では情報漏えい対策になりません。
動画のリアルタイム翻訳も段階的に廃止
動画のリアルタイム翻訳機能も、Edge 152から段階的に廃止されます。提供状況は端末や展開状況によって異なり、関連するLiveVideoTranslationEnabledポリシーも非推奨になる予定です。(Microsoft Learn)
研修動画、外国語の説明会、問い合わせ対応などで利用している場合は、次の項目を整理します。
- どの部署が利用しているか
- 対象となる動画やサービス
- 字幕だけで業務を継続できるか
- 翻訳済み字幕を事前作成できるか
- アクセシビリティ上の代替策があるか
- 個人情報や機密情報を外部翻訳サービスへ送信してよいか
ポリシーを有効にしていても、廃止後の提供継続を保証するものではありません。「設定で延命する」のではなく、業務手順そのものを移行する必要があります。
Local Network Accessの延長を「対応不要」と判断しない
Edge Beta 152.0.4191.10では、LocalNetworkAccessRestrictionsTemporaryOptOutポリシーの削除時期が、当初予定されていたEdge 152からEdge 156より後へ延期されました。
ただし、延期されたのは一時的なオプトアウトポリシーの削除時期です。Local Network Accessの制限自体が中止されたわけではありません。オプトアウトを有効にすると、失敗したアクセスチェックがDevTools上の警告扱いになるため、問題を見逃しやすくなります。(Microsoft Learn)
影響を受けやすい構成は次のとおりです。
| 業務構成 | 具体例 | Beta環境での確認 |
|---|---|---|
| インターネット上のWebサービスからlocalhostへ接続 | 電子署名、印刷エージェント、スキャナー連携 | 許可確認の表示、接続成功、再接続 |
| 公開サイトからプライベートIPへ接続 | プリンター、NAS、ルーター、POS | 192.168.x.xなどへの通信結果 |
| iframe内のシステムがローカル接続する | ポータル内の業務画面 | 親フレームを含む権限委譲 |
| WebSocketでローカルサービスへ接続 | 常駐アプリ、機器監視 | 初回接続、再接続、証明書エラー |
| VPN経由で内部システムへ接続 | 在宅勤務、拠点間接続 | 社内と社外の両ネットワークで確認 |
恒久対応の優先順位は次のとおりです。
- WebアプリをLocal Network Access対応へ改修する
- iframeを使う場合は、必要なフレーム階層で
local-network-accessを許可する - 信頼できる接続元だけを
LocalNetworkAccessAllowedForUrlsで許可する - 改修までの期間に限り、一時オプトアウトを利用する
LocalNetworkAccessAllowedForUrlsは、ローカル機器のIPアドレスを無条件に許可する考え方ではありません。アクセスを開始する信頼済みオリジンを管理します。全サイトを対象にした広範な例外設定は避けてください。(Microsoft Learn)
検証時には一時オプトアウトを無効にした状態でもテストします。オプトアウトを有効にしたままでは、将来ポリシーが削除されたときの挙動を再現できません。
Copilot Coworkの操作権限を明示する
Edge 152では、CopilotCoworkToolActionsEnabledポリシーが追加されました。Coworkがタブ操作、スクリーンショット取得、Webページ上の操作などを実行できるかを管理します。
ただし、Microsoft 365管理センターでCowork Browsingがテナント全体に対して有効になっていることが前提です。ブラウザーポリシーだけを設定しても、テナント側の機能が無効であれば利用できません。(Microsoft Learn)
| ポリシー設定 | ユーザーの状態 |
|---|---|
| 有効 | Coworkのツール操作が許可され、ユーザーは変更できない |
| 無効 | ツール操作が禁止され、ユーザーは変更できない |
| 未構成 | ユーザーが設定を変更できる |
機密情報を扱う組織では、未構成のままにしないことが重要です。次の観点から許可範囲を決めます。
- 顧客情報や人事情報が表示された画面を扱うか
- Webページ上のボタン操作をAIへ任せてよいか
- 外部サービスへの入力や送信を伴うか
- 操作ログをどこまで取得できるか
- 誤操作が発生した場合の責任分界を定めているか
検証では、ポリシーを有効、無効、未構成の3状態に切り替え、ユーザーが設定を変更できるかまで確認してください。
GoogleデータのインポートとAppleアカウントを分けて管理する
Edge 152では、設定画面からGoogleアカウントのデータを任意のタイミングでインポートする機能が段階的に展開されます。対象には、パスワード、お気に入り、履歴、自動入力データなどが含まれます。また、WindowsとmacOSではAppleアカウントによるサインインも段階的に提供されます。(Microsoft Learn)
GoogleアカウントやAppleアカウントによるサインインは、NonMicrosoftAccountSignInEnabledで制御できます。無効にすると、対応するサインインの入口が非表示または利用不可になります。Microsoftアカウントのサインインまで無効になるポリシーではありません。(Microsoft Learn)
一方、アカウントのサインイン制御とブラウザーデータのインポート制御は、別の設定として確認する必要があります。業務用プロファイルへ個人データを持ち込ませたくない場合は、少なくとも次のポリシーを確認します。
ImportSavedPasswordsImportFavoritesImportHistoryImportAutofillFormData
これらのポリシーを無効にすると、初回起動時だけでなく、ユーザーが設定画面から手動で実行する該当データのインポートも制限できます。(Microsoft Learn)
検証対象は、初回起動だけに限定しないでください。既存プロファイルの設定画面、管理対象プロファイル、個人プロファイル、Windows、macOSの組み合わせを確認します。
パスワード表示と通知解除のUI変更も確認する
Edge 152では、アドレスバーの鍵アイコンから保存済み資格情報の詳細パネルを開き、ユーザー名やパスワードのコピー、パスワード表示、メモの確認などを行える変更が段階的に展開されます。
共有端末、VDI、窓口端末、画面共有を多用する部署では、次の点を確認してください。
- ブラウザーへのパスワード保存を許可してよいか
- パスワード表示時にOS認証が適切に要求されるか
- 離席時の画面ロックが徹底されているか
- 画面共有中に資格情報を表示しない手順があるか
- 共用アカウントのパスワードが保存されていないか
また、詐欺サイトや悪意のある通知元から自動的に登録解除する機能も段階的に展開されます。Webプッシュ通知を業務で使用している場合は、正規サイトの通知登録が維持されることも確認します。これらは制御された機能ロールアウトであり、すべてのBeta端末へ同時に表示されるとは限りません。(Microsoft Learn)
画面に機能が表示されなかったことを「問題なし」と判定してはいけません。未展開なのか、ポリシーで無効なのか、対象外の端末なのかを区別してください。
新しいポリシーは対応バージョンまで確認する
Edge Beta 152.0.4191.10のリリースノートには複数の新しいポリシーが掲載されました。しかし、Beta時点の一覧と、最終的にStableで提供された一覧が完全に同じとは限りません。
| ポリシー | 対象・用途 | 検証ポイント |
|---|---|---|
BackForwardCacheForWebSocketsAllowed | Edge 152以降。WebSocket使用ページのbfcache動作 | 戻る操作後の再接続とデータ更新 |
CopilotCoworkToolActionsEnabled | Edge 152以降。Windows、macOS | 有効、無効、未構成の権限差 |
UpdateOnZeroWindowEnabled | Edge 152以降。macOS | 全ウィンドウ終了後のバックグラウンド更新 |
LaunchEdgeOnWindowsStartupEnabled | Windows起動時のEdge起動 | Edge 152ではなく、対応バージョンを再確認 |
ShowHistoryThumbnails | 履歴サムネイル制御 | Edge 152で削除された古い設定を整理 |
UpdateOnZeroWindowEnabledが有効または未構成の場合、macOS上で保留中の更新を適用するため、すべてのEdgeウィンドウを閉じた後にバックグラウンドでEdgeが再起動することがあります。無効にすると、この動作を禁止できます。(Microsoft Learn)
注意が必要なのはLaunchEdgeOnWindowsStartupEnabledです。このポリシーはBeta 152のリリースノートには掲載されましたが、現在のポリシー資料ではEdge 153以降がサポート対象となっており、Stable 152の最終的な新規ポリシー一覧にも含まれていません。
したがって、Betaの一覧だけを根拠にEdge 152用設定として展開してはいけません。実際に導入するEdgeのバージョン、最新のポリシーテンプレート、正式なポリシー資料を突き合わせて判断します。(Microsoft Learn)
edge://policyで実際の適用結果を確認する
管理コンソール上で「設定済み」と表示されても、端末へ正しく反映されているとは限りません。テスト端末でedge://policyを開き、次の項目を確認します。
- ポリシー名が認識されている
- 想定した値が表示されている
- 対象スコープが正しい
- エラーや競合が表示されていない
- ポリシー再読み込み後も値が維持される
- ブラウザー再起動後に動作が変わる
- 削除済みポリシーが管理テンプレートに残っていない
ShowHistoryThumbnailsのように削除されたポリシーが表示されなくなった場合、配布障害と誤認しないようにします。古いGPO、Intune構成、設定台帳からも不要な項目を整理してください。(Microsoft Learn)
WebView2アプリは4桁のランタイムバージョンで確認する
Edge 152では、WebView2のDowngradeVersionに指定するバージョンとして、4つの数字を含む完全なバージョン番号が必要です。メジャーバージョンだけを指定する方法はサポートされません。
さらに、指定したバージョンと完全に一致するランタイムフォルダーが存在しなければ、設定は効果を発揮しません。その場合は、BrowserExecutableFolderで指定されたランタイムやEvergreen Runtimeなど、通常の選択処理へ戻ります。(Microsoft Learn)
WebView2を使用する業務アプリでは、次の情報を証跡として残します。
- Edgeの完全なバージョン番号
- WebView2 Runtimeの完全なバージョン番号
- アプリが実際に読み込んだランタイム
DowngradeVersionへ設定した値- 対象ランタイムフォルダーの存在
- ダウングレード前後の起動結果
- 認証、印刷、ファイル選択、PDF表示の結果
ダウングレードは、問題の切り分けや緊急回避には利用できますが、アプリ改修の代わりにはなりません。終了条件と元のランタイムへ戻す日程も決めておきます。
Beta環境で実施する推奨テスト手順
業務依存を台帳化する
最初に、Edgeの機能名ではなく業務名から洗い出します。
| 台帳へ記録する項目 | 記入例 |
|---|---|
| 業務名 | 電子申請受付 |
| システム名 | 申請管理Web |
| 利用部署 | 総務課、窓口 |
| 重要操作 | 入力、添付、送信、印刷 |
| Edge依存 | unload、WebSocket、localhost印刷 |
| 管理ポリシー | LNA許可、パスワードインポート禁止 |
| 合格条件 | データ消失なし、印刷成功 |
| 問題発生時の対応 | Stable更新保留、旧手順へ切り替え |
| 担当者 | システム管理者、業務主管課 |
「Edge Dropを使っている人がいるか」と尋ねるだけでは、機能名を知らない利用者を拾えません。「パソコンとスマートフォンの間でEdgeを使ってファイルを送っているか」のように、実際の操作で確認します。
代表環境を用意する
すべてを1台の管理者PCだけで確認すると、実際の問題を見逃します。少なくとも次の環境を含めます。
- 一般利用者と同じ権限のWindows端末
- GPOまたはIntune管理端末
- macOS管理端末
- プロキシ、VPN、Webフィルタリングを通る端末
- WebView2アプリを利用する端末
- ローカル機器と接続する端末
- 共有PCまたはVDI
- 標準ユーザーと管理者で設定が異なる端末
バージョンとポリシーを固定して記録する
「Edge 152で確認した」だけでは、再現に必要な情報が不足します。少なくとも152.0.4191.10のような完全なバージョン番号、OSビルド、適用ポリシー、テスト日時、利用者のアカウント種別を記録します。
制御された機能ロールアウトでは、同じバージョンでも端末によって機能の有無が異なる場合があります。UI表示の違いも証跡へ残してください。(Microsoft Learn)
実際の業務シナリオで判定する
| テスト対象 | 実行する操作 | 合格条件 |
|---|---|---|
| 入力フォーム | 入力後に別ページへ移動し、戻る | 入力内容と保存状態が正しい |
| WebSocket画面 | 接続中に移動し、戻る | 自動再接続し、最新情報を表示 |
| localhost連携 | 印刷や署名処理を実行 | 許可処理を含めて正常完了 |
| Drop移行 | 過去ファイルとメモを確認 | 必要データを別サービスへ退避済み |
| Cowork | 有効、無効、未構成を切り替える | 組織方針どおり操作可否が変わる |
| データインポート | 設定画面から手動インポート | 禁止対象データを持ち込めない |
| Appleアカウント | サインイン入口を確認 | 管理方針どおり表示または非表示 |
| WebView2 | 業務アプリを起動して主要操作 | 指定ランタイムで正常動作 |
| macOS更新 | 全ウィンドウを閉じる | 更新ポリシーどおりに動作 |
Stable展開を止めるべき判断基準
次のいずれかが発生した場合は、対象部署への一括展開を止め、原因を特定します。
- 入力内容、申請内容、編集結果が失われる
- 同じ操作が重複登録される
- 「戻る」操作後にリアルタイム更新が停止する
- WebSocketが二重接続される
- プリンターやローカル機器へ接続できない
- 利用者が理解できない権限確認が業務を止める
- 禁止した個人アカウントでサインインできる
- パスワードや履歴を業務プロファイルへ持ち込める
- 管理ポリシーが
edge://policyで認識されない - WebView2が想定外のランタイムで起動する
- 廃止機能に保存された業務データを回収できていない
一方、制御されたロールアウト対象のUIが表示されないだけでは、合格とも不合格とも判断できません。その端末では未評価として記録し、別端末または正式展開後に再確認します。
Edge 152への対応で最初に実行すること
Edge Beta 152.0.4191.10の検証では、最初に社内Webシステムからunload依存を検索し、バックフォワードキャッシュ復元後のWebSocket接続を確認します。続いて、localhostやプライベートIPへ接続する業務を洗い出し、Local Network Accessの一時オプトアウトを無効にした状態でテストしてください。
その後、Edge Dropと動画翻訳への業務依存を確認し、管理ポリシーを最新テンプレートへ更新します。新しいポリシーは名称だけで判断せず、対応OS、対応バージョン、Stable版の最終リリースノート、edge://policyの実際の値まで確認することが重要です。
すでにStable 152を導入している場合も、問題が報告されていないことを「影響なし」の根拠にしてはいけません。フォーム保存、戻る操作、リアルタイム通信、ローカル機器接続という具体的な業務操作を再現し、段階展開の可否を判断してください。
コメント