Googleは、Androidの認証基盤「Credential Manager」において、端末内の異なるパスワードマネージャー間で認証情報を安全に直接移行できる「Credential Transfer API」の提供を開始した。
従来のパスワード管理アプリの乗り換えは、暗号化されていない平文のCSVファイルを経由するか、手作業で再入力する運用に依存してきた。この手法は端末内に資格情報の平文ファイルを残す危険を伴う上、近年急速に普及しつつある「パスキー（Passkey）」を移行できないという構造的な限界を抱えていた。公開鍵暗号に基づくパスキーは秘密鍵を安全な領域で保護する仕組み上、従来の平文テキストファイルとしては書き出せないからである。結果として、一度作成したパスキーは特定のアプリやサービスに縛り付けられ、ユーザーがより優れたサービスへ自由に乗り換える選択肢を奪っていた。
今回登場した仕組みは、FIDO Allianceが策定を進めてきた業界標準規格「FIDO CXF（Credential Exchange Format v1.0）」を採用し、AndroidのOS機能が仲介することで、外部ファイルを作らずにアプリ同士が端末内で直接データを引き渡す。パスキー普及の最大のボトルネックとされてきたベンダーロックインを、プラットフォームの標準機能としてどう解きほぐすのか。その技術構造とエコシステムへの影響を整理する。
平文CSVの危険とロックインの打破：Androidが切り開くパスワード移行の新標準
パスワード管理アプリの移行作業は長年にわたり、セキュリティ担当者やプライバシーを重視するユーザーにとって頭の痛い問題であり続けた。旧アプリからデータを書き出す際、標準的に用いられてきた形式は暗号化されていないCSVファイルである。
このCSVファイルは、ユーザーが利用しているすべてのウェブサイトのURL、ログインID、そしてマスターパスワード以外の全パスワードを平文のまま記録する。端末内のダウンロードフォルダやローカルストレージに一度保存された平文ファイルは、他のアプリによる不正な読み取りやマルウェアの標的になりやすく、意図せずクラウドストレージへ自動同期されて二次被害を生む危険を常に抱えていた。利用後にファイルを即座に完全消去したとしても、ストレージのキャッシュやゴミ箱領域に痕跡が残る可能性を完全には排除できない。
さらに深刻な問題となったのが、フィッシング耐性を持つ次世代認証として導入が進むパスキーの存在だ。パスキーは公開鍵暗号方式を前提とし、秘密鍵はハードウェアの安全な領域や各パスワードマネージャーの暗号化ボールト内部で厳重に保護される。平文のテキストファイルとして書き出す手段が存在しないため、従来のCSVインポート・エクスポートではパスキーを別の管理アプリへ引き継ぐことができなかった。
この仕様は結果として、ユーザーに対して「一度使い始めたパスワード管理サービスから二度と抜け出せなくなる」という強い囲い込みをもたらした。セキュリティ向上のためにパスキーを導入したいと考えても、乗り換えができなくなる懸念が導入をためらわせる最大の障壁として機能していたのである。
Credential Transfer APIは、この二重の課題を一挙に解決するために設計された。移行処理は端末内部の保護されたメモリ空間と安全な通信経路だけで完結し、ストレージ上へ一切の平文ファイルを作成しない。さらにパスワードに加えパスキーの移行を正式にサポートすることで、利用者がセキュリティ強度を落とすことなく、自らの意思で自由にツールを選び直せる環境を整えた。
FIDO CXF準拠のP2P設計と、Binder上限を回避するFileProviderの構造
この安全な移行体験を支えているのが、AndroidのJetpackライブラリ「androidx.credentials:providerevents」を通じて実装されたCredential Transfer APIのアーキテクチャだ。
システムは移行元となる「送出側（Exporter）」と、移行先となる「受取側（Importer）」という2つの明確な役割分担によって動作する。全体の処理は、OSの中核機能が仲介するピアツーピア（P2P）方式で進行する。
移行を始める際、ユーザーは新しく利用したい受取側のパスワードマネージャーを開き、インポート機能を起動する。受取側アプリが「ProviderEventsManager.importCredentials()」を呼び出すと、Androidシステムがネイティブのセレクター画面を表示し、端末内にインストールされている対応アプリの中から移行可能な送出側候補を一覧表示する。
送出側アプリは、あらかじめ自身のアカウントメタデータと、暗号論的に生成された一意の秘密識別子「secretEntryId」をシステムへ事前登録（registerExport）しておく。ユーザーがシステム画面上で移行元を選択すると、送出側アプリの専用アクティビティ（androidx.identitycredentials.action.IMPORT_CREDENTIALS）が呼び出される。
ここで送出側アプリは、リクエスト元のパッケージ名（callingAppInfo.packageName）を検証すると同時に、受け取った識別子が自身で保管していた「secretEntryId」と一致するかを厳密に照合する。不正なサードパーティアプリが偽のインポート要求を送りつけてデータを詐取する攻撃を、この二重検証で確実に遮断する設計だ。
呼び出し元の正当性が確認されると、送出側アプリはユーザーに対して生体認証（Biometric Prompt）または端末のPINコード入力を要求する。ユーザー本人が明示的に本人確認を通過しない限り、資格情報の暗号化解除や引き渡しは一切実行されない。
技術面で注目すべき工夫の一つが、大容量データの受け渡し方法だ。Androidの標準的なプロセス間通信（IPC）であるBinderには、1回のトランザクションあたり1MBという厳格な容量制限が存在する。数千件におよぶIDやパスワード、証明書、メタデータを含むパスワードボールトは、この1MBの上限を容易に超過し、TransactionTooLargeExceptionによる処理の破綻を引き起こす。
そこでCredential Transfer APIは、Binder経由で巨大なデータペイロードを直接送受信することを避け、安全なContent URI（FileProvider）を介した一時キャッシュファイルによる受け渡しを採用した。データは端末内の保護されたキャッシュ領域に一時的に書き出され、ファイル記述子の安全なハンドシェイクを通じて受取側へと渡される。処理完了後は一時ファイルが破棄されるため、ストレージ上に永続的な平文データが残る心配もない。
さらに、プロバイダ間のデータ型適合判定にはWebAssembly（WASM）モジュールが活用されている。標準では共通の「credential_transfer_matcher.wasm」が同梱されており、双方が対応する資格情報タイプの積集合を安全に照合する。開発者は必要に応じてカスタムWASMモジュールを組み込み、独自の動的フィルタリングや権限判定をサンドボックス環境で実行させることも可能だ。
17種のデータ型を網羅：パスキーからSSH鍵まで動かすエコシステム
Credential Transfer APIが扱うデータ形式は、Google独自の私設フォーマットではなく、FIDO Allianceが策定した「FIDO CXF（Credential Exchange Format v1.0）」に完全準拠している。
FIDO AllianceのCredential Provider Special Interest Groupには、GoogleをはじめAppleやMicrosoftといったプラットフォーム企業、さらに1Password、Bitwarden、Dashlaneといった主要なパスワード管理サービスが名を連ねる。業界各社が合意した標準仕様を採用したことで、特定の企業に依存しないオープンな相互運用性が確保された。
FIDO CXF仕様に基づき、AndroidのCredential Transfer APIがサポートする資格情報のデータ型は実に17種類に及ぶ。
- basic-auth：従来のログインIDとパスワード
- passkey：FIDO2およびWebAuthnに基づく公開鍵クレデンシャル
- totp：認証アプリで用いられる時刻同期型ワンタイムパスワードのシード
- address / credit-card：自動入力用の住所情報やクレジットカード情報
- note：暗号化された安全なテキストメモ
- ssh-key：サーバー認証に用いるSSH公開鍵・秘密鍵ペア
- wifi：Wi-FiネットワークのSSIDと接続用パスフレーズ
- api-key / drivers-license / passport / identity-document：各種開発者トークンや公的身分証
現代のパスワード管理ツールは単なるウェブブラウザのパスワード保管庫を超え、ソフトウェア開発者のSSH鍵や二要素認証のシード、日常の決済情報やセキュアメモまでを一括管理する「デジタル資産の保管庫」へと進化している。パスワードとパスキーの移動に加え、これら17種類の包括的なデータ型をカバーしたことで、ユーザーは長年蓄積したデジタルボールトの内容を一切損なうことなく、丸ごと安全に新環境へ移植できる。
エコシステムの立ち上がりも迅速だ。今回の機能提供開始にあわせ、Android標準のGoogleパスワードマネージャーに加え、1Password、Bitwarden、Dashlaneの主要なサードパーティアプリが初期対応を完了した。
市場で高いシェアを持つ主要アプリが足並みを揃えてAPIを実装したことで、ユーザーはAndroid端末上でこれらのアプリを切り替える際、即座に直接移行の恩恵を受けられる。標準規格の採用が形骸化せず、初日から実用的な移行エコシステムとして機能し始めた意味は大きい。
Android 8.0以降に広く開放：残る課題とクロスプラットフォームへの展望
機能の普及において特筆すべき点は、その対象範囲の広さにある。Credential Transfer APIはAndroidのメジャーOSアップデートを必須とせず、Google Play開発者サービス（Google Play Services）を通じて提供される。
対応環境はAndroid 8.0（APIレベル26）以降のすべてのGoogle認定デバイスだ。Google Play開発者サービスの広範なサポート体制により、実質的に現在市場で稼働しているほぼすべてのAndroid端末でこの新機能が利用可能になる。新しいOSバージョンへのアップデートを待たずに数億人規模のユーザーへ即座にセキュリティ機能が届けられる配信体制は、Androidエコシステムの大きな強みといえる。
もっとも、実務的な観点からはいくつかの注意点や今後の課題も残されている。
第一に、直接移行を実行するためには、移行元と移行先の両方のパスワードマネージャーアプリが同一の端末内にインストールされている必要がある。移行が完了するまでの間は両アプリを端末内に同居させ、それぞれ最新のAPIに対応したバージョンへ更新しておかなければならない。未対応のアプリや、デスクトップ専用ツールとの間では依然として従来の平文CSVや手動入力に頼らざるを得ない。
第二に、移行完了後の古いボールトの管理方針だ。Credential Transfer APIは安全にデータを複製・引き渡す処理を行うが、移行元アプリに保管されている元データの消去やアカウント解約までは自動で行わない。移行が正常に完了したことを確認した後、旧アプリ内のデータをどう安全に整理・破棄するかは、依然としてユーザー自身の確認作業に委ねられている。
最大の焦点は、モバイルOSの枠を超えたクロスプラットフォーム連携の進展だ。
FIDO Allianceが策定するCXP（Credential Exchange Protocol）およびCXF仕様は、本来プラットフォームの境界を超えた認証情報の移動を想定している。現時点でのCredential Transfer APIは同一のAndroid端末内におけるアプリ間移行を対象としているが、ユーザーが真に求めているのは「AndroidからiPhoneへ」、あるいは「MacやWindowsのブラウザからスマートフォンへ」といった、異なるOSやデバイス間をまたぐシームレスな移行体験である。
GoogleがAndroidにおいて先行してFIDO標準の実装を完了させ、1PasswordやBitwardenといった業界の旗手がこれに呼応したことは、長年続いてきたパスワード移行のセキュリティ不全を是正する決定的な一歩だ。今後はAppleを含む他の主要プラットフォームがどのような形でFIDO CXF/CXP標準の足並みを揃えていくのか。認証情報のポータビリティをめぐる主導権争いと標準化の進展が、次に見るべき重要な分岐点となる。
