PWA
ぴーだぶりゅーえー
Webサイトをネイティブアプリのように使えるようにする技術群。オフラインや通知に対応する。
概要
PWA(Progressive Web App)は、Webサイトにネイティブアプリのような体験 — ホーム画面へのインストール、オフライン動作、プッシュ通知 — を持たせるための技術群と設計思想の総称です。特定の新しいAPIが1つあるわけではなく、Service Worker・Web App Manifest・HTTPS という既存のWeb標準を組み合わせ、「URLを開くだけで使え、気に入ったらアプリとして住み着く」体験を作ります。
「Progressive(漸進的)」という名前には、対応ブラウザでは豊かな体験を、非対応ブラウザでも普通のWebサイトとして動く、という段階的な向上の思想が込められています。つまりPWAは「アプリ か Web か」の二択ではなく、Webのまま少しずつアプリに近づけていくアプローチです。Twitter(X)や Starbucks、日経電子版など、アプリストアを経由せずアプリ級の体験を配る事例で広く知られるようになりました。
なぜ生まれたか
スマートフォン時代、開発者は長らく「配布はWebが圧倒的に楽、体験はネイティブが圧倒的に上」という分断に悩まされてきました。WebはURLひとつで世界中に届き、更新も即時ですが、オフラインでは動かず、通知も送れず、ホーム画面にも並べません。ネイティブアプリはその全部ができる代わりに、iOSとAndroidで別々に開発し、ストア審査を通し、ユーザーに「ダウンロードしてインストールする」という高いハードルを越えてもらう必要があります。実際、大半のユーザーは月に新しいアプリをほとんど入れない一方、Webサイトには日々何十と訪れる — リーチとエンゲージメントが両立しない構造でした。
PWAは2015年にGoogleのエンジニアが提唱した概念で、「Webの配布力を保ったまま、足りない体験だけを標準技術で補う」という解決を示しました。ちょうど Service Worker がオフラインとプッシュ通知の技術的土台を提供し始めた時期で、これにインストール情報を記述するマニフェストを組み合わせることで、「ストアを通らないアプリ」が現実になったのです。
詳細
3本柱 — Service Worker・マニフェスト・HTTPS
PWAの技術的な骨格は3つの要素に集約されます。第一に Service Worker。ページとネットワークの間に入るプログラム可能なプロキシとして、オフライン対応・キャッシュ戦略・プッシュ通知の受信・バックグラウンド同期を担う、PWAの心臓部です。第二に Web App Manifest。アプリ名・アイコン・テーマ色・起動時のURL・表示モード(ブラウザのUIを隠す standalone など)を記述した JSON ファイルで、ブラウザはこれを見て「このサイトはインストール可能だ」と判断し、ホーム画面に置いたときの見た目を決めます。第三に HTTPS。リクエストを横取りできる Service Worker の力は改ざんと相性が悪すぎるため、暗号化された配信がPWAの前提条件になっています。
体験の中身 — インストール・オフライン・プッシュ通知
条件を満たしたサイトを訪れると、ブラウザはインストールを提案できるようになります(Androidのバナーやアドレスバーのアイコンなど)。インストールといってもストアからバイナリを落とすわけではなく、実体はホーム画面へのアイコン追加と、ブラウザUIを外した専用ウィンドウでの起動設定です。起動すればスプラッシュ画面が出て、タスク切り替えにも独立したアプリとして並びます。
オフライン対応は Service Worker のキャッシュ戦略そのものです。アプリの「殻」(HTML・CSS・JS)を事前キャッシュしておき、起動時は殻を即座に表示してからデータだけをネットワークに取りに行く「App Shell モデル」が定番で、SPA のアーキテクチャと特に相性よく組み合わさります。プッシュ通知は、ページを閉じていてもブラウザ(のプッシュサービス)経由で Service Worker が起こされ、通知を表示する仕組みで、Webが「訪れてもらうのを待つ」メディアから「こちらから呼びかける」メディアに変わる、エンゲージメント面での目玉機能です。
iOSという現実、そしてPWAの使いどころ
PWAを語るとき避けて通れないのがプラットフォーム間の温度差です。AndroidとChromeが積極的に推進してきた一方、AppleのiOS/Safariは長らく消極的で、プッシュ通知の対応は2023年(iOS 16.4)までかかり、しかも「ホーム画面に追加」済みのPWAに限られます。インストールの導線も、Androidのような能動的な提案がなく、ユーザーが共有メニューから自分で「ホーム画面に追加」を選ぶ必要があります。ストア手数料を回避できるPWAは、アプリストアを収益源とするプラットフォーマーと利害が衝突する — PWAの普及史は、技術の話であると同時にプラットフォーム政治の話でもあります。
それでもPWAの価値は揺らいでいません。ストア審査なしの即時更新、1つのコードベースで全プラットフォームに届く開発効率、URLで共有できる導線の軽さは、ネイティブアプリにはない強みです。実務では「全ユーザーにまずWebで届け、ヘビーユーザーにはインストールしてもらう」という漸進的な設計がPWAらしい使い方で、カメラやBluetoothの深い制御が必須ならネイティブ、という住み分けが現在の相場観です。判定の目安として、Lighthouse(Chrome内蔵の監査ツール)がPWA要件のチェックリストを提供しており、最初の一歩に向いています。