パンタグラフ オリジナル資料
PWAで「できること」を公開中 What is "PWA"?
資料ダウンロードはこちら
PWAのホーム画面アイコン追加とプッシュ通知UIパターン|iOS対応も解説
UI/UXデザイン 2026.09.30

本記事は2026年8月に内容を更新しました。
初回公開は2018年6月22日です。公開当時、iOSではPWAのプッシュ通知を利用できませんでしたが、2023年3月のiOS 16.4以降は対応しています。今回の更新では、iOSでの対応条件と実装上の注意点を新しいセクションとして追加しました。
PWA(Progressive Web Apps)とは、Webサイトでありながら、ホーム画面への追加やプッシュ通知といったネイティブアプリに近い機能を使える仕組みです。本記事では、そのなかでも成果に直結する「ホーム画面へのアイコン追加」と「プッシュ通知」のUIに絞って解説します。
目次
「ホーム画面へのアイコン追加」と「プッシュ通知」
PWAの「ホーム画面へのアイコン追加」と「プッシュ通知」は、いずれもユーザー自身のアクションがあって初めて機能する仕組みです。
ホーム画面へのアイコン追加
PWAではホーム画面(スクリーン)にアイコンを追加することができます。
ユーザーのホーム画面からネイティブアプリと同じようにワンタップでサイトへアクセスできるようになるため、ブラウザを開いてわざわざ検索するなりブックマークから目的のサイトを選ぶなどの手間がかかりません。ユーザーにとっての利便性が向上するので、来訪頻度の増加が期待できます。
ユーザーがホーム画面にアイコンを追加するには二つの方法があります。ひとつはサイト閲覧時に表示されるホーム画面追加のメッセージから行う方法、もうひとつはブラウザメニューの「ホーム画面に追加」から行う方法です。いずれもユーザーにアクションしてもらう必要があります。尚、ひとつ目の方法でユーザーがホーム画面へのアイコン追加を拒否した場合、同じメッセージは一定期間再表示されない仕様となっています(今後変更の可能性あり)。
![]()
(Financial Times:https://app.ft.com/?standalone)
プッシュ通知
PWAでは、ネイティブアプリと同じようにプッシュ通知を送ることができます。
ユーザーはブラウザを閉じている状態でもプッシュ通知を受け取ることができるので、従来のモバイルサイトと比べてユーザーとの接触機会を格段に増やすことができます。
ユーザーにプッシュ通知を送るためには、あらかじめユーザーの許諾を得る必要があります。プッシュ通知の許可は、サイト閲覧時に表示されるブラウザ固有の許諾メッセージから行いますが、ホーム画面へのアイコン追加と同様、こちらもデフォルトで許諾がONになることはなく、ユーザーにアクションしてもらう必要があります。尚、このブラウザ固有のプッシュ通知許諾メッセージはユーザーに一度拒否されると再出現はしないようです。
![]()
(Roman:https://www.romanoriginals.co.uk/?utm_source=web_app_manifest&utm_medium=web_app_manifest)
ユーザーとの接触機会の増加が期待できる「ホーム画面へのアイコン追加」と「プッシュ通知」ですが、それをユーザーに利用してもらうためには、上記のとおりユーザーの実際のアクションが必要となります。つまり、ユーザーにホーム画面にアイコンを追加してもらわないとサイトへの直アクセスはしてもらえず、またプッシュ通知を許可してもらわないとユーザーの元に通知を届けることはできません。従って、当然のことですが、これらのアクションをユーザーに取ってもらえるかどうかで、ユーザーとの接触機会を増やせるかどうかが大きく左右されることになります。
iOSでのPWAプッシュ通知対応(2023年3月〜)
iOSでは、2023年3月に公開されたiOS 16.4以降、ホーム画面に追加したWebアプリでプッシュ通知を利用できます。
本記事の初回公開時点(2018年)では、iOSはPWAのプッシュ通知に対応しておらず、これがPWA導入をためらう最大の理由になっていました。Appleは2023年2月にiOS 16.4のベータ版でWeb Pushへの対応を発表し、同年3月の正式版から、iPhoneでもPWAのプッシュ通知が利用できるようになっています。これにより、iOSとAndroidの双方で同じ仕組みのプッシュ通知を配信できる環境が整いました。
iOSでプッシュ通知を利用するための条件
iOSでPWAのプッシュ通知を配信するには、Webアプリマニフェストの設定、ホーム画面への追加、ユーザー操作起点での許可要求という3つの条件を満たす必要があります。
|
条件 |
内容 |
|
Webアプリマニフェストの設定 |
マニフェストファイルを用意し、displayメンバーをstandaloneまたはfullscreenに設定します。これによりホーム画面から起動した際にアプリのように動作します |
|
ホーム画面への追加が必須 |
iOSでは、Safariで閲覧しているだけではプッシュ通知を利用できません。ユーザーがホーム画面にWebアプリを追加していることが前提条件です |
|
ユーザー操作起点での許可要求 |
「通知を受け取る」ボタンのタップなど、ユーザーの直接的な操作に応答する形でのみ通知の許可を要求できます。ページ読み込み時に自動でダイアログを表示することはできません |
ここで特に重要なのは、2つ目の「ホーム画面への追加が必須」という条件です。iOSでは、ホーム画面にアイコンを追加してもらえなければ、そもそもプッシュ通知を送る権利すら得られません。本記事で解説しているアイコン追加を促すUIの工夫は、iOS環境においてはプッシュ通知施策の前提条件そのものであり、公開当時よりも重要性が高まっています。
また3つ目の条件により、iOSでは「サイトを開いた瞬間に許諾ダイアログが自動表示される」という設計自体が不可能です。後述する事例のうち、パターン②にあたる自動表示の手法はiOSでは成立せず、パターン③のようにユーザーへ価値を説明してからボタンを押してもらう設計が必須となります。
iOSでできること・実装時の注意点
iOSのPWAでは、ネイティブアプリと同様にバッジ表示やロック画面への通知表示が可能です。
- 通知はロック画面、通知センター、Apple Watchに表示され、集中モード(Focus)の設定にも従います
- Badging APIのsetAppBadge・clearAppBadgeを使い、アイコンに未読件数のバッジを表示できます
- W3C標準に沿ってWeb Pushを実装済みであれば、iOS向けに追加の実装をしなくてもそのまま動作します
- マニフェストにidメンバーを設定すると、デバイス間で集中モードの設定を同期できます
- プッシュの送信元を制限している場合は、*.push.apple.com からのURLを許可する必要があります
実装時は、ブラウザの種類で処理を分ける「ブラウザ判定」ではなく、機能の有無を確認する「機能検出」を用いることが推奨されています。iOSのバージョンによって挙動が異なるため、機能検出で分岐させたほうが安全です。
Declarative Web Push(iOS 18.4以降)
iOS 18.4以降では、Service Workerを使わずにプッシュ通知を実装できるDeclarative Web Pushが利用できます。
従来のWeb PushはJavaScriptを前提とした設計で、通知を表示するためにService Workerの実装が必須でした。Declarative Web Pushでは、決められた形式のJSONを送信することでブラウザが直接通知を処理するため、Service Workerを用意しなくても購読のリクエストと通知の表示ができます。省電力性やプライバシー保護の面でも改善されており、従来のWeb Pushとの後方互換性も保たれています。
対応プラットフォームはiOS 18.4、iPadOS 18.4、macOS 15.5です。これからPWAのプッシュ通知を実装する場合は、実装負荷の低いDeclarative Web Pushを軸に検討し、対応していない環境向けに従来方式を併用するという構成が現実的です。
※iOSのPWA関連仕様は更新が続いている領域です。実装前にAppleおよびWebKitの公式ドキュメントで最新の要件をご確認ください。
ユーザーのアクションを促す方法の重要性
ホーム画面へのアイコン追加とプッシュ通知の許可は、ユーザーにどんな価値があるのかを伝えられるかどうかで結果が大きく変わります。
ネイティブアプリでのプッシュ通知に関して、これまでしばしばその許諾の取得方法について議論されることがありました。
今も多くのネイティブアプリは、インストール直後の初回起動時に、十分な説明のないままプッシュ通知の許諾ダイアログを表示します。しかしサービス内容がまだ分からない段階では、「とりあえず許可しない」「内容を確認してから考える」と判断するユーザーが少なくありません。
最近では、こうした”藪から棒”的な許諾の取り方に課題を感じ、アプリのオンボーディング時にプッシュ通知に関して説明をした上で許諾ダイアログを出すなどの工夫をしているアプリも多く見かけるようになりました。
これと同じことがPWAでの「ホーム画面へのアイコン追加」、「プッシュ通知」にも言えます。ホーム画面にアイコンを追加すること、プッシュ通知を受け取ることでユーザーにどんな価値、どんなメリットがあるのかを伝えられないと、ユーザーにアクションを起こしてもらえず、ユーザーとの接触機会増加のチャンスを逃してしまうことにつながりかねません。タイミングも含め、ユーザーにどのようにホーム画面へのアイコン追加、プッシュ通知の許可を促すのかが、PWA対応においても非常に重要なポイントになります。
そこで、今回はPWA対応しているサービス(サイト)でのホーム画面へのアイコン追加方法と、プッシュ通知許諾の取得方法を調べてみました。今後PWA対応を検討される際の参考にしていただければと思います。
「アイコン追加」・「プッシュ通知許諾」メッセージの表示パターン
30サイトの調査では、アイコン追加・プッシュ通知許諾ともに、メッセージなし・自動表示・工夫ありの3パターンに分類できました。
今回は海外のサービスを中心に30のサイトについて、「ホーム画面へのアイコン追加」を促す方法と、「プッシュ通知」の許諾の取得方法を調査しました。ここで紹介するに当たり、それぞれ以下のパターンに分類してみました。
|
ホーム画面へのアイコン追加 |
プッシュ通知 |
|
|
パターン① |
メッセージ表示なし(ユーザーが自発的にブラウザメニューから設定) |
許諾のメッセージなし(またはプッシュ通知配信なし) |
|
パターン② |
サイト閲覧時にデフォルトでメッセージを画面下部に自動表示 |
サイト閲覧開始直後にブラウザ固有の許諾ダイアログを自動表示 |
|
パターン③ |
アイコン追加を促す方法に工夫がある |
許諾取得の方法に工夫がある |
「ホーム画面へのアイコン追加」については、調査した中では、ブラウザ固有のアイコン追加ダイアログを自動表示するパターンが大多数でした。アイコン追加を促す方法に工夫をしているサイトが2サイトありましたが、現状ではユーザーが閲覧開始をした早い段階でブラウザ固有のアイコン追加ダイアログを自動的に表示させる方式が最も一般的といえるでしょう。逆にアイコン追加の方法には今後工夫のし甲斐があるともいえると思います。
「プッシュ通知」については、調査した30のサイトの中の半数超がプッシュ通知配信を行っていない状況でした。プッシュ通知配信を行っているサイトでは、ブラウザ固有の許諾メッセージを自動表示するパターンが5サイト、許諾の取得方法に工夫をしているパターンが8サイトという状況で、先に触れたプッシュ通知の許諾取得における課題を認識しPWAでも対応しているサイトが一定数あることがわかりました。
なお、この調査は2018年時点のものです。前章で解説したとおり、iOSではページ読み込み時に許諾ダイアログを自動表示することができないため、iOSも対象に含めて設計する場合は、パターン③にあたる「価値を説明してから許可を求める」方式を前提に考える必要があります。
尚、今回調査した具体的な30のサイトは以下になります。
![]()
今回調査した全30サイトの事例は、以下の記事で紹介しています。併せてご覧ください。
PWA対応サイトの「アイコン追加」・「プッシュ通知許諾」の事例
ここからは、アイコン追加とプッシュ通知許諾のそれぞれについて、パターン別に代表的な事例を紹介します。
ホーム画面へのアイコン追加の促し方
パターン①:アイコン追加メッセージの自動表示なし
ホーム画面へのアイコン追加に関して、特段それを促すメッセージを表示しないパターンです。ホーム画面にアイコンを追加するには、ユーザーが自らブラウザメニュー内の「ホーム画面に追加」メニューを介して設定する必要があります。
![]()
(日経電子版:https://r.nikkei.com/)
パターン②:ブラウザ固有のアイコン追加メッセージを自動表示
サイト閲覧時にデフォルトでホーム画面へのアイコン追加メッセージを画面下部に自動表示するパターンです。ブラウザ固有のダイアログが表示されます。
![]()
(Billing Gazette:https://billingsgazette.leeaws.com/pwa/index.html#top-stories)
(Alibaba.com:https://m.alibaba.com/)
パターン③:アイコン追加を促す方法に工夫あり
パターン②のようにデフォルトでブラウザ固有のダイアログのみを自動表示するのではなく、ホーム画面にアイコン追加を促す方法に工夫がをしているパターンです。
![]()
上記のFlipkartの場合、デフォルトでアイコン追加のダイアログを出さず、代わりに画面上部中央の「+」ボタンがブルブル震えることでユーザーの注目を引きます。気づいたユーザーが「+」ボタンをタップして初めてアイコン追加のダイアログが表示されます。この時点でユーザーがアイコンを追加すればそれで終了ですが、アイコン追加を拒否した場合、「+」ボタンが再度ブルブルと震えます。先ほども触れたとおり、アイコン追加のダイアログは一度拒否されると一定期間再表示されないため、ユーザーが2回目以降に「+」ボタンをタップした場合は、どのようにホーム画面にアイコンを追加すればいいかの説明が表示され、ブラウザメニューからのアイコン追加に誘導します。
ユーザーが初めてサイトを訪問した際に、サイトの中身を十分に理解していない状況で早々にホーム画面へのアイコン追加メッセージを表示して拒否されるリスクを取る代わりに、少し控えめに「+」ボタンに注目を引くことによって、ホーム画面へのアイコン追加をしてもらえる可能性を高めている例と言えます。また、初回のアイコン追加が拒否された場合の対応も考えられており、ユーザーによるアイコン追加の確実性をより高める工夫がされています。
(Flipkart:https://www.flipkart.com/?start_url=homescreenicon)
![]()
上記のSelioの場合も、Flipkart同様デフォルトでアイコン追加のダイアログを出さず、代わりにホーム画面にアイコンを追加することによるメリットを説明したダイアログを表示させています。例えば、リテラシーのさほど高くないユーザーなど、いきなり「ホーム画面に追加」とだけ記載されたブラウザ固有のメッセージが表示されても意味を理解できず、とりあえず拒否してしまうことも多いと思います。そうしたリスクを低減するために、事前に、ホーム画面にアイコンを追加することでユーザーにどんないいことがあるのかを説明し理解してもらうことで、アイコン追加の可能性を高めている例といえます。あらゆるレベルのユーザーを考慮し工夫していると思います。
(Selio:https://pt.selio.com/homescreen?utm_source=direct&utm_medium=homescreen)
この2つの事例で使われている「ブラウザ標準のダイアログをいきなり出さず、先に価値を伝える」という考え方は、iOSでプッシュ通知を配信する際にはそのまま必須の設計になります。iOSではホーム画面への追加が通知配信の前提条件となるため、アイコン追加の段階でユーザーに納得してもらう設計が、そのまま通知施策の成否を左右します。
プッシュ通知配信許諾の取得方法
パターン①:許諾メッセージの自動表示なし
プッシュ通知配信許諾のメッセージを自動表示しないパターンです。プッシュ通知を受け取るためには、ユーザーが自らサイトメニュー等のプッシュ通知設定で配信を許可する必要があります。
![]()
(日経電子版:https://r.nikkei.com/)
パターン②:ブラウザ固有の許諾メッセージを自動表示
サイト閲覧開始直後にプッシュ通知配信に関するブラウザ固有の許諾ダイアログを自動表示するパターンです。
![]()
(cnet:https://www.cnet.com/?homepage=1&setDevice=mobile)
(Roman:https://www.romanoriginals.co.uk/?utm_source=web_app_manifest&utm_medium=web_app_manifest)
※前述のとおり、この自動表示方式はiOSでは利用できません。iOSも対象とする場合は、パターン③の方式を採用してください。
パターン③:プッシュ通知許諾の取得方法に工夫あり
パターン②のようにデフォルトでブラウザ固有のダイアログのみを自動表示するのではなく、プッシュ通知配信の許諾の取得方法に工夫をしているパターンです。
![]()
上記はエールフランスのプッシュ通知許諾取得の事例です。デフォルトでブラウザ固有のプッシュ通知許諾ダイアログを表示する代わりに、トップページ内にプッシュ通知の内容を説明したコンテンツを掲載し、そこからプッシュ通知配信許諾に誘導しています。「●●が通知を送信しようとしています」とだけ記載された無味乾燥なブラウザ固有のメッセージをいきなり表示するよりも、どんな内容の通知が送られるのか、ユーザーにどんな価値があるのかを事前に説明した上で許可を取る方が確実性が高いですし、先にも触れたとおり、ブラウザ固有のメッセージ表示は1回だけのチャンスなので、こうした工夫はプッシュ通知の許諾を得る上で非常に有効だと思います。
尚、プッシュ通知配信登録を完了した際にはページ上にその旨が表示されますが(右下の画面)、他のページに遷移して再度トップページに戻るとこのメッセージは表示されません。
(Air France:https://mobile.airfrance.fr/?fromHomeScreen=true)
![]()
Twitterもエールフランス同様、デフォルトでブラウザ固有のプッシュ通知許諾ダイアログを表示する代わりに、タイムライン内にプッシュ通知の説明を掲載し、そこからプッシュ通知配信許諾に誘導しています。
(twitter:https://mobile.twitter.com/)
![]()
上記はLancomeの例ですが、こちらもエールフランス同様、デフォルトでブラウザ固有のプッシュ通知許諾ダイアログを表示する代わりに、画面下部にプッシュ通知の説明を掲載したダイアログを表示し、そこからプッシュ通知配信許諾に誘導しています。
こうした「説明してから許可を求める」設計は、公開当時は許諾率を高めるための工夫という位置づけでしたが、iOSが対応した現在では、iOS向けの実装要件を満たすための標準的な作法になっています。
(Lancome:https://www.lancome-usa.com/homepage?homescreen=1)
さいごに
PWAのメリットを活かせるかどうかは、ユーザーがアイコンを追加しやすく、プッシュ通知を許可しやすい状態をつくれるかで決まります。
今回はPWAの「ホーム画面へのアイコン追加」と「プッシュ通知」に焦点を当て、ユーザーがこれらを利用するための手続きについて事例を交えて紹介しました。
PWA対応による「ホーム画面へのアイコン追加」と「プッシュ通知」はうまく活用することでユーザーとの接触機会の増加を期待できますが、それは飽くまでユーザーが実際に”アイコンを追加した”、”プッシュ通知を許可した”場合に限られることは言うまでもありません。従って、ユーザーがアイコンを追加しやすい状態、プッシュ通知を許可しやすい状態をいかに構築するかが非常に重要なポイントになります。
iOSがプッシュ通知に対応したことで、PWAは iPhone・Androidの双方でユーザーとの継続的な接点を持てる選択肢になりました。一方でiOSでは、ホーム画面への追加が通知配信の前提条件であり、許可を求めるタイミングもユーザー操作起点に限られます。本記事で紹介したUIの工夫は、いまやPWAを成立させるための必須要件といえます。
今後PWA対応を検討される際には、PWAのメリットを最大限活かせるよう、是非今回紹介した事例を参考にしていただければと思います。
関連する記事
pagetop