Microsoft Edge PWAのオリジン移行とは？Edge 150の期限・対象・実装手順

Microsoft Edge Progressive Web Apps（PWA）の「same-site origin migration」は、PWAの廃止や強制的な仕様変更ではありません。Microsoft Edge 150で追加された、インストール済みPWAを同一サイト内の別オリジンへ移行するための機能です。

たとえば、https://www.example.com/app/で提供していたPWAをhttps://app.example.com/へ移す場合、従来はユーザーによるアンインストールと再インストールが必要でした。新しい仕組みでは、移行元と移行先が相互に許可することで、インストール状態を維持したまま更新フローとして移行を案内できます。

2026年7月12日時点で、Microsoftから移行期限や旧方式の廃止日は発表されていません。対応が必要なのは、主にEdgeでインストールされているPWAのサブドメイン変更やURL構成変更を予定している運営者です。通常のWebサイトだけを提供している場合や、オリジンを変更しない場合は、原則として直ちに対応する必要はありません。

Microsoft Edge Blogの掲載日は2026年7月7日で、日本時間では7月8日時点の更新情報として確認できます。公式記事では、同一サイト内の新しいオリジンへ、ユーザーのインストール状態を維持しながらPWAを移行できると説明されています。(Windows Blog)

結論：Edge 150の新機能であり、廃止・強制移行ではない

今回の変更を整理すると、次のようになります。

項目	内容
変更の種類	インストール済みPWAを移行するための新機能
導入バージョン	Microsoft Edge 150
Edge 150のStable公開日	2026年7月2日
公式の対応期限	発表されていない
主な対象	デスクトップ版EdgeでインストールされたPWA
対応できる移行	同一サイト内のオリジン移行
対応できない代表例	`example.com`から`example.net`などの別サイト移行
今すぐ対応が必要なケース	PWAのサブドメイン変更やオリジン変更を予定している場合

Microsoft Edge 150のStableチャネルは2026年7月2日に公開され、同バージョンのWebプラットフォーム更新としてPWA origin migrationが案内されています。したがって、7月8日を期限とする変更ではなく、7月上旬から利用可能になった移行手段と理解するのが適切です。(Microsoft Learn)

Microsoft Edge PWAのsame-site origin migrationとは

PWAはブラウザからインストールできるWebアプリですが、インストール後はアプリのIDやセキュリティ境界が、Webサイトのオリジンと強く結び付いています。

オリジンは、基本的に次の3要素の組み合わせです。

スキーム：https
ホスト名：www.example.com
ポート番号：通常は443など

そのため、同じ会社が管理するURLでも、www.example.comとapp.example.comは異なるオリジンです。

従来、この変更をインストール済みPWAへ反映するには、ユーザーに旧アプリをアンインストールしてもらい、新しいURLから再インストールしてもらう必要がありました。操作が分かりにくいうえ、旧アプリが端末に残ったり、新旧のアプリが重複したりする問題もありました。

PWA origin migrationでは、ブラウザが移行元と移行先の関係を確認し、ユーザーにアプリ更新として移行を案内します。

「same-site」は「同じオリジン」という意味ではない

この機能で重要なのが、same-siteとsame-originの違いです。

same-site migrationでは、移行元と移行先が同じ登録可能ドメイン、技術的には同じeTLD+1を共有している必要があります。(Chrome for Developers)

移行例	判定	PWA origin migration
`www.example.com/app/` → `app.example.com/`	別オリジン・同一サイト	対応可能
`old.example.co.jp/` → `new.example.co.jp/`	別オリジン・同一サイト	対応可能
`example.com/app/` → `example.com/v2/`	同一オリジン	ID変更への利用を検討可能
`example.com/` → `example.net/`	別サイト	対応不可
`service-a.jp/` → `service-b.jp/`	別サイト	対応不可

同じホスト内でパスだけを変更する場合、オリジン自体は変わりません。ただし、Web App Manifestに明示的なidがなく、start_urlが実質的なアプリIDとして使われていたPWAでは、パス変更によって別アプリとして認識されることがあります。

WICGの説明では、このような同一オリジン内の「アプリID分裂」を修正する用途にも、移行用のManifestメンバーを利用できるとされています。(GitHub)

対応が必要な環境と不要な環境

すべてのMicrosoft Edge利用者やPWA運営者が対応する必要はありません。まず、次の表で自社環境を判定してください。

利用状況	対応要否	判断理由
Edgeでインストール済みのPWAを別サブドメインへ移す	必要	今回の機能の主な対象
PWAをインストールせずブラウザで利用している	原則不要	通常のWeb移転として対応する
バックエンドだけを変更し、公開オリジンは維持する	不要	PWAのIDやオリジンが変わらない
`example.com`から`example.net`へ移す	別手段が必要	same-siteの条件を満たさない
Edge 149以前を利用している	代替手段が必要	Edge 150で導入された機能
Android版ブラウザのPWA	別途検討	初期実装はデスクトップ向け
管理者が強制インストールしたPWA	管理者対応が必要	通常のユーザー移行フローが制限される
同じオリジンで`start_url`だけを変更する	IDを確認	明示的な`id`がないと別アプリ化する可能性がある

Chromiumの実装方針では、この機能は当初デスクトッププラットフォームのみを対象としており、AndroidのPWAインストール・更新機構は対象外とされています。(Google グループ)

端末側では、次の内部ページを使って確認できます。

edge://settings/help：Microsoft Edgeのバージョン確認
edge://apps：インストール済みWebアプリの確認

実際の影響調査では、アクセス解析だけでなく、社内端末管理やサポート履歴も確認してください。Webアクセスが多くても、PWAとしてインストールしている利用者が少なければ、移行対象は限定的です。

企業管理端末は通常の移行と分けて考える

Chromiumの実装方針では、管理者によって強制インストールされたWebアプリには移行を提示せず、移行がブロックされたことを示す案内を表示するとされています。URLやオリジンを基準に適用された企業ポリシーを、PWA側の操作で回避させないためです。(Google グループ)

Microsoft Edgeには、Webアプリをユーザー操作なしでインストールするWebAppInstallForceListポリシーがあります。このポリシーで配布したPWAについては、通常ユーザー向けのorigin migrationに任せず、管理者が配布URLやポリシーの切り替え計画を作成する必要があります。(Microsoft Learn)

移行期限はいつか

2026年7月12日時点で、MicrosoftはPWA origin migrationの利用期限、旧オリジンの廃止期限、移行完了期限を案内していません。

今回の情報は「今後この日までに移行しなければPWAが動かなくなる」という廃止告知ではなく、これまで難しかったオリジン移行を実現するための機能追加です。(Windows Blog)

ただし、実務上の期限は存在します。それは、運営者が決める旧オリジンの停止日です。

旧オリジンを先に停止すると、まだ移行していない端末が次の問題に直面します。

旧PWAを起動できない
旧Manifestを取得できない
移行情報を検出できない
ログイン状態やローカルデータを引き継げない
サポート窓口へ問い合わせが集中する

旧オリジン停止日から逆算する

以下は、一般的なサービスで使える移行計画の例です。期間は公式要件ではないため、利用者数や更新頻度に合わせて調整してください。

段階	実施内容	完了条件の例
事前調査	旧PWAのID、端末、ブラウザ、保存データを調査	対象範囲と責任者が確定
検証	テスト環境で`migrate_from`と関連付けファイルを実装	Edge 150以降で移行成功
小規模公開	`suggest`で一部利用者へ案内	重大障害がなく、移行率を計測できる
全体公開	対象利用者へ段階的に展開	問い合わせやエラーが許容範囲内
強制移行	必要な場合だけ`force`へ変更	旧アプリを継続できない理由が明確
旧環境終了	DNS、証明書、旧Manifestなどを停止	未移行者への代替経路を用意済み

旧オリジンの停止判断は、公開からの日数だけで決めないほうが安全です。たとえば、社内基準として「対象端末の95％以上が移行」「重大障害ゼロを2週間継続」「未移行者向けの手動再インストール手順を公開」といった条件を設定します。

95％や2週間という数値は公式基準ではありません。自社の利用者数、業務影響、サポート体制に合わせて決めるための例です。

移行の仕組みは新旧オリジンによる双方向確認

PWA origin migrationは、新しいサイトが一方的に「旧アプリの後継」を名乗れる仕組みではありません。

次の2つがそろって、初めて移行が検証されます。

移行先PWAが、どの旧PWAから移行するかをManifestで宣言する
移行元オリジンが、移行先PWAへの引き渡しを.well-knownファイルで許可する

この双方向確認により、悪意のあるサイトが正規PWAを乗っ取るリスクを抑えています。([WICG][7])

移行先Manifestに明示的なidとmigrate_fromを追加する

たとえば、旧PWAをhttps://www.example.com/app/、新PWAをhttps://app.example.com/で提供する場合、移行先のWeb App Manifestは次のように設定します。

{
  "name": "Example App",
  "id": "/",
  "start_url": "/",
  "scope": "/",
  "display": "standalone",
  "migrate_from": [
    {
      "id": "https://www.example.com/app/",
      "install_url": "https://www.example.com/app/install-for-migration",
      "behavior": "suggest"
    }
  ]
}

各項目の役割は次のとおりです。

項目	役割
`id`	移行先PWAの安定したアプリID
`migrate_from`	移行元PWAのIDを指定
`migrate_from.id`	旧PWAの実際のManifest ID
`install_url`	旧Manifestを取得できるページ
`behavior`	ユーザーへの提示方法を指定

ここで最も間違えやすいのが、migrate_from.idです。

指定する値は単なる旧ホスト名ではなく、インストール済み旧PWAの実効Manifest IDです。旧Manifestに明示的なidがない場合は、当時のstart_urlがアプリIDとして使われている可能性があります。

末尾のスラッシュやパスも含め、実際のIDと一致させてください。現在公開中のManifestだけを見て推測せず、旧PWAをインストールした状態でDevToolsのManifest情報も確認するのが安全です。

移行先Manifestには、明示的で有効なidが必要です。これは、将来start_urlを変更したときに同じ問題を繰り返さないためにも重要です。(Chrome for Developers)

移行元にweb-app-origin-associationを配置する

移行元オリジンには、次の正確なパスでJSONファイルを公開します。

https://www.example.com/.well-known/web-app-origin-association

内容は次のようになります。

{
  "https://app.example.com/": {
    "allow_migration": true
  }
}

JSONのキーには、移行先Manifestのidを絶対URLへ解決した値を指定します。移行先Manifestで"id": "/"を指定した場合、今回の例ではhttps://app.example.com/です。

次の点も確認してください。

ファイルをアプリ配下ではなく、オリジン直下の/.well-known/へ置く
認証なしで取得できるようにする
HTTPS証明書を有効に保つ
WAFやCDNがドットで始まるパスを拒否していないか確認する
JSONの構文エラーがないことを確認する
移行先IDの末尾スラッシュやパスを一致させる
設定変更時はCDNキャッシュも更新する

仕様上、ブラウザは移行元オリジンの/.well-known/web-app-origin-associationを取得し、移行先のManifest IDに対してallow_migrationがtrueであることを確認します。([WICG][7])

必要に応じて旧Manifestにmigrate_toを追加する

旧PWAのManifestには、移行先を示すmigrate_toを追加できます。これは必須ではありませんが、利用者が移行先サイトへアクセスするのを待たずに、旧PWA側から移行を検出させたい場合に役立ちます。

一方、旧URLから新URLへリダイレクトする方法もあります。ただし、すべての旧URLを即座にリダイレクトすると、ブラウザが旧Manifestを取得できなくなります。

その場合は、移行先Manifestのmigrate_from内にinstall_urlを設定し、リダイレクトされず、旧Manifestへリンクしているページを旧オリジンに残してください。(Chrome for Developers)

301や302リダイレクトを設定するだけでは、インストール済みPWAのIDや保存データが自動的に移行されるわけではありません。リダイレクトは移行フローの一部として利用できますが、双方向の許可設定やManifest更新の代わりにはなりません。

suggestとforceは段階的に使い分ける

migrate_fromのbehaviorには、主に"suggest"と"force"を指定できます。

設定	ユーザーへの表示	ユーザーの選択	適した場面
`suggest`	受動的な更新通知	移行、アンインストール、無視	検証期間や段階公開
`force`	次回起動時にブロッキングダイアログ	移行またはアンインストール	旧アプリを継続できない場合

behaviorを省略した場合も、基本的にはsuggest相当として扱われます。

最初からforceを使用すると、設定ミスやデータ移行漏れがあったときに、ユーザーが旧アプリへ戻れなくなる可能性があります。まず"suggest"で移行率、エラー率、問い合わせ件数を測定し、必要性が確認できた段階で"force"を検討するのが安全です。

forceを使った移行では、移行と同時にアプリ名やアイコンを変更できません。名称やアイコンの変更は、オリジン移行後に通常のアプリ更新として行う必要があります。(Chrome for Developers)

インストール移行とデータ移行は別の作業

Microsoftの公式説明では、PWA origin migrationによってインストール状態や「適用可能な権限」を維持できると案内されています。(Windows Blog)

ただし、この表現を「Cookie、IndexedDB、キャッシュ、ログイン状態、通知権限などがすべて自動的に移動する」と解釈してはいけません。

Chromiumの技術議論では、移行機能はストレージの状態を変更せず、Cookieなどを引き継ぐ場合はサイト側で処理する必要があると説明されています。WICGの現行Explainerでも、初期バージョンでは権限を移行せず、新しいオリジン側の権限状態から開始すると記載されています。(Google グループ)

公式リリースノートと仕様説明で表現の範囲に差があるため、実務では権限やデータは自動移行されない前提で、Edgeの対象バージョンごとに検証するのが安全です。

項目	自動移行への期待	必要な対応
PWAのインストール状態	今回の機能の対象	実機でショートカットやピン留めも確認
Manifest ID	新しいIDへ移行	新旧IDを正確に指定
`localStorage`	自動移行を期待しない	サーバー同期や移行ページを用意
IndexedDB	自動移行を期待しない	必要なデータを明示的に転送
Cache Storage	自動移行を期待しない	新Service Workerで再取得
Cookie	自動転送されない	Domain、Path、SameSite、Secure属性を確認
ログインセッション	維持を保証できない	再ログインまたは安全なセッション引き継ぎを設計
通知・位置情報権限	再許可が必要になる可能性	再同意画面と説明を用意
Push購読	再登録が必要になる可能性	新オリジンで購読し、サーバー側を更新
サーバー保存データ	アカウントにひも付けば維持可能	新オリジンから同じアカウントへ接続できるか確認

特にオフライン対応PWAでは、IndexedDBやCache Storageに業務データを保存していることがあります。移行前に同期を完了させる仕組みや、未同期データがある場合は移行を止める仕組みを用意してください。

移行前に必要な確認事項

PWAのIDと対象端末を確認する

[ ] 旧PWAの実効Manifest IDを特定した
[ ] 旧PWAに明示的なidがあったか確認した
[ ] start_urlがIDとして使われていなかったか確認した
[ ] 末尾スラッシュ、パス、大文字・小文字を確認した
[ ] Edge 150以降のデスクトップ端末数を把握した
[ ] Edge 149以前や他ブラウザの利用者数を把握した
[ ] Android利用者を別対象として切り分けた
[ ] 管理者による強制インストールの有無を確認した

新旧オリジンの設定を確認する

[ ] 新Manifestに明示的なidを設定した
[ ] migrate_from.idが旧PWAのIDと一致している
[ ] behaviorを意図どおりに設定した
[ ] 移行元の正しいルートに関連付けファイルを配置した
[ ] 関連付けファイルのキーが新Manifest IDと一致している
[ ] allow_migrationが真偽値のtrueになっている
[ ] DNSとTLS証明書を移行期間中も維持できる
[ ] WAF、CDN、認証処理が.well-knownを妨げていない
[ ] 旧URLをリダイレクトする場合は、非リダイレクトのinstall_urlを用意した

"true"という文字列ではなく、JSONの真偽値であるtrueを指定します。キーのURLが1文字でも異なると、移行が検証されない可能性があります。

認証・データ・セキュリティ設定を確認する

[ ] Cookieとセッションの引き継ぎ方式を決めた
[ ] IndexedDB、Local Storage、Cache Storageの利用箇所を洗い出した
[ ] オフライン中の未同期データを検出できる
[ ] OAuthやOpenID ConnectのリダイレクトURIを追加した
[ ] Microsoft Entra IDなどのアプリ登録を更新した
[ ] CORSの許可オリジンを更新した
[ ] CSPのconnect-srcやframe-srcなどを確認した
[ ] CSRF対策が新しいオリジンでも機能する
[ ] WebAuthnやパスキーのRP IDと許可オリジンを確認した
[ ] 通知、位置情報、カメラ、マイクの再許可手順を用意した
[ ] Push通知の購読再作成と古い購読の整理方法を決めた
[ ] プライバシーポリシーや同意画面のURL変更を確認した

サブドメインが同じ組織内にあっても、認証サービスやAPIから見れば別オリジンです。PWAの移行自体が成功しても、OAuthのリダイレクトURIやCORS設定が古いままだと、ログイン直後にエラーが発生します。

実機テストとロールバックを確認する

[ ] 新規インストールではなく、旧PWAを実際にインストールしてテストした
[ ] suggestの通知から正常に移行できた
[ ] ユーザーが通知を無視した場合も旧アプリを継続できた
[ ] forceで移行またはアンインストールを選べた
[ ] オフライン状態から復帰した場合をテストした
[ ] 複数のEdgeプロファイルで確認した
[ ] 通常端末と管理端末を分けてテストした
[ ] 新旧両方のログイン状態を確認した
[ ] ショートカット、タスクバー、通知、ファイル関連付けを確認した
[ ] 移行失敗時に旧オリジンへ戻せる
[ ] 旧オリジンのDNS、証明書、Manifestをすぐに削除しない
[ ] 移行成功率と失敗理由を計測できる
[ ] サポート担当者向けの復旧手順を用意した

ブラウザの通常タブから新サイトを開くだけでは、インストール済みPWAの移行テストになりません。必ず旧バージョンのPWAをインストールした検証用プロファイルを作り、実際の更新フローを再現してください。

実装時に失敗しやすいポイント

失敗例	発生する問題	対策
`migrate_from.id`にホスト名だけを指定	旧PWAと一致せず移行が表示されない	実効Manifest IDを指定する
`.well-known`を`/app/`配下に配置	ブラウザがファイルを取得できない	オリジン直下へ配置する
関連付けファイルのキーが新URLと不一致	双方向確認に失敗する	絶対形式の新Manifest IDを使用する
旧URLをすべて即時リダイレクト	旧Manifestを更新できない	非リダイレクトの`install_url`を残す
最初から`force`を指定	障害時にユーザーが旧アプリを使えない	`suggest`で段階展開する
`force`と同時に名前・アイコンを変更	意図した更新フローにならない	移行後の通常更新に分ける
ローカルデータも自動移行されると想定	オフラインデータや設定が失われる	サーバー同期や個別移行を実装する
旧オリジンを早期停止	未移行ユーザーが起動できない	移行率を確認してから終了する
新規インストールだけで検証	既存利用者固有の問題を見落とす	旧PWAからの更新を再現する

Manifestの構文が正しくても、指定したIDが既存インストールと一致していなければ移行は始まりません。実装作業では、JSONファイルの作成よりも、旧PWAのIDを正確に特定する作業を優先してください。

same-siteで移行できない場合の代替手段

ユーザーに手動で再インストールしてもらう

example.comからexample.netのような別サイト移行には、same-site origin migrationを利用できません。

この場合は、旧PWA内で次の手順を案内します。

未同期データをサーバーへ保存する
新しいサイトへサインインできることを確認する
新PWAのインストールページを開く
新PWAをインストールする
データと設定を確認する
旧PWAをアンインストールする

新PWAのインストールを先に案内し、動作確認後に旧PWAを削除する流れにすると、移行失敗による利用不能を防げます。ただし、一時的に新旧2つのアプリアイコンが表示されるため、画面付きの案内を用意すると親切です。

公開オリジンを維持して内部構成だけを変更する

ユーザー側のオリジンを変える必要がなければ、旧オリジンをフロントエンドの入口として残し、リバースプロキシやAPI Gatewayを使って新基盤へ接続する方法があります。

たとえば、PWAの公開URLをhttps://app.example.com/のまま維持し、バックエンドだけを新しいクラウド環境へ移します。PWAのID、Cookie、権限、Service Workerの境界を変えずに済むため、利用者への影響を抑えられます。

ただし、旧インフラを完全に廃止したい場合や、ブランド変更で公開ドメインそのものを変える場合には使えません。

管理端末では配布ポリシーを更新する

WebAppInstallForceListなどで配布している場合は、利用者向け移行ダイアログではなく、管理ポリシーの変更として扱います。

管理者は次の点を確認してください。

新PWAの配布URL
旧PWAのポリシー削除時期
新旧アプリが一時的に重複する可能性
デスクトップショートカットの作成設定
カスタム名やカスタムアイコン
ユーザーデータとログイン状態
ポリシー適用失敗時の復旧方法

一斉に旧設定を削除するのではなく、テストグループで新ポリシーを適用し、正常に起動できることを確認してから対象を広げます。

古いEdgeや他ブラウザ向けの経路を残す

PWA origin migrationに対応していないブラウザやバージョンでは、従来どおり手動再インストールが必要です。

移行期間中は、ユーザーエージェントだけで分岐するのではなく、次のようなフォールバックを用意してください。

旧PWA内の移行案内
新PWAのインストール手順
ブラウザ更新の案内
データ同期状況の確認画面
旧アプリのアンインストール手順
問い合わせ窓口

ブラウザ判定だけに依存すると、管理ポリシーや機能の段階展開による差を見落とします。実際に移行が完了したかどうかを、アカウント情報やサーバー側の記録でも確認できる設計が理想です。

対応要否を最終判断する

次の順番で確認すると、自社が取るべき対応を決められます。

EdgeからインストールされたPWAが存在しない
→ 今回の機能への直接対応は不要です。
PWAは存在するが、公開オリジンを変更しない
→ origin migrationは不要です。ただし、Manifestのidが未設定なら将来に備えて確認します。
公開オリジンを変更するが、移行先は同じ登録可能ドメイン内
→ Edge 150のsame-site origin migrationを利用できます。
移行先が別の登録可能ドメイン
→ この機能は利用できません。手動再インストールや旧オリジン維持を検討します。
対象端末がAndroidまたはEdge 149以前
→ origin migrationだけに依存せず、フォールバックを用意します。
管理者がPWAを強制インストールしている
→ ユーザー向け移行ではなく、管理ポリシーの更新として計画します。
ローカルデータ、通知、ログイン状態を利用している
→ アプリの移行とは別に、データ・権限・認証の移行設計が必要です。

最初に着手すべき作業は、コードの変更ではありません。まず、旧Manifest ID、新Manifest ID、対象端末、管理ポリシー、保存データ、使用権限を一覧化してください。

そのうえで、Edge 150を使った検証環境にbehavior: "suggest"で実装し、実際にインストール済みの旧PWAから移行できるか確認します。旧オリジンはすぐに停止せず、移行率とエラーを計測しながら段階的に対象を広げることが、最も安全な進め方です。
[7]: https://wicg.github.io/manifest-incubations/ “
Manifest Incubations
“

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Edge PWAのオリジン移行とは？Edge 150の期限・対象・実装手順

結論：Edge 150の新機能であり、廃止・強制移行ではない

Microsoft Edge PWAのsame-site origin migrationとは

「same-site」は「同じオリジン」という意味ではない

対応が必要な環境と不要な環境

企業管理端末は通常の移行と分けて考える

移行期限はいつか

旧オリジン停止日から逆算する

移行の仕組みは新旧オリジンによる双方向確認

移行先Manifestに明示的なidとmigrate_fromを追加する

移行元にweb-app-origin-associationを配置する

必要に応じて旧Manifestにmigrate_toを追加する

suggestとforceは段階的に使い分ける

インストール移行とデータ移行は別の作業

移行前に必要な確認事項

PWAのIDと対象端末を確認する

新旧オリジンの設定を確認する

認証・データ・セキュリティ設定を確認する

実機テストとロールバックを確認する

実装時に失敗しやすいポイント

same-siteで移行できない場合の代替手段

ユーザーに手動で再インストールしてもらう

公開オリジンを維持して内部構成だけを変更する

管理端末では配布ポリシーを更新する

古いEdgeや他ブラウザ向けの経路を残す

対応要否を最終判断する

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Edge PWAのオリジン移行とは？Edge 150の期限・対象・実装手順

結論：Edge 150の新機能であり、廃止・強制移行ではない

Microsoft Edge PWAのsame-site origin migrationとは

「same-site」は「同じオリジン」という意味ではない

対応が必要な環境と不要な環境

企業管理端末は通常の移行と分けて考える

移行期限はいつか

旧オリジン停止日から逆算する

移行の仕組みは新旧オリジンによる双方向確認

移行先Manifestに明示的なidとmigrate_fromを追加する

移行元にweb-app-origin-associationを配置する

必要に応じて旧Manifestにmigrate_toを追加する

suggestとforceは段階的に使い分ける

インストール移行とデータ移行は別の作業

移行前に必要な確認事項

PWAのIDと対象端末を確認する

新旧オリジンの設定を確認する

認証・データ・セキュリティ設定を確認する

実機テストとロールバックを確認する

実装時に失敗しやすいポイント

same-siteで移行できない場合の代替手段

ユーザーに手動で再インストールしてもらう

公開オリジンを維持して内部構成だけを変更する

管理端末では配布ポリシーを更新する

古いEdgeや他ブラウザ向けの経路を残す

対応要否を最終判断する

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル