プログレッシブ Web アプリ - アプリが不要で、サイトをアプリとして使えば足りるとき
プログレッシブ Web アプリ（PWA） は、ホーム画面にインストールでき、ほぼネイティブアプリのように開き、オフラインや弱い回線でも動けるサイトです。多くのビジネスにとって、App Store と Google Play への本格リリースは余分な月数と予算です。カタログ、会員ページ、予約、レストランのメニュー、B2B ポータルは、通常の HTML、CSS、JavaScript 上の PWA で足りることが多いです。以下では、「サイトをアプリとして使う」で十分なとき、必須技術、そしてネイティブがまだ必要な場面を整理します。
- PWA - サイト + マニフェスト + service worker：アイコン、フルスクリーン、キャッシュ、場合によっては push
- あらゆるアプリの代替ではない - 重いグラフィック、深い端末アクセス、厳しい App Store SLA はネイティブの領域
- ひとつのコードベース - 最初は別々の iOS/Android チームではなく一つの Web 版
- ストアなしで更新 - サーバーにデプロイすれば、次の訪問で新版が届く
- SEO は残る - 検索上は普通のページであり、閉じたバイナリではない
- スタート用チェックリスト - HTTPS、
manifest.webmanifest、service worker、レスポンシブ、速い First Contentful Paint
PWA を平易に言うと
PWA（Progressive Web App）は、サイトをインストール済みアプリのように振る舞わせる実践と Web API のセットです。
- インストールできる - ブラウザからスマホやデスクトップへ（アイコン、いつものアドレスバーのない別ウィンドウ）。
- 速く開く - shell（UI の殻）のキャッシュによる。
- 悪い回線に耐える - キャッシュ画面を出すか、「あとで送信」用に操作をキューする。
- ネイティブっぽく見える - スプラッシュ、theme-color、
display: standalone。
別言語でも「また別のフレームワーク」でもありません。いまのサイトを installability の基準まで上げ、コンテンツを安定して届けることです。Chrome、Edge、Safari、Firefox では基本シナリオは成熟しています。push、バックグラウンド同期、一部の端末 API には差が残ります。
サイトをアプリとして使えば足りるとき
製品の本質がブラウザ上のデータ UIであり、ゲームやシステムツールでないとき、PWA は見合います。
良い候補：
| シナリオ | なぜ PWA で足りることが多いのか |
|---|---|
| カタログ、メニュー、価格表、予約 | コンテンツ + フォーム。ストア側の付加価値は小さい |
| 顧客アカウント / B2B ポータル | 認証、表、文書、注文ステータス |
| 社員向け社内ツール | ストア公開なしで業務スマホにインストール |
| メディアやフィード（ニュース、ブログ、ドキュメント） | SEO とリンク共有が重要 |
| 「本物のアプリ」のマーケ前の MVP | ネイティブ 2 チーム分のコストなしで需要を検証 |
週に何度も戻り、「銀行アプリのような」アイコンと、地下鉄で圏外でも安定した UX が欲しい - なら PWA が期待に応え、App Store レビューも不要です。
ネイティブアプリの方がよいとき
「PWA がすべてを置き換える」というマーケより、正直な答えが大事です。
- 厳しいバックグラウンド処理、複雑な Bluetooth / NFC / 低レベルセンサーが必要；
- 3D/AR 性能、重いカメラ、オフラインゲームがクリティカル；
- 製品がストアにだけ存在すべき（パートナー棚、ネイティブ必須の法人 MDM）；
- Apple/Google の IAP 経由の課金・サブスクが主収益チャネル；
- すでに強い iOS/Android 体制があり、Web は副次チャネル。
2026 年のよくある妥協案：全員向けに PWA またはレスポンシブサイト + 指標が需要を示したところだけネイティブ（リテンション、モバイル比率、再訪）。
PWA の構成要素
「プログレッシブ」に欠かせない最小セット：
1. HTTPS
Service worker と installability には安全な origin が必要です。ローカルの localhost は開発用の例外です。
2. Web App Manifest
manifest.webmanifest（または JSON）で名前、アイコン（多くは 192 と 512）、start_url、display、テーマ色を記述します。これがないとブラウザは「アプリをインストール」を出しません。
3. Service Worker
バックグラウンドのスクリプト：shell と静的資産をキャッシュし、オフライン用フォールバックを返し、回線断で POST をキューすることもあります。典型戦略は CSS/JS/アイコンが cache-first、API と価格が network-first。
4. レスポンシブで速い UI
PWA は遅いサイトを救いません。レスポンシブ、画像圧縮、妥当な JavaScript バンドルが必要です。さもなければ「アプリ」は一度入れて消されます。
5. 任意：push、Share Target、shortcuts
Push とバッジはリテンションを上げますが、同意と通知ポリシーを複雑にします。マニフェストの shortcuts はアイコン長押しで素早い操作を提供します。
ビジネス効果：幻想のない数字
比較すべきは「流行るか」ではなく、予算とリリース周期です。
| 項目 | PWA / サイト | ネイティブアプリ |
|---|---|---|
| MVP 期間 | 週単位 | 両プラットフォームでしばしば月単位 |
| 更新 | サーバーへデプロイ | ストア審査 + ユーザー更新待ち |
| 配布 | URL + 「ホーム画面に追加」 | ストア、ASO、審査 |
| 検索とリンク | 十分な SEO | 限定的。流入はストアや広告が多い |
| 保守コスト | フロントエンド一つ | 2 つのコードベース、またはクロス + それでも Web |
仮説検証の段階や、コンテンツとフォームがハードウェアアクセスより重要なサービスでは節約は現実です。「複雑な生体認証とバックグラウンド地理トリガー付きの完全ネイティブ銀行体験」を約束すると節約は消え、ネイティブが適切です。
既存サイトへの導入チェックリスト
- まず速度とレスポンシブを整える - さもなくば PWA は悪い UX を固定するだけ。
- マニフェストとアイコンセットを出す（必要なら明暗テーマ）。
- 明確なキャッシュ方針で service worker を登録 - 個人データを期限なしでキャッシュしない。
- Chrome DevTools / Lighthouse（PWA）で installability を確認。
- Safari（iOS）を試す - 「ホーム画面に追加」でインストール。push と一部 API は Android と異なる。
- インストール計測と「アイコンから開いた」vs「リンクから来た」経路を取る。
- インデックスを壊さない - コンテンツは普通の URL として届くこと。PWA は上乗せであり、SSR/プリレンダなしの SPA 行き止まりではない。
- オフライン挙動を正直に書く - 圏外で何ができ、何ができないか。
サイトビルダー では機能はプラットフォーム次第です。スイッチ一本で PWA になるものもあれば、自前ホスティングとカスタムコードが必要なものもあります。原則は同じ - マニフェスト + worker + HTTPS。
よくある失敗
- service worker もマニフェストもないレスポンシブサイトをすべて PWA と呼ぶ。
- 価格・在庫 API を「永久」キャッシュ - 昨日の価格表が見える。
- 「App Store 並み」と言いながら UX と性能の予算を削る。
- iOS を無視し、Android Chrome だけ試す。
- 重い SPA をインデックスなしで作り、検索流入を失う。
- 初回訪問で強引に push - 通知とブランドがブロックされる。
まとめ
プログレッシブ Web アプリは、「画面のアイコン + 速い再訪」が必要で、両プラットフォームの本格ネイティブ製品までは要らないときの現実的な道です。カタログ、ポータル、予約、社内ツールなら、サイトをアプリとして使うので足りることが多いです。ゲーム、深いハードウェア、ストア中心の収益化ならネイティブを計画してください。HTTPS、マニフェスト、service worker、速度から始め、あとはハイプではなくリテンション指標で改善します。
よくある質問
PWA と普通のモバイルサイトの違いは？
普通のレスポンシブサイトはブラウザのタブで開きます。PWA は installability（アイコン、standalone ウィンドウ）、キャッシュとオフライン用の service worker、アプリメタデータのマニフェストを足します。見た目は同じデザインでも、配信と再訪のモデルはアプリに近づきます。
PWA を App Store と Google Play に出せますか？
Google Play は Trusted Web Activity / PWA ラッパーに比較的寛容です。App Store は厳しく、明確なネイティブ価値のない「殻だけのサイト」は却下されがちです。多くのビジネスでは PWA の主チャネルはブラウザと「ホーム画面に追加」。ストアは別要件の別製品です。
PWA は完全にオフラインで動きますか？
完全であることは稀です。 オフラインで使えるのはだいたい shell、以前開いたページ、静的資産です。ライブ価格、アカウント、決済には回線が要ります。良い PWA は使えない部分を正直に示し、必要なら回線復帰まで操作をキューします。
PWA 用に別ドメインやサブドメインが必要ですか？
別ドメインは必須ではありません。重要なのは安定した origin（スキーム + ホスト + ポート）、正しい start_url、旧キャッシュと衝突しない service worker 更新です。app.example.com に置くのは組織の選択であり、仕様の要求ではありません。
WordPress、Tilda、自前スタックならどこから？
プラットフォームがマニフェストと service worker を標準で出すか確認します。なければ静的マニフェスト、最小の shell worker、アイコンを追加。自前スタックならだいたい 1 スプリントです。その後 Core Web Vitals を測り、Android / iOS でインストールを試し、API キャッシュ方針を決めます。最初は push ではなく、速いインストールと安定した再オープンを優先してください。