FIDO2 / WebAuthn Standard Specification

パスキー互換性マスターマトリクス

マルチプラットフォーム、OS、ブラウザ、物理デバイス、サードパーティ製管理ツールにおける相互運用性を視覚的に解析したインフォグラフィックダッシュボード

認証成功率
93%

パスワード比2倍以上の高い認証完了率を達成

認証時間短縮
73%

ログイン摩擦を取り除きユーザー体験を変革

管理コスト削減
81%

認証トラブルによるヘルプデスク費用を削減

総合平均互換性
80%

全5項目の実用互換達成率の加重平均インジケータ

公開鍵暗号に基づく新しい認証基準

パスキーは、FIDO標準およびWebAuthn仕様に基づき、フィッシング攻撃を根本的に無効化する新しい認証メカニズムです。パスワードや2要素認証に伴う摩擦を排除し、サインイン成功率を高めながらヘルプデスクコストを大幅に圧縮します。しかし、主要ベンダーのクローズドなエコシステムやOS・ブラウザの対応状況によって、実運用の挙動には依然として様々な違いが存在します。本ページでは、この重要な互換性の実態を5つの切り口から紐解き、各領域における実用的な「互換性達成率」を評価します。

75%

プラットフォーム間 互換性達成率: 75% (実用ステージ)

独自のクラウド同期内では100%シームレスですが、クロスプラットフォーム間はQR/CDAの摩擦が一部残ります。

主要ビッグテックのエコシステム相互運用性

主要プラットフォームにおける同期パスキーは、各ベンダーが独自に展開するクラウド同期エンジン(iCloudキーチェーン、Googleパスワードマネージャー等)に強く依存しています。 Appleは強固な境界内で最高品質の体験を提供し、Googleはクロスプラットフォームに対応した自動入力を展開。MicrosoftはFall 2024以降に同期協調を一新し、外部エコシステムへの連携を強化させています。

Apple エコシステム

iCloud Keychainをベースとし、Apple ID配下のデバイス間で自動エンドツーエンド暗号化同期。外部への直接エクスポートは長い間制限されていましたが、最新API(2025年)で緩和が進んでいます。

Google エコシステム

Google Password Manager (GPM)はAndroidとChromeにネイティブ統合。iOS 17以降でもシステム自動入力として振る舞い、強力な汎用性を有します。

Microsoft エコシステム

Windows Helloによるローカル保存から、Microsoft Accountを軸にしたクラウド同期モデルを強化。他エコシステム(Android, Apple)との双方向同期を急速に整備。

先進決済・IDインフラにおける実用事例

💳 Mastercardの取組 PSD2規制等をクリアするため、銀行のKYCプロセスと連携し、パスキーを決済用カード情報に安全にバインド。フィッシング不能な高セキュリティ決済を確立。
🏦 北欧BankIDの移行劇 ユーザー体験に影響を与えないよう、2023年中にアプリのバックグラウンド更新を介してSMS認証からパスキーへ静かに完全移行、セキュリティ強度を飛躍的に向上。

プラットフォーム同期比較

iCloud Keychain Apple専用

iOS / iPadOS / macOS 間で暗号化自動同期

他エコシステム連携: 不可。QRコード(CDA)による一時認証のみ
Google Password Manager マルチクロス

Android、Chromeブラウザ全般、iOS(一部設定要)

他エコシステム連携: iOS 17以降の自動入力連携で直接動作
Microsoft Hello & Account ハイブリッド

Windowsローカル(TPM) & Azureクラウド同期

他エコシステム連携: Fall 2024以降、Google/Android等と双方向同期開始
85%

OS間 互換性達成率: 85% (高標準ステージ)

iOS, Android, Windowsの最新世代は完全ネイティブ統合済み。Linuxなどのデスクトップのみ物理トークンに限定されます。

オペレーティングシステム層のネイティブ対応と制約

OSレベルでのサポートは、セキュリティカーネルやハードウェア(TPM等)に直結しています。Linuxなどの特殊な例外を除き、現在の主要OSは十分なサポート要件を達成しています。 また、パスキーが端末内に限定される「デバイスバウンド型(物理的複製不可能)」か、他デバイスに広がる「同期型」か、その特性の違いを理解することが極めて重要です。

同期型パスキー (Synced Passkey)

作成された秘密鍵が、クラウドサービス(iCloud/Googleアカウント等)を経由して、同一ユーザーの複数端末へ安全にレプリケーションされます。

  • 端末紛失時でも別端末からログイン可能
  • 初期設定の手間が少なく、一般ユーザー向け

デバイスバウンド型 (Device-Bound)

鍵情報が端末のSecure EnclaveやTPM(ハードウェアチップ)に固定され、外部への書き出しや複製は絶対に不可能です。

  • 軍用・金融レベルの最高機密要件をクリア
  • YubiKey、Windows Hello(個別設定)、Android 16強制オプション等

OS対応マトリクス一覧

iOS / iPadOS
iOS 16〜 (同期型)
macOS
macOS 13〜 (同期型)
Android
Android 9〜 (同期型)
Windows 10 / 11
23H2〜 (ハイブリッド)
Linux (Ubuntu等)
未対応 (物理キーのみ)
90%

ブラウザ間 互換性達成率: 90% (ほぼ完璧なステージ)

Safari、Chrome、Chromium系、Edgeの対応度は極めて強力。Firefoxや特定OS上のWebViewで発生する細かなエッジケースのみ解消が待たれます。

Webブラウザ標準規格と次世代拡張API

Safari、Chrome、EdgeはOSとの深いレイヤー統合によって最上級の自動入力を提供していますが、Firefox等のスタンドアロン型ブラウザでは、高セキュリティサイトでの追加2FA設定の登録処理に失敗するなど、特有の制限が見られることがあります。 この摩擦を最小限に抑えるため、W3CおよびFIDOアライアンスはWebAuthnの仕様拡張を急ピッチで進めています。

Conditional Create (条件付き登録)

ユーザーがパスワードでログインした直後に、モーダル表示を行わず、裏側でシームレスにパスキー作成へと自動誘導してセキュリティレベルをアップグレードする技術。

Signals API

サーバー側で失効された古いパスキーをブラウザや管理ツール側からも自動削除する仕組み。使えない認証情報が候補として残り続けるログイン不具合を防ぎます。

Related Origin Requests (関連オリジン)

多国籍サイトや異なるトップドメイン(`.com`, `.co.jp`, `.ca`)を同一企業が運営する場合、ドメインごとに登録し直す手間なく、1つのパスキーで安全に共用ログインできます。

WebAuthn Client Hints

サーバーから `hints: ["security-key"]` を要求。ブラウザのシステムが最初にセキュリティキー(YubiKey等)の接続を直接誘導するスムーズな導線を形成します。

ブラウザ実装の詳細仕様

Safari (16.1+) 最高品質

Apple OSと100%同調。キーボード上部に最適化候補を埋め込み。

Chrome / Edge 完全対応

2024年秋、デスクトップ版もローカル固定からクラウド同期へ刷新。

Firefox (122+) 限定対応

2FA登録等、一部高度なセキュリティコンテクストの設定で弾かれる不具合報告あり。

80%

デバイス間 互換性達成率: 80% (堅実な普及ステージ)

Bluetoothを用いた近接ハイブリッド認証(CDA)規格は安定。ローカルNFCハードウェア統合と端末同士のペアリング導線にまだいくつかの認知負荷が存在します。

クロスデバイス・ハイブリッド認証と物理セキュリティキー

ユーザーが未登録のデスクトップPCからログインする際、手元のスマートフォンを使って認証を済ませる「ハイブリッド認証(クロスデバイス認証: CDA)」が重要な実用手段となっています。 実務上、このプロセスにはセキュリティ設計の大きく異なる2つのQRコード方式が存在します。

アプリ流用型

① ネイティブアプリ主導QRログイン

Revolut、WhatsApp、TikTok等で使用。デスクトップ画面のQRをスマホカメラで読み取り、スマホ側の既存アプリセッション(有効ログイン状態)を利用してデスクトップ側を承認します。

⚠️ セキュリティ考慮点: 中間者による遠隔詐取(フィッシング)を防ぐため、QRコードの120秒制限、IPアドレスによる位置差分(impossible travel)検知などの高度なインフラ監視体制が必須となります。
WebAuthn標準

② WebAuthn/FIDOハイブリッドQR

固有のアプリ不要。OS標準機能としてQRコードとBluetooth近接検証を介し、2つのデバイス間が「手が届く物理的距離」にあることを担保して安全な秘密鍵処理を行います。

🛡️ Bluetooth近接検証 (caBLE): Bluetoothは「距離の測定」にのみ使われ、秘密鍵などの暗号情報はインターネットを経由した安全なエンドツーエンド暗号化トンネルで送られるため、遠隔の詐取は不可能です。

物理接続メディア・仕様

YubiKey等のセキュリティキー 最も強固。デバイスバウンド型固定フラグ isBackupEligible = 0 で鍵の持ち出しを完全防御。
NFC (近距離無線) スマートフォン(iPhone等)自体を他デバイス向けのNFC物理キーカードとしてエミュレートすることはシステム制限上不可能。
70%

マネージャー間 互換性達成率: 70% (急速成長ステージ)

WindowsプラグインAPIの登場とCXP/CXFによる規格統合が急速に課題を打破。しかし未だ大半のサードパーティ製品とOS間における完全統合への過渡期にあります。

サードパーティ製ツールとポータビリティ標準 (CXP/CXF)

当初懸念されていた「一度登録したパスキーを他のプラットフォームに引越しできない」というベンダーロックイン課題は、FIDOが策定したCXP(Credential Exchange Protocol)およびCXF(Credential Exchange Format)という標準規格により一挙に解決へと進んでいます。 さらにWindows 11での最新アップデート統合に伴い、サードパーティ製マネージャーをOSネイティブの認証器として動作させる道が完全に整備されました。

Windows 11 プラグインAPIによる「役割の完全分離(Split of Responsibilities)」

2025年11月の累積セキュリティアップデートにより、Windows OSの内部構造に専用のプラグインAPIが実装。ローカル認証はOSの生体承認(Windows Hello)が直接担保し、秘密鍵の同期はサードパーティツールが行う協調体制が組まれています。

🛡️ Windows OSが担う役割 ユーザーの生体バイオメトリック(顔・指紋)データ。生体テンプレート情報が外部に漏れ出すことは一切ありません。
🔑 1Password / Bitwarden等が担う役割 エンドツーエンドに暗号化された秘密鍵の保持。クロスプラットフォーム間(Mac、Windows、Android等)の高度な同期・移送。

主要管理ツールの最新仕様要件

1Password MSIXパッケージ必須

Windows 11のシステムネイティブ登録には、従来のEXEインストーラーではなくMSIX形式でパッケージ化された専用ビルドの導入が必要です。

Bitwarden オープン規格に積極的

先行ベータ版経由でWindows Helloとの統合を展開。オープンソースの強みを活かしCXP/CXFに基づく高頻度のインポート連携を実施。

実務における推奨導入ロードマップ

01

WebAuthn動的フロントエンド

ユーザーのブラウザ(Firefoxでの特定2FA画面のエラーやプライベートセッション制限)をあらかじめ自動識別し、WebAuthn Client Hints等を用いて、動的に振る舞いを変えるアダプティブなWebAuthnクライアントコードを実装します。

02

Conditional Createの有効化

従来のパスワードユーザーがサインインを通過したタイミングを捉え、ブラウザの自動入力上でシームレスにパスキー作成へと誘導します。合わせてSignals APIを用いて期限切れや不要な無効認証情報を自動クリーンアップします。

03

外部プロバイダーの全社配置

多種多様なOSとモバイルデバイスが交差する社内環境において、MSIXパッケージ等を導入しOSと完璧に役割分離を行う1PasswordやBitwardenを一元配布。全社規模で認証統合と管理コスト最小化を両立させます。



※パスキーのクロスプラットフォーム間の互換性(75%)は低いですが、これには「クロスデバイス認証」が有力な候補となります。
※補足でクロスデバイス認証の例を記載します。
○Windows⇒Iphone

    このブロック図は、以下の4つの主要なコンポーネントと、それらの間のデータフローを示しています。
    1.Windows PC (ブラウザ: Edge/Chrome): Webサイトにアクセスし、ログインのためにQRコードを表示します。
    2.iPhone (カメラ & 生体認証): カメラでQRコードをスキャンし、Face IDまたはTouch IDで生体認証を行います。
    3.Apple iCloud Keychain / 秘密鍵管理システム (秘密鍵の保管 - iPhone側): 生体認証が成功した後、iPhone上のパスキー(秘密鍵)にアクセスします。この秘密鍵は、クラウド経由で同期されていることを前提としています。
    4.Webサイト・サービス (RPサーバー): 公開鍵で署名を検証し、検証に成功するとWindows PC上のブラウザにログインを許可します。

    図中のBluetoothの破線は、デバイス間の物理的な近接性を確認し、セキュリティを高めるための「近接確認(安全確認)」を示しています。
    これにより、遠隔地からの不正アクセスを防ぐ仕組みになっています。

○Mac⇒Android

    1. Mac PC: QRコード表示
    2. Androidスマートフォン: QRスキャンと生体認証
    3. Googleパスワードマネージャー: 秘密鍵へのアクセス
    4. Webサイト(RPサーバー): 検証と許可
    Bluetooth近接確認によるセキュリティ担保や、クラウド経由での署名データ転送の仕組みも適切に表現されています。
    この構成図は、異なるOS環境におけるパスキーの連携動作を理解するのに非常に役立ちます。

著者:志村佳昭(株式会社トリニタス 技術顧問)