パスキー日本 2026：規制・導入状況と実装課題

1. はじめに#

2025年、進化するセキュリティ上の脅威に対応するため、日本国内でパスキーの導入が一気に加速しました。金融セクターで不正アクセス事件が相次いだことを受け、規制当局は「ID・パスワードのみの認証や、メール/SMSによるワンタイムパスワードではもはや不十分である」とし、高リスクな金融取引においては「パスキーのような、より強固な認証方法を優先すべき」と強調しました。

その結果、2025年末までに50以上のパスキープロバイダーがサービスを開始（または計画）し、64の組織がFIDO Japan Working Groupに参加しました。業界は数年単位ではなく、数ヶ月単位での対応を迫られる規制スケジュールに直面しました。

しかし、この日本の急速な展開は、米国や欧州の事例ではあまり見られない形でFIDOエコシステムに負荷をかけることになりました。企業におけるWindows/Edgeの高いシェア、多様なAndroid OEMの状況、そして厳格な企業のネットワークポリシーなどが組み合わさり、特にAndroidでのパスキーQRコード、iPhoneのクロスデバイスフロー、複数デバイスでの登録といったエッジケースが露呈しました。これは、グローバル市場向けの製品を開発するチームにとっても理解しておくべき重要な点です。

この記事では以下について解説します：

1. 導入済みの企業：楽天証券、野村證券、SBI証券、マネックス証券など
2. きっかけ：規制と不正利用の時系列
3. APAC特有の事情：Android vs iPhoneの断片化
4. 実装上の課題：現場で頻発する障害
5. 対策：戦略的な推奨事項

2. 導入状況トラッカー：どこが対応済み？#

日本の金融機関は、新たな規制要件を満たすために急速に動いています。以下は、2025年後半時点での状況スナップショットです。

2.1 野村證券のパスキー#

ステータス： 対応済み（2025年11月29日よりパスキー認証を原則必須化）

野村證券は、すべてのユーザーに対してパスキー認証を必須化しました。主な特徴は以下の通りです：

• ネイティブアプリ「NOMURAアプリ」経由での登録
• より安全な取引のために、フィッシング耐性がありパスワードレスな手段としてパスキーを位置づけ
• 既知のAndroidの課題：特定のAndroid端末やOSの組み合わせにおいて、ユーザーから「M0902」や「操作が中断されました」といったエラーが報告されています（トラブルシューティングガイド、サポートリソース）。

野村證券 サポート

2.2 楽天証券のパスキー#

ステータス： 対応済み（2025年10月26日導入）

楽天証券は、強力なクロスデバイスサポートを備えたFIDO2パスキー認証を展開しました：

• すべての取引チャネルでFIDO2パスキー認証に対応
• クロスデバイスQRフローにより、スマートフォン上のパスキーを使ってPCへのログインが可能
• パスキーへの移行を強く推奨
• パスキー登録後はパスワードを無効化：他の証券会社とは異なり、ユーザーがパスキーを登録すると、そのユーザーのパスワードログインは無効化されます。これは「段階的移行」の中でもより厳格なアプローチです。
• 家計簿アプリなどがスクレイピングの代わりに利用できるAPIを提供。

楽天証券 お知らせ

2.3 SBI証券のパスキー#

ステータス： 対応済み/計画中（FIDOは2021年から、FIDO2パスキーは2025年秋までに）

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

• パスワード ＋ SMS OTPからの置き換え
• ウェブ版への初期展開に続き、ネイティブアプリ（10以上のアプリを計画）へ展開
• ユーザーの選択：パスキーを推奨しつつも、パスワード認証も維持
• 以前の不正被害への補償請求への対応として一部導入
• 課題：サポートの混雑（待ち時間が最大30分に及ぶことも）。

Impress Watch記事

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

ステータス： 対応済み（2025年10月31日導入）

マネックス証券は、幅広いプラットフォームのサポートと明確なセキュリティメッセージを掲げてローンチしました：

• 幅広いOSサポート：Windows 11+、macOS 13+、Android 11+、iOS 16+
• ウェブとアプリで統一された体験
• 「フィッシング耐性」を明確にアピール

マネックス証券 お知らせ

2.5 PayPay証券のパスキー#

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

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

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

Impress Watch記事

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

ステータス： 対応済み（2025年）

リクルートIDは、マルチデバイス対応のパスキーを実装しました：

• マルチデバイス登録をサポート
• 共有/公共デバイスでの資格情報登録に対して強く警告

リクルート お知らせ

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

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

アコムは登録時のセキュリティを見直し強化するため、新規の生体認証登録を一時停止しました。これは教訓的な事例です。フィッシング耐性のある認証器（Authenticator）であっても、不正アクセスを防ぐためには強力な初期登録時の本人確認が必要であることを示しています。

アコム FAQ

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

ステータス： 計画中（2026年2月9日よりパスキー必須化）

みずほ証券は、重要な口座操作すべてにおいてパスキーを必須とする予定です：

• 対象：ネット倶楽部および株アプリでの取引、入出金、登録情報変更
• サポート環境：Windows 11 (Edge/Firefox/Chrome)、macOS 14+、iOS 17+、Android 10+
• Windows Hello、iCloud キーチェーン、または Google パスワードマネージャー を利用

みずほ証券 FAQ

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

ステータス： 対応済み（登録者数20万人超、アクティブユーザーの40-50%が利用）

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

• 必須化への道：今後1年以内にパスワード認証の廃止を目指す。
• 家計簿アプリなどがスクレイピングの代わりに利用できるAPI連携を提供。
• Appleの「Automatic Passkey Upgrade（自動パスキーアップグレード）」のような新技術に期待。
• ITmedia 記事

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

日本におけるパスキーの急激な普及は、UX（ユーザー体験）のトレンドによるものではありませんでした。それは、規制当局が直接介入する事態にまでエスカレートした、フィッシングによるアカウント乗っ取り（ATO）に対する防衛策でした。

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

2025年1月の対話に向けた資料において、日本の金融庁（FSA）はフィッシング被害を主要な詐欺経路として説明し、DMARCや迅速なサイト閉鎖と並ぶ対策として**「パスキー利用の促進」**を挙げました。また、2024年12月24日に警察庁と共同で発出した、より強力なフィッシング対策を求める要請についても言及しています。

3.2 2025年：規制の焦点「オンライン取引における不正アクセス」#

2025年半ばまでに、金融庁は「証券口座のインターネット取引における不正アクセスおよび不正取引」を強調し、現代の脅威に対してID・パスワードのみの認証では不十分であることが多いと明言しました。

3.3 JSDAガイドライン改正案：重要な操作にはフィッシング耐性MFAをデフォルトに#

2025年7月15日、日本証券業協会（JSDA）は、インターネット取引における不正アクセス防止のためのガイドライン改正案を公表しました。この草案では、ログイン、出金、出金先口座変更のフローにおいて、フィッシング耐性のあるMFAの実装と必須化（デフォルトオン）を求めており、その例としてパスキーを明示しています。また、検知・通知およびロックアウト制御の基準も引き上げています。（JSDA ガイドライン改正案 PDF、報道記事）義務化の期限は2026年夏と予想されています。

2025年12月までに、FIDOアライアンスのJapan Working Groupは64の加盟組織に拡大し、日本国内で50以上のパスキープロバイダーが稼働または計画中となりました。これは、証券フィッシング危機とその後の規制当局のプッシュによる直接的な結果です。

3.4 アコムの教訓：「パスワードレス」の安全性は、登録と復旧の安全性次第#

アコムによる新規生体認証登録の一時停止（2025年半ば）は、有益な教訓です。フィッシング耐性のある認証器であっても、不正アクセスを防ぐためには、最初の登録時における強力な本人確認が必要です。（アコム FAQ）

4. なぜAPACでは独自の戦略が必要なのか：デバイスとブラウザの現実#

日本（および広範なAPAC地域）にパスキーを展開する場合、米国や欧州でのテストが通常カバーする範囲よりも、はるかに不均一なデバイスおよびネットワーク環境で運用することになります。

• 日本のトラフィックは「モバイルオンリー」ではありません。デスクトップも依然として重要です。
• 企業のWindowsフリート（端末群）が重要であり、多くの市場と比較してEdgeのシェアが実質的に高い傾向にあります。
• 「デバイスの現実」を知るための追加コンテキストとして、StatCounterはモバイルベンダーおよびモバイル画面解像度の分布データも提供しています（ハードウェアの多様性を示す有用な指標です）。
• Androidエコシステムはより多様（OEMおよびキャリアによるカスタマイズ）であり、パスキーの挙動は、OS、ブラウザ、そしてプラットフォームの認証情報プロバイダー層（例：Google Play開発者サービス / Credential Manager）の相互作用に依存します。その実際の結果として、ばらつきが大きく、エッジケースが増え、「端末Aでは動くが、端末Bでは失敗する」といったデバッグ作業が増加します。
• OEM固有の導入ブロッカー： Conditional Create（条件付き作成・自動パスキーアップグレード）のような高度な登録機能は、Google Pixelデバイスと比較して、「OEM Android」ハードウェア（Pixel以外のデバイス）での成功率が著しく低いことがよくあります。例えば、多くのSamsungデバイスは、プライマリの認証情報マネージャーとしてSamsung Passをデフォルトにしているため、Google パスワードマネージャーの統合に依存するパスキーのバックグラウンド作成がブロックされることがあります。
• Credential Managerのシステムバグ： Android 14における大きなハードルの一つが、文書化されたシステムバグです。これにより、Credential Manager APIがパスキー選択UIを正しく表示できなかったり、「認証情報が見つかりません」というエラーを返したりします。この問題はOEMハードウェアのユーザーに不均衡に影響を与えており、重要な金融アプリのロールアウト時に予期せぬ摩擦を生み出しています。
• OEM Androidの課題： 最近の金融アプリのロールアウトに関する独立した分析により、特定のAndroid 14デバイス（人気のあるSamsung Galaxy A、Sony Xperia、Sharp AQUOSモデルを含む）における認証の課題が特定されています。Google独自の実装は最新のFIDO標準とより整合している傾向があるため、これらの問題は通常、Google Pixel以外のハードウェアで発生します。詳細なトラブルシューティングについては、現地のサポートリソースも参照してください。
• これは仮定の話ではありません。公式のOEMセキュリティアップデート・データセットを分析した2024年のNDSS論文は、大手Android OEMが一度にどれだけ多くの地域/国/キャリアのバリアントをサポートしているかを示しています（例：Samsungは97カ国、109キャリアにわたる402デバイスの約1,400のユニークモデル；Xiaomiは10地域にわたる223デバイス）。同論文は、このワークロードが一部のセキュリティアップデートの遅延（あるいは失敗）を招き、パッチがエンドユーザーに届くのが遅れたり、不均一になったりする可能性があると指摘しています。

5. 実装上の考慮事項：失敗のパターン#

日本の組織が仕様策定から本番運用へと移行するにつれ、いくつかの繰り返される失敗パターンが浮上してきました。これらの実例は、標準的なテストとAPACでの展開現実とのギャップを物語っています。

ケース1：「手探りロールアウト」シナリオ#

サービスプロバイダーが規制ガイドラインを満たすためにパスキーの導入を急ぎ、デバイスレベルのテレメトリ（遠隔測定データ）なしに全ユーザーへ一斉にパスキーを導入する場合です。

• 失敗： チームは自分たちのテスト端末で「成功」を確認しますが、断片化されたOEMハードウェアでの3倍高い失敗率には気づけません。ユーザーは混乱（例：非対応端末、プラットフォームアカウントの欠如など）に直面し、単に離脱してしまいますが、銀行側にはなぜ、どこで摩擦が起きているのかを説明するデータがありません。

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

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

• 失敗： 「ハッピーパス（理想的な経路）」では、完璧なBluetooth/ハイブリッドフロー接続を前提としています。現実には、企業のプロキシがFIDOハイブリッドフローに必要な通信をブロックすることが頻繁にあります。堅牢なマルチアクセスポイント計画がない場合、これはシームレスなログインを恒久的な接続障壁に変えてしまいます。

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

以前は機能していたフローがOSアップデート後に失敗し始めたり、特定のメーカーのデバイス（Samsung、Sony、Sharp）でのみ失敗したりする場合です。

• 失敗： 文書化されたAndroid 14のバグや、OEM固有のデフォルト設定（Samsung Passなど）が標準化されたフローをブロックします。パスキープロバイダー層の挙動がバージョンによって一貫せず、QRコードのハンドオフ失敗や、デバイス固有のモニタリングなしでは原因特定が不可能な「認証情報が見つかりません」エラーにつながります。

ケース4：「完全なロックアウト」リスク#

サービスがパスワードによるフォールバック（代替手段）を早すぎる段階で無効化したり、初期登録時の本人確認を確実にしなかったりする場合です。

• 失敗： 初期登録が不安全な場合（アコムの事例のように）、盗まれたパスワードを持つ攻撃者が自分のパスキーを登録してしまいます。逆に、2025年の義務化に対応するために銀行が「パスワードレス」に移行した後は、レガシーなセーフティネットが存在しないため、登録時の摩擦やデバイスの故障は、絶対的なユーザーのロックアウト（締め出し）を意味します。

6. 戦略的な推奨事項#

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

1. 認証の可観測性と段階的なロールアウトに投資する。 サポートチケットが届く前に「3倍の失敗率」のギャップを捉えるため、デバイス、OS、ブラウザごとにパスキーのプロンプト表示から完了までの率を追跡する必要があります。

   • Webの場合：OSバージョンとブラウザの種類ごとにロールアウトを段階分けします。
   • ネイティブアプリの場合：特定のデバイスモデル（例：まずはPixel、次にOEMメーカー）ごとに段階分けし、リグレッション（後戻り）を早期に発見します。
   • モニタリング：ロックアウトのリスクを理解するために、保存場所（システム vs サードパーティ）を継続的に監視します。

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

3. 完全なパスワードレスへの準備をする。 規制当局からの圧力により、初回ログインにおけるパスワードの完全廃止が加速すると予想してください。これにより、セクション5で述べた技術的なハードルの解決はコンプライアンス上の必須事項となります。パスワードというフォールバックがなくなれば、デバイスレベルの障害はそのまま完全なロックアウトになるからです。

4. APAC重視のデバイステスト・マトリックスを構築する。 日本ではSamsung、Sony、Sharpのモデルが大きなシェアを占めています。テストマトリックスが限定的であれば、バグを含んだまま出荷することになります。日本市場でシェアの高いOEMを含め、推奨事項1の可観測性データを使用して、サポート対象デバイスリストをリアルタイムで改善してください。

5. マルチデバイスおよびマルチアクセスポイントの現実に向けて設計する。 Bluetooth CDAや企業プロキシは失敗すると想定してください。明確なネットワーク要件と、マルチデバイス登録などの堅牢なフォールバックを提供し、環境やアクセスポイントに関わらずユーザーが認証できるようにしてください。

6. 高保証の補完手段としてハードウェアセキュリティキーを評価する。 厳しく制限された企業環境のユーザーや、最大限の保証を必要とするユーザーにとって、ハードウェアセキュリティキー（YubiKeyなど）は、同期型パスキーの強力な代替手段となります。これらのキーは、プラットフォーム固有のクラウド同期やBluetooth接続に依存することなく、モバイルやレガシーなデスクトップフリートを含むほぼすべてのデバイスで一貫して動作する物理的な信頼の基点（Root-of-Trust）を提供します。堅牢なアーキテクチャでは、これらのハードウェアバウンドな認証器がプラットフォームパスキーと共存できるようにし、ユーザーが特定のアクセスコンテキストに合わせて「鍵」を選択できる柔軟性を持たせるべきです。

7. サポートのボトルネックを防ぐために復旧を自動化する。 パスワードレスモデルへの移行は、脆弱な認証方法を再導入しない合理化された復旧プロセスがあって初めて持続可能になります。日本の金融のような高セキュリティ分野にとって、これはSMS/メールによるリセットを超えて、セルフィーベースの本人確認や、信頼されたハードウェアを使用したクロスデバイスフォールバックなどの「スマートMFA」復旧へ移行することを意味します。自動化された復旧計画がなければ、パスワードリセットのチケットが減った分は、すぐに複雑なパスキー紛失サポートの電話対応で相殺されてしまうでしょう。

結論： 日本の経験は、「仕様への準拠」と「実際のユーザー環境での動作」の間のギャップが、多くのチームが予想する以上にAPACでは広いことを示しています。勝者となるのは、デバイスの断片化と登録セキュリティを第一級のエンジニアリング課題として扱い、専用のオーケストレーション層を使ってそのギャップを埋めるチームです。

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

日本の金融機関にとって、パスキーへの移行はもはや「UXの実験」ではありません。それは、不正利用率と運用コストに即座に影響を与える、重要なコンプライアンス上の義務です。しかし、最近の導入事例が示すように、「パスキーをリリースする」ことは始まりに過ぎません。真の課題は、日本のデバイスエコシステムの断片化された現実を管理することにあります。

Corbadoは、既存のIDプロバイダー（IDP）とWebAuthnサーバーの上に配置される、パスキーの可観測性および導入支援レイヤーを提供します。私たちは、「仕様への準拠」と「現実世界での成功」の間のギャップを埋めるお手伝いをします。

7.1 「手探り」をやめる：完全なフォレンジック可視化#

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

• 問題：ログには「ログイン失敗」と表示されるかもしれませんが、それが文書化されたAndroid 14のシステムバグなのか、Samsung Passの競合なのか、あるいはUIがわかりにくくてユーザーがキャンセルしたのかまでは教えてくれません。
• Corbadoのソリューション：特定のデバイスモデル、OSバージョン、ブラウザごとに、プロンプト表示から完了までの率を追跡する、認証ネイティブな可観測性を提供します。これには、ハードウェアセキュリティキーと同期型パスキーの使用状況のモニタリングも含まれ、特定のユーザーセグメントに対してどの要素が最も高い成功率をもたらすかを正確に把握できます。

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

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

• 問題：単一の認証パス（同期型パスキーなど）を強制すると、クラウド同期が無効化されている企業環境や、認証情報マネージャーが破損しているOEMデバイスで失敗する可能性があります。
• Corbadoのソリューション：私たちの導入インテリジェンスにより、プラットフォームパスキーとハードウェアセキュリティキーの両方をシームレスに統合する柔軟なポリシーを定義できます。問題のあるデバイスや制限されたネットワークのユーザーに対して、YubiKeyをプレミアムまたは高保証のフォールバックとして提供することができ、サポートのオーバーヘッドを増やすことなく100%のリーチを確保できます。

7.3 自動化された安全な復旧#

パスワードレスへの移行は、紛失したデバイスに対するレガシーなフォールバック手段がないため、アカウント復旧の重要性を高めます。

• 問題：摩擦の大きい復旧フローは、ユーザーを高コストな有人対応（支店や電話）に追いやるか、不安全なSMS/メールリセットの再導入を余儀なくさせます。
• Corbadoのソリューション：私たちは、ユーザーの行動に基づいて外部の復旧ソリューションやプロセスを統合します。これには、ハードウェアセキュリティキーやシステムで定義されたその他のカスタム手順など、高保証の復旧要素を明示的に要求することが含まれます。これにより、ユーザーがプライマリデバイスを紛失した場合でも、手動介入なしに日本の規制基準を満たす検証済みメソッドを通じてアクセスを回復できます。

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

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

• 問題：特定のSonyやSharpのデバイスモデルでリグレッション（不具合）が発生した場合、義務化されたロールアウトでは何千ものアカウントが即座にロックアウトされる可能性があります。
• Corbadoのソリューション：私たちのプラットフォームでは、ユーザーベース全体でさまざまな認証器タイプをパイロット運用し、技術環境ごとに段階的にロールアウトすることができます。特定のデバイス/OSの組み合わせで障害が発生し始めた場合、アプリストアのアップデートを待つことなく、デバイスレベルのキルスイッチで即座にその組み合わせを無効化できます。

7.5 完全なコントロールを維持#

ティア1の銀行にとって、WebAuthnサーバーとユーザーデータを自社で保有することは、規制およびセキュリティ上の理由から譲れない条件であることを理解しています。

• Corbadoのアプローチ：私たちはIDPではありません。 お客様は既存のスタック、ユーザーデータベース、セキュリティポリシーを維持します。Corbadoはその上に「インテリジェンスと可視化のレイヤー」を追加し、既存のSIEMや不正検知ツールに期待するのと同等のフォレンジック可視性を、パスキーとセキュリティキーのジャーニーに対しても提供します。

7.6 今すぐ始めましょう#

日本におけるフィッシング耐性のあるパスワードレスな未来への移行は不可避ですが、それがサポートの惨事を招く必要はありません。フォレンジックな可観測性とインテリジェントな導入戦略を組み合わせることで、デバイスに関わらずすべてのユーザーにシームレスな体験を提供しながら、金融庁の必須要件を満たすことができます。既存のソリューションへのSDK統合やロールアウトの計画については、お問い合わせください。

8. FAQ付録：日本のユーザーが実際に抱いている疑問#

以下の質問は、検索トレンド、サポートチケットの傾向、コミュニティでの議論から導き出された、パスキーに関して日本のユーザーから最も頻繁に寄せられる質問です。これらを自然な質問形式にすることで、移行期にユーザーが直面する本当の意図や混乱に対処します。

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

パスキーでログインできない場合はどうすればいいですか？#

一般的な原因：デバイス/ブラウザの不一致（特定のデバイスで作成したパスキーはモバイルには表示されない）、アプリ内のWebViewの制限、またはクロスデバイス認証に必要な通信をブロックする企業のプロキシなどがあります。登録時と同じブラウザ/プロファイルを使用するか、アプリ内ブラウザではなく完全なシステムブラウザでサイトを開いてみてください。

「問題が発生しました」というエラーが表示されるのはなぜですか？#

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

パスキーでアカウントに入れない時の対処法は？#

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

よくあるパスキーのエラーとその解決方法は？#

一般的なパスキーのエラーは、古いブラウザやサポートされていないOSの使用に起因することがよくあります。最新のOSバージョンでモダンブラウザ（Chrome、Edge、Safari）を使用していることを確認してください。また、デバイスの時計が同期されているか、シークレットモード/プライベートモードになっていないかも確認してください（パスキーの保存や呼び出しに干渉することがあります）。

パスキーが反応しない、または認証が始まらないのはなぜですか？#

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

パスキーの認証画面が表示されないのはなぜですか？#

システムパスキーのダイアログが表示されない場合、WebAuthnをサポートしていないWebView（アプリ内ブラウザ）を使用しているか、プラットフォームの認証情報マネージャーが無効になっているか、パスキーが別のプロファイルに存在している可能性があります。Androidでは、Google Play開発者サービスが実行されており、パスキーUIで正しいGoogleアカウントが選択されていることを確認してください。

パスキーの認証中に画面がくるくるして進まないのはなぜですか？#

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

「操作が中断されました」というエラーはどういう意味ですか？#

このエラーは、フローがユーザーによって明示的にキャンセルされた場合、タイムアウトした場合、またはフォーカスが外れた場合に表示されます。すぐに認証を再試行してください。生体認証の確認を素早く完了させ、プロセス中にアプリを切り替えたり画面をスリープさせたりしないようにしてください。2025年11月の義務化以降、Nomura SecuritiesのAndroidユーザーからこのエラーが頻繁に報告されており、デバイス/OSの互換性の問題に関連していることが多いです（詳細な分析）。

「NotAllowedError」が表示されるのはなぜですか？#

「NotAllowedError」は通常、ユーザーが生体認証プロンプトをキャンセルしたか、デバイスの画面ロックが無効になっているか、システムレベルの権限に問題がある場合に発生します。WealthNaviも指摘しているように、「NotAllowedError」はOSが提供する唯一のフィードバックであることが多く、リモートでのトラブルシューティングを困難にしています。

8.2 機種変更とライフサイクル#

機種変更をする時、パスキーはどうすればいいですか？#

同期型パスキー（iCloud キーチェーン、Google パスワードマネージャー）は、新しいデバイスで同じクラウドアカウントにサインインすると自動的に引き継がれます。デバイスバウンドパスキー（例：YubiKeyや非同期のプラットフォーム認証情報）は引き継がれません。古いデバイスを消去する前に、新しいデバイスで新しいパスキーを登録する必要があります。

パスキーを安全に削除するにはどうすればいいですか？#

適切な削除は2ステップのプロセスです：(1) サービスのセキュリティ設定ページからパスキーを削除してリクエストされないようにし、(2) ローカルストレージを整理するために、デバイスのパスキーマネージャー（iCloud キーチェーン、Google パスワードマネージャーなど）から認証情報を削除します。

新しいスマホにパスキーを引き継ぐことはできますか？#

パスキーにおいて「転送」という言葉は正確ではありません。通常はクラウド（Apple/Google）経由で「同期」するか、新しいものを「登録」します。エコシステムを切り替える場合（例：iPhone → Android）、既存のパスキーを移行することはできません。新しい電話で（パスワードまたはクロスデバイス認証を使用して）ログインし、そこで全く新しいパスキーを作成する必要があります。

パスキーの設定方法は？#

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

複数の端末で同じパスキーを使うことはできますか？#

同期型パスキーの場合、1回の登録でそのエコシステム内のすべてのデバイス（例：すべてのAppleデバイス）をカバーします。クロスエコシステムでの利用（例：iPad + Windows PC）の場合、ログインのたびにQRコードに頼るのを避けるため、各プラットフォームでパスキーを登録することをお勧めします。ほとんどのサービスでは、1つのアカウントに対して複数のパスキーを登録できます。

パスキーが入ったスマホを紛失した場合はどうなりますか？#

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

本人が亡くなった後、パスキーのアカウントはどうなりますか？#

パスキーはユーザー個人のクラウドアカウントに厳密に紐付けられているため、デジタル遺産としての継承は極めて困難です。紙に書いたパスワードとは異なり、家族が単にパスキーを「使う」ことはできません。近親者によるアカウントアクセスについて法的な手続きを整備し始めているサービスもありますが、依然として複雑な課題となっています。

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

Androidでパスキーを使う際の注意点はありますか？#

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

iPhoneでパスキーはどう機能しますか？#

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

Windowsでパスキーを使うにはどうすればいいですか？#

Windows 11は、Windows Helloを介してネイティブのパスキー管理を提供します。パスキーはローカルに保存される（顔/指紋/PINで保護）か、ブラウザプロファイル（例：ChromeのGoogleアカウント）を介して同期されます。企業のPCでは、ITポリシーによってWindows Helloの使用が制限されている場合があり、その際はモバイルデバイス認証（QRコード）やセキュリティキーへの依存を余儀なくされることがあります。

高齢者でもパスキーは使いこなせますか？#

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