PWA(プログレッシブウェブアプリ)とは、通常のWebサイトに設定ファイルと常駐プログラムを足して、スマートフォンのアプリのように扱えるようにする仕組みです。ホーム画面にアイコンを置き、ブラウザのアドレスバーが無い画面で起動し、通信が不安定でも表示でき、条件を満たせばプッシュ通知も送れます。
アプリストアの審査を通さずにアプリらしい体験を提供できるため、開発費を抑える手段として紹介されることが多い技術です。ただし導入すれば成果が上がるものではありません。PWAが改善するのは2回目以降の訪問であり、初回訪問の体験はほとんど変わらないからです。
この記事では、PWAを構成する要素、実際にできること、効果が出るサイトの条件、iOSでの制約と誤解されている点、工数がどこにかかるか、計測がどう変わるか、そして導入を見送ってよい場合までを整理します。
この記事でわかること
・PWAはHTTPS・マニフェスト・Service Workerの3点で成り立つ
・改善するのは2回目以降の訪問。初回の速度は変わらない
・効果が出るのは再訪頻度が高いサイトに限られる
・iOSの「データが7日で消える」は閲覧時の話で、ホーム画面追加後は別扱い
・工数の本体はマニフェストではなくキャッシュの設計と運用
・アプリのように起動すると流入元が計測できなくなる

PWAを構成する3つの要素
PWAという単一の製品や規格があるわけではありません。既存のWebサイトに、次の3つを追加した状態を指す呼び方です。特別なフレームワークへの作り替えは前提ではなく、今あるサイトに足していく形で実現できます。
| 要素 | 役割 | 無いとどうなるか |
|---|---|---|
| HTTPS | 通信の暗号化。すべての前提になる | ホーム画面への追加も通知も使えない |
| Webアプリマニフェスト | アイコン、起動URL、表示形式を指定するJSONファイル | アイコンや独立ウィンドウでの起動ができない |
| Service Worker | ブラウザに常駐し、通信を横取りしてキャッシュや通知を扱う | オフライン表示とプッシュ通知が使えない |
マニフェストにはアプリ名、192ピクセルと512ピクセルのアイコン、起動時に開くURL、表示形式を記述します。ここまでで「ホーム画面に追加できるサイト」にはなります。
混同されやすい点として、インストール可能にするだけならService Workerは必須ではありません。MDNの解説でも、Service Workerはインストール要件ではなくオフライン動作のために推奨される要素として扱われています。逆に言えば、オフライン表示や通知を求めた時点で常駐プログラムの設計が必要になり、そこから工数が跳ね上がります。
PWAは製品ではなく、既存サイトに3要素を足した状態を指す。
追加だけなら軽いが、オフラインと通知を求めると設計が要る。
実際にできること、できないこと
紹介記事では「アプリと同じことができる」と書かれがちですが、実際にはAndroidとiOSで対応範囲が違います。特に日本はiPhoneの利用率が高いため、iOS側でできることを基準に判断してください。
| できること | Android(Chrome) | iOS(Safari) | 補足 |
|---|---|---|---|
| ホーム画面にアイコンを置く | 可能 | 可能 | iOSは共有メニューから利用者が手動で行う |
| アドレスバー無しで起動する | 可能 | 可能 | マニフェストの表示形式で指定する |
| オフラインでも表示する | 可能 | 可能 | iOSは保存できる容量が小さい |
| プッシュ通知を送る | 可能 | 条件付きで可能 | iOS16.4以降かつホーム画面追加済みが前提 |
| インストールを促す案内を出す | 可能 | 不可 | iOSは自動の導線を作れない |
| 閉じている間に裏で同期する | 可能 | 不可 | 起動中しか処理できない |
| カメラ・位置情報を使う | 可能 | 可能 | 利用者の許可が必要 |
| 連絡先・SMSなど端末機能の深い利用 | 不可 | 不可 | ネイティブアプリが必要 |
最も影響が大きいのは、iOSでインストールを促す案内を出せないことです。Androidでは「アプリを追加しますか」という案内をサイト側から表示できますが、iOSでは共有メニューを開いて「ホーム画面に追加」を選ぶ操作を、利用者が自分で行う必要があります。
つまりiPhone利用者には、その操作方法をサイト内で案内しない限り、PWAの存在自体が気づかれません。導入したのに追加されないという結果は、ここから生まれます。
対応範囲はAndroidとiOSで違う。判断はiOS基準で行う。
iOSは自動の追加導線が作れず、手順の案内が必須になる。
効果が出るのは再訪頻度が高いサイトだけ
ここがPWAの採否を決める中心です。PWAが速くするのは2回目以降の訪問であり、初回訪問はむしろ常駐プログラムを登録するぶん、わずかに処理が増えます。
検索から初めて訪れた人にとって、PWA対応サイトと通常のサイトの体験は変わりません。差が生まれるのは、キャッシュが効いた2回目以降、そしてホーム画面から直接起動した場合です。したがって同じ人が何度も訪れないサイトでは、投資した工数が回収されません。
| サイトの種類 | 同じ人の再訪頻度 | PWAの効き方 |
|---|---|---|
| 会社案内・コーポレートサイト | 年に数回以下 | ほぼ効かない |
| 採用サイト | 応募までの数週間に数回 | 限定的 |
| 店舗の予約サイト | 月1回から数回 | 効く |
| ECサイト | 月に数回 | 効く |
| オウンドメディア | 週に数回 | 条件次第で効く |
| 会員向けサービス・社内向けツール | ほぼ毎日 | 最も効く |
判断は次の掛け算で見てください。ホーム画面への追加率、1人あたりの再訪回数、1回あたりの体験の改善幅。このどれかがゼロに近ければ、全体もゼロに近づきます。追加率が数パーセントしかないサイトで再訪頻度も低ければ、成果に現れる規模にはなりません。
予約を軸にした再訪の設計については予約システムの選び方|既製サービスで足りる条件と、作るべき条件も参考になります。ECでのスマホ体験はECサイトのスマホ対応で見るべき箇所|購入までの各段階で起きる離脱で扱っています。
PWAが改善するのは2回目以降。初回訪問は変わらない。
追加率・再訪回数・改善幅の掛け算で、効果の規模が決まる。
iOSの「データが7日で消える」という誤解
PWAを検討すると、「iOSでは7日使わないとデータが消えるので実用にならない」という説明に必ず出会います。これは正確ではありません。
元になっているのはAppleのブラウザ開発チームであるWebKitが2020年に公表した、スクリプトから書き込まれた保存データを7日で削除するという方針です。ただし同じ文書に、ホーム画面へ追加したWebアプリは別扱いだと明記されています。ホーム画面のWebアプリはSafariの一部ではなく、独自の利用日数カウンタを持ち、実際に使うたびにその日数がリセットされる、という趣旨の記述です。同文書は、そうしたWebアプリのデータが削除されることは想定していないとも述べています。
- 7日の削除が効くのは、Safariでサイトを閲覧しているだけの状態
- ホーム画面に追加したあとは、使うたびにカウンタが戻る
- したがって定期的に使われるWebアプリでは、この制限は実務上の障害になりにくい
- 一方でSafariで見ているときと、ホーム画面から起動したときで保存領域は共有されない
実際のボトルネックは、消えるかどうかではなく、そもそもホーム画面に追加してもらえるかどうかです。iOSでは自動の案内を出せないため、追加率は施策の巧拙で大きく変わります。「7日で消えるから駄目」と結論づけると、本当に検討すべき論点を飛ばすことになります。
なお保存できる容量はiOSのほうが小さく、大量の画像をあらかじめ保存しておくような使い方には向きません。保存するのは画面の枠組みと繰り返し使う部品に限り、中身は通信で取得する構成が現実的です。
7日の削除はSafariでの閲覧に対する制限で、追加後は別カウンタ。
真の課題は保存期間ではなく、ホーム画面への追加率。
工数はマニフェストではなくキャッシュ設計で決まる
見積りを取ると金額に大きな幅が出る領域です。理由は明快で、ホーム画面に追加できるようにするだけの作業と、オフライン対応まで含む作業では、性質がまったく違うからです。
- マニフェストとアイコンを用意し、追加できる状態にする(作業量は小さい)
- 常駐プログラムを入れ、どのファイルを保存するか決める(設計が要る)
- 更新時に古い内容が出ないよう、破棄の条件を決める(運用が要る)
- 通知を送る仕組みと、送る内容の運用体制を作る(別の投資になる)
費用の大半は2番目と3番目に集中します。何を保存し、いつ捨てるかを間違えると、更新したはずの情報が利用者の画面に出続けます。
| 対象 | 扱い方 | 誤ると起きること |
|---|---|---|
| ページ本体のHTML | 通信を優先し、失敗時だけ保存分を出す | 保存を優先すると古いページが表示され続ける |
| デザインや動作のファイル | ファイル名に版を付けて保存を優先する | 名前が同じだと古い見た目のまま変わらない |
| 画像・アイコン | 保存を優先し、期限を決める | 差し替えが反映されない |
| 料金・在庫・予約枠 | 保存しない | 古い値のまま申し込みが入る |
| 問い合わせフォーム | 保存しない | 送信されたつもりで届かない |
最も多い事故は「サイトを更新したのに、一部の利用者にだけ古い画面が出続ける」というものです。問い合わせを受けても再現しないため、原因の特定に時間がかかります。導入時には、更新の反映を確認する手順を運用側に用意してください。公開後の更新体制についてはホームページの保守運用とは?何を、どの頻度でやるのかで整理しています。
費用は保存対象の設計と、破棄条件の運用に集中する。
料金・在庫・フォームは保存しない。古い値での申込を防ぐ。
計測はどう変わるか
見落とされやすい影響です。ホーム画面から起動した訪問には参照元の情報がありません。検索やリンクを経由していないため、アクセス解析では流入元不明の直接訪問として扱われます。
PWAの利用が増えるほど直接訪問の割合が増え、広告やSEOの成果が過小評価されているように見えるという現象が起きます。実際には既存の利用者が戻ってきているだけなのに、新規獲得の数字が落ちたと誤読されかねません。
| 起きること | 見え方 | 対処 |
|---|---|---|
| ホーム画面からの起動に参照元が無い | 直接訪問が増える | 起動URLに計測用の印を付ける |
| 再訪が増える | 1人あたりの訪問回数が上がる | 新規と再訪を分けて評価する |
| オフライン時の操作 | 記録が送信されない | 復帰後に送る設定が要る |
| 独立ウィンドウでの表示 | 画面幅の分布が変わる | 端末別の比較を分けて見る |
対処は難しくありません。マニフェストの起動URLに計測用のパラメータを付けておけば、ホーム画面からの起動だけを切り分けられます。命名の規則はUTMパラメータの設計と命名規則|流入元を正しく計測する方法に揃えてください。導入前後で数字を比較する場合は、この設定を導入と同時に入れておかないと、切り分けができなくなります。
ホーム画面起動は参照元を持たず、直接訪問に混ざる。
起動URLに計測用の印を付け、導入と同時に設定する。
ネイティブアプリ・アプリストア配信との比較
「アプリを作るべきか、PWAで足りるか」という相談は多くあります。判断は機能の多寡ではなく、配布と更新をどう回したいかで決まります。
| 項目 | PWA | ネイティブアプリ |
|---|---|---|
| 開発 | 既存サイトの延長 | iOSとAndroidで別々に作る |
| 配布 | URLを知らせるだけ | ストアの審査を通す |
| 更新 | サーバー側の変更が即反映 | 審査を経て利用者の更新を待つ |
| 発見のされ方 | 検索エンジンから | ストア内の検索から |
| 端末機能 | 使える範囲が限られる | 広く使える |
| 初回の導入 | 追加操作が要り、率は低い | インストールの動機が要る |
アプリストアでの配信も選択肢に入りますが、AndroidとiOSで事情が異なります。Androidは、PWAをアプリの外側で包んでGoogle Playへ出す仕組みが用意されており、ドメインの所有を示すファイルをサーバーに置いて自社のサイトであることを検証します。
一方でiOSは、Webサイトを包んだだけのアプリをApp Storeへ出せません。Appleの審査ガイドラインは、Webサイトを詰め替えただけのものを超える機能や体験を求めており、Webページの切り出しにあたるものは対象外だと明記しています。ストアでの配信を前提とするなら、iOS側は別途ネイティブでの開発が必要になると考えてください。
判断軸は機能ではなく、配布と更新の回し方。
Google Playへは出せるが、App Storeへは包むだけでは出せない。
導入より先に手をつけるべきこと
PWAの相談を受けたとき、先に確認するのは表示速度とスマートフォンでの操作性です。この2つが未対応のままPWA化しても、初回訪問の離脱は減りません。
- 表示速度を改善する。初回訪問に効くのはこちらで、PWAでは解決しない
- スマートフォンでの操作性を整える。押しにくい、読みにくいは先に潰す
- 計測を正しくする。改善の判断材料が無いまま次の投資はしない
- 再訪の理由を作る。通知で伝える内容が無いなら、通知の実装は不要
- 以上を満たしたうえで、PWA化を検討する
表示速度の改善順序はサイトの表示速度を改善する優先順位|何から手をつけるか、スマートフォンを前提とした設計はモバイルファーストデザインとは?重要視される理由と設計のコツで扱っています。
見送ってよい条件も明確です。訪問が年に数回で終わるサイト、通知で伝える内容が無い事業、公開後に更新を確認する担当者がいない体制。このいずれかに当てはまるなら、同じ予算を速度改善や導線の整理に充てたほうが成果に近づきます。
当社の制作実績では、業種ごとに求められる体験の違いをご覧いただけます。自社サイトで先に手をつけるべき箇所の切り分けはお問い合わせからご相談ください。
初回訪問の離脱は、PWAではなく速度と操作性で解決する。
再訪の理由が無いなら、導入を見送ってよい。
よくある失敗
再訪頻度を確認せずに導入する
PWAが改善するのは2回目以降の訪問です。年に数回しか訪れないサイトでは、工数に見合う変化は現れません。導入前に、同じ人が何回訪れているかを確認してください。
iOSで追加方法を案内しない
iOSでは自動の案内を出せません。共有メニューから追加する手順をサイト内で示さない限り、iPhone利用者には気づかれないまま終わります。
ページ本体を保存優先で扱う
更新したのに古い画面が出続けます。しかも一部の利用者にだけ起きるため、問い合わせを受けても再現できません。ページ本体は通信を優先してください。
料金や在庫を保存対象に含める
古い値を見たまま申し込みが入ります。金額や残数など、変動する情報は保存しない設定にしてください。
計測の設定を後回しにする
ホーム画面からの起動は流入元を持たないため、直接訪問が増えます。導入と同時に起動URLへ印を付けておかないと、前後の比較ができなくなります。
よくある質問
コーポレートサイトをPWA化する意味はありますか
多くの場合はありません。会社案内サイトは同じ人が繰り返し訪れる性質ではなく、PWAが効く2回目以降の訪問がほとんど発生しないためです。同じ予算を表示速度の改善や問い合わせ導線の整理に充てるほうが、成果に直結します。
PWAにするとSEOで有利になりますか
PWAであること自体が評価される仕組みはありません。ただし表示速度や操作性の改善は評価に関わるため、その過程で速度が上がれば間接的に効くことはあります。順位を目的にPWAを導入する判断は避けてください。
既存のサイトを作り直す必要がありますか
原則として不要です。PWAは既存サイトに設定ファイルと常駐プログラムを追加する形で実現できます。ただしHTTPSに対応していない場合は先にその対応が必要で、サイトの構造が複雑な場合は保存対象の整理に時間がかかります。
プッシュ通知はiPhoneにも送れますか
送れますが条件があります。利用者がホーム画面に追加していること、iOS16.4以降であること、そのうえで通知を許可していることが必要です。Safariで閲覧しているだけの状態では、許可を求めることもできません。到達する範囲は限定されると考えて設計してください。
費用はどのくらいかかりますか
ホーム画面に追加できるようにするだけなら小規模で済みますが、オフライン対応や通知まで含めると規模が変わります。金額差の中心は、何を保存し、いつ捨てるかという設計と、その後の運用にあります。見積りを比較するときは、対応範囲がどこまでかを揃えて確認してください。
まとめ
PWAは、既存のWebサイトにマニフェストとService Workerを追加し、ホーム画面から起動できるアプリのような形にする仕組みです。アプリストアの審査を経ずに提供でき、更新もサーバー側の変更が即座に反映されるため、配布と更新の負担は小さくなります。
ただし導入すれば成果が上がる技術ではありません。PWAが改善するのは2回目以降の訪問であり、検索から初めて訪れた人の体験は変わらないからです。効果の規模は、ホーム画面への追加率、1人あたりの再訪回数、1回あたりの改善幅の掛け算で決まります。会社案内サイトのように訪問が年に数回で終わる場合、この掛け算はほぼゼロになります。
iOSについては「データが7日で消えるため実用にならない」という説明が広まっていますが、WebKitの公表文書では、ホーム画面に追加したWebアプリはSafariとは別の利用日数カウンタを持ち、使うたびにリセットされると明記されています。実際の制約はそこではなく、iOSでは追加を促す案内を自動で出せず、追加率が上がりにくい点にあります。
工数の中心はマニフェストの作成ではなく、何を保存し、いつ捨てるかというキャッシュの設計と、その後の運用です。ここを誤ると、更新したはずの情報が一部の利用者にだけ古いまま表示されます。料金や在庫のように変動する情報は保存対象から外してください。あわせて、ホーム画面からの起動は流入元を持たないため、導入と同時に起動URLへ計測用の印を付けておく必要があります。
検討の順序は、表示速度、スマートフォンでの操作性、計測の整備、再訪の理由づくり、そのうえでPWAです。前の段階が未整備のままPWA化しても、初回訪問の離脱は変わりません。自社がどの段階にあるかの切り分けは、会社紹介資料とあわせてご確認ください。