※本記事は、Nina Satragno氏とNatalia Markoborodova氏による、Google I/O 2026でのChromeセッション「Modernize authentication with passkeys, digital credentials, and more」の内容を基に作成されています。動画は https://www.youtube.com/watch?v=xzMx2khmGJ4 でご覧いただけます。本セッションでは、パスワードのリスクを排除し離脱率を低減するフィッシング耐性のある認証の実装方法として、パスキー、Digital Credentials、ID連携(Identity Federation)などのモダンなアイデンティティソリューションを用いて、高いセキュリティとシームレスなユーザー体験を両立するアイデンティティフローの構築方法が紹介されています。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
セッションの詳細やベストプラクティスの詳細については、以下のリソースもあわせてご参照ください。
- セッションの復習と最新のユーザー認証ベストプラクティス:https://goo.gle/io26-web-identity
- Google I/O 2026のChromeセッション一覧:https://goo.gle/Chrome-at-IO2026
- Chrome for Developers購読:https://goo.gle/ChromeDevs
1. セッション概要と認証改善の意義
1-1. 登壇者紹介とセッションの狙い
Nina： こんにちは、Ninaです。本日はNataliaと二人で、ユーザー認証のベストプラクティスと、皆さんのアプリケーションで活用できるAPI群についてお話しします。
Natalia： Nataliaです。私たちがこのセッションで扱うのは、ユーザーのアカウントライフサイクル全体の体験をどう改善するかというテーマです。サインアップからサインイン、そしてアカウント復旧まで、一連の流れを通して見ていきたいと思います。
Nina： アカウント管理システムを構築されている方であれば、日々の開発の中で頭を悩ませているポイントがいくつもあるはずです。今日はその課題に対して、具体的な解決策を提示していきます。
1-2. アカウント管理の課題
Natalia： 私たちがまず指摘したいのは、高フリクションなサインアップフォーム、パスワードを忘れた際に発生するループ、そして常につきまとうフィッシングの脅威です。これらはいずれも、ユーザーがアプリケーションから離脱してしまう「コンテキストスイッチ・キラー」だと私たちは捉えています。
Nina： まさにその通りです。ユーザーが本来集中したいタスクから意識を逸らされてしまうたびに、離脱のリスクは高まります。だからこそ私たちは、このセッションを通じて、パスワードやワンタイムパスワードのような脆弱かつ高フリクションなサインイン手段を段階的に廃止し、より強固でユーザーフレンドリーな代替手段を有効化していくことを、アカウント管理システム設計における目標として掲げていただきたいと考えています。
1-3. 業界事例に見る効果と扱うトピックの全体像
Natalia： 効果の面でも裏付けがあります。私たちがこれから紹介する技術を導入することで、サインインの速度が従来の倍になり、成功率は4倍に向上するという結果が出ています。
Nina： 実際に業界のリーダー企業がこうした技術を取り入れることで、優れた成果を上げている例があります。代表的なのがPixivの事例で、ログイン成功率99%という数字を達成しています。こうした具体的な成果を踏まえて、私たちはユーザーのアカウントライフサイクル体験を改善するための実践的なヒントを用意してきました。
Natalia： 具体的にこのセッションで取り上げるトピックは、大きく4つです。まずアカウント作成、次にユーザー属性の検証、続いてパスキーを用いたサインイン、そして最後にアカウント復旧です。それぞれの段階について、ベストプラクティスと活用できるAPIを順番に解説していきます。
Nina： なお、これらのトピックに加えて、他にも関心を持っていただけそうなAPIについてまとめたブログ記事も用意しています。詳細はぜひ、説明欄のリンクからご確認ください。それでは、アカウントライフサイクルの各段階を一つずつ見ていきましょう。
2. アカウント作成における摩擦削減とユーザー属性検証
2-1. サインアップフォームの離脱問題
Nina： ユーザーのアカウントライフサイクルは、アカウント作成から始まります。しかし、従来型のサインアップフォームは、しばしばユーザーにとって最初のハードルになってしまいます。必須項目がずらりと並んだ長いフォームは、それだけでユーザーにフラストレーションを引き起こします。
Natalia： 特に問題なのは、入力にかかる認知的な負荷が、サインアップによって得られるメリットの実感を上回ってしまった場合です。そうなると、ユーザーは高い確率で途中離脱してしまいます。逆に言えば、ここで良い第一印象を与えられれば、その後の継続利用にもつながるということですね。
Nina： その通りです。ですので、まずはサインアップ時の摩擦を減らすための具体的な工夫から見ていきたいと思います。
2-2. ID連携による解決
Nina： 一つ目にご検討いただきたいのが、ID連携、いわゆるIdentity Federationです。これは、ユーザーがすでに信頼しているアイデンティティプロバイダーのアカウントを使って、皆さんのアプリケーションにサインアップできる仕組みです。例えばGoogleのアカウントが分かりやすい例ですね。
Natalia： ユーザーがすでにそのアイデンティティプロバイダーに登録済みであれば、プロバイダー側はユーザー名や氏名、メールアドレスといったアカウント情報をすでに保持しています。
Nina： ですので、ユーザーはサイトやアプリケーションごとに同じ情報を何度も入力する代わりに、アイデンティティプロバイダーに対して、選択した属性情報をアプリケーション側に共有することを許可するだけで済みます。つまり、面倒なフォーム入力を省略して、ワンクリックでサインアップが完了するということです。
Natalia： さらに重要なのは、信頼できるアイデンティティプロバイダーは、すでにユーザーの連絡先情報の検証を済ませているという点です。これにより、アプリケーション側でメールアドレスの検証作業のような確認プロセスを別途行う必要がなくなります。結果として、ユーザーがコンテキストスイッチを起こすことなく、サインアップを完了できる可能性が高まります。
Nina： ID連携はこれほどアカウント作成を容易にしてくれますので、初回サインアップ時のデフォルトの選択肢として実装することをお勧めします。私たちはここで「まず連携、その後アップグレード(federate, then upgrade)」というパターンを推奨しています。
Natalia： 具体的には、まずフェデレーテッドアイデンティティのアプローチを使ってアカウントを即座に作成し、そのうえで、ユーザーがデバイス間で素早く安全にサインインできるよう、直後にパスキーの作成を促すという流れです。パスキーの作成戦略の詳細については、この後Ninaから改めて説明があります。
2-3. FedCM API
Nina： ID連携の話に戻りますと、もし皆さんがアイデンティティプロバイダーの立場であれば、FedCM APIの活用をご検討ください。FedCMの大きなメリットは、ユーザー体験とプライバシーの両方が向上する点にあります。
Natalia： すでにGoogleのサインインをはじめとする主要なアイデンティティプロバイダーが、このFedCMの機能を有効化しています。FedCM APIに関するより詳しい資料は、ブログ記事に掲載していますので、そちらもぜひご覧ください。
2-4. オートフィルの最適化
Nina： ID連携が推奨のオプションではありますが、それでもサインアップフォームを使わざるを得ない場合もあると思います。その場合は、オートフィルを有効化することで、ユーザー体験を大きく改善できます。
Natalia： オートフィルを正しく機能させるためには、フォーム入力欄に分かりやすいname属性やid属性を設定し、明確なlabel要素を用意することが重要です。そして何より、「new-password」や「email」といった適切なautocomplete値を設定することで、ブラウザがユーザーを的確にサポートできるようになります。
Nina： ちなみに、オートフィルは単に入力の手間を省くだけの機能ではありません。メール検証プロトコルや、複数のサインイン方法に対応した統一的な条件付きサインインUIといった、新しく魅力的な機能への入り口としても進化してきています。この点については、まずメールをはじめとするユーザー属性の検証について見ていきたいと思います。
2-5. メールアドレス検証の重要性
Natalia： ID連携を利用する場合、信頼できるアイデンティティプロバイダーがすでにメールアドレスなどのユーザーデータを検証済みです。一方で、サインアップフォームに頼る場合、そこで受け取るデータが必ずしも検証されているとは限りません。私たちとしては、まずそのデータを検証することをお勧めします。
Nina： メールアドレスは、多くのアプリケーションにとって主要な識別子であり続けています。ほぼすべてのユーザーが利用している、安定的でクロスプラットフォームなコミュニケーションチャネルだからです。メールアドレスは、請求書の送付や長期的なアカウント復旧の基盤としても機能します。
Natalia： もしアプリケーションが存在しないメールアドレスでの登録を許してしまうと、ユーザーが重要な通知を一切受け取れないという、高フリクションかつサイレントな失敗が発生してしまいます。これはユーザーに「このプラットフォームは壊れている」という印象を与え、即座の離脱につながります。加えて、無効なメールアドレスは高いバウンス率を引き起こし、届くことのないメッセージに対してメール配信サービスの料金がかさむという問題も生じます。
2-6. メール検証プロトコル
Natalia： メールアドレスの検証手段として、多くのID関連ソリューションはメールのワンタイムパスワードやマジックリンクに依存しています。メールOTPは入力フォームに入力する一度限りのコードで、マジックリンクはワンタイムコードを含んだURLをクリックすることでサインインできる仕組みです。
Nina： どちらの手法にも共通する弱点は、コンテキストスイッチが発生してしまうことです。ユーザーはアプリケーションを離れて、受信トレイを探し、リンクやOTPが届くのを待たなければなりません。この摩擦は、コンバージョンを大きく損なう要因として知られています。
Natalia： さらに、OTPは依然としてフィッシングに対して脆弱です。マジックリンクについては、正しいオリジンにユーザーを誘導するためフィッシングの余地は小さくなるものの、多くの場合インアプリブラウザで開かれてしまい、通常のブラウザと同じセッションデータやクッキーが共有されていません。これによってユーザーが混乱し、離脱してしまうことがあります。例えば、カートの中身が突然空になっているように見えるといったケースです。
Nina： こうした課題に対する、より優れた選択肢の一つがメール検証プロトコルです。このプロトコルを使えば、ウェブアプリケーションはメールを一切送信することなく、検証済みのメールアドレスを取得できます。検証フローはすべてブラウザ内で完結しており、ユーザーから見れば「受信トレイを確認する」という摩擦が完全になくなります。コンテキストスイッチも配信待ちの時間も発生しません。
Natalia： その仕組みについてもう少し詳しく説明しますと、これはメールプロバイダー、ブラウザ、そして専用の発行者(issuer)の三者間で行われるハンドシェイクです。メールプロバイダーは検証の権限を発行者に委任することをオプトインで選択できます。発行者は、ユーザーがログイン済みでありメールアドレスを管理下に置いていることを証明する、ファーストパーティの認証クッキーを保持しています。
Nina： ユーザーがアプリケーション上でメールアドレスを入力すると、ブラウザはそのメールアドレスの検証を発行者にリクエストします。発行者は認証クッキーを確認したうえで、安全なデジタルトークンに署名し、それをブラウザに返却します。ブラウザはこのトークンをアプリケーションに渡します。
Natalia： このプロトコルを自分のサイトで有効化するには、メール入力欄にautocomplete属性をemailに設定したうえでnonce属性を付与し、email verifiedイベントに対するJavaScriptのリスナーを追加します。イベントが発火したら、プレゼンテーショントークンを取得し、そのトークンの署名とクレームを必ず検証してください。
Nina： なお、このメール検証プロトコルは現在も活発に開発が進められている段階の機能であり、皆さんからのフィードバックをもとに実装の詳細が今後変わる可能性がある点にご留意ください。また、これはオプトイン機能であり、対応するかどうかは個々のメールプロバイダーの判断に委ねられています。詳しくはブログ記事をご覧いただければと思います。
2-7. Digital Credentials API
Natalia： メールアドレス以外にも、法的な氏名や年齢要件など、アカウント作成を完了させる前に検証しなければならないユーザー属性が必要になるケースがあります。これは、地域の規制に準拠するために求められることが多いです。
Nina： 一部の地域では、こうしたケースに対応するために、検証可能なデジタルアイデンティティクレデンシャルが利用できるようになっています。プライバシーに配慮した形でユーザー属性を検証するために、Digital Credentials APIを使うことができます。
Natalia： この仕組みを理解するために、まずデジタルクレデンシャルの三者モデルについて、高いレベルで整理しておきましょう。一つ目が発行者(issuer)です。これはクレデンシャルのクレームに暗号署名を行う、信頼された組織です。例えば、運転免許証を発行する機関などが該当します。
Nina： 二つ目が保持者(holder)です。これは、署名済みのクレームを保管しているユーザーのモバイルデバイスを指します。そして三つ目が検証者(verifier)です。これは、Digital Credentials APIを通じて証明を要求する、皆さんのウェブサイトやモバイルアプリのことです。
Natalia： デジタルクレデンシャルからユーザー属性をリクエストする際、サイト側はDigital Credentials APIを呼び出します。すると、ブラウザとOSが連携して、検証者とインストール済みのウォレットとの間の通信を仲介します。要求された属性を含むクレデンシャルが利用可能であれば、OSがユーザーに対して、それを検証サイトと共有するかどうかを確認するプロンプトを表示します。
Nina： 検証者は、要求した情報だけを受け取り、その真正性を発行者に直接確認します。同時に、ユーザー側には、どのデータが共有されようとしているのかについて、包括的な開示情報が表示されます。
Natalia： ここで、先ほどの「まず連携、その後アップグレード」というパターンを思い出してください。同じ考え方に沿って、ユーザーデータの検証を終えた後には、続くサインインのためにパスキーの作成をユーザーに促すことができます。これは実装上、サイト側での二つのAPI呼び出しに集約されます。まずgetを呼び出してDigital Credentials APIでユーザー属性を検証し、その後createを呼び出してパスキー作成を提案する、という流れです。
Nina： デジタルクレデンシャルを取り巻くエコシステムは、政府発行のクレデンシャルにとどまらず、さらに成熟しつつあります。Digital Credentials APIは、アプリケーションとユーザーのモバイルアプリを接続するために必要なトランスポート層を提供するものであり、証明書から搭乗券に至るまで、さまざまな種類の検証可能なクレデンシャルを共有するための汎用的なツールと言えます。
Natalia： ユーザーが、信頼できる発行者からのクレデンシャルを保持する互換性のあるウォレットアプリを持ってさえいれば、Digital Credentials APIを使ってそのデータを検証できます。これでアカウント作成に関する私たちの推奨事項は一通りお話しできました。ここまでで、ユーザーのセットアップと検証が完了した状態になります。次のステップに進みましょう。ここからはNinaに、サインインのベストプラクティスについて説明してもらいます。
3. パスキーによるサインイン体験の構築
3-1. Immediate UI Mode
Nina： ありがとうございます、Natalia。スムーズなサインイン体験は、ユーザージャーニー全体のトーンを決定づけるという意味で非常に重要です。サインインの方法は数多くありますが、それ自体は良いことだと思っています。ユーザーによって、パスワード、フェデレーテッドアカウント、パスキーなど、好みのサインイン方法は異なるからです。
Natalia： とはいえ、その中でも私たちが強く推奨したいのはパスキーです。パスキーはパスワードやOTPに比べてより簡単かつ安全な代替手段であり、フィッシング耐性も備えています。
Nina： まず、パスキーを他の選択肢と統合された一つのUIの中で提供する方法から見ていきましょう。Chrome 148からは、Immediate UI Modeという新しいモードが利用できるようになります。このモードは、ユーザーがすぐにサインインできる認証情報を選択できるよう手助けしてくれます。
Natalia： 具体的には、パスワードマネージャーに保存されている利用可能なパスキーやパスワードをまとめてUIに表示します。同じアカウントに対して複数の認証情報が存在する場合には、ブラウザが最も適切な選択肢をインテリジェントに選び出してくれるため、ユーザーにとっての認証情報管理がシンプルになります。
Nina： 通常のパスキーリクエストと違う点として、利用可能な認証情報が一つもない場合、ブラウザはUIを一切表示せずに、即座にエラーを返します。そうなった場合、皆さんのウェブサイト側で、ユーザーを通常のサインインページへ誘導すればよいということです。
Natalia： このAPIを使うには、まずgetClientCapabilitiesを呼び出して対応状況を確認し、immediateGetプロパティをチェックします。そのうえで、UIモードのプロパティをimmediateに設定してgetを呼び出します。
Nina： ここで一つ推奨したいのが、passwordプロパティをtrueに設定することです。これを加えておくと、APIはパスワードまたはパスキーのアサーションのどちらかを返してくれるようになります。こうすることで、より多くのユーザーにとって、この呼び出しが成功する可能性を最大限に高めることができます。私たちとしても、フェデレーテッドアカウントをこのImmediate UI Modeでサポートする方法について、現在検討を進めているところです。
3-2. Conditional UI
Natalia： 通常のサインインページでは、Conditional UIへのフォールバックも引き続き利用できます。
Nina： Conditional UIは、フォームのオートフィル体験をうまく活用した仕組みで、ユーザー名やパスワードの入力欄にフォーカスが当たったときに、ブラウザのオートフィル候補として直接パスキーが表示されるようにするものです。Conditional UIについてより詳しく知りたい方は、ぜひブログ記事をご覧ください。
3-3. ケイパビリティチェック
Nina： ここまででサインイン時にパスキーをどう活用できるかをお話ししてきましたので、次はパスキーの作成についてお話しします。新規ユーザーには、サインアップ中またはサインアップ直後のタイミングで、パスキーの作成を促すことをお勧めします。
Natalia： その際にまず行うべきなのが、getClientCapabilitiesを呼び出して、passkeyPlatformAuthenticatorプロパティを確認し、ユーザーの環境にパスキープロバイダーが利用可能かどうかをチェックすることです。
3-4. Conditional Createによる自動作成
Nina： この確認が済んだら、createを呼び出してパスキーを作成します。ここで重要なのは、authenticatorAttachment属性をplatformに設定することです。これにより、ブラウザはローカルで利用可能な認証情報プロバイダーにUIの焦点を当てるようになります。
Natalia： すでにいる既存ユーザーに対しては、Conditional Createと呼ばれる自動パスキー作成の仕組みをリクエストすることをお勧めしています。この機能を使うと、プロンプトを一切表示することなく、ウェブサイト側からパスキー作成をトリガーできます。
Nina： 実際にAdidasはこのConditional Createを実装し、パスキー作成数が8%向上したという結果を得ています。使い方としては、mediationプロパティをconditionalに設定した通常のクエリリクエストを行います。Chromeの場合、使用されたパスワードがパスワードマネージャーに保存されているものと一致すれば、ブラウザは追加のプロンプトを一切出すことなく、バックグラウンドで静かにパスキーを登録してくれます。
3-5. パスキー推奨画面の効果
Natalia： 単純にパスキーのメリットをユーザーに通知するだけでも、コンバージョンが向上しているプラットフォームが多く見られます。例えばPixivは、パスキーをより速く安全なログイン方法として推奨するセキュリティ確認画面を追加しました。
Nina： その結果、たった一つのシンプルな画面を追加しただけで、新規ユーザーにおけるパスキー採用率が6%向上したそうです。ちょっとした一言の案内でも、ユーザーの行動に大きな影響を与えられるということがよく分かる事例だと思います。
3-6. Signal APIと登録通知
Natalia： もう一つ良い実践として挙げたいのが、パスキー作成に失敗したケースへの対応です。公開鍵がバックエンドの保存に失敗した場合には、Signal APIを使ってパスキープロバイダーにシグナルを送ってください。このAPIについては、この後のセクションで改めて詳しく説明します。
Nina： そして最後に忘れてはならないのが、パスキーが作成されたことをユーザーに通知することです。パスキーが登録された際には、メールやアプリ通知などを通じて、必ずすぐにユーザーへ知らせるようにしてください。これは、不正な認証情報の追加からユーザーを守るための重要な手段になります。
3-7. クロスプラットフォーム対応
Natalia： ユーザー体験は、ブラウザの中だけでなく、ユーザーが使うすべてのデバイスをまたいで一貫している必要があります。
Nina： クロスプラットフォームでのスムーズな体験を実現するために、皆さんのウェブサイトとモバイルアプリの間で検証済みの関連付けを確立することができます。Androidアプリの場合は、サーバー上のassetlinks.jsonというデジタルアセットリンクファイルを使って関連付けを指定します。このファイルには、アプリケーションのパッケージ名と、SHA256署名証明書のフィンガープリントを、handle_all_urlsとget_login_credsという二つのリレーションに含める必要があります。
Natalia： さらに、アプリのマニフェストファイルを更新して、パスキーを有効化することも忘れないでください。このファイルは、皆さんのウェブオリジンとネイティブアプリが同一の主体によって所有されていることを証明するものです。これがないと、ウェブサイト上で作成したパスキーでアプリにサインインしたり、その逆を行ったりすることができません。
Nina： これでユーザーはパスキーを手に入れた状態になりました。次は、そのユーザー体験をできるだけスムーズでストレスのないものに保つために、皆さんのアプリケーションが従うべきベストプラクティスを見ていきましょう。
4. パスキー運用管理とアカウントリカバリー
4-1. Signal APIによる同期維持
Nina： 想像してみてください。ユーザーが皆さんのウェブサイト上でアカウントを削除したり、パスキーを取り消したりしたのに、そのパスキー自体はパスキープロバイダー側に残ったままになっているというケースです。次にユーザーがサインインしようとすると、サーバー側で対応する公開鍵が見つからず、失敗してしまうパスキーが表示されてしまいます。
Natalia： こうした状況を防ぐために役立つのが、Signal APIです。これを使えば、ユーザーのパスキーが同期しなくなってしまう事態を避けることができます。
Nina： 具体的には、バックエンド側で、データベースに存在しない認証情報IDを使ったサインイン試行を検知した場合に、signalUnknownCredentialを呼び出してください。これにより、そのパスキーはもはや使えないということが認証情報プロバイダーに伝わり、以降のサインイン試行からは非表示になるか削除されます。
Natalia： それに加えて、利用可能なパスキーの状態そのものについてもシグナルを送るべきです。これは、サインインのたびに、またユーザーがパスキーを削除するたびに行ってください。signalAllAcceptedCredentialsを使うことで、パスキーの一覧をパスワードプロバイダー側と同期した状態に保つことができます。
Nina： そして最後に忘れてはならないのが、signalCurrentUserDetailsの呼び出しです。これによって、パスキーの一覧に表示されるユーザー名や表示名を、常に最新の状態に同期させることができます。こうしたSignal APIのメソッドを一貫して呼び出しておくことで、次回ユーザーがサインインする際に目にするプロンプトの内容が、常に正確なものになります。
4-2. 複数パスキー登録
Natalia： ここからは、優れたユーザー体験のもう一つの重要な要素についてお話しします。それは、ユーザーが自分のパスキーをコントロールできるようにすることです。まず一つ目として、ユーザーは複数のパスキーをアカウントに追加できるようにするべきです。
Nina： これは、レジリエンスの観点から非常に重要です。もしユーザーが異なるプロバイダー由来のパスキーを複数登録できれば、一つのプロバイダーが利用できなくなった場合でも、脆弱なパスワードにフォールバックすることなく使えるバックアップ手段を持てることになります。加えて、異なるエコシステムをまたいでサインインする際にも、その利便性が生きてきます。
4-3. パスキー管理ページ
Natalia： また、ユーザーが自分のすべてのパスキーを確認し、管理できる専用のページを用意しておくことも良い実践です。例えば、パスワードや二要素認証を管理する画面と同じ場所に、パスキー管理の機能を統合するといった形が考えられます。
Nina： 大切なのは、ユーザーがこのページを簡単に見つけられるようにすることと、そのページ内にパスキーをまとめて扱う専用のセクションを設けることです。ユーザーは、パスキーの閲覧、追加、削除ができるようにするべきです。そして、こうした変更が行われた際には、Signal APIを通じてパスキープロバイダーに必ず通知することも忘れないでください。
Natalia： このページでは、パスキープロバイダーの名前も表示するようにしてください。AAGUIDを使うことで、Google Password ManagerやBitwardenといったプロバイダー名を調べて、そのロゴを表示することができます。AAGUIDについて詳しく知りたい方は、ぜひブログ記事をご覧ください。
Nina： さらに、そのパスキーが同期可能かどうかについても、明確に示すべきです。例えば、ユーザーが職場のPCで非同期タイプのパスキーを登録してしまうと、そのパスキーは自宅のノートパソコンでは使えません。作成時のレスポンスに含まれるbackup eligibleビット、いわゆるBEを使うことで、この情報を判別することができます。
Natalia： これで、優れたユーザーサインイン体験をどう構築するかについての説明は以上になります。ユーザーアカウントライフサイクルの次の段階として、アカウント復旧についてお話しするために、ここからは私、Nataliaが引き継ぎます。
4-4. デバイス紛失時の復旧
Natalia： ありがとうございます、Nina。ここからは、最悪のシナリオともいえるアカウント復旧について見ていきましょう。ユーザーがデバイスを紛失してしまったり、誤ってパスキーを削除してしまったりした場合に何が起こるのか、疑問に思われるかもしれません。こうしたケースでも、ユーザーが自分のアカウントにアクセスしたり、復旧したりできるよう、私たちからいくつかの推奨事項をご用意しています。
Nina： 以前お話ししたとおり、パスキーは同期され、エンドツーエンドで暗号化されています。
Natalia： ですので、たとえユーザーがスマートフォンを紛失してしまったとしても、Google Password Managerのようなパスキープロバイダーにパスキーが保存されていれば、そのパスキーはクラウド上に安全にバックアップされています。ユーザーは新しいデバイス上でGoogleアカウントにサインインし、Android端末の画面ロックやGoogle Password ManagerのPINを入力することで、新しいハードウェア上でも同期済みのパスキーにアクセスできます。
Nina： そして、そのパスキーを使って、引き続き皆さんのアプリケーションにサインインすることができます。Google Password Manager以外にも、多くのパスキープロバイダーが同期とエンドツーエンドの暗号化に対応しています。
4-5. パスキー全喪失時のフォールバック
Natalia： では、ユーザーがパスキーに対応したデバイスすべてへのアクセスを失ってしまった場合はどうでしょうか。その場合でも、検証済みのユーザー属性にフォールバックすることができます。例えば、ユーザーが最初にサインアップした際に使ったフェデレーテッドアカウントを通じて、サインインさせるという方法があります。
Nina： また、ユーザーが元々フェデレーテッドアカウントを使っていなかった場合でも、メールアドレスの検証によって対応することができます。これには、このセッションで紹介してきたメール検証プロトコルをはじめとする、さまざまな手法を活用できます。こうした方法を組み合わせることで、ユーザーが皆さんのアプリケーションへのアクセスを取り戻せるよう、常にサポートすることが可能になります。
5. まとめとAI活用への言及
5-1. ライフサイクル全体の総括
Natalia： これが、私たちからの主な推奨事項になります。ここまでで、アカウントライフサイクルのあらゆる段階におけるベストプラクティスを一通りお話ししてきました。
Nina： 改めて振り返りますと、まずアカウント作成の段階では、ID連携やオートフィルの最適化を通じて、ユーザーの摩擦をどう減らすかについてお話ししました。次に、メール検証プロトコルやDigital Credentials APIを使って、ユーザー属性をどのように検証するかを見てきました。
Natalia： そのうえで、Immediate UI ModeやConditional Create、Signal APIといった仕組みを組み合わせて、パスキーをどう実装すれば最良のサインイン体験を実現できるかを説明しました。そして最後に、ユーザーがデバイスやパスキーを失ってしまった際に、どのようにアカウントへのアクセスを取り戻す手助けができるかについても触れました。
Nina： こうして見ると、アカウント作成からサインイン、そして万が一の復旧まで、一貫してユーザーの摩擦を減らしながら、セキュリティを高めていくという考え方が、すべてのトピックに共通していたように思います。
Natalia： そうですね。そして、このエコシステム自体も急速に進化し続けています。だからこそ、皆さんが使う開発ツールも、その変化のスピードについていく必要があります。
5-2. AIコーディングエージェントの活用
Natalia： 今日、AIコーディングエージェントは、皆さんがアイデンティティ関連のソリューションを構築する speed を大きく加速してくれる存在になっています。
Nina： その点を踏まえて、私たちはコーディングエージェントがベストプラクティスに沿った実装を行えるよう手助けするための、一連のスキル集も用意しました。これまでこのセッションでお話ししてきた推奨事項に加えて、さらに詳しい内容をブログ記事でご確認いただけます。
Natalia： こうしたベストプラクティスに従うことで、皆さんはより安全で、フィッシングに強く、そしてユーザーを第一に考えたアイデンティティレイヤーを構築するための準備が整うはずです。
Nina： 私たちはNinaと申します。
Natalia： そしてNatalia、Chromeチームからお届けしました。また次回お会いしましょう。Happy coding!