PWAとは
PWA（Progressive Web App） とは、Webアプリにアプリ的な機能を追加した仕組み。
WebサイトやWebアプリそのものが別物になるわけではなく、
通常のWebアプリ
↓
PWA対応
↓
ブラウザがアプリとして扱う
というイメージに近い。
Googleが2015年に提唱した概念で、当時は「Reliable（信頼性）」「Fast（高速）」「Engaging（没入感）」の3要素が軸とされていた。特定のフレームワークやライブラリを指す言葉ではなく、HTTPS・manifest.json・Service Workerという3つの技術要件を満たしたWebアプリの総称にすぎない。React、Vue、素のHTML/CSS/JSどれで作っても要件さえ満たせばPWAと呼べる。
代表的な採用事例として、Twitter Lite（現X Lite）、Starbucks、Uberなどが挙げられる。特にStarbucksは低速回線環境でのアプリサイズ削減を目的にPWAへ移行した事例として有名。
PWAの必須要件
ブラウザがWebアプリを「PWAとして扱ってよい」と判断するための最低条件は以下の3つ。どれか1つでも欠けるとインストール可能にはならない。
HTTPS
セキュリティ確保のため必須。
Service Workerは通信内容を横取りできる強力な仕組みのため、中間者攻撃（MITM）を防ぐ目的でHTTPS環境でしか登録できない。localhostは開発用の例外としてHTTP接続でも動作するが、本番環境では常時SSL化されている必要がある。
manifest.json
アプリ情報を定義するJSON設定ファイル。<link rel="manifest" href="/manifest.json"> のようにHTMLから読み込む。
例
- アプリ名（name / short_name）
- アイコン（icons）
- 起動URL（start_url）
- テーマカラー（theme_color / background_color）
- 表示モード（display：standalone / fullscreen / minimal-ui など）
最低限のサンプルは以下の通り。
{
"name": "サンプルアプリ",
"short_name": "サンプル",
"start_url": "/",
"display": "standalone",
"background_color": "#ffffff",
"theme_color": "#000000",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
]
}
display: standalone を指定することで、起動時にブラウザのアドレスバーが非表示になり、ネイティブアプリに近い見た目になる。
Service Worker
ブラウザとネットワークの間で動作するJavaScriptの仕組み。Webページとは別スレッドで動作し、ページを閉じても裏で生き続けられるのが特徴。
主な用途
- キャッシュ管理
- オフライン対応
- バックグラウンド処理
- 通知機能（Push API連携）
ライフサイクルは大きく3段階に分かれる。
install（初回登録・キャッシュ準備）
↓
activate（古いキャッシュの破棄・有効化）
↓
fetch（リクエストの横取り・キャッシュ返却）
キャッシュ戦略にもいくつかパターンがあり、用途に応じて使い分ける。
| 戦略 | 挙動 | 向いている用途 |
|---|---|---|
| Cache First | キャッシュ優先、なければネットワーク | 画像・CSS・JSなど更新頻度が低い静的ファイル |
| Network First | ネットワーク優先、失敗時にキャッシュ | ニュースなど最新性が重要なコンテンツ |
| Stale-While-Revalidate | キャッシュを即返しつつ裏で更新 | ある程度の鮮度で妥協できるコンテンツ |
PWAで追加される機能
| 機能 | 通常のWeb | PWA |
|---|---|---|
| ブラウザ閲覧 | ○ | ○ |
| ホーム画面追加 | △ | ○ |
| インストール | × | ○ |
| 独立ウィンドウ起動 | × | ○ |
| オフライン動作 | × | ○ |
| キャッシュ活用 | △ | ○ |
| プッシュ通知 | × | ○ |
| 自動更新 | △ | ○ |
△は「ブラウザの標準機能として簡易的に対応している」状態を指す。例えばホーム画面追加はPWA要件を満たさなくてもショートカットとしては可能だが、アイコンやスプラッシュ画面の質、オフライン動作までは保証されない。
メリット
インストール可能
ユーザーが任意でホーム画面へ追加できる。アプリストアの審査を経由しないため、公開までのリードタイムが短い。
アプリのように起動できる
ブラウザタブではなく独立したウィンドウで動作可能。display: standalone の設定次第で、URLバーやブラウザUIを隠した状態で起動できる。
オフライン対応
Service Workerを利用してキャッシュから表示できる。ネットワークが不安定な環境（地下鉄・地方・海外など）でも最低限の閲覧体験を維持できるのが強み。
プッシュ通知
ネイティブアプリに近い通知体験を実現できる。Push APIとNotification APIを組み合わせて実装する。ただしiOSはSafari 16.4以降（2023年3月〜）でようやく対応した経緯があり、Android/デスクトップと比べて対応が遅れていた。
自動更新
アプリストア経由の更新が不要。Service Workerが新しいバージョンを検知すると自動的に更新され、ユーザーが手動でアップデートする手間がない。
デメリット・注意点
インストールは必須ではない
通常のWebサイトとして利用することもできる。インストールを強制する仕組みではなく、あくまでオプションの一つ。
ブラウザ依存
ブラウザやOSによって対応状況が異なる。特にiOS（Safari）は歴史的に対応が遅く、以下のような制限がある。
- バックグラウンドでのストレージが一定期間アクセスがないと自動削除される場合がある
- Push通知対応がAndroidより数年遅れた
- インストール導線（Add to Home Screen）がAndroidほど自然に表示されない
ネイティブアプリではない
OSの機能へ深くアクセスする用途には向かない。Bluetooth、NFC、カメラの高度な制御、バックグラウンドでの常時位置情報取得など、OSレベルのAPIへのアクセスは制限される。
PWA化しただけでは価値が薄い場合もある
例えば
普通のWebサイト
↓
ホーム画面追加可能
だけでは利用体験はほとんど変わらない。オフライン対応やプッシュ通知など、PWA特有の機能を実際に使い込んで初めて差別化になる。要件を満たすだけの「なんちゃってPWA」は珍しくない。
PWAが向いているもの
- ToDoアプリ
- 社内システム
- 業務アプリ
- 予約システム
- ECサイト
- ニュースアプリ
特徴
オフライン
通知
高速表示
の恩恵を受けやすい。特に社内システムは「アプリストア審査なしで即座に更新を配布できる」点が業務上のメリットになりやすい。
PWAが向いていないもの
- 高性能ゲーム
- 動画編集
- 3Dアプリ
- 高度なネイティブ機能が必要なアプリ
この場合はネイティブアプリの方が適している。GPUへの直接アクセスやOS固有のAPIを多用する用途では、Webの制約がボトルネックになりやすい。
本質
PWAは
Webをアプリ風に見せる仕組み
というより、
Webにアプリ的な体験を追加する仕組み
と考えた方が近い。見た目をアプリに寄せることが目的ではなく、オフライン耐性や通知といった体験的な価値を段階的に追加していく発想が本質。
個人的な理解
通常のWebアプリ
↓
manifest.json
＋
Service Worker
↓
PWA
↓
ブラウザがアプリとして扱う
技術的にはWebアプリの延長線上にある。ネイティブアプリのような別プラットフォーム向けの実装ではなく、既存のWeb技術に薄いレイヤーを足しているだけ、という理解をしておくと迷いにくい。
まとめ
- PWAはWebアプリの進化形
- HTTPS・manifest・Service Workerが基本要件
- オフラインや通知が大きな価値
- ネイティブアプリの代替ではない
- オフラインや通知を活用しない場合、通常のWebアプリとの差は小さい
PWAは「新しいアプリ開発技術」ではなく、
Webにアプリ的な体験を追加するための仕組み
と考えると理解しやすい。