結論
Firebase Authentication の登録件数は、サービスで利用できる会員数ではありません。
本人確認を伴うサービスでは、認証済みのアカウント、プロフィール登録済みの利用者、本人確認を承認した利用者、検索・表示対象の利用者を分けて管理する必要があります。
実際に起きた集計のずれ
テスト運用中のデータを確認すると、Firebase Authentication の登録は36件でした。一方、Firestore にプロフィールを持つ利用者は17件、本人確認承認済みは6件でした。
この差は異常ではありません。OAuthで作られたアカウント、登録途中で離脱したアカウント、審査待ちの利用者が混在するためです。
4つの状態を分離する
- 認証アカウント: ログインの資格情報が存在する状態
- プロフィール完了: サービスで必要な利用者情報が揃った状態
- 本人確認承認: 書類確認を経て年齢確認を完了した状態
- 公開対象: 検索・推薦・表示の対象として出せる状態
認証アカウントを会員数として数えたり、公開対象を認証状態だけで判定したりすると、運用と安全性の両方でずれが生まれます。
Firestore側を正とする
アプリが参照する利用者状態は、Firestoreのプロフィール文書を正とします。認証情報はログインのため、サービス状態はプロフィール文書のため、と役割を分けます。
公開対象は、プロフィールが完成していて、本人確認が承認済みで、利用停止状態ではないことをサーバー側で判定します。クライアントだけに判定を任せないことが重要です。
英語名のアカウントをAI作成と誤認しない
Googleログインでは、Googleアカウントの表示名がそのまま入ることがあります。そのため英語名の認証アカウントがあっても、AIやバッチ処理が作成した会員とは限りません。
調査では、通常の認証フロー以外に会員アカウントを自動生成する実装は確認されませんでした。判断材料は表示名ではなく、認証プロバイダ、作成日時、プロフィール文書の有無、監査ログです。
AI審査の位置付け
本人確認書類のAI判定は、画像の不足、文字の読みにくさ、書類種別の不一致などを検知する補助に使えます。ただし承認・否認の最終判断を自動化せず、運営者が確認する設計にしています。
センシティブな書類を扱うため、保存期間、アクセス権、監査記録、手動審査への切り替えを最初から設計に含める必要があります。
運用で見る指標
見るべき指標は認証登録数だけではありません。プロフィール完了率、本人確認提出率、承認率、承認までの時間、公開対象数を分けて可視化します。
これにより、登録導線の問題なのか、審査体験の問題なのか、そもそも利用意欲の問題なのかを切り分けられます。
まとめ
認証基盤の数字は便利ですが、そのまま事業の会員数にはなりません。会員の状態を明確に定義し、Firestoreなどのドメインデータを正として、公開条件と審査状態を分離することが安全な運用の出発点になります。