2026.08.27 開発

Firebase Dynamic Linksの終了と移行｜停止後に残る作業とUniversal Links／App Linksへの移行手順【2026年8月時点】

Firebase Dynamic Links（以下FDL）は2025年8月25日に停止しました。page.linkのリンクも独自ドメインのリンクも今はHTTP 404を返し、新しいリンクを作ることもできません。停止から1年が過ぎた2026年8月時点でも、受託の現場には「アプリ自体は動いているのに、ヘルプ記事とメール文面に残った旧リンクだけが行き止まりになっている」という相談が届く状況です。この記事では、停止がどの粒度で起きたのか、移行の前に何を洗い出すのか、apple-app-site-associationとassetlinks.jsonをどう成立させるのか、そして遅延ディープリンクと計測をどう引き取るのかを、実装する側の解像度で扱います。カスタムURLスキーム・ユニバーサルリンク・App Linksという方式そのものの違いはディープリンクとは？種類とユニバーサルリンク・URLスキームの違いで整理しているので、本記事は移行作業だけに絞ります。

まとめ：停止後に残る作業をリンク・遷移・計測の3層に分けて考える

先に結論を置きます。FDLの移行は「1つのサービスを別のサービスへ置き換える作業」ではありません。FDLが1本で担っていた短縮リンク・アプリへの遷移・流入計測という3つの役目が、停止によってバラバラの部品へ戻っただけ。だから移行先も3つに分かれます。短縮リンクは自前のリダイレクト基盤、遷移はUniversal LinksとApp Links、計測は自前のパラメータ設計か外部サービス。この3層に分けないまま「FDLの代わり」を探すと、要らないSDKまで抱え込むことになります。

次に判断です。既存ユーザー向けの画面遷移とアプリ内共有だけが目的なら、OS標準（Universal Links＋App Links）で完結し、追加費用はかかりません。一方、広告経由のインストール計測や、未インストールの利用者をインストール後に目的画面へ運ぶ遅延ディープリンクが要件に入るなら、OS標準では構造的に届かないため外部サービスを前提にします。ここは工夫で埋まる話ではないので、要件定義の段階で切り分けておきたいところ。

そして後始末です。FDLで独自ドメインを使っていたなら、ドメインは自社の管理下に残っているので、同じURLを生かしたまま中身だけ差し替えられます。page.linkサブドメインだった場合、そのホストは自社の管理外にあるため、発行済みのリンクはどうやっても復活しません。印刷物やQRコードに焼き込んだリンクの生死は、この一点で決まります。

Firebase Dynamic Linksは2025年8月25日に完全停止した

終了の告知は2023年8月に出され、停止日は2025年8月25日でした。約2年の猶予が置かれた計算になります。公式FAQは、独自ドメインで配信していたリンクとpage.linkサブドメインのリンクの双方が動作を止めると明記しており、例外は設けられていません。

停止で何が返るようになったか：リンクは404、APIは400と403

停止後の挙動は2種類に分かれます。利用者がクリックする側のリンクはHTTP 404を返し、管理やリンク生成に使うAPIリクエストは400または403を返す。ドメインとリンクのメタデータは2025年8月25日付で削除対象としてマークされ、データ保持ポリシーに沿ってパージされました。

厄介なのはアプリ側の壊れ方です。公式FAQは、SDKはアプリをクラッシュさせないものの、空の応答やエラーコールバックをアプリ側で扱う必要があると説明しています。つまりクラッシュレポートには何も上がってきません。アプリは正常に起動し、リンクを開いた利用者だけが静かに行き止まりへ着く。この壊れ方が発見を1年単位で遅らせます。旧バージョンのアプリが市中に残っているなら、まずリンク受け取り処理がnull応答で例外を出さないかを確認してください。

page.linkと独自ドメインでは後始末の手順が変わる理由

独自ドメイン（例：link.example.com）でFDLを配信していた場合、そのホスト名のDNSと証明書は自社の管理下にあります。したがって配信先を自前のリダイレクタへ向け直せば、配布済みのURLをそのまま生かせる。旧URLのパス構造を読んで新しい遷移先へ翻訳する互換層を1枚置けば、印刷物のQRコードすら救えるということです。

page.linkサブドメインの場合は事情が違います。公式FAQは、サービス停止後にpage.linkドメインは利用できなくなると回答しており、再取得の手段もありません。ホストがGoogleの管理下にある以上、こちらから手を出せる部分がないからです。この場合に残る手は、差し替えられるチャネル（アプリ内・メール・広告・自社サイト）だけを新リンクへ更新し、差し替えられないチャネル（印刷物・第三者に転載されたリンク）は損失として計上する、という切り分けになります。

移行の前に洗い出す資産は4種類あり、計測の切れ目もここで拾う

移行作業の量は、コードの量ではなく「発行済みリンクがどこに散らばっているか」で決まります。実装から入ると必ず取りこぼすので、棚卸しを先に済ませます。

発行済みリンクの所在をアプリ内・広告・印刷物・QRの順で棚卸す

まずコードベースを機械的に洗います。検索語は page.link、firebasedynamiclinks.googleapis.com、iOS側の DynamicLinkComponents、Android側の FirebaseDynamicLinks、それに設定ファイルへ書いたドメイン名。クロスプラットフォーム構成なら、React Native Firebaseとはで触れたとおりv26でDynamic Linksモジュールが削除済みのため、依存関係の側からも検出できます。

次に、コードの外にあるリンクを人手で集めます。優先順位は次の表のとおり。

資産の種類	差し替えの可否	扱い
アプリ内の共有機能	アプリ更新で可能	生成処理を置き換える
メール・プッシュ文面	テンプレート更新で可能	配信基盤側で一括置換
広告クリエイティブ	入稿し直しで可能	計測パラメータも設計
印刷物・QRコード	不可	ドメイン保持で救済

差し替え不能な資産があるかどうかで、独自ドメインを維持し続ける必然性が決まります。QRコードを配った実績があるなら、ドメインの解約は選択肢から外してください。

FDLの計測イベントが消えた後に流入をどこで数え直すのかを決める

FDLはクリックとアプリ起動をAnalyticsのイベントとして自動で送っていました。停止によってこの経路は無くなり、過去のリンクメタデータと分析データも保持ポリシーに沿って消えています。停止前にエクスポートしていなければ、遡って取り戻す手段はありません。

ここは割り切りが要る場所です。過去との連続した比較は諦め、切り替え後に新しい基準値を取り直す前提で設計する。具体的には、リダイレクタ側でクリックを自前のログとして記録し、アプリ側は起動時に受け取ったURLのクエリパラメータをそのままイベント属性として送る。この2点だけでも、どのリンクが押されて何人がアプリまで到達したかは追えます。

OS標準で足りる線と、外部の計測サービスが要る線をここで引く

移行先を先に決めてしまうと、要らない機能まで抱え込みます。判断の材料は次の一点に集約されます。アプリが入っていない利用者を、インストール後に目的の画面まで運ぶ必要があるか。

要件	移行先
既存ユーザーの画面遷移	OS標準で足りる
アプリ内共有・招待リンク	OS標準で足りる
メールからの復帰導線	OS標準で足りる
広告のインストール計測	外部サービスが要る
遅延ディープリンク	外部サービスが要る

採用条件をはっきり言い切ります。広告出稿がなく、リンクの用途がアプリ内共有とサポート導線に限られるプロダクトなら、外部の計測サービスは入れないほうが良い。SDKの追加はビルド構成・審査時のプライバシー申告・年次のバージョン追随という継続コストを生み、それに見合うだけの意思決定材料が広告非出稿では得られないからです。逆に、複数媒体へ広告を出していてキャンペーン別の成果を比べているなら、遅延ディープリンクと計測は同じ基盤へ載せるべきで、自前実装は割に合いません。

折衷も現実的です。ドメインを用途で分け、計測が要る導線だけ外部サービスのドメインへ寄せ、残りは自社ドメインとOS標準で受ける。こうしておくと、外部サービスを乗り換えるときに影響範囲が広告リンクだけに閉じます。移行の設計から実装・検証までを外部へ預けたい場合は、スマホアプリ開発の相談先として当社でも承っています。

iOS側の移行手順：Universal Linksを自前で成立させる

iOSはアプリ側のentitlementとサーバー側の検証ファイルの二段構えです。片方だけでは成立しないうえ、失敗しても画面上は「Safariが開くだけ」で終わるため、原因が見えにくい部分でもあります。

apple-app-site-associationをcomponents形式で書く

検証ファイルは /.well-known/apple-app-site-association にHTTPSで置きます。拡張子は付けず、Content-Typeは application/json、リダイレクトを挟んではいけません。iOS 13以降は従来の paths に代わって components 形式が推奨されており、paths も後方互換で動作します。

{
  "applinks": {
    "details": [
      {
        "appIDs": ["TEAMID.com.example.app"],
        "components": [
          { "/": "/product/*", "comment": "product detail" },
          { "/": "/campaign/*", "?": { "utm_source": "?*" } },
          { "/": "/admin/*", "exclude": true }
        ]
      }
    ]
  }
}

components形式にする利点は、クエリパラメータ単位の一致と除外指定が書けることです。FDLはクエリにリンク先URLを丸ごと入れる設計だったため、旧リンクを新方式へ移すとパス設計そのものを見直すことになります。除外指定を使い、管理画面やログアウト用のパスをアプリへ吸わせない設定も同時に入れておく。

AppleのCDN経由になった影響と、失敗キャッシュの外し方

iOS 14以降、検証ファイルは端末が直接取りに来るのではなく、AppleのCDNが取得して端末へ配る方式に変わりました。Appleの案内では、初めてホスティングした検証ファイルがCDNへ取り込まれるまで24時間以内。ここに落とし穴があります。JSONの構文エラー、Content-Typeの誤り、リダイレクトの介在があった状態でCDNに読まれると、その失敗状態がキャッシュされ、サーバー側を直しても即座には回復しません。

開発中はAssociated Domainsのエントリに ?mode=developer を付けると、CDNと端末キャッシュを迂回してオリジンから直接取得します。社内ネットワークにしか居ないステージング環境の検証にも使える一方、この指定を本番のentitlementへ残すと配信のたびに全端末がオリジンを叩くことになるので、リリース前の除去が必須です。検証ファイルの置き場に迷うなら、Firebase Hostingとはで扱ったホスティングでも要件を満たせます。

Android側の移行手順：App Linksの検証を通し切る

AndroidはDigital Asset Linksによる検証が通るかどうかの一点勝負です。通れば既定のハンドラになり、通らなければブラウザが開く。中間状態がないぶん、原因の切り分けはiOSより機械的に進められます。

assetlinks.jsonの配置とautoVerifyの前提条件

設置先は https://hostname/.well-known/assetlinks.json、Content-Typeは application/json です。マニフェスト側は次のように宣言します。

<intent-filter android:autoVerify="true">
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="https" android:host="link.example.com" />
</intent-filter>

autoVerify は、ACTION_VIEW・BROWSABLE／DEFAULT・http(s)スキームを含むintent-filterのいずれか1つに付ければ、そのアプリが宣言する全ホストが検証対象になります。自動検証が働くのはAndroid 6.0（API 23）以上。インストール直後の検証は非同期で走るため、20秒以上待ってから結果を見ます。

注意すべきはAndroid 11以前の挙動です。マニフェストに書いた全ホストがDigital Asset Linksと一致しない限り、どのホストについても既定ハンドラになりません。テスト用ドメインを1つ書き残しただけで本番ドメインまで巻き添えで落ちる、という事故が起きます。移行時は宣言するホストを実運用の分だけに絞ってください。

adbで検証状態を読み、verifiedにならない原因を切り分ける

検証が通ったかどうかは端末の状態を直接読めば分かります。

adb shell pm get-app-links --user cur com.example.app

adb shell pm set-app-links --package com.example.app 0 all

adb shell pm verify-app-links --re-verify com.example.app

1つ目が現在の検証状態の表示、2つ目が検証前の状態へのリセット、3つ目が検証の手動実行（Android 12／API 31以上）です。Android 12未満をターゲットにしているアプリで新しい検証手順を試すなら adb shell am compat enable 175408749 com.example.app を先に打ちます。

返る状態は verified・approved・denied・legacy_failure・none などで、none は「まだ記録されていない」だけなので数分待って再検証。denied や legacy_failure が続くときに疑う先は、ほぼ署名の指紋です。assetlinks.json に書く証明書のSHA-256指紋は、ローカルのデバッグ鍵ではなく実際に配信される鍵の指紋である必要があり、Play App Signingを使っているならPlay Console側が保持するアプリ署名鍵の指紋を入れます。ここを取り違えたまま「ファイルは置いたのに検証が通らない」と止まる例が最も多い。アプリの真正性をサーバー側でも見たいなら、Firebase App Checkとはで扱った仕組みと組み合わせる手もあります。

既存の短縮リンク資産を自前のリダイレクト基盤へ引き継ぐための手順

Universal LinksとApp Linksは「URLを受け取ってアプリを開く」仕組みであって、短いURLを発行する仕組みではありません。FDLが担っていた短縮の役目は別に用意します。

独自ドメインを維持できるなら、同じホストで静的なリダイレクトを返すだけで足ります。Firebaseの導入手順で作ったプロジェクトをそのまま使うなら、Hostingの設定ファイルに書けます。

{
  "hosting": {
    "site": "link-example",
    "redirects": [
      { "source": "/p/:id", "destination": "https://www.example.com/product/:id", "type": 302 },
      { "source": "/c/:code", "destination": "https://www.example.com/campaign/:code", "type": 302 }
    ]
  }
}

切り替え初期は302で始めます。301はブラウザにもCDNにも強く記憶されるため、対応表の誤りに気づいたときの巻き戻しが効かなくなるからです。数週間運用して到達先が固まってから301へ寄せる、という順序が安全でしょう。旧FDLのURLはリンク先とアプリ識別子をクエリに持っているので、これらを読んで新形式へ翻訳する互換ハンドラを1本置いておくと、配布済みリンクを段階的に畳めます。

自前で短縮IDを発行する場合、連番は避けて衝突しない乱数IDにし、総当たりでの走査に備えて存在しないIDへのアクセスは一律で同じ応答に揃えます。リンクの中身がキャンペーン情報である以上、IDから他社の施策が読めてしまう作りは避けたいところ。

遅延ディープリンクの穴はOS標準だけでは埋まらないと割り切る

移行の見積もりが崩れる原因は、ほぼここに集中します。FDLは「アプリ未インストールの利用者をストアへ送り、インストール後の初回起動で元のリンク先へ着地させる」遅延ディープリンクを持っていました。OS標準にはこれに相当する仕組みがありません。

AndroidにはGoogle PlayのInstall Referrer APIがあり、ストア経由で渡された参照元の文字列を初回起動時に読めます。これを使えば近似は成立する。一方iOSには同種の仕組みがなく、かつてクリップボードの内容や端末の特徴量から突き合わせていた手法はプライバシー面の制約で使えなくなりました。AdAttributionKitはキャンペーン単位の成果を測る枠組みであって、個々の利用者を特定の画面へ運ぶ用途のものではありません。

つまり、iOSとAndroidで同じ体験を自前で作ることは構造的にできない。要件に遅延ディープリンクが入っているなら、公式FAQが代替として挙げるAdjust・Airbridge・AppsFlyer・Bitly・Branch・Kochava・Singularといった外部サービスを前提に見積もります。逆に、これを要件から外せるなら移行はぐっと軽くなります。外し方の定石は、ストアからの初回起動時にWeb側で始めた手続きの続きを再開させる導線へ寄せること。ログインやワンタイムのコード入力を挟めば、リンクを覚えていなくても目的の画面へ戻せます。

移行の切り替え当日までに通しておきたい受け入れテストの並びと確認順

検証ファイルとリダイレクタとアプリ更新は、切り替える順序を間違えると片側だけが先に新しくなります。順序は次の1つに固定してください。検証ファイルの設置、CDN取り込みの待機、新アプリの配信、旧リンクのリダイレクト切り替え。逆順にすると、リンクだけが新しい遷移先へ飛び、旧バージョンのアプリがそれを受け取れない状態が生まれます。

受け入れテストは実機で次の項目を通します。

アプリ未インストールの端末でリンクを開き、Webページへ着地するか
インストール済みの端末でリンクを開き、目的の画面が直接出るか
メールアプリやSNSアプリの内蔵ブラウザからの遷移（効かない経路がある）
iOSでリンクを長押しし、アプリ名で開くメニューが出るか
Androidで pm get-app-links の結果が verified になっているか
旧ドメインのリンクが302で新しい遷移先へ届くか
クリックとアプリ到達の両方でログが残るか

強制アップデートの仕組みを持たないアプリなら、旧バージョンが数か月は市中に残る前提で計画します。旧バージョンでもWeb側へ落ちれば用が足りる状態を維持しておけば、更新の浸透を待つあいだも導線が死にません。iOSとAndroidで配信の反映速度が違う点は、iOSアプリ開発とはとAndroidアプリ開発とはで扱った審査と公開の流れも踏まえて見積もってください。