低スコアの理由を、ユーザーに伝えられるようになった
Amazon Rekognition Face Livenessに、低い判定スコアの原因を示すFeedback Codesが追加されました。GetFaceLivenessSessionResults APIのレスポンスから、判定に影響した条件を取得できます。
対象となる例には、次のようなものがあります。
- 照明が不足している
- 顔の一部が遮られている
- 目を閉じている
- 動画品質が低い
従来の実装では、スコアが低い場合に「もう一度試してください」とだけ案内するケースが少なくありませんでした。しかし、原因が分からないまま再試行を求めると、同じ条件で失敗を繰り返し、本人確認の離脱につながります。
Feedback Codesを使えば、失敗理由に応じた具体的な案内を表示できます。さらに、1回のセッションで複数のコードが返る場合があるため、ユーザーは複数の問題をまとめて解消してから再試行できます。
APIレスポンスは「判定結果」と「改善案」に分けて扱う
実装では、Face Livenessのレスポンスを単なる成功・失敗の判定として扱わないことが重要です。少なくとも、次の情報を分けて処理できる設計にすると、画面や運用へ展開しやすくなります。
- livenessの信頼度スコア
- 本人確認を継続できるかどうかの判定
- Feedback Codesの一覧
- 顔照合に利用する参照画像や監査用画像に関する情報
Feedback Codesは、バックエンドでユーザー向けメッセージへ変換する構成が扱いやすいでしょう。AWSから返されたコードをそのまま画面に表示するのではなく、自社の表示文言や対応手順へマッピングします。
1. GetFaceLivenessSessionResultsを呼び出す
2. スコアとFeedback Codesを取得する
3. コードをユーザー向けメッセージへ変換する
4. 複数のメッセージを画面に表示する
5. 条件を改善したうえで再試行できる導線を提供する
例えば、照明不足と顔の遮蔽が同時に検出された場合は、次のように一度に案内します。
- 明るい場所へ移動してください
- マスクや手などで顔を隠さないでください
- 顔全体がカメラに映る位置で再試行してください
フロントエンドではコードを直接表示しない
Feedback Codesは開発者にとって有用な診断情報ですが、エンドユーザーには意味のある文章として提示する必要があります。コード名をそのまま表示すると、ユーザーが何を改善すればよいのか理解できない可能性があります。
表示設計では、次の点を意識します。
- 複数コードをすべて処理できるようにする
- 同じ内容のメッセージを重複表示しない
- 画面内で優先順位を付け、最初に対応すべき項目を分かりやすくする
- 日本語を含む必要な言語へ翻訳する
- 色やアイコンだけに依存せず、テキストでも説明する
- 読み上げ機能で内容を認識できる構成にする
特にアクセシビリティを考慮する場合、「失敗しました」とだけ表示するのでは不十分です。照明、カメラ位置、顔の遮蔽など、ユーザーが次に取るべき行動を短く具体的に示すことが重要です。
再試行フローの設計ポイント
Feedback Codesを活用する目的は、エラーを詳しく見せることではなく、次の試行で成功する確率を高めることです。再試行フローには、次のような改善が考えられます。
- 低スコアの理由を一覧で表示する
- 撮影環境を改善する手順を提示する
- 改善後に再試行できるボタンを表示する
- 繰り返し失敗した場合は、サポート窓口や別の本人確認手段を案内する
- 一定回数を超えた場合は、不正対策上の制御とユーザー支援を分けて扱う
本人確認の導入フローだけでなく、再認証や高リスク操作の追加認証にも有効です。例えば、ログイン後の本人確認でカメラの状態が悪い場合、抽象的なエラーを返すよりも、撮影条件を修正する案内を出した方が正当なユーザーの離脱を抑えやすくなります。
ログ設計では個人情報と診断情報を分離する
Feedback Codesを運用改善に利用する場合、コードごとの発生件数、再試行率、成功率を集計すると、本人確認フローのボトルネックを把握できます。例えば、特定の端末や地域で動画品質に関するコードが集中していれば、カメラ起動や通信環境の問題を調査するきっかけになります。
一方で、顔画像や監査用画像は生体情報に関わるため、診断ログへ無制限に含めるべきではありません。ログには次のような情報を中心に記録します。
- セッションを特定するための内部ID
- Feedback Codesの種類と件数
- 再試行回数
- 処理結果と処理時刻
- アプリバージョンや端末情報など、必要最小限の技術情報
顔画像や参照画像を保存・利用する場合は、本人確認の要件、アクセス制御、保持期間、暗号化、監査方針を別途設計します。Feedback Codesのログを増やすことと、生体データの保存範囲を広げることは同じではありません。
従来実装からの移行で確認したいこと
すでにFace Livenessを導入している場合は、低スコア時の処理を見直すことから始められます。
- 低スコア時に一律のエラーメッセージを返していないか
GetFaceLivenessSessionResultsのレスポンスからFeedback Codesを取得しているか- 複数コードを受け取っても一つに上書きしていないか
- コードと画面文言の対応を一元管理しているか
- 再試行の上限や不正検知のルールと矛盾しないか
- 成功率だけでなく、再試行率や離脱率も計測しているか
Feedback Codesは、判定モデルそのものを変更する機能ではありません。低スコアという結果を、ユーザーが改善可能な情報へ変換するための機能です。そのため、価値を引き出すにはAPIの組み込みだけでなく、画面文言、再試行制御、ログ、サポート導線まで一体として設計する必要があります。
Amazon Rekognition Face Livenessは、日本を含む対応リージョンで利用できます。本人確認を実装するエンジニアは、Face LivenessのAPIドキュメントを参照しながら、低スコア時のユーザー体験を「再試行してください」で終わらせない設計へ見直すとよいでしょう。
出典: AWS What’s New
