はじめに

スマートフォンのブラウザにある「ホーム画面に追加」を、最後に真面目に検討したのはいつでしょうか。

数年前、Webサイトをアプリのようにインストールして使う仕組みが「Progressive Web Apps（PWA）」という名前で大きく注目されました。ただ、実際に試した人ほど、Service Workerの設定の手間や、iOSで動かない機能の多さに直面し、話題は次第に落ち着いていきました。

このPWAの特徴として当初から挙げられていたものの1つが、アプリストアを介さずホーム画面に置いて使えること、つまり「インストールできること」でした。その入り口が、ブラウザの「ホーム画面に追加」です。この記事では、ホーム画面に追加してアプリとして起動するサイトを「インストールされたWebアプリ」と呼びます。

「ホーム画面に追加」は、ブックマークをホーム画面に置く程度の機能、という認識で止まっている人も多いはずです。

ところが、この数年で状況は静かに変わっています。2023年のiOS 16.4でiPhoneでもインストールされたWebアプリからプッシュ通知とアイコンバッジが使えるようになり、2025年に登場したiOS 26からは、ホーム画面に追加したサイトがすべてインストールされたWebアプリとして起動するようになりました。

このシリーズでは、「ホーム画面に追加」でできることを、2026年時点の最新の情報であらためて押さえます。1回目の今回は、ホーム画面に追加されたサイトで何が起こるのか、そしてどんな条件でアプリとして扱われるのかを見ていきます。2回目でプッシュ通知とアイコンバッジの実装を、3回目でこの仕組みの弱点と、どんなサービスに向いているのかを扱います。

ホーム画面に追加するとどうなるのか

まず、操作そのものを確認しておきます。iOSのSafariでは共有メニューから、Android版Chromeではメニューから「ホーム画面に追加」を選ぶと、サイトのアイコンがホーム画面に置かれます。ここまでは多くの人が知っているとおりです。

問題は、そのアイコンをタップしたときに何が起こるかです。

ブラウザのタブが開くだけなら、それはブックマークです。しかし条件を満たしたサイト（条件については後述します）は「アプリとして起動」します。

「アプリとして起動する」とは、単にアドレスバーが消えることではありません。OSがそのサイトをブラウザのタブの1つではなく、独立した1つのアプリとして登録し、専用のウインドウで開く状態を指します。具体的には、次の3つの変化が起こります。

見え方が変わる

アドレスバー、タブ切り替え、戻る・進むボタン、リロード、共有ボタンといったブラウザのUIがすべて表示されなくなり、サイト全体がフルスクリーンで表示されるようになります。

ユーザーから見ると、ネイティブアプリと区別がつかない見た目です。

裏返すと、ユーザーはURLを見て今どのサイトにいるかを確認できず、リロードもできません。ブラウザの戻るボタンも消えるので、画面内の遷移や戻る手段、エラー時のリカバリはサイト側で用意する責任が生じます。

OSからの扱いが変わる

通常、Webサイトはブラウザ内のタブとして並びますが、ホーム画面に追加すると、アプリスイッチャーに並ぶようになります。

iOSでは、インストールされたWebアプリが設定アプリのアプリ一覧にネイティブアプリと同じように並びます。ユーザーはここから通知の許可などを管理できます。

Androidでは、アプリとしてインストールするか、ホーム画面上のChromeのショートカットにするか選択することができます。アプリとしてインストールを選択すると、アプリと同等に扱われます。

インストールされたWebアプリは実際のアプリパッケージ（WebAPK）としてインストールされるため、ほかのアプリでそのサイトへのリンクをタップするとインストールされたWebアプリ側で開きます。

マニフェストで設定すれば、アイコンの長押しメニューや、ほかのアプリの共有先にもなれます。

使える機能が変わる

iOSでは、プッシュ通知とアイコンバッジはインストールされたWebアプリでしか使えません。

Safariのタブで開いている状態では、通知の許可を求めることすらできません。この2点は次回で詳しく扱います。

インストールされたWebアプリとして扱われる条件

では、どんなサイトが「アプリとして起動」するのでしょうか。その鍵になるのが、Webアプリマニフェスト（Web App Manifest）です。

これはアプリとしての名前、アイコン、起動したときに開くURL、表示モードなどの情報をまとめたJSONファイルで、ブラウザがサイトを「アプリ」として扱うときの説明書にあたります。

ファイル名はmanifest.jsonかmanifest.webmanifestが一般的で、HTMLのhead要素内のlink要素で指定します。

ブラウザは「ホーム画面に追加」を実行したページのhead要素を見るため、このlink要素はすべてのページに入れておきます。

<head>
  <!-- ... -->
  <link rel="manifest" href="/manifest.json">
</head>

iOSでは、ホーム画面に置かれる名前、アイコン、起動URLが追加した時点の内容で固定されます。公開したあとにアイコンや名前を変えても、すでにアプリとして追加したユーザーのホーム画面には反映されず、削除して追加し直してもらう必要があります。

Androidでは、インストールされたWebアプリの起動をきっかけとして、24時間に1回の頻度でマニフェストの変更を確認します。名前やアイコン、start_urlなどが変わっていれば、Webアプリを閉じたあと、端末が充電中でWi-Fiに接続されたタイミングで更新されます。Chromeの公式ブログによると、名前やアイコンが変わった場合は、起動中に確認のダイアログが表示され、ユーザーが承認してから更新されます。

iOSのように固定はされませんが、すぐには反映されません。

なお、ここで挙げた更新の条件やタイミングは、端末の状態やブラウザのバージョンにも左右されるため、環境によって異なる場合があります。

このマニフェストをどう扱うかが、iOSとAndroidで異なります。

iOSではホーム画面に追加したサイトはすべてインストールされたWebアプリになる

iOS 26では、アプリとして起動するかどうかの判定にマニフェストを使いません。ホーム画面に追加したサイトは、マニフェストがなくてもすべてインストールされたWebアプリとして開きます。ただし、マニフェストが無視されるわけではなく、アプリの名前やアイコンには引き続きマニフェストの内容が使われます。

iOS 18以前は、マニフェストのdisplay（standaloneなど）や専用のmetaタグを指定したサイトだけがインストールされたWebアプリとして開き、それ以外はブックマーク扱いでした。iOS 26でこの条件はなくなりましたが、iOS 18以前の端末では今もこの条件が有効です。

条件がなくなった代わりに、追加時のシートには「Webアプリとして開く」というトグルボタンが用意され、ブラウザで開きたい人はユーザー側でオフにできます。

Androidではマニフェストの条件を満たすとインストールになる

Androidでは、今もマニフェストの内容がアプリとして起動するかどうかの条件です。HTTPSで配信され、マニフェストにname（またはshort_name）、start_url、browser以外のdisplay、192pxと512pxのiconsがそろっているサイトだけが、アプリとしてインストールされます。

条件を満たさないサイトは、ブラウザで開くショートカットになります。

つまり、両方のプラットフォームでアプリとして起動させるには、結局Androidの条件を満たすマニフェストを用意することになります。最小限の構成は次のとおりです。

{
  "name": "CodeGrid Reader",
  "short_name": "Reader",
  "start_url": "/",
  "display": "standalone",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

なお、以前のChromeが条件にしていたService Workerの登録は、今は不要です。

ただし次回扱うプッシュ通知ではService Workerが必要になります。

マニフェストで指定できるほかの項目についてはMDNのWeb app manifestを参照してください。

まとめ

今回は、「ホーム画面に追加」したサイトに何が起こるのかを見てきました。

以前から知っていた人も、iOS 26でユーザーがどのサイトでもアプリとして開けるようになったことや、iOSではマニフェストの名前とアイコンが追加時点で固定されることなど、知らない部分があったのではないでしょうか。

次回は、アプリとして起動したサイトだからこそ使える、プッシュ通知とアイコンバッジの実装を見ていきます。