2．パスキーは「機能」ではなく「エコシステム」

パスキーの必須化に向けた動きが進む中、導入企業には、実装だけでなく展開や運用まで見据えた設計が求められます。実装については、パスキーの技術仕様は標準化され、主要なOSやブラウザでも対応が進んでいます。そのため、パスキーに対応した認証サーバを導入すれば、実装のハードル自体は以前より低くなっています。

一方で、パスキーは単一の認証機能ではありません。自社の認証サーバ、利用者のデバイス、OS、ブラウザやアプリなどのクライアント、クレデンシャルマネージャ（※6）やセキュリティキーが連携して成立するエコシステムです。FIDO Alliance（※7）が提供するPasskey Centralでも、パスキーのエコシステムが示されており、導入に関わる設計、ロールアウト、デザイン、トラブルシューティングなどが整理されています。（※8）（※9）

パスキー導入は自社の認証サーバだけでは完結しません。利用者環境の幅広いバリエーションによる差異や、OS、ブラウザ、クレデンシャルマネージャなどの仕様変更の影響を受けます。

たとえば、OSベンダーのサポート情報でも、パスキー利用時の問題として複数の要因が挙げられています。具体的には、クレデンシャルマネージャ、クロスデバイスサインインにおけるBluetoothの接続状況、画面ロックの状態、手順のタイムアウトなどです。こうした前提条件は、一般利用者にとって理解しにくく、問い合わせ時の切り分けも容易ではありません。（※10）
このため自社で制御できる範囲とできない範囲を見極め、設計と運用を行うことが求められます。

図1：パスキーを支える主な要素

3．導入時に押さえるべき設計ポイント

パスキー導入では、ログイン時の認証だけでなく、登録時の本人確認、追加登録、復旧、削除、退会までを含むアカウントライフサイクル全体を見渡した設計が必要です。例としてweb.devのパスキー導入チェックリストでも、ユーザー体験、セキュリティ、互換性、相互運用性を確認する観点が示されています。（※11）以下、主なポイントを挙げます。

• 1．登録時の本人確認を強く設計する
  登録時の本人確認が不十分だと、攻撃者が本人になりすましてパスキーを登録してしまい、結果として攻撃者に強い認証手段を与えることになります。例えば、マイナンバーカードを利用した公的個人認証や、登録済みの連絡先による確認など、十分な強度を持つ本人確認手段を設計することが重要です。
• 2．復旧導線を登録導線と同じ強度で設計する
  ログインを強化しても、端末紛失や機種変更時の復旧手続きが弱ければ、攻撃者は復旧手続きを狙います。復旧時にも登録時と同等の本人確認を行い、正当な利用者のみがアカウントを利用できるように設計することが重要です。一方、本人確認のうえで本来のアカウントに確実に結びつける難しさがあるため、あらかじめ複数のパスキーを登録できるようにし、復旧そのものの発生を減らす設計も有効です。
• 3．複数のパスキー登録をサポートし、利用者向け管理画面を整備する
  web.devでは、複数のパスキーや複数のプロバイダを利用できるようにすることで、アカウントロックアウトのリスクを下げられると説明されています。管理画面では、登録済みのパスキーを確認、追加、削除できるようにし、どのクレデンシャルマネージャやセキュリティキーで管理されているかを理解できる表示にします。あわせて、パスキーの同期可否、削除時の通知なども考慮します。（※12）
• 4．対応環境を明確にする
  OS、ブラウザ、アプリ、クレデンシャルマネージャの組み合わせは多岐にわたります。対応範囲を広げすぎると、検証、問い合わせ対応、不具合の調査の負荷が大きくなります。そのため、サポート対象とする利用環境を明確に定め、利用者にも分かりやすく案内することが重要です。
• 5．段階的に導入し、利用状況を可視化する
  必須化を急ぎすぎると、例外対応や代替手段の設計が不十分になり、導入後の混乱につながります。全面展開の前に、まずは管理者操作、重要情報の変更、高リスク取引など、効果が大きい領域から適用することが有効です。導入後も、登録率、利用率、失敗率、復旧件数、問い合わせ件数などを確認しながら、UI/UXや運用を継続的に改善します。（※13）

パスキー導入の成否は、認証方式そのものだけでなく、その周辺にある登録、復旧、例外対応、運用設計の品質にも左右されます。パスキーを導入すれば対策が完了すると考えるのではなく、登録、復旧、監視、UI/UXまで幅広い視野で設計する必要があります。

図2：パスキー導入で考慮すべきアカウントライフサイクル

4．パスキー時代の認証基盤に求められる総合力

パスキー時代の認証基盤に求められるのは、認証方式を追加する力だけではありません。アカウントライフサイクル、アプリケーション、インフラ、運用、UI/UXを横断して設計し、継続的に改善する総合力です。

そのためには、本人確認、登録、認証、復旧、退会までを一連の流れとして捉える必要があります。また、認証サーバだけでなく、アプリケーション、ログ、監視、セキュリティ運用、サポート窓口をつなぎ、障害時や仕様変更時に何が起きているかを追跡できる設計が求められます。OS、ブラウザ、クレデンシャルマネージャの仕様変更を継続的に把握することも欠かせません。

認証はサービスの入口であり、利用者が本人として安全にサービスへ到達できるかを左右する重要な接点です。パスキーの登録、選択、利用、復旧の導線が分かりにくい場合、正当な利用者がサービスを利用できない、問い合わせが増える、弱い代替手段に流れるといった問題につながります。画面、文言、導線、サポート案内を一体で設計し、登録率、利用率、失敗率、問い合わせ内容などを確認しながら改善を続けることが重要です。

パスキー導入は、単なる認証機能の追加ではありません。変化し続けるエコシステムに対応しながら、認証基盤を継続的に改善していく取り組みです。