ベストプラクティス 1：登録を明確にする
顔認識ログインは最初の撮影前から始まります。生体認証を有効にする理由、用途、アクセスを復旧する方法をユーザーへ説明してください。
顔の登録は、アカウント作成後、メール確認後、安全な設定ページなど、信頼できるアカウントセッションで行います。追加認証中に新しい顔を登録しないでください。登録は認証より高い信頼が必要です。
カメラを開始する前に、分かりやすい同意画面を表示します。アプリケーションが受け取るのは Facial IDであり、生体認証ハッシュは、所有者の設定、同意フロー、削除ポリシーに従って選択された顔認識エンジンが管理することを説明します。 プライバシーのベストプラクティス では、同意とユーザー権利への対応を説明しています。
ベストプラクティス 2：ログイン方法を明確にする
ユーザーが実行中の操作を理解できる UI にします。メインのログインと追加認証を明確に区別してください。
メインの顔ログイン
生体認証を標準のログイン方法として使用する場合に選びます。“顔でログイン”をメイン CTA とし、代替手段へのリンクも表示します。
追加の顔認証
ログイン済みユーザーが重要な操作を行い、新しい顔認証が必要な場合に使用します。“続行するには本人確認を行ってください”など明確に表示します。
商用フローの追加認証については E コマースセキュリティ を参照してください。
ベストプラクティス 3：実際の失敗に備える
カメラ、照明、権限、端末には問題が起こります。本番フローではユーザーをロックアウトせず、次の手順を示してください。
- カメラ権限が拒否された場合は、再設定方法を表示します。
- 照明、顔の位置、カメラを改善する再試行ガイドを表示します。
- カメラを利用できないユーザー向けに、パスワード、OTP、サポートなどの代替手段を用意します。
- 認証結果をセッション発行前にバックエンドで対象アカウントへ関連付けます。 セキュリティのベストプラクティス を参照してください。
- 再試行回数を制限し、上限後は代替手段またはアプリケーションの確認手順へ移します。
ベストプラクティス 4：アカウントアクセスをサーバーで決定する
authenticate() が返す結果はログインフローへの入力であり、サーバー側の認可判断ではありません。バックエンドで返された Facial ID を対象アカウントへ関連付け、アカウントとリクエストのコンテキストを確認し、セッションルールを適用します。
authenticate() リファレンスにはブラウザの応答が記載されています。CHECKFACIALID エンドポイントでは Facial ID が登録中か確認できますが、特定のブラウザコールバックを認証するものではありません。API チェックリストでアカウントの関連付け、PIN ポリシー、セッション管理を確認してください。
顔認識ログインの開発者向けリソース
FACEIO ドキュメントを使用してブラウザフローを実装し、Facial IDs をアカウントへ関連付け、Console でアプリを設定します。
よくある質問
顔ログインでパスワードを完全に置き換えるべきですか？
アカウントモデルとリスクにより異なります。顔認証をメインのログインにする場合も、追加認証にする場合もあります。カメラを利用できないユーザー向けに復旧手段を用意してください。 生体認証ログイン の UX も参照してください。
眼鏡やひげなど、外見が変わった場合はどうなりますか？
通常の外見変化だけで再登録が必要になるとは限りません。認証が繰り返し失敗する場合は代替手段へ案内し、信頼できるセッションからのみ再登録を許可します。
再試行は何回まで許可しますか？
少数の再試行後に代替手段、サポート、手動確認へ移す方法があります。バックエンドのレート制限、PIN、Webhook 監視と組み合わせてください。
共有端末や公共端末で顔ログインを利用できますか？
利用できますが、その環境に合わせた設計が必要です。短いセッションを使用し、端末へ機密状態や顔画像を保存しないでください。FACEIO は Facial ID を返し、生体認証ハッシュは選択された顔認識エンジンが所有者の設定と同意に従って管理します。
関連ガイド
安全な顔ログインを実装する
製品概要は 顔認識ログイン を参照してください。実装については ログインページのチュートリアルを読み、FACEIO Console でアプリを作成してバックエンドを含むフローをテストします。