銀行が犯すパスキー導入の10の失敗と対策

1. はじめに#

銀行業界は今、レガシーなパスワードやOTP（ワンタイムパスワード）から、フィッシング耐性のあるパスキーへの移行という重要な岐路に立っています。CISO（最高情報セキュリティ責任者）やプロダクトオーナーにとって、これはフィッシング被害やインフラコストの増大に対処するための、避けては通れない生存戦略です。しかし、銀行での導入には独自のハードルがあります。PSD2やSCAといった厳格な規制、レガシーなインフラ、そして極めて多様なデバイス環境です。

本ガイドは、世界各国の導入事例から得られた知見をまとめたものです。パスキー導入の成功は、ユーザーによる採用（アダプション）という「ラストワンマイル」をいかに攻略するかにかかっています。インフラ中心の導入では普及率が<1%で停滞することが多い一方、プロダクト主導のアプローチでは短期間で>50%の普及率を達成することも可能です。

戦略上の必須事項:

• 登録こそが防御境界線: パスキー作成の瞬間を保護することが、アカウント乗っ取り（ATO）に対する主要な防御策となります。
• 可視性は譲れない: クライアント側のテレメトリ（計測データ）がない「ブラインド（盲目的）なロールアウト」は、原因不明の問い合わせ急増を招きます。
• コンテキストが重要: 互換性のないハードウェアでの「致命的なユーザーロックアウト」を防ぐには、インテリジェントなフォールバック（代替手段）ロジックが不可欠です。

2. 銀行におけるパスキー導入が特殊な理由#

銀行には、「素早く動いて破壊する（Move fast and break things）」というシリコンバレー的な贅沢は許されません。不正に対する許容度はゼロであり、厳格な監視下で運用する必要があります。このような環境でのパスキー導入には、他業界にはない特有の摩擦が生じます。

2.1 「ブラックボックス」問題#

パスワードの世界では、サーバーログがすべてを教えてくれました。ログインが失敗した理由（文字の間違い、有効期限切れなど）を正確に把握できました。しかしパスキーの場合、認証はユーザーのデバイス上で行われます。顔認証の失敗、ユーザーによるキャンセルの選択、Bluetooth接続の切断などが起きても、サーバーには一般的なエラーしか届きません。

銀行の現実: 不正対策チームやリスク管理チームは、突然認証の試みに対する「目」を失うことになります。クライアント側に専用の新しいテレメトリがなければ、ロールアウト中に目隠し状態で飛行するようなもので、失敗の急増が技術的なバグなのか攻撃なのかを判断できません。

2.2 「所持」に関するコンプライアンスの頭痛の種#

規制当局（PSD2/SCAなど）は、2つの異なる要素を要求します。「知識/生体（何かを知っている/誰かである）」と「所持（何かを持っている）」です。

銀行の現実: クラウドに同期されるパスキー（iCloud KeychainやGoogle Password Managerなど）は、この境界線を曖昧にします。鍵がiPad、MacBook、iPhoneに同期されている場合、ユーザーは特定のデバイスを物理的に「所持」していると言えるでしょうか？法務・コンプライアンスチームは、従来のハードウェア的な意味での「所持」を確認できないとしてロールアウトを阻止することが多く、チームはUXを損なう複雑な「デバイスバインディング（紐付け）」の回避策構築を迫られます。

2.3 極端なデバイスとユーザーの断片化#

SaaS企業であれば古いブラウザのサポートを打ち切ることができますが、銀行はそうはいきません。顧客はデジタルネイティブな18歳から、何年も更新されていない格安Android端末を使う80歳まで多岐にわたります。

銀行の現実: Androidのエコシステムは地雷原です。Samsungのデバイスはしばしば「Samsung Pass」をデフォルトとし、スムーズなパスキー作成を阻害することがあります。法人顧客はファイアウォールの背後にいることが多く、クロスデバイスログイン（QRコード認証）に必要なWebSocket接続がブロックされる可能性があります。QA（品質保証）用のiPhoneで動作する「標準的」な実装も、数千人の実世界の顧客環境では失敗し、サポート窓口を即座にパンクさせることになります。

2.4 恒久的なアカウントロックアウトのリスク#

Spotifyユーザーがアカウントを失っても「迷惑」で済みますが、銀行の顧客がアクセスを失えば、食料品を買うことすらできなくなります。

銀行の現実: パスキーはエコシステム（Apple/Google）に依存しています。ユーザーがApple IDからロックアウトされれば、パスキーも失います。パスワードを廃止したにもかかわらず、堅牢なリカバリ経路（ID認証など）を構築していなければ、顧客をアカウントから永久に締め出すリスクがあります。このシナリオへの恐怖が、銀行の導入における意思決定を麻痺させています。

3. パスキー導入における10の大きな失敗#

以下は、銀行がパスキーを導入する際によく見られる10の失敗の概要です。

1. 「CIAM/IdPがパスキーに対応した」ことをゴールと見なす
2. パスキーの分断（誤ったrpID戦略）
3. 「ブラインドロールアウト」（クライアント側のテレメトリなし）
4. デバイスとネットワークの現実を無視する
5. パスキーをアカウント設定に隠してしまう
6. アカウントの存在を漏洩する（列挙攻撃）
7. 安全でない登録（ATOの入り口）
8. 共用デバイスとPINのリスクを無視する
9. コンプライアンス判断の先送り（1要素 vs 2要素）
10. リカバリと恒久的ロックアウトの軽視

3.1 失敗1：「CIAM/IdPがパスキーに対応した」ことをゴールと見なす#

失敗: チームはIdentity Provider（IdP）をアップグレードしてFIDO2をサポートし、機能フラグを有効にしてプロジェクト完了とみなします。パスキーをフロントエンドのプロダクト体験としてではなく、バックエンドのコモディティとして扱ってしまいます。

影響: ユーザーが機能を見つけられなかったり理解できなかったりするため、普及率は<1%で停滞します。ログインの大部分がレガシーな方法のまま残るため、SMSコストの削減や不正防止によるROI（投資対効果）はゼロとなります。

対策:

• ロールアウトを単なるITアップグレードではなく、プロダクトプログラムとしてリソース配分する。
• IdPの前に「アダプションレイヤー（普及促進層）」を構築し、ユーザー教育、登録のナッジ（誘導）、エラー処理を管理する。
• 普及のKPI（例：「6ヶ月以内にログインの50%をパスキー経由にする」）を設定し、登録誘導のA/Bテストを行う。

3.2 失敗2：パスキーの分断（誤ったrpID戦略）#

失敗: 異なる事業部門（例：リテール、ウェルス、法人）が、統一されたアンカーなしに、ばらばらのサブドメイン（例：retail.bank.com, wealth.bank.com）でパスキーを展開してしまう。

影響: パスキーはフィッシングを防ぐためにドメイン（オリジン）に紐付いています。リテール用に作成されたパスキーはウェルス用では機能せず、ユーザーは同じ銀行に対して複数の認証情報を登録することを余儀なくされます。これはUXを分断し、「フィッシング耐性」という約束の効果を薄めます。

次の図は、銀行が通常直面するRelying Party ID (rpID)の可能性を示しています。

対策:

• 単一の主要なRelying Party ID（例：bankgroup.com）を早期に定義する。
• 集中的なリダイレクト（OIDC/SAML）を使用し、すべてのアプリがこの単一のアンカードメインに対して認証を行うようにする。
• レガシーなドメインをすぐに統合できない場合は、Related Originsの利用を検討する。

3.3 失敗3：「ブラインドロールアウト」（クライアント側のテレメトリなし）#

失敗: クライアント側のWebAuthnイベントを詳細に可視化せずにローンチする。チームはサーバー側のログ（HTTP 200/400）に依存しますが、これではデバイス上で何が起きているか（ユーザーによるキャンセル、生体認証の失敗、OSエラーなど）が見えません。

影響: 原因不明の失敗急増。ユーザーから「操作が中断されました」といったエラー（日本の導入事例でもよく見られます）が報告された際、銀行側はそれがSamsungのファームウェアバグなのか、ユーザーのミスなのか、ネットワークブロックなのかを区別できず、サポートの過負荷につながります。

本番グレードのパスキー導入では、少なくとも以下のクライアント側テレメトリイベントを追跡すべきです。

認証ファネルイベント:

エラー分類シグナル:

デバイスと認証器のコンテキスト（イベントごとに取得）:

• OS + バージョン (例: iOS 18.2, Android 15)
• ブラウザ + バージョン
• ハードウェアのブランド / モデル
• クレデンシャルマネージャー (iCloud Keychain, Google Password Manager, Samsung Pass, 1Password など)
• トランスポート方法 (内部、ハイブリッド、ハイブリッド + 内部)
• 完了までの時間 / エラーまでの時間

パスキー分析や認証分析に関する完全なガイドについては、それぞれの解説記事をご覧ください。

対策:

• クライアントを計測可能にする: セレモニーの全ステップ（プロンプト -> ユーザーアクション -> ブラウザエラーコード）を追跡する。
• コホート（集団）ごとにロールアウト: テックに詳しい社内ユーザーから始め、次に特定のOSバージョン（例：iOS 18以上）へと広げ、デバイスモデルごとのエラー率を監視する。

3.4 失敗4：デバイスとネットワークの現実を無視する#

失敗: 最新のiPhoneやPixelでの「ハッピーパス（理想的なシナリオ）」向けに設計し、エンタープライズWindowsフリート、企業のプロキシ、多様なAndroid OEM（Sony, Sharp, Samsung）の断片化された現実を無視してしまう。

影響: 企業のプロキシは、「ハイブリッド」（QRコード）フローに必要なWebSocketトラフィックをブロックすることが多く、職場のユーザーをブロックしてしまいます。Androidの断片化により、競合するクレデンシャルマネージャー（例：Samsung Pass）が原因で、非Pixelデバイスでは「Conditional Create（条件付き作成）」などの機能が失敗することがあります。

対策:

• 地域の市場シェアに重み付けしたデバイステストマトリックスを構築する。
• 明示的なフォールバックの実装: 特定のOEMデバイスやネットワーク環境で失敗することがわかっている場合、動的にパスキーのプロンプトを抑制し、ユーザーの不満を防ぐ。
• プロンプトを出す前に、デバイスの機能を検出するためにPasskey Intelligenceを使用する。

3.5 失敗5：パスキーをアカウント設定に隠してしまう#

失敗: メインのログインフローでのユーザーの混乱を恐れ、登録オプションを「設定 > セキュリティ > MFA」の奥深くに埋もれさせてしまう。

影響: 「1%の罠」。データによると、ユーザーが自発的にセキュリティ設定を変更することは稀です。普及率はごくわずかに留まり、銀行はログインの99%に対してSMS OTPのコストを払い続けることになります。

対策:

• 文脈に応じたプロモーション: 信頼度が高いMFAチェック成功直後のログインフロー内で、パスキーを作成するようユーザーに促す。
• 段階的な緊急度: 12〜18ヶ月のタイムラインで、「任意」のナッジから「推奨」、「必須」へと移行させる。

3.6 失敗6：アカウントの存在を漏洩する（列挙攻撃）#

失敗: ユーザーが存在すれば即座にパスキーを求め、存在しなければパスワードを求める「識別子ファースト（Identifier-First）」のログインフローを使用する。

影響: この挙動により、攻撃者は何千ものメールアドレスに対してスクリプトを実行し、有効な銀行顧客のリストを作成（アカウント列挙）できるようになり、厳格なプライバシー規制（FFIEC/Nachaなど）に違反することになります。

対策:

• Conditional UI: ブラウザのオートフィル機能を使用して、アカウントの存在を明かさずにユーザー名フィールド内でパスキーを提案する。
• 統一されたフロー: 識別子ファーストが必要な場合は、厳密なタイミング調整と一般的なエラー処理を実装し、バックエンドの状態を隠蔽する。

3.7 失敗7：安全でない登録（ATOの入り口）#

失敗: 弱いログイン（例：パスワードのみ）の後や、信頼できないデバイスでのパスキー作成を許可してしまう。

影響: フィッシングでパスワードを入手した攻撃者が、被害者のアカウントに自分のパスキーを登録し、正当なユーザーを永久にロックアウトしてしまう可能性があります。

対策:

• 登録時のステップアップ認証: パスキー登録を許可する前に、最新の帯域外認証（SMS、プッシュ通知、自撮り）を要求する。
• デバイストラスト: デバイスのフィンガープリントや行動シグナルを使用し、疑わしいデバイスや共有性の高いデバイス（ネットカフェなど）での作成をブロックする。

3.8 失敗8：共用デバイスとPINのリスクを無視する#

失敗: 家族（配偶者、子供）で共有されるデバイスや、弱いデバイスPIN（「1234」など）を考慮せず、パスキーログインを本人確認の決定的な証拠として扱ってしまう。

影響: 親のiPadのPINを知っている子供が取引を承認できてしまいます。プライバシー保護されたWebAuthnは、顔認証が使われたのかPINが使われたのかを銀行に通知しません。

対策:

• 共有デバイスの検出: テレメトリを使用して、複数のユーザープロファイルや頻繁なアカウント切り替えがあるデバイスを特定し、そこでのパスキー利用を制限する。
• リスクベース認証: パスキーログインが有効であっても、デバイス環境がリスクを示している場合、高額取引に対してはステップアップチャレンジ（追加認証）をトリガーする。

3.9 失敗9：コンプライアンス判断の先送り（1要素 vs 2要素）#

失敗: 鍵がクラウドにコピーされるため、同期型パスキーは「所持 + 生体/知識」の要件（2FA）を満たさないと法務/コンプライアンス部門が判断することを、後になって認識する。

影響: 土壇場でのプロジェクト停止や、パスワードレス体験を損なう強制的なUXの摩擦（PayPalのような「デバイスバインディング」ステップの追加など）が発生します。

核心となる問いは、パスキーを1要素としてカウントするか、2要素としてカウントするかです。

現在の市場データ: 2025年時点で、同期型パスキーが約80%、デバイスバウンド（同期しない）パスキーが約20%です。認証器の中では、約85%がiCloud KeychainまたはGoogle Password Managerを使用しており、約10%がWindows Hello、約5%がサードパーティのパスワードマネージャーを使用しています。Windowsが同期型パスキーをサポートすれば、このシェアはさらに同期型へとシフトするでしょう。

パスキーを1要素（1FA）として扱う場合 - フォールバック要素の追加:

パスキーを単一要素として扱う場合、必要に応じて追加の要素を使用するポリシーを実装します。これは主にWebアプリに関連します（ネイティブアプリはログイン状態を長く維持でき、ローカル生体認証を使用できるため、追加要素は最初のネイティブアプリログイン時のみ必要）。

• 新しいデバイス / ログイン環境: パスキーログイン後に一度だけ第二要素を要求し、ユーザーの本人確認とデバイスの信頼性を確認します。その後、そのデバイスは（Cookieやフィンガープリントを通じて）信頼済みとしてマークできます。選択肢にはSMS OTP、自撮りの生存確認、クレジットカード番号、アプリプッシュなどがあります。例：PayPalやRevolutはこのアプローチを採用しています。
• 既知の信頼済みデバイス: 追加の摩擦なしで直接パスキーログインを許可します。ユーザーは過去にデバイスの所持を証明しているため、シームレスなUXを維持できます。

このアプローチは、日常的な利用におけるパスワードレス体験（通常のデバイスを使用するユーザーには変化がなく、素早いパスキーログインのみ）を維持しつつ、新しいシナリオでの2FA要件を満たします。これは、毎回ユーザーに負担をかけることなく厳格なセキュリティ基準を満たす、ユーザーフレンドリーな妥協案です。

対策:

• 早期の決定: 実装を開始する前にコンプライアンスチームと連携し、パスキーの要素構成を決定する。これにより、最終的にパスキーのみで運用できるか、PSD2準拠のために常に他の要素と組み合わせる必要があるかが決まります。
• NIST SP 800-63B: 同期型パスキーをAAL2として検証しているNISTのガイダンスを参照する。

3.10 失敗10：リカバリと恒久的ロックアウトの軽視#

失敗: デバイスエコシステム（例：Apple IDのロックアウト）を失ったユーザーのための、堅牢で自動化されたリカバリ戦略なしに、パスワードというフォールバック手段を削除してしまう。

影響: ユーザーが資金へのアクセスを完全に失う恒久的なロックアウトが発生します。これは高コストでストレスの多いサポート対応を引き起こし、リカバリの代替手段が弱い（例：メールリセット）場合、セキュリティのバックドアを作ることになります。

対策:

• スマートなフォールバック: 行き詰まりにならない代替手段（例：ハードウェアセキュリティキー）が存在することを確認する。
• 自動化された本人確認: eKYC（IDスキャン + 生存確認）によるセルフサービスリカバリを実装し、コールセンターの介入なしに安全に再登録できるようにする。
• デジタル資格情報: 最も安全でUXに優れたリカバリ経路として、検証可能な資格情報（例：mDL/モバイル運転免許証）の準備をする。

4. Corbadoの8ステップ・パスキーバンキングフレームワーク（PSD2準拠）#

上記の地雷原を乗り越えるには、構造化されたフレームワークが必要です。以下の8ステップのブループリントは、PSD2に準拠した銀行の導入と大規模なレジリエンス（回復力）のために設計されています。

5. Corbadoがお手伝いできること#

上記の失敗例をお読みになれば、「パスキーへの対応」とは、5%のWebAuthn実装（IdP）作業と、95%の継続的で容易ではない（アダプション）作業であることにお気づきでしょう。多くの銀行が苦戦するのは、既存のIdentity Provider（Ping, Okta, ForgeRock）がバックエンドは完璧に処理しても、「ラストワンマイル」——デバイスの断片化、UXのナッジ、クライアント側のテレメトリ——のためのツールを全く提供していないからです。

Corbadoは、あなたのIdPのためのアダプションレイヤーです。既存のスタックを置き換えるのではなく、その手前に位置して現実世界の複雑さを処理します。

• アダプションエンジン: 私たちの構築済みUIコンポーネントとロジックが、「ナッジ」戦略、A/Bテスト、登録タイミングを処理し、普及率を1%から50%へと引き上げます。
• デバイスインテリジェンス: 私たちは「何がどこで機能するか」という膨大なマトリックスを維持しています。特定のSamsungデバイスでパスキー実装が壊れている場合、システムは自動的にプロンプトを非表示にし、サポートチケットの発生を防ぎます。
• スマートフォールバック: デバイスの準備ができていない場合にユーザーを賢くフォールバックへと誘導することで恒久的なロックアウトを防ぎ、正当な顧客を決してブロックしないようにします。
• フォレンジックテレメトリ: 失われた「X線」のような視力を提供します。ログイン失敗の理由が、ユーザーのキャンセルなのか、生体認証のタイムアウトなのか、Androidのファームウェアバグなのかを正確に把握できるため、ヘルプデスクが盲目になることはありません。

6. 結論#

パスキーへの移行は、銀行のセキュリティにおける根本的なシフトであり、単なる認証情報のアップグレードを超えた、アイデンティティ保証の完全な再考を意味します。技術的な実装は第一歩に過ぎず、成功は最終的にユーザーの採用率と運用のレジリエンスによって定義されます。

これら10の落とし穴——特に登録時のセキュリティ、デバイスの可視性、リカバリロジック——を予測することで、銀行は「パイロット段階での停滞」を脱し、今後10年のデジタル金融の標準となる、安全でフリクションレスな顧客体験を提供できるようになります。