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

1. はじめに#

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

その結果、年末までに50以上のパスキープロバイダーが稼働または計画され、FIDOジャパン・ワーキンググループには64の組織が参加し、業界に数年ではなく数ヶ月での対応を求める規制スケジュールが示されました。

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

本記事の内容：

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

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

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

2.1 野村證券のパスキー#

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

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

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

野村證券 サポート

2.2 楽天証券のパスキー#

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

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

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

楽天証券 ニュース

2.3 SBI証券のパスキー#

ステータス： 稼働中/計画中（2021年からFIDO導入；2025年秋までにFIDO2パスキーへ）

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年半ばに新規の生体認証登録を一時停止）

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

アコム FAQ

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

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

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

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

みずほ証券 FAQ

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

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

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

• 義務化への道：来年中のパスワード認証の廃止を目指す。
• スクレイピングに代わる家計簿アプリ向けのAPI統合を提供。
• Appleの「パスキーの自動アップグレード（Automatic Passkey Upgrade）」のような新技術に期待。
• ITmedia 記事

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

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

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

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

プレスリリース

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

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

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

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

ソフトバンク お知らせ（日本語）

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アライアンスのFIDOジャパン・ワーキンググループは64のメンバー組織に拡大し、日本では50以上のパスキープロバイダーが稼働または計画中となりました。これは、証券フィッシング危機とそれに続く規制の推進による直接的な結果です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以前は機能していたフローがOSのアップデート後に失敗し始めるか、特定のメーカーのデバイス（Samsung、Sony、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、Sharpのモデルが主流です。テストマトリックスが限定されている場合、バグを出荷することになります。日本で多く使用されるOEMを含め、推奨事項1のオブザーバビリティのデータを使用して、サポート対象のデバイスリストをリアルタイムで改良してください。

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

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

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

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

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

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

Corbadoは、既存のアイデンティティプロバイダー（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 完全な制御を維持する#

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

• Corbadoのアプローチ：私たちはIDPではありません。 既存のスタック、ユーザーデータベース、セキュリティポリシーはそのまま保持されます。Corbadoはその上に「インテリジェンスと可視性の層」を追加し、現在既存のSIEMや不正防止ツールに期待されているのと同じ、パスキーとセキュリティキーのジャーニーに対するフォレンジックの可視性を提供します。

7.6 今すぐ始める#

日本におけるフィッシング耐性のあるパスワードレスな未来への移行は避けられませんが、それがサポートの惨事になる必要はありません。フォレンジックのオブザーバビリティとインテリジェントな導入戦略を組み合わせることで、デバイスに関係なくすべてのユーザーにシームレスなエクスペリエンスを維持しながら、金融庁の義務化要件を満たすことができます。当社のSDKを既存のソリューションに統合する方法や展開の計画については、お問い合わせください。

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

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

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

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

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

「問題が発生しました」というエラーが表示されるのはなぜですか？ / 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、Edge、Safari）を使用していることを確認してください。また、デバイスの時計が同期されていること、およびパスキーの保存や取得を妨げる可能性があるシークレット/プライベートモードになっていないことも確認してください。

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

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

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

次の場合、システムのパスキーダイアログが表示されないことがあります：WebAuthnをサポートしていないWebView（アプリ内ブラウザ）を使用している場合、プラットフォームのクレデンシャルマネージャーが無効になっている場合、またはパスキーが別のプロファイルに存在する場合。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の互換性の問題に関連しています（詳細な分析）。

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

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

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

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

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

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

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

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

パスキーについて「引き継ぐ」という表現は誤解を招きやすいです。通常はクラウド（Apple/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デバイスなど）をカバーできます。クロスエコシステムでの使用（例：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は、Windows Helloを介したネイティブのパスキー管理を提供します。パスキーはローカルに（顔/指紋/PINで保護されて）保存することも、ブラウザプロファイル（ChromeのGoogleアカウントなど）を介して同期することもできます。企業のPCでは、ITポリシーによって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) 企業ネットワークによるクロスデバイスプロトコルのブロック。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのAuthentication Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →