サービスワーカーを使うと、一度端末へ保存したページや画像、PDFを、電波が弱い場所でも表示できます。ただし、ホームページ全体が自動でオフライン対応になるわけではありません。最初の接続、保存する範囲、更新方法、機密情報を保存しない設計まで決めて、初めて実務で使える仕組みになります。
向いているのは、工場・倉庫・屋外などで繰り返し確認する手順書、商品資料、会場案内です。一方、在庫、価格、予約枠、決済、ログイン後の情報は、古い内容を見せると困るため、同じ方法で保存してはいけません。この記事では、中小企業が制作会社と相談するときに決める範囲と、公開前の確認方法を整理します。
結論：オフラインで見せる範囲を先に分ける
最初に「保存してよい情報」「なるべく新しく見せたい情報」「必ず通信が必要な操作」の三つへ分けます。全ページを同じ設定にすると、古い資料を見続けたり、共用端末へ機密情報を残したりする原因になります。
| 分け方 | 例 | 基本方針 |
|---|---|---|
| 保存してオフライン表示 | 操作手順、会場地図、会社・商品案内、更新頻度の低い画像 | 必要なファイルを事前に保存し、更新版の確認方法も用意する |
| 新しい情報を優先 | お知らせ、営業日、一般公開の更新資料 | まず通信を試し、失敗したときだけ保存済みの内容を見せる |
| 通信を必須にする | 決済、予約確定、在庫、問い合わせ送信、ログイン後の個人情報 | 保存対象から外し、接続が必要だと画面で伝える |
この機能を制作の途中で追加すると、ページ構成や更新担当まで見直す場合があります。相談から公開までの決め方は、ホームページ制作の流れと発注側の確認事項も参照してください。
サービスワーカーキャッシュの仕組み
サービスワーカーは、ブラウザと通信先の間でリクエストを扱うJavaScriptです。指定した範囲のページやファイルについて、ネットワークから取得するか、ブラウザ内のCache Storageから返すかを決められます。通常のブラウザキャッシュとは別の仕組みで、保存や削除、更新のルールを制作側が実装します。
- 登録：ページからサービスワーカーのファイルを登録する。
- インストール：オフライン表示に必要な最小限のファイルを保存する。
- 有効化：新しい版を使う準備をし、不要になった古い保存領域を整理する。
- 表示：ページや画像の要求ごとに、通信と保存済みデータのどちらを使うか判断する。
サービスワーカーは安全な通信が必要なため、公開環境ではHTTPSが前提です。また、登録したファイルの置き場所と設定によって、制御できるURLの範囲が変わります。
初回はインターネット接続が必要
端末に何も保存されていない初回から、完全な圏外でページを開くことはできません。接続できる場所でホームページを開き、サービスワーカーの登録と必要ファイルの保存を終える必要があります。保存中に画面を閉じたり、容量不足で失敗したりする場合もあるため、「オフラインで利用できます」と表示する前に完了を確認します。
| 保存方法 | オフラインで見られる範囲 | 注意点 |
|---|---|---|
| 事前保存 | 制作側が指定したページ・画像・資料 | 初回登録時の通信量と、更新時の差し替えを管理する |
| 閲覧時に保存 | 利用者がオンライン中に開いたページ | 一度も開いていないページは圏外では表示できない |
| 案内ページだけ保存 | 接続できないことと次の行動を示す共通ページ | 資料そのものは見られないが、真っ白なエラーを避けられる |
向いている場面と向いていない場面
「電波が弱い」という理由だけで導入を決めず、同じ情報を繰り返し見るか、内容が古くなっても一時的に参照できる方がよいかで判断します。
| 場面 | 向き・不向き | 確認すること |
|---|---|---|
| 工場・倉庫・屋外の公開手順書 | 向いている | 改訂時の通知、版番号、古い資料の削除 |
| 展示会や地域イベントの会場案内 | 向いている | 来場前の保存案内、会期後の終了表示 |
| 商品カタログや公開PDF | 条件付きで向いている | ファイル容量、価格や仕様の更新頻度 |
| ネットショップの在庫・決済 | 基本的に不向き | 古い情報を見せず、通信が必要な操作を明示する |
| 顧客別資料・個人情報 | 安易に保存しない | 端末共有、認証、ログアウト後の削除、漏えい時の影響 |
PDFを使う場合は、保存機能だけでなく容量とスマートフォンでの読みやすさも確認します。詳しくは、PDFを軽くして読みやすくする確認手順をご覧ください。
ページの種類ごとにキャッシュ戦略を変える
キャッシュ戦略とは、通信と保存済みデータを使う順番です。ホームページ全体へ一つの戦略を当てるのではなく、情報の変わりやすさと、古い内容を見せた場合の影響で分けます。
| 戦略 | 動き | 向く対象 |
|---|---|---|
| Cache First | 保存済みを先に表示し、なければ通信する | 内容の版がURLで分かれる画像、CSS、公開資料 |
| Network First | 新しい内容を取りに行き、失敗時だけ保存済みを表示する | 更新される一般公開ページやお知らせ |
| Stale While Revalidate | 保存済みをすぐ表示し、裏で次回用の更新を取得する | 少し古くても支障が小さい画像や一覧 |
| Network Only | 保存済みを使わず通信だけで処理する | 決済、送信、認証、最新状態が必須の操作 |
WordPressを使っていても実装できますが、管理画面、ログイン中の表示、プレビュー、個人別ページまで保存しないよう除外が必要です。更新する人と保守する人を先に決める考え方は、中小企業向けCMSの選び方にもつながります。
更新事故を防ぐために版と通知を用意する
サービスワーカーを更新しても、すでに開いている画面では旧版が動き続け、新しい版が待機することがあります。強制的に切り替える設定もできますが、入力途中の画面まで急に更新すると困ります。大切な資料は、版番号、更新日、更新通知、再読み込み後の確認を一組で設計します。
- 保存領域の名前に版を付け、新しい版が有効になった後で不要な旧版を削除する
- 資料名だけでなく、画面上にも更新日や版番号を示す
- 新しい版が使えるときは利用者へ伝え、安全な時点で再読み込みしてもらう
- 緊急更新では、旧版を見てよい時間と、必ず通信させる条件を決める
導入は小さな対象から始める
- 利用場面を決める：誰が、どの場所と端末で、何を見るかを記録する。
- 対象を絞る：最初は重要な説明ページと軽い資料など、失敗時の影響を管理できる範囲にする。
- 通信必須を分ける：送信・決済・認証・最新情報は保存対象から外す。
- 失敗時の画面を作る：未保存、圏外、更新失敗、容量不足の次の行動を示す。
- 更新方法を決める：版番号、通知、切り替え、旧版削除、担当者を決める。
- 実機で試す：実際の端末と電波状況で、初回から更新後まで確認する。
- 公開後に見直す：表示失敗と更新失敗を記録し、不要な保存対象を減らす。
機密情報と共用端末は保存しない前提で考える
Cache Storageは端末側に残るため、ログインできたことだけを理由に顧客情報や社外秘資料を保存してはいけません。サービスワーカー側で保存対象から除外し、サーバー側のキャッシュ制御も整えます。共用端末では、利用終了、ログアウト、担当変更、紛失時にどのデータを消すかまで決めます。
| 確認項目 | 実務で決めること |
|---|---|
| HTTPS | 全ページを安全な通信にし、証明書切れも監視する |
| 制御範囲 | 必要なURLの範囲だけをサービスワーカーの対象にする |
| 保存除外 | 認証後、個人別、送信結果、決済、管理画面を明示的に除外する |
| 端末運用 | 共用・私物端末の可否、紛失時、利用終了時の削除方法を決める |
| 停止手順 | 不具合時に登録解除や修正版を配信できる責任者と手順を残す |
ホームページ全体の安全対策は、中小企業のホームページで確認するセキュリティ項目、公開後の更新責任はBämの保守・管理で確認できます。
端末容量とブラウザによる削除も想定する
ブラウザ内の保存領域は永久ではありません。端末の空き容量やブラウザの判断、利用者の操作で削除されることがあります。そのため「一度保存したから必ず残る」とは案内せず、保存完了の表示、必要容量の確認、再取得の手順を用意します。大きな動画や高解像度PDFを無制限に保存せず、件数と保存期間を決めて古いものを整理します。
公開前テストで確認すること
| 試す状態 | 確認内容 | 合格の考え方 |
|---|---|---|
| 初回・オンライン | 登録、必要ファイルの保存、完了表示 | 途中失敗を成功として案内しない |
| 保存後・完全オフライン | 対象ページ、画像、PDF、戻る操作 | 必要な資料が欠けず、未保存URLは適切に案内する |
| 再接続 | 新しい情報の取得と失敗した操作の扱い | 二重送信や古い表示の継続を起こさない |
| 版の更新 | 旧画面を開いたまま更新し、通知後に切り替える | どの版を見ているか利用者が判断できる |
| 容量不足・削除後 | 保存失敗と再取得 | 原因と次の操作が画面に出る |
| 実際の端末 | 会社支給・共用・私物など許可する端末 | 対応範囲と制限を運用文書に残す |
表示幅や操作の確認はスマートフォン表示の確認手順、公開後の異常検知はホームページ監視で決める正常条件と初動も参考になります。
費用は保存する範囲と更新責任で変わる
必要な作業は、対象ページの整理、サービスワーカー実装、失敗時の画面、更新通知、実機テスト、公開後の保守です。公開資料を数ページだけ見せる場合と、認証や入力データを扱う業務用の仕組みでは、確認範囲が大きく違います。ページ数だけで概算せず、古い情報を見せた場合の影響と、誰が更新するかを見積もり条件に含めます。
Bämでは、通常の会社ホームページにこの機能が本当に必要かも含めて整理します。制作内容はコーポレートサイト制作の内容から確認できます。
よくある質問
一度も開いていないページも圏外で見られますか？
制作側が事前保存の対象へ入れ、端末で保存が完了していれば表示できます。閲覧時に保存する方式では、一度も開いていないページは表示できません。
WordPressでも使えますか？
使えます。ただし、管理画面やログイン中の表示、プレビュー、問い合わせ・決済などを保存対象から外し、更新後のキャッシュ削除まで確認する必要があります。
サービスワーカーを入れればPWAになりますか？
サービスワーカーはPWAで使われる要素の一つですが、それだけでインストール可能なホームページになるとは限りません。今回必要なのがオフライン表示だけなら、不要な機能まで増やさず目的に合う範囲で実装します。
更新した資料はすぐ全端末へ反映されますか？
端末の接続状態や、旧画面が開いているかによって切り替わる時点が異なります。重要資料は自動更新だけに任せず、版番号と更新通知を表示し、利用者が最新版を確認できるようにします。
まとめ
サービスワーカーキャッシュは、電波が弱い場所で必要な公開資料を読む助けになります。ただし、初回接続、保存範囲、情報の新しさ、更新通知、端末容量、機密情報の除外がそろって初めて安全に運用できます。
まず「圏外で誰が何を見たいか」と「古い内容を見せて困る情報」を分けてください。必要性と実装範囲から相談したい場合は、オフライン閲覧に対応したホームページについて相談するから、利用場所と資料の種類を分かる範囲でお知らせください。
参考資料
- W3C「Service Workers」（2026年9月6日確認）
- MDN Web Docs「Service Worker API」（2026年9月6日確認）
- MDN Web Docs「Cache」（2026年9月6日確認）
- Chrome for Developers「Strategies for service worker caching」（2026年9月6日確認）
- Chrome for Developers「A service worker’s life」（2026年9月6日確認）
- web.dev「Storage for the web」（2026年9月6日確認）
- OWASP Cheat Sheet Series「HTML5 Security Cheat Sheet」（2026年9月6日確認）
