---
url: 'https://www.corbado.com/ja/blog/パスキー-日本-概要'
title: '日本のパスキー事情：概要 [2026年]'
description: '2026年の日本のパスキー事情：規制による義務化、FIDO導入の統計、および実装における重要な教訓について解説します。'
lang: 'ja'
author: 'Vincent Delitz'
date: '2026-01-03T18:48:08.841Z'
lastModified: '2026-10-03T06:02:15.269Z'
keywords: 'パスキー 日本, FIDO認証 日本, 日本 銀行 セキュリティ規制, パスキー 導入 2026, 楽天証券 パスキー, 野村證券 パスキー, Android パスキー 日本, フィッシング耐性 多要素認証 日本'
category: 'Passkeys Strategy'
---

# 日本のパスキー事情：概要 [2026年]

## Key Facts

- 2025年末時点で、日本では**50以上のパスキープロバイダー**が稼働または計画中
- **FIDOジャパン・ワーキンググループ**に**64の組織**が参加
- **フィッシング危機**により、**規制のタイムライン**が数年から数ヶ月に短縮
- すでに稼働している主要な金融機関には、**楽天証券**、**野村證券**、**SBI証券**、**マネックス証券**が含まれる
- 導入は金融にとどまらず通信業界にも**拡大**：**ソフトバンク**は**2026年5月25日**に**My
  SoftBank**へパスキー認証を導入
- **APAC特有の課題**として、**Android
  OEMの断片化**、エンタープライズにおける**Windows/Edgeの高いシェア**、および**企業ネットワークの制限**が挙げられる
- 複数の機関で、**重要な金融取引**における**パスキー認証**が**義務化**されつつある

## 1. はじめに

2025年、日本では進化するセキュリティ課題への対応として、パスキーの導入が加速しました。金融セクター全体で不正アクセス事件が増加したことを受け、規制当局は\*\*「ID/パスワードのみの認証や、メール/SMSのワンタイムパスワードでは不十分である」**と強調し、リスクの高い金融取引には**パスキーなどのより強力な認証方法を優先すべきである\*\*としました。

その結果、年末までに**50以上のパスキープロバイダー**が稼働または計画され、[FIDO](https://www.corbado.com/ja/blog/visa-passkey)ジャパン・ワーキンググループには**64の組織**が参加し、業界に数年ではなく数ヶ月での対応を求める規制スケジュールが示されました。

しかし、日本の急速な展開は、米国や欧州での展開ではめったに直面しない形で[FIDO](https://www.corbado.com/ja/blog/visa-passkey)エコシステムにストレステストを課すことにもなりました。エンタープライズにおけるWindows/Edgeの高いシェア、多様な[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)
OEMの状況、厳格な企業ネットワークポリシーの組み合わせにより、特に**AndroidパスキーのQRコード**、**iPhoneのクロスデバイスフロー**、および**複数デバイスの登録**に関するエッジケースが露呈しました。これは、グローバル市場向けに製品を構築するチームが理解しておくべき内容です。

本記事の内容：

1. **稼働中のサービス**：楽天証券、野村證券、SBI証券、マネックス証券など
2. **きっかけ**：規制と不正アクセスのタイムライン
3. **APACが異なる理由**：[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)とiPhoneの断片化
4. **何が問題となるか**：現場で繰り返し発生する実装のハードル
5. **どう対策すべきか**：戦略的推奨事項

## 2. 展開トラッカー：稼働中のサービスは？

日本の金融機関は新たな規制の期待に応えるべく迅速に動いており、その波は現在、通信（以下のソフトバンクを参照）などの隣接する消費者セクターにも目に見えて広がっています。以下は2026年半ば時点の現在の状況のスナップショットです。

### 2.1 野村證券のパスキー

**ステータス：** 稼働中（2025年11月29日よりパスキー認証を義務化）

野村證券はすべてのユーザーに対してパスキー認証を義務化しました。主な特徴：

- ネイティブのNOMURAアプリ経由での登録
- より安全な取引のために、パスキーをフィッシング耐性のあるパスワードレスとして位置づけ
- 確認されている[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)の問題：特に特定のAndroidデバイス/OSの組み合わせにおいて、「M0902」および「操作が中断されました」というエラーがユーザーから報告されています（[トラブルシューティングガイド](https://reiwabook.blog/nomura-pass-key-error/)、[サポートリソース](https://www.sakura-agent.net/nomura-passkey-error/)）

[野村證券 サポート](https://www.nomura.co.jp/support/procedure/online/passkey/)

### 2.2 楽天証券のパスキー

**ステータス：** 稼働中（2025年10月26日導入）

楽天証券は、強力なクロスデバイスサポートを備えた[FIDO2](https://www.corbado.com/glossary/fido2)パスキー認証を展開しました：

- すべての取引チャネルにわたる[FIDO2](https://www.corbado.com/glossary/fido2)パスキー認証
- クロスデバイスのQRフローを介して、スマートフォンのパスキーをPCログインに使用可能
- パスキーへの移行を強く推奨
- **パスキー登録後にパスワードを無効化**：他の証券会社とは異なり、ユーザーがパスキーを登録すると、そのユーザーのパスワードログインは無効になります（より厳格な「段階的移行」アプローチ）。
- スクレイピングに代わる家計簿アプリ向けのAPIを提供。

[楽天証券 ニュース](https://www.rakuten-sec.co.jp/web/info/info20250718-02.html)

### 2.3 SBI証券のパスキー

**ステータス：**
稼働中/計画中（2021年から[FIDO](https://www.corbado.com/ja/blog/visa-passkey)導入；2025年秋までに[FIDO2](https://www.corbado.com/glossary/fido2)パスキーへ）

SBI証券はFIDOの早期導入企業であり、現在は完全なパスキーサポートへの移行を進めています：

- パスワード + SMS OTPからの置き換え
- 最初にウェブへの展開、その後ネイティブアプリへの展開（10以上のアプリを計画）
- **ユーザーの選択**：パスキーを推奨しつつ、パスワード認証も維持。
- 以前の不正アクセスによる補償請求への対応として部分的に導入
- **課題**：サポートの混雑（最大30分の待ち時間）に直面。

[Impress Watch](https://www.watch.impress.co.jp/docs/news/2035818.html)

### 2.4 マネックス証券のパスキー

**ステータス：** 稼働中（2025年10月31日導入）

マネックス証券は、幅広いプラットフォームのサポートと明確なセキュリティメッセージとともにサービスを開始しました：

- 幅広いOSサポート：[Windows 11](https://www.corbado.com/blog/passkeys-windows-11)以降、[macOS](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)
  13以降、Android 11以降、[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) 16以降
- ウェブとアプリ全体で統一されたエクスペリエンス
- 「フィッシング耐性」を明確にアピール

[マネックス証券 お知らせ](https://info.monex.co.jp/news/2025/20250731_03.html)

### 2.5 PayPay証券のパスキー

**ステータス：** 進行中（2025年秋〜冬）

PayPay証券は、「強く推奨される」オプション機能としてパスキーを展開しています：

- 「強く推奨」されるオプション機能
- 二次的なシグナルとして、ログイン/出金時のメール通知を追加
- 複数の取引アプリとPCサイトをカバー

[Impress Watch](https://www.watch.impress.co.jp/docs/news/2043236.html)

### 2.6 リクルートIDのパスキー

**ステータス：** 稼働中（2025年）

リクルートIDは、複数デバイスをサポートするパスキーを実装しました：

- 複数デバイスの登録をサポート
- 共有/公共のデバイスにクレデンシャルを登録しないよう強く警告

[リクルート お知らせ](https://point.recruit.co.jp/recruitid/doc/announcement/passkey.html)

### 2.7 アコムのパスキー（消費者金融）

**ステータス：** 停止中（2025年半ばに新規の生体認証登録を一時停止）

アコムは、登録時のセキュリティを見直し、強化するために、新規の生体認証登録を一時停止しました。これは[教訓的な事例](https://infrontsecurity.net/blogs/column/passkey2)です：フィッシング耐性のあるオーセンティケーターであっても、不正アクセスを防ぐためには強力な初期登録の検証が必要です。

[アコム FAQ](https://faq.acom.co.jp/)

### 2.8 みずほ証券のパスキー

**ステータス：** 計画中（2026年2月9日よりパスキーを義務化）

みずほ証券は、すべてのアカウントの重要な操作に対してパスキーを必須とします：

- 対象：ネット倶楽部および株アプリでの取引、入出金、アカウント情報の変更
- サポート対象：[Windows 11](https://www.corbado.com/blog/passkeys-windows-11)
  (Edge/[Firefox](https://www.corbado.com/ja/blog/digital-credentials-api)/[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api))、[macOS](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)
  14以降、[iOS 17](https://www.corbado.com/blog/apple-passkeys-integration)以降、Android 10以降
- [Windows Hello](https://www.corbado.com/glossary/windows-hello)、iCloudキーチェーン、またはGoogleパスワードマネージャーを使用

[みずほ証券 FAQ](https://faq.mizuho-sc.com/faq/show/13648)

### 2.9 ウェルスナビのパスキー

**ステータス：** 稼働中（登録者数20万人以上、アクティブユーザーの40〜50%）

ウェルスナビは、パスワードのない未来に向けて最も積極的な姿勢を取っています。

- **義務化への道**：来年中のパスワード認証の廃止を目指す。
- スクレイピングに代わる家計簿アプリ向けのAPI統合を提供。
- [Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)の「パスキーの自動アップグレード（Automatic
  Passkey Upgrade）」のような新技術に期待。
- [ITmedia 記事](https://www.itmedia.co.jp/business/articles/2601/06/news006.html)

### 2.10 SMBC日興証券のパスキー

**ステータス：** 稼働中（2026年1月30日開始）

SMBC日興証券は、個人顧客向けのオンライントレードを含むウェブサービスにパスキー認証を導入しました。

- **フィッシングやアカウント乗っ取り**に対するより強力な保護として位置づけられた\*\*パスキー（FIDO2）\*\*を使用
- **パスワード入力をなくし**、パスワードリセットの手間を減らすことで利便性を向上させる設計
- **クラウドベース**の認証サービスとして実装され、比較的迅速な展開（約**5ヶ月**と報告）を可能にした
- **生体認証データはユーザーのデバイス内に留まり**、サーバー側への生体情報の保存ではなく公開鍵暗号技術に依存していることを明示
- 今後、SMBC日興証券の他のオンラインサービスにもこのアプローチを**拡大**する計画

[プレスリリース](https://global.fujitsu/en-global/pr/news/2026/02/02-01)

### 2.11 ソフトバンクのパスキー（通信、金融の枠を超えて）

**ステータス：** 稼働中（2026年5月25日導入）

日本の3大モバイルキャリアの1つであるソフトバンクは、主要な顧客ポータルである**My
SoftBank**にパスキー認証を追加しました。これは、他の日本のキャリア（特にNTTドコモは、My
docomoなどのサービスをカバーするdアカウントに対して[WebAuthn / パスキーサポートを展開](https://www.docomo.ne.jp/info/news_release/2022/10/17_00.html)しました）が通信のログイン画面をパスワードのみの認証から移行させている動きに加わるものです。ここでのシグナルは、先陣を切ることよりも規模に関するものです。日本のパスキーの波はもはや証券や[銀行](https://www.corbado.com/ja/blog/passkey-deployment-mistakes-banks)に限定されず、携帯電話の契約、請求、および個人データを管理するために使用される大容量の消費者向け画面にまで達しています。

- My SoftBankの**スマートフォン向けウェブブラウザ**版でパスキーログインが利用可能
- 現在、セットアップは**モバイルのみ**で、ユーザーはMy
  SoftBankのアカウント領域内で「パスキーの登録・設定」へと案内されます
- パスワード入力が不要で、**パスワードよりも簡単で安全**であると位置づけられています
- 通信キャリアのアカウントは、SIMスワップ、アカウント乗っ取り、およびフィッシング攻撃の頻繁な標的となるため、この動きは日本の金融庁（FSA）によるフィッシング耐性のある[MFA](https://www.corbado.com/ja/blog/medibank-data-breach)推進により直接的に関連しています
- 他の日本の通信キャリアや大規模な消費者プラットフォームに対し、パスキーが単なる金融セクターの管理手段ではなく、**主流の消費者向け認証の期待値**になりつつあることを示しています

[ソフトバンク お知らせ（日本語）](https://www.softbank.jp/mobile/info/personal/news/service/20260525a/)

## 3. きっかけ：フィッシング危機から規制による義務化へ

日本のパスキー導入の急増は、UXのトレンドではありませんでした。それは、規制当局が直接介入するまでにエスカレートした、フィッシング主導のアカウント乗っ取り（ATO）に対する防衛的な対応でした。

### 3.1 フィッシングの圧力と、規制当局によるパスキーの明示（2024年後半 → 2025年前半）

2025年1月の[対話文書](https://www.fsa.go.jp/en/press_releases/issues/202501/02.pdf)において、日本の[金融庁](https://www.corbado.com/passkeys-for-banking)（FSA）はフィッシング被害を主要な不正アクセス経路として説明し、対策として（DMARCや迅速なテイクダウンと並んで）**「パスキーの利用促進」**を挙げています。また、強力なフィッシング対策を要請するために**2024年12月24日**に発行された警察庁との共同注意喚起にも言及しています。

### 3.2 2025年：規制の焦点：オンライントレードにおける不正アクセス

2025年半ばまでに、[金融庁は](https://www.fsa.go.jp/en/press_releases/issues/202506/02.pdf)「証券口座のインターネット取引における不正アクセスおよび不正取引」を強調し、現代の脅威に対して**ID/パスワードのみ**の認証では不十分な場合が多いと明言しました。

### 3.3 日本証券業協会（JSDA）のガイドライン改定案：重要な操作に対するフィッシング耐性のあるMFAのデフォルト有効化

**2025年7月15日**、日本証券業協会（JSDA）は、インターネット取引における不正アクセス防止のためのガイドラインの改定案を公表しました。この改定案では、**ログイン**、**出金**、および**銀行口座の変更**フローに対して、**フィッシング耐性のあるMFA**を実装して義務付ける（デフォルトで有効にする）ことを求めており、その例として**パスキー**を明示しています。また、検知/通知およびロックアウトの制御基準も引き上げています。（[JSDAガイドライン改定案PDF](https://www.jsda.or.jp/about/public/bosyu/files/20250715_guideline_public.pdf)、[報道](https://www.watch.impress.co.jp/docs/news/2031496.html)）義務化の期限は**2026年夏**と予想されています。

2025年12月までに、FIDOアライアンスのFIDOジャパン・ワーキンググループは**64のメンバー組織**に拡大し、日本では**50以上のパスキープロバイダー**が稼働または計画中となりました。これは、証券フィッシング危機とそれに続く規制の推進による[直接的な結果](https://japan.cnet.com/article/35241293/)です。

### 3.4 アコムの教訓：「パスワードレス」は登録と復旧の安全性に依存する

アコムによる**新規の生体認証登録**の一時停止（2025年半ば）は、有益な[教訓的な事例](https://infrontsecurity.net/blogs/column/passkey2)です：フィッシング耐性のあるオーセンティケーターであっても、不正アクセスを防ぐためには強力な初期登録の検証が必要です。（[アコム FAQ](https://faq.acom.co.jp/)）

以下のタイムラインは、規制の圧力がどれほど急速にエスカレートしたかを示しています：

## 4. APACで適応した戦略が必要な理由：デバイスとブラウザの現実

日本（およびより広範なAPAC）にパスキーを展開する場合、米国や欧州でのテストで通常カバーされる環境よりも、より\_多様な\_デバイスやネットワーク環境で運用することになります。

- 日本のトラフィックは「モバイルのみ」ではありません。[デスクトップの割合は依然として大きい](https://gs.statcounter.com/platform-market-share/desktop-mobile/japan)です。
- エンタープライズにおけるWindowsフリートは重要であり、多くの市場と比較して[Edgeのシェアが実質的に高く](https://gs.statcounter.com/browser-market-share/desktop/japan)なっています。
- さらなる「デバイスの現実」のコンテキストとして、StatCounterは[モバイルベンダー](https://gs.statcounter.com/vendor-market-share/mobile/japan)および[モバイルの画面解像度](https://gs.statcounter.com/screen-resolution-stats/mobile/japan)の分布も提供しています（ハードウェアの多様性を測る有用な代用指標となります）。
- **Androidエコシステム**はより多様化しており（OEM + キャリアのカスタマイズ）、パスキーの動作は、OS、ブラウザ、およびプラットフォームのクレデンシャルプロバイダー層（Google
  Play開発者サービスやクレデンシャルマネージャーなど）の間の相互作用に依存する可能性があります。その実用的な結果として、差異が広がり、エッジケースが増加し、「デバイスAでは機能するがデバイスBでは失敗する」といったデバッグが増加します。
- **OEM特有の導入の障害：**
  [Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys)（パスキーの自動アップグレード）などの高度な登録機能は、Google
  Pixelデバイスと比較して、「OEMのAndroid」ハードウェア（非Pixelデバイス）では成功率が著しく低くなることがよくあります。例えば、多くの[Samsung](https://www.corbado.com/blog/samsung-passkeys)デバイスでは[Samsung](https://www.corbado.com/blog/samsung-passkeys)
  Passがデフォルトの主要なクレデンシャルマネージャーとして設定されており、これがGoogleパスワードマネージャーとの統合に依存するパスキーのバックグラウンド作成をブロックする可能性があります。
- **クレデンシャルマネージャーのシステムのバグ：** Android
  14における重大なハードルは、[文書化されているシステムのバグ](https://issuetracker.google.com/issues/349310440)です。これにより、クレデンシャルマネージャーAPIがパスキーの選択UIを正しく表示できなかったり、「クレデンシャルが見つかりません」というエラーを返したりします。これらのクレデンシャルマネージャーのパスキーエラーは、ウェブ側で
  `UnknownError` または一般的な `NotAllowedError`
  として表面化することが多く、デバイスレベルのコンテキストなしにトリアージすることは困難です。この問題はOEMハードウェアを使用するユーザーに不釣り合いに影響を与えており、リスクの高い金融アプリの展開中に予期せぬ摩擦を引き起こしています。
- **OEMのAndroidの課題：**
  [最近の金融アプリの展開に関する独立した分析](https://reiwabook.blog/nomura-pass-key-error/)により、特定のAndroid
  14デバイス（人気のある[Samsung](https://www.corbado.com/blog/samsung-passkeys) Galaxy
  A、[Sony](https://www.corbado.com/blog/playstation-passkeys-ps4-ps5) Xperia、Sharp
  AQUOSモデルなど）における認証の課題が特定されています。これらの問題は通常、GoogleのPixel以外のハードウェアで発生します。Google独自の実装は最新のFIDO標準とより一貫している傾向があるためです。詳細なトラブルシューティングについては、[現地のサポートリソース](https://www.sakura-agent.net/nomura-passkey-error/)も参照してください。
- これは仮説ではありません。公式のOEMセキュリティアップデートのデータセットを分析した[2024年のNDSSの論文](https://www.ndss-symposium.org/wp-content/uploads/2024-175-paper.pdf)は、大規模なAndroid
  OEMが一度にどれほど多くの地域/国/キャリアのバリエーションをサポートしているかを示しています（例：Samsungは**97**カ国、**109**のキャリアにわたる**402**のデバイスの**約1,400の固有モデル**；Xiaomiは**10**の地域にわたる**223**のデバイス）。同論文はまた、この作業負荷が一部のセキュリティアップデートの配信に**遅延**（または失敗すら）をもたらす可能性があり、パッチがエンドユーザーに遅れて、または不均一に届く可能性があると指摘しています。

上記のようなプラットフォームレベルの影響は、測定された展開結果に直接表れています。[CorbadoのPasskey Benchmark 2026におけるパスキー登録率の分析](https://www.corbado.com/passkey-benchmark-2026/passkey-enrollment-rate)では、2026年第1四半期の初回ウェブ登録率は、[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)で49〜83%、[macOS](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)で41〜65%、Androidで41〜67%、Windowsで25〜39%と報告されています。日本の展開は、そのマトリックスの中でもより困難な2つのセル（Windowsが主流のデスクトップトラフィックとOEMのAndroidが主流のモバイルトラフィック）に偏っているため、予想されるウェブでの結果は、グローバルベンチマークの平均よりもAndroidとWindowsの帯域の下限に近くなります。

[Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys)の準備状況は、これらの帯域がその位置にある理由を説明しています。[CorbadoのPasskey Benchmark 2026におけるConditional Create率の分析](https://www.corbado.com/passkey-benchmark-2026/conditional-create)では、2026年第1四半期のプラットフォームの準備状況を、[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)が
_Very strong_（登録への追加貢献度+42〜62%）、macOSが _Strong_（+28〜43%）、Androidが
_Fragmented_（+7〜11%）、およびWindowsのウェブが
_Constrained_（+12〜18%）に分類しています。このベンチマークは消費者向けウェブのテレメトリを対象としており、ネイティブおよび[WebView](https://www.corbado.com/blog/native-app-passkeys)を多用する金融アプリの画面は範囲外ですが、多くの場合、同じブラウザ/OSの機能の限界がそこにも現れます。

## 5. 実装に関する考慮事項：障害のモード

日本の組織が仕様から本番稼働へと移行するにつれて、いくつかの繰り返し発生する障害モードが明らかになっています。これらの現実世界のシナリオは、標準的なテストとAPACでの展開の現実とのギャップを示しています。

### ケース1：「ブラインド・ロールアウト」のシナリオ

サービスプロバイダーは規制のガイドラインを満たすためにパスキーの展開を加速させ、デバイスレベルのテレメトリがないまま全ユーザーに同時にパスキーを導入します。

- **障害：**
  チームは自身のテストデバイスでは「成功」を確認しますが、断片化されたOEMハードウェアでの3倍高い失敗率には気づきません。ユーザーは混乱（サポートされていないデバイス、プラットフォームアカウントの欠落など）に直面して単に離脱しますが、銀行側は摩擦が\_なぜ\_、または\_どこで\_発生しているのかを説明するデータを持っていません。

### ケース2：マルチアクセスポイントの接続の壁

ユーザーが企業ネットワークや日本のホームオフィス内からクロスデバイスのパスキー認証（PC
↔ スマートフォン）を試みます。

- **障害：**
  「ハッピーパス（正常系）」は、Bluetooth/ハイブリッドフローの接続が完璧であることを前提としています。しかし実際には、FIDOハイブリッドフローに必要なトラフィックは、企業プロキシによって頻繁にブロックされます。堅牢なマルチアクセスポイントの計画がなければ、これはシームレスなログインを永久的な接続の壁に変えてしまいます。

### ケース3：OEMの断片化とシステムのバグ

以前は機能していたフローがOSのアップデート後に失敗し始めるか、特定のメーカーのデバイス（Samsung、[Sony](https://www.corbado.com/blog/playstation-passkeys-ps4-ps5)、Sharp）でのみ失敗します。

- **障害：** 文書化されているAndroid 14のバグやOEM固有のデフォルト設定（Samsung
  Passなど）が、標準化されたフローをブロックします。パスキープロバイダー層はバージョン間で一貫性のない動作を示し、デバイス固有のモニタリングや適切なWebAuthnエラー分類なしにはトリアージ不可能な、QRコードのハンドオフ失敗や
  `NotAllowedError` / 「クレデンシャルが見つかりません」エラーにつながります。

### ケース4：「ターミナル・ロックアウト」のリスク

サービスがパスワードのフォールバックを早急に無効にするか、最初の登録時の検証の保護に失敗します。

- **障害：**
  初期の登録が脆弱な場合（アコムの事例のように）、盗まれたパスワードを持つ攻撃者が自身のパスキーを登録してしまいます。逆に、2025年の義務化を満たすために銀行が「パスワードレス」に移行すると、フォールバックできる従来のセーフティネットが存在しないため、登録時の摩擦やデバイスの障害はすべて絶対的なユーザーロックアウトとなります。

## 6. 戦略的推奨事項

上記で特定されたリスクを軽減するために、プロダクトチームおよびセキュリティチームは予防的なアーキテクチャを採用する必要があります。ここで最も重要な推奨事項を概説します：

1. **認証のオブザーバビリティ（可観測性）と段階的な展開に投資する。**
   サポートチケットが届く前に「3倍の失敗」のギャップを捉えるには、デバイス、OS、およびブラウザごとのパスキーのプロンプトから完了までの完了率を追跡する必要があります。
    - **ウェブの場合**：OSのバージョンとブラウザの種類ごとに段階的に展開します。
    - **ネイティブの場合**：特定のデバイスモデル（例：最初はPixel、次にOEMメーカー）ごとに段階的に展開し、回帰を早期に捉えます。
    - **モニタリング**：保存場所（システム対サードパーティ）を継続的に監視し、ロックアウトのリスクを把握します。

2. **登録をセキュリティの対象として扱う。**
   フィッシング耐性のある認証は、最初のバインディングの強度に依存します。攻撃者がパスワードレスへの移行を「乗っ取る」のを防ぐため、パスキーの登録前にステップアップ検証（eKYC、既存の強力な要素）を要求してください。

3. **完全なパスワードレスへの準備をする。**
   最初のログインのためのパスワードの完全な段階的廃止に向けて、規制の圧力が加速することを予期してください。これにより、セクション5で言及した技術的なハードルを解決することがコンプライアンス上の義務となります：パスワードのフォールバックが削除されると、デバイスレベルの障害はすべてターミナル・ロックアウトになります。

4. **APACに重きを置いたデバイスマトリックスを構築する。**
   日本ではSamsung、[Sony](https://www.corbado.com/blog/playstation-passkeys-ps4-ps5)、Sharpのモデルが主流です。テストマトリックスが限定されている場合、バグを出荷することになります。日本で多く使用されるOEMを含め、推奨事項1のオブザーバビリティのデータを使用して、サポート対象のデバイスリストをリアルタイムで改良してください。

5. **マルチデバイスおよびマルチアクセスポイントの現実に対応したアーキテクチャを設計する。**
   Bluetooth
   [CDA](https://www.corbado.com/ja/glossary/cda)や企業プロキシが失敗することを前提とします。ユーザーが環境やアクセスポイントに関係なく認証できるように、明確なネットワーク要件と、複数デバイスの登録などの堅牢なフォールバックを提供してください。

6. **高保証の補完手段としてハードウェアセキュリティキーを評価する。**
   制限の厳しい企業環境のユーザーや最大の保証を必要とするユーザーにとって、（[YubiKey](https://www.corbado.com/glossary/yubikey)などの）ハードウェアセキュリティキーは、同期されたパスキーに対する強力な代替手段となります。これらのキーは、プラットフォーム固有のクラウド同期やBluetooth接続に依存することなく、モバイルおよび従来のデスクトップフリートを含むほぼすべてのデバイスで一貫して機能する物理的な信頼の基点を提供します。堅牢なアーキテクチャは、これらのハードウェアにバインドされたオーセンティケーターがプラットフォームのパスキーと共存できるようにし、特定のアクセスコンテキストに合った「鍵」をユーザーが柔軟に選択できるようにするべきです。

7. **リカバリーを自動化してサポートのボトルネックを防ぐ。**
   パスワードレスモデルへの移行が持続可能であるのは、脆弱な認証方法を再導入しない合理化されたリカバリープロセスがある場合のみです。日本の金融業界のようなセキュリティの高いセクターの場合、これはSMS/メールによるリセットから、自撮りによる本人確認や信頼されたハードウェアを使用したクロスデバイスのフォールバックなどの「スマート[MFA](https://www.corbado.com/ja/blog/medibank-data-breach)」リカバリーに移行することを意味します。自動化されたリカバリー計画がなければ、パスワードリセットのチケットの初期の減少は、複雑なパスキー紛失サポートの呼び出しの急増によってすぐに相殺されてしまいます。

**結論：**
日本での経験は、「仕様への準拠」と「実際のユーザーで機能する」ことの間のギャップが、多くのチームが予想するよりもAPACにおいて広いことを示しています。成功するチームは、デバイスの断片化と登録時のセキュリティを最優先のエンジニアリング課題として扱い、専用のオーケストレーション層を使用してそのギャップを埋めるチームです。

## 7. Corbadoがどのようにお手伝いできるか

これらの領域をカバーする2つの製品があります。[Corbado Observe](https://www.corbado.com/observe)は認証のオブザーバビリティ（可観測性）層であり、まだ置き換えられていないSMS
OTPステップを含む、現在実行しているログインを読み取ります。[Corbado Connect](https://www.corbado.com/connect)は、既存のアイデンティティプロバイダーとWebAuthnサーバーの前に配置され、各ユーザーに何を提供するかを決定します。どちらも、現在のスタックをそのまま維持します。

### 7.1 ブラインドフライトの防止：完全なフォレンジックの可視性

ほとんどの銀行は高度な不正防止テレメトリを持っていますが、パスキーログインの「フロントエンドに焦点を当てた」ジャーニーに対する可視性はゼロです。

- **問題点**：ログには「ログインの失敗」が示されているかもしれませんが、それが文書化されているAndroid
  14のシステムのバグなのか、Samsung
  Passの競合なのか、UIが分かりにくくてユーザーがキャンセルしたためなのかは分かりません。
- **Corbadoのソリューション**：Observeは、その単一の「ログインの失敗」を3つの方法で分割します。「デバイスヘルス（Device
  Health）」は、デバイスモデル、OS、およびOSバージョンごとに結果をランク付けし、回帰したバージョンの異常テーブルを保持し、ウェブトラフィックとアプリ内トラフィックを分離します。これにより、特定のAndroidビルド上のSharpの端末が、全体平均ではなく独自の行に配置されます。「テクノロジー（Technology）」は、ウェブログインのブラウザとOSバージョンの内訳を追加します。「パスキーエラー（Passkey
  Errors）」は、障害自体を繰り返し発生するパターンに分類します。これにより、何千回も発生するクレデンシャルマネージャーの競合は、OEMに報告できる1つの数え可能なクラスターになり、純粋なユーザーのキャンセルは分散したままになります。単一の苦情が届いた場合、「ユーザー検索（User
  Search）」は、ユーザーID、お客様独自の外部ID、または[YubiKey](https://www.corbado.com/glossary/yubikey)のシリアル番号から、その人のフローを再生します。

[Video: Device health](https://www.corbado.com/videos/features/device-health.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))

### 7.2 統一された導入ポリシー：同期型とハードウェアバインド型

義務化された展開には、ユーザーのハードウェアと環境にリアルタイムで適応する戦略が必要です。

- **問題点**：単一の認証パス（同期されたパスキーなど）を強制すると、クラウド同期が無効になっている企業環境や、クレデンシャルマネージャーが壊れているOEMデバイスで失敗する可能性があります。
- **Corbadoのソリューション**：Connectは、セレモニーが開始される前にパスキーを提供するかどうかを決定し、その決定はブラウザの文字列以上のものをカバーします。[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)は、アカウントがセキュリティキー（`user-security-key`）を保持しているかどうか、この環境にローカルのプラットフォームパスキー、同期されたパスキー、クロスプラットフォームのパスキー、またはパスワードマネージャーに保持されているパスキーがあるかどうか、そして最近の完了、最近の不完全なログイン、中断された追加など、この環境で以前に何が起こったかをすでに知っている検出オブジェクトを受け取ります。したがって、クレデンシャルマネージャーが壊れていてアカウントに[YubiKey](https://www.corbado.com/glossary/yubikey)があるユーザーは、何もないユーザーとは異なるケースであり、どちらかがプロンプトを見る前に両者は分離されます。レポート側では、「インベントリ（Inventory）」が管理している内訳（クレデンシャルベースの同期型、デバイスバインド型、セキュリティキーのシェア、「セキュリティキーを持つユーザー」のKPI、および各クレデンシャルがどのように登録されたかの内訳）を表示します。

### 7.3 自動化された安全なリカバリー

パスワードレスへの移行により、紛失したデバイスの従来のフォールバックがないため、アカウントのリカバリーの重要性が高まります。

- **問題点**：摩擦の大きいリカバリーフローは、ユーザーを費用のかかる人手による支店への電話へと追いやるか、あるいは安全でないSMS/メールリセットの再導入を強いることになります。
- **Corbadoのソリューション**：リカバリーは、お客様が要求するeKYCやハードウェアセキュリティキーのステップを含め、お客様のプロセスおよびポリシーのままです。Corbadoの役割は、それを測定し、その頻度を減らすことです。Observeのファネルは、ログイン、サインアップ、登録と並んでリカバリーの図を保持するため、リカバリーはサポートの統計に消えてしまうのではなく、独自のステージと独自の離脱を持ち、「フリクション（Friction）」は、リカバリーで終了したログインと、ユーザーが開始して放棄したリカバリーを分離します。Connect側では、パスキーリストコンポーネントにより、ユーザー自身がクレデンシャルを追加および削除でき、削除後には`signalAllAcceptedCredentials`呼び出しが続くため、アカウントがもはや保持していないクレデンシャルをオーセンティケーターが提供しなくなります。古いクレデンシャルは、支店に届く「機能しないパスキーを要求される」という問い合わせの大部分を占めています。

### 7.4 キルスイッチによる安全な移行

パスワードのフォールバックを削除することは2025年の規制ロードマップの最終目標ですが、データなしにそれを行うことはユーザーアクセスにとっての致命的なリスクです。

- **問題点**：特定の[Sony](https://www.corbado.com/blog/playstation-passkeys-ps4-ps5)やSharpのデバイスモデルでの回帰問題にぶつかるような義務的な展開は、何千もの即時アカウントロックアウトを引き起こす可能性があります。
- **Corbadoのソリューション**：Connectの段階的展開のルールセットは、デバイスのブランド、デバイスモデル、プラットフォームとプラットフォームバージョン、ブラウザ、IPレンジ、および機能フラグに関する条件を持ち、許可、ブロック、サンプリング、またはフラグ付けのアクションを伴います。Connect独自のデバイスヘルスページは、異常な中断率を持つモデルを表面化し、各行から、ブランドとモデルがブロックとしてすでに記入されたルールビルダーに直接リンクします。そのため、展開から特定の端末を外すことは、アプリストアのリリースではなく、ルールセットの編集となります。ルールセットは、公開される前に過去1週間の記録されたトラフィックに対してリプレイできます。これらすべての背後にあるキルスイッチは、意図的に大まかなものになっています。ログイン、追加、およびパスキー管理を一緒に停止する、入力確認の背後にあるプロジェクト全体の1つのトグルです。これは最終手段であり、デバイスごとの作業はルール内で行われます。

[Video: Rollout rules](https://www.corbado.com/videos/features/rollout-rules.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))

### 7.5 完全な制御を維持する

Tier-1の銀行にとって、独自のWebAuthnサーバーとユーザーデータを所有することは、規制およびセキュリティ上の理由から交渉の余地がないことを私たちは理解しています。

- **Corbadoのアプローチ**：**私たちはIDPではありません。**
  既存のスタック、ユーザーデータベース、セキュリティポリシーはそのまま保持されます。Observeは現在のテレメトリでは見えないパスキーとセキュリティキーのジャーニーを記録し、Connectはすでに運用しているログインの前にオファーロジックを実行します。データはお客様の条件で外部に出力され、3つの出力ルートは異なる方法で制限されています。ページからのCSVダウンロードは、APIキーを伴わないプレーンなブラウザダウンロードです。日次Parquetテーブルのエクスポートはリスト化され、`observe:tableExports:read`を保持するAPIキーを介して署名されます。ユーザーごとのサブジェクトエクスポートは、`observe:dataExports:read`の背後にある個別のルートです。ObserveにはWebhookもイベントストリームもないため、お客様がプルしなかった宛先に何かがプッシュされることはありません。

### 7.6 今すぐ始める

日本におけるフィッシング耐性のあるパスワードレスな未来への移行は避けられませんが、それがサポートの惨事になる必要はありません。フォレンジックのオブザーバビリティと、プロンプトを出す前に各環境を読み取る意思決定層を組み合わせることで、ユーザーがどのデバイスでアクセスしてきても予測可能なエクスペリエンスを維持しながら、金融庁の義務化要件を満たすことができます。当社のSDKを既存のソリューションに統合する方法や展開の計画については、[お問い合わせ](https://www.corbado.com/contact)ください。

## 8. FAQ付録：日本のユーザーが実際に尋ねる質問

以下の質問は、検索のトレンド、サポートチケットの傾向、およびコミュニティのディスカッションから導き出された、日本のユーザーからのパスキー関連の最も一般的な質問を反映しています。これらを自然な質問として表現することで、移行中にユーザーが直面する真の意図や混乱に対処します。

### 8.1 エラーとトラブルシューティング

#### パスキーでログインできない場合はどうすればいいですか？ / What should I do if I can't login with a passkey?

一般的な原因：デバイス/ブラウザの不一致（特定のデバイスで作成されたパスキーはモバイルには表示されません）、アプリ内の[WebView](https://www.corbado.com/blog/native-app-passkeys)の制限、またはクロスデバイス認証に必要なトラフィックをブロックする企業プロキシ。登録時と同じブラウザ/プロファイルを使用するか、アプリ内ブラウザではなくシステムのフルブラウザでサイトを開いてみてください。

#### 「問題が発生しました」というエラーが表示されるのはなぜですか？ / Why am I seeing an "A problem occurred" error?

この一般的なエラーは通常、ブラウザとプラットフォームのオーセンティケーター間の通信障害を示しています。OSとブラウザが最新であること（例：最新のiOS、またはPlay開発者サービスが更新された最新のAndroid）を確認してください。

#### パスキーでアカウントに入れない時の対処法は？ / How do I fix access issues when I can't enter with a passkey?

アカウントにアクセスできない場合は、以下を確認してください：(1) パスキーが作成されたのと同じデバイス/クラウドエコシステムを使用しているか、(2) デバイスで画面ロック（生体認証/PIN）が正しく設定されているか、(3) サービスのセキュリティ設定がリセットされていないか。完全にロックアウトされた場合は、サービスのアカウント復旧フローを使用するか、サポートにお問い合わせください。

#### よくあるパスキーのエラーとその解決方法は？ / What are common passkey errors and how do I fix them?

パスキーの一般的なエラーは、古いブラウザやサポートされていないOSの使用に起因することがよくあります。最も一般的なエラーは
`NotAllowedError`
であり、これはユーザーによるキャンセルからクレデンシャルの欠落まで様々な原因が考えられます。ブラウザ、iOS、Androidにわたるすべてのエラータイプの詳細な内訳については、当社の包括的なWebAuthnエラーガイドを参照してください。最新のOSバージョンで最新のブラウザ（[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api)、Edge、[Safari](https://www.corbado.com/ja/blog/digital-credentials-api)）を使用していることを確認してください。また、デバイスの時計が同期されていること、およびパスキーの保存や取得を妨げる可能性があるシークレット/プライベートモードになっていないことも確認してください。

#### パスキーが反応しない、または認証が始まらないのはなぜですか？ / Why is my passkey not responding or starting authentication?

パスキーのプロンプトが起動しない場合：Bluetoothが有効になっているか（クロスデバイス/QRコードフローでは必須）、サイトがHTTPSを使用しているかを確認し、ブラウザの拡張機能（広告ブロッカーやパスワードマネージャーなど）がWebAuthnの呼び出しと競合していないか確認してください。ブラウザやデバイスを再起動することで、一時的な停止が解消されることがよくあります。

#### パスキーの認証画面が表示されないのはなぜですか？ / Why is the passkey authentication screen not appearing?

次の場合、システムのパスキーダイアログが表示されないことがあります：WebAuthnをサポートしていない[WebView](https://www.corbado.com/blog/native-app-passkeys)（アプリ内ブラウザ）を使用している場合、プラットフォームのクレデンシャルマネージャーが無効になっている場合、またはパスキーが別のプロファイルに存在する場合。Androidでは、Google
Play開発者サービスが実行されており、パスキーのUIで正しいGoogleアカウントが選択されていることを確認してください。

#### パスキーの認証中に画面がくるくるして進まないのはなぜですか？ / Why is the passkey screen stuck spinning or loading?

「くるくる」回っている状態は、ブラウザがBluetooth経由でオーセンティケーターデバイスへの接続を待機している（クロスデバイスフローの場合）、またはユーザーの操作を待機していることを意味することがよくあります。ローカルのパスキーを使用している場合、生体認証のプロンプトが別のウィンドウの後ろに隠れているか、別のプロンプトがまだ開いている可能性があります。

#### 「操作が中断されました」というエラーはどういう意味ですか？ / What does the "Operation was interrupted" error mean?

このエラーは、フローがユーザーによって明示的にキャンセルされた場合、タイムアウトした場合、またはフォーカスを失った場合に表示されます。すぐに認証を再試行してください。生体認証のプロンプトをすばやく完了し、処理中にアプリを切り替えたり画面をスリープさせたりしないようにしてください。Androidの野村證券ユーザーは、2025年11月の義務化以降、このエラーを頻繁に報告しており、多くの場合デバイス/OSの互換性の問題に関連しています（[詳細な分析](https://reiwabook.blog/nomura-pass-key-error/)）。

#### 「NotAllowedError」が表示されるのはなぜですか？ / Why am I seeing a "NotAllowedError"?

「[NotAllowedError](https://www.corbado.com/blog/webauthn-errors)」は通常、ユーザーが生体認証のプロンプトをキャンセルしたか、デバイスの画面ロックが無効になっているか、システムレベルの権限の問題がある場合に発生します。ウェルスナビも、「[NotAllowedError](https://www.corbado.com/blog/webauthn-errors)」はOSが提供する唯一のフィードバックであることが多く、リモートでのトラブルシューティングを困難にしていると指摘しています。

### 8.2 デバイスの変更とライフサイクル

#### 機種変更をする時、パスキーはどうすればいいですか？ / What happens to my passkeys when I change devices?

**同期されたパスキー**（iCloudキーチェーン、Googleパスワードマネージャー）は、新しいデバイスで同じクラウドアカウントにサインインすると自動的に引き継がれます。**デバイスにバインドされたパスキー**（[YubiKey](https://www.corbado.com/glossary/yubikey)や同期されていないプラットフォームのクレデンシャルなど）は引き継がれません。古いデバイスを初期化する\_前に\_、新しいデバイスで新しいパスキーを登録する必要があります。

#### パスキーを安全に削除するにはどうすればいいですか？ / How do I safely delete a passkey?

適切な削除は2段階のプロセスです：(1) パスキーが要求されないように、**サービスの**セキュリティ設定ページからパスキーを削除する。(2) ローカルストレージをクリーンアップするために、**デバイスの**パスキーマネージャー（iCloudキーチェーン、Googleパスワードマネージャーなど）からクレデンシャルを削除する。

#### 新しいスマホにパスキーを引き継ぐことはできますか？ / Can I transfer my passkeys to a new smartphone?

パスキーについて「引き継ぐ」という表現は誤解を招きやすいです。通常はクラウド（[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)/Google）経由で「同期」するか、「新しく登録」します。エコシステムを切り替える場合（例：iPhoneからAndroid）、既存のパスキーを移行することはできません。新しいスマートフォンで（パスワードまたはクロスデバイス認証を使用して）ログインし、そこで新しいパスキーを作成する必要があります。

#### パスキーの設定方法は？ / How do I set up a passkey?

セットアップは一般的に次の手順で行われます：(1) サービスにログインする、(2) アカウント/セキュリティ設定に移動する、(3) 「パスキーを作成」を選択する、(4) システムのプロンプトが表示されたら、生体認証/PIN認証を実行する。パスキーにはこの基盤となるセキュリティが必要なため、デバイスで画面ロック（FaceID、指紋、またはPIN）が有効になっていることを確認してください。

#### 複数の端末で同じパスキーを使うことはできますか？ / Can I use the same passkey on multiple devices?

同期されたパスキーの場合、1回の登録でそのエコシステム内のすべてのデバイス（すべての[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)デバイスなど）をカバーできます。クロスエコシステムでの使用（例：iPadとWindows
PC）の場合、ログインのたびにQRコードに依存することを避けるために、\_各\_プラットフォームでパスキーを登録する必要があります。ほとんどのサービスでは、アカウントごとに複数のパスキーを許可しています。

#### パスキーが入ったスマホを紛失した場合はどうなりますか？ / What happens if I lose the device containing my passkey?

唯一のパスキーが入ったデバイスを紛失した場合：利用可能であれば、フォールバック手段（パスワード、バックアップコード、メールのマジックリンク）を使用します。サービスが「パスキーのみ」である場合は、そのサービスの本人確認/復旧プロセスを経る必要があります。同期されたパスキーを使用すると、クレデンシャルが他のデバイスやクラウドアカウントに存在するため、このリスクを軽減できます。

#### 本人が亡くなった後、パスキーのアカウントはどうなりますか？ / What happens to passkey accounts after the owner passes away?

パスキーはユーザー個人のクラウドアカウントに厳密にバインドされているため、デジタル遺産の相続は非常に困難です。書き留められたパスワードとは異なり、家族がパスキーをそのまま「使う」ことはできません。サービス提供者は近親者によるアカウントアクセスのための法的手続きを確立し始めていますが、これは依然として複雑な摩擦ポイントです。

### 8.3 プラットフォームとデバイス

#### Androidでパスキーを使う際の注意点はありますか？ / Are there specific things to know about using passkeys on Android?

Androidのパスキーは、GoogleパスワードマネージャーとGoogle
Play開発者サービスに依存しています。エクスペリエンスはメーカー（Samsung、Sony、Sharpなど）によって異なる場合があります。クロスデバイス（QR）フローでは、OEMのカメラアプリがFIDOのQRコードを認識できない場合は、システム提供のスキャナーまたはGoogleレンズを使用してください。

#### iPhoneでパスキーはどう機能しますか？ / How do passkeys work on iPhone?

iPhoneのパスキーはiCloudキーチェーンに統合されています。同じApple
IDでサインインしているiOSおよびmacOSデバイス全体で一貫して機能します。設定で「iCloudキーチェーン」と「パスワードとパスキーの自動入力」が有効になっていることを確認してください。

#### Windowsでパスキーを使うにはどうすればいいですか？ / How do I use passkeys on Windows?

[Windows 11](https://www.corbado.com/blog/passkeys-windows-11)は、[Windows Hello](https://www.corbado.com/glossary/windows-hello)を介したネイティブのパスキー管理を提供します。パスキーはローカルに（顔/指紋/PINで保護されて）保存することも、ブラウザプロファイル（[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api)のGoogleアカウントなど）を介して同期することもできます。企業のPCでは、ITポリシーによって[Windows Hello](https://www.corbado.com/glossary/windows-hello)の使用が制限され、モバイルデバイス認証（QRコード）やセキュリティキーへの依存を余儀なくされる場合があります。

#### 高齢者でもパスキーは使いこなせますか？ / Are passkeys suitable for elderly users?

高齢のユーザーは、「パスワードがない」という概念や、QRコードスキャンの仕組みに苦労することがよくあります。最新のAndroidを搭載したシニア向けの新しいスマートフォンは技術的にパスキーをサポートしているかもしれませんが、UXの障壁は高くなります。セットアップには家族の支援が必要になることがよくあります。サービス提供者は、この層向けに代替のログイン方法を厳格に維持する必要があります。

### 8.4 コンセプト

#### そもそも「パスキー」とは何ですか？ / What exactly is a "passkey"?

パスキーとは、パスワードに代わる、デバイスに保存される安全なデジタルキーです。秘密の文字列を入力する代わりに、デバイスのロックを解除（顔、指、PIN）して本人であることを証明します。ウェブサイトがあなたの秘密鍵を見ることはないため、パスキーは情報漏洩やフィッシングに対して耐性を持ちます。

#### パスキーはパスワードよりも本当に安全ですか？ / Are passkeys really more secure than passwords?

パスキーは、**フィッシング耐性**があり（偽のサイトにログインするように騙されることがない）、**一意**である（クレデンシャルの使い回しがない）ため、パスワードよりもはるかに安全です。ただし、セキュリティは最初の登録に依存します。攻撃者があなたのパスワードを持っている場合、あなたが登録する前に攻撃者自身のパスキーを登録する可能性があります。

#### パスキーを使うことのデメリットやリスクはありますか？ / Are there disadvantages or risks to using passkeys?

主なデメリット：(1)
**デバイスへの依存**：クラウドアカウントやデバイスへのアクセスを失った場合、ロックアウトのリスクは現実のものです。(2)
**共有デバイスでの摩擦**：パスキーは個人的なものであり、共有の家族用/公共のコンピューターではうまく機能しません。(3)
**アカウント集約の問題**：銀行が専用のAPIを提供せずにパスキーのみに移行した場合、従来型の統合方法に依存するアカウント集約サービス（マネーフォワードなど）は接続の課題に直面する可能性があります。(4) 企業ネットワークによるクロスデバイスプロトコルの**ブロック**。