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

ユーザーの継続性を維持するため、Uber のエンジニアは Restore Credentials 機能に注目しました。米国では 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 との統合中に、いくつかのサーバーサイドの課題が発生しました。これは、ユーザー確認が常に必要であり、すべての認証情報がユーザーのアカウント設定に一覧表示されることを前提として設計されているためです。これらの前提条件は、ユーザーが管理しない 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 万件の手動ログインが不要になると推定しています。アプリへのアクセスを簡素化し、重要な課題を解消することで、乗車ごとに顧客満足度とロイヤリティを高めています。

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

アプリのログイン エクスペリエンスを向上させる準備はできましたか？

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

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