Firebase終了後のUniversal Links / App Links設定方法

古い page.link がまだ QR、広告、メール、ダウンロード導線、紹介フローに残っているなら、今の課題は「Firebaseの代替を探すこと」ではありません。公開リンクを壊さずに、アプリ起動、fallback、計測を立て直すことです。

そのためには、Firebase Dynamic Links が1つにまとめていた役割を分けて考える必要があります。

公開用のブランドURL
インストール済みアプリの起動
App Store / Google Play / Web への fallback
UTM などのキャンペーン計測

公式の Firebase Dynamic Links FAQ によると、Firebase Dynamic Links は 2025年8月25日 に終了しました。既存リンクがまだキャンペーンやオンボーディングに残っているなら、近い見た目の代替を探すより、リンクレイヤーを整理し直すほうが安全です。

Universal Links と App Links が担当すること

Apple Universal Links

Apple Universal Links は、通常の HTTPS リンクから iOS のインストール済みアプリを開くための仕組みです。成立には次が必要です。

ドメインがアプリと関連付けられている
capability が正しく設定されている
apple-app-site-association が正しく配信されている
アプリ側が該当 path を処理できる

Android App Links

Android App Links は Android 側の同等機能です。必要なのは:

検証済みドメイン
正しい manifest 設定
有効な assetlinks.json
アプリ側の path 処理

それだけでは足りない部分

Universal Links と App Links だけでは、次は解決しません。

desktop fallback
アプリ未インストール時の遷移先
ブランド付きの共有URL
デバイス別ルーティング
UTM の維持
一時的なキャンペーン切り替え

ここを担当するのが redirect / routing レイヤーです。

Firebase後の現実的な構成

多くのチームにとって、保守しやすい構成は次です。

go.yourbrand.com/promo
  -> Edgeで端末判定
  -> iPhone かつアプリあり: Universal Link
  -> iPhone かつ未インストール: App Store
  -> Android かつアプリあり: App Link
  -> Android かつ未インストール: Google Play
  -> Desktop: LP、ドキュメント、QR案内ページ

この構成が扱いやすい理由は:

ドメインを自社で管理できる
fallback を明文化できる
マーケティングは1本のきれいなURLを配れる
mobile / growth / web で同じ実フローをテストできる

つまずきやすいのは検証ファイル

実務で詰まりやすいのは、仕組みの理解よりも次の配信です。

apple-app-site-association
assetlinks.json

Shopify、Webflow、Wix、制約の強い CMS などを使っていると、root や .well-known に必要なファイルを置くのが面倒になりがちです。

その点で UrlEdge は実務に寄せやすいです。custom response を使えば、こうした検証ファイルを Edge から返せるため、別の公開フローを増やさずに済みます。

実務向けの移行手順

1. まず公開リンクを棚卸しする

確認対象は:

広告リンク
QR コード
ダウンロードボタン
ライフサイクルメール
サポートページ
SNS のプロフィール導線
紹介フロー

2. アプリ起動と fallback を分けて定義する

各リンクについて、次を決めます。

アプリが入っていれば開くべきか
未インストールなら store に送るか web に送るか
desktop は何を見せるか
UTM を残す必要があるか

3. 公開用の正規ドメインを決める

候補はたとえば:

go.yourbrand.com
app.yourbrand.com
links.yourbrand.com

こうしておくと、今後 stack が変わっても公開リンクの主導権を失いにくくなります。

4. 検証ファイルを正しく配信する

必ず公式ドキュメントで確認してください。

ここが崩れていると、redirect が動いていても native app opening は安定しません。

5. fallback を明示的に設計する

たとえば:

iOS でアプリあり -> app
iOS でアプリなし -> App Store
Android でアプリあり -> app
Android でアプリなし -> Google Play
desktop -> LP または QR handoff

この部分を曖昧にしないことが大事です。

6. 実際の流入環境でテストする

少なくとも次は見てください。

iPhone Safari
Android Chrome
SNS やメッセージアプリの in-app browser
desktop
QR スキャン
UTM 付きリンク

ここで初めて、「リンクは返る」と「体験として正しい」の差が見えます。

よくある失敗

Device routing だけで十分だと思う

違います。routing は行き先を選びます。Universal Links / App Links は OS レベルの信頼された起動を担います。

desktop を後回しにする

desktop fallback が弱いと、サポート、ドキュメント、営業資料、QR の回遊で破綻しやすくなります。

UTM を落とす

広告、メール、QR、SNS から来るリンクなら、計測パラメータは意図的に保持すべきです。

レイヤーを増やしすぎる

shortener、古い redirect、LP の中継が増えるほど、障害調査が遅くなります。

UrlEdge が向いている場面

UrlEdge は次を1つの流れで管理したいときに相性がいいです。

ブランドURL
デバイス別ルーティング
store / web fallback
UTM の維持
クリック計測
検証ファイルの Edge 配信

モバイル attribution 全体を置き換える道具ではありません。ただ、公開リンクと fallback という、もっとも目に見える部分の制御を取り戻せます。

まとめ

Firebase Dynamic Links の後に必要なのは、別の魔法の箱ではなく、整理された構成です。

ブランドURL
デバイス別ルーティング
正しく検証された Universal Links と App Links
明示的な fallback
維持されるキャンペーンパラメータ

派手さは減りますが、運用はかなり安定します。

コアルーティング

スマートルール

セキュリティ＆モニター

ユーティリティとチェッカー

無料で構築を開始

会社とコミュニティ

法務とコンプライアンス

ドキュメント