パスキーとデジタルクレデンシャルで認証を刷新、Google I/O 2026で示された最新動向
ログインフォームまわりの技術が、ここ数年で大きく変わりつつあります。Google I/O 2026のWeb Identityセッションでも、パスワードに代わる認証手段として、パスキー(Passkeys)、デジタルクレデンシャル(Digital Credentials)、メール検証プロトコルといった複数のアプローチが取り上げられたとみられます。本記事では、Webディレクターが制作要件やUX設計を検討するうえで押さえておきたいポイントを、公式ドキュメントを参照しながら整理します。
なぜいま認証の刷新が進むのか
パスワード認証は、使い回しやフィッシングによる漏洩リスクが構造的に残り続けます。ユーザーにとっては「覚える負担」、事業者にとっては「漏洩時の責任」と、双方に負債が積み上がる仕組みでした。
これを解消する本命として普及が進んでいるのがパスキーです。パスキーは公開鍵暗号を用いた認証方式で、端末の生体認証(指紋・顔)やPINでログインを完結させます。秘密鍵は端末やパスワードマネージャー側に保管され、サーバーには公開鍵しか渡らないため、サーバー側が漏洩してもなりすましに直結しません。
パスキー導入で制作側が決めること
パスキーは「入れれば終わり」ではなく、既存のパスワード認証と共存させながら段階的に移行する設計が現実的です。公式のチェックリストやフォーム自動入力(Form Autofill)のガイドでは、ログインフォームにautocomplete属性を正しく付与し、パスキーの候補を自動で提示する実装が推奨されています。
ディレクターとして要件定義で確認したいのは、主に次の3点です。
- サインアップ／ログイン画面の導線: 既存ユーザーにいつパスキー登録を促すか(ログイン成功直後など)
- 複数ドメインの扱い: 関連する別ドメインでも同じパスキーを使いたい場合、Related Origin Requestsの設定が必要
- 管理画面の提供: ユーザーが登録済みパスキーを一覧・削除できる管理UI(Passkey Management)を用意するか
adidasやpixivの事例では、パスキー導入後にログイン成功率の大きな改善が報告されています。pixivではパスキー利用者の認証成功率が99%(パスワード認証比で29ポイント増)、adidasでもサインイン開始後の成功率が99%超とされています。単なるセキュリティ強化ではなく、ログイン失敗による離脱の削減にもつながる施策として位置づけられており、企画時の説得材料になりそうです。
デジタルクレデンシャルとメール検証
パスキー以外の動きも並行して進んでいます。デジタルクレデンシャルは、運転免許証や在学証明といった発行済みの証明書を、ブラウザ経由で安全に提示する仕組みとされています。年齢確認や本人確認が必要なサービスで、書類アップロードに代わる選択肢になり得ます。
また、WICGで議論されているメール検証の提案(Email Verification API)は、確認コードの入力といった従来の煩雑なフローを、暗号的な所有証明に置き換えて標準化しようとする取り組みです。ステータスはプロトタイプ・実験の意向表明段階で、いずれもまだ発展途上ですが、フォーム設計の前提が今後変わっていく方向性として把握しておく価値があります。
FedCMへの移行という論点
ソーシャルログイン(Googleでログイン等)を実装しているサイトにとって重要なのが、FedCM(Federated Credential Management)への移行です。サードパーティCookieに依存しないサインイン方式への移行が進むなか、従来のGoogle Sign-Inの実装もFedCMベースへ切り替えることが公式に推奨されています。移行ガイドも用意されており、既存実装の棚卸しは早めに着手しておくのが安全です。
日本のWeb制作の現場では、認証は外部SaaSやCMS標準機能に任せているケースも多いですが、その場合でも「利用中のサービスがパスキーやFedCMに対応しているか」はベンダー選定・更改の判断軸になります。
まとめ
パスキーはすでに実運用フェーズに入り、デジタルクレデンシャルやメール検証は次の標準化を待つ段階とみられます。ディレクターとしては、(1)新規案件ではパスキー対応を前提に導線を設計する、(2)既存のソーシャルログインはFedCM移行の要否を確認する、という2点をまず押さえておくとよいでしょう。公式のチェックリストと事例を参照しながら、自社サービスの認証UXを見直す好機です。