パスキーとパスワードの移行 - FIDO Credential Exchange (CXP/CXF) 入門
パスキーはフィッシングに強く、パスワードより安全な認証方式として実用段階に入りました。しかし普及するほど現実的になってきたのが、「使っている管理ツールを乗り換えたいとき、保存したパスキーをどうやって持ち出すのか」という問題です。パスワードなら CSV にエクスポートできましたが、パスキーは秘密鍵を含むため、平文ファイルに書き出すこと自体が危険です。
この「囲い込み（ロックイン）」を解消するために FIDO Alliance が策定を進めているのが、Credential Exchange Protocol (CXP) と Credential Exchange Format (CXF) です。そして 2026 年に入り、iOS / macOS 26 に続いて Android も対応を始め、Google Password Manager と 1Password・Bitwarden・Dashlane などの間でパスワードやパスキーを移行できるようになりました。
この記事では、CXP / CXF の役割分担と仕組みを一次ソースを軸に整理し、各プラットフォームの対応状況と現在のステータス（まだドラフトである点）まで、誇張せずにまとめます。パスキーそのものの基礎は Passkeys / WebAuthn 入門 で扱っているので、あわせて参照してください。
なぜパスキーの移行に標準が必要なのか
パスワードの移行はこれまで、各管理ツールが提供する CSV / JSON エクスポートに頼ってきました。しかしこの方式には根本的な弱点があります。
- エクスポートされたファイルは平文で、ダウンロードフォルダや一時ファイルに残る
- パスキー（公開鍵暗号の秘密鍵）を平文で書き出すと、フィッシング耐性という最大の利点が損なわれる
- ツールごとにフォーマットがバラバラで、互換性がない
パスキーは「秘密鍵がデバイス（認証器）から出ない」ことを前提に安全性を担保しています。これを別の管理ツールへ移すには、平文ファイルを経由せず、アプリ間で直接・暗号化された状態で受け渡す仕組みが必要です。CXP / CXF はまさにこの課題に応えるための標準です。
NOTE
CSV エクスポートが不要になるわけではありませんが、FIDO Alliance や各社は「平文 CSV / JSON に頼る移行を、暗号化された安全な移行へ置き換える」ことを目的として掲げています。
CXP と CXF の役割分担
混同しやすいのですが、CXP と CXF は別物で、役割が分かれています。
| 名称 | 役割 | 中身 |
|---|---|---|
| CXF（Credential Exchange Format） | データの形式 | パスキー・パスワード・TOTP（ワンタイムコード）・メモなどを表現する JSON ベースの構造 |
| CXP（Credential Exchange Protocol） | 転送のプロトコル | その CXF データを 2 つのプロバイダ間で暗号化して安全に運ぶ手順 |
おおまかには、CXF が「何を運ぶか（荷物の形）」、CXP が「どうやって安全に運ぶか（配送方法）」を定めていると考えると分かりやすいです。
CXF: 何を運ぶかを定める JSON 形式
CXF は、管理ツールが保持する各種クレデンシャルを移行可能な形で表現する、JSON ベースのデータ形式です。FIDO Alliance の解説によれば、対象はパスキーだけでなく、パスワード・TOTP シークレット・メモなど、クレデンシャルマネージャーが扱う情報を広くカバーします。
つまり CXF は「パスキー専用」ではなく、クレデンシャルマネージャーの中身まるごとを運ぶための共通フォーマットだという点が重要です。
CXP: HPKE でアプリ間を暗号化する転送手順
CXP は、CXF で表現したデータを 2 つのプロバイダ（同一デバイス上、または別デバイス間）でやり取りするための手順を定めます。一次ソースである Working Draft（2024 年 10 月 3 日版）によれば、CXP は HPKE（Hybrid Public Key Encryption / ハイブリッド公開鍵暗号）を用いて、転送中のクレデンシャルをエンドツーエンドで保護します。
仕組みの骨子は次の通りです。
- インポート側が、暗号化の設定（HPKE のパラメータ）と自分の公開鍵を含むエクスポート要求を出す
- エクスポート側が、その公開鍵とパラメータを使って対象クレデンシャルを暗号化し、自分の公開鍵とともに暗号化済みペイロードを返す
- 双方が Diffie-Hellman 鍵交換によって共有鍵を導出し、事前に安全なチャネルがなくても暗号化された受け渡しを成立させる
この設計のおかげで、オンライン・オフライン・エアギャップ（ネットワーク分離）といった状況でも、平文を経由せずにクレデンシャルを移せます。鍵そのものを生のまま外に出さず、受け渡しの瞬間だけ暗号化トンネルを張るイメージです。
現在のステータス: まだ「ドラフト」である
ここは慎重に書く必要があります。CXP / CXF は便利な機能としてすでに各社の製品に載り始めていますが、仕様自体は正式標準として完成済みではありません。
確認できた範囲では、状況は次の通りです。
- CXP は Working Draft（2024 年 10 月 3 日版）として FIDO Alliance のサイトで公開されています
- 仕様は FIDO の Credential Provider Special Interest Group（クレデンシャルプロバイダ特別作業部会）で策定が進められ、公開レビューを経て更新が続いています
- 二次情報では、CXF が 2025 年 3 月に Review Draft（レビュードラフト）相当に達し、CXP は 2026 年初頭の標準化を目標にしている、という説明が見られます（この具体的な時期・段階の表現は二次情報ベースで、要確認です）
WARNING
「ドラフト」は、実装に向けて頻繁に更新・公開される段階を指します。製品としては動いていても、仕様番号やパラメータが将来変わる可能性があります。本記事で挙げる日付・段階のうち一次ソースで直接確認できないものは、確定情報として扱わないでください。
参加している企業
CXP / CXF は、特定ベンダーの囲い込みを崩すための標準なので、主要な認証・パスワード管理ベンダーが横断して関わっています。FIDO Alliance の Credential Provider Special Interest Group の参加企業として、各ソースで以下が挙げられています。
- プラットフォーマー: Apple、Google、Microsoft、Samsung
- パスワード管理ベンダー: 1Password、Bitwarden、Dashlane、Enpass、NordPass
- その他: Okta、SK Telecom など
補足: ソースによって列挙される顔ぶれに差があります（少数を「主要メンバー」として挙げる記事もあります）。確実に複数ソースで一致しているのは Apple・Google・Microsoft・1Password・Bitwarden・Dashlane の参加です。
2026 年の対応状況: iOS が先行、Android が追随
仕様がドラフトであっても、実装は着実に進んでいます。プラットフォームごとに整理します。
Apple（iOS / macOS 26）
Apple は iOS / macOS 26 で、CXF ベースの同一デバイス上でのクレデンシャル移行を提供しました。OS レベルで ASCredentialExportManager という API を導入し、パスワード管理アプリがこの API を実装することで、パスキー・パスワード・確認コードを暗号化したままアプリ間で移行できるようになっています。従来の平文 CSV / JSON ダンプと異なり、エンドツーエンド暗号化で、Face ID / Touch ID などのローカル認証を要求する点が特徴です。
補足: Apple がクロスプラットフォームの輸出入機能を順次拡大しているという報道もありますが、提供範囲や時期の細部はソースにより表現が異なるため、最新の状況は Apple の公式情報で確認してください。
Android / Google Password Manager（2026 年 6 月）
そして 2026 年 6 月、Android も対応しました。Google の 6 月の Play services リリースノートには、次の記載があります。
You can now import and export passwords and passkeys between Google Password Manager and third-party password managers with the Credential Exchange standard. （Credential Exchange 標準により、Google Password Manager とサードパーティのパスワード管理ツールとの間で、パスワードとパスキーをインポート / エクスポートできるようになりました）
この機能は Google Play services v26.21（2026 年 6 月 1 日付）で導入され、6 月初頭からロールアウトが始まりました。これにより、Android 上で Google Password Manager と 1Password・Bitwarden・Dashlane などの間で、パスワードとパスキーを直接・暗号化したまま移行できます。
操作の流れはおおむね次の通りです。
1. 移行先の管理ツールで「インポート」を選ぶ
（または Google Password Manager 側で「エクスポート」を選ぶ）
2. 生体認証（指紋・顔）でローカル認証する
3. 選んだクレデンシャルが、平文ファイルを経由せず
アプリ間で暗号化されたまま移動するNOTE
Play services のロールアウトは段階的です。バージョン 26.21 が配信されていても、すべての端末・地域で即座にメニューが現れるとは限りません。表示されない場合は、Google Play services の更新を待つ必要があります。
開発者・利用者にとっての意味
CXP / CXF が広がると、何が変わるのでしょうか。
- 利用者: パスキーを理由に管理ツールへ縛られなくなります。「乗り換えたいがパスキーを持ち出せない」というロックインが解消に向かいます
- RP（サービス提供者）: 直接の実装作業は基本的に発生しません。CXP / CXF はクレデンシャルマネージャー間の移行プロトコルであり、WebAuthn でパスキー認証を提供するサーバ側のフロー（Passkeys / WebAuthn 入門 で解説）とは別レイヤーだからです
- パスワード管理ベンダー: 平文 CSV インポート / エクスポートに代わる、暗号化された標準移行経路を実装することになります
認証まわりの全体像としては、ログイン自体は WebAuthn / パスキー、そのセッション管理は Cookie・セッション・SameSite、外部サービス連携は OAuth 2.0 / OIDC というように層が分かれており、CXP / CXF はそこに「クレデンシャルの持ち運び」というもう一つの層を加えるものだと位置づけられます。
まとめ
CXP / CXF は、パスキー時代の「移行できない」問題に正面から取り組む標準です。要点を整理します。
- CXF は、パスキー・パスワード・TOTP・メモなどを表す JSON ベースのデータ形式
- CXP は、その CXF を HPKE でエンドツーエンド暗号化してアプリ間で運ぶ転送プロトコル
- 仕様は FIDO Alliance の作業部会で策定中のドラフト段階で、Apple・Google・Microsoft・1Password・Bitwarden・Dashlane らが参加
- 実装は iOS / macOS 26 が先行し、2026 年 6 月の Google Play services 26.21 で Android も対応した
「パスキーは便利だが囲い込みが怖い」という懸念は、こうした移行標準の普及によって徐々に薄まっていきます。一方で仕様はまだドラフトであり、日付や段階の表現には未確定な部分が残ります。導入や記事化の際は、必ず FIDO Alliance と各プラットフォームの一次情報で最新状況を確認することをおすすめします。
