Edge 147 Web プラットフォームで追加された Web App Origin Migration は、PWA の“引っ越し”を「再インストール前提」から「ブラウザ主導の安全な更新フロー」へ変える機能です。2026年4月10日に公開された Stable 147.0.3912.60 に対応する Edge 147 の Web プラットフォーム ノートでは、この機能が Web APIs の追加項目として掲載され、PWA を新しいオリジンへ移しつつインストール状態を保てると説明されています。従来のように www.example.com/app から app.example.com へ移すたびに、ユーザーへアンインストールと再インストールを案内する必要を減らせるのが最大の価値です。 (Microsoft Learn)
ただし、何でも移せるわけではありません。関連仕様では、基本は同一サイト内のオリジン移行を前提にし、旧オリジンの明示的な許可と manifest 設定が必要です。この記事では、Edge 147 Web プラットフォームで何が変わったのか、Web App Origin Migration の仕組み、実装例、見落としやすい制約、実務での導入手順まで順に整理します。 (WICG)
Edge 147で追加された Web App Origin Migration とは
今回追加された Web App Origin Migration が解決するのは、PWA の“住所変更”です。これまで PWA はオリジンに強く結びついていたため、リブランディング、サブドメイン分離、アーキテクチャ変更などでホスト先を変えると、旧アプリが壊れる、通常のブラウザタブで開いてしまう、ユーザーが手動で入れ直す必要がある、といった問題が起こりやすい状態でした。関連 explainer でも、この課題が機能追加の主な動機として示されています。 (GitHub)
しかも問題は単純なドメイン移転だけではありません。manifest に明示的な id がないまま start_url を変えると、同じサービスなのに別アプリとして二重にインストールされる“split apps”のような状態も起こりえます。Web App Origin Migration は、こうした古いインストールを新しい正しいアプリへ寄せるための仕組みとしても期待されています。 (GitHub)
まず押さえるべき適用範囲
まずは、できることとできないことを一枚で押さえると理解が速いです。下の表は Microsoft Learn と関連仕様・explainer を実務目線で整理したものです。 (Microsoft Learn)
| 項目 | 実務での判断 |
|---|---|
| Edge 147 でPWAのオリジン移行フローを作れるか | できる |
www.example.com → app.example.com のような同一サイト内の移行 | 対象 |
example.com → another-site.com のような別サイト移行 | 対象外 |
新アプリ側の migrate_from と明示的な id | 必須 |
旧オリジン側の /.well-known/web-app-origin-association | 必須 |
旧アプリ側の migrate_to | 任意だが有効 |
| IndexedDB / Cache Storage のローカルデータ | 自動移行を期待しない |
要点だけ言えば、再インストールなしの移行は可能だが、別サイトへの引っ越しまで自動化する機能ではない、ということです。新側の manifest、旧側の .well-known、必要に応じた旧側 manifest の更新が3本柱になります。 (WICG)
Web App Origin Migration の仕組み
Web App Origin Migration は、単なるリダイレクトではなく、新旧オリジンが相互に合意する“ハンドシェイク”として設計されています。移行は、新URLにユーザーが来た場合にも、旧アプリの更新チェック時にも検知できる想定です。 (GitHub)
新アプリの manifest に migrate_from を入れる
新しいオリジン側では、manifest に migrate_from を追加して「自分はこの旧アプリの後継です」と宣言します。このとき、新 manifest には明示的な id が必要です。 id が曖昧だと、どのアプリを引き継ぐのか判定が不安定になるからです。 (WICG)
{
"name": "New App",
"id": "/",
"start_url": "/",
"display": "standalone",
"migrate_from": [
{
"id": "https://old.example.com/app/",
"install_url": "https://old.example.com/install"
}
]
}これは概念例ですが、実運用では id を将来も変えにくい安定値にしておくのが重要です。
旧オリジンで /.well-known/web-app-origin-association を公開する
旧オリジン側では、/.well-known/web-app-origin-association を置いて、新アプリへの移行を明示的に許可します。仕様では、このファイルがないと別のアプリが勝手に後継を名乗るリスクを防げないため、クロスオリジンの same-site 移行では核心となる要素です。 (WICG)
{
"https://new.example.com/": {
"allow_migration": true
}
}旧アプリ側の manifest に migrate_to を追加する
旧アプリ側の manifest に migrate_to を入れるのは必須ではありませんが、先回りして移行を知らせたいときに有効です。ユーザーが新URLへ直接来なくても、旧アプリの更新経由で移行を見つけやすくなります。 (GitHub)
{
"name": "Old App",
"id": "/app/",
"start_url": "/app/start",
"display": "standalone",
"migrate_to": {
"id": "https://new.example.com/",
"install_url": "https://new.example.com/install"
}
}suggest と force をどう選ぶか
移行時のユーザー体験は behavior で調整できます。関連 explainer では、suggest は通知するが無視でき、force は次回起動時に「移行するか、アンインストールするか」を求める設計です。 (GitHub)
behavior | 向いているケース | 実務での注意 |
|---|---|---|
suggest | 数週間の並行運用をしたい | すぐに全ユーザーが移るとは限らない |
force | 旧環境を早めに止めたい | 起動時の負荷が高く、説明不足だと反発が出やすい |
迷うなら、旧バックエンドをしばらく残せるなら suggest、セキュリティや運用都合で早期停止が必要なら force が現実的です。ただし force では、名称やアイコンなどの安全性に関わる変更が別更新へ後送りされる想定も示されているため、「URL変更」と「ブランド刷新」を一度に押し込まないほうが無難です。 (GitHub)
実装で外しやすいポイント
301/302 リダイレクトだけで終わらせない
よくある失敗が、「旧URLを全部 301 にすれば十分」と考えることです。explainer では、リダイレクトだけだとユーザーが最初から新URLへ来た場合に移行検知ができない、suggest のような段階移行とも相性が悪い、と整理されています。さらに旧側を全面リダイレクトすると、移行前に必要な旧 manifest 更新を取得できなくなるため、必要に応じてリダイレクトしない install_url を残す設計が勧められています。 (GitHub)
本番では、「通常のユーザーアクセスは新URLへ送るが、ブラウザが旧 manifest を取得できる専用エンドポイントは残す」という分け方が実務向きです。
id を固定しないと「別アプリ」が増える
id を後回しにするのも危険です。関連 explainer では、過去には start_url がPWAの識別に使われがちで、開始パスを変えただけで別アプリ扱いになり、古いアイコンと新しいアイコンが共存する問題が起きうると説明されています。移行を機に id を明示し、今後も変えない前提で固定するのが基本です。 (GitHub)
権限は再確認前提で設計する
権限まわりは、楽観視しないほうが安全です。Microsoft Learn の Edge 147 ノートでは「install state, and applicable permissions」という要約がありますが、関連 explainer では初期版のクロスオリジン移行は新しいエンティティとして扱い、通知や位置情報などは新オリジン側で再許可を求める前提が示されています。実務では「インストール状態は引き継がれても、通知許可は再確認されるかもしれない」と考え、初回起動時の案内文や再許可導線を用意しておくのが安全です。 (Microsoft Learn)
ローカルデータ移行はブラウザ任せにしない
ローカルデータ移行もブラウザ任せにはできません。explainer では、IndexedDB や Cache Storage などのローカル保存データはこの機構の対象外で、開発者が別途移行設計を担う想定です。ログイン後にサーバー同期で再構成するのか、初回起動で移行APIを叩くのか、あるいは旧版をしばらく並行運用するのかは、事前に決めておく必要があります。 (GitHub)
強制移行でブランド変更まで同時に押し込まない
強制移行を使うときに、URL変更、アプリアイコン変更、アプリ名変更を一気に入れたくなることがあります。ですが関連 explainer では、force 移行時に名称やアイコンのような安全性に関わる変更は別更新として扱う考え方が示されています。ユーザーの立場では「URLも見た目も一気に変わる」ほうが不信感につながりやすいので、段階を分けるほうが実務では成功しやすいです。 (GitHub)
実は「ドメイン移転」以外にも使い道がある
この仕組みは、サブドメイン移転だけのためではありません。関連 explainer では、同一オリジンのまま id を正したり、誤って分裂した複数のPWAを整理したりする same-origin migration にも使えると説明しています。この場合はオリジン自体が変わらないため、.well-known ファイルは不要で、ユーザーUIなしのサイレント移行が想定されています。 (GitHub)
たとえば、www.example.com/social を social.example.com に切り出すケース、photo-app.example.com を photos.example.com/app に寄せるケース、mail.example.com を app.example.com に統合するケース、start_url 変更で増えてしまった二重インストールを整理するケースでは、Edge 147 の Web App Origin Migration が特に効きます。単なる見た目の変更ではなく、URL再設計とPWA配布体験の両方を同時に整える機能だと考えると分かりやすいです。 (GitHub)
Edge 147時点での導入チェックリスト
導入前に確認したいポイントを、最短ルートで並べると次の順番です。
- 現行の移行が same-site か判定する。別サイトへの移行なら、この機構では扱えません。 (WICG)
- 新 manifest に明示的な
idとmigrate_fromを入れる。ここが移行宣言の出発点です。 (WICG) - 旧 origin に
/.well-known/web-app-origin-associationを配置して、新アプリへの移行を許可する。 (WICG) - 旧アプリ側には必要に応じて
migrate_toと、リダイレクトしないinstall_urlを用意する。 (GitHub) suggestとforceを、旧環境の停止計画とユーザー負荷のバランスで決める。 (GitHub)- 通知・位置情報などは再許可が出ても破綻しないUIにする。権限の自動引き継ぎを前提にしない。 (GitHub)
- IndexedDB / Cache Storage などのローカルデータ移行を別設計する。 (GitHub)
- テストは「旧PWAを起動する導線」と「新URLに直接来る導線」の両方で行う。仕様上、移行検知は両経路を想定しています。 (GitHub)
まとめ
Edge 147 の Web App Origin Migration は、PWA を再インストール前提で移す時代から一歩進める機能です。とくに同一サイト内でのサブドメイン化、URL設計の見直し、split apps の整理では効果が大きく、migrate_from、旧側 .well-known、必要に応じた migrate_to をそろえることで、より安全な移行フローを作れます。反対に、別サイト移行、ローカルデータの自動移送、権限の完全引き継ぎまで期待すると設計を誤ります。 (Microsoft Learn)
次にやるべきことは明確です。いま使っている PWA の id、start_url、リダイレクト、通知権限、ローカルデータ保存場所を棚卸しし、same-site で移せるなら検証環境で Web App Origin Migration を試す。ここまで決めてから本番移行に入ると、ユーザーに“入れ直し”を求める確率を大きく下げられます。 (WICG)
コメント