はじめに：ログインはなぜ難しいのか
Airbnbのような両面市場プラットフォームでは、ログイン失敗は単なる技術的問題ではなく、ゲストの予約やホストの収益に直結するビジネス問題です。ユーザーが1月に予約し、6ヶ月後に再びアプリを開く場合、その間にパスワードを忘れたり、SMSを受信できない状況が発生しやすくなります。このような「不定期なアクセス」こそが、むしろ正常な利用パターンなのです。
従来の認証システムは、ログインを単一の質問、すなわち「この人は本人であることを証明できるか？」としてのみ捉えていました。しかしAirbnbは、ここにプロダクトインサイトを加えます。「ユーザーのコンテキストに合った最も簡単な認証方法は何か？」 この問いがプロジェクト全体を変えました。
主要インサイト：「まず識別、次にチャレンジ」(Identify first, then Challenge)
新しいパラダイムは、ログインを2つの段階に分離します。
- 識別(Identify): ユーザーはメール、電話番号、ソーシャルログインなど、希望する方法で自分が誰であるかを伝えます。
- チャレンジ(Challenge): サーバーのポリシーエンジンがアカウント情報とセッションコンテキストを分析し、成功率が最も高い認証手段を提示します。
例えば、ブラジルの旅行者にはSMSよりもWhatsApp OTPが適しており、韓国のホストにはGoogleよりもNaverログインが馴染み深いです。この決定をクライアントではなくサーバーが下すことが重要です。
# ポリシーエンジンの意思決定ロジック例（概念コード）
def select_challenge(user_context, account_info):
"""ユーザーコンテキストとアカウント情報に基づき最適な認証方法を選択します。"""
# 地域別メッセンジャー選好、過去の成功履歴、デバイス対応状況などを考慮
if user_context.region == 'BR' and user_context.has_whatsapp:
return Challenge.WHATSAPP_OTP
if user_context.region == 'KR' and account_info.has_naver:
return Challenge.NAVER_OAUTH
if account_info.last_success_method == 'EMAIL_OTP':
return Challenge.EMAIL_OTP
# デフォルトとしてSMS OTPを返す
return Challenge.SMS_OTP
本論1：「別の方法を試す」— 行き止まりの排除
従来システムの最大の問題は、認証失敗時にユーザーが閉じ込められることでした。パスワードを忘れると再設定フローに進み、SMSを受信できないと最初からやり直す必要がありました。
Airbnbは「すべての認証画面には逃げ道がなければならない」という原則を掲げ、チャレンジピッカーと呼ばれるサーバードリブンコンポーネントを導入しました。このコンポーネントは、主要な認証手段だけでなく、予測成功率に基づいてソートされた代替手段のリストも一緒に返します。
# チャレンジピッカー応答例 (JSON)
{
"primary_challenge": "SMS_OTP",
"alternatives": [
{"method": "EMAIL_OTP", "rank": 1},
{"method": "PASSWORD", "rank": 2},
{"method": "NAVER_OAUTH", "rank": 3}
]
}
これにより、ユーザーが「別の方法を試す」をタップしてもフローが再開されず、コンテキストに応じて適応します。失敗体験が減り、ログイン成功率が自然に向上します。
本論2：サーバードリブン画面レンダリング — コード60%削減の秘密
Airbnbは認証画面自体をサーバースキーマで定義し、クライアントは単純なレンダラーとしてのみ機能するように設計しました。画面の順序、文言、フローロジックがすべてサーバー応答に含まれるため、アプリ更新なしで実験やポリシー変更が可能です。
この転換の効果は即座に現れました:
- クライアントコード60%削減 (Webバンドル100KB削減)
- 実験サイクル短縮: アイデアから結果測定まで数週間 → 数日
- ログイン時間の大幅短縮 (成功率の高いチャレンジを最初に提示)
# サーバードリブン画面定義例（概念）
SCREEN_SCHEMA = {
"type": "challenge",
"title": "本人確認",
"fields": [{"type": "otp_input", "length": 6}],
"primary_action": {
"type": "verify_otp",
"endpoint": "/auth/challenge/verify"
},
"fallback": {
"type": "challenge_picker",
"alternatives": [...]
}
}
注意点：サーバードリブンアーキテクチャの限界
この方式は強力ですが、すべてのチームに適しているわけではありません。
- サーバー依存性の増加: オフライン環境やネットワーク遅延時には認証自体が不可能になる可能性があります。
- 複雑な状態管理: サーバーとクライアントの状態同期が難しく、スキーマバージョン管理が必須です。
- 初期構築コスト: サーバードリブンシステムの設計にはかなりのエンジニアリングリソースが必要です。
また、ポリシーエンジンがまだ初期段階であることも認識すべきです。Airbnbも「最適化の始まりに過ぎない」と述べています。
日本市場への適用コンテキスト
日本では、Yahoo! JAPAN、LINE、PayPayなど国内IDプロバイダーが強い市場です。グローバルサービスでも、日本のユーザーに馴染みのある認証手段を最優先で提供する必要があります。例えば、LINEログインをサポートしないサービスは、日本で大きなユーザー離脱を経験する可能性があります。
また、国内のSI環境ではレガシーシステムとの統合が大きな課題です。サーバードリブン画面を導入するには、既存クライアントロジックを段階的に移行する戦略が必要です。
まとめ：認証はプロダクト体験である
Airbnbの事例は、認証システムが単なる技術的障壁ではなく、プロダクト成長の核心的な原動力であることを示しています。識別-チャレンジモデル、行き止まりの排除、サーバードリブンレンダリングは、すべてユーザー行動への深い理解から生まれました。
次のステップとして、認証専用のポリシーエンジンを設計してみたり、サーバードリブンUIフレームワーク（例：Formly、JSON Forms）を学習することをお勧めします。認証は進化し続ける領域であり、コンテキストに応じた最適な体験を提供することが重要です。
合わせて読みたい記事
本記事はAirbnbエンジニアリングブログの事例を基に再構成したものです。
