PWAを導入する？検討する意味すらない理由｜今や「令和版apple-touch-icon」です

「WebサイトにPWAを導入すべきか？」

PWA（Progressive Web Apps）の話をすると、なぜか急に「大がかりな開発案件」になりがちです。

サイト構造への影響は？ Service Workerは？ オフライン対応は？ SEOは？ 保守コストは？

もちろん、本格的なWebアプリをゼロから構築するなら検討することはたくさんあります。

でも、既存のWebサイトをホーム画面から使いやすくするだけなら、そこまで大げさに悩む必要は全くありません。

私はPWA LABでiPhoneとAndroidのホーム画面追加を何度も検証してきましたが、最近はむしろこう考えるようになりました。

今のPWA（ホーム画面対応）は「令和版のapple-touch-icon（Android対応・高機能版）」と考えるくらいでちょうどいい。

特に1ページを1つのアプリとして扱う「1P1A（One Page. One App.）」なら、既存サイトを大きく作り変える必要すらありません。

昔はapple-touch-iconを普通に書いていた

少し前まで、スマホ向けのWebサイトを作るときには、こんなコードを当たり前のように書いていました。

<link rel="apple-touch-icon" href="/apple-touch-icon.png">

iPhoneでWebページがホーム画面へ追加されたときに使うアイコン指定です。

これを書くためだけに、

「弊社サイトにapple-touch-iconを導入するべきでしょうか？」

なんて何時間も社内会議を開いて検討した人は、まずいないはずです。

「ホーム画面に追加される可能性があるなら、とりあえず1行書いておくか」

それくらいの軽い感覚でした。

ところが「PWA」という名前になった瞬間、なぜか話が一気に難しくなります。

PWA＝大規模なWebアプリ開発ではない

PWAという言葉には、実はさまざまな要素が含まれています。

• ホーム画面追加（インストール体験）
• standalone表示（全画面表示）
• オフライン対応
• Push通知
• キャッシュ
• Service Worker

これらを全部セットの「巨大な一つの技術」として捉えてしまうから、導入のハードルが高く見えてしまうのです。

でも、全部使う必要はありません。

例えば「ホーム画面へ追加して、アプリのように起動できればいい」という目的なら、必要な部分（ホーム画面対応）だけをチョイスすればいい。

Service Workerを使ってオフライン対応することと、ホーム画面へ追加できるようにすることは、本来まったく別の話です。

実際、PWA LABでもmanifest、Service Worker、キャッシュ戦略などを分けて検証してきました。

PWAは一枚岩ではなく、必要な機能を選んで使えるWebの仕組みとして考えた方が分かりやすいです。

※PWA全体の構成や仕組みを詳しく知りたい方は、PWAの作り方｜manifest.json・Service Worker・ホーム画面対応を丁寧に解説もあわせてご覧ください。

OJapp Tips｜合わせて読みたい
ホーム画面名刺とは？新しいつながり方「Petal」の考え方と使い方 の解説が役に立ちます。

ホーム画面対応だけなら普段のWebサイトはほぼそのまま

ここが今回一番伝えたいポイントです。

ホーム画面対応を目的としてPWAの要素を追加しても、普段ブラウザでサイトを見ている人にとっては、良い意味でも悪い意味でも100%いつものWebサイトのままです。

• ページのHTMLを全部作り直す必要はありません
• デザインやレイアウトをPWA用に変更する必要もありません
• サイトの表示速度やSEOに悪影響を与えることもありません

ユーザーが普通に検索やSNSから訪問したなら、これまで通りのWebページとして閲覧できます。

違いが出てくるのは、唯一「そのページをホーム画面へ追加したとき」だけです。

ホーム画面に専用アイコンが置かれ、そこから起動したときだけブラウザの枠線が消え、アプリ的な入口として使える。

だったら最初から、その「追加されたとき用の入口」だけを用意しておけばいい。

これが、私が「apple-touch-iconの現代版」と考えている理由です。

実はapple-touch-iconに頼る必要もなくなった

以前のiPhone向けホーム画面対応では、apple-touch-icon が必須級の存在でした。

<link rel="apple-touch-icon" href="/icon.png">

しかし現在のiOS（Safari）では、Web App Manifestの icons もホーム画面アイコンとしてしっかり利用されます。

{
 "name": "Example",
 "short_name": "Example",
 "start_url": ".",
 "display": "standalone",
 "icons": [
 {
 "src": "/icon.png",
 "sizes": "512x512",
 "type": "image/png",
 "purpose": "any maskable"
 }
 ]
}

PWA LABで実機検証済みですが、iPhoneでもmanifest側のアイコンが優先的に使用されます。

むしろ注意したいのは、既存ページに古い apple-touch-icon が残っているケースです。

iOSの仕様上、apple-touch-icon が記述されていると、manifestの icons よりそちらが優先されてしまいます。

つまり「manifest側でページ固有のアイコンを指定したのに、ホーム画面には昔設定したサイト共通の古いアイコンが出てくる」という現象が起きます。

ページごとにホーム画面アイコンを最適化したい場合、apple-touch-icon は必須どころか、むしろ邪魔になってしまうことすらあります。

泥臭い作業をすべて消し去る「1行追加」

昔のPWA化といえば、裏側で途方もない作業が必要でした。

１. デザインツールで180×180、192×192、512×512などのアイコン画像を何枚も書き出し

２. manifest.json を手動で作成し、JSONの構文エラーと戦いながらパスを指定

３. iOS用に apple-touch-icon を別で書き、Android用にmanifestを読み込む……

この「準備の面倒くささ」こそが、PWAの検討を長引かせていた元凶です。

そこでOJappが提案しているのが、「1P1A（One Page. One App.）」というアプローチです。

1P1Aは、サイト全体を1つのアプリにするのではなく、「1ページを1つのアプリ」として扱う考え方です。

導入に必要なのは、対象ページにこのスクリプトを1行追加するだけ。

<script src="https://ojapp.app/js/ojapp_1p1a.js"></script>

これだけで、そのページをホーム画面へ追加するための最適なmanifestが自動的に用意されます。

昔なら、

<link rel="apple-touch-icon" href="/apple-touch-icon.png">

と書いていた場所に、

<script src="https://ojapp.app/js/ojapp_1p1a.js"></script>

と貼っておく。

画像リサイズも、manifest.json の手動作成も不要。考える時間も作業時間も、一瞬で終わります。
さらに、apple-touch-icon はiOSのためだけに書いていましたが、これはAndroid用の記述でもあるのです。

サイトアイコンとは別にページごとに専用アイコンも指定できる

「ファビコンとは別に、この記事・この商品専用のホーム画面アイコンにしたい」という場合も簡単です。

ページに次のmetaタグを1行追加するだけで、AndroidにもiOSにも対応した高画質アイコンが適用されます。

<meta name="ojapp:icon" content="https://example.com/icon.png">

従来の apple-touch-icon は、基本的に「サイト全体で共通のアイコン」という発想でした。

1P1Aなら、

• ブログ： サイトロゴではなく「記事のアイキャッチ画像」をホーム画面アイコンに
• ECサイト： ショップロゴではなく「購入した商品画像」をホーム画面アイコンに
• Webツール： サービスロゴではなく「そのツール固有の機能アイコン」に

というように、「このページをホーム画面に置くなら、どのアイコンが一番直感的か」をページ単位でコントロールできます。

新旧コード比較：head内デトックス

長々と書きましたが、実際のコードを見比べれば一目瞭然です。

【今までのhead（地獄の記述＋画像とJSON作成が必要）】

<link rel="icon" href="/favicon.ico">
<link rel="icon" type="image/png" sizes="180x180" href="/icon/icon-180.png">
<link rel="apple-touch-icon" sizes="180x180" href="/icon/icon-180.png">
<link rel="manifest" href="/manifest.json">

【現代（OJapp時代）】

<link rel="icon" href="/favicon.ico">
<script src="https://ojapp.app/js/ojapp_1p1a.js"></script>

(※サイト全体で1つのアプリにしたい場合は ojapp_1s1a.js を貼るだけ)

ファビコンを1行置いて、スクリプトを1行貼る。以上です。

アイコン画像（ojapp:icon）を省略した場合は、自動的に既存のファビコンを拾ってフォールバック処理してくれるため、本当にこれだけで機能します。

あの何種類もの画像切り出しと、manifest.json の構文チェックに追われていた時間は一体何だったのかと思うレベルの差です。

1P1Aについては、1P1A（One Page. One App.）というPWA設計思想と合わせて読むと、この違いが分かりやすいと思います。

既存サイトを壊さない「あえてService Workerを同梱しない」安心感

ここでWebエンジニアの方なら、「え、Service Worker（キャッシュ制御）の処理はどうなってんの？」と疑問に思うかもしれません。

結論から言うと、この1行スクリプトにはあえてService Workerを同梱していません。

なぜなら、強引なキャッシュ制御は、既存サイトの表示が更新されなくなったり、本番のシステムとバッティングして事故を起こす最大の原因になるからです。

• 1行スクリプト（OJapp）： 面倒なアイコン指定・manifest自動生成・ホーム追加動線という「フロントの表示」をリスクゼロで解決する

• 自社開発： オフライン表示やキャッシュ制御が必要になった場合のみ、サイトの仕様に合わせてエンジニアが安全にSWを構築する

この割り切りがあるからこそ、「導入しても既存サイトの動作を1ミリも邪魔しない」「バグらない」と言い切ることができます。

PWAは「検討する技術」から「貼っておくもの」へ

ここまで考えると、「PWAを導入すべきか？」と何時間も会議で悩むこと自体が、少し勿体なく思えてきませんか？

例えばブログ記事に1P1Aの1行タグを追加したからといって、突然そのブログが複雑なWebアプリに化けるわけではありません。

普段は、今まで通りのシンプルなWebページです。

ただ、その記事や商品を気に入った人が「ホーム画面に追加」を押したときだけ、専用アイコンを持ったアプリライクな入口になる。

Webはもともと 1URL = 1コンテンツ です。

検索もブックマークもSNS共有もページ単位なのに、ホーム画面だけ「サイト全体を1つのアプリにする」と大げさに考える必要はありません。

まとめ

もちろん、Push通知をゴリゴリに飛ばしたり、完全オフラインで動く高度なWebアプリを作るなら、相応の設計と検討が必要です。

でも、「ユーザーがホーム画面からサクッと戻ってこられる入口を作る」という目的において、PWAはもう何時間も検討するようなハードルの高い技術ではありません。

昔 apple-touch-icon をとりあえず書いていた場所に、現代の1行タグをコピペしておく。

それくらいの軽やかな感覚で、今すぐ試してみてはいかがでしょうか？😊✨

公式サイトでは、実際に導入しているホーム画面追加の体験をしていたたけます。
キーボードF12DevToolからの記述も確認できますので、PC,Android,iOS,iPhoneで実際の挙動を試してみてください😊

1P1A公式サイト：https://ojapp.app/one-page-one-app/