序論：認証技術の歴史的変遷とパスワードの構造的限界
デジタル社会のインフラストラクチャにおいて、個人やシステムを識別し、リソースへのアクセスを制御する認証メカニズムは、長らく「パスワード」という共有シークレット（Shared Secret）技術に依存してきた。しかし、現代の高度に相互接続されたデジタル環境において、パスワードベースの認証アーキテクチャはもはや防衛ラインとして機能不全に陥っている。本報告書では、パスワードの時代が終焉を迎えつつある理由を技術的・構造的観点から解き明かし、その後継となる「パスキー（Passkey）」の仕組みを図解表現を交えながら包括的に整理・分析する。
パスワードの仕組みが内包する致命的な脆弱性は、主に4つの構造的問題に分類される。第一の問題は、人間の認知能力の限界とそれに伴う認証情報の「使い回しによる連鎖漏洩」である。現代のインターネットユーザーは数十から数百のオンラインアカウントを保有しているが、各サービスに対して完全にランダムで推測不可能なパスワードを設定し、それらをすべて記憶することは不可能に近い1。その結果、多くのユーザーが少数のパスワードを複数のプラットフォーム間で使い回すという行動様式をとる。この脆弱性を突いたのが「パスワードリスト攻撃（クレデンシャル・スタッフィング攻撃）」であり、ある一つの脆弱なサービスで発生したデータ漏洩が、強固なセキュリティを持つ他のプラットフォームにおける不正アクセスを連鎖的に誘発する結果を招いている1。
第二の問題は、パスワードがフィッシング詐欺に対して極めて脆弱であるという点である。パスワード認証の根幹は「正しい文字列の入力」にある。したがって、攻撃者が正規のサービスに酷似した偽サイト（フィッシングサイト）を構築し、ユーザーを巧妙に誘導して文字列を入力させれば、どれほど複雑で長大なパスワードであっても即座に攻撃者の手に渡る1。この事実は、システムのセキュリティ水準が技術的な強度ではなく、ユーザー個人の注意力という最も不確実なヒューマンエラー層に依存していることを意味している。
第三の問題は、サーバー側における秘密情報の保管リスクである。パスワード認証は、ユーザーとサーバーが同一の秘密情報を共有し、照合することによって成立する。現代のシステムはパスワードを平文のまま保存せず、暗号学的ハッシュ関数を用いて不可逆なデータとして保管するのが一般的であるが、情報そのものはサーバー側に確実に存在する1。ブルートフォース（総当たり）攻撃やレインボーテーブルを用いた解析技術、さらに計算機能力の飛躍的な向上により、漏洩したハッシュ値から元のパスワードが復元されるリスクは決してゼロではない1。サーバー側がサイバー攻撃を受けた場合、ユーザー側に一切の過失がなくとも認証情報が危険に晒されるというアーキテクチャ上の欠陥が存在する。
第四の問題は、「強いパスワード」と「覚えられるパスワード」の概念的衝突である。セキュリティのベストプラクティスが要求する「大文字、小文字、数字、記号を混在させた12文字以上のランダムな文字列」は計算機科学的には安全性が高いが、人間にとっては記憶不可能である1。その結果、ユーザーは辞書にある単語や誕生日、キーボードの配列（例：「qwerty」や「123456」）などの推測容易なパターンに依存せざるを得ず、攻撃者にとっては辞書攻撃による突破が容易となる1。これらの要因が複合的に作用することで、パスワードという共有シークレットアーキテクチャそのものが、限界を迎えているのである。
パスキーの基盤技術：公開鍵暗号方式によるパラダイムシフト
パスワードの構造的欠陥を根本から解決するために開発されたのが「パスキー（Passkey）」である。パスキーは、FIDOアライアンス（Fast IDentity Online Alliance）とW3C（World Wide Web Consortium）が共同で策定したFIDO2およびWebAuthn（Web Authentication）標準に基づく、フィッシング耐性を持つ次世代の認証クレデンシャルである3。パスキーは特定のプラットフォームに依存する機能ではなく、クロスプラットフォームで利用可能な一般名詞として定義されている4。
パスキーの最大の特徴は、従来の「秘密の文字列を共有する」アプローチから、非対称暗号である「公開鍵暗号方式（Public-Key Cryptography）」を用いたアプローチへの完全なパラダイムシフトにある1。
このアーキテクチャにおいては、ユーザーのアカウントごとに固有の「暗号鍵ペア（公開鍵と秘密鍵）」が生成される。公開鍵（Public Key）はネットワークを通じてサービス提供者のサーバー（Relying Party）に送信され、保存される5。一方、秘密鍵（Private Key）はユーザーのデバイス（スマートフォンやPCなど）内のセキュアなハードウェア領域に厳重に保管され、ネットワーク上に送信されることも、サーバーに共有されることも一切ない1。この公開鍵と秘密鍵のペアは数学的に強い結びつきを持っているが、公開鍵から秘密鍵を逆算することや、一方の鍵だけで認証を完結させることは計算量的に不可能である5。
【図解】パスキーのメカニズムとログインフロー
パスワードとパスキーの仕組みの違いをより明確に理解するため、それぞれの認証フローの構造を整理する。パスキーの認証プロセスは、ネットワーク上に秘密情報を流すことなく、「所有の証明（Proof of Possession）」を行う「チャレンジ＆レスポンス（Challenge & Response）」方式を採用している1。以下に、パスキーの「登録（Registration）」および「ログイン（Authentication）」のシーケンスを図解的テキスト表現で示す。
パスキー登録時のシーケンスモデル
登録フェーズでは、デバイス上で新しい鍵ペアが生成され、公開鍵のみがサーバーに渡される。
[ユーザーデバイス (認証器)] [ウェブサービス (サーバー)]
| |
| 1. アカウント登録/パスキー設定の要求を開始 |
|———————————————————->|
| |
| 2. サーバーからの登録要求（ユーザーIDなどの情報） |
|<———————————————————-|
| |
| 3. 生体認証（指紋/顔）またはPINによるローカル本人確認 |
| (※生体情報はデバイス内に留まる) |
| |
| 4. デバイス内で「公開鍵」と「秘密鍵」のペアを生成 |
| (※ドメイン情報と強固に紐付けられる) |
| |
| 5. 「公開鍵」のみをサーバーへ送信 |
|———————————————————->|
| |
| 6. ユーザーIDと「公開鍵」を|
| データベースに安全に保存|
パスキーログイン時のシーケンスモデル（チャレンジ＆レスポンス）
ログインフェーズでは、サーバーが生成したランダムな課題（チャレンジ）に対し、デバイスが秘密鍵で署名（レスポンス）を返すことで認証が成立する。
[ユーザーデバイス (認証器)] [ウェブサービス (サーバー)]
| |
| 1. ログイン要求 (ユーザーIDを送信) |
|———————————————————->|
| |
| 2. 暗号学的に安全なランダム|
| データ「チャレンジ」生成|
| |
| 3. 「チャレンジ」をデバイスへ送信 |
|<———————————————————-|
| |
| 4. 生体認証（指紋/顔）またはPINによるローカル本人確認 |
| (※秘密鍵のロックを解除するためのゲートキーパー) |
| |
| 5. デバイス内の「秘密鍵」を用いて、受け取った |
| 「チャレンジ」に対する『デジタル署名』を生成 |
| |
| 6. 生成した『デジタル署名』をサーバーへ返送 |
|———————————————————->|
| |
| 7. 事前に保存していた |
| 「公開鍵」を用いて |
| デジタル署名を検証 |
| |
| 8. 検証成功・ログイン許可 |
|<———————————————————-|
パスキーのログインプロセスにおいて、サーバーが生成する「チャレンジ」は、少なくとも16バイト以上の暗号学的に安全なランダム値である1。このランダム値はセッションごとに毎回異なるため、攻撃者がネットワーク通信を傍受して過去の署名データを取得したとしても、それを次のログインに再利用する「リプレイ攻撃」を完全に防ぐことができる1。
以下の表は、パスワード認証とパスキー認証におけるアーキテクチャおよびセキュリティ特性の構造的な違いを比較したものである1。
| 比較・評価軸 | パスワード（Password） | パスキー（Passkey） |
| 認証のコア概念 | 共有シークレット（Something you know） | 非対称暗号による所有の証明（Something you have + who you are） |
| ネットワーク送信データ | 秘密情報（パスワードの文字列）そのもの | ランダムなチャレンジに対するデジタル署名 |
| ユーザーの認知負荷 | 極めて高い（複雑な文字列の記憶が必須） | 無し（デバイスの生体認証・PINのみで完結） |
| サーバー側の保管情報 | パスワードのハッシュ値（秘密情報由来） | 公開鍵（パブリックな情報）のみ |
| サーバー漏洩時の影響 | アカウント乗っ取り・リスト攻撃の標的となる | 被害無し（公開鍵単体では偽造や認証の突破は不可能） |
| フィッシング耐性 | 低い（偽サイトに入力すると即座に漏洩） | 極めて高い（ドメインバインディングにより構造的に防御） |
| クレデンシャルの使い回し | 非常に一般的（ヒューマンエラーの温床） | 構造的に不可能（サービスごとに完全に固有の鍵ペアを生成） |
生体認証の役割とドメインバインディングによる強力な防御機構
パスキーのユーザーエクスペリエンス（UX）は、スマートフォンやPCのロック解除と全く同じ操作で完結する。ユーザーはユーザーネームやパスワードを入力する代わりに、生体認証（指紋や顔認証）またはデバイスのPINコードを使用してログインを承認する4。この認証フローの摩擦の少なさは、ログインにかかる時間を大幅に短縮し、パスワードの忘却によるリセット手続きの負担を完全に排除する8。
しかし、この簡便さゆえに「自身の指紋や顔のデータがウェブサイトのサーバーに送信されているのではないか」というセキュリティ上の誤解を生むことがある。技術的な実態はまったく異なる。パスキーアーキテクチャにおいて、生体認証データはデバイスのセキュアなハードウェア領域（例：AppleのSecure Enclave）から外部に出ることは決してない1。生体認証やPINの役割は、デバイス内に厳重にロックされている「秘密鍵」にアクセスし、署名操作を許可するための「ローカルでの所有者確認（Owner Verification）」ゲートとして機能することに限定されている1。すなわち、パスキーによる認証とは「秘密鍵を保持するデバイス（Something you have）」と「それを操作する正規のユーザー（Who you are）」の二要素を組み合わせた、強力な多要素認証（MFA）の進化形なのである7。
さらに、パスキーがパスワードに対して圧倒的な優位性を誇る最大の理由が、「ドメインバインディング（Domain Binding）」に基づく構造的なフィッシング耐性である1。 パスキーを生成する際、作成される鍵ペアはそのウェブサイトの正規のドメイン（Relying Party ID）のメタデータと暗号学的に厳密に紐付けられる1。仮にユーザーが精巧に作られたフィッシングメールに騙され、正規サイト（例：amazon.co.jp）に酷似した偽サイト（例：amaz0n.co.jp）にアクセスしたとする。従来のパスワードであれば、ユーザー自身が騙されているため、パスワードを入力してしまい漏洩に繋がる2。 しかしパスキーの場合、認証要求を受けたブラウザおよびデバイスのOS（認証器）が、現在アクセスしているドメインと、パスキーに紐付いたドメインが一致しないことをプロトコルレベルで自動的に検知する1。不一致が検知されると、デバイスは秘密鍵の呼び出しを拒否し、署名操作のプロンプト自体をユーザーに表示しない2。また、攻撃者が正規のサーバーから有効なチャレンジを取得してユーザーのデバイスに署名させようと試みたとしても、デバイスが生成する署名データには攻撃者のドメイン情報が付与されるため、正規サーバー側での検証プロセスで不一致が発覚し、認証は確実に失敗する5。このように、パスキーはユーザーの注意力に依存することなく、テクノロジーの構造によってソーシャルエンジニアリング攻撃を無力化している。
CTAPとクロスデバイス認証（ハイブリッドフロー）のアーキテクチャ
パスキーのエコシステムは、単一のデバイス上での認証に留まらず、複数の異なるデバイス間でシームレスに認証を行うための標準規格を備えている。これを支えるのが、FIDOの「Client-to-Authenticator Protocol（CTAP）」である。WebAuthnがブラウザ（システム）とウェブサイト（サーバー）間の通信を標準化する役割を持つのに対し、CTAPはユーザーの主要なデバイス（ラップトップなど）と、実際に秘密鍵を保持している認証器（スマートフォンやハードウェアセキュリティキーなど）の間のローカル通信を標準化する9。
CTAP 2.2によって拡張された「FIDO Cross-Device Authentication（CDA）」、通称「ハイブリッドフロー（Hybrid Flow）」は、あるデバイスに保存されたパスキーを用いて、別のデバイスでのログインを可能にする画期的なメカニズムである4。最も一般的なユースケースは、ユーザーがラップトップのブラウザでサービスにログインしようとした際、画面に表示されたQRコードをスマートフォンのカメラでスキャンし、スマートフォン側の生体認証を用いてラップトップ側のログインを完了させるフローである4。
このハイブリッドフローのセキュリティモデルは極めて高度に設計されている。QRコードには、FIDO URLとしてエンコードされたルーティング情報、セッション固有のシークレット、および一時的な公開鍵（Ephemeral Public Key）が含まれている12。スマートフォンがこれをスキャンすると、Bluetooth Low Energy（BLE）のアドバタイズメントを利用して両デバイス間の「物理的な近接性（Physical Proximity）」が証明される。これは、地球の裏側にいる攻撃者が遠隔から認証要求を送りつける攻撃を防ぐための重要なプロセスである4。近接性が確認されると、デバイス間で使用される標準的なBluetoothのセキュリティ特性に依存するのではなく、CTAPのハイブリッドトランスポート仕様に基づき、交換した鍵情報を用いて独立した強力なエンドツーエンド暗号化トンネルがローカルに構築される4。スマートフォンの秘密鍵で生成された署名データは、この暗号化トンネルを経由してラップトップへ安全に伝送されるため、ネットワーク経由での盗聴や改ざんは不可能である。
ハイブリッドフローの応用は、QRコードの枠を超えて多様なプラットフォームで進化している。Meta QuestなどのXR（Cross Reality）デバイス環境では、ヘッドセットを装着したユーザーに対して物理的なQRコードを提示し、それをスマートフォンでスキャンさせるという視覚的な操作は極めて困難である12。この課題を解決するため、Metaはヘッドセット内でFIDO URL（QRコードに相当するペイロード）を生成した後、それを画像としてレンダリングするのではなく、ユーザーの同一アカウントでサインインしているスマートフォンの「Meta Horizonアプリ」に対し、認証済みのGraphQLベースのプッシュ通知チャネルを用いてFIDO URLを直接データとして送信するシステムを構築した12。ユーザーはスマートフォンの通知をタップするだけで、ハイブリッドトランスポートシーケンス（BLEブロードキャストと暗号化トンネルの確立）を自動的に開始でき、VR空間でのシームレスなパスキー認証を実現している12。
また、パスワードマネージャーのBitwardenは、このハイブリッドプロトコルを応用し、OSレベルでのWebAuthnフレームワークが不足しているレガシーなAndroidデバイス向けにネイティブプロトコルスタックを提供するソフトウェアベースのローミング認証器機能を開発している13。さらに、公共の端末などの信頼できない環境（Untrusted Environments）においてブラウザ拡張機能にログインする際、メールアドレスやマスターパスワードの入力を一切行わず、ハイブリッドチャネルを介して認証結果を直接送信する「QRコードログイン」を実装している。これにより、キーボード入力を完全に迂回し、ハードウェアレベルのキーロガー攻撃を根本から防止することが可能となっている13。
同期型パスキーとプラットフォームの暗号化エコシステム
FIDO標準の初期実装においては、秘密鍵を単一の物理的なUSBハードウェア（セキュリティキー）から決して外に出さない「デバイスバウンド（Device-bound）」の概念が主流であった。このアプローチは極めて高いセキュリティ保証（High Assurance）を提供するが、デバイスを紛失した際にその鍵を使用するすべてのアカウントへのアクセスを喪失するという致命的な可用性の課題があり、消費者市場での普及を妨げる大きな障壁となっていた1。
このユーザビリティのジレンマを解決するため、2022年にApple、Google、Microsoftのプラットフォーム企業が協調して導入したのが「同期型パスキー（Synced Passkeys）」である1。同期型パスキーでは、秘密鍵はデバイス内のハードウェアセキュリティモジュール（HSM）で生成された後、デバイス固有の暗号鍵で強力に暗号化された状態で、プラットフォームのクラウドインフラ（Apple iCloud KeychainやGoogle Password Managerなど）を介してユーザーの他のデバイスに同期される1。これにより、iPhoneで作成したパスキーが自動的にMacでも利用可能となり、機種変更時にもシームレスにクレデンシャルが引き継がれるという、パスワード同等以上の利便性が実現された16。
クラウドプロバイダーにおけるエンドツーエンド暗号化と信頼の輪
同期型パスキーに対する最大の懸念は、プラットフォーム提供企業（AppleやGoogle）のサーバーがサイバー攻撃を受けた場合や、企業自身がユーザーの秘密鍵にアクセスして悪用するのではないかという点である。しかし、これらのクラウドバックエンドは厳密な「エンドツーエンド暗号化（End-to-End Encryption: E2EE）」アーキテクチャによって構築されており、そのリスクは構造的に排除されている1。
Appleの「iCloud Keychain」のセキュリティモデルを詳細に分析すると、パスキーの同期・保存プロセスが極めて高度な防御機構の上に成り立っていることが理解できる。iCloud Keychainのデータは、Apple自身にも知られていない強力な暗号鍵を用いてE2EEで保護されており、ユーザーのデバイス上でしかアクセス・復号することができない19。Appleの設計方針は、ユーザーのアカウントが侵害された場合、iCloudのインフラストラクチャが外部の攻撃者または内部の従業員によって侵害された場合、さらにはサードパーティがユーザーアカウントにアクセスした場合であっても、パスキーが保護され続けることを保証している19。
このセキュリティを担保するため、iCloud Keychainを利用するすべてのApple Accountには二要素認証（2FA）の有効化がシステムレベルで強制される19。2FAが未設定の状態でパスキーを登録しようとすると、自動的にセットアップフローが起動し、以後は新しいデバイスでのサインイン時にパスワードに加えて、信頼できるデバイスに送信される6桁の確認コードが必須となる19。 さらに、iCloud Keychainの同期プロセスには「信頼の輪（Circle of Trust）」という厳格なメカニズムが採用されている。ユーザーが初めてiCloud Keychainを有効にした際、そのデバイスは固有のキーペアを生成し、自身を基点とする同期アイデンティティを確立する19。新しいデバイスがこの同期サークルに参加するためには、すでにサークル内に存在する信頼されたデバイスとのペアリングによる「スポンサーシップ」を受けるか、後述する厳格なリカバリプロセスを完了する必要がある。この仕組みにより、攻撃者がパスワードやSMS認証を突破したとしても、既存のデバイスの承認なしに勝手に同期サークルに加わりパスキーを窃取することは不可能である19。
Google Password Managerにおいても同様のセキュリティ原則が貫かれており、パスキーは常にE2EEで暗号化され、暗号化された秘密鍵のみがGoogleのサーバーにアップロードされる。この暗号化と復号のプロセスはすべてユーザーのデバイス上の暗号鍵を用いてローカルで実行されるため、Googleのサーバー管理者であっても中身を読み取ることはできない16。
エスクローセキュリティとアカウント復旧のメカニズム
同期型パスキーは複数デバイス間での冗長性を提供するが、「ユーザーがすべてのデバイスを同時に喪失する」という最悪のシナリオ（例えば、火災による全損や旅行先での全デバイスの盗難など）に対するセーフティネットが不可欠である。Appleはこの課題に対し、「iCloud Keychain Escrow」という高度なバックアップ・復元機構を提供している19。
エスクローサービスは、ユーザーのキーチェーンデータのコピーを強力なデバイスパスコードを用いて暗号化し、Appleのサーバーに保管する機能である。Appleのサーバーは暗号化されたデータブロックを保持するのみであり、復号するための鍵を持たない19。ユーザーがすべてのデバイスを喪失し、全く新しいデバイスからパスキーを含むキーチェーンを復旧するためには、厳格な条件を満たす必要がある。 具体的には、iCloudアカウントのIDとパスワードでの認証、登録済み電話番号でのSMS検証、そして「過去に使用していたデバイスのパスコード（またはMacのログインパスワード）」の正確な入力という多要素の証明が要求される19。
セキュリティを担保するための特筆すべき機能として、ブルートフォース攻撃への徹底した対策が挙げられる。iOSやmacOSは、エスクローデータに対するパスコードの入力試行回数を最大「10回」に厳格に制限している19。数回の失敗でアカウントは一時的にロックされ、Apple Supportへのコンタクトが必要となる場合がある。そして、10回の試行すべてに失敗した場合、サーバー上のエスクローレコードは自己破壊（Self-Destruct）メカニズムによって永久に消去・破棄され、いかなる手段を用いてもデータの復元は不可能となる19。
また、ユーザーがApple Accountのパスワードやデバイスのパスコード自体を忘却してしまうリスクに備え、iOS 15以降およびmacOS Monterey以降のデバイスにおいて「アカウント復旧連絡先（Account Recovery Contact）」を設定する機能が提供されている19。13歳以上のユーザーで2FAとiMessageが有効になっている環境であれば、信頼できる家族や友人を最大5人まで復旧連絡先として指定できる。復旧連絡先として指定された人物は、ユーザーのデータに一切アクセスすることはできないが、ユーザーがアカウントから締め出された際に、復旧のための6桁のセキュリティコードを生成し、口頭や電話でユーザーに伝える役割を担う19。これにより、パスワード忘却時においてもクレデンシャルの完全な喪失を防ぐ運用が可能となっている。
エンタープライズ環境における展開とポリシー制御：Microsoft Entra IDの事例
コンシューマー市場における同期型パスキーの普及と並行して、企業や組織のID管理基盤においてもパスキーの導入が急速に進展している。Microsoftのエンタープライズ向けID管理プラットフォームである「Microsoft Entra ID」の運用事例は、企業環境におけるパスキーの戦略的価値を如実に示している。
Microsoftのデータ報告によれば、現在Entra IDユーザーの約半数が多要素認証（MFA）によって保護されているものの、従来のMFA（SMSベースのワンタイムパスワードなど）は使い勝手の悪さやフィッシングの標的になるという課題を抱えており、組織にとって高いトレーニングコストと生産性の低下をもたらしていた22。これに対する解決策として、MicrosoftはEntra IDにおいて同期型パスキーのサポートを拡張した。同期型パスキーの導入により、Microsoftのコンシューマーエコシステムにおけるサインイン成功率は、従来のレガシー認証方式の30%から95%へと劇的に向上し、さらにサインインにかかる時間はパスワードとコードベースのMFAの組み合わせと比較して14倍も高速化されたという実績が報告されている22。
企業環境において特筆すべきは、組織のセキュリティ要件に応じた「パスキープロファイル（Passkey Profiles）」のきめ細やかなポリシー制御である15。Microsoft Entra IDの管理者は、認証強度に関する条件付きアクセス（Conditional Access）ポリシーを設定する際、パスキーの種類を厳密に制限することができる15。
管理者は、すべての従業員に対してApple iCloud KeychainやGoogle Password Managerなどのクラウドパスキープロバイダーを利用した「同期型パスキー」を許可し、利便性とリカバリの容易さを優先する設定を行うことができる14。その一方で、極めて機密性の高いデータにアクセスする特権管理者グループに対しては、同期型パスキーの使用を禁止し、FIDO2セキュリティキーやMicrosoft Authenticatorアプリのデバイスバウンド（同期不可）プロファイルのみを許可するといった、「Target Specific Passkeys」に基づく高度なアクセス制御（AAGUIDによる制限など）を実装することが可能である15。このように、エンタープライズの運用においては、利便性を追求する同期型パスキーと、最高レベルの保証（High Assurance）を要求するデバイスバウンドパスキーをハイブリッドで管理する手法が標準となりつつある。
次世代の進化：パスワードマネージャーとPRF拡張によるエンドツーエンド暗号化
パスキー技術の普及は、認証（Authentication）の領域にとどまらず、データ暗号化（Encryption）のパラダイムにも革新をもたらしている。その最前線にあるのが、1PasswordやBitwardenといったパスワードマネージャープラットフォームによる「PRF（Pseudo-Random Function：擬似乱数生成機能）拡張」の実装である24。
従来のパスキーの基本機能は、デジタル署名による「身元の証明」に特化していた。公開鍵暗号方式における秘密鍵は署名の生成には利用できるものの、プラットフォームを跨いで同一の秘密鍵から直接データの暗号化・復号に用いる共通鍵を取り出す標準的な仕組みはWebAuthnには存在しなかった24。そのため、パスワードマネージャーなどがユーザーの機密データ（Vault/保管庫）をエンドツーエンドで暗号化する際、マスターパスワードという「共有シークレット」に依存し続ける必要があった。
この課題を解決する技術が、WebAuthn標準の「PRF拡張」である。PRF拡張をサポートする認証器（OSやハードウェアキー）は、パスキーの認証プロセスの中で、パスキー固有の内部シークレットを基にして、暗号学的に安全で予測不可能な「PRF対称鍵（Symmetric Key）」をローカル環境で決定論的に再生成・出力することが可能となる24。
BitwardenにおけるPRF拡張を利用したエンドツーエンド暗号化の確立プロセスは、極めて洗練された多層的復号連鎖として実装されている25。
- ユーザーがパスキーを用いてBitwardenにログインすると、サーバー側から提供される固有のソルト（Salt）と、デバイス内のパスキーの内部シークレットを組み合わせて、PRF対称鍵がローカルで再生成される。
- 生成されたPRF対称鍵を用いて、あらかじめ暗号化されて保存されていたユーザーの「PRFプライベートキー」が復号される。
- 復号されたPRFプライベートキーを用いて、ユーザーの「アカウント暗号化キー」が復号される。
- 最終的に、このアカウント暗号化キーを用いて、Bitwardenの保管庫（Vault）内に保存されているパスワードや機密データが、ローカル環境で平文へと復号される。
このプロセスにより、マスターパスワードというユーザーの記憶に依存した脆弱な鍵を完全に排除しつつ、パスキー単体による強力なエンドツーエンド暗号化を維持することが可能となった25。
さらに、エンタープライズ環境向けの「組織（Organization）」機能において、複数ユーザー間で機密データを安全に共有するための鍵管理メカニズムも高度化されている。Bitwardenでは、組織の保管庫を復号するための「組織の対称鍵」を管理するためにRSA-OAEP（Optimal Asymmetric Encryption Padding）を使用している25。組織の対称鍵はBitwardenのサーバーに平文で保存されることは決してない。組織が作成された瞬間、その対称鍵は組織作成者のRSA公開鍵を用いて暗号化される。 新規メンバーが組織に追加される際、すでに復号済みの組織対称鍵をローカルメモリ内に保持している既存メンバーのクライアントアプリケーションが、新規メンバーのRSA公開鍵をサーバーから取得する。そして、その公開鍵を用いて組織対称鍵を暗号化し直し、サーバーにアップロードするというプロセスを経る25。これにより、クラウドサーバーをデータの中継地として利用しながらも、暗号化鍵の平文へのアクセス権をプラットフォーム提供者（Bitwarden）に一切与えない「ゼロ知識アーキテクチャ（Zero-Knowledge Architecture）」が維持されている。
1Passwordにおいても同様に、パスキーとPRF拡張を組み合わせたパブリックベータを展開しており、アカウントパスワードやシークレットキーに依存しないVaultの復号を実現している24。1Passwordは自社のオープンソースパスキーライブラリを通じてこのPRF実装を公開しており、他のアプリケーションやウェブサービスがパスキーを採用する際に、認証と同時にユーザーデータのエンドツーエンド暗号化を容易に実装できるエコシステムの構築を業界全体で牽引している24。
移行期における課題とハイブリッド運用戦略
パスキーの技術的優位性とアーキテクチャの強固さは疑いようもないが、パスワードの完全な終焉に至るまでの過渡期においては、いくつかの現実的な運用課題が顕在化している。2026年現在の状況を俯瞰すると、大手プラットフォーマー（Apple、Google、Microsoft）や先進的なSaaSプロバイダーが一斉にパスキー対応を進めているものの、ビジネスインフラや一般生活において利用されるすべてのサービスがパスキーに対応しているわけではない。プロジェクト管理ツール、会計ソフトウェア、業界特化型のレガシーアプリケーションの多くは依然としてパスワード認証に依存しており、企業や個人の認証環境は、パスワード、パスキー、そしてパスワードマネージャーが混在するハイブリッドな状態にある26。
残存する最大の課題の一つは、「デバイス紛失時のリカバリ手段の断片化」である1。同期型パスキーを使用していれば、同一プラットフォーム（例：Appleエコシステム内）の別端末からの復旧は担保されているが、プラットフォームを跨いだ鍵の移行手段や、サービス提供者側でのアカウント復旧（Account Recovery）プロセスは統一されていない1。サービスごとにリカバリの設計が異なるため、ユーザー目線での実用的な安全策としては、「パスキーをスマートフォンとPCなど、2つ以上の異なるOS・端末に個別に登録しておくこと」や「サービスが提供するリカバリーコードを物理的に安全な場所に退避しておくこと」という、運用によるリスクヘッジが依然として求められている1。
また、企業の情報システム部門における導入戦略としては、パスキーがすべてのツールでサポートされる日を待つのではなく、「利用可能な高付加価値アカウントから段階的にパスキーを適用する」アプローチが推奨されている27。メール、クラウドストレージ、財務プラットフォームなどの重要インフラにはパスキーを最優先で適用し、フィッシングによる不正アクセス経路を遮断する。同時に、未対応のシステムに対しては、信頼できるパスワードマネージャーを用いて、複雑で一意なパスワードを自動生成し管理する従来のベストプラクティスを継続する7。このハイブリッドなマネージドクレデンシャル戦略こそが、過渡期における組織のセキュリティポスチャを最適化する現実的な解である7。
結論
パスワードの時代が終焉に向かっている理由は、セキュリティの境界線を人間の脆弱な記憶力と注意力という最も不確実な要素に依存させているアーキテクチャの構造的な限界にある。クレデンシャル・スタッフィング攻撃や高度なフィッシング詐欺が常態化する現代の脅威ランドスケープにおいて、共有シークレットに基づく認証モデルはもはや持続可能ではない。
パスキーは、FIDO2およびWebAuthnの公開鍵暗号技術を基盤とし、認証の主体をユーザーの記憶からデバイスのセキュアなハードウェアモジュールへと移行させることで、この問題を根本的に解決した。生体認証やPINによるローカルでの所持確認と、プロトコルレベルで組み込まれたドメインバインディング機能により、パスキーはフィッシング攻撃やサーバー情報の漏洩に対して構造的な無敵性（Phishing-resistant）を獲得している。
さらに、Apple iCloud KeychainやGoogle Password Managerに代表されるエンドツーエンド暗号化を伴う同期メカニズムは、高いセキュリティを維持したままデバイス紛失時の可用性を担保し、これまでのパスワード入力に依存していた摩擦の多いユーザーエクスペリエンスを劇的に改善した。CTAP 2.2によるハイブリッドフローの実装は、QRコードやプッシュ通知、さらにはパスワードマネージャーのネイティブプロトコルを介したセキュアな通信トンネルを構築し、XRデバイスやレガシーシステムを含むあらゆるエンドポイントでのシームレスな認証体験を実現している。そして、WebAuthnのPRF拡張技術は、パスキーの役割を単なる「身元の証明」から、ゼロ知識アーキテクチャに基づく「ユーザーデータのエンドツーエンド暗号化基盤」へと進化させつつある。
現在はまだパスワードからの移行期にあり、リカバリプロセスの標準化やサービスプロバイダー側の対応拡大など、実運用上の課題は残されている。しかし、認証プロセスからパスワードという共有秘密情報のネットワーク送信を完全に排除するパスキーのアーキテクチャは、サイバーセキュリティの防御モデルにおいて不可逆的な進化である。それは単なる新しいログイン手段ではなく、デジタルアイデンティティ管理の未来を決定づけ、安全なデジタル社会を支える不可欠なインフラとして確固たる地位を確立しつつある。
引用文献
- パスワードの時代が終わる理由 – パスキーの仕組みを図解でわかりやすく整理する – Qiita, 5月 28, 2026にアクセス、 https://qiita.com/ktdatascience/items/78212f9f851ffe97f3d9
- パスキーとは？しくみ・メリット・導入事例をわかりやすく解説, 5月 28, 2026にアクセス、 https://www.digitalsales.alsok.co.jp/col_passkeys
- Password vs Passkey: Key Differences & Security Comparison – SentinelOne, 5月 28, 2026にアクセス、 https://www.sentinelone.com/cybersecurity-101/identity-security/password-vs-passkey/
- FIDO Passkeys: Passwordless Authentication, 5月 28, 2026にアクセス、 https://fidoalliance.org/passkeys/
- ELI5: What is a Passkey and why are so many websites trying to get me to use one?, 5月 28, 2026にアクセス、 https://www.reddit.com/r/PasswordManagers/comments/1rg3nl4/eli5_what_is_a_passkey_and_why_are_so_many/
- パスキーの解説：WebAuthnと公開鍵セキュリティ | BitGo | JA-JP, 5月 28, 2026にアクセス、 https://www.bitgo.com/ja-jp/resources/blog/how-webauthn-replaces-passwords-with-public-key-security/
- Passkey vs password: What’s the difference? – Bitwarden, 5月 28, 2026にアクセス、 https://bitwarden.com/resources/passkey-vs-password-whats-the-difference/
- Passkey vs password: What is the difference? – Proton, 5月 28, 2026にアクセス、 https://proton.me/blog/passkey-vs-password
- CTAP（Client-to-Authenticator-Protocol）とは？FIDO2・WebAuthn …, 5月 28, 2026にアクセス、 https://www.corbado.com/ja/glossary/ctap
- Sign in with passkeys in Authenticator for Android and iOS devices – Microsoft Entra ID, 5月 28, 2026にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-sign-in-passkey-authenticator
- High assurance hybrid flows – WebAuthn – Yubico Developers, 5月 28, 2026にアクセス、 https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows/High_assurance_hybrid_flows/
- No Display? No Problem: Cross-Device Passkey Authentication for XR Devices, 5月 28, 2026にアクセス、 https://engineering.fb.com/2026/02/04/security/cross-device-passkey-authentication-for-xr-devices-meta-quest/
- Native FIDO Hybrid Protocol (Passkey) Support & QR Code Login for Untrusted Environments – Bitwarden Community Forums, 5月 28, 2026にアクセス、 https://community.bitwarden.com/t/native-fido-hybrid-protocol-passkey-support-qr-code-login-for-untrusted-environments/94084
- Passkey FAQs – Microsoft Entra ID, 5月 28, 2026にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/passkey-faq
- How to enable passkeys (FIDO2) in Microsoft Entra ID, 5月 28, 2026にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2
- パスワードでログインはもう古い？「パスキー」の仕組みと特徴 …, 5月 28, 2026にアクセス、 https://blog.trainocate.co.jp/blog/sec-passkey?hsLang=ja
- Authentication methods in Microsoft Entra ID – passkeys (FIDO2), 5月 28, 2026にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2
- 5月 28, 2026にアクセス、 https://developers-jp.googleblog.com/2022/11/security-of-passkeys.html#:~:text=Google%20Password%20Manager%20%E3%81%AE%E3%83%91%E3%82%B9%E3%82%AD%E3%83%BC%E3%81%AF%E3%80%81%E5%B8%B8%E3%81%AB%E3%82%A8%E3%83%B3%E3%83%89%E3%83%84%E3%83%BC%E3%82%A8%E3%83%B3%E3%83%89,%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E8%A1%8C%E3%81%84%E3%81%BE%E3%81%99%E3%80%82
- About the security of passkeys – Apple Support, 5月 28, 2026にアクセス、 https://support.apple.com/en-us/102195
- Passkeys Overview – Apple Developer, 5月 28, 2026にアクセス、 https://developer.apple.com/passkeys/
- iCloud Keychain security overview – Apple Support, 5月 28, 2026にアクセス、 https://support.apple.com/guide/security/icloud-keychain-security-overview-sec1c89c6f3b/web
- Synced passkeys and high assurance account recovery – Microsoft Community Hub, 5月 28, 2026にアクセス、 https://techcommunity.microsoft.com/blog/microsoft-entra-blog/synced-passkeys-and-high-assurance-account-recovery/3627343
- Synced Passkeys in Microsoft Entra for Phishing-resistant MFA, 5月 28, 2026にアクセス、 https://techcommunity.microsoft.com/blog/microsoftmechanicsblog/synced-passkeys-in-microsoft-entra-for-phishing-resistant-mfa/4472994
- 1PasswordのPasskeyによるデータ暗号化を理解したい – Zenn, 5月 28, 2026にアクセス、 https://zenn.dev/ffjlabo/scraps/b8629d343117c4
- Bitwardenセキュリティホワイトペーパー, 5月 28, 2026にアクセス、 https://bitwarden.com/ja-jp/help/bitwarden-security-white-paper/
- passkey vs password: what’s the difference and which one should you use? – Reddit, 5月 28, 2026にアクセス、 https://www.reddit.com/r/IdentityManagement/comments/1ssguc4/passkey_vs_password_whats_the_difference_and/
- Passkeys, iCloud Keychain, and Apple’s Built-In Security Stack – What’s Enough and What’s Not – Dr Logic, 5月 28, 2026にアクセス、 https://drlogic.com/article/passkeys-icloud-keychain-and-apples-built-in-security-stack-whats-enough-and-whats-not/
