サイト更新後も開いたタブが古いまま？Service Workerの待機と切替の確かめ方

Service Workerは、ページとは別に動いて通信の応答を扱う仕組みです。キャッシュという保存済みのコピーを返すこともあります。更新時に交代を待つのは、利用中の旧画面と新しい通信処理が不用意に混ざるのを避けるためです。ただし、この仕組みを使わないサイトもあるので、古い表示だけで原因を決めません。

更新の途中には、旧Worker Aが使われたまま新Worker Bが準備される時間があります。教材では画面の『表示版A』、サーバーの『配信版B』、今のタブを担当する『controller A』を別々に見ます。Bを配信できたことだけで、先に開いたタブがBを利用したとは言えません。

更新担当は、古い画面のURL、確認日時、ブラウザ、操作前後の版を記録します。Service Workerの登録がない、違うURLを見ている、元の配信内容もAのままなら、配信先や通常のHTTPキャッシュなど別の原因を調べます。既存の入力を消してから探す必要はありません。

この章の根拠：出典3出典4

waitingは、導入の準備が済んで交代を待つWorkerです。activeは、その登録で活動中、または活動開始の処理中のWorkerです。controllerは、今のページを制御するWorkerです。『制御』は、このページの通信を扱う役割を指します。登録のactiveがあっても、初回に開いたページのcontrollerは空になる場合があります。

開発担当は、登録のwaiting・activeと、今のページを担当するcontrollerを別々に読みます。Service WorkerのURLが同じでも、動いている版まで同じとは限りません。自社のリリース識別の方法を確認し、Workerから版名の返答を得られない場合は、期待値で埋めず未確認として残します。

開発担当は、今のページに合う登録と通信担当を読む

会社が認めたHTTPSの確認環境で、開発担当が対象ページの開発者ツールにあるConsole（値やエラーを表示する確認欄）を開きます。次のコードは登録と状態を読むだけで、登録の追加・更新・削除やキャッシュ消去は行いません。対象ページ以外の画面で実行すると、その画面に合う登録を調べることになるため、先にURLを合わせてください。

画面が狭い場合は、コード欄を横に動かして行の末尾まで読めます。

if (!("serviceWorker" in navigator)) {
  console.log("このページでは読み取れません");
} else {
  navigator.serviceWorker.getRegistration()
    .then((registration) => {
      console.table({
        "登録範囲": registration?.scope ?? "登録なし",
        "交代待ち": registration?.waiting?.state ?? "なし",
        "活動中": registration?.active?.state ?? "なし",
        "このページの担当":
          navigator.serviceWorker.controller?.state ?? "なし"
      });
    })
    .catch((error) => console.error("読取りに失敗", error));
}

getRegistration()は、今のページのURLに担当範囲が合う登録を読みます。仕様はMDNのgetRegistration()の説明で確認できます。「登録なし」なら、このURLに合う登録が取得されていません。「読取りに失敗」というエラーは「なし」と区別します。

このコードで分かるのは登録範囲とinstalled・activatedなどの状態で、A版・B版の識別ではありません。版名は自社のリリース識別方法で別に照合します。例えば表の交代待ちがinstalled、活動中とこのページの担当がactivatedでも、その文字だけからB・A・Aとは決められません。Workerから版名を返す仕組みがない場合は、URLが同じという理由で版を埋めず、更新担当と識別方法をそろえます。

waiting B、active A、controller Aなら、Bは準備済みで、そのタブはまだAの担当下です。一方、waitingが空なら、先にactiveとcontrollerの版も読みます。両方がBなら交代済みの候補であり、次は画面版と保存した入力を照合します。Aのままなら、新しい内容の配信、登録先、導入エラーを調べます。waitingが空という一項目だけでは、成功にも失敗にも決めません。強制再読み込みではcontrollerが空になる場合があるため、通常の再読み込みと区別してください。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典2出典3出典11

開発担当は、旧版を利用する画面が残っているかを、会社が認めた確認環境で調べます。旧版を表示する先に開いたタブと、後から開いたタブを区別し、それぞれの画面版と通信担当を確認します。業務中の画面では、入力を保全できるまで、原因確認のためにタブを閉じる操作を先に求めません。

同じService WorkerのURLに新しい内容を配信しても、旧版が担当するタブへ直ちに適用されるとは限りません。開発担当が更新確認を要求した後は、waiting・active・controllerと各タブの画面版を読み直します。update()の要求が終わったことと、待機中の新版がそのタブを担当したことは別に確認します。

教材の期待はwaiting B、active A、controller A、画面Aです。編集側は2026年10月10日、専用127.0.0.1の教材をCodexのブラウザで操作し、この交代待ちを実際に読みました。次の第5章で操作ごとの結果を示します。初回の制御確認やBの導入が違えば、その段階の実値とエラーを保存してください。今回の記録は自社サイトの結果を代わりにするものではありません。

この章の根拠：出典4出典5出典9出典12

未送信の受注メモがあるタブは、保存内容を照合する前に閉じません。会社が決めた保存先で内容を実際に読み、元の画面の文章や入力項目と比べます。図4の「部品の見積メモ」も、保存を始めたという操作と、同じ内容が残ったという結果を分ける例です。一致しない、保存先を開けない、入力が欠けている場合は、タブを残したまま保存方法を確認します。保存できたことは、取引先へ送信・受領されたこととは別です。

作業を残した後、先に開いたタブだけでなく同じ登録の旧Workerを使う後から開いたタブなども終了するか、担当範囲の外へ移動します。scopeはWorkerがページを担当するURL範囲です。通常の再読み込みでは旧ページと新ページが重なるため、待機が解消しないことがあります。他の開いた画面や処理中のイベントも関係するので、『2タブを閉じた直後に必ずB』とは約束しません。

対象画面を開き直し、画面版・active・controllerの版と、保存したメモを照合します。教材で/lesson/を開き直したときの期待は画面B・active B・controller Bですが、自社では実際の対象URLとリリース識別を使います。画面だけBで担当がA、または担当だけBで画面がAなら、切替完了とせず新旧の組合せを開発担当が調べます。版がそろっても入力が欠けていれば業務再開を保留します。未送信のメモを取引先へ再送してよいかは、元の送信・受領状態を確かめてから業務責任者が判断します。

この章の根拠：出典4出典6出典13

waitingが空でもactiveとcontrollerがBなら、待機を終えた可能性があります。画面版と保存内容を先に照合し、waitingを作るためだけに更新を繰り返しません。activeがAのままなら、Bのスクリプトの実内容、登録のscopeとURL、導入時の通信・構文エラーを調べます。導入が失敗して旧Workerが残っている場合は、そのエラーを直してから同じ条件で更新確認をやり直します。教材のserver-phase Bという配信側の値だけで、SW Bの導入成功とは判定しません。

waiting Bが残るなら、Aを使う別タブやアプリのウィンドウ、処理中のイベントを開発担当が調べます。controller Bなのに画面Aの場合は、交代を急ぐ設定による混在や、別の応答経路も確認対象です。skipWaitingは待機を省く要求ですが、読み込まれた古いHTMLまで自動で新しい文書へ書き換える命令ではありません。採用するなら、旧画面から新しいWorkerへの通信や未保存入力を別途試験します。

キャッシュをすべて消す、登録を外す、配信版をAへ戻す、といった処置をまとめて実行すると、原因や影響が追いにくくなります。まず観察JSON、エラー、リリース資材を保存し、開発担当が対象の登録・資材を限定します。サーバーをAへ戻しただけで、既に動くBのタブが即座にAへ戻るとも限りません。戻す場合も同じ版・担当・入力の照合を行います。

比較表は横に動かして全ての列を確認できます。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典5出典6出典7出典8

新版の配信だけでは、朝から開いていた画面まで新版になるとは限りません。まず今のページを担当するWorkerと登録の状態を分けて読みます。waitingが空でも、activeとcontrollerが新版なら交代済みの候補です。登録がなければ、Service Workerの切替操作へ進まず配信先など別の原因を調べます。

営業担当はメモを保存先の実内容と照合し、未送信という業務状態を残します。その後、旧Workerを使う画面を整理し、新しいタブの版・担当を確認します。切替を急ぐ機能を導入する場合にも、旧画面と新しいWorkerの組合せ、入力保護、戻す方法を試験してから業務責任者が採用範囲を決めます。

今日まず行うのは、古い画面1件の未送信入力を残し、そのページの担当と配信版を照合することです。保存内容が一致するまではタブを閉じず、切替後は画面・通信担当・入力をそろえて確認します。どれかが一致しなければ、その状態に対応する第5章の対処へ戻ります。読取りエラーを「なし」にしたり、教材のBを自社の成功へ置き換えたりしません。

この章の根拠：出典1出典2出典3出典4