Edge 155で閉じると保存されない？フォームのunload依存と確認手順

入力中は問題なく動くのに、ページを閉じたあとで下書きや終了ログが残っていない。予約・見積・問い合わせフォームを運営しているなら、「送信ボタンは動くから大丈夫」とは別に確認したい点があります。

Edge 155で点検したいのは、ページを離れるときのunloadだけに保存を任せていないか、です。Microsoftは2026年10月8日公開のStable版155で、サイトが明示許可しない限りunload処理が動かない既定変更の展開を、ページロードの100%へ進めると案内しています。全フォームの送信が止まるという話ではありません。

この記事では、対象になり得る処理を見つけ、操作を分けて試し、画面上の「送った」とサーバー上の「保存できた」を区別する順番を整理します。自分のサイトでの再現結果を確認してから、改修や保守依頼を判断できます。実サイトの障害を再現した記事ではなく、公式仕様に基づく点検ガイドです。

公式情報の確認日：2026年10月14日。EdgeとChromeの展開日程は別々に扱います。

Edge 155で止まるのは「閉じる瞬間に頼る処理」

たとえば、見積フォームに入力している間はブラウザーの中だけにデータがあり、別ページへ移る瞬間にまとめて送る設計を考えてみてください。入力欄もボタンも表示されます。しかし、最後の保存をunloadにだけ置いていれば、その最後の処理が動かないことで、入力した内容がサーバーへ届かない可能性があります。これは仕組みを説明する仮定で、特定のサイトで起きた事故の報告ではありません。

unloadは、ページの終了時に保存や後片付け、セッション終了の通知を行うために使われてきたイベントです。Edge 155の変更は、このイベントのハンドラー、つまり登録した処理を既定で動かさない方向へ進めるものです。MicrosoftのStableリリースノートとサイト互換性に影響する変更の資料で対象を確認できます。

展開割合の100%は「ページロード」の割合です。「100%のフォームが壊れる」「全利用者が入力を失う」という意味に読み替えてはいけません。通常の送信、入力時の保存、一定間隔の保存まで一律に無効になる変更でもありません。自分のページがどの処理に依存しているかが、最初の分かれ目です。

確認するのはフォームの名前ではなく、保存を始めるタイミング

実装の例	今回の確認ポイント
unloadだけで下書き・終了ログを送る	既定変更の直接の点検対象。処理が動かない場合に残せる内容を確認する
送信ボタンや入力中に保存する	この変更だけで一律に停止とはいえない。最後の差分だけunload任せになっていないかを見る

フォーム全体が動いているように見えても、最後のメモ一行や終了ログだけ取りこぼすことは、実装上あり得ます。逆に、未保存が起きたという事実だけでunloadが原因だとは決められません。送信先のエラー、認証、入力検証など、別の原因も切り分けます。

ブラウザーとOSは、ページの処理を続けるより、停止や終了を優先することがあります。閉じるときに処理を実行できるという前提自体に限界があるのです。では、自分のページのどこにその前提が残っているのでしょうか。

自分のフォームにunload依存があるかを見つける

最初に見るのは、ページの見た目ではなく、保存・計測・後処理をどこから呼んでいるかです。自作のコードだけでなく、タグ管理、解析ツール、埋め込みフォーム、古いライブラリも候補になります。コードを触れない担当者は、対象URLと「残らない内容」を制作会社や保守担当へ渡し、確認を依頼できます。

コード検索は「見つかったあと」が大切

unload、onunloadを手がかりに、イベント登録とその先で呼ばれる処理を探します。見つけた箇所が、下書き保存なのか、分析ログなのか、単なる後片付けなのかを分けてください。文字列がコメントにあるだけの場合もありますし、圧縮された外部スクリプトでは分かりにくい場合もあります。

同じsendBeaconを使っていても、呼び出すタイミングがunloadだけなら、API名を変えたことにはなっても離脱トリガーへの依存は残ります。確認するのは「どのAPIを使うか」と「何をきっかけに呼ぶか」の両方です。

公式のDevTools手順は、依存を探す補助にする

Chrome公式のunload検出ガイドでは、DevToolsのApplication → Background services → Back/forward cacheでテストする手順と、unloadハンドラーがあることを示す画面例を確認できます。この記事の画像は仕組みを伝える図解で、実在のDevTools画面の代用品ではありません。メニュー位置や表示を確認するときは、リンク先の公式画面と説明を使ってください。

bfcacheは、戻る・進むの際にページを素早く復元する仕組みです。そのテストでunloadの利用が指摘されれば、コード棚卸しの手がかりになります。ただし、bfcacheの検査は、予約情報が保存されたかを調べる検査ではありません。指摘がない場合も、フォームの保存を保証する証拠にはできません。利用ブラウザー・バージョンによる表示差も確認します。

技術担当は対応環境でPerformanceNavigationTiming.notRestoredReasonsも補助に使えます。表示された阻害理由は、復元できなかった理由として読み、保存失敗の原因と同一視しません。実装依存を見つける道具と、実データの保存を確かめる道具を使い分けます。

検索結果を並べるだけでは、すぐ改修すべき場所が見えません。「処理の役割」「呼び出すタイミング」「送信先」「失敗すると失う内容」を一組でメモにすると、次に試す操作を選べます。

ここまでで疑わしい処理は絞れました。次は、それがタブを閉じたときだけの問題か、別の操作でも起きるのかを見ます。

「閉じる」以外も試すと、消えるタイミングが分かる

「ページを閉じたら消えた」という一行の報告には、別URLへの移動、戻る、再読込、タブ切替、ブラウザー終了などが混ざりがちです。操作を分けると、保存を始めるタイミングと、残っている内容を比較できます。

点検はテスト環境や、実際の予約・見積依頼にならないテスト用データで行います。顧客の個人情報を使って試したり、本番へ重複予約を送ったりしないでください。テストしたブラウザーとバージョン、ページ、操作、入力した差分を記録しておくと、保守担当が条件を追えます。

同じ下書きで、操作だけを変える

たとえば、テスト用のメモを入力した状態で、最初は通常の保存を押す。次は別URLへ移る。その次は再読込、タブ切替、最小化、タブ終了を別々に試す、という具合です。モバイルは、別アプリへ切り替えたあとでブラウザーを終了する操作も別ケースにします。一度に多くの操作を重ねると、どの段階で差が出たか追いにくくなります。

各操作のあと、同じ下書きを開き直すか、権限のあるサーバー側の読取で、最新の内容が残ったかを確認します。「入力欄が復元された」だけで合格にしないことが大切です。ブラウザー内の復元内容と、サーバーへ保存した内容は区別します。

戻る・進むでbfcacheからページが復元される場合には、古い表示が再び現れたり、復元後の処理で同じ送信を重ねたりしないかも点検します。web.devのbfcache解説は、復元の仕組みとpageshowのpersistedを確認する考え方の参考になります。

「最後の一行」が残ったかで判定する

試験の前に保存済みだった内容ではなく、操作の直前に追加した差分を追います。前の保存が成功していれば、途中まで残っていることで安心してしまうためです。テスト用の識別子と更新版を記録し、ブラウザーの送信、サーバーの処理、開き直した結果をつなげます。

タブ切替で残り、タブ終了で残らない、という結果が出ても、それだけではイベントが原因だと確定できません。イベントの発火、送信要求、サーバーのエラーを順に見ます。反対に、どの操作でも失敗するなら、unload以外の共通処理にも調査を広げます。

この手順は再現条件を探すためのものです。本記事で各操作の成功率や特定環境の動作を測定したわけではありません。点検結果を得ると、次の課題が見えてきます。閉じる瞬間へ集中していた仕事を、いつ、どこへ移すかです。

保存・離脱・警告を別の役割に戻す

unloadを見つけたからといって、名前をbeforeunloadへ置き換えるだけでは保存の設計は完成しません。入力内容を残す処理、ページから離れたときの後片付け、未保存を知らせる警告は、目的が違います。

保存は、入力・変更時や適切な間隔のオートセーブで早めに始め、ページが見えなくなるときに残る差分を処理する形を検討します。長い入力を最後の一回だけで守る設計を避ける、というリモノアの判断です。入力欄やサーバー負荷に合わせた間隔・認証・競合処理は、サイトごとに設計してください。

代替イベントは同じ仕事をするものではない

候補	向いている役割と限界
visibilitychangeでhiddenを確認	見えなくなる時点の状態保存・送信のきっかけ。タブ切替でも起きるため、閉鎖や受付確定と同一視しない
pagehide	ページ離脱の補完や後片付け。bfcacheと互換だが、モバイル等の終了で発火を保証できない
beforeunload	未保存変更の警告用。ユーザー操作等の表示条件があり、保存完了処理の代用品にはならない

visibilitychangeの資料では、hiddenへの変化をページから観測できる最後の信頼できる時点として説明しています。ここを使っても、回線不通やサーバー障害まで消えるわけではありません。「トリガーを早める」と「保存を保証する」は別の問題です。

pagehideの資料では、bfcacheとの互換性と、モバイルのアプリ切替後の終了などで発火しない場合の両方を確認できます。単にイベントを追加して数を増やすより、それぞれがどの操作を補うかを決めます。

beforeunloadの資料によれば、警告にはユーザー操作などの条件があり、表示文言もブラウザーが決めます。必要な未保存変更がある間だけ登録し、保存できたら不要な警告を出さない運用を考えます。「この警告が出ればデータは守られる」とは案内できません。

複数のきっかけから保存を呼ぶなら、同じ下書きの同じ更新を何度送っても重複作成しない処理、古い更新で新しい内容を戻さない処理も必要になります。テストで使った下書きID・更新版を、保存結果の確認にも役立ててください。

予約の確定と下書き保存は、さらに区別します。利用者の送信操作を待って確定するフォームなら、タブがhiddenになったという理由で予約を確定させてはいけません。裏へ回っただけで予約が入る設計では、別の事故を作ってしまいます。

イベントの役割を分けても、「送信関数が成功を返した」という判定が残ることがあります。その成功は、どこまで進んだという意味でしょうか。

sendBeaconのtrueで、予約受付は確定しない

sendBeaconは、ページの移動を邪魔せず、小さなデータを非同期のPOSTで送るためのAPIです。分析・診断ログには有力な候補ですが、返り値を業務データの保存完了通知に使うと、判定する場所を取り違えます。

MDNのsendBeacon資料では、trueはブラウザーが送信用キューへデータを積めたこと、falseはそれができなかったことを示します。trueは「サーバーで予約情報を保存できた」という意味ではありません。

荷物を集荷待ちの置き場へ預けたことと、宛先で受け取って台帳へ記録したことが違うのと同じです。W3CのBeacon仕様ドラフトでも、非同期転送の成功結果を知らせるAPIではなく、レスポンスのコールバックがないことを説明しています。ブラウザー内の受付、ネットワーク送信、サーバーの業務処理を分けて見ます。

容量だけでなく、返ってこない結果を考える

MDNはキューへ積むデータの合計を64KiB、65,536バイトまでと説明しています。大きな添付ファイルや長い入力内容を、閉じる直前の一括送信へ押し込む設計には向きません。これは単純な「何文字まで」の上限ではなく、送るデータのバイト数の話です。

POST以外のメソッド、送信設定の変更、サーバーレスポンスが必要なら、同資料が案内するfetchのkeepaliveも候補です。ただし、別APIを使っただけで、閉じる直前にしか保存しない設計の不確実性がなくなるわけではありません。重要な入力はページを使っている間に保存し、応答や後からの読取りで結果を確かめる設計を先に検討します。

成功条件を「保存した内容が読める」に置く

技術担当は、Networkで要求が出たか、サーバーが受信・処理したか、権限のある読取で最新の内容が返るかを確認します。HTTPの成功コードも、そのエンドポイントが何を完了したと定義しているかで意味が変わります。受付だけの応答と、保存完了の応答を混同しないでください。

下書きなら、再表示した内容が最後の差分と一致すること。予約の確定なら、利用者の確定操作と受付結果が結びつき、管理側でも対象の予約を確認できること。終了ログなら、同じログを重複登録せず、必要なイベントが集計先に存在すること。何を残したいかによって、点検の終点を選びます。

この整理ができると、「sendBeaconを使っています」という説明だけでは十分でない理由が分かります。最後に、すぐ移行できないときの一時対応と、保守依頼へ渡す情報をまとめます。

一時許可は期限付き。直せないときは確認結果を渡す

修正するまで旧来のunload処理を動かしたい場合、Permissions-Policyによる明示許可があります。MDNのunload directive資料は、トップレベルのページを許可するHTTPレスポンスヘッダーとして、次の記述を示しています。

Permissions-Policy: unload=self

これは、サーバーから返すヘッダーの例です。本文のHTMLへ文字列を貼るだけで設定できるものではありません。自分が管理するページと、対象ブラウザーの対応、既存のヘッダー設定を確認してから扱います。

別オリジンのiframeに埋め込まれたフォームでは、親ページの許可リスト、iframeのallow属性、子のページ自身が返す許可ヘッダーという条件も関係します。外部フォームの管理権限がない場合、親側の設定だけで完了したとは判断できません。資料のiframe例と実際の提供元の条件を確認し、担当者へ相談してください。

このdirectiveは非標準で、対応にも限りがあります。再許可は従来の動作を一時的に使うための移行猶予であり、OSによる停止やモバイルの終了でもunloadが動く保証を追加するものではありません。「直ったから今後も放置する」という判断は避け、対象、撤去条件、移行担当を決めます。

保守依頼は、症状より再現条件を渡す

コード検索で依存が見つかった場合も、自社で触れないCMSや外部フォームの場合も、ブラウザー名だけを伝えるより、保存したい内容と確認結果を一緒に渡す方が調査を進めやすくなります。下の手順は、依頼前に揃える情報です。自分で改修できる場合にも、同じ記録を修正前後の比較に使えます。

実装を変えられない、無償の点検と修正をしても保存結果が安定しない、提供元の対応予定が確認できない。こうした条件に達したときに、保守の依頼範囲やフォーム基盤の変更を比べます。先に回線の追加契約やブラウザーの巻き戻しで解決すると決めつける必要はありません。

最初に確かめるのはunload依存、最後に確かめるのは実際に保存された内容です。自分のフォームが対象でなければ、今回の変更を理由に乗り換えなくてもかまいません。対象なら、閉じる瞬間の一回へ賭ける形から、入力中に残して結果を確認する形へ、段階的に移していきます。

公式資料が示すのは仕様と推奨する移行の考え方です。Edge 155固有の障害件数、影響サイトの比率、本記事の手順での成功率は確認していません。自分の環境で残った差分を確かめ、その結果を次の判断に使ってください。