PWAとは｜仕組み・できること・ネイティブアプリとの違いと採用判断

PWAとは何か｜3つの構成要素で決まる

PWAは「Progressive Web Apps」の略で、Webページをアプリとして振る舞わせるための技術の束を指します。ライブラリ名でも製品名でもありません。MDNのPWAドキュメントでは、単一のコードベースで複数プラットフォームに対応し、インストール可能で、オフラインでも動作し、OSと統合されるアプリとして整理されています。

重要なのは、PWAがオール・オア・ナッシングではないことです。マニフェストだけ置いてホーム画面に追加できる状態から、オフライン完全対応まで段階があります。「Progressive（段階的）」という名前のとおり、どこまで実装するかは選べます。

Service WorkerとWeb App Manifestの役割

2つの役割は明確に分かれています。

Service Workerは、ページとネットワークの間に挟まるJavaScriptです。fetchイベントで通信を横取りし、キャッシュから返すか、ネットワークに取りに行くかを決めます。ページが閉じていても動けるため、プッシュ通知の受信もここが担います。

Web App Manifestは、見た目とOS統合を決めるJSONファイルです。アプリ名、アイコン、起動URL、表示モード（standaloneなど）を書きます。ブラウザのUIを隠して単独ウィンドウで起動させるのは、このdisplayの指定です。

ほかに、ショートカット、共有ターゲット（OSの共有メニューへの登録）、ファイル関連付けなどもマニフェストから設定できます。このあたりはデスクトップPWAで効いてくる部分です。

インストール要件は緩和されている

ここは情報が古いまま流通している箇所です。Chrome for Developersの公式ブログによると、Chromeはメニューからのインストールについて、fetch()を実装したService Workerを持つという要件を、モバイルは108、デスクトップは112から撤廃しました。空のfetchハンドラを置くだけの「要件回避」が横行し、かえってパフォーマンスを損ねていたためです。

web.devのインストール要件に整理されている、主にChrome系ブラウザでのインストール判定条件は、おおむね次のとおりです。インストールの条件はブラウザごとに異なり、後述するSafari/iOSの挙動とは別物として扱ってください。

• HTTPSで配信されていること

• マニフェストにshort_nameまたはname、start_url、displayが指定されていること

• 192pxと512pxのアイコンが用意されていること

• prefer_related_applicationsを省略するか、falseにすること

• ユーザーがページ上でクリック/タップを1回以上行い、30秒以上滞在していること（インストールプロンプト発火の条件）

最後の条件は見落とされがちです。ローカルで検証していてbeforeinstallpromptが発火しないとき、原因が実装ではなくエンゲージメント条件であることは珍しくありません。

ミニFAQ：PWAにするとSEOは有利になりますか？

PWA化そのものがランキング要因になるわけではありません。ただし、Service Workerのキャッシュ設計によって再訪時の表示速度が改善されるケースはあります。速度改善を狙うなら、まずバンドルサイズや画像配信を見直すほうが効果を測りやすく、PWA化はその後の選択肢です。ビルド周りの前提はWebpackとは｜モジュールバンドラーの仕組み・Viteとの違い・基本設定で整理しています。

PWAでできること・ブラウザ差が出ること

結論から言えば、「アプリらしい体験」の大部分は実現できます。一方で、OSの深い部分に触るAPIはブラウザ間の実装差が残っています。

標準的に使える機能

主要ブラウザで広く使える範囲は次のとおりです。

• ホーム画面・アプリ一覧へのインストールと、単独ウィンドウでの起動

• Service Workerのキャッシュによるオフライン表示

• プッシュ通知（iOSは後述の前提条件あり）

• IndexedDBによるローカルデータ保存

• Web Share APIでのOS共有メニュー連携

• Badging APIでのアイコンバッジ表示（主にデスクトップとAndroid）

ブラウザ差が出る機能

一方、次の領域は実装状況を都度確認する前提で扱うのが安全です。MDNのBackground Synchronization APIは「Limited availability」と明記され、広く使われているブラウザの一部では動作しないとされています。

仕様の採用状況は変わります。要件定義の段階でMDNのブラウザ互換性テーブルを開き、対象ブラウザの行を実際に確認してから約束する。これを省くと、受入テストで揉めます。

ネイティブアプリ・クロスプラットフォームとの違い

3方式の違いは、技術よりも「配布」と「権限」に現れます。

配布・更新・手数料の違い

PWAの実利が大きいのはここです。審査待ちがないため、ネイティブより早く修正を反映しやすくなります。ネイティブアプリの審査は通常数時間から数日で、リリース計画に組み込む必要があります。ただし実際にユーザーへ届くまでの速度は、後述するキャッシュ制御の設計に依存します。

課金も判断材料になります。ストア外のWeb決済を使えるため、ストア手数料の設計から外れます。ただし決済手段の実装・不正対策は自前になるので、トータルで安くなるかは取引額と運用体制次第です。

一方で失うものもあります。ストアに並ばないことは、ストア内検索での発見機会を捨てることとほぼ同義です。既にWebで集客できているサービスなら影響は小さく、ストア経由の新規獲得を狙うサービスなら致命的になります。

デバイス機能へのアクセス範囲

カメラ、位置情報、ファイル選択、センサーの一部はWeb APIでも扱えます。しかし、バックグラウンドでの常時動作、OSレベルのウィジェット、ヘルスケアや決済など各OS固有のフレームワークへの接続は、Webの範囲外です。

この線引きで迷うなら、クロスプラットフォームを挟む選択肢もあります。方式ごとの特徴はFlutterとは？React Native・Kotlin・Swiftとの違い・案件単価をフリーランス視点で解説とReact Nativeとは？特徴・Flutter/Swift/Kotlinとの違い・案件単価をフリーランスエンジニア視点で解説が参考になります。React Native側の開発効率を上げる周辺環境はExpoとは｜React Nativeとの違いと開発を効率化する仕組みにまとめています。

なお、デスクトップ配布が目的ならPWAのほかにTauriやElectronも候補です。こちらはTauriとは｜Rust製デスクトップアプリ開発の特徴・Electronとの違いを解説で比較しています。

iOSのPWAは2026年時点で何が動くか

iOSの制約は、2023年以前の情報がそのまま引用され続けている代表的な領域です。現在のステータスを公式情報ベースで整理します。

プッシュ通知の前提条件

iOSのWeb Pushには、Safariのタブではなくホーム画面に追加された状態であるという前提があります。タブで通知を許可しても届きません。この一点が、iOS向けPWAの実装計画で最も影響します。「サイトを訪れただけのユーザーには通知が打てない」ため、ホーム画面への追加を促す導線そのものを設計に入れる必要があります。

加えて、WebKitの公式ブログで紹介されたDeclarative Web Pushは、条件次第でService Workerを介さずに通知を表示できる仕組みです。バッテリー消費とプライバシーの観点で設計が見直されたもので、実装の負担も軽くなります。ただし利用できるOS・ブラウザのバージョンは限られるため、対象ユーザーの環境分布を確認したうえで、従来のService Worker経由の実装と併用するか決めるのが現実的です。

iOS 26での変更点

WebKit in Safari 26.0では、ホーム画面に追加したサイトを既定でWebアプリとして開く仕様に変更されたと説明されています。マニフェストのdisplay値やメタタグを必須とする扱いが見直され、追加時のトグルでユーザーが選べる形です。UIの挙動はOSのマイナーアップデートや端末設定でも変わりうるため、実機での確認を前提にしてください。

実務上の意味は2つあります。マニフェストを用意していないサイトもアプリ的な起動になること、そしてブラウザのUIが消える前提でレイアウトを確認しておく必要があることです。セーフエリアの処理や、戻る操作の代替手段が用意されているかは、追加で見ておきたい箇所です。

「7日でデータが消える」の誤解

LocalStorageやIndexedDBが7日で消えるという話は、WebKitのTracking Preventionに基づくものです。ただし少なくともWebKitの説明では、ホーム画面に追加したWebアプリのファーストパーティドメインは、一律の7日上限とは別扱いとされています。Webアプリは独自の利用日数カウンタを持ち、実際の利用でリセットされる扱いです。

つまり「Safariのタブで開いているとき」と「ホーム画面のWebアプリとして使っているとき」で挙動が違います。ここを混同したまま「iOSのPWAはデータが消えるから業務利用は無理」と結論づけている説明は、現在の仕様とずれています。重要なデータはいずれにせよサーバー側に持たせるべきですが、判断の前提が誤っているのは別の問題です。

ミニFAQ：iOS対応を検証するのに実機は必要ですか？

必要です。Safariのレスポンシブデザインモードではホーム画面追加後の挙動（通知、セーフエリア、起動時のキャッシュ）を再現できません。最低でもiPhone実機1台を検証に組み込み、ホーム画面に追加した状態からテストを始めてください。

PWAを採る・採らないの判断軸

判断は2つの質問で大半が決まります。

1. ストアに並べる必要があるか（発見経路・信頼感・既存の課金導線）

2. OS固有の機能にどこまで触るか（バックグラウンド処理・デバイス連携）

PWAが向くケース

• 既にWeb版があり、再訪ユーザーの体験を底上げしたい

• 社内ツール・管理画面など、配布対象が限定されていてストア掲載の意味が薄い

• コンテンツ中心で、オフライン閲覧ができれば十分

• リリース頻度が高く、審査の待ち時間がボトルネックになっている

• 複数OSに人員を割けず、1つのコードベースで回したい

ネイティブ・クロスプラットフォームが向くケース

• ストア検索からの新規獲得が主要な流入経路

• バックグラウンドでの位置情報取得、BLE接続、ウィジェットなどが要件に入る

• ストア内課金やサブスクリプションの仕組みに乗せたい

• 高いフレームレートが求められるUIやゲーム

両取りも現実的な選択です。Web版をPWA化しつつ、ストア配布が必要な機能だけネイティブで持つ構成は珍しくありません。判断を一度で確定させる必要はなく、PWAで要件の輪郭を掴んでからネイティブ化する順序は、初期コストを抑える進め方として機能します。

フリーランスエンジニアから見たPWAの実務

2026年10月時点で、主要なフリーランスエージェント数社のWeb公開案件（フロントエンド職種の募集要件）を確認した範囲では、「PWA開発」という名称で切り出された募集は多くありません。目にするのは、フロントエンド案件の必須・歓迎スキル欄に「PWA対応の経験」が1行入っている形が中心です。少なくとも公開案件ベースでは、PWAは独立した案件カテゴリというより、フロントエンド案件での加点要素として扱われる傾向があります。非公開案件や受託開発会社の内部案件では事情が異なる可能性があり、ここでの記述は公開情報の観測にもとづく目安です。

加点につながりやすいのは、PWA単体の知識よりも周辺の実装力です。

• Service Workerのキャッシュ戦略を要件から設計できる

• 通知基盤（配信サーバー・購読管理・オプトイン率の計測）まで含めて話せる

• iOS実機での検証手順を持っている

• 既存のWebアプリに後付けで導入し、既存ユーザーの体験を壊さず移行できる

4つ目は特に重宝されます。新規構築よりも「既存サイトのPWA化」という形で相談が来るほうが多く、その場合はキャッシュによる旧バージョン固定をどう避けるかが実務の山場になります。配信側の知識があると設計が早く、CDNやエッジの理解はCloudflareとは｜CDN・セキュリティ・Workersの特徴と案件動向が参考になります。プッシュ基盤を外部サービスで組む場合はFirebaseとは？特徴・主要サービス・案件単価をフリーランス視点で徹底解説も押さえておくと話が早くなります。

単価面では、同じく公開案件の募集要件を見る限り、PWA対応経験の単体で単価が大きく跳ねるというより、フロントエンド全体のスキルセットの一部として評価されるケースが多く見られます。レンジ感はフロントエンドエンジニアのフリーランス単価相場｜経験別・技術別レンジと動向、モバイル領域との比較はモバイルアプリ開発案件の単価相場｜iOS・Android・クロス比較を参照してください。自分の経験でどのくらいを狙えるか知りたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

実装でつまずきやすいポイント

PWA導入の失敗は、だいたい同じ3箇所で起きます。

キャッシュ戦略を決めずに書き始める

Service Workerは「とりあえず全部キャッシュ」で書くと、更新が反映されないアプリになります。リソースの種類ごとに戦略を決めてから実装してください。

Service Workerの更新が反映されない

新しいService Workerは、既存のものが制御しているページが全て閉じるまで待機状態に入ります。ブラウザをリロードしただけでは切り替わりません。

対策は、更新検知時にユーザーへ再読み込みを促すUIを出すことです。黙ってskipWaitingを呼ぶと、開いているページが古いアセットを掴んだまま新しいコードで動くという最も厄介な状態を作りかねません。更新通知を出してユーザー操作で切り替える流れが無難です。

iOSを後回しにする

Android/Chromeで作り込んでから、公開直前にiOSを確認して要件が崩れる。PWA案件で繰り返し起きるパターンです。前述のとおり、通知はホーム画面追加が前提で、インストール導線の出し方もAndroidとは異なります。iOSの検証をスケジュールの後半に置かない。これだけで事故の多くは防げます。

PWA採用判断チェックリスト

要件定義の段階で、次の項目を順に埋めてください。No が出た項目は、その要件だけをネイティブ/クロスプラットフォームで補う案も含めて比較します。全部をどちらか一方に寄せる必要はありません。

1〜4がすべて Yes なら、PWAは第一候補として検討する価値があります。5〜8は実装品質に直結する項目で、ここを埋めずに着手すると「動くが使われないPWA」になりがちです。

まとめ

PWAは「Webアプリをインストール可能にし、オフラインと通知を足す仕組み」であり、採用判断はストア掲載の要否とOS機能の必要範囲でほぼ決まります。

• 構成要素はHTTPS・Web App Manifest・Service Workerの3点。段階的に導入できる

• Chromeはバージョン108（モバイル）/112（デスクトップ）以降、fetchハンドラ付きService Workerをインストール要件から外している

• iOSはiOS 16.4以降で通知が使え、Safari 18.4のDeclarative Web Pushは条件次第でService Workerなしでも通知を表示できる

• WebKitの説明では、ホーム画面に追加したWebアプリの自ドメインはITPの7日ストレージ上限とは別扱い

• Safari 26系ではホーム画面追加時に既定でWebアプリとして開くため、マニフェスト未設置サイトも挙動確認が必要

• 公開案件ベースでは、独立カテゴリではなくフロントエンド案件の加点要素として現れるケースが中心

次のステップとしては、手元のサイトにマニフェストを置いてChrome系で基本挙動を確認し、そのうえでiPhone実機でホーム画面に追加してからの起動を検証する順序が効率的です。そこで崩れるレイアウトや導線が、そのまま本番で対応すべき課題になります。

参照した一次情報は次のとおりです。

• プログレッシブウェブアプリ (PWA) - MDN

• Revisiting Chrome's installability criteria - Chrome for Developers

• What does it take to be installable? - web.dev

• Meet Declarative Web Push - WebKit

• WebKit in Safari 26.0 - WebKit

• Tracking Prevention in WebKit

• Background Synchronization API - MDN