01 文脈と問題
消費者グループは、1つの共有顧客プラットフォーム上で9つの異なるブランドを運営していました。顧客は一度アカウントを作成し、AppleやGoogle、メールとパスワードでサインインしてどこでも再利用できました。ソーシャルサインインは二次的な利便性ではなく、主要なアクセス手段として意図されていたため、同じ人が異なるプロバイダーを通じて異なる時間に到着することが多かったです。Googleはあるブランド、Appleは別のブランド、パスワードは後からです。
その柔軟性がアイデンティティの問題を生み出しました。顧客が既存のアカウントに属するメールアドレスを持つ新しいAppleまたはGoogleのIDでサインインした場合、プラットフォームはどうするかを決定しなければなりませんでした。メールマッチだけで自動的に2つを結びつけるのは安全ではありません。メールアドレスが一致すれば関係性を示唆しますが、サインインした人が実際にその受信箱を管理している証拠にはなりません。このプラットフォームは、互換性のあるAppleとGoogleのアイデンティティを一つの共有アカウントに結びつける方法を必要としていましたが、メールマッチング自体でアクセス権を付与することなく、Appleのプライベートリレーアドレス、パスワード対応アカウント、リスクの高いサインイン、プロバイダーの障害など、9つのブランドすべてで一貫して対応できるようになっていました。
02 役割と制約
AI Product Manager、私はIDとアカウント連携の設計を端から端まで所有していました。9つのブランドすべてにわたる認証の流れ、同一メールの検出と解決ロジック、リンクをゲートする検証モデル、リスクベースのチャレンジポリシー、プライベートリレーの処理、メール変更時のリンク解除と再検証ルール、ブロックポリシー、そしてプロバイダー障害時のセーフフェイル動作などです。指針としては、メールマッチングはリンクの過程を開始できるが、それを完成させることはできないというものでした。顧客は、2つの認証方法が1つのプロフィールに紐づく前に、既存のアカウントに紐づいたメールへのアクセスを必ず示す必要がありました。
制約は具体的でした。リンクは双方向かつ順序に依存しないものでなければなりません。Googleが先に、次にApple、またはAppleが先に、次にGoogleが同じ共有アカウントに到達しなければなりませんでした。Appleの「Hide My Email」は別途扱う必要がありました。なぜなら、顧客の実際のアカウントのメールアドレスと一致しないプライベートリレーアドレスが、そのアカウントに無言でリンクしてはならないからです。検証は、既に信頼されていた高リスク認証のコードチャレンジメカニズムを再利用しなければならず、新しい制御を発明するのではなく、継承された実証済みのコントロールを結びつける必要がありました。リスクは摩擦を調整しなければなりませんでした:低リスクのサインインは摩擦のないままで、中リスク、高リスク、未確定リスクはOTPが必要でした。繰り返される失敗は、ブランドごとにではなく、すべてのブランドで適用されるブロックポリシーによって抑えられなければなりませんでした。また、プロバイダーの失敗はフェイルセーフでなければならず、顧客に部分的または重複したアカウントを残してはなりませんでした。
03 プロダクトアプローチ
基本的な見直しは、メールマッチを所有権の証明ではなく、認証の始まりとして扱うことでした。AppleやGoogleが顧客を認証した際、プロバイダーの応答とそのメールはサーバー側で共有アカウントプラットフォームに対して解析されました。もしメールが既存アカウントと一致していたとしても、プラットフォームはまだ何もリンクしていません。既存アカウントのメールに一度きりのコードが発行され、顧客がそのコードを入力した後に新しいプロバイダーをリンクさせていました。所有権が証明されてから、1つのクロスブランドプロファイルに2つの認証方法が付与されました。
同じ検証済み経路が両方の接続方向をカバーしていました。もし顧客がGoogleでアカウントを作成し、その後同じ共有メールアドレスで「Appleで続ける」を選択した場合、システムは既存アカウントを検出し、そのメールにコードを送り、認証が成功した後にAppleをリンクさせました。逆に、AppleのShare My Emailが先に、Googleは後で、同じチャレンジを通じて同じ共有アカウントに移行しました。リンク後、顧客はApple、Google、または設定済みのメールアドレスとパスワードでサインインし、同じアカウントにログインすることができました。
AppleのHide My Emailは意図的に独立した道を保ちました。プライベートリレーアドレスが顧客の非公開の個人メールアドレスと一致しない場合、そのIDは同一メールリンクの対象外となりました。リレーを無関係なアカウントにリンクする代わりに、プラットフォームはアクセス制限の説明を示し、別のリレーメールアカウントを作成しました。初回リンクだけでなく、同じアカウントには独自のライフサイクルがあり、顧客はソーシャルアカウントでパスワードを設定し、プライマリメールを変更することができ(これにより前のソーシャルプロバイダーとの連携が解除され再認証が必要)、返還サインインもセッションが発行される前にリスク評価を通過していました。
一致するメールは身元証明のように見えますが、実際には単なる信号に過ぎません。プラットフォームは認証の過程を開くために使われており、アクセス権を付与することはありませんでした。AppleとGoogleの対応アイデンティティは、顧客がメールコードチャレンジを完了した後にのみ1つの共有アカウントに紐づけられたため、マッチすると自動的に2つのログインが統合されるのではなく認証が始まりました。
製造機能
AppleとGoogleのサインイン
1つの認証オーケストレーターは、9つのブランドすべてで「Appleで続けて」「Googleで続けて」とパスワードサインインをルーティングします。
共有クロスブランドアカウント
顧客は一度アカウントを作成し、どのプロバイダーを使ってもすべてのブランドで再利用します。
同一メール検出
サーバーサイドのアイデンティティ解決は、新しいプロバイダーのメールアドレスが既存アカウントに属している場合にフラグを立てます。
メールコードチャレンジ
2つのプロバイダーを連携する前に、既存アカウントのメールに一度きりのコードを入力しなければなりません。
双方向リンク
Googleが先に、次にApple、あるいはAppleが先に、そしてGoogleが同じチャレンジを通じて同じ共有アカウントに移行します。
Appleのプライベートリレーパス
一致しない「私のメールアドレスを隠す」アドレスはリンクされません。代わりに別の中継メールアカウントが作成されます。
リスクベースOTP
リスクの低いサインインにはセッションが与えられます。中、高、未確定のリスクはアクセス前にメールOTPが必要です。
アカウントレベルのブロッキング
繰り返しのOTP、コード、パスワードの失敗により、9つのブランドインターフェースすべてで共有アカウントがブロックされます。
ソーシャル用のパスワード設定
顧客はソーシャルプロバイダーを通じて最初に作成されたアカウントにメールとパスワードのログインを追加できます。
メール変更時のプロバイダーのリンク解除
主メールアドレスを変更すると、以前のソーシャルプロバイダーとの連携が解除され、プロバイダーの再認証が必要です。
安全なプロバイダー故障復旧
AppleやGoogleのサービス障害は安全なエラーを返し、再試行を行い、部分的または重複したアカウントを防ぎます。
パスワード+ソーシャルパリティ
一度パスワードを設定した後、メールとパスワードはAppleやGoogleと連携して同等のログイン機能を持ちます。
また、ソーシャルアカウントのパスワード設定、設定後のメールアドレスとパスワードの追加ログイン、パスワードゲートによるメール変更、メールアドレス変更後のプロバイダー再認証、不確定のリスク処理、そしてどのブランドから購入しても一貫したセキュリティのプロセスが提供されています。
05 アーキテクチャ
9つのブランド体験が1つの認証オーケストレーターに提供されました。どのブランドを通じて来た顧客も同じ流れに振り分けられます:Appleで続け、Googleで続け、メールとパスワードで。AppleとGoogleの応答はプロバイダー応答検証を経て共有アカウントプラットフォームに対するID解決を経て、パスワードサインインは直接共有アカウントに処理されました。アイデンティティ解決は2つの質問を順にしました:このプロバイダーはすでにリンクされているか、もしそうでなければリンク可能な同一メールアカウントがあるか。
そこから流れは明確に境界のある結果へと分岐していきました。適格なメールマッチは既存アカウントのメールアドレスにリンクコードを発行しました。認証が成功するとプロバイダーがリンクされ、失敗すると試みが却下され記録されました。一致しなかったAppleのリレーメールは、限定アクセスの説明と別のリレーメールアカウントにルーティングされました。共有のクロスブランドアカウントに解決されると、アカウントの状態が確認されました。ブロックされたアカウントはブロックされ、アクティブなアカウントはリスクカテゴリに分類されました。Low Riskは認証済みセッションを直接発行しました。中リスク、高リスク、未確定リスクが認証OTPを送信し、繰り返し失敗したチャレンジが一定の閾値まで続き、9ブランドすべてで共有アカウントがブロックされました。アカウント自体がパスワード設定やメール変更を暴露し、主メールアドレスを変更したことで前のソーシャルプロバイダーの連携が解除され、プロバイダーの再認証が必要になりました。プロバイダーサービスの失敗は部分的な状態を生み出さず、安全なエラーを返し、再試行が同じオーケストレーターに戻されるため、AppleやGoogleの失敗した通話では半分リンクされたアカウントや重複アカウントは生成されませんでした。リンク境界は、検証済みプロバイダー応答、互換性のある同一メールマッチ、成功したメールコードチャレンジの3つのチェックを組み合わせており、失敗したコード提出はリスクOTPと同じチャレンジ制御およびブロッキングポリシーを通過しました。
06 測定と分析
アイデンティティの経路は、プロバイダー認証から解決、検証、セッション発行までのファネルとして測定され、低下はそれを引き起こした段階(プロバイダーの対応、同一メール検出、コードチャレンジ、リスクスコアリング、ブロッキング)にたどり着くことができました。利用可能なデータは、Apple、Google、またはアカウント連携のジャーニーを使ったブランドあたり、約4万から10万人の1日訪問者という総合的な採用推計を支持していましたが、分離できない部分は意図的に誇張していませんでした。Apple対Google、登録と再ログイン、新たにリンクしたアカウントと以前に連携したアカウント、成功したコードの課題と放棄されたコードのチャレンジ、リレーメールと共有メールのAppleアカウント、重複アカウントや不正、サポートへの連絡減少は、基礎となる分析データが利用可能になるまで定量化されず、正確な数値として報告されることはありませんでした。
採用指標
Apple、Google、またはリンクドアカウントのジャーニーを使ったブランドごとの1日ごとの訪問者シェアを、9つのブランドにまたがって集計します。
検証ファネル
プロバイダーの応答、同一メール検出、コード送信、コード検証、プロバイダー連携を段階的に測定しました。
リスクおよびOTP指標
リスクカテゴリ分布、中リスク、高リスク、未確定リスクのOTPチャレンジ率、OTPの成功および放棄率。
故障およびブロッキングの指標
リンクコードの失敗、リスクOTP、パスワードは固定閾値にカウントされ、アカウントレベルのブロックが適用されました。
プロバイダーおよびリレーの指標
リレーメールと共有メールのAppleアカウント、そしてプロバイダーサービスの失敗が安全な再試行に割り当てられること。
07 検証とリスク決定
意思決定層は単一のイエスかノーではなく、狭い質問の連続に答えました。このプロバイダーはすでに連携していますか?もしそうでなければ、対象となる同一メールアカウントはありますか?それとも対象外のAppleのリレーアドレスでしょうか?もし対象であれば、メールコードチャレンジを通じて顧客の所有権を証明していますか?そして、解決されたサインインごとにアカウントのリスクカテゴリは何で、セッションを発行する前にOTPが必要でしょうか?低リスクは認証されたセッションに続きました。中リスク、高リスク、未確定リスクはメールOTPが必要でした。リンクコード、リスクOTP、パスワードのいずれであれ、繰り返し失敗したものは、アカウントを一定の閾値でブロックする共有チャレンジ制御機構を通じてカウントされました。ここでのリスクは摩擦と検証強度を調整しました。その識別は単独で決定せず、所有権証明としてリンクをゲートするものに代わることもありません。
アカウント連携はコードチャレンジで保護されており、メールマッチで完了したわけではありません。この境界線は、AppleまたはGoogleの認証済み応答、互換性のある同一メールアカウント、そして成功したメール認証を組み合わせたものでした。それに合うメールがその始まりとなりました。顧客は、1つのクロスブランドプロフィールに2つのログインを紐付ける前に、既存アカウントでメールへのアクセスを示す必要がありました。
08 状況と結果
この実装により、ソーシャル認証は二次的なログインオプションではなく主要なアクセスチャネルとして確立されました。顧客はAppleやGoogleに登録し、同じアカウントを9つのブランドすべてで再利用し、メールコードチャレンジ後に互換性のあるAppleとGoogleのIDをリンクし、ソーシャルアカウントにパスワードを追加し、どのブランドから始めても一貫したセキュリティの道を進むことができました。各ブランドは1日あたり約10万人の訪問者を獲得し、Apple、Google、またはリンクされたアカウントの利用者として、約40%が1日あたり、ソーシャルやリンクされたアクセスでのエンゲージメント率が約40%に達しました。9つのブランドすべてで、約90万人の1日訪問者と約36万件のソーシャルまたはリンクアカウントの訪問があります。その結果、Apple、Google、パスワードアクセスが1つのクロスブランド顧客アカウントを中心に管理された方法で機能し、認証によるリンク、OTPによるリスクの高いサインイン、個別の中継処理、そしてアカウントレベルのブロックで繰り返される失敗を収めるという共有認証基盤が生まれました。これらの数値は概算であり、供給比率に基づいています。彼らは、各プロバイダーや旅程タイプを分けるのではなく、ソーシャルアカウントとリンクドアカウントの活動を組み合わせています。
~40%
ブランドごとにソーシャルまたはリンクドジャーニーを利用する日々の訪問者数
9
消費者ブランドを1つの共有アカウントにまとめています
~360K
Apple、Google、またはリンクされたアカウントの日々のジャーニー
~900K
グループ全体の1日の総訪問者数
09 リフレクション / 次は何だ
決定的な成果はAppleやGoogleのボタンを追加したことではありません。彼らは、9つのブランド間でソーシャルアクセスを安全かつ再利用可能にするためのアイデンティティコントロールを構築していました。プラットフォームは、プロバイダーのアイデンティティが新規か、すでにリンクされているか、リンク可能か、プライベートリレーの使用、パスワード有効か、リスクがあるかブロックされているかを識別でき、互換性のあるアイデンティティはメールコードチャレンジ後にしかリンクできませんでした。次に強化したいのは、現在結合されている分析(Apple対Google、新規と新規登録、新規と以前連携、チャレンジ成功と放棄、リレーと共有メール)を分離し、ファネルを推定ではなく証拠で調整できるようにすることです。リスクモデルのカテゴリー定義と閾値を明示的なガバナンスとともに形式化すること;リレーアカウントのガイダンスを厳格にし、顧客がなぜ「メールを隠す」サインインで別アカウントが作成されるのか理解できるようにし、メール変更のリンク解除および再検証ルールはエンドツーエンドで監査可能に保ちます。その結果、認証層が共有され、対応するメールが自動的にアクセスを許可するのではなく認証を開始し、Apple、Google、パスワードのログインが単一のクロスブランド顧客アカウントを中心に管理され連携可能な方法で機能しました。