今日のデジタル環境において、ユーザーがアプリに初めて触れる瞬間は、多くの場合、最も重要な瞬間です。しかし、数十年にわたり、この最初の操作は従来の確認方法の煩雑さによって妨げられてきました。このたび、Google が発行する新しい確認済みメールアドレスの認証情報がリリースされました。デベロッパーは、Android の認証情報マネージャー Digital Credential API から直接取得できます。

問題: 現代における認証の煩雑さ

現在の認証は、セキュリティと利便性のトレードオフによって定義されます。ユーザーが提供したメールアドレスを所有していることを確認するには、通常、メールまたは SMS で送信されるワンタイム パスワード（OTP）または「マジックリンク」を使用します。

効果的ではあるものの、これらの従来の手順には次のような大きな課題があります。

• コンテキストの切り替え: ユーザーはアプリを離れ、受信トレイまたはメッセージ アプリを開いてコードを探し、アプリに戻る必要があります。このプロセスで、多くの潜在的なユーザーが離脱してしまいます。
• 配信の問題: メールは無料ですが、遅延したり、迷惑メール フォルダに振り分けられたりすることがあります。
• オンボーディングの煩雑さ : 「確認ループ」に費やされる時間が 1 秒増えるごとに、ユーザーが興味を失う可能性が高まり、コンバージョン率に直接影響します。

ソリューション: シームレスな確認済みメールアドレス

Google は、暗号で確認されたメールアドレスの認証情報を Android デバイスに直接発行するようになりました。この確認済みメールアドレスの認証情報は、Credential Manager APIを介して配信されます。これは、Android によるW3C's Digital Credential API標準の実装です。

ユーザーは、外部チャネルを介してメールアドレスを手動で確認する必要がなくなります。デベロッパーは、アカウント作成フロー、復元プロセス、高リスクのステップアップ認証のいずれを構築する場合でも、API を使用して、確認済みのユーザー クレームを安全に配信できます。

この特定の確認済みメールアドレスは、デバイス上のユーザーの Google アカウントから安全に取得されますが、基盤となる Digital Credentials API は発行元に依存しません。これによりオープンなエコシステムが促進され、メールアドレスのクレームを含むデジタル認証情報の所有者は、アプリにその確認を提供できます。

ユーザー エクスペリエンス

この API の魅力は、エンドユーザーにとってのシンプルさにあります。OTP コードを探す必要がなく、Android OS に直接統合されています。

1. 開始: ユーザーがメールアドレス入力フィールドにフォーカスするか、[登録] または [アカウントを復元] ボタンをタップすると、プロセスが開始されます。ページ読み込み時にプロセスを開始することもできます。
2. 透明性: ネイティブの Android ボトムシートが表示され、リクエストされているデータ（ユーザーの確認済みメールアドレスなど）が明確に表示されます。
3. ワンタップで同意: ユーザーは [同意して続行] をタップするだけでデータを共有できます。
4. 即座に進行: 同意すると、アプリはすぐにデータを受け取ります。登録フローまたはアカウント復元フローでは、ユーザーをパスキーの作成にシームレスに移行できます。これにより、次のことが保証されます。
   1. 従来のユーザー名/パスワード登録とは異なり、ユーザーはユーザー情報を手動で入力する必要がありません。  
   2. 次回のログインがさらに迅速かつ安全になります。

ユースケース 1. 登録

ユーザーが [登録] をタップした瞬間に確認済みメールアドレスを取得することで、オンボーディングを迅速化します。確認済みメールアドレスの取得とパスキーの作成を組み合わせることを強くおすすめします。パスキーの作成も Credential Manager API の一部です。

注: ユーザーの名、姓、名前、プロフィール写真、確認済みメールアドレスに関連付けられたホスト ドメインなど、確認されていない他のフィールドを取得することもできます。

ユースケース 2. アカウント復元 

ユーザーが迷惑メール フォルダで復元コードを探す煩わしさを解消します。デバイスに安全に保存されている確認済みメールアドレスを使用して、アカウントを復元できるようにします。

ユースケース 3. 機密情報に関する操作の再認証 

設定の変更やプロフィール情報の更新など、機密情報に関するユーザー操作を、簡単な再認証手順を必須とすることで保護します。OTP の代わりに、デバイスの確認済みメールアドレスを使用して、煩雑さの少ない確認を提供できます。

重要な考慮事項

Digital Credentials API を中心に認証アーキテクチャを設計する際は、次の点に注意してください。

• アカウントのサポート: Google が発行する特定のメールアドレスの認証情報については、通常の一般ユーザー向け Google アカウントのみがサポートされています（Workspace アカウントと管理対象アカウントは現在サポートされていません）。Credential Manager API 自体は発行元に依存しないため、他の ID プロバイダは独自のアカウント サポート ポリシーで認証情報を発行できます。
• その他のユーザーデータ: メールアドレス以外に、ユーザーの名、姓、フルネーム、プロフィール写真をリクエストできます。ただし、Google によって確認されるのはメールアドレスのみです。
• @gmail アカウントの自動確認: API は、すべての一般ユーザー向け Google アカウントの確認済みメールアドレスを提供します。@gmail.com ユーザーを自動的に確認し、カスタム ドメインを既存の確認フロー（OTP フローなど）にルーティングすることをおすすめします。これにより、Google が直接管理していない外部ドメインへの長期的なアクセスを維持できます。
• Google でログインを補完: 新しい確認済みメールアドレスの認証情報と Google でログイン API の両方で確認済みメールアドレスが提供されますが、どちらを選択するかは、想定されるユーザー エクスペリエンスによって異なります。
  • ユーザーがフェデレーション ログイン セッションを作成する場合は、Google でログインを使用 します。
  • ユーザーがユーザー名/パスワードまたはパスキーを使用して従来の方法でログインしたいが、OTP の手動操作なしでメールアドレスを自動的に確認したい場合は、確認済みメールアドレスを使用 します。

まとめと次のステップ

Credential Manager API を介して新しい確認済みメールアドレスを統合することで、オンボーディングの煩雑さを大幅に軽減し、ユーザーに効率的で安全な認証ジャーニーを提供できます。これは、「確認」がユーザーにとって手動の作業ではなく、ネイティブ モバイル エクスペリエンスのシームレスな統合された一部となる未来への移行を意味します。

これがアプリにどのように適合するかを確認する準備はできましたか？まず、プロジェクトを最新の Credential Manager API に更新し、統合ガイドをご覧ください。この効率化された確認方法が、アカウント作成の最適化から再認証フローの強化まで、重要なユーザー ジャーニーをどのように簡素化できるかをご確認ください。