New: Passkey Benchmark 2026 - 8 production KPIs to compare your passkey rolloutcompare your passkey rollout
概要に戻る

パスキー:内製と購入の比較ガイド

パスキーソリューションは内製すべきか、購入すべきか?DIYパスキーとパスキーベンダーソリューション(SaaSおよびオンプレミス)のメリット・デメリット、課題、コスト、ベストプラクティスを解説します。

Vincent Delitz
Vincent Delitz

作成日: 2025年3月7日

更新日: 2026年5月28日

パスキー:内製と購入の比較ガイド

このページは自動翻訳されています。英語の原文は こちら.

パスキー内製・購入ガイド全文のダウンロード#

パスキー内製・購入ガイドの完全版を無料ダウンロードして、すべてのインサイトにアクセスしてください。

  • ✅ Adidas、Woolworths、Mitsubishiなどのチームからのリクエストに基づき作成
  • ✅ 購入と内製のどちらを決定するかを判断するための、構成要素とコストモデルの完全なリスト
  • ✅ 実用的な50ページの意思決定フレームワーク

パスキーソリューションは購入すべきか、内製すべきか?

内製・購入ガイド完全版のダウンロード

DIYとベンダーソリューション(SaaSおよびオンプレミス)の比較、主な課題、コスト、ベストプラクティスなど、パスキー導入のための完全なチェックリストを入手してください。

内製・購入ガイド完全版のダウンロード

内製・購入ガイドの無料ダウンロード

重要なポイント
  • ほとんどの大規模な消費者向け導入において、パスキーベンダーのソリューションを購入する方が、社内で構築するよりも迅速に導入でき、TCO(総所有コスト)を抑え、高い普及率を実現できます。
  • パスワードの廃止を実現可能にするには、アクティブユーザーの50〜80%という普及の限界値に達する必要があり、普及促進ツールが内製か購入かを決定する決定的な要因となります。
  • パスワードログインの27%以上が失敗するのに対し、パスキー認証は95〜97%の成功率を達成し、eコマースや小売業におけるコンバージョン率の向上に直結します。
  • パスキーは、パスワードとSMS MFAの組み合わせに比べて3倍〜5倍の速度向上を実現し、ユーザー満足度の向上と継続的な利用をもたらします。
  • オープンソースのWebAuthnライブラリは出発点にはなりますが、エンタープライズレベルのセキュリティ、最適化されたUX、そして大規模な導入に必要な普及促進機能が不足しています。

1. 動機:パスキー認証ソリューションは購入すべきか、内製すべきか?#

パスキーの独自実装というアイデアは魅力的に聞こえます。完全な制御、カスタマイズされた統合、ベンダーロックインの排除などです。結局のところ、FIDO2はオープンスタンダードに基づいており、WebAuthnのコードの最初の数行を書くのは簡単そうに見えます。本当にそれほど難しいのでしょうか?

しかし、複雑さが始まるのはまさにここからです。特に、以下のような業界で数百万人のユーザーを抱える大規模な消費者向けの導入シナリオを計画している場合はなおさらです。

  • 銀行・金融サービス(例:オンラインバンキング決済、フィンテック)
  • 政府・公共サービス(例:市民ポータル、税務・社会保障プラットフォーム)
  • 保険・医療(例:患者ポータル、デジタル保険プラットフォーム)
  • eコマース・小売(例:マーケットプレイス、ロイヤルティプログラム)
  • 通信・公益事業(例:モバイル通信キャリア、エネルギープロバイダー)
  • 旅行・ホスピタリティ(例:航空会社のアカウント、ホテルのロイヤルティプログラム)

本当の課題は、最初のパスキーログインが成功した後に始まり、パスキーソリューションを実装している最中に明らかになることがよくあります。突然、奇妙なエッジケース、ユーザーの混乱を招くエラー、パスキーが利用できないことによるユーザーのロックアウトの可能性などが現れます。簡単だと思われていた統合が、数か月から数年におよぶ開発の労力、予期せぬメンテナンスコスト、そして潜在的なパスキープロジェクトの失敗に変わってしまうのです。

しかし、特定の組織や特定の要件においては、独自のソリューションを構築することが正しい選択となる場合もあります。私たちはこれまでに数十の組織とパスキーの実装計画について話し合い、実際に一部の組織の導入をハンズオンでサポートしてきました。このガイドは、Do-It-Yourself(DIY)のアプローチが意味を持つケースと、実績のあるパスキープロバイダーを選択する方が賢明な判断となるケースを見極めるのに役立ちます。

このパスキー内製・購入ガイドでは、以下の質問にお答えします。

  1. パスキーを実装し、パスワードレスを実現するにはどのようなコンポーネントが必要か?
  2. パスキーを社内で実装すべきか、それとも外部のパスキーベンダーを利用すべきか?
  3. オープンソースライブラリがある中で、パスキーベンダーを利用するメリットは何か?
  4. パスキーソリューションを構築する上での最大の課題は何か?
  5. パスキーを社内で実装する際のリスクは何か?

2. 前提条件:なぜパスキーが新しい標準ログインなのか#

パスワードは時代遅れで、安全性が低く、イライラするものです。パスキーはフィッシングのリスクを排除し、ユーザーエクスペリエンスを向上させ、認証を簡素化します。これにより、パスキーは安全なログインの新しい標準となっています。社内で構築する場合でも、外部ソリューションを使用する場合でも、パスキーの統合はセキュリティとユーザビリティの大きなアップグレードとなります。

Googleは、使いやすさやスピードを前面に押し出すことがユーザーの共感を呼び、効果的であることを発見しました。人々は概してサインインに不満を抱いているため、プロセスを簡単かつ迅速にするものはすべてプラスに働きます。

これらのセキュリティ上の利点に加えて、パスキーによって運用コストを大幅に削減できる可能性があります。ユーザーに送信されるSMS OTPの数を減らすことができ、ユーザーベースが大きい場合はそのコストが膨大に積み重なります。さらに、パスワードやMFAの復旧がカスタマーサポートチームに与える負担も排除できるコスト要因です。

それに加えて、パスキーはユーザーのログイン成功率とログイン時間を改善し、最終的にコンバージョン率の向上につながります。これは、eコマース小売旅行などの業界においてトップラインの成長を牽引する主要な推進力となります。

3. パスワードレスへの道のり:パスキーはどのように機能するのか?#

パスキーの導入を検討している多くの組織にとっての最終的な目標は、完全にパスワードレスに移行することです。この目標を達成するには、通常、完了しなければならない4つのフェーズがあります。これらのフェーズが進行する速度は、組織の技術的能力、ログインパターン、ユーザーベースに大きく依存します。場合によっては、より安全な認証の導入を求める公的な圧力や財政的な制約などの外部要因も影響する可能性があります。

パスキーの統合はパスキープロジェクトを成功させるための1つのステップに過ぎないため、これら4つのフェーズを順を追って説明しましょう。

3.1 フェーズ1:パスキーの統合#

完全なパスワードレスシステムへの移行における最初のステップは、ログイン方法としてパスキーを統合することです。この段階では、まだパスキーを導入していないユーザーでもアカウントにアクセスできるように、パスワードやその他の認証方法がフォールバックとして残されます。統合を成功させるには、既存のログインフローやセキュリティポリシーとのシームレスな互換性が必要です。組織は、パスキーの作成をシンプルにすることに重点を置き、技術的知識の有無に関わらず、ユーザーが摩擦なく新しい認証方法を採用できるようにする必要があります。

Igor Gjorgjioski Testimonial

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

3.2 フェーズ2:パスキー普及率の向上#

パスキーが統合された後の次の課題は、ユーザーへのパスキーの普及を促進することです。多くの組織はこのフェーズの重要性を過小評価していますが、ユーザーの広範な普及がなければ、パスキープロジェクトは失敗する可能性が高くなります。目標は、可能な限り多くのユーザーにパスキーの作成と使用を促し、理想的にはそれをデフォルトのログイン方法にすることです。

普及を促進するための主要な戦術には、積極的なユーザー教育、パスキーの作成を促すUIナッジ、切り替えを行ったユーザーに報いるインセンティブプログラムなどが含まれます。組織は、次のフェーズに進む前に、アクティブユーザーの50〜80%がパスキーを利用するといった、普及の限界値を設定する必要があります。普及が重要である理由についてより深く理解するには、普及率の低さがパスキープロジェクトを危険にさらす理由に関する詳細な記事を参照してください。

3.3 フェーズ3:パスワードの廃止#

パスキーの普及がクリティカルマスに達すると、組織はパスワードの段階的な廃止を開始することができます。ただし、時期尚早にパスワードを削除したり、慎重な計画なしに削除したりすると、ユーザビリティの問題やサポートリクエストの増加につながる可能性があります。段階的なアプローチを推奨します。

  • ユーザーが継続的にパスキーで認証しているアカウントから、パスワードの削除を開始します。
  • 早期導入者向けに、アカウント設定でパスワードを削除するオプションを提供します。
  • データに基づいたインサイトを利用して、完全なパスワードレス移行の準備ができているユーザーを特定します。たとえば、複数のデバイスで複数のパスキーを登録しているユーザーを、パスワード廃止の優先対象とすることができます。
  • ユーザーの信頼を構築するために、パスワード廃止の利点を積極的にコミュニケーションします。

ユーザーを完全なパスワードレス認証へと戦略的に導くことで、組織はユーザーエクスペリエンスを損なうことなくセキュリティを最大化できます。

3.4 フェーズ4:アカウント復旧の自動化#

パスワードが廃止されると、アカウント復旧メカニズムは堅牢で安全なものでなければなりません。従来の復旧方法は、サポートチケットやメールによるリセットなどの手作業による介入に依存することが多く、これらはセキュリティリスクと運用コストをもたらす可能性があります。組織は、ユーザーエクスペリエンスを向上させながらセキュリティを維持する、最新のセルフサービスによるアカウント復旧ソリューションを実装する必要があります。

自動化されたアカウント復旧の重要な要素には、以下が含まれます。

  • ライブネスチェック(Liveness checks):ユーザーが物理的に存在していることを確認し、不正なアカウントの乗っ取りを防止します。
  • 身元確認(ID verification)政府発行の身分証明書や生体認証を活用して身元を確認します。
  • フォールバックパスキー:ユーザーの別のデバイスに保存されているバックアップパスキーを使用して、アカウントを復旧できるようにします。

多くの組織は、コストを削減し、ユーザビリティを向上させるために、パスワードレスへの移行とは独立して、自動化された復旧プロセスにすでに投資しています。しかし、パスキー主導のエコシステムにおいては、これらのメカニズムはセキュリティを維持し、摩擦を減らすためにさらに重要になります。

これら4つのフェーズに基づいて、購入か内製かの決定を評価するお手伝いをします。したがって、パスキープロジェクトの長期的な成功のためには、すべてのフェーズを念頭に置くことが非常に重要であり、単にパスキーを統合するだけではありません(統合自体を目標とすることもできますが、それではパスキーの可能性を十分に活かしきれません)。

4. 適切なパスキーへのアプローチを決定する方法#

DIYと外部のパスキーソリューションのどちらを選択するかは、企業の技術リソース、セキュリティの優先順位、導入の規模、長期的なパスキー戦略によって異なります。次のセクションでは、最適な決定を下すための重要な側面について詳しく説明します。

以下の表は、評価が必要なさまざまな基準を示しています。どちらの説明に傾いているかに基づいて、異なるポイントが提供されます。

評価マトリックスの使用方法:

各基準について、企業がよりシンプルなソリューションを必要としているか、それともより手の込んだソリューションを必要としているかを選択します。

  • あなたのケースにおける複雑さが最も低く、左側の説明により一致する回答には1ポイントを割り当てます。
  • あなたの回答が右側の最も複雑な説明により一致する各カテゴリには5ポイントを割り当てます。
  • 確信が持てない場合は、中立的な選択肢として3ポイントを使用してください。

パスキー内製・購入ガイド全文のダウンロード#

パスキー内製・購入ガイドの完全版を無料ダウンロードして、すべての評価基準にアクセスしてください。

パスキーソリューションは購入すべきか、内製すべきか?

内製・購入ガイド完全版のダウンロード

DIYとベンダーソリューション(SaaSおよびオンプレミス)の比較、主な課題、コスト、ベストプラクティスなど、パスキー導入のための完全なチェックリストを入手してください。

内製・購入ガイド完全版のダウンロード

内製・購入ガイドの無料ダウンロード

5. このガイドの効果的な使用方法#

パスキーソリューションを内製するか購入するかを決定する際には、パスキー展開の単一のフェーズだけでなく、プロセス全体に目を向けることが重要です。短期的にはパスキーをMVPとして提供することが優先される場合でも、長期的な影響、特に普及の推進について予測しておく必要があります。以下では、普及が他のほとんどの要素よりも重要である理由を強調しながら、このガイドの使用方法と結果の解釈について推奨事項を示します。

5.1 成功の最大の要因として普及に焦点を当てる#

パスキーソリューションがどれほど高度であっても、ユーザーがパスキーを作成し、ログインに使用して普及させなければ、プロジェクト全体がリスクにさらされます。私たちの経験では、組織はユーザーをパスワードから移行させるために必要な労力を過小評価しがちです。技術的なレベルでパスキーをシームレスに実装したとしても、普及率が低いと以下の結果を招きます。

  • パスワードへの継続的な依存により、パスキーのセキュリティ上の利点が損なわれます。
  • 最小限のROI。パスワードリセットの減少やSMS OTPの削減によるコスト削減は、ログイン時のパスキーの大幅な使用にかかっているためです。
  • ほとんどのサインインが引き続き従来の方法で行われ、少数のユーザーのみがパスキーを使用する場合、分断されたユーザーエクスペリエンスが発生します。

パスワードの削減または完全な廃止に向けた有意義な前進を図るには、通常、ユーザーベースの50%、あるいは80%以上という高い普及率が必要です。GoogleやAmazonのような組織は、明確な普及目標を設定し、A/Bテスト、ユーザー教育キャンペーン、UIナッジを体系的に実施して、パスキーが広く受け入れられるようにしています。普及に向けたこの集中的な取り組みは任意ではありません。パスキーの導入を単なる機能から目に見える競争上の優位性へと変えるのがこの取り組みなのです。

5.2 ガイドを全体的に、またはフェーズごとに使用する#

このガイドは、ジャーニーのあらゆる段階でパスキーの実装に関する情報に基づいた意思決定を行えるように設計されています。

  1. **フェーズ1(パスキーの統合):**パスキーの導入を検討しており、どのように統合するかを考えている段階であれば、パスキー統合のための内製 vs 購入の基準に焦点を当てます。
  2. **フェーズ2(普及率の向上):**パスキーを単なる機能以上のものにしたい場合は、早い段階でユーザーの普及を促進する計画を立ててください。初期実装よりも大幅に多くの技術投資が必要になることが多いため、MVPであっても同様です。
  3. **フェーズ3(パスワードの廃止):**パスワードの排除が長期的な戦略目標である場合は、最終的なステップを念頭に置いてアーキテクチャとユーザーフローを設計してください。
  4. **フェーズ4(アカウント復旧の自動化):**現在完全にパスワードレスに移行する準備ができていなくても、将来の障害を避けるために、パスキーのアプローチを堅牢でシームレスな復旧へと進化させられるようにしてください。

このうち、フェーズ2(普及率の向上)が最も重要です。各セクションを個別に評価することもできますが、長期的な成功とROIは、最初から普及の促進をどれほど真剣に取り組むかにかかっていることが多い点を覚えておいてください。

5.3 主要なステークホルダーを巻き込み、普及目標について合意する#

パスキー実装を決定する初期段階にある場合は、評価マトリックスの最初のセクション(パスキーの統合)から始め、経営陣、IT部門、プロダクトオーナー、その他の主要な意思決定者と記入してください。以下のように自問してください。

  1. 希望するパスキーのログイン率はどの程度か? 5%で実現可能性を証明できれば十分なのか、それともパスキーが成功したと見なすには50〜80%が必要なのか?
  2. 数か月にわたるA/Bテストの実施、最適化キャンペーンの実行、教育用資料の作成、ユーザーフローの継続的な改善を行うための予算と経営陣の賛同があるか? ユーザーがパスキーを理解し、切り替えたいと思うようにするためです。必要なすべてのレポート、分析、テストを実装するのに十分なエンジニアリング能力があるか? これらの目標を達成できるだけの頻度でリリースできるか?
  3. 長期的なビジョンは何か? パスワードの廃止を目指すのか、それとも単に代替手段を提供するだけなのか?

これらの質問に前もって答えておくことで、パスキープロジェクトが行き止まりになるのを防ぐことができます。普及の計画を怠った組織は、何年にもわたってパスワードから抜け出せず、セキュリティとユーザーエクスペリエンス戦略全体の価値を低下させることになりがちです。

5.4 「中立」から遠ざかるほど、ベンダーの利用が理にかなうようになる#

マトリックス全体を通じて、各評価基準は**複雑さが最も低い(1)から複雑さが最も高い(5)までのどこかに該当します。回答が中立ゾーン(3)**を越えて複雑な方向にシフトするほど、専門のパスキーベンダーを利用するべき強い理由となります。

  • 高度なフォールバック手法、厳格なコンプライアンス、詳細な分析、マルチデバイス対応UXなどの高い複雑性要件は、エンジニアリングとメンテナンスの負担を倍増させます。
  • パスキーの高い普及率を迅速に達成したり、パスワードを廃止したりするなど、普及の促進を強く重視するには、通常、十分にテストされたユーザーフロー、詳細なテレメトリ、および構造化されたナッジが必要です。

これらの要因は、技術的にも組織的にも、社内チームを圧倒する可能性があります。マネージドパスキーソリューションは、DIYアプローチよりもはるかに早く普及を促進するために、実証済みのベストプラクティス、迅速なアップデート、実世界の専門知識を提供できることがよくあります。

5.5. Corbadoの視点:ベンダーの方が優れた選択肢となる場合#

パスキーのスペシャリストとして、私たちCorbadoは強い見解を持っています。パスキーがロードマップにあり、普及を積極的に推進する最先端の実装を求めている場合、Corbado Connectは規模の大きい複雑さに対処するのに役立ちます。その理由は以下の通りです。

ソリューションに組み込まれた普及推進機能: 当社のプラットフォームは、スマートなナッジ、分析、継続的なA/Bテストを通じてユーザーのオプトインを最大化するように設計されており、これによりコスト削減も促進されます。

次のステップ:

  1. 評価マトリックスの関連する各セクションに記入する - 当面および長期的な目標の両方を考慮します。
  2. 意思決定において普及を優先する - 明確な普及目標とそれを達成するためのリソースについてステークホルダーと足並みを揃えます。
  3. 複雑さと普及の野望を理解したら、社内ソリューションとベンダーソリューションのTCOを比較し、社内プロセスを進めて内製か購入かを評価します。

  1. 戦略的目標が、技術的課題と普及の課題の両方に効果的に対処する完全マネージドプラットフォームを指し示している場合は、パスキーの専門家(Corbadoなど)に相談してください

パスキーに包括的にアプローチし、普及を主要な目標の1つにすることで、最高の結果を得ることができます。それはつまり、より強力なセキュリティ、簡素化されたログイン、そしてパスワードレスな未来への確実な道のりです。クライアントが高いパスキー普及率を達成するために私たちがどのように支援しているか、Corbado Connectについての詳細に興味がございましたら、いつでもご相談をお受けいたします。

6. パスキー導入の成功を測定する方法#

「内製か購入か?」という質問に答えるための適切なアプローチの決定方法について説明しました。次は、パスキー導入の成功をどのように評価するかを分析します。そのため、パスキープロジェクトの入力KPIと出力KPIを定義します。

6.1 重要なパスキー入力KPIとは?#

入力KPIは、パスキーの初期段階の普及率と、広く使用されるために必要な条件が確立されているかどうかを追跡するのに役立ちます。これらの指標は実際のログイン行動に先行するものですが、有意義な普及を可能にし、展開を最適化するために重要です。

KPI定義重要である理由測定方法ベンチマーク
パスキー受け入れ率(Passkey Acceptance Rate)ログインに成功した後(サインイン後)に「ナッジ」(パスキーの設定を促すプロンプトまたは提案)を受け取り、パスキーの作成を選択したユーザーの割合。このKPIは、サインイン後のプロンプトに対するユーザーの反応を具体的に測定し、パスキー作成を促進するナッジメッセージの有効性を強調します。ユーザーは通常、アカウントや資格情報管理の設定から主体的にパスキーを作成しないため、このアプローチは最先端と見なされています。その代わり、ログイン直後に直接プロンプトが表示されると最も成功しやすくなるため、ナッジがパスキー作成の主要な推進力となります。最初のナッジとその後のナッジでは割合が低下するため、必ず区別してください。高い受け入れ率は、ユーザーへの説得とナッジの設計が成功していることを示します。割合が低い場合は、摩擦、メッセージの不明確さ、またはユーザーの躊躇があることを示します。計算式:(ナッジ後にパスキー作成を完了したユーザー数)÷(ナッジにさらされたユーザー数)。OS / ブラウザ / デバイスごとにセグメント化します。初回のナッジで50%〜75%、モバイルでは複数のナッジにわたって最大85%。デスクトップではこれより低くなります。表現や実装に大きく依存します。
パスキー作成成功率(Passkey Creation Success Rate)パスキー登録のセレモニーを開始し、正常に完了した(つまり放棄しなかった)ユーザーの割合。わかりにくいUX、技術的な問題、またはユーザーの心変わりなどが原因で、作成の途中でドロップアウトしたユーザーの数を示します。計算式:(完了したパスキー登録数)÷(登録試行回数)。OS / ブラウザ / デバイスごとに失敗ポイントを分析します。100%に近い値。
作成されたパスキーの数(Number of Created Passkeys)特定の期間(日次、週次、月次)に新しく作成されたパスキーの累積数。多くの場合、半出力KPIと見なされる未加工の普及率の指標。パスキー使用のと、将来パスワードからのログイン移行の可能性を反映します。計算式:OS、ブラウザ、デバイスのカテゴリ全体で新しく登録されたすべてのパスキーの合計。時間の経過に伴う成長傾向を監視します。絶対数自体には意味がなく、ユーザーベースのサイズに依存します。完全に展開された時点で、1日あたり相当な数。

これらの入力KPIは、将来のパスキー普及の先行指標として機能し、組織がユーザー教育、UXフロー、技術的な実装を微調整することを可能にします。

6.2 重要なパスキー出力KPI / OKRとは?#

出力KPI(OKR)は、ユーザーの行動、運用の改善、およびビジネスへの影響を評価することにより、パスキー普及の実際の成功を測定します。これらの指標は、パスキー展開の現実世界での有効性を反映しています。パスキーログイン率は、実際のパスキーの普及と使用状況を直接反映するため、中核的な出力KPIとなります。パスキーログイン率の上昇は、オンボーディングの成功と、ユーザーがレガシーな認証方法よりもパスキーを継続して好んでいることを示しています。

KPI定義重要である理由測定方法ベンチマーク
ユーザーアクティベーション率(User Activation Rate)(時間の経過とともに複数回表示される可能性のある)ナッジを少なくとも1回見たすべてのユーザーのうち、最終的に少なくとも1つのパスキーを作成したユーザーの割合。複数のナッジにわたる、全体的なパスキーのオンボーディングの成功を測定します。ユーザーは最初のナッジを拒否しても、後で変換される可能性があります。計算式:(1つ以上のパスキーを作成したユニークユーザー数)÷(少なくとも1回のナッジが表示されたユニークユーザー数)。OS、ブラウザ、デバイスごとにセグメント化して、最終的に誰がパスキーを採用するかを確認します。展開が拡大したら、削除されたパスキーもここに反映する必要があります。12か月で50%以上。パスキーログイン率はユーザーアクティベーション率に収束します。これはユーザー構成によって異なります。
パスキーログイン率(Passkey Login Rate)レガシーな方法(パスワード、SMS OTPなど)ではなく、パスキーを使用して完了したすべてのログインイベントの割合。実際のパスキー使用頻度を示します。ログイン率が常に低い場合は、ユーザーが最初にパスキーを作成したにもかかわらず、パスワードを好むか元に戻っていること、アクティベーション率が低いこと(高いログイン率はアクティベーション自体が高い場合にのみ発生するため)、または既存のパスキーを自動的に活用しない最適ではないログイン実装によるものであることを示しています。計算式:(パスキーログイン数)÷(合計ログイン数)。OS / ブラウザ / デバイスまたはユーザーグループごとにセグメント化します。これは、問題のあるプラットフォームやパスキー使用率の低い属性を特定するのに役立ちます。数週間で20%以上、12か月で50%以上。(実装方法に大きく依存します)
パスキーログイン成功率(Passkey Login Success Rate)フォールバックに戻ることなく成功裏に終わったパスキーログイン試行の割合。パスキーフロー内の摩擦を明らかにします。割合が低い場合は、ユーザーの混乱、環境の制約、またはデバイスの互換性の問題が原因でフォールバックにつながっている可能性があります。ユーザーがデバイスを切り替えたり、接続されていないデバイスからログインしようとしたりするため、100%にならないことが予想されます。ユーザーのパターンと使用するデバイスに大きく依存します。計算式:(成功したパスキーログイン数)÷(試行されたパスキーログイン数)。ユーザーがパスキーを途中で放棄し、パスワードに切り替えた部分的な試行を追跡します。モバイルウェブで95%以上。ネイティブアプリで99%以上。デスクトップのログイン率は、複数のデバイスを持つユーザーの数と、最初に登録する場所によって異なります。
パスキーログイン時間とレガシーログイン時間の比較(Passkey Login Time vs. Legacy Login Time)ユーザーがログインを開始した瞬間から正常に完了するまでの、パスキー経由の平均認証時間とパスワード(またはその他のレガシーな方法)の比較。パスキーによるサインインの高速化は、ユーザー満足度の向上と継続的な使用に相関しています。各ログイン試行の開始と成功のタイムスタンプを記録します。平均パスキーログイン時間と平均レガシーログイン時間を計算して比較します。OS / ブラウザ / デバイスごとにセグメント化して、より深いインサイトを得ます。3倍〜5倍の速度向上。既存のMFA(PW+SMS)と比較した場合。
フォールバック率(Fallback Rate)最初にパスキーで開始されたログイン試行中に、ユーザーがパスワードまたは他のパスキー以外の方法にどれくらいの頻度で戻るか。パスキーの信頼性の低さやユーザーの慣れの不足などにより、レガシーフローに継続して依存していることを示します。計算式:(フォールバックイベント数)÷(パスキーログイン試行回数)。フォールバックデータをユーザーアンケートやサポートチケットと関連付けて、根本原因を特定します。このKPIは基本的にパスキーログイン率の反転であり、実装に依存します。

摩擦のないユーザーエクスペリエンスを確保するために、主にパスキーログインの成功とパスキーログイン率を最適化することが重要です。同時に、ユーザーアクティベーション率の向上にも取り組みますが、それはユーザーのフラストレーションを招かない程度にログイン成功率が十分に高い場合に限ります。さらに、これらのKPIをさまざまなセグメント(OS、ブラウザ、デバイスなど)および特定のユースケース(クロスデバイスログインなど)ごとに追跡することで、普及のパターンや潜在的な摩擦ポイントに関するより深い洞察を得ることができます。

6.3 パスキー指標に必要なイベントを記録する方法#

入力(例:受け入れ、作成)と出力KPI(例:ログイン率、フォールバックの使用)の両方を正確に測定するには、以下の3つの主要なソースからデータを収集する必要があります。

  1. フロントエンドのイベントデータ
  2. パスキー / 資格情報ストア
  3. レガシーな認証とフォールバックのログ

6.3.1 フロントエンドのイベントデータ#

パスキー受け入れ率パスキー作成成功率のような指標を計算するには、サインイン後のナッジを見るユーザー数、「はい、パスキーを作成します」をクリックする数、そして実際にパスキー作成を完了する数を検出する必要があります。これには、以下をキャプチャするためのJavaScript(またはネイティブモバイル)イベントトラッキングが必要です。

  • ナッジがいつ表示されたか、または表示されたかどうか(初回とそれ以降の回数)
  • ナッジを完了するのにかかる時間
  • パスキー作成セレモニーを1回または複数回中止したかどうか

また、特定の壊れたパスを検出するために、受け入れ率を特定のOS / ブラウザのバージョンと結びつけるためのユーザーエージェント解析または**クライアントヒント(Client Hints)**も必要になります。

6.3.2 パスキー / 資格情報ストア#

ユーザーがフロントエンドで登録を開始した後、サーバーは新しいパスキーが実際に保存されたかどうかを確認する必要があります。各資格情報の作成イベントを記録するデータベース、または外部のアイデンティティプロバイダーのAPIにアクセスする必要があります。このリポジトリは、ユーザーごとに存在するパスキーの数を数え、最終的な結果(成功または失敗)を追跡するのに役立ち、登録の完了に終わった試行を正確に把握することができます。

6.3.3 レガシーな認証とフォールバックのログ#

フォールバック率などの指標については、現在の認証ログとプロセスを確認する必要があります。これらのログをフロントエンドイベントと統合することで、ユーザーがパスキーログインを開始し、エラーを受け取り、フォールバックログイン(SMSやパスワードなど)に切り替えたかどうかを確認できます。

最後に、パスキーログイン時間とレガシーログイン時間の比較などの時間ベースのKPIの測定は、クライアントとサーバーの両方のタイムスタンプに依存します。多くの組織は成功したサインインしか記録しないため、摩擦とフォールバックを真に測定するには、部分的または失敗したパスキーフローの計装を追加する必要があります。プライバシーや規制上の制約を尊重しながら、これら3つのデータソースを統合することは、予想以上に複雑になることが多く、組み込みの分析とイベントトラッキングを提供する専用のパスキープラットフォームを導入するチームが直面するもう1つの要因です。

6.3.4 Corbadoの統合アプローチ:認証プロセスマイニング#

Corbado Connectコンポーネントは、認証プロセスを開始するすべてのユーザーに対して一意のプロセスを自動的に生成することで、記載されているすべてのデータポイント(数百の異なるデータポイント)を暗黙的に収集します。シームレスな統合を通じて、Corbadoはお客様の既存のソリューションからも認証指標を収集します。この包括的なビューにより、ユーザーのための改善点を正確に特定し、お客様側で追加の労力をかけることなく、すべての重要なパスキーKPIに関する包括的なインサイトを提供します。

6.4 影響を受けるべきその他の重要な出力KPI / OKRとは?#

さらに、以下の出力KPIへの影響も、パスキー導入の成功後に現れるはずであり、その大部分はすでに企業内で収集されています。

運用およびコスト削減の指標

  • SMS OTP使用量の削減 – パスキー認証によって節約されたSMS OTPの数(直接的なコスト削減)。
  • パスワードリセット要求の削減 – パスワード忘れに関連するヘルプデスクとのやり取りの減少。
  • カスタマーサポートチケットの削減 – 認証に関連するカスタマーサービス問題の減少。
  • サポートコール量の削減 – アカウントアクセス問題に関連するインバウンドコールの減少。

ビジネスとUXへの影響の指標

  • ユーザー定着率 – 最初のログイン後も認証を継続するユーザーの割合。
  • コンバージョン率 – 認証後にユーザーがトランザクションを完了する頻度。
  • ログインファネルのドロップオフ率 – パスキーによってログイン試行を放棄するユーザー数が減少するかどうか。

パスキーの入力KPIと出力KPIを具体的に追跡し、それらを他のデータと関連付けることで、組織はパスキー展開の影響を定量化し、データ主導の改善を行って普及を最大化し、コストを削減し、セキュリティを強化することができます。

7. 推奨事項#

適切なパスキーソリューションの選択は、特定の課題、セキュリティ要件、およびコストの考慮事項によって異なります。以下は、さまざまなセクターにおける内製 vs 購入の決定に関する主な推奨事項です。

7.1 銀行・金融サービスにおけるパスキーの推奨事項#

主な考慮事項:

  • 規制コンプライアンス(PSD2SOC 2ISO 27001、GDPRなど)では、パスキー認証における厳格なセキュリティ対策が求められます。
  • 銀行は社内ソリューションの長期的な複雑さとメンテナンスを過小評価することが多いため、パスキーのコスト比較が重要です。
  • アカウント乗っ取り詐欺やフィッシングを減らすためには、安全な認証が不可欠です。

推奨事項:
ほとんどの銀行や金融機関は、社内で構築するよりもパスキーベンダーのソリューションに依存すべきです。パスキーインフラストラクチャを内部で管理すると、従来のIT専門知識を超える隠れた複雑さが生じるためです。パスキー認証を大規模に実装するには、継続的な最適化とアップデート、WebAuthnの互換性管理、およびレガシーなバンキングシステムとのシームレスな統合が必要ですが、これらはすべてパスキーベンダーがすでに対応しています。

Ubank、RevolutFinomなどの銀行はパスキー導入の最前線に立っており、セキュリティを強化しながらユーザーエクスペリエンスを向上させるテクノロジーの可能性を認識しています。パスキーのROI分析では、継続的なメンテナンスやアップデートに投資するよりも、パスキーソリューションを購入する方が有利になることが多く、実装により詐欺の試みや認証関連のサポートコストが大幅に減少することが示されています。

例: Armstrong Bank、First Financial Bank、Ubank、RevolutFinom、Neobank、Cathay Financial Holdings、Stripe、PayPal、Square

7.2 医療におけるパスキーの推奨事項#

主な考慮事項:

  • HIPAAおよびGDPRコンプライアンスでは、パスキーの導入において厳格な認証セキュリティが求められます。
  • パスキー導入の課題には、患者、医療スタッフ、病院のIT管理者にとってのセキュリティと使いやすさのバランスを取ることが含まれます。
  • 多くの医療認証システムは依然としてレガシーインフラに依存しており、パスキーの統合をより複雑にしています。

推奨事項:
パスキーベンダーのソリューションは、認証を簡素化しながらコンプライアンス要件を満たすための最も効果的な方法です。パスキーベンダーはセキュリティパッチ、コンプライアンスアップデート、認証の信頼性を処理し、ITチームの負担を軽減します。

例: CVS Health、Caremark、Helsana、NHS、Swica

7.3 eコマース・小売におけるパスキーの推奨事項#

主な考慮事項:

  • コンバージョン率の最適化(CRO)はビジネスにとって重要であり、認証の摩擦は収益に直接影響します。
  • マルチデバイスのシナリオ(ユーザーがモバイルで閲覧し、デスクトップでチェックアウトを完了するなど)がシームレスに機能する必要があります。
  • 認証エラーはカート放棄率を直接増加させるため、UXが最適化されたログインフローが不可欠です。

推奨事項:
eコマースプラットフォームは、高い普及率を提供するパスキー実装プロバイダーから最も恩恵を受けます。AmazonやShopifyなどの主要プラットフォームはパスキー認証を実装しており、eコマースにおけるこのテクノロジーの普及の拡大を示しています。現実のデータでは、最初のパスワードログインの27%以上が失敗するのに対し、パスキーベースの認証は、以前の導入事例で示されているように、最大95〜97%のログイン成功率を達成できることがわかっています。パスキーのROI分析では、コンバージョン率の向上と詐欺による損失の減少によって、投資がすぐに正当化されることが示されています。

Amazonは最近、100%のパスキー普及とパスワードの完全な廃止という野心的な目標を設定したと述べました。

Googleはまた、パスキーを操作するトライアルユーザーは、そうでないユーザーに比べて有料顧客にコンバージョンする可能性が20%高いことも発見しました。

例: KAYAK、Amazon、Mercari、Best Buy、eBay、Home Depot、Shopify、Target

7.4 旅行・ホスピタリティにおけるパスキーの推奨事項#

主な考慮事項:

  • ユーザーはあるデバイスで旅行を予約し、別のデバイスでチェックインするため、クロスデバイス認証が不可欠です。
  • パスキー専門のベンダーは、便利な予約、チェックイン、アカウント管理のために、高速で安全なログインを確保する必要があります。
  • 旅行プラットフォームは高額な取引を処理するため、不正行為防止が優先事項となります。

推奨事項:
ほとんどの旅行会社は、セキュリティとユーザーエクスペリエンスを向上させるためにパスキーソリューションを実装する必要があります。Kayakや主要な航空会社などの大手企業は、すでにパスキー認証を利用してユーザーエクスペリエンスを向上させています。構築済みのソリューションは、より強力な不正検出、シームレスなログインエクスペリエンス、即時のマルチデバイスサポートを提供します。ホスピタリティ部門は、パスキーの実装によるチェックイン時間の短縮とセキュリティ向上の恩恵を特に受けており、すべてのタッチポイント(アプリ、キオスク、ウェブ、パートナープラットフォーム)でのスムーズな認証を確保しています。

例: Air New Zealand、Bolt、Grab、Uber、Hyatt

7.5 保険におけるパスキーの推奨事項#

主な考慮事項:

  • パスキーの実装コストは、コンプライアンスのニーズとユーザーエクスペリエンスの向上とバランスが取れている必要があります。
  • 多くの保険顧客は技術にあまり詳しくないため、あらゆる種類のデバイスやブラウザでのユーザーエクスペリエンスが必須です。
  • ポリシー管理や請求処理には、パスキーと本人確認の統合が必要になることがよくあります。

推奨事項:
外部のパスキーソリューションは、迅速な導入と規制コンプライアンスに最適です。保険プロバイダーは、パスキーを実装した後、認証関連のサポートチケットが大幅に減少したと報告しています。カスタマイズ可能な認証フローと統合された本人確認を備えたパスキー実装プロバイダーは、顧客のログインをシンプルに保ちながらセキュリティを確保します。パスキーのROI分析は、パスワードのリセットや不正による損失の減少がベンダーのコストを相殺することを示唆しています。

例: Branch

7.6 政府・公共サービスにおけるパスキーの推奨事項#

主な考慮事項:

  • 最高レベルのセキュリティ基準とコンプライアンス要件(例:NIST、Essential Eightフレームワークではフィッシング耐性のあるMFAが求められます)。
  • 技術的習熟度がさまざまな多様なユーザー層全体での大規模な導入ニーズ。
  • 既存の政府の身元確認システムやレガシーインフラストラクチャとの統合要件。

推奨事項:
政府機関にとって、厳格なセキュリティ基準を満たしつつアクセシビリティを確保する専用のパスキーソリューションは不可欠です。VicRoadsでの実装の成功は、政府組織が、コンプライアンス要件とセキュリティの更新を自動的に処理する外部のパスキーソリューションから最も恩恵を受けることを示しています。したがって、エンタープライズレベルのセキュリティを提供し、マルチデバイス認証をサポートし、すべての市民に対応する適応型認証フローを提供するパスキー実装プロバイダーを選択してください。

例: VicRoads、myGov、State of Michigan

7.7 通信・公益事業におけるパスキーの推奨事項#

主な考慮事項:

  • 通信プロバイダーや公益事業者は、多くの場合、さまざまな顧客セグメントにわたって数百万人のユーザーを管理しており、高可用性でフォールトトレラントな認証を必要とするため、スケーラビリティと信頼性が重要です。
  • ユーザーはモバイルアプリやウェブポータルを介してアカウントにアクセスするため、マルチデバイスおよびクロスプラットフォームのサポートが不可欠です。シームレスなパスキー認証は、すべての顧客タッチポイントで機能する必要があります。
  • 通信プロバイダーや公益事業者は、現在の認証フローを中断することなく、既存のIAMシステムや顧客アイデンティティプラットフォームにパスキーを統合する必要があるため、レガシー認証システムのサポートが必要になることがよくあります。
  • 不正行為防止とアカウントのセキュリティは最優先事項であり、特にSIMスワップ詐欺、個人情報の盗難、不正なアカウントアクセスなどが懸念されます。パスキーは、フィッシング攻撃やクレデンシャルスタッフィングのリスクを大幅に削減できます。

推奨事項:
通信プロバイダーや公益事業者にとって、外部のパスキーソリューションを採用することが推奨されるアプローチです。これらの業界の規模、複雑さ、セキュリティ要件を考慮すると、マネージドパスキープロバイダーは、コンプライアンス、高可用性、既存の認証インフラストラクチャとのシームレスな統合を確保します。通信大手やデジタルファーストの公益事業者は、不正行為を減らし、ユーザーエクスペリエンスを向上させるためのセキュリティ近代化の取り組みの一環として、すでにパスキーを取り入れています。さらに、パスキーの実装をアウトソーシングすることで、継続的なメンテナンス、セキュリティアップデート、規制コンプライアンスがプロバイダーによって処理されるため、社内で構築するよりも総所有コスト(TCO)が低くなります。

例: Deutsche Telekom、Telstra、SK Telecom

7.8 B2B SaaSにおけるパスキーの推奨事項#

主な考慮事項:

  • B2B SaaSではマルチテナント認証が不可欠であり、さまざまなIAMシステム全体でスケーラブルなパスキー統合が必要になります。
  • 企業はSSO(OIDC / SAML)を期待しているため、アイデンティティプロバイダーとのシームレスな統合はビジネスにとって不可欠です。
  • パスキーの実装コストは、多要素認証(MFA)やゼロトラストセキュリティモデルなど、他のセキュリティ投資とのバランスを取る必要があります。

推奨事項:
ほとんどのB2B SaaSプロバイダーにとって、外部パスキーの実装が最適な選択肢です。実装は通常、社内開発よりも高速です。Notion、Hubspot、VercelなどのデジタルB2B企業は、認証セキュリティを強化するためにすでにパスキーを取り入れています。メンテナンス、アップデート、コンプライアンス要件がプロバイダーによってカバーされるため、総所有コストは社内開発よりも大幅に低くなります。

例: Canva、DocuSign、Notion

8. 結論#

パスキーは認証のグローバルスタンダードとなっており、エンドユーザーのログインを簡素化しながらセキュリティを強化しています。企業がパスキーの実装方法を評価する際、社内ソリューションを構築するか、専門のパスキーベンダーを活用するかを決定する必要があります。DIYの実装は完全な制御を提供しますが、高度な技術的専門知識、開発リソース、継続的なメンテナンスを必要とします。対照的に、パスキーベンダーはより迅速でスケーラブルかつ費用対効果の高いアプローチを提供し、高い普及率、シームレスなユーザーエクスペリエンス、進化するセキュリティ基準への準拠を確保します。

このガイドでは、以下の重要な質問に対処しました。

  • パスキーを実装し、パスワードレスを実現するにはどのようなコンポーネントが必要か?

    パスキーの展開を成功させるには、FIDO2/WebAuthnインフラストラクチャ、シームレスなUXフロー、フォールバックメカニズム、安全なアカウント復旧オプションが必要です。企業はまた、クロスプラットフォームの互換性とセキュリティコンプライアンスも考慮しなければなりません。

  • パスキーを社内で実装すべきか、それとも外部ベンダーを利用すべきか?

    社内開発は制御を提供しますが、高い複雑さ、継続的なメンテナンスコスト、セキュリティ上の責任が伴います。ほとんどの大規模な消費者向け組織は、迅速な導入、運用コストの削減、技術的オーバーヘッドの軽減を提供する外部パスキーソリューションから恩恵を受けます。

  • オープンソースライブラリがある中で、パスキーベンダーを利用するメリットは何か?

    オープンソースのWebAuthnライブラリは出発点を提供しますが、エンタープライズレベルのセキュリティ、パスキーに最適化されたユーザーエクスペリエンス、普及を促進する機能が不足しています。パスキーベンダーは、シームレスな展開、スケーラビリティ、最適化されたユーザー普及戦略を確実に行い、より良いROIをもたらし、ユーザーと開発者の両方の摩擦を減らします。

  • パスキーソリューションを構築する上での最大の課題は何か?

    社内のパスキーシステムを開発するには、WebAuthn、マルチデバイスサポート、パスキー普及に関する深い専門知識が必要です。継続的なデバイスとブラウザの複雑さを維持し、高い普及率を確保することは、複雑さをさらに増大させます。

  • パスキーを社内で実装する際のリスクは何か?

    企業は、高い開発コスト、長引く導入スケジュール、継続的なセキュリティメンテナンスの負担といったリスクに直面します。コンプライアンス違反、セキュリティの脆弱性、低いユーザー普及率は、パスキー導入の成功を狂わせる可能性があります。ベンダーが管理するパスキーソリューションは、組み込みのセキュリティと規制コンプライアンスを備えた、実証済みでスケーラブルな認証インフラストラクチャを提供することで、これらのリスクを軽減します。

Corbado

Corbadoについて

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

よくある質問#

エンタープライズ企業がパスキーソリューションを内製する場合の主なリスクは何ですか?#

内製化には、高度なWebAuthnの専門知識、継続的なブラウザやデバイスの互換性管理、専任のセキュリティメンテナンスが必要です。企業は、導入スケジュールの長期化、コンプライアンス違反、低いユーザー普及率などのリスクを負います。銀行や医療などの規制の厳しい業界では、PSD2、HIPAA、NISTへの準拠がさらに複雑さを増しますが、パスキーベンダーはこれらに継続的に対応しています。

パスワードを安全に廃止する前に、パスキーの普及率はどの程度必要ですか?#

組織は、パスワードを廃止する前に、アクティブユーザーの50〜80%がパスキーで認証している状態にする必要があります。時期尚早にパスワードを廃止すると、サポートへの問い合わせやユーザビリティの問題が増加します。段階的なアプローチでは、ユーザーが継続的にパスキー経由で認証しているアカウントから開始し、複数のナッジ(複数回のプロンプトによりモバイルでの受け入れ率は最大85%に達します)を活用し、データ主導のインサイトに基づいて拡大していきます。

パスキー導入の成功を測定するには、どのKPIを追跡すべきですか?#

パスキー受け入れ率(ベンチマーク:初回ナッジで50〜75%、複数回ナッジでモバイルでは最大85%)や、ほぼ100%を目標とする作成成功率などの入力KPIを追跡します。出力KPIとしては、数週間以内に20%以上、12か月で50%以上のパスキーログイン率を目標とします。すべての指標をOS、ブラウザ、デバイスごとにセグメント化し、摩擦のポイントを特定します。

技術的な導入が成功しても、パスキープロジェクトが失敗するのはなぜですか?#

ほとんどのパスキープロジェクトは、技術的な問題よりも、ユーザーの普及率の低さによって失敗します。パスワードへの依存が続くと、セキュリティのメリットが損なわれ、SMS OTPやパスワードリセットの削減によるコスト削減効果が失われ、ユーザーエクスペリエンスが分断されます。GoogleやAmazonは、普及を明確なターゲットとした継続的なA/Bテスト、UIナッジ、構造化されたユーザー教育キャンペーンを通じてこの問題に対処しています。

内製するよりもパスキーベンダーを利用することで、最も恩恵を受けるのはどの業界ですか?#

銀行、医療、政府機関、eコマース、通信、保険セクターは、PSD2、HIPAA、NISTなどの規制要件と、大規模なユーザーベース、複雑なレガシーインフラストラクチャが組み合わさっているため、パスキーベンダーソリューションから最も恩恵を受けます。Amazonは、100%のパスキー普及とパスワードの完全な廃止という目標を設定しており、これらの導入が必要とするコミットメントの規模を示しています。

パスキーの展開で実際に何が起きているかを把握できます。

Consoleを見る

この記事を共有


LinkedInTwitterFacebook