パスキーでドライブする アカウント統合（OAuth/OIDC Numa (Immersion) Workshop 2026）

2026/08/25 開催
OAuth/OIDC Numa (Immersion) Workshop 2026 発表資料

パスキーでドライブする
アカウント統合
アカウント統合はなぜ進まないのか。パスキーはそれをどう変えうるか。

株式会社メルカリ
狩野 達也

Transcript

1. Passkey-Driven Account Integration パスキーでドライブする アカウント統合 アカウント統合はなぜ進まないのか。パスキーはそれをどう変えうるか。 Mercari — kokukuma
2. AGENDA 目次 1 身近に転がっていたアカウント統合の話題 2 アカウント統合の難しさ 3 パスキーでドライブするアカウント統合 2
3. イントロ アカウント統合とは 統合前: サービスごとに別アカウント サービスA サービスB サービスC 統合 同じ組織内の複数サービスが別々に持っているアカウ ントを、1つに統合すること よくある背景・ねらい 統合後: 1つのアカウントで全サービス • 機能の共通利用・開発の効率化 • 1アカウントで完結する UX の向上 • 複数サービスの横断利用によるシナジー創出 サービスA サービスB サービスC 3
4. イントロ アカウント統合、どうやるんだろうね？ 一番シンプルに考えると: ID連携から始めて、認証を OP に寄せていく STEP 1 ID連携の形でスタート STEP 2 全アカウントに連携を広げる STEP 3 RP独自の認証を削除 どれか (例: サービスB) を OP、他を RP とし て ID連携できるようにする まず新規アカウントで OP アカウントを必須 に。次に既存アカウントの連携を進める 各 RP のログインを OP のログインプロセス に統一する ✕ A B (OP) C A・Cからは Bのアカウントでも ログイン可能に (点線) A B (OP) 全ユーザが OP アカウントと 連携済みに C A ✕ B (OP) C A・C独自のアカウントを削除し ログインは OP に一本化 現実には、既存アカウントの移行・削除まで含めて 数年単位の重い migration になりがち 4
5. SECTION 1 身近に転がっていた アカウント統合の話題 5
6. 1. 身近なアカウント統合の話題 身近に転がっていた「アカウント統合」の話 最近見聞きした 3 つのケースを紹介します Case 1 C2Cマーケットプレイスを提供する会社の「海外ユーザ向け」アカウント Case 2 B2C / C2B向け機能を提供する会社の「パートナー向け」アカウント Case 3 多種多様な金融サービスを展開する会社の「国内ユーザ向け」アカウント 6
7. 1. 身近なアカウント統合の話題 Case 1: C2Cマーケットプレイス — 海外ユーザ向けアカウント • C2Cマーケットプレイスを国内と US で展開 JP ID専任チーム US ID専任チーム JPアカウント USアカウント • クロスボーダー事業 (TW / HK / US) も拡大中 • US では「クロスボーダー」と「US向けC2C」で アカウントが別々 UX がよくないし、機能の共通利用もできない → 統合したほうがいいんじゃない？ C2C for JP XB C2C for US 重要な点 ・2つのアカウントの統合 ・それぞれに専任チームがいる ・機能共通利用、UX改善 7
8. 1. 身近なアカウント統合の話題 Case 2: B2C / C2B向け機能を提供する会社 — パートナー向けアカウント • B2C / C2B 向けの機能を複数サービスで提供 JP ID専任チーム Product Team • 外部パートナー向け UI があり、 アクセス用にアカウントを発行 • 古いアカウントが一つだけ全然違う管理 Aと同じアカウント なんでこれだけ独自に？ → 統合したほうがいいんじゃない？ サービスA サービスB サービスC 重要な点 ・2つのアカウントの統合 ・専任チームがいるわけではない ・機能共通利用 (負債解消) 8
9. 1. 身近なアカウント統合の話題 Case 3: 多種多様な金融サービスを展開する会社 — 国内ユーザ向けアカウント • 多種多様な金融サービスを展開 Product Team A Product Team B Product Team C サービスA サービスB サービスC • サービス毎別のアカウント。専任の管理チームなし。 • サービス間のデータ連携でシナジーを産んだ実例あり → 統合したほうがいいんじゃない？ データ連携でシナジー実証済み 重要な点 ・多くのアカウントの統合 ・専任チームがいるわけではない ・サービス連携によるシナジー 9
10. 1. 身近なアカウント統合の話題 Case のまとめ いろんな状況、いろんな目的で「アカウント統合したい」という話が出てくる 統合したいアカウント 専任チーム 目的 Case 1: US向けアカウント 2つのアカウント統合 あり 機能共通利用、UX改善 Case 2: パートナー向けアカウント 2つのアカウント統合 微妙 機能共通利用 (負債解消) Case 3: 国内ユーザ向けアカウント 複数のアカウント統合 なし サービス連携によるシナジー 10
11. 1. 身近なアカウント統合の話題 Case のまとめ いろんな状況、いろんな目的で「アカウント統合したい」という話が出てくる 統合したいアカウント 専任チーム 目的 Case 1: US向けアカウント 2つのアカウント統合 あり 機能共通利用、UX改善 Case 2: パートナー向けアカウント 2つのアカウント統合 微妙 機能共通利用 (負債解消) Case 3: 国内ユーザ向けアカウント 複数のアカウント統合 なし サービス連携によるシナジー どれも、うまく進んではいない！！ 11
12. SECTION 2 アカウント統合の難しさ 12
13. 2. アカウント統合の難しさ アカウント統合の難しさ 技術的な難しさ ＋ 組織的な難しさ ＞ 認識されている価値 技術的な難しさ 組織的な難しさ 価値提供の難しさ 止めずに移行する migration の重さ どのアカウントを残すかという意思決定 統合の価値が「大きい」と認識されにく い 認識されて いる価値 技術的 難しさ 難しさが価値を 上回ると統合は 止まる 組織的 難しさ 13
14. 2. アカウント統合の難しさ Case 1: C2Cマーケットプレイス — 海外ユーザ向けアカウント 「組織的難しさ」の大きさ、「認識されている価値」の小ささ 重要な点 ・2つのアカウントの統合 ・それぞれに専任チームがいる ・機能共通利用、UX改善 どちらに寄せ るか決められ ない 数年掛かり。 認証強度・身 元確認強度の 差。 共通機能が使 える、だけ... 技術的 難しさ 組織的 難しさ 認識されて いる価値 14
15. 2. アカウント統合の難しさ Case 2: B2C / C2B向け機能を提供する会社 — パートナー向けアカウント 「組織的難しさ」は小さいが、「認識されている価値」も小さい… 重要な点 ・2つのアカウントの統合 ・専任チームがいるわけではない ・機能共通利用 (負債解消) みんな専任チ ームが管理す べきと思って る 数年掛かり 技術的 難しさ 組織的 難しさ 負債解消が主 認識されて いる価値
16. 2. アカウント統合の難しさ Case 3: 多種多様な金融サービスを展開する会社 — 国内ユーザ向けアカウント 「認識されている価値」が大きい分、「組織的難しさ」もより大きい… 重要な点 ・多くのアカウントの統合 ・専任チームがいるわけではない ・サービス連携によるシナジー 調整コストが 非常に高い 数年掛かりの migration が複 数 認識されて いる価値 組織的 難しさ シナジー創出 は実証済み 技術的 難しさ 16
17. 2. アカウント統合の難しさ アカウント統合の難しさ (まとめ) 技術的な難しさ ＋ 組織的な難しさ ＞ 認識されている価値 技術的な難しさ 組織的な難しさ 価値提供の難しさ • 既存データ・ユーザを抱えたまま、基本止 • 今までコストを掛けてきたものを「捨てる • 対社内価値・対顧客価値の両方を示す必要 めずに替える 」難しさ • UX や認証・身元確認強度の差も埋める • 各アカウント管理組織の力関係・知名度・ • 効くのは中長期のシナジーで、短期には見 えにくい 機能に左右される • 数年かけて実施 認識されている価値 技術的 難しさ 組織的 難しさ 17
18. 2. アカウント統合の難しさ 事例に学ぶ「難しさ」の解消 実例はいくつもあり、いろんなやり方が考えられる LINE + Yahoo! JAPAN 統合ではなく「連携」を選ぶ まずアカウント連携で相互利用を実現し、 完全統合は段階的に (連携解除も許す) Nintendo 上位アカウントを新設する 旧アカウント (NNID 等) を消さず、 新しい Nintendo Account の下にぶら下げる Disney + Hulu (US) サービスごと片側に寄せる サービス統合 (Hulu on Disney+) に合わせて、 アカウントも Disney 側へ誘導 Google + YouTube 長期併存させながら移行 買収後、Google アカウントでのログインを併存させ、 数年かけて一本化 標準仕様は、なさそう Account migration / porting 系の議論は「別組織間」の移行の話なので少し違う 18
19. SECTION 3 パスキーでドライブする アカウント統合 19
20. 3. パスキーでドライブするアカウント統合 パスキーでドライブするアカウント統合 パスキー導入は、この不等式の両辺に効くのではないか パスキー導入は、アカウント統合の 「認識されている価値」を増やす 難しさを軽減 技術的 難しさ 組織的 難しさ パスキー導入は、アカウント統合の 技術的・組織的難しさを軽減する 認識されて いる価値 価値を増やす 20
21. 3. パスキーでドライブするアカウント統合 前提: パスキーの導入と運用 モチベーション パスキーの導入 パスキーの運用 • フィッシング耐性 • FIDO サーバの導入 • 登録・利用の促進 • 認証 UX の改善 • パスキー登録・管理画面 • ログイン導線の改善 • SMS OTP コスト削減 • ログイン・追加認証としての利用 • パスキー以外の認証要素の整理 • (金融庁) 多要素認証の規制対応 例: 金融庁ガイドラインで、フィッシング耐性のある 多要素認証の必須化へ • リカバリの改善 実装ガイド: passkeys.dev 参考: FIDO Alliance「Passkey Central」/ web.dev の パスキー導入事例 利用が広がらないと便益 (コスト減・フィッシング耐性) は実現しない。 モチベーションの達成には、導入だけでなくその後の運用が重要（そして重い ） 21
22. パスキー導入は、統合の「認識されている価値」を増やす アカウント統合しないまま、パスキーを導入すると… 各サービスが独立にパスキー導入 FIDO Server FIDO Server FIDO Server サービスA サービスB サービスC 別々の RP ID で登録 別々の RP ID で登録 別々の RP ID で登録 導入コストも、その後の運用コストも、サービスの数だけ掛かる 22
23. パスキー導入は、統合の「認識されている価値」を増やす アカウント統合しないまま、パスキーを導入すると… 各サービスが独立にパスキー導入 → 後からサービスBへ統合しようとしても、パスキーは移行できない ✕ ✕ FIDO Server ✕ FIDO Server FIDO Server サービスA サービスB サービスC 再度パスキー登録が必要 ✕ 再度パスキー登録が必要 補足: Signal API (WebAuthn Level 3) サービスごとに掛けたコストは結局消え、 ユーザにも再登録の負荷が掛かる RP から認証器側の資格情報に「削除」や「name / displayName の更新」は通知できる。 しかし RP ID と user handle は登録後に変更不可 → パスキー を統合先へ移す手段はない 23
24. パスキー導入は、統合の「認識されている価値」を増やす アカウント統合してから、パスキーをしよう アカウント統合してから、統合先のパスキーに依存する FIDO Server サービスA サービスB サービスC 先にアカウント統合してからパスキーを導入すれば、 運用コストとユーザ負担を大きく削減できる 24
25. パスキー導入は、統合の「認識されている価値」を増やす とは言えの疑問… 「アカウント統合をパスキー導入の前提にすると 、パスキー導入までめちゃくちゃ時間が掛かるの では？」 特に規制対応などで、そんなに待てないケースもある 25
26. パスキー導入は、統合の「認識されている価値」を増やす とは言えの疑問… 「アカウント統合をパスキー導入の前提にすると 、パスキー導入までめちゃくちゃ時間が掛かるの では？」 特に規制対応などで、そんなに待てないケースもある そこで： 「共通利用できるパスキーの導入」から始 めるアカウント統合 25
27. パスキー導入は、統合の「認識されている価値」を増やす とは言えの疑問… 「アカウント統合をパスキー導入の前提にすると 、パスキー導入までめちゃくちゃ時間が掛かるの では？」 特に規制対応などで、そんなに待てないケースもある 01 どうやってその状況を作るのか？ 02 ユーザ体験的にはどうなるか？ 03 どんな利点が出てくるのか？ 04 Security Considerations そこで： 「共通利用できるパスキーの導入」から始 めるアカウント統合 25
28. パスキー導入は、統合の技術的・組織的難しさを軽減する 「共通利用できるパスキー導入」から始めるアカウント統合 FIDO Server まずは主軸となるサービスBに 普通にパスキーを導入する サービスA サービスB サービスC (RP) (OP / 主軸) (RP) ① 主軸となるアカウントで パスキー導入 (OIDC) で RP に ② ID連携 ID mapping を保持 で OP のパスキーを ③ RP 使えるように (ROR+FiPA) ④ ログイン時の連携作成・ アカウント作成をサポート 27
29. パスキー導入は、統合の技術的・組織的難しさを軽減する 「共通利用できるパスキー導入」から始めるアカウント統合 FIDO Server 普通にOpenID Connectで ID連携 ※「Sign in with サービスB」は提供 しない。 サービスA サービスB サービスC (RP) (OP / 主軸) (RP) ID mapping 保持 OIDC 認可サーバ ① 主軸となるアカウントで パスキー導入 (OIDC) で RP に ② ID連携 ID mapping を保持 で OP のパスキーを ③ RP 使えるように (ROR+FiPA) ④ ログイン時の連携作成・ アカウント作成をサポート 28
30. パスキー導入は、統合の技術的・組織的難しさを軽減する 「共通利用できるパスキー導入」から始めるアカウント統合 FIDO Server ROR でパスキー認証 サービスBのパスキーを使って、 サービスAにログイン可能に。 （RORとFiPAを利用） サービスA サービスB サービスC (RP) (OP / 主軸) (RP) ID mapping 保持 OIDC 認可サーバ ① 主軸となるアカウントで パスキー導入 (OIDC) で RP に ② ID連携 ID mapping を保持 で OP のパスキーを ③ RP 使えるように (ROR+FiPA) ④ ログイン時の連携作成・ アカウント作成をサポート 29
31. パスキー導入は、統合の技術的・組織的難しさを軽減する ③を支える 2つの仕様: ROR と FiPA ROR: Related Origin Requests FiPA: OAuth 2.0 for First-Party Apps WebAuthn Level 3 IETF Draft • RP ID が別のoriginのサイトでも、そのパスキーを利用できる • ファーストパーティのアプリが、リダイレクト無しで認可フ ようにする仕様 ローを実行するための仕様 • RP IDのdomain側が /.well-known/webauthn に許可する • WebAuthn の assertion を Authorization Challenge Endpoint origin を列挙する に提示し、認可コード → トークンを取得できる – 許可できる origin は 5 ラベル程度が上限 – RP の画面から離れずに「OP のパスキーでログイン」が完結する – Chrome / Safari 等の主要ブラウザが対応済み この 2つを組み合わせると「サービスBのパスキーを使って、画面遷移なしで、ID Tokenを取得する」ことができる 30
32. パスキー導入は、統合の技術的・組織的難しさを軽減する ③の流れ: RP 上で OP のパスキーを使ってログイン ユーザ / 認証器 サービスA (RP) サービスB (認可サーバ) サービスB (FIDOサーバ) パスキーでログイン開始 credentials.get( rpId = OPのRP ID ) ← ROR assertion (パスキー認証結果) assertion を Authorization Challenge Endpoint へ assertion 検証 検証 OK (OP ユーザ特定) 認可コード 認可コードを token endpoint へ ID token / access token ID token の sub × ID mapping で RP側アカウントを特定 → ログイン完了 31
33. パスキー導入は、統合の技術的・組織的難しさを軽減する 「共通利用できるパスキー導入」から始めるアカウント統合 FIDO Server ROR でパスキー認証 ROR でパスキー認証 サービスA サービスB サービスC (RP) (OP / 主軸) (RP) ID mapping 保持 OIDC OIDC 認可サーバ ① 主軸となるアカウントで パスキー導入 (OIDC) で RP に ② ID連携 ID mapping を保持 mapping 無し! アカウントが無ければ: 新規作成して連携 (通常のID連携と同様) で OP のパスキーを ③ RP 使えるように (ROR+FiPA) ④ ログイン時の連携作成・ アカウント作成をサポート 32
34. パスキー導入は、統合の技術的・組織的難しさを軽減する ユーザ体験的にはどうなるか？ フォーカス: RP でのパスキーを使ったログイン RPのログイン画面 あり そのままログイン完了 メールアドレス kokukuma@mail.com サービスB のパスキー OP のパスキー で認証 ID mapping ある？ なし Conditional UI (autofill) に OP のパス キー候補が出る 「新規登録」を選択 → 登録画面 kokukuma@mail.com 登録 サービスB (OP) の情報をもとにアカウントを作成 補足: 以下は通常と同じ ・OP でのパスキー登録・利用 — 通常のパスキーと同様 ・RP での ID連携 — 通常の ID連携と同様 33
35. パスキー導入は、統合の技術的・組織的難しさを軽減する どんな利点が出てくるのか？ サービスA・Cに対して、 メリットを提供する形で、 アカウント統合を進められる アカウント統合をまたずに パスキー導入・運用が始め られる FIDO Server ROR でパスキー認証 ROR でパスキー認証 サービスA サービスB サービスC (RP) (OP / 主軸) (RP) OIDC OIDC 認可サーバ 32
36. パスキー導入は、統合の技術的・組織的難しさを軽減する Security Considerations 1. どうやってFirst-partynessを検証しますか？ RORでassertion取れるRPを許可制にしてる状態なので、assertion取れることを持って、First partyと認識。 2. Phishing/Credential Stuffing Attacksリスクの増加 Authorization Challenge Endpointが、パスワード・OTPを受け入れてるならそうだけど、 passkeyしかサポートしないのであれば、問題ないのではないか？ 3. 連携作成時のアカウント結合 (account linking / pre-hijacking) メールアドレス一致などの属性による自動紐付けはしない。既存アカウントへの連携は、必ず RP 側の既存認証を通す 4. RP が OP より高い身元確認・認証強度を要求していたら？ ID 連携の作成時に、RP の要求を満たすよう OP 側アカウントを引き上げる (step-up) 形で対応する 35
37. Summary まとめ 19
38. SUMMARY パスキーでドライブするアカウント統合（まとめ） 技術的な難しさ ＋ 組織的な難しさ ＞ 認識されている価値 技術的 難しさ 組織的 難しさ 認識されて いる価値 36
39. SUMMARY パスキーでドライブするアカウント統合（まとめ） 「パスキー導入」を、アカウント統合の最初のステップとすることで... 価値を増やす 難しさを軽減 PasskeyでRPの体験向上 既存ユーザの Migrationが 進めやすい 技術的 難しさ 組織的 難しさ パスキー導入 コストが重複 しない パスキー運用コストが 無駄にならない 認識されて いる価値 RPのアカウントが 作られやすくなる 36
40. SUMMARY パスキーでドライブするアカウント統合（まとめ） 「パスキー導入」を、アカウント統合の最初のステップとすることで... 価値を増やす 難しさを軽減 PasskeyでRPの体験向上 既存ユーザの Migrationが 進めやすい 技術的 難しさ 組織的 難しさ パスキー運用コストが 無駄にならない パスキー導入 コストが重複 しない 認識されて いる価値 誰かこれにチャレンジしてみませんか？ RPのアカウントが 作られやすくなる 36
41. Summary OLD 19
42. パスキー導入は、統合の技術的・組織的難しさを軽減する ユーザ体験的にはどうなるか？ フォーカス: RP でのパスキーを使ったログイン RPのログイン画面 そのままログイン完了 メールアドレス kokukuma@mail.com サービスB のパスキー あり OP のパスキー で認証 ID mapping ある？ Conditional UI (autofill) に OP のパス キー候補が出る なし / アカウント無し 選択画面が出る 「ログイン」を選択 → RPの認証 パスワード •••• ログイン RP の認証でログイン。ID連携が自動で作られる ログイン 新規登録 補足: 以下は通常と同じ ・OP でのパスキー登録・利用 — 通常のパスキーと同様 「新規登録」を選択 → 登録画面 kokukuma@mail.com 登録 サービスB (OP) の情報をもとにアカウントを作成 ・RP での ID連携 — 通常の ID連携と同様 33
43. パスキー導入は、統合の技術的・組織的難しさを軽減する どんな利点が出てくるのか？ △ 「OP をどれにするか」の難しさは残る 主軸アカウントの選定・新設に伴う組織的な調整は、このアプローチでもなくならない mappingがある場合 ◦ mappingがない場合 ◦ アカウントがない場合 ◦ RP には「今の体験 + パス キー」と説明できる 既存ユーザの移行 (ID連携) が進みやすい 各 RP で新規ユーザが作ら れやすくなる 「RP の認証 vs ID連携」や「ID連 携中心の strangler pattern」の構 図になるより、ポジティブに説明 できる。「RP の認証 + パスキー 」— UX がいきなり大きく変わる ことはない パスキーでのログインが、既存ユ ーザに ID 連携を作ってもらう自 然なきっかけになる。「連携する とこんな便益がある」という誘導 とも相性がよい パスキーでのログインが、シーム レスな新規ユーザ作成につながる (④ のログイン時アカウント作成) 34