メール登録に実在確認を足す — なぜ確認メール方式にしたか
「ぽんっ！」（旧称：でいりんぐ）はアカウントを作っておくと機種変更時にデータを引き継げます。このアカウント登録（メール登録）に、メールアドレスが実在するかの確認を足しました。方式の選定理由と、判定をどこに効かせたかを残します。
背景（当時の状況）
端末引き継ぎがメール登録ベースの仕組みになったことで、「登録されたメアドが本当に届くのか」を確かめる必要が出てきました。捨てアドや打ち間違いのまま引き継ぎ用アカウントを作られると、いざというときにデータを取り戻せません。2026-07-17 に方式を検討し、実在確認を設計しました。
2つの方式と、選ばなかった理由
Firebase Authentication でメアドの実在確認をするなら、大きく 2 つの方式があります。
- メールリンクサインイン（
sendSignInLinkToEmail）: メール内のリンクを踏むとサインインが完了する。 - 確認メール（
sendEmailVerification）: 通常のメール/パスワード登録後に確認メールを送り、リンクを踏むとemailVerifiedが真になる。
「ぽんっ！」では 2 の確認メール方式を選びました。理由は 1 が重かったからです。
- Dynamic Links が廃止（2025-08）されたため、メールリンクサインインを成立させるには Firebase Hosting のリンクドメイン + App Links / Universal Links を新規に整備する必要がある。
- 「ぽんっ！」にはディープリンク基盤が無いため、実在確認のためだけにディープリンク一式を作り込むのは割に合わない。
確認メール方式なら、着地ページは Firebase 標準のアクションハンドラで足り、ディープリンク基盤なしで完結します。
emailVerified を「登録済み」の判定に組み込む
単にメールを送るだけでなく、emailVerified=true になるまで「メール登録済み」とみなさないように判定を変えました。
- 設定画面のアカウント状態を 3 状態（未登録 / 確認待ち / 登録済み） に。
- 連携バナー等の「登録済みかどうか」の判定を、
emailVerified込みに変更。 - 確認が済むまでは新規課金も不可にした（登録成功 → 自動購入の連鎖は廃止）。ただし、引き継ぎログインと購入復元はブロックしない（既存ユーザーを締め出さないため）。
こまかいが効く UX
- 確認メールの再送をアプリ内からできるようにした（連打防止に 10 秒のクールダウン）。届かない・見失ったときの復帰導線です。
- パスワード変更・退会は確認待ちでも可能にした。ここまで縛ると不便になるため、締めるところと緩めるところを分けています。
- メールテンプレートの日本語化は Firebase コンソール側の作業として分離。
まとめ
- メアド実在確認は、自分のアプリにディープリンク基盤があるかで方式が変わる。無いなら 確認メール方式（
sendEmailVerification） が軽い。Dynamic Links 廃止後はメールリンクサインインの前提コストが上がっている点に注意。 - 実在確認は「メールを送る」だけで終わらせず、
emailVerifiedを『登録済み』判定と課金導線に組み込むところまでやって初めて意味が出る。 - 一方で引き継ぎ・復元・退会まで縛らない。既存ユーザーの締め出しを避けるさじ加減が UX を左右します。