パスキー運用のDay‑2問題：ローンチ後の5つのリスク

1. はじめに：ローンチ後のパスキーのリスク#

パスキーを導入してはいけません。

少なくとも、何がなんでも導入すべきではありませんし、適切に行うためのリソースがないのであれば、なおさらです。

たしかに、パスキーはこの10年におけるコンシューマー向け認証技術の中で最高の出来事です。 フィッシングを撲滅でき、UX（ユーザー体験）を劇的に向上させることができます。しかし、間違ったやり方で導入されたパスキーは、多くの害をもたらす可能性もあります。

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

この記事では、パスキープロジェクトを頓挫させがちな 5つの「Day 2」問題について解説します。これらすべてを解決できなければ、パスキーを出荷する準備はできていないと言えるでしょう。逆にこれらを解決できれば、パスワードが決して提供できなかった、より安全で使いやすい認証システムを構築できるはずです。

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

エンジニアリングの世界では、「Day 1」は構築して出荷（ローンチ）する段階を指します。「Day 2」は、出荷したものを運用し、保守し、拡張していく段階です。パスキーにおいて、Day 1 は比較的シンプルです。

• WebAuthn サーバーを統合する
• フロントエンドのフローを追加してローンチする

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

プロジェクトが失敗するのは Day 2 です。それは、実際のユーザーが、現実のエッジケースを含む実際のデバイスを使って、あなたのパスキーシステムと対話する瞬間です。MacBook 上では完璧に動作していたピカピカのデモが、企業のプロキシ環境下にある Windows ノートPCの Chrome ブラウザでは動かないことが発覚する瞬間です。そして、サポートチームの元に「ログインできなくなった」という問い合わせが殺到する瞬間でもあります。

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

今回取り上げる 5つの Day 2 問題は以下の通りです。

• 課題 1：リカバリとフォールバックのセキュリティ確保が難しい
• 課題 2：クロスデバイスやエコシステム間のエッジケースがフローを壊す
• 課題 3：ネイティブアプリが複雑さを倍増させる
• 課題 4：普及（Adoption）は技術ではなくプロダクトの問題
• 課題 5：プラットフォームの変更はパスキーを静かに破壊する

3. 課題 1：リカバリとフォールバックのセキュリティ確保が難しい#

リカバリとフォールバックを適切に設計しないと、大規模なユーザーの締め出し（ロックアウト）を招くか、排除したはずのフィッシングに対して脆弱なフローを再び導入してしまうことになります。

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

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

仮に、ログインしようとしているデバイスに秘密鍵がまだ残っていると想定して、WebAuthn のログインフローを開始したとします。すると、OS やブラウザのモーダル（ダイアログ）が表示され、「別のデバイスにあるパスキーでログインしてください」と求められます。基本的に、この時点でユーザーはアカウントから締め出された状態になります。パスキーが保存されている「別のデバイス」は手元にないのですから。ユーザーは大混乱に陥ります。これが数千人のユーザーに起これば、サポートの危機です。

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

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

私たちの考えでは、正しいアプローチは「階層化されたリカバリ（Layered Recovery）」です。

1. 同期されるパスキー（Synced Passkeys） を主要戦略とする：デバイスを紛失しても認証情報まで失わないよう、ユーザーに同期されるパスキー（iCloud キーチェーン、Google パスワードマネージャー、またはサードパーティのパスキープロバイダー経由）を作成してもらいます。
2. クロスデバイス認証 を第2の層とする：QRコードをスキャンすることで、パスキーが利用可能な別のデバイスを使って認証できるようにします。
3. 本人確認（IDV） を第3の層とする：パスワードやOTP（ワンタイムパスワード）にフォールバックする代わりに、生体検知（Liveness check）を含む自動化された IDV を提供します。
4. デジタル検証可能な認証情報（Verifiable Credentials） を第4の層とする：これは最も安全でプライバシー保護に優れ、かつ UX フレンドリーなアカウントリカバリ方法です。ユーザーは自身のデジタルな検証可能な認証情報（例：デジタル国民IDやmDL：モバイル運転免許証）を使用し、標準 API（例：Digital Credentials API）を通じて本人確認を行います。この技術はまだ新しく普及率は高くありませんが、今後数ヶ月から数年の間に主要な役割を果たすようになるでしょう。

一般的に、コストと摩擦（Friction）の観点から、どのアカウントリカバリ層まで実装するかを判断する必要があります。たとえば、小売や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 ノートPCでログインしたい場合、クロスデバイス認証（通常はQRコードと Bluetooth を使用）を利用できます。このフローは機能しますが、壊れやすいものです。

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

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

4.3 ブラウザと OS の不整合#

同じデバイス上であっても、ブラウザが異なれば挙動も異なります。macOS の Chrome は、macOS の Safari とは異なるパスキーのモーダルを表示します。Firefox には独自の挙動があります。Client Hints とユーザーエージェント検出は、適切なユーザーに適切なフローを提供するために不可欠ですが、すべての組み合わせでこれらを正しく解析し続けることは、終わりのない保守負担となります。

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 となります。クロスプラットフォームのエラーマッピング完全版については、WebAuthn errors in production を参照してください。
• アプリストアの審査サイクルがあるため、パスキーのリグレッション（退行バグ）に対して緊急修正を出荷したい場合に遅れが生じます。

5.3 3倍になる QA の負担#

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

6. 課題 4：普及（Adoption）は技術ではなくプロダクトの問題#

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

6.1 なぜ普及率の低さがプロジェクトを殺すのか#

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

パスキー採用のビジネスケースは強力ですが、それは実際に採用（Adoption）が進んだ場合の話です。私たちは、優れた技術実装でパスキーをローンチしたにもかかわらず、ロールアウトと採用戦略を誰も考えていなかったために、普及率が 5% 未満にとどまった企業を見てきました。

6.2 普及には意図的なプロダクトワークが必要#

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

• 段階的な登録（Progressive enrollment）：適切なタイミング（例：ログイン成功後やアカウントセキュリティ設定時）でパスキーを作成するようユーザーを誘導する。
• 明確なユーザーコミュニケーション：パスキーとは何か、なぜ優れているのかを、技術に詳しくないユーザーにもわかる言葉で説明する。
• デバイスを意識したプロンプト：ユーザーのデバイスが実際にパスキーを適切にサポートしている場合にのみパスキー作成を提案し、未対応の構成でのイライラする体験を避ける。
• 測定インフラ：パスキー作成率、ログイン成功率、フォールバック率、離脱率を追跡し、ボトルネックを特定して修正する。

6.3 「良い」普及率とは#

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

3ヶ月経過後の普及率が「低い」列のような数字であれば、プロジェクトは危機的状況です。これを測定するアナリティクスがなければ、危機にあることすら気づかないでしょう。

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

OS やブラウザのアップデートは、プロンプト、オートフィルの挙動、フォールバックフローを変更します。継続的な監視を行っていないと、警告なしにリグレッション（機能退行）やサポートチケットが発生します。

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

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

サーバーが文字列を検証するだけのパスワードとは異なり、パスキーはオペレーティングシステム、ブラウザ、クレデンシャルマネージャーとの深い統合に依存しています。Apple が新しい iOS バージョンを出荷すると、パスキー作成のプロンプトの見た目が変わるかもしれません。Chrome がオートフィルロジックを更新すると、ログインフローが壊れるかもしれません。パスワードマネージャーが新バージョンをリリースすると、予期せぬ方法でパスキーリクエストへの割り込みを始めるかもしれません。

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

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

潜在的なバグにすべて気付き、普及状況を追跡するためには、認証の可観測性（Observability）スタックをセットアップする必要があります。少なくとも以下を導入することをお勧めします。

• リアルタイム認証アナリティクス：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 は、適応型セキュリティレベルを備えたリカバリフローを標準で提供します。同期パスキー戦略からクロスデバイス認証、自動化された本人確認（Identity Verification）まで対応しています。リカバリロジックは組み込まれており、継続的に更新されます。

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

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

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

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

9.4 普及状況のアナリティクス#

私たちのアナリティクスダッシュボードは、重要なあらゆる指標を追跡します。パスキー作成率、ログイン成功率、フォールバック率、デバイスレベルの内訳などです。単なる生データではなく、普及を促進するための実用的なインサイトが得られます。

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

Corbado は、パスキーに影響を与える OS やブラウザの変更を継続的に監視しています。SDK は先回りして更新されます。プラットフォームの状況が足元で変化しても、あなたのパスキーデプロイメントは安定したままです。

10. 結論#

パスキーは認証のゴールドスタンダードです。そこに疑いの余地はありません。しかし、「パスキーに対応している」状態から「パスキーが大規模に安定稼働している」状態への道のりは、多くのチームが過小評価している Day 2 問題で舗装されています。

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

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