Microsoft Edge 152以降では、BackForwardCacheForWebSocketsAllowedポリシーを使い、アクティブなWebSocket接続を持つページのBFCache動作を制御できます。
結論として、通常は「未構成」または「有効」にし、Webアプリ側でBFCacheからの復元後にWebSocketを再接続できるようにするのが基本です。「戻る」操作後に更新が止まる、接続状態が誤表示されるなどの問題が発生する場合だけ、「無効」を一時的な互換性対策として使用します。
注意したいのは、ポリシーを無効にしてもWebSocket接続がページ移動後まで維持されるわけではないことです。アクティブなWebSocketを持つページをBFCacheの対象外にし、戻ったときにページを通常どおり再構築させる設定です。Microsoft Edge Stable 152では、2026年8月27日のリリースでこのポリシーが追加されました。(Microsoft Learn)
BackForwardCacheForWebSocketsAllowedポリシーの設定ポイント
BFCacheはHTTPキャッシュとは異なる
BFCacheは「Back/Forward Cache」の略で、ブラウザーの「戻る」「進む」を高速化する仕組みです。
通常のHTTPキャッシュがHTMLや画像などのレスポンスを保存するのに対し、BFCacheはページのDOM、JavaScriptの状態、スクロール位置などを含むページ全体をメモリ上に保持します。ユーザーがページに戻ると、ネットワークから読み込み直すのではなく、保存されていた状態をほぼそのまま復元できます。(Web.dev)
Microsoft Edge 149では、アクティブなWebSocketを持つページの扱いが変更されました。
以前はWebSocket接続が開いているだけでBFCacheの対象外になっていましたが、変更後はBFCacheへ入る際にWebSocketを切断し、ページ自体をキャッシュできるようになっています。BFCacheへの移行時には対象のWebSocketでcloseイベントが発生し、復元後は切断された状態になります。(Microsoft Learn)
BackForwardCacheForWebSocketsAllowedは、この新しい動作を企業側で制御するためのポリシーです。
有効・無効・未構成の違い
| 設定値 | WebSocketの扱い | BFCacheの扱い | 戻ったときの動作 | 推奨用途 |
|---|---|---|---|---|
| 未構成 | BFCacheへ入る際に切断 | 他の阻害要因がなければ利用可能 | 保存されたページを切断状態で復元 | 通常の推奨設定 |
| 有効 | BFCacheへ入る際に切断 | 他の阻害要因がなければ利用可能 | 保存されたページを切断状態で復元 | 新動作を組織で明示的に適用する場合 |
| 無効 | BFCacheへ入るための切断を行わない | アクティブなWebSocketを持つページは対象外 | 通常の履歴ナビゲーションとしてページを再構築 | 旧Webアプリの一時的な互換性対策 |
未構成と有効は、実質的に同じブラウザー動作です。無効にすると、アクティブなWebSocketを持つページはBFCacheへ保存されません。(Microsoft Learn)
ただし、有効にしても必ずBFCacheが使われるわけではありません。unloadイベント、レスポンスヘッダー、埋め込みフレーム、ほかのWeb APIなど、WebSocket以外の理由でBFCacheの対象外になることがあります。
原則は未構成または有効にする
このポリシーは、BFCacheを利用できない旧動作へ戻すための恒久設定ではありません。Microsoftは一時的なポリシーとして位置付けており、将来削除する予定であると説明しています。(Microsoft Learn)
そのため、基本方針は次のようになります。
| Webアプリの状態 | 選ぶ設定 | 必要な対応 |
|---|---|---|
| 復元後に自動再接続し、最新状態も取得できる | 未構成または有効 | 通常運用を継続 |
| 戻る操作後にリアルタイム更新が止まる | 一時的に無効 | pageshowでの再接続処理を追加 |
| 接続が二重化し、通知やメッセージが重複する | 未構成または有効 | 再接続処理を多重実行しないよう修正 |
| 復元後に古い在庫・注文・認証状態が表示される | 未構成または有効 | 復元時にサーバーの最新状態を再取得 |
| 業務停止につながる不具合があり、すぐに改修できない | 対象を絞って無効 | 改修期限を決めて暫定運用 |
特に重要なのは、問題がない環境で予防的に無効化しないことです。BFCacheを使わない場合、「戻る」「進む」のたびにページの再読み込みやJavaScriptの初期化が必要になり、操作感や通信量に影響する可能性があります。
影響を受けやすいWebアプリ
WebSocketを使っているだけで、必ず問題が発生するわけではありません。WebSocketの切断と再接続を前提に設計されているアプリであれば、大きな影響は出にくいでしょう。
一方、次のようなWebアプリは重点的な確認が必要です。
- チャットや社内メッセージング
- 監視ダッシュボード
- 株価、在庫、受注状況などのリアルタイム画面
- コールセンターやオペレーター向け画面
- 共同編集ツール
- IoT機器や設備を遠隔操作する管理画面
- WebSocket経由で通知を受信する業務システム
戻った後に画面の更新が止まる
初回表示時にだけWebSocketを作成し、切断後の再接続処理を持たないアプリで発生します。
BFCacheから復元されたページでは、DOMやJavaScript変数は残っていても、WebSocketは切断されています。そのため、見た目は正常でも新しい通知やデータが届かない状態になることがあります。
「接続中」のまま実際には切断されている
接続状態を示すUIがcloseイベントに連動していない場合、WebSocketが閉じられても画面上は「接続中」と表示され続けます。
接続アイコンだけで判断せず、実際に新しいデータが届くか、送信処理が成功するかまで検証する必要があります。
WebSocketや購読処理が二重化する
復元時の処理と既存の自動再接続処理が同時に動くと、複数のWebSocketが作成されることがあります。
サーバーへの購読登録も重複すると、同じ通知が2回表示されたり、操作が二重送信されたりする原因になります。再接続関数は、すでに接続中または接続処理中なら新しい接続を作らない設計にする必要があります。
古いデータや認証状態が残る
BFCacheはページ全体の状態を保存します。そのため、別タブでログアウトした、権限が変更された、在庫や注文状態が更新されたといった場合でも、戻った直後には古い画面が表示される可能性があります。
リアルタイム接続を張り直すだけでなく、BFCacheからの復元時に認証状態や重要データを再確認することが重要です。(Web.dev)
このポリシーはURL単位では設定できない
BackForwardCacheForWebSocketsAllowedはBoolean型のポリシーであり、対象URLの一覧を指定する項目はありません。ポリシー単体では「社内システムAだけ無効、その他のサイトは有効」といったURL単位の例外設定はできません。
適用範囲はプロファイル単位ですが、特定サイト単位ではないため、1つの旧システムのために全社へ無効設定を配布すると、同じプロファイルで利用するほかのWebSocketページにも影響します。(Microsoft Learn)
対象を限定したい場合は、次のようにポリシーの配布範囲で調整します。
- 該当システムを利用するユーザーグループだけに配布する
- 検証端末や特定OUだけに適用する
- Intuneで対象のMicrosoft Entraグループを限定する
- 改修完了後にポリシーを未構成へ戻す
グループポリシーで設定する手順
Edge 152以降のADMXテンプレートを用意する
古いMSEdge.admxには、このポリシーが含まれていません。ポリシーがグループポリシーエディターに表示されない場合は、Microsoft Edgeの管理用テンプレートを更新します。
ドメイン環境では、ダウンロードしたテンプレートから次のファイルをセントラルストアへコピーします。
msedge.admx- 日本語表示に必要な
ja-JP\msedge.adml
Microsoftの手順では、msedge.admxをPolicyDefinitionsフォルダーへ、msedge.admlを対応する言語フォルダーへ配置します。(Microsoft Learn)
ポリシーを有効または無効にする
グループポリシー管理エディターを開き、次の場所へ移動します。
コンピューターの構成
> ポリシー
> 管理用テンプレート
> Microsoft Edge
> WebSocket のバック/フォワード キャッシュを許可するユーザー単位で適用するときは、「ユーザーの構成」側にある同じポリシーを使用します。
設定内容は次のとおりです。
- 新しいBFCache動作を明示的に適用する：有効
- 旧Webアプリの互換性を一時的に優先する：無効
- Edgeの既定動作へ戻す：未構成
このポリシーは必須ポリシーとしてのみ利用でき、ユーザーが上書きできる推奨ポリシーには対応していません。そのため、「Microsoft Edge – 既定の設定」ではなく、通常の「Microsoft Edge」配下を確認します。(Microsoft Learn)
クライアントへ反映する
Active Directoryのグループポリシーを手動更新する場合は、対象端末で次を実行します。
gpupdate /forceその後、Microsoft Edgeで次のページを開きます。
edge://policy「ポリシーの再読み込み」を実行し、BackForwardCacheForWebSocketsAllowedが表示されることを確認します。Microsoft Edgeのポリシー確認にはedge://policyを利用でき、必要に応じてEdgeを開き直します。(Microsoft Learn)
レジストリで設定する方法
Windowsでのレジストリ値は次のとおりです。
| 項目 | 値 |
|---|---|
| パス | HKLM\SOFTWARE\Policies\Microsoft\Edge |
| 値の名前 | BackForwardCacheForWebSocketsAllowed |
| 種類 | REG_DWORD |
| 有効 | 1 |
| 無効 | 0 |
ポリシーを有効にするコマンドは次のとおりです。
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v BackForwardCacheForWebSocketsAllowed /t REG_DWORD /d 1 /f互換性対策として無効にする場合は、値を0にします。
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v BackForwardCacheForWebSocketsAllowed /t REG_DWORD /d 0 /f未構成へ戻す場合は、値そのものを削除します。
reg delete "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v BackForwardCacheForWebSocketsAllowed /fレジストリ設定は動作確認には便利ですが、組織で継続運用する場合はグループポリシーやIntuneで管理した方が、適用対象や変更履歴を把握しやすくなります。レジストリパスと値の種類はMicrosoftのポリシードキュメントにも明記されています。(Microsoft Learn)
Intuneの設定カタログから配布する
Microsoft Intuneでは、WindowsおよびmacOS向けのMicrosoft Edgeポリシーを設定カタログから管理できます。
基本的な作成手順は次のとおりです。
- Intune管理センターで「デバイス」を開く
- 「デバイスの管理」から「構成」を開く
- 「作成」から新しいポリシーを作成する
- プラットフォームに「Windows 10以降」または「macOS」を指定する
- プロファイルの種類に「設定カタログ」を指定する
- 「設定の追加」で
BackForwardCacheForWebSocketsAllowedを検索する - 有効または無効を選択する
- 検証用のユーザーまたはデバイスグループへ割り当てる
IntuneのMicrosoft Edge設定はADMXベースで、オンプレミスのグループポリシーと同様のポリシーをクラウドから配布できます。最初から全社グループへ割り当てず、WebSocketを使用する業務アプリの利用者を含む検証グループから展開するのが安全です。(Microsoft Learn)
Webアプリ側で必要な互換性対応
ポリシーを無効にすれば一時的に旧動作へ戻せますが、恒久対応はWebアプリ側で行います。
Microsoftは、BFCacheから復元されたことをpageshowイベントのpersistedプロパティで判定し、値がtrueの場合にWebSocketを再接続する方法を案内しています。(Microsoft Learn)
再接続処理の実装例
let socket = null;
function connectWebSocket() {
if (
socket &&
(socket.readyState === WebSocket.OPEN ||
socket.readyState === WebSocket.CONNECTING)
) {
return;
}
socket = new WebSocket("wss://example.com/realtime");
socket.addEventListener("open", () => {
// 必要なチャンネルやトピックを再購読する
resubscribeChannels();
});
socket.addEventListener("close", () => {
socket = null;
updateConnectionStatus("disconnected");
});
socket.addEventListener("message", (event) => {
applyRealtimeMessage(event.data);
});
}
window.addEventListener("pageshow", async (event) => {
if (!event.persisted) {
return;
}
// BFCacheから復元された場合
connectWebSocket();
// WebSocket切断中に発生した変更を取得する
await refreshLatestState();
});
connectWebSocket();実際のアプリでは、次の点も追加で考慮します。
- 接続中または接続済みの場合は新しいWebSocketを作らない
- 再接続後に購読先を再登録する
- アクセストークンの有効期限を確認する
- 切断中に発生した更新をREST APIなどで補完する
- 自動再接続には一定の待機時間やバックオフを設ける
- ページ非表示中に再接続を繰り返さない
- メッセージの欠落や重複をサーバー側でも防止する
単にWebSocketを再作成するだけでは、切断中に発生した変更を取得できない場合があります。復元時にはサーバーから現在の状態を取得し直し、その後にリアルタイム更新へ戻す設計が適しています。
ポリシーとBFCacheの動作を確認する
Edgeのバージョンを確認する
次のページを開き、Microsoft Edgeが152以降であることを確認します。
edge://settings/help152未満では、BackForwardCacheForWebSocketsAllowedはサポートされません。Windows、macOS、Androidでは152以降が対象で、iOS版Microsoft Edgeには対応していません。(Microsoft Learn)
edge://policyで適用値を確認する
次のページを開きます。
edge://policy確認する項目は次のとおりです。
- ポリシー名が表示されているか
- 値が
trueまたはfalseになっているか - ステータスにエラーや競合が表示されていないか
- コンピューターとユーザーのどちらから適用されているか
ポリシーを未構成にした場合は、一覧から表示が消えることがあります。
DevToolsでBFCacheをテストする
対象ページをMicrosoft Edgeで開き、開発者ツールから次の場所へ移動します。
Application
> Background services
> Back/forward cacheテストを実行すると、ページがBFCacheから復元できたか、何が保存を妨げているかを確認できます。BFCacheのテスト画面では、対象外になった理由や影響を受けたフレームも確認できます。(Chrome for Developers)
実際の業務操作でも確認する
DevToolsのテストだけでなく、実際の利用手順に近い操作を行います。
- WebSocketを使用する業務画面を開く
- 接続が確立したことを確認する
- 同じタブで別ページへ移動する
- ブラウザーの「戻る」を押す
- WebSocketが再接続されるか確認する
- 最新データが表示されるか確認する
- 通知や操作が重複しないか確認する
- 認証エラーや権限エラーが発生しないか確認する
ページの再読み込みだけではBFCacheの検証になりません。必ずブラウザーの「戻る」「進む」を使って確認します。
コンソールへ次のコードを入力すると、BFCacheから復元されたかを簡単に確認できます。
window.addEventListener("pageshow", (event) => {
console.log("pageshow: persisted =", event.persisted);
});
window.addEventListener("pagehide", (event) => {
console.log("pagehide: persisted =", event.persisted);
});戻ったときにpageshow: persisted = trueと表示されれば、BFCacheから復元されています。
よくある設定ミスと対処法
ポリシーがグループポリシーに表示されない
主な原因は、msedge.admxまたはmsedge.admlが古いことです。
Edge本体だけを152以降へ更新しても、管理用テンプレートが古ければ新しいポリシーは表示されません。セントラルストアと管理端末の両方を確認します。
edge://policyに表示されない
次の項目を確認します。
- Edgeが152以降か
- GPOやIntuneの割り当て対象に端末またはユーザーが含まれているか
- レジストリパスや値の名前に誤りがないか
- コンピューターポリシーとユーザーポリシーが競合していないか
gpupdate /forceを実行したか- Edgeを開き直したか
このポリシーは、個人用Microsoftアカウントでサインインしているプロファイルには適用されません。業務用プロファイルと個人用プロファイルを併用している場合は、どちらのプロファイルで対象サイトを開いているかも確認します。(Microsoft Learn)
有効にしてもBFCacheへ保存されない
BackForwardCacheForWebSocketsAllowedが有効でも、WebSocket以外の理由でBFCacheの対象外になることがあります。
代表例は次のとおりです。
unloadイベントを登録しているCache-Control: no-storeの影響を受けている- iframe内の処理がBFCacheを妨げている
- 対応していないAPIや処理が動作中である
- ブラウザーのメモリ状況などによりキャッシュが破棄された
原因はDevToolsのBack/forward cache画面で確認します。(Chrome for Developers)
無効にすればWebSocketが接続されたままになると思っている
これは誤解です。
無効設定は、WebSocketをページ移動後も維持する機能ではありません。アクティブなWebSocketを持つページをBFCacheへ入れず、戻ったときにページを通常の方法で読み込み直させます。
結果として初期化処理が再実行されるため、旧アプリでは問題を回避できる可能性がありますが、ページ移動をまたいで同じWebSocket接続が存続するわけではありません。
1つの旧システムのために全社で無効化している
このポリシーはURL単位で設定できないため、全社で無効にすると正常にBFCacheへ対応しているほかのWebSocketページまで対象外になります。
まずは問題が発生するユーザーや端末だけに適用し、アプリ改修後に未構成へ戻します。
BackForwardCacheEnabledと混同している
BackForwardCacheEnabledという別のポリシーも存在しますが、WindowsおよびmacOSではサポートされておらず、Android 138以降向けのポリシーです。
Windows版Microsoft EdgeでWebSocketページの挙動を制御する場合は、BackForwardCacheForWebSocketsAllowedを使用します。(Microsoft Learn)
段階的に導入してアプリ改修へつなげる
BackForwardCacheForWebSocketsAllowedは、WebSocketを使用する旧Webアプリを新しいBFCache動作へ移行させるための互換性ポリシーです。
まずEdge 152以降と最新の管理用テンプレートを用意し、原則として未構成または有効の状態で業務アプリを検証します。「戻る」操作後にリアルタイム更新が止まるなどの問題が確認された場合だけ、対象グループへ無効設定を一時配布します。
同時に、アプリ側でpageshowとevent.persistedを使った再接続、購読の再登録、最新データの再取得を実装します。修正後は無効設定を解除し、将来のポリシー削除に備えることが重要です。
コメント