Zenn
🔗

Firebase Dynamic Links終了に備えたメール認証の代替実装ができたのでふりかえる

に公開
Firebase
tech

こんにちは、たけ🎋です。

2025年8月25日をもって、Firebase Dynamic Links（以下、FDL）のサポートが完全終了します😢

https://firebase.google.com/support/dynamic-links-faq?hl=ja

自分が開発しているアプリでもメールリンク認証にFDLを全面的に利用しており、「このままでは夏以降ログイン不能になる…！」という不安がずっとありましたが、ギリギリのタイミングでなんとか代替サービスへの移行を完了することができました🙌

今回は、その代替をどのように選び、どんな苦労や学びがあったかを振り返ってまとめます。

そもそもFDLはどこで使われていた？

まず、アプリ内でどのようにFDLが利用されているのかを調べたところ、大きく2つありました。

  • コードで管理されている部分

    • アプリのメールリンク認証、特定画面への遷移など

  • コード外（マーケティングなど）で管理されている部分

    • LPやメルマガ内でのディープリンクなど

アプリ認証に関しては特に影響が大きく、早急に代替サービスを検討する必要がありました。

代替サービスの要件と比較検討

代替サービスの選定では、次のような要件を設定しました。

優先度 要件
必須 ディープリンクで特定画面へ遷移／ストアリダイレクト／Long Link生成
なるべく必要 ディファードDL／独自ドメイン／Short Link生成／OGP指定
不要 クリック分析（Google Analyticsで代替可能）

この要件を元に、候補となったサービスを比較しました。

サービス 充足率 料金 導入コスト 特徴
Adjust ◯ MAU従量課金 中 マーケ計測が得意
AppsFlyer OneLink ◎ メールリンク用途は無償 低 既存のSDK活用可能
Bitly △ クリック数課金 低 リンク生成のみ
Branch ◎ MAU従量課金 中 UIが豊富
Kochava ◯ MAU従量課金 中 計測が充実

比較した結果、既にアプリに導入しており追加コストが最も少ない AppsFlyerのOneLink を採用することに決定しました。サービス移行時のコード差分も最小限に抑えられることが決め手になりました。

実装概要

FDLからOneLink＋SendGridへの移行で、実装は次のように変わりました。

Before（FDL） After（OneLink＋SendGrid）

実際の実装手順は、

  1. Cloud FunctionsにOneLinkのURL生成処理を追加
  2. SendGridでDynamic Templateを作成しメール送信を移行
  3. アプリ側のリンクバリデーションにOneLinkドメインを追加

というシンプルな形になり、移行負担は想像していたよりも小さく済みました。

項目 Before（FDL） After（OneLink＋SendGrid）
リンク生成 FirebaseのSDK Cloud FunctionsでOneLink API
メール送信 Firebase Auth直送 SendGridのテンプレート
リダイレクト Dynamic Links→アプリ/ストア OneLink（ディファード対応）→アプリ/ストア
認証処理 isSignInWithEmailLink() 同じ（URLの置換のみ）

苦労したことと学んだこと

① ドキュメント迷子問題

Firebase、AppsFlyer、SendGridと複数サービスを横断した実装で、一つの機能を把握するのに3つの公式ドキュメントを行き来する状態になりました。
用語や設定方法が微妙に異なり、「今は何をしているんだっけ？」という混乱が起きましたが、AIに設定手順をリサーチやチェックリストや動作確認リストを整理することで理解を深めて実装することができました。

② 既存コードのリファクタリング

旧コードはリンク生成・メール送信・認証後の処理がいろんなクラスを行き来してかなり見づらいコードとなっていて簡単な処理のはずなのに理解に時間がかかりました。。
なので、どこで何が行われているかを一旦把握し、クラスごとに処理を責務分離してリファクタリングをしてから作業を進めたことで、処理の内容は増えながらもコード管理の容易性とパフォーマンス向上ができて品質の高いコード管理に繋げることができました。

③ 動作環境による不具合

「開発環境では動くのに、本番環境では動かない」や「iOSとAndroid端末ごとに挙動が違う」や「メアドごとに同じ処理でも挙動が違う」など、環境差異が原因が多々あり、再現をとりながら改修することが大変でした。
自分の端末だけではわからないのでチームメンバーと一緒にデバックをして問題なく動作するか確認して進めてなんとか解決できた感じです。

④ メールの迷惑フォルダにいってしまう

SendGrid移行直後、送ったメールがユーザーの迷惑フォルダに振り分けられる事態が発生しました。
メール知識が全くと言っていいほどんなかったので、調べながら進めたのですが、SPF、DKIMを設定しても改善されず、調査の結果、DMARCというメールの送信元を検証する設定が原因だと判明しました。設定を変更し、メールが確実に届くようにモニタリング体制も整えました。
ここから、メール配信にはDNSの細かい設定や継続的なモニタリングが必要だという重要な学びを得ました。

まとめ

今回の経験は正直、ギリギリのタイミングで改修して冷や汗ものでした。
ただ、「外部依存を見直す良いチャンス」だったと感じています。
ディープリンクは最初「ブラックボックス」だと思っていましたが、今回の件を通じて仕組みを深く理解し、次回また同じようなことがあっても冷静に対応できそうな自信がつきました。

今後は、メール到達率や認証成功率を定量的に分析・改善していきたいです。
また何か気づきがあれば共有していきます！

Discussion