パスキー (WebAuthn) 2026 年版の状況 — 普及・実装・移行戦略

OS / ブラウザ

「 iOS 16+ / Android 9+(クラウド同期は Android 14+)/ macOS Ventura+ / Windows 10+(Microsoft アカウント同期)」 で完全対応。「Chrome / Safari / Firefox / Edge」 すべての主要ブラウザで動く。` 一般ユーザーの大半の環境で 「何の準備もなく動く」 状態。

パスワードマネージャ

「 1Password」 「 Bitwarden」 「 Dashlane」 「 LastPass」 のような主要パスワードマネージャがパスキー対応完了。「OS のキーチェーンでなくても、パスワードマネージャ経由でクラウド同期できる」 ようになり、「ベンダー横断のパスキー体験」 が成立。

大手サービスの対応

「 Google」 「 Apple ID」 「 Microsoft アカウント」 「 Amazon」 「 GitHub」 「 X(Twitter)」 「 Adobe」 「 Shopify」 「 PayPal」 「 eBay」 など、主要 SaaS / 消費者サービスがパスキーログイン対応済み。Google は 2025 年に 「パスワードレスを優先する」 方針を発表し、ログイン画面の UX がパスキー優先に変わった。

エンタープライズ採用

「 Microsoft Entra ID(旧 Azure AD)」 「 Okta」 「 OneLogin」 「 Ping Identity」 などエンタープライズ IdP もパスキー標準サポート。「SSO のセカンドファクタとしてパスキー必須化」 する企業が増加。「金融・医療・政府機関」 で 「Device-bound パスキー(ハードウェアキー)」 採用が進む。

公開鍵暗号ベース

「 登録時にデバイス内で鍵ペアを生成」 → 「公開鍵だけサーバに送る」 → 「認証時にサーバからチャレンジを受け、デバイス内の秘密鍵で署名 → サーバが公開鍵で検証」。パスワードはどこにも存在しない。

フィッシング耐性

「 パスキーは origin(ドメイン)に紐付く」。偽サイトに行ってもブラウザが正規ドメインのパスキーを送らない。「URL を見間違えるユーザー」 がそもそも被害に遭わない設計。

同期(Synced) vs デバイス紐付き(Device-bound)

「 Synced」 = iCloud Keychain / Google Password Manager / 1Password などで クラウド同期。「複数デバイスで使える」 利便性が高い。「Device-bound」 = 「YubiKey などハードウェア」 や 「デバイス内 Secure Enclave」 に紐付き、「 クラウドに鍵が出ない」 高セキュリティ用途。

UX

「 顔認証 / 指紋認証 / PIN」 で本人確認(これは ユーザー検証(User Verification))。「デバイスがロックされていればすぐログイン」。パスワード入力もコード入力も無い 圧倒的に楽な体験。

Resident Key(Discoverable Credential)を使う

「 ユーザーが username を入力しないでログイン」 を実現する設定。パスキーログインの UX を最大化するには必須。古い設定だと 「username 必須」 になることがあるので、IdP 設定を確認。

複数パスキー登録を許可

「 ユーザーが iPhone と Windows PC の両方にパスキーを登録できる」 ように設計。1 つのアカウントに複数の Authenticator を関連付けられる のがパスキー運用の標準。

リカバリの設計

「 パスキーを失った場合のリカバリパス」 を必ず設計。「登録済み別デバイスからの認証」 「 メール / SMS の確認コード」 「 バックアップコード」 「 ID 確認(身分証提出)」 などを組み合わせる。リカバリの抜け道がフィッシング攻撃の入口になる ので慎重に設計。

User Verification(UV)を必須に

「 顔認証 / 指紋認証 / PIN」 などのユーザー検証を必須(「userVerification: required」)に設定。UV なしのパスキーは盗まれたデバイスから誰でも使える リスクがある。「高セキュリティが要る用途では UV 必須」 は妥協しない。

Device-bound の特徴

「 鍵がクラウドに同期されない」 = 「特定のハードウェアでのみ使える」。クラウド事故 / アカウント乗っ取りで鍵が漏れない 最大限のセキュリティ。「YubiKey」 「 Google Titan」 「 SoloKey」 などの専用ハードウェアキーで実現。

トレードオフ

「 紛失すると完全に失効 」 「 複数デバイスで使うには複数キーを買う」 「 ユーザー教育が必要」。UX が Synced より硬い 代わりに 鍵の安全性は最高クラス。

Attestation で実装可能

` WebAuthn の 「attestation」 オプション」 で、「どんな種類の Authenticator で登録されたか」 を IdP が検証可能。「Synced のみ拒否、ハードウェアキーのみ受付」 のような ポリシー強制 ができる。

使い分け

「 一般ユーザー = Synced パスキー(利便性重視)」 「 管理者アカウント / 高権限ロール = Device-bound(セキュリティ重視)」。ユーザー種類別にポリシーを使い分ける のが現代的設計。

パスワード廃止を急ぎすぎる

「 半年でパスワード廃止予定」 のような急ぎ移行は ユーザー離れ を招く。「Apple / Google でも完全廃止はせず、当面パスワード併用」 が現実的アプローチ。1 年以上の段階移行が標準。

UX の混乱

「 パスキーログイン」 「 パスワードログイン」 「 SSO ログイン」 が並ぶと、ユーザーが混乱。優先順位を明確にする(パスキー > SSO > パスワード)が定石。「残りのオプションは折りたたみ」 で UX を整理。

古いブラウザ / 環境のサポート

「 Internet Explorer の残存ユーザー」 「 Linux + Firefox + パスワードマネージャ未対応」 のような マイノリティ環境での挙動確認は不可欠。「サポート外環境は明示してフォールバック」 を必ず用意。

複数デバイス対応の説明不足

` ユーザーが 「1 つのパスキーで全デバイスで使える」 と誤解」 して、別デバイスでログインできずに混乱。Synced と Device-bound の違い」 「 別デバイスでは新規パスキー登録が必要なケース を分かりやすく説明する。