PWAのstart_urlは何を指定すべき？トップ・現在ページ・専用URLの違い

PWAのWeb App Manifestには、start_url という項目があります。

名前だけを見ると簡単です。

ホーム画面のアイコンからPWAを起動した時に、最初に開くURLを指定します。

でも実際にPWAを作り始めると、ここで意外と悩みます。

サイトのトップを指定するのか。今見ているページを開くのか。それともPWA専用のURLを作るのか。

さらに、私がPWA LABで使っている start_url: "." のような設計もあります。

今回は、それぞれの違いを「どこへ戻したいPWAなのか」という視点から整理します。

start_urlはホーム画面から起動した時の入口

まず基本から確認します。

例えばManifestが次のようになっているとします。

{
  "name": "Example App",
  "start_url": "/",
  "display": "standalone"
}

この場合、ホーム画面からPWAを開いた時の起点は / です。

つまり、どのページでホーム画面追加を案内したとしても、PWAの入口としてはサイトのトップを使う設計になります。

start_url は単なる設定値ではなく、そのPWAを何への入口として扱うかを決める項目です。

一番分かりやすいのはサイトトップを指定する方法

従来のPWAでよく見るのが、サイトトップを指定する形です。

"start_url": "/"

例えばニュースサイト、SNS、ECサイト、Webサービスなど、サイト全体を1つのアプリとして扱うなら分かりやすい設計です。

記事ページからホーム画面へ追加しても、商品ページから追加しても、最終的には同じアプリのトップへ戻る。

私はこの考え方を、1S1A（One Site. One App.）として整理しています。

サイト全体
↓
1つのPWA
↓
起動するとサイトの入口へ戻る

サイトそのものをアプリとして見せたいなら、この形は自然です。

PWAの二極化：トップへ還る「1S1A」と、全ページをアプリ化する「1P1A」でも、この違いを詳しく整理しています。

OJapp Tips｜合わせて読みたい
SafariでPWAが使えない理由｜iPhoneで動かない本当の原因を解説【2026年版】 の解説が役に立ちます。

でも、ユーザーが戻りたいのは本当にトップページなのか

ここで少し考えてみます。

例えばユーザーが、Web上の5分タイマーを気に入ってホーム画面へ追加したとします。

その人が次に開きたいのは、サイトのトップページでしょうか。

たぶん違います。

5分タイマーそのものを開きたい。

同じことは、商品ページや予約ページ、プロフィール、管理画面、画像圧縮ツールなどにも言えます。

目的のページをホーム画面へ置いたのに、起動すると毎回サイトトップへ戻される。

それでは、ホーム画面に置いた意味が少し薄くなります。

特定ページをstart_urlに固定する方法

それなら、目的のページを直接指定する方法があります。

"start_url": "/timer/"

このPWAをホーム画面から開けば、毎回 /timer/ から始まります。

専用ツールやログイン後のダッシュボードなど、そのPWAの入口が最初から決まっている場合には使いやすい方法です。

例えば、

• 社内用管理画面
• 予約専用ページ
• Webツール
• 会員ページ

のように、アプリとして開かせたいURLが明確なら固定URLで問題ありません。

問題はページがユーザーごとに変わる場合

少し難しくなるのが、ホーム画面へ追加したいページが最初から決まっていない場合です。

例えばプロフィールサービスなら、

/user/alice
/user/bob
/user/charlie

のようにユーザーごとにURLが変わります。

商品ページなら、商品ごとにURLが違います。

ここで静的なManifestに、

"start_url": "/user/alice"

と書いてしまうと、Alice用のManifestになってしまいます。

Bobのページでは別のManifestが必要です。

ページ数が増えるほど、管理が面倒になります。

そこで使えるのが start_url: “.”

PWA LABで私が特に面白いと感じたのが、相対URLの . です。

"start_url": "."

. は相対URLです。

重要なのは、ManifestのURLを基準に解決されるという点です。

つまり、静的な /manifest.json をサイト全体で共通利用している場合、単純に . と書けば「今見ているページ」が自動的に入るわけではありません。

ここはかなり大事です。

私が1P1Aで start_url: "." を使えているのは、ページごとに動的なManifestを生成し、そのページを基準に相対URLを成立させているからです。

start_url: “.” が最強説｜PWAで“入れたページに戻る”を成立させる考え方では、この仕組みを実験ベースで詳しく書いています。

動的Manifestならページごとの入口を作りやすい

例えば、ユーザーが次のページを開いていたとします。

https://example.com/tools/timer/

そのページ用に動的Manifestを生成し、そこで、

"start_url": "."

とすれば、相対URLを使ってそのページを入口として扱う設計ができます。

別のページでは、別の入口になります。

/tools/timer/
↓
タイマーApp

/tools/compressor/
↓
画像圧縮App

/products/item-a/
↓
商品AのApp

Manifestをページ単位で生成できる環境では、この考え方がかなり柔軟です。

これは1P1Aと相性がいい

私はこの設計を、1P1A（One Page. One App.）という考え方にまとめています。

1S1Aでは、

どのページから追加しても
↓
同じサイトApp

と考えます。

一方で1P1Aでは、

ページA
↓
App A

ページB
↓
App B

のように、ページそのものをアプリの単位として扱います。

この場合、start_url もページごとに変わる方が自然です。

専用URLを用意する方法もある

もう1つの方法が、PWA起動専用のURLを作ることです。

例えば、

"start_url": "/app/"

として、通常のWebアクセスとは別の入口を用意します。

この方法なら、起動時にPWA向けの処理を入れたり、必要なページへリダイレクトしたりできます。

例えば、

/app/
↓
ログイン状態を確認
↓
ダッシュボードへ移動

のような設計です。

Webアプリ全体として起動フローを管理したい場合には便利です。

ただし、単純に特定ページへ戻したいだけなら、専用URLを増やすことで構成が複雑になる場合もあります。

クエリ付きURLを入口にすることもできる

さらに、URLのクエリがページの状態を表しているWebアプリもあります。

例えば、

/timer/?time=5&mode=down

というURLで5分のカウントダウンタイマーを表現しているなら、この状態をホーム画面の入口として扱う設計も考えられます。

私が実験しているUDA（User Defined App）では、このようにURLが表している状態をユーザー自身のAppとして残すという考え方まで広げています。

PWA UDA（User Defined App）とは？ユーザーが自分のAppを定義する新しい設計思想で詳しく紹介しています。

start_urlにユーザーIDを直接埋め込む必要はない場合もある

ユーザーごとのページをPWA化する時、最初に考えやすいのが、

"start_url": "/user/12345"

のようにユーザーIDをManifestへ直接書く方法です。

もちろん、それが必要な設計もあります。

ただ、動的Manifestと相対URLで成立するなら、毎回Manifestへ個別IDを組み立てなくても済む場合があります。

これはManifest生成処理をシンプルにしやすいだけでなく、URLの個別情報を必要以上にManifestへ固定しない設計にもつながります。

どれを選ぶかは「何を1つのAppと考えるか」で決まる

どれか1つが絶対に正しいわけではありません。

重要なのは、そのPWAを何のAppとして設計するのかです。

サイトをAppにするならトップ、ページをAppにするならそのページ

考え方をかなり単純化すると、こうなります。

サイト全体をAppにしたい
↓
サイトトップをstart_urlにする

特定ページをAppにしたい
↓
そのページをstart_urlにする

これだけです。

ところが従来のPWAでは「PWA = サイト全体をアプリ化するもの」という前提で考えられることが多かったので、start_url もサイトトップに固定されがちでした。

でもWebには、ページごとに違う役割があります。

商品、記事、ツール、プロフィール、予約、タイマー。

ホーム画面に置く価値があるのがそのページなら、起動先もそのページでいい。

start_urlは「起動URL」ではなくAppの入口設計

start_url はManifestの中ではたった1行です。

でも、その1行によってPWAの性格はかなり変わります。

トップへ戻るならサイトApp。

ツールへ戻るならツールApp。

商品へ戻るなら商品への入口。

URLの状態まで残せば、ユーザー自身が決めたAppにもできます。

start_urlを決めるということは、ユーザーが次にそのアイコンを押した時、どこへ戻すのかを決めることです。

だから私は、Manifestを書く時に最初から / を入れるのではなく、「このアイコンは何への入口なのか」を先に考える方が分かりやすいと思っています。