PWA
Progressive Web App ・ ぴーだぶりゅーえー
Webサイトをネイティブアプリのように使えるようにする技術群。オフラインや通知に対応する。
✦ 30秒で試す — 航海アプリストアを一度も通らずに、スマホにアプリが増えるこのとき、スマホで実際に起きたことは？予想してみる概要
PWA（Progressive Web App）は、Web サイトにネイティブアプリのような体験 — ホーム画面へのインストール、オフラインでの動作、プッシュ通知 — を持たせるための技術群と設計の考え方の総称です。PWA という名前の新しい API が1つあるわけではなく、Service Worker・Web App Manifest・HTTPS という既存の Web 標準を組み合わせて、「URL を開くだけで使え、気に入ったらアプリとして端末に住み着く」体験を作ります。
「Progressive（漸進的）」という名前には、対応するブラウザでは豊かな体験を、対応しないブラウザでもふつうの Web サイトとして動く、という段階的な向上の思想が込められています。つまり PWA は「アプリか Web か」の二択ではなく、Web のまま少しずつアプリに近づけていく作り方です。Twitter（現 X）の軽量版や Starbucks、日経電子版など、アプリストアを経由せずにアプリ並みの体験を配る事例で広く知られるようになりました。
なぜ生まれたか
スマートフォンの時代、開発者は長く「配布は Web が圧倒的に楽、体験はネイティブが圧倒的に上」という分断に悩まされてきました。Web は URL ひとつで世界中に届き、更新も即時ですが、オフラインでは動かず、通知も送れず、ホーム画面にも並べません。ネイティブアプリはそのすべてができる代わりに、iOS と Android で別々に作り、ストアの審査を通し、利用者に「探して、ダウンロードして、インストールする」という高い壁を越えてもらう必要があります。多くの人は新しいアプリをめったに入れない一方で、Web サイトには毎日いくつも訪れる — 届く範囲の広さと、使い続けてもらう力が両立しない構造でした。
2015 年、Google の Chrome チームのエンジニアだったアレックス・ラッセルと、デザイナーのフランシス・ベリマンが、こうした「アプリのように振る舞う Web サイト」に Progressive Web App という名前を付けました。ちょうど Service Worker がオフライン動作とプッシュ通知の技術的な土台を提供し始めた時期で、これにインストール用の情報を書くマニフェストを組み合わせれば、「ストアを通らないアプリ」が作れる。新しい仕組みを発明したというより、Web の配布力を保ったまま、足りない体験だけを標準技術で補う、という方向に名前を与えたのです。
詳細
3本柱 — Service Worker・マニフェスト・HTTPS
PWA の技術的な骨格は3つの要素にまとまります。第一に Service Worker。ページとネットワークの間に入るプログラム可能な中継役として、オフライン対応・キャッシュ戦略・プッシュ通知の受信・バックグラウンド同期を担う、PWA の心臓部です。第二に Web App Manifest。アプリ名・アイコン・テーマ色・起動時の URL（start_url）・表示モード（ブラウザの UI を隠す standalone など）を書いた JSON ファイルで、HTML から <link rel="manifest"> で指し示します。ブラウザはこれを読んで「このサイトはインストールできる」と判断し、ホーム画面に置いたときの見た目を決めます。第三に HTTPS。リクエストを横取りできる Service Worker の力は改ざんとの相性が悪すぎるため、暗号化された配信が前提条件になっています。
インストールできる条件はブラウザごとに違い、少しずつ緩くなっています。Chrome はかつて「オフラインで何か返す fetch ハンドラを持つ Service Worker」を必須にしていましたが、空のハンドラを置くだけで条件を満たすサイトが増え、かえって遅くなったため、2022〜2023 年（モバイルは Chrome 108、デスクトップは 112）にメニューからのインストールについてはこの条件を外し、オフライン時は Chrome が既定のページを出すようにしました。いまの最低条件は、おおむね HTTPS とマニフェスト（名前・アイコン・start_url・表示モード）です。
体験の中身 — インストール・オフライン・プッシュ通知
条件を満たしたサイトを訪れると、ブラウザはインストールを提案できるようになります（Android のバナーや、デスクトップのアドレスバーのアイコンなど）。インストールといってもストアからプログラムを落とすわけではなく、実体はホーム画面へのアイコン追加と、ブラウザの UI を外した専用ウィンドウで start_url を開く設定です。起動すればスプラッシュ画面が出て、タスクの切り替えにも独立したアプリとして並びます。
オフライン対応は Service Worker のキャッシュ戦略そのものです。アプリの「殻」（画面の骨組みを作る HTML・CSS・JavaScript）を install のときに事前キャッシュしておき、起動時は殻を即座に出してから、データだけをネットワークに取りに行く「App Shell モデル」が定番で、SPA の作りと特に相性よく組み合わさります。プッシュ通知は、ページを閉じていてもブラウザのプッシュサービス経由で Service Worker が起こされ、通知を出す仕組みです。Web が「訪れてもらうのを待つ」メディアから「こちらから呼びかける」メディアに変わる、エンゲージメント面の目玉機能です。
iOS という現実 — 技術の話であり、プラットフォームの話
PWA を語るとき避けて通れないのがプラットフォーム間の温度差です。Android と Chrome が積極的に推してきた一方、Apple の iOS / Safari は長く消極的で、プッシュ通知に対応したのは 2023 年の iOS 16.4、しかも「ホーム画面に追加」済みの PWA に限られます。インストールの導線も、Android のようにブラウザから提案されることはなく、利用者が共有メニューから自分で「ホーム画面に追加」を選ぶ必要があります。
2024 年には、それが表面化する出来事がありました。EU のデジタル市場法（DMA）でサードパーティのブラウザエンジンを認めることになった Apple は、iOS 17.4 のベータ版で EU 域内のホーム画面 Web アプリを無効化し、単なるブックマークに格下げしようとしました。開発者や規制当局から強い反発を受け、正式版の直前（2024 年 3 月 1 日）に撤回しています。ストアの手数料を通らない PWA は、アプリストアを収益源とするプラットフォーマーと利害がぶつかる — PWA の普及の歴史は、技術の話であると同時にプラットフォーム政治の話でもあります。
使いどころと、いまの確かめ方
それでも PWA の価値は揺らいでいません。ストア審査なしの即時更新、1つのコードベースで全プラットフォームに届く開発効率、URL で共有できる導線の軽さは、ネイティブアプリにはない強みです。実務では「全員にまず Web で届け、よく使う人にはインストールしてもらう」という漸進的な設計が PWA らしい使い方で、カメラや Bluetooth の深い制御、バックグラウンドでの常駐処理が必須ならネイティブ、という住み分けがいまの相場観です。
かつては Lighthouse（Chrome の監査ツール）に PWA のチェックリストがありましたが、インストール条件の見直しに合わせて Lighthouse 12（2024 年）で PWA カテゴリは削除されました。いまは Chrome DevTools の Application パネルでマニフェストの読み取り結果（インストールできない理由も表示される）と Service Worker の状態を確かめ、ネットワークパネルでオフラインにして殻が表示されるかを試すのが定番の確かめ方です。
試問
PWA のアプリらしい体験は、3つの標準技術で支えられています。ページとネットワークの間に入る中継役のプログラム「Service Worker」、アプリ名・アイコン・起動時の URL・表示モードを書いた JSON ファイル「Web App Manifest」、そして暗号化された配信「HTTPS」です。PWA の8つの働きを、それを担う技術ごとに分けます。
PWA の8つの働きを、それを担う技術（Service Worker・マニフェスト・HTTPS）に仕分けよ
項目を選んでから、入れる箱を選びます