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

ユーザーの継続性を維持するため、Uber のエンジニアは Restore Credentials 機能に注目しました。米国では 1 年に 40% の人がスマートフォンを買い替えるため、この機能は不可欠なツールです。ユーザーのニーズとコードのプロトタイピングを評価した後、Uber のライダー アプリに Restore Credentials のサポートを導入しました。認証情報の復元が再ログインの煩雑さを解消するのに役立つことを検証するため、Uber チームは 5 週間にわたって A/B テストを実施しました。この統合により、手動ログインが削減されました。Uber の大規模なユーザーベース全体で考えると、年間 400 万件の手動ログインが不要になる見込みです。

Restore Credentials でログインの煩雑さを解消

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

Uber の Android エンジニアである Thomás Oliveira Horta 氏は次のように述べています。「Uber アプリを毎日使用するユーザーもいますが、必要なときにすぐに使えることを期待しています。新しい Android スマートフォンで配車をリクエストしようとアプリを開いたときに、ログアウトしていることがわかると、不快で不便に感じることがあります。

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

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

Thomás 氏は次のように述べています。「Uber のライダー アプリに Restore Credentials を導入したことで、一貫した使用状況が見られるようになりました。現在のロールアウト段階では、平均して毎日 10,000 人のユニーク ユーザー が Restore Credentials でログインしています。新しいデバイスで初めてアプリを開いたときに、シームレスなエクスペリエンスを利用できました。ロールアウトをユーザーベース全体に拡大すると、その数は2 倍 になると予想しています。」

導入の際の留意事項

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

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

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

エンジニアは、復元に使用する Restore Credentials のエントリ ポイント を選択する際に、完全にシームレスなユーザー エクスペリエンスと実装のシンプルさのトレードオフを慎重に検討しました。最終的に、理想的なバランスを提供するソリューションを優先しました。

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

サーバーサイドの課題への対応

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

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

Restore Credentials のライフサイクルの管理

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

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

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

この機能は、2 か月間の迅速な開発とテスト プロセスを経て、設計から提供まで実現しました。その後、5 週間の A/B テスト（ユーザーによる機能の検証期間）がスムーズに進み、否定できない結果が得られました。 

Restore Credentials によるユーザーの離脱防止

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

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

現在、Restore Credentials は Uber のライダー アプリの標準 機能になりつつあり、トライアル グループの95% 以上のユーザー が登録しています。

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

Restore Credentials の目に見えない大きな影響

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

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

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

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

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