Uber は世界最大のライドシェアリング会社であり、何百万人もの人々を目的地まで送り届けるとともに、フード デリバリー、医療機関への送迎、貨物輸送もサポートしています。アクセスが簡単であることは、この機能の成功に不可欠です。ユーザーは新しいデバイスに切り替える際に、Uber アプリに再度ログインしたり、SMS ベースのワンタイム パスワード認証を行ったりすることなく、シームレスに移行できることを期待しています。デバイスの買い替え頻度が高いことは、ユーザー維持率を高めるうえで課題であると同時に、チャンスでもあります。

ユーザーの継続性を維持するため、Uber のエンジニアは Restore Credentials 機能を利用しました。これは、米国の 40% の人が毎年スマートフォンを買い替える時代において不可欠なツールです。ユーザーの需要とコードのプロトタイピングを評価した結果、Uber 乗客アプリに認証情報の復元サポートを導入しました。認証情報の復元が再ログインの際の摩擦を軽減するのに役立つことを検証するため、Uber チームは 5 週間にわたって A/B テストを実施し、成功を収めました。この統合により、手動ログインが減少し、Uber の大規模なユーザーベース全体で年間 400 万件の手動ログインが削減されると推定されています。

認証情報の復元によるログインの煩雑さの解消

以前は、定期的なデータ バックアップや BlockStore などのソリューションを使用して、新しいデバイスでアカウントを復元しようとしていましたが、どちらのソリューションでも、認証トークンをソースデバイスから宛先デバイスに直接共有する必要がありました。トークン情報は非常に機密性が高いため、これらのソリューションは、移行先のデバイスのログイン フィールドを事前入力し、ログイン フローでの摩擦を軽減するために、ある程度のみ使用されます。パスキーは安全かつ迅速なログイン方法を提供するためにも使用されますが、ユーザーが開始する性質上、シームレスなデバイス移行への影響は限定的です。

Uber の Android エンジニアである Thomás Oliveira Horta 氏は、「Uber アプリを毎日使用するユーザーもいれば、必要なときにアプリが動作することを期待するユーザーもいます」と述べています。新しい Android スマートフォンで配車をリクエストしようとアプリを開いたときに、ログアウトしていることに気づくのは、不快で嫌な体験です。

認証情報の復元により、エンジニアはこのギャップを埋めることができました。API は古いデバイスで一意のトークンを生成します。このトークンは、ユーザーが標準のオンボーディング プロセスでアプリデータを復元する際に、シームレスかつサイレントに新しいデバイスに移動されます。このプロセスでは、Android OS のネイティブのバックアップと復元のメカニズムを活用して、アプリのデータとともに復元キーを安全に転送します。この合理化されたアプローチにより、シンプルで安全なアカウント移行が保証され、ユーザー入力や開発オーバーヘッドなしで Uber のセキュリティ要件を満たすことができます。

注: 復元キーとパスキーは、同じ基盤となるサーバー実装を使用します。ただし、データベースに保存する際は、これらを区別する必要があります。ユーザーが作成したパスキーはユーザーが直接管理できますが、復元キーはシステムによって管理され、ユーザー インターフェースには表示されないため、この区別は重要です。

「Uber の乗客向けアプリで認証情報の復元が採用されたことで、継続的な利用が見られるようになりました」と Thomás 氏は述べています。現在のロールアウト段階では、平均して 1 日あたり 10,000 人のユニーク ユーザーが認証情報の復元を使用してログインしており、新しいデバイスでアプリを初めて開く際にシームレスな体験を楽しんでいます。全ユーザーにロールアウトを拡大すれば、この数は倍増すると予想しています。」

実装に関する考慮事項

「サンプルコードとドキュメントに沿って Android 側で少し調整するだけで、簡単に統合できました」と Thomás 氏は述べています。アプリではすでにパスキーに認証情報マネージャーを使用しており、バックエンドではわずかな調整しか必要ありませんでした。そのため、認証情報マネージャーの依存関係を最新バージョンに更新するだけで、新しい Restore Credentials API にアクセスできるようになりました。同じパスキー作成フローで復元キーを作成しました。アプリが新しいデバイスで起動されると、アプリはサイレント パスキー取得を試行して、このキーを積極的にチェックします。復元キーが見つかった場合は、すぐに使用されてユーザーが自動的にログインし、手動ログインはバイパスされます。」

開発プロセス全体を通して、Uber のエンジニアは、適切なエントリ ポイントの選択からバックエンドでの認証情報のライフサイクルの管理まで、実装中にいくつかの課題を乗り越えました。

Restore Credentials エントリ ポイントの選択

エンジニアは、復元に使用する認証情報の復元 エントリ ポイントを選択する際に、完璧にシームレスなユーザー エクスペリエンスと実装の簡便さのトレードオフを慎重に検討しました。最終的に、理想的なバランスを実現するソリューションが優先されました。

「これは、アプリの起動時、またはデバイスの復元とセットアップのバックグラウンドで BackupAgent を使用して行われる可能性があります」と Thomás 氏は述べています。「バックグラウンド ログイン エントリ ポイントはユーザーにとってよりシームレスですが、バックグラウンド オペレーションで課題が生じ、BackupAgent API の使用が必要になります。これは、Uber のような大規模なコードベースでは複雑さが増すことにつながります。」Uber は、初回アプリ起動時にこの機能を実装することにしました。これは、手動ログインよりも大幅に高速です。

サーバーサイドの課題に対処する

バックエンド WebAuthn API との統合中に、サーバーサイドでいくつかの課題が発生しました。これらの API の設計では、ユーザー確認が常に必要であり、すべての認証情報がユーザーのアカウント設定に一覧表示されることが想定されていましたが、これらの想定はユーザー管理以外の認証情報復元キーには当てはまりませんでした。

Uber チームは、WebAuthn サービスに小さな変更を加え、パスキーと復元認証情報を区別して適切に処理するための新しい認証情報タイプを作成することで、この問題を解決しました。

Restore Credentials のライフサイクルを管理する

Uber のエンジニアは、バックエンドで認証情報キーを管理する際にいくつかの課題に直面しました。バックエンド エンジニアの Ryan O’Laughlin から専門的なサポートを受けました。

• 孤立した鍵の防止: 登録済みの公開鍵が「孤立」しないように、削除するための戦略を定義することが大きな課題でした。たとえば、アプリをアンインストールするとローカル認証情報が削除されますが、このアクションはバックエンドに通知されないため、サーバーに未使用の鍵が残ります。
• 鍵の有効期間のバランス: 鍵には、エッジケースを処理するのに十分な長さの有効期間が必要でした。たとえば、ユーザーがバックアップと復元を行い、古いデバイスから手動でログアウトすると、その古いデバイスから鍵が削除されます。ただし、新しいデバイスが引き続き使用できるように、鍵はサーバー上で有効な状態を維持する必要があります。
• 複数のデバイスのサポート: ユーザーが複数のデバイスを所有している可能性があり（どのデバイスからでもバックアップと復元を開始できる）、バックエンドではユーザーごとに複数の復元認証情報（デバイスごとに 1 つ）をサポートする必要がありました。

Uber のエンジニアは、新しい認証情報の登録と認証情報の使用に基づいてサーバーサイドの鍵削除ルールを確立することで、これらの課題に対処しました。

この機能は、2 か月間の迅速な開発とテストのプロセスを経て、設計からリリースまで完了しました。その後、5 週間の A/B テスト（ユーザーによる機能の検証期間）がスムーズに実施され、確実な結果が得られました。 

認証情報の復元によるユーザーの離脱防止

新しいデバイスでの手動ログインを不要にしたことで、Uber は、新しいデバイスでのログイン フローを途中で放棄する可能性があったユーザーを維持しました。お客様の利便性の向上は、さまざまな改善に反映されています。一見するとわずかな改善に見えるかもしれませんが、Uber のユーザーベースの規模で考えると、その影響は非常に大きくなります。

• 手動ログイン（SMS OTP、パスワード、ソーシャル ログイン）が 3.4% 減少しました。
• SMS OTP を必要とするログインの費用が 1.2% 削減されました。
• Uber のアクセス率（アプリのホーム画面に正常にアクセスしたデバイスの割合）が 0.575% 増加しました。
• 乗車が完了したデバイスが 0.614% 増加しました。

現在、認証情報の復元は Uber の乗車用アプリの標準機能になるべく順調に進んでおり、トライアル グループの95% 以上のユーザーが登録しています。

新しいデバイスのセットアップ時に、ユーザーはバックアップからアプリデータと認証情報を復元できます。復元するアプリとして Uber を選択し、バックグラウンド プロセスが完了すると、新しいデバイスでアプリを初めて起動したときに、ユーザーは自動的にログインされます。

認証情報の復元による目に見えない大きな影響

今後数か月以内に、Uber は認証情報の復元の統合を拡大する予定です。トライアルの結果から、この変更により年間 400 万件の手動ログインが不要になると推定しています。アプリへのアクセスを簡素化し、重要な課題を解消することで、1 回の乗車ごとに、より満足度の高い忠実な顧客ベースを積極的に構築しています。

Uber のリード プロダクト マネージャー（コア ID）である Matt Mueller 氏は次のように述べています。「Google の RestoreCredentials を統合することで、ユーザーが新しいデバイスで期待するシームレスな『すぐに使える』エクスペリエンスを提供できるようになりました。」「これにより、収益が目に見えて増加しました。ログインの煩雑さを軽減することが、ユーザー エンゲージメントとユーザー維持率を高める鍵となることが証明されました。」

アプリのログイン エクスペリエンスを向上させましょう

認証情報の復元を使用してデバイスを切り替える際にシームレスなログイン エクスペリエンスを実現する方法については、ブログ投稿をご覧ください。Android Studio Otter の最新の Canary 版では、新しい機能を使用してバックアップと復元のメカニズムをモックできるため、統合を検証できます。

認証情報マネージャー を初めて使用する場合は、統合に役立つ公式のドキュメント、Codelab、サンプルを参照してください。