パスキー移行の実装手順：パスワード併存からSignal API・CXPでの鍵移行まで

サーバ側で無効にしたはずのパスキーが、スマートフォンのオートフィル候補に残り続ける。パスキー移行の実務でつまずく箇所は、鍵の生成ではなく移行期間中の状態のずれです。本記事は、サービス提供側（RP）がパスワード認証からパスキーへ切り替える実装と、利用者が端末やパスワードマネージャを乗り換えるときに資格情報そのものを持ち出す作業を、別々の課題として整理します。パスキー登録を促す4つのタイミング、excludeCredentialsの指定、Signal APIによる状態同期、FIDOのCXP／CXFによる鍵の移行までを、2026年9月時点の一次情報で確認した内容です。パスワードを完全に廃止すべきでない条件も、最終章で条件付きに言い切ります。

まとめ：パスキー移行で先に確定させる実装順序とアカウント回復方針

パスキー移行という言葉は、2つの別作業を指しています。ひとつはRPが認証方式をパスワードからパスキーへ切り替える実装、もうひとつは利用者が端末やパスワードマネージャを乗り換えるときに鍵そのものを移す操作。前者はWebAuthnとCredential Manager、後者はFIDOアライアンスのCXP／CXFが担当します。要件定義でこの2つを混ぜると、RP側の実装で解決できない話をRP側の課題として抱え込むことになります。

実装順序の結論から示します。第1段階はパスワードを残したままパスキーを追加登録できる状態、第2段階はサインイン画面でパスキーを優先提示する状態、第3段階でようやくパスワード廃止の是非を検討する順序です。第2段階と第3段階の間にSignal APIによる状態同期を挟まないと、サーバで削除した資格情報が利用者の端末に残り、認証失敗と問い合わせが増えます。

アカウント回復の方針も、移行を始める前に決めておきます。パスキーだけに寄せた設計は、端末紛失時の負荷がすべてサポート窓口の本人確認に集まる構造。共用端末やキオスク端末を含む業務システムでは、パスワードの完全廃止を見送る判断が妥当です。その分岐条件は最終章で具体的に示します。

パスキー移行に含まれる2種類の作業と認証方式・資格情報の切り分け

最初に、自社が取り組もうとしている移行がどちらなのかを確定させます。ここを曖昧にしたまま設計に入ると、RP側の実装範囲が無限に膨らみます。

サービス側の移行：パスワード併存からパスキー優先へ切り替える段取り

RP側の移行とは、既存のパスワード認証を残したままパスキーを登録させ、サインインの主経路を入れ替えていく作業です。いきなりパスワードを廃止する設計は採用しません。理由は単純で、パスキー未対応のブラウザや、生体認証を設定していない端末からのアクセスが残るからです。

段取りは3段階に分けます。第1段階でパスキーの追加登録を開放し、第2段階で既存利用者にパスキー作成を促し、第3段階でパスワード認証の扱いを見直す。この間、認証基盤側では「同一アカウントに複数のパスキーが紐づく」状態が常態になります。パスキーという仕組みそのものの前提や、パスワード・二段階認証との違いはパスキー認証とは？仕組み・パスワードとの違い・企業の導入判断を解説で整理しているため、本記事では移行の実装に絞ります。

利用者側の移行：端末とパスワードマネージャをまたいだ鍵の持ち出し

もうひとつの移行は、利用者が保存済みのパスキーを別の保管先へ移す操作です。従来この操作はできませんでした。パスワードは暗号化されていないテキストファイルに書き出して移せた一方、パスキーは移せず、サービスごとに作り直すしかなかったためです。Googleは2026年9月10日、Android上でパスワードマネージャ間の移行を開始したと公式ブログで公表しました。

この移行はRPの実装とは無関係に成立します。鍵はプロバイダ間で直接受け渡され、RPのサーバは関与しないためです。ただしRP側には別の影響が出ます。鍵の保管先が変わってもcredentialIdは変わらないため、サーバ側のレコードはそのまま有効である一方、利用者から見た「どのアプリに入っているか」は変化する。サポート対応の想定問答を更新しておく必要があります。

パスワード認証からパスキー登録へ誘導する4つのタイミングと実装箇所

既存利用者にパスキーを作ってもらえなければ、移行は第1段階で止まります。どこで作成を促すかは、実測にもとづいた定石があります。

アカウント登録・サインイン・回復・パスワード再設定の4箇所での要求

Googleが公開しているCredential Managerでのパスキー移行ベストプラクティス（2025年9月4日公開）は、パスキー作成を促す場面としてアカウント登録時・サインイン時・アカウント回復時・パスワード再設定後の4つを挙げています。共通点は、利用者が本人確認を終えた直後という点。パスワードやワンタイムコードで本人性を確認できた地点であれば、追加の認証なしにパスキー登録へ進めます。

実装上は、Androidネイティブアプリならandroidx.credentialsのCredential Manager API、Webならnavigator.credentials.create()を呼ぶ箇所がこの4点に対応します。サーバ側は同じ登録エンドポイントを4箇所から呼べる形にしておくと、導線を増やしても実装が分岐しません。登録・認証フローそのものの組み立てはWebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点で扱っています。

決済や購読の導線からパスキー要求を外した結果の作成完了率10%改善

同じ資料に、インドの経済紙Economic Timesの事例が載っています。サブスクリプション購入のような事業上の重要導線からパスキー作成の促しを外し、サインアップ・明示的なサインイン画面・アカウント管理画面の3箇所に限定したところ、初期ロールアウト期間内でパスキー作成完了率が約10%改善したという記述です。

この数字が示しているのは、促す回数ではなく置き場所で結果が変わるということ。決済フローの途中に認証方式の変更を挟めば、利用者は購入を中断します。移行を急ぐ現場ほど「全画面で促す」設計に寄りがちですが、収益導線から外す判断のほうが結果的に登録数を増やします。

excludeCredentialsの指定で重複パスキーの登録を止める実装

移行期間に最も多く起きる不具合が、同じ端末に同じアカウントのパスキーが二重に作られる事象です。原因は登録オプションの指定漏れにあります。

excludeCredentialsを含む登録オプションのJSONと重複防止の理屈

登録要求を組み立てるとき、そのアカウントが既に持つcredentialIdの一覧をexcludeCredentialsに入れます。認証器は、この一覧に自分が持つ鍵が含まれていれば登録を拒否する。結果として、同じ保管先に重複したパスキーが作られなくなります。サーバが返すオプションの形は次のとおりです。

{
  "rp": { "id": "example.com", "name": "Example Service" },
  "user": {
    "id": "M2YPl-KGnA8",
    "name": "[email protected]",
    "displayName": "Taro Yamada"
  },
  "challenge": "qNqrLL4dGGDGEvUOn4z9Ow",
  "pubKeyCredParams": [
    { "type": "public-key", "alg": -7 },
    { "type": "public-key", "alg": -257 }
  ],
  "excludeCredentials": [
    { "type": "public-key", "id": "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" }
  ],
  "authenticatorSelection": {
    "residentKey": "required",
    "userVerification": "preferred"
  }
}

あわせてuser.id（userHandle）の設計も固めておきます。ここにメールアドレスやログインIDを入れると、利用者がアドレスを変更したときに同一人物と判定できなくなる。アカウント作成時に採番した不変のランダム値を入れ、表示名はnameとdisplayNameだけで扱う形が安全です。

Signal APIでサーバとパスキープロバイダの登録状態を同期する実装

移行期間中、サーバ側のパスキー一覧と、端末のパスワードマネージャが持つ一覧は簡単にずれます。このずれを埋める仕組みがSignal APIです。

サインイン成功時に呼ぶsignalAllAcceptedCredentialsの実装例

W3CのWeb Authentication仕様には、RPから認証器側へ状態を通知する3つのSignal Methodsが定義されています（Level 3は2026年8月25日にW3C勧告となり、Signal Methodsは仕様本体の5.1.10節に置かれています）。サインイン成功時とアカウント設定変更後に、サーバが有効と認めるcredentialIdの全量を通知するのがsignalAllAcceptedCredentialsです。

// サインイン成功後：サーバが有効と認める資格情報IDの全量を通知する
if (PublicKeyCredential.signalAllAcceptedCredentials) {
  await PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "M2YPl-KGnA8",
    allAcceptedCredentialIds: [
      "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA"
    ]
  });
}

// 認証失敗時：サーバに存在しない資格情報が提示されたことを通知する
if (PublicKeyCredential.signalUnknownCredential) {
  await PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA"
  });
}

この通知を受けたパスキープロバイダは、一覧から外れた資格情報を非表示にし、オートフィル候補から除きます。利用者が管理画面でパスキーを削除したのに端末側の候補に残る、という問い合わせは、この呼び出しを入れるだけで消えます。

不明な資格情報の通知メソッドとChrome 132以降のブラウザ対応

3つ目のsignalCurrentUserDetailsは、利用者がメールアドレスや表示名を変更したときに呼び、プロバイダ側のメタデータを更新させるメソッドです。引数はrpId・userId・name・displayNameの4つ。ChromeのSignal APIドキュメントによれば、3メソッドともChrome 132以降とEdge 132以降で利用でき、Safariは26系で対応します。

対応していないブラウザではPublicKeyCredential.signalAllAcceptedCredentials自体が未定義になるため、上のコードのように存在確認で囲みます。呼べない環境ではずれが残る前提で、管理画面に「この端末に残った候補は手動で削除してください」といった案内を置いておくと、サポートの往復が減ります。

CXP／CXFでパスワードマネージャ間のパスキーを移行する仕組み

ここからは利用者側の移行です。RPが実装する範囲ではありませんが、仕様の制約を知らないとサポート回答を誤ります。

CXFのpasskey辞書が持つフィールド構成とJSON出力の読み方

FIDOアライアンスのCredential Exchange Format（CXF）は、資格情報を表すJSONスキーマを定める仕様です。2024年5月22日付のWorking Draftでは、パスキーはtype・credentialId・rpId・userName・userDisplayName・userHandle・keyを必須とする辞書として定義されています。

{
  "type": "passkey",
  "credentialId": "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA",
  "rpId": "example.com",
  "userName": "[email protected]",
  "userDisplayName": "Taro Yamada",
  "userHandle": "M2YPl-KGnA8",
  "key": "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQg"
}

データ構造はHeaderの下にAccount、その下にCollectionとItem、Itemの下にCredentialが並ぶ階層です。秘密鍵を格納するkeyの具体形式は、同ドラフトの時点でJWK・COSE Key・PKCS#8のいずれかを想定する旨のコメントが残るだけで、確定していません。移行後に鍵が使えるかどうかは、実装側の相互運用テストに依存します。

CXPのHPKE転送と3つの応答モード・Android 8以上での提供状況

転送手順を定めるのがCredential Exchange Protocol（CXP）です。2024年10月3日付のWorking Draftでは、受け取り側をImporter、渡す側をExporterと呼び、RFC 9180のHPKE（ハイブリッド公開鍵暗号）で経路を保護します。応答モードはdirect・indirect・selfの3種類で、selfは同一プロバイダ内のバックアップ用途です。

実装側の状況を見ると、GoogleはAndroid 8以上でこの移行を提供し、Googleパスワードマネージャー・1Password・Bitwarden・Dashlaneが対応済みと公表しています。AppleはWWDC25のセッション279で、iOS・iPadOS・macOS 26における資格情報マネージャ間の転送を説明しました。いずれも仕様自体はWorking Draft段階であり、企業が管理端末の運用手順として正式に組み込むには早い。規格の全体像はFIDO認証・FIDO2とは？仕組みとパスキー・導入判断を解説で確認できます。

パスワード完全廃止を見送るべき条件とパスキー移行の失敗パターン

ここが本記事の結論部分です。移行の技術的な段取りが組めても、廃止まで進めてよい組織とそうでない組織があります。

パスキーのみへ寄せた場合のアカウント回復と管理者リセットの設計

パスワードを廃止すると、端末を紛失した利用者の復帰経路は「もう1台の登録済み端末」か「サポート窓口の本人確認」の二択になります。前者を成立させるには、移行の第2段階で2台目の登録を促す導線が要る。促していない状態で廃止に踏み切ると、窓口の本人確認が唯一の経路になり、そこが攻撃対象になります。ソーシャルエンジニアリングでサポートを騙す手口は、耐フィッシング性の高いパスキーを迂回する最短路です。

業務システムでは、管理者によるリセット手順も設計に含めます。管理者が資格情報を無効化したあと、利用者側の端末に古い候補が残らないよう、前章のSignal APIを管理操作からも呼ぶ形にしておく。会員基盤の認証方式を移行する設計や、回復経路を含む実装をまとめて外部に委ねる場合は、会員管理システム開発で対応しています。認証要素そのものの整理は多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説を参照してください。

移行を止めるべき条件：共用端末・キオスク端末・回復手段が電話のみの場合

次の3条件のいずれかに当てはまる場合、パスワードの完全廃止は見送ります。第1に、複数人が同一端末を使う共用端末やキオスク端末が業務にある場合。パスキーは端末や保管先アカウントに紐づくため、共用前提の運用と噛み合いません。第2に、回復手段がSMSや電話の音声確認しか用意できない場合。パスキーの耐フィッシング性を、回復経路の弱さが打ち消します。

第3に、利用者の端末が組織の管理外で、OSバージョンを揃えられない場合。パスキーの対応環境はOSとブラウザの組み合わせで決まるため、旧環境が一定割合残るならパスワード経路を消せません。逆に、対応環境が揃った自社アプリ利用者だけが対象で、2台目登録の導線とサポート窓口の本人確認強化まで実装できるなら、廃止まで進めてよい。ここは条件がそろわない限り踏み込まない領域です。

よくある質問

パスキー移行の実装と運用で、実際に問い合わせが集中する論点を5つ挙げます。

パスキーを登録したらパスワードは削除してよいですか？

移行の初期段階では削除しません。パスキー未対応のブラウザや、生体認証を設定していない端末からのアクセスが残るためです。削除を検討できるのは、対象利用者のパスキー登録率が十分に上がり、2台目の登録導線とサポート窓口での本人確認手順を整えたあとになります。削除に踏み切る際も、まずパスワードでのサインインを無効化し、アカウント自体は残す段階的な進め方が安全です。

機種変更するとパスキーは引き継げますか？

同じパスワードマネージャやOSアカウントを新端末で使う場合、鍵は同期されて引き継がれます。別のプロバイダへ乗り換える場合は、従来は引き継げませんでした。2026年9月10日以降のAndroid 8以上の端末では、対応プロバイダ間で直接移行できます。RP側の実装としては、いずれの場合もcredentialIdは変わらないため、サーバのレコードを触る必要はありません。

パスワードマネージャを乗り換えるとパスキーも移せますか？

対応プロバイダ同士なら移せます。Googleの公表時点で対応しているのは、Googleパスワードマネージャー・1Password・Bitwarden・Dashlaneの4つで、追加のパートナーも予定されています。移行はファイルの書き出しを伴わず、OSが既存プロバイダを検出して転送を仲介する方式です。CXP自体はWorking Draftのため、対応外のマネージャとの間では従来どおり移せません。

サーバでパスキーを削除したのに端末の候補に残るのはなぜですか？

RPがパスキープロバイダへ削除を通知していないためです。WebAuthnの仕様では、サーバ側のレコード削除がプロバイダ側へ自動で伝わる仕組みはありません。サインイン成功時にsignalAllAcceptedCredentialsで有効な資格情報の全量を通知するか、認証失敗時にsignalUnknownCredentialを呼ぶことで、プロバイダ側の一覧から外れます。Chrome 132以降とEdge 132以降が対応済みです。

社内システムのパスキー移行はどこから着手すればよいですか？

利用端末の棚卸しから始めます。共用端末とキオスク端末の有無、OSバージョンの分布、端末が組織の管理下にあるかどうかの3点で、到達できる範囲が決まるためです。そのうえで、管理者リセットとアカウント回復の手順を先に設計し、パスキー登録の開放はその後に回す。この順序を逆にすると、登録が進んだあとで回復経路の不備が露見し、運用が止まります。

関連記事

• パスキー認証とは？仕組み・パスワードとの違い・企業の導入判断を解説：パスキーの仕組みと導入可否の判断軸をまとめた概念編です。
• WebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点：登録・認証フローそのものをRP実装の視点で解説しています。
• FIDO認証・FIDO2とは？仕組みとパスキー・導入判断を解説：CXP／CXFを策定しているFIDO規格の全体像を扱った記事です。
• 多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説：パスキー併用時の認証要素の整理に使えます。
• パスワード管理のベストプラクティス｜NIST最新指針と企業ポリシー設計を解説：併存期間に残すパスワード側のポリシー設計を補完します。