導入後に潜む5つのリスク：パスキー運用の「Day 2」問題

1. はじめに：導入後に潜むパスキーのリスク#

パスキーを実装してはいけません。

少なくとも、どんな犠牲を払ってでも実装すべきではありませんし、適切に行うリソースがないならなおさらです。

確かに、パスキーはこの10年間で消費者向け認証に起こった最高の出来事です。フィッシングを撲滅し、UXを劇的に向上させることができます。しかし、パスキーの実装を誤ると、多くの損害をもたらす可能性もあります。

WebAuthnサーバーの実装自体はそれほど複雑ではありません。本当の課題は、その周辺のすべてにあります。パスキーを大規模かつ効率的に運用するには、事前の計画が必要です。パスキーの展開を開始した後に初めて表面化する運用の現実、つまり「Day 2（運用フェーズ）」のすべての問題について考える必要があります。

この記事では、パスキープロジェクトを継続的に失敗させる5つの「Day 2」問題について解説します。これらをすべて解決できない場合、パスキーを導入する準備はできていません。解決できるなら、パスワードが提供できるものをはるかに超える、より安全で使いやすい認証を構築できるでしょう。

2. パスキーの「Day 2」問題とは何か？#

エンジニアリングにおいて、「Day 1」は構築してリリースする時です。「Day 2」は、リリースしたものを運用、保守、拡張する時です。パスキーの場合、Day 1はシンプルです：

• WebAuthnサーバーをエンタープライズスタックに統合する
• フロントエンドのフローを追加してリリースする

ほとんどのチームは、数日から数週間で基本的なパスキー実装を稼働させることができます。

Day 2こそが、プロジェクトが失敗する場所です。実際のデバイス、実際のエッジケースを持つ実際のユーザーが、あなたのパスキーシステムと対話する瞬間です。MacBookで完璧に動作した見栄えの良いデモが、企業のプロキシの背後にあるChromeを実行しているWindowsラップトップで壊れることに気づく時です。サポートチームが「もうログインできない」というチケットで溢れかえる時です。

動作するパスキーのデモと、本番環境レベルのパスキー展開との間には、とてつもないギャップがあります。これまでにも、技術的な実装の落とし穴や、パスキープロジェクトが失敗する戦略的な理由について取り上げてきました。この記事では、本番稼働後に運用の観点から何が起こるかに特化して焦点を当てます。

以下が、今回取り上げる5つのDay 2問題です：

3. 課題 1：リカバリーとフォールバックの保護は難しい#

リカバリー（復旧）とフォールバックを適切に設計しないと、ユーザーを大規模に締め出すか、排除したかったはずのフィッシングに弱いフローを静かに再導入することになります。

3.1 大規模なアカウントロックアウトのリスク#

ユーザーがiPhoneでパスキーを登録し、その後そのiPhoneを紛失したとします。通常、これらのリカバリーケースの大部分は現在、クレデンシャルマネージャー（iPhoneの場合は主にiCloudキーチェーン）によって処理されています。ユーザーがAppleアカウントにアクセスできる限り、新しいデバイスでログインするために同期されたパスキーを利用できます。しかし、そのクラウドアカウントにアクセスできなくなった場合はどうなるでしょうか？ここで、通常のリカバリーパスが機能します。

ユーザーがログインしようとしているデバイスに秘密鍵がまだあると仮定して、WebAuthnのログインセレモニーを開始するとします。これにより、OS/ブラウザのモーダルが表示され、「別のデバイスでパスキーを使用してログインしてください」とユーザーに求めます。実質的に、ユーザーは自分のアカウントから締め出されます。パスキーが保存されている他のデバイスはありません。ユーザーは非常に混乱します。これを何千人ものユーザーで掛け合わせると、サポートの危機に陥ります。

よくある対応は、フォールバックとしてメールベースのアカウントリセットを追加することです。しかし、これではパスキーの目的が台無しになります。フィッシング可能なリカバリーチャネルを再導入してしまったからです。ユーザーのメールを侵害できる攻撃者は、あなたのフィッシング耐性のあるパスキー実装を完全に迂回できるようになります。

3.2 フィッシングを再導入しないフォールバックの設計#

私たちの意見では、正しいアプローチは階層化されたリカバリーです：

1. 同期パスキーを基本戦略とする：デバイスの紛失がクレデンシャルの紛失を意味しないように、ユーザーが（iCloudキーチェーン、Googleパスワードマネージャー、またはサードパーティのパスキープロバイダー経由で）同期パスキーを作成するようにする。
2. クロスデバイス認証を第2層とする：別のパスキーが利用可能な別のデバイスから、QRコードをスキャンすることでユーザーが認証できるようにする。
3. **身元確認（IDV）**を第3層とする：パスワード/OTPにフォールバックする代わりに、ライブネスチェックを伴う自動化されたIDVを提供する。
4. デジタル検証可能クレデンシャルを第4層とする：これはアカウントリカバリーの最も安全で、プライバシーを保護し、UXに優れたバージョンです。これにより、ユーザーは標準API（例：Digital Credentials API）を使用して、デジタル検証可能クレデンシャル（例：デジタル国民IDやmDL）を使用して身元を確認できます。この技術はかなり新しく、普及率は高くありませんが、今後数か月から数年で重要な役割を果たすでしょう。

一般的に、コストと摩擦の観点から、アカウントリカバリーのどの層を正当化できるかを決定する必要があります。例えば、小売 / Eコマース分野では、最初の2つの層だけを提供し、財務的な理由からフィッシングリスクを受け入れるかもしれません。セキュリティがより重要な他の業界では、層3と層4まで進みます。

各層は複雑さを増します。ユースケースでどの層が必要かを決定し、それらを構築し、すべてのデバイスの組み合わせでテストし、その使用状況を監視する必要があります。これは、初期のWebAuthn統合よりもはるかに多くの作業を伴います。

3.3 ほとんどのチームが間違えること#

ほとんどのチームは、リカバリーを過度に単純化する（パスワードやSMS OTPへのフォールバック）か、過度に複雑化する（すべてのリカバリーにハードウェアセキュリティキーを要求するなど）かのどちらかです。適切なバランスは、脅威モデル、ユーザーベース、および規制要件に依存します。これを間違えると、セキュリティ態勢を損なうか、ユーザーがフローを放棄するほどの摩擦を生み出すことになります。

4. 課題 2：クロスデバイスとクロスエコシステムのエッジケースがパスキーフローを壊す#

ユーザーはクリーンなAppleのみの世界に住んでいるわけではありません。デバイスを切り替え、WindowsとiOSを混在させ、異なるブラウザを使用し、企業が管理する環境で作業します。事前に計画していなければ、そこでパスキーのフローが壊れます。

4.1 エコシステムの断片化は現実である#

パスキーのエコシステムは、3つの主要プラットフォーム（Apple、Google、Microsoft）、複数のブラウザ（Chrome、Safari、Firefox、Edge）、数十のパスキープロバイダー / クレデンシャルマネージャー（1Password、Bitwarden、Dashlaneなど）、そして無数のOS/ブラウザ/デバイスの組み合わせにまたがっています。各組み合わせの動作はわずかに異なる場合があります。例えば：

• AppleはデフォルトでiCloudキーチェーン経由でiOS、iPadOS、macOS間でパスキーを同期しますが、WindowsやAndroidには同期しません。
• GoogleはGoogleパスワードマネージャー経由でAndroidとChrome間で同期しますが、iOSでのエクスペリエンスは異なります（手動で設定する必要があります）。
• Windowsは他のプラットフォームとは大きく異なる独自のパスキー動作を持っています。
• パスワードマネージャーはそれぞれパスキーの作成と選択の処理が異なり、プラットフォーム固有のプロンプトと競合することがあります。

4.2 クロスデバイス認証フロー#

ユーザーがiPhoneでパスキーを作成したが、Windowsラップトップでログインしたい場合、クロスデバイス認証（通常はQRコードとBluetooth経由）を使用できます。このフローは機能しますが、壊れやすいものです：

• 両方のデバイスでBluetoothが有効になっている必要があります。
• バックグラウンドでトンネルが設定されるため、企業のファイアウォールやMDMポリシーが干渉する可能性があります。
• ブラウザ間でUXが劇的に異なります。
• ユーザーはしばしば、何が起こっているのか、なぜQRコードをスキャンしているのか理解していません。

私たちは何千ものデバイスの組み合わせで、これらのエッジケースを直接見てきました。パスキーを自社で構築する場合、これらすべてをテストして処理する必要があります。それができなければ、ユーザーはサポートチームが説明できないエラーに直面することになります。

4.3 ブラウザとOSの不一致#

同じデバイス上でさえ、異なるブラウザは異なる動作をします。macOSのChromeは、macOSのSafariとは異なるパスキーのモーダルを表示します。Firefoxには独自の動作があります。Client HintsとUser Agentの検出は、適切なユーザーに適切なフローを提供するために不可欠になりますが、すべての組み合わせにわたってそれらを正しく解析することは、終わりのないメンテナンスの負担になります。

5. 課題 3：ネイティブアプリがパスキーの複雑さを増大させる#

Webアプリにとって、パスキーのテストとQAはすでに課題です（詳細は「課題 5：プラットフォームの変更がパスキーを密かに破壊する」で取り上げます）。しかし、製品にネイティブのiOSおよびAndroidアプリもある場合、Web専用のチームが直面することのないアーキテクチャ上の決定とプラットフォーム固有の動作により、複雑さは倍増します。

5.1 ネイティブとWebViewの選択#

最初の決定は、パスキーをネイティブに実装するか、WebView経由で実装するかです。各アプローチにはトレードオフがあります：

iOSだけでも、WKWebView、SFSafariViewController、SFAuthenticationSession、ASWebAuthenticationSessionから選択でき、それぞれパスキーサポートの特性が異なります。Androidでは、Chrome Custom Tabsは標準のWebViewとは動作が異なります。これらはWeb専用チームが決して下す必要のない決定であり、それぞれの選択が独自のメンテナンス領域を生み出します。

5.2 ネイティブアプリでのプラットフォーム固有の動作#

アーキテクチャ上の決定を超えて、iOSとAndroidはOSレベルでパスキーを異なる方法で処理します：

• iOSはパスキーをシステムのクレデンシャルマネージャーに深く統合しており、iOSの各バージョンで変更される可能性のある特定の自動入力動作を持っています。
• Androidは、複数のパスキープロバイダーと同時に対話するCredential Manager APIを介してパスキーリクエストをルーティングします。
• エラー状態、タイムアウトの動作、ユーザープロンプトはプラットフォーム間で異なります。同じユーザーのキャンセルでも、WebではNotAllowedErrorとして表面化しますが、iOSではSimpleAuthenticationServices.AuthorizationErrorとして、AndroidのCredential ManagerではUser cancelled the operationとして表面化します。
• 緊急のパスキー回帰テスト（リグレッション）修正を出荷する必要がある場合、アプリストアの審査サイクルが遅延をもたらします。

5.3 QA領域の3倍化#

Webアプリとネイティブアプリの両方を運用している場合、QAの労力は2倍になるだけでなく、3倍になります。Web、iOS、Androidはそれぞれ独立したエンドツーエンドのテストと監視を必要とする別個のパスキー環境として機能します。修正を即座にデプロイできるWebとは異なり、ネイティブアプリの修正はアプリストアの審査サイクルによってブロックされます。

6. 課題 4：普及は技術の問題ではなく、プロダクトの問題である#

「パスキー対応」は「パスキーが使われている」ことを意味しません。展開戦略と測定がなければ、普及率は期待外れに終わり、プロジェクトは内部で失敗というレッテルを貼られることになります。

6.1 なぜ低い普及率がプロジェクトを失敗させるのか#

ユーザーがパスキーに切り替えなければ、プロジェクトはすでに失敗しているということを、パスキー実装が失敗する理由に関する記事で詳しく取り上げました。パスワードが支配的なままであり、SMS OTPのコストは高いままで、フィッシングリスクは継続し、組織は多大なエンジニアリング投資に対する見返りを得られません。

パスキー導入のビジネスケースは強力ですが、それは導入が実際に起こった場合に限られます。素晴らしい技術的実装でパスキーをリリースしたものの、ロールアウトと普及戦略について誰も考えていなかったために、普及率が5%未満に終わった企業を見てきました。

6.2 普及には意図的なプロダクトの取り組みが必要#

パスキーの普及を促進することは、以下を必要とするプロダクトの課題です：

• 段階的な登録：適切なタイミング（例：ログイン成功後、アカウントのセキュリティレビュー中）でパスキーを作成するようにユーザーを誘導する
• 明確なユーザーコミュニケーション：非技術的なユーザーが理解できる言葉で、パスキーとは何か、なぜ優れているのかを説明する
• デバイスを意識したプロンプト：ユーザーのデバイスが実際にパスキーを適切にサポートしている場合にのみパスキー作成を提供し、サポートされていない構成でのフラストレーションのたまる体験を避ける
• 測定インフラストラクチャ：ボトルネックを特定して修正するために、パスキー作成率、ログイン成功率、フォールバック率、放棄率を追跡する

6.3 「良い」普及率とはどのようなものか#

大規模なパスキー展開での私たちの経験に基づくと、企業が目指すべき水準は以下の通りです：

3か月経過後に普及率の数値が「弱い」列のようになっている場合、プロジェクトはトラブルに陥っています。これを測定する分析（アナリティクス）がなければ、それに気づくことすらできません。

7. 課題 5：プラットフォームの変更がパスキーを密かに破壊する#

OSやブラウザのアップデートにより、プロンプト、自動入力の動作、フォールバックフローが変更されます。継続的な監視がなければ、警告なしにリグレッション（退行バグ）やサポートチケットが発生することになります。

私たちは最近、本番環境で発生したWebAuthnエラーの包括的な概要を公開しました。

7.1 なぜパスキーはプラットフォームの変更に特有の影響を受けるのか#

（サーバーが検証する単なる文字列である）パスワードとは異なり、パスキーはオペレーティングシステム、ブラウザ、クレデンシャルマネージャーとの深い統合に依存しています。Appleが新しいiOSバージョンをリリースすると、パスキーの作成プロンプトが違って見えるかもしれません。Chromeが自動入力のロジックを更新すると、ログインフローが壊れるかもしれません。パスワードマネージャーが新バージョンをリリースすると、予想外の方法でパスキーのリクエストをインターセプトし始めるかもしれません。

最近の例の1つはiOS 26.2のバグで、Safari以外のすべてのブラウザ（Chrome、Edge、Firefox）でisUserVerifyingPlatformAuthenticatorAvailable()がfalseを返し、回避策としてgetClientCapabilities()を使用するプラットフォーム認識の検出ロジックが必要になりました。

7.2 監視はオプションではない#

潜在的なすべてのバグを確実に把握し、普及率を追跡するには、認証のオブザーバビリティ（可観測性）スタックを設定する必要があります。少なくとも以下のものを導入することをお勧めします：

• リアルタイムの認証分析：OS、ブラウザ、パスキープロバイダーの組み合わせごとの成功率と失敗率を追跡する
• バージョン認識型の監視：新しいOSやブラウザのバージョンがエラーやフォールバックの急増を引き起こした時に検出する。予期されるエラー（ユーザーの中止がNotAllowedErrorとして表面化）と予期しないエラー（並行処理のバグからのAbortErrorの急増や、Androidアップデート後の新しいCredential Managerのパスキーエラー）を区別する
• アラート：ユーザーがサポートチケットを提出し始める前に通知を受け取る
• 迅速な対応能力：影響を受けるデバイスの組み合わせに対して、迅速に修正をプッシュしたり、パスキーを無効にしたりする機能

これは、ほとんどのチームがインシデントを経験するまで構築しない類の認証分析インフラストラクチャです。インシデントが起きた時には、ユーザーの信頼と内部プロジェクトの信用に対するダメージはすでに発生しています。

7.3 継続的なメンテナンスコスト#

パスキー実装の本当のコストは初期構築ではありません。継続的なメンテナンスです：

• iOS、Android、Windows、macOS、およびすべての主要ブラウザにわたるプラットフォームの変更の監視
• 各アップデートのリグレッションテスト
• ブラウザAPIが変更された場合のフロントエンドSDKの更新
• 成長するパスキープロバイダーのエコシステムとの互換性の維持
• サポートチームへの変更の文書化と伝達

8. パスキーを導入すべき（すべきでない）時期#

これらのDay 2問題を踏まえた上で、いつパスキーを導入すべきで、いつ導入すべきでないかの率直な評価を以下に示します。

8.1 以下の場合はパスキーを導入すべきではありません#

• 明確なフォールバックとリカバリーの戦略がない
• ユーザーが実際に使用するデバイスの組み合わせ全体でテストしていない
• ネイティブアプリがあるが、継続的なプラットフォーム固有のQAの計画がない
• 普及率を測定する分析インフラストラクチャがない
• 継続的なメンテナンスにエンジニアリングリソースをコミットできない
• 適切な計画なしに、単なるコンプライアンスのチェックボックスとしてパスキーを実装しようとしている

適切な計画なしに規制上の理由から全力を挙げることは、コストを著しく押し上げる可能性があります。不適切に実装されたパスキーシステムは、パスキーシステムがないことよりも悪いです。ユーザーの信頼を損ない、サポートのオーバーヘッドを生み出し、社内の関係者にプロジェクトを終了させる理由を与えます。

8.2 以下の場合はパスキーを導入すべきです#

• 上記で説明した5つのDay 2問題すべてについて計画している
• 継続的なロールアウトをサポートするプロダクト、エンジニアリング、セキュリティ、分析の能力がある
• 初期構築だけでなく、継続的なメンテナンスの予算を組んでいる
• 明確な普及目標を持つ段階的なロールアウト戦略がある
• 運用の複雑さを代行してくれるCorbadoのようなパートナーと協力している

8.3 構築するか、購入するか（Build vs. Buy）の決定#

この記事で説明したDay 2問題こそが、多くの企業がパスキーインフラストラクチャを自社で構築するのではなく、購入することを選択するまさにその理由です。WebAuthnサーバーの構築は簡単な部分です。適切なリカバリー、監視、普及分析を備え、何千ものデバイスの組み合わせにわたって本番環境レベルのパスキーシステムを運用することが、デモと実際の展開を分けるものです。

9. CorbadoがパスキーのDay 2問題をどのように解決するか#

Corbadoは、Day 2問題が難しいからこそ存在しています。私たちのプラットフォームが運用の複雑さを処理するため、お客様自身で構築して維持する必要はありません。

9.1 リカバリーとフォールバック#

Corbadoは、適応型セキュリティレベルを備えたすぐに使えるリカバリーフローを提供します。同期パスキー戦略から、クロスデバイス認証、自動化された身元確認まで対応しています。リカバリーロジックは組み込まれており、継続的に更新されます。

9.2 クロスデバイス互換性#

当社のフロントエンドSDKは、何千ものOS、ブラウザ、パスキープロバイダーの組み合わせであらかじめテストされています。デバイスの検出、Conditional UIの処理、フォールバックのルーティングは自動的に行われます。新しいブラウザバージョンで何かが壊れた場合、ユーザーが気づく前に当社のSDKで修正します。

9.3 ネイティブアプリのサポート#

Corbadoは、プラットフォームの違いを抽象化するSDKを使用して、ネイティブおよびWebViewのパスキー実装の両方をサポートしています。お客様はアプリのUXに集中し、iOSとAndroid間のパスキーの配管作業は私たちが処理します。

9.4 普及率分析#

当社の分析ダッシュボードは、パスキー作成率、ログイン成功率、フォールバック率、デバイスレベルの内訳など、重要なすべての指標を追跡します。単なる生データではなく、普及を促進するための実用的なインサイトを得ることができます。

9.5 プラットフォーム変更の監視#

Corbadoは、パスキーに影響を与えるOSとブラウザの変更を継続的に監視しています。当社のSDKはプロアクティブに更新されます。プラットフォームの状況が足元で変化しても、パスキーの展開は安定したままです。

10. 結論#

パスキーが認証のゴールドスタンダードであることは間違いありません。しかし、「パスキー対応」から「大規模で確実に機能するパスキー」への道には、ほとんどのチームが過小評価しているDay 2問題が敷き詰められています。

私たちが取り上げた5つの問題（リカバリー、クロスデバイスのエッジケース、ネイティブアプリの複雑さ、普及率、プラットフォームの変更）は稀なものではありません。これらは、本番環境のパスキー展開における中核的な運用の課題です。これらを無視しても問題は消えません。単にユーザーが先にそれらを発見するだけです。

私の率直な推奨事項は、パスキーを適切に行うノウハウとリソースがないなら、リリースしないでください。プロダクト、エンジニアリング、セキュリティ、分析の能力に投資するか、すでにこれらの問題を解決しているパートナーと協力してください。最悪の結果は、誰もDay 2を計画していなかったためにロールバックされる、中途半端なパスキーの展開です。

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エキスパートに相談する →

よくある質問（FAQ）#

リリース後にパスキープロジェクトが失敗する原因となる、5つの「Day 2」問題とは何ですか？#

5つの運用の問題とは、安全でないリカバリーとフォールバックのフロー、クロスデバイスのエコシステムのエッジケース、ネイティブアプリの複雑さ、低いユーザー普及率、そしてOSやブラウザのアップデートによる密かなリグレッション（退行バグ）です。ほとんどのチームは初期のWebAuthn統合に集中し、これらのリリース後の課題を過小評価しています。これが、多くのパスキープロジェクトがロールバックされたり、社内で密かに放棄されたりする理由です。

iPhoneで登録したWindowsのエンタープライズユーザー向けに、クロスデバイスのパスキー認証をどのように処理すればよいですか？#

ユーザーはQRコードとBluetoothのクロスデバイスフローを介して認証できますが、これには両方のデバイスでBluetoothが有効になっている必要があり、企業のMDMポリシーやファイアウォールによってブロックされる可能性があります。ブラウザ間でUXが大きく異なり、ユーザーはなぜQRコードをスキャンしているのか理解していないことがよくあるため、エンタープライズ展開においては、デバイスを認識したフォールバックルーティングと明確なコミュニケーションが不可欠です。

リリース後にターゲットとし、追跡すべきパスキーの普及率の指標は何ですか？#

強力な普及とは、対象ユーザーのパスキー作成率が60%を超え、全ログインのパスキーログイン率が40%を超えることを意味します。3か月経過後に作成率が10%未満、ログイン率が5%未満の場合は、ロールアウトが失敗していることを示しています。これを測定するには、デバイスおよびOSの組み合わせごとに分類された、作成率、ログイン成功率、フォールバック率、および放棄率を追跡する専用のインフラストラクチャが必要です。

パスキーはモバイルアプリにネイティブで構築すべきですか、それともWebViewを使用すべきですか？#

ネイティブ実装はクラス最高のUXを提供しますが、iOSとAndroidで別々のコードベースが必要となり、プラットフォーム固有のAPI処理と独立したQAパイプラインが必要になります。WebViewのアプローチはWebロジックを共有できますが、WebViewの種類によってパスキーサポートの不一致が生じます。iOSだけでも、WKWebView、SFSafariViewController、ASWebAuthenticationSessionの選択にはそれぞれ異なるパスキーサポート特性があり、アーキテクチャを決定する前にこれらを評価する必要があります。

パスキーのアカウントリカバリーが予想以上に難しく、正しいアプローチとは何ですか？#

メールベースのリセットのような単純化されたリカバリーはフィッシング可能なチャネルを再導入し、ハードウェアセキュリティキーの義務化のような厳格すぎるリカバリーは放棄を生み出します。推奨されるアプローチは階層化です：第1層として同期パスキー、第2層としてクロスデバイスのQRコード認証、第3層としてライブネスチェックを伴う自動化された身元確認、第4層としてデジタル検証可能クレデンシャルです。どの層を実装するかは、脅威モデル、ユーザーベース、および規制要件に依存します。