Firebase Dynamic Links終了後：古いリンク・アプリ招待・メールログインを復旧するには

問題を四つの段階に分ける

現在も使われているリンクを一つ選び、受信から完了まで追います。会員招待なら、メールのURLを開けるか、インストール済みアプリで招待画面へ進めるか、新規インストール後に再開できるか、正しいアカウントで承認できるかを確認します。URL、画面遷移、インストール後の引き継ぎ、本人確認は別々に検証します。「アプリが開いた」は途中経過です。

• メールテンプレート、SMS、WhatsApp、Webサイト、プッシュ通知、印刷したQRコード、アプリ内共有を洗い出します。
• 各リンクのドメイン、用途、遷移先、生成元、ログインの要否、再発行できるかを記録します。
• 旧バージョンと現在のストア配信版を確認します。開発版で動くだけでは不十分です。

古いpage.link URLは自社サーバーでは復旧できない

まずドメインの管理者を確認します。Googleのpage.linkドメインは保持も移管もできません。自社サイトにリダイレクトを追加しても、旧ドメインへのリクエストは受け取れません。編集できる掲載箇所を差し替え、招待を再発行し、送信済みメールや印刷物には別の復旧手段を用意します。

自社が所有する独自ドメインなら、既知のパスを新しいHTTPSの処理先で受けられる可能性があります。ただし、ドメインを維持できても短縮コードの遷移先まで復元できるとは限りません。保存済みのエクスポート、データベース、送信記録、キャンペーン一覧から対応表を探します。対応表がなければ復元は不確実です。Firebaseは終了時にメタデータを削除対象にすると説明しており、今からの再エクスポートを前提にはできません。

Firebase — Dynamic Links deprecation FAQ

代替サービスより先に、必要な動作を決める

インストール済みアプリの特定画面を開くだけなら、Android App LinksとApple Universal Linksを検討し、未インストールの利用者には役立つWebページを用意します。「招待を押す→ストアへ移動→インストール→初回起動で同じ招待を続ける」には、さらに遅延ディープリンクの仕組みが必要です。ストアに送るだけでは完了ではありません。

BranchやAppsFlyerなどのサービスと、明示的な再開方法を比較します。インストール後にメールを再度開く、期限付き招待コードを入力する、ログイン後に未処理の招待を表示する、といった方法です。小規模な会員サービスなら、次の操作が明確であれば後者で足りる場合もあります。実際の端末と配信経路でのデモを依頼し、料金、データ収集、ドメインの所有、エクスポート、解約時の移行を確認してください。「ディープリンク対応」だけでは同じ機能が揃うとは判断できません。

Firebase — Migrate to App Links and Universal Links · Branch — Firebase Dynamic Links migration

メールログインは別に検収する

Firebase Authenticationには、モバイル向けメールリンクをFirebase Hostingで処理する代替方式があります。SDKだけでなく、リンク生成の設定、新ドメインを受け取るモバイル側の設定、受信したURLから認証を完了する処理も確認します。AndroidとiOSの公式手順をそれぞれ読み、Flutter、React Native、ローコードツールでは内部のネイティブSDKとビルド設定も調べます。

有効期限、使い捨ての制約、アカウント確認を省いてはいけません。招待とログインは別の役割です。招待URLを持っているだけで参加権限を与えず、サーバー側でアカウント、招待状態、権限を確認します。計測には処理結果とエラーの分類を使い、認証URL全体、認証コード、トークンは収集しないようにします。

別の端末でメールを開く場合も試します。Firebaseのメールリンクログインでは送信先アドレスの確認が必要です。URLにメールアドレスを入れて本人確認の根拠にしないでください。パスワード再設定とメールアドレス確認も個別に試します。Dynamic Links終了は、FirebaseのWeb向けメール操作がすべて終了したという意味ではありません。

Firebase — Android email-link migration · Firebase — iOS email-link migration · Firebase — Email-link authentication and security

顧客が実際に受け取るメッセージで試す

ブラウザーにURLを貼り付けるだけでは、一つの入口しか確認できません。メール配信ツールのクリック計測でURLが置き換わったり、WhatsAppなどがアプリ内ブラウザーを使ったりする場合があります。実際に届いたテストメールを保存し、最終URLだけでなく、最初に押すURLのホスト名とリダイレクトの経路を確認します。

AndroidではApp Linksの検証状態とリリース版の署名証明書を、iOSではAssociated Domainsとapple-app-site-associationを確認します。待ち時間を延ばしてもドメインの関連付けは直りません。まずOSがURLをアプリへ渡しているか、その後でアプリが正しい画面に進むかを切り分けます。

特にiOSでは、ブラウザーのアドレス欄にURLを入力してもアプリは起動せず、同じWebサイト内の移動もブラウザーに留まる場合があります。検収ではテストメッセージ内のリンクを押してください。想定されたブラウザーの動作を修正の失敗と混同しないようにします。

Android Developers — Verify App Links · Apple Developer — Debugging universal links

完了条件を再現できるテストにする

初回の修正では、既存会員のメールログインなど優先度の高い用途を一つ復旧しても構いません。次の項目を出発点に、自社の処理で期待する結果を具体化します。アプリのバージョン、OS、入口、ログイン状態、最終結果を記録し、失敗時の対応とサポート手順も納品物に含めます。

• インストール済み：停止中でも起動中でも目的の内容へ進み、ログインが必要なら完了後も遷移先を維持する。
• 未インストール：次の操作が明確で、インストール後の自動引き継ぎを約束した場合は、その動作も合格条件にする。
• 期限切れ・使用済み・取り消し済みの招待：状態を明確に示して安全に再発行を依頼でき、再度押しても会員登録や注文を重複させない。
• 別アカウント・別端末：本人確認と権限が正しく働き、公開プレビューに機密情報を出さない。
• 実際の配信・共有経路、ストア配信版、サポート対象の旧版を試し、認証情報を記録せずに失敗を追跡できる。

修正を依頼する前に、導線と失敗例を揃える

再現用リンク、ストアのURLとバージョン、ドメイン一覧、メッセージの生成元、優先する導線、旧リンクの対応表を用意します。テストアカウントと機密情報を伏せた画面の方が、「Firebaseが壊れた」という説明より調査に役立ちます。管理者パスワードやサービスアカウントキーをメールで送らず、必要に応じて適切なアクセス権を設定します。

調査、URLの処理、アプリ更新、メール生成の変更、検収を見積もりで分けます。ストア審査と利用者のアプリ更新も日程に含めてください。終了済みサービスには戻せないため、検証済みのWeb導線や手動の再開方法を用意します。引き継ぎにはドメインと画面の対応表、テスト結果、監視項目、今後の更新担当を含めます。