Webパスキー準備状況

レディネスは完了したWebログインに基づいて測定されます。ブラウザAPIの応答（getClientCapabilities / isUVPAA）だけに依存することはありません。APIの応答がポジティブであり、かつ利用可能なプラットフォームオーセンティケーター（例: Windows Helloの登録、iCloud KeychainやGoogle Password Managerのアクティブ化など）が実際にセットアップされている場合、デバイスは準備完了とみなされます。APIが「yes」を返しても、パスキープロバイダーが設定されていないデバイスはカウントされません。

プラットフォーム	2025年初頭	2025年末
iOS1,2	100%	99%
Android	96%	97%
ChromeOS	94%	95%
macOS	88%	91%
Windows 113	85%	85%
Windows 103	56%	70%

1. この表におけるiOSはブラウザのみを対象としています。アプリやwebviewコンテキストは、リライングパーティのパスキーの通常のブラウザコンテキストではないため除外されています（Googleアプリが最も重要な例です）。市場の構成によっては、これらのコンテキストがiOSのWeb使用量の約1-10%を占める場合があります。そこではパスキーがブラウザのようには機能しないため、そのトラフィックは測定されるiOSのレディネスを同程度低下させ、ログインの摩擦を生む可能性があります。
2. iOS 26.2のWKWebViewにおけるisUVPAA()の退行バグは2025年末の時点ですでに確認されており、その後数ヶ月にわたってサードパーティのiOSブラウザのレディネスをさらに低下させますが、その後回復に向かいます。Corbadoは、このバグと回復の過程をこのiOS 26.2 isUVPAA分析に記録しています。
3. Windows 10およびWindows 11では、Microsoftの継続的なパスキーレディネスへの取り組みが成果を上げていることが示されており、特に2025年12月と2026年2月のアップデートにおいて顕著です。2026年にはWindows 11でさらなる改善が見られます。ブラウザの違いも重要です。Google Password Managerのパスキー同期は2024年9月19日にデスクトップ版Chromeに導入され、一方でMicrosoftは2025年11月3日にWindows上のEdge 142でのパスキーの保存と同期を発表しました。これらのプロバイダーの変更は、2025年を通じてChromeが改善し、2026年初頭にEdgeが明確に追いつく理由を説明するのに役立ちます。