このページは自動翻訳されています。英語の原文は こちら.
パスキー内製・購入ガイドの完全版を無料ダウンロードして、すべてのインサイトにアクセスしてください。
パスキーソリューションは購入すべきか、内製すべきか?
DIYとベンダーソリューション(SaaSおよびオンプレミス)の比較、主な課題、コスト、ベストプラクティスなど、パスキー導入のための完全なチェックリストを入手してください。

パスキーの独自実装というアイデアは魅力的に聞こえます。完全な制御、カスタマイズされた統合、ベンダーロックインの排除などです。結局のところ、FIDO2はオープンスタンダードに基づいており、WebAuthnのコードの最初の数行を書くのは簡単そうに見えます。本当にそれほど難しいのでしょうか?
しかし、複雑さが始まるのはまさにここからです。特に、以下のような業界で数百万人のユーザーを抱える大規模な消費者向けの導入シナリオを計画している場合はなおさらです。
本当の課題は、最初のパスキーログインが成功した後に始まり、パスキーソリューションを実装している最中に明らかになることがよくあります。突然、奇妙なエッジケース、ユーザーの混乱を招くエラー、パスキーが利用できないことによるユーザーのロックアウトの可能性などが現れます。簡単だと思われていた統合が、数か月から数年におよぶ開発の労力、予期せぬメンテナンスコスト、そして潜在的なパスキープロジェクトの失敗に変わってしまうのです。
しかし、特定の組織や特定の要件においては、独自のソリューションを構築することが正しい選択となる場合もあります。私たちはこれまでに数十の組織とパスキーの実装計画について話し合い、実際に一部の組織の導入をハンズオンでサポートしてきました。このガイドは、Do-It-Yourself(DIY)のアプローチが意味を持つケースと、実績のあるパスキープロバイダーを選択する方が賢明な判断となるケースを見極めるのに役立ちます。
このパスキー内製・購入ガイドでは、以下の質問にお答えします。
パスワードは時代遅れで、安全性が低く、イライラするものです。パスキーはフィッシングのリスクを排除し、ユーザーエクスペリエンスを向上させ、認証を簡素化します。これにより、パスキーは安全なログインの新しい標準となっています。社内で構築する場合でも、外部ソリューションを使用する場合でも、パスキーの統合はセキュリティとユーザビリティの大きなアップグレードとなります。
Googleは、使いやすさやスピードを前面に押し出すことがユーザーの共感を呼び、効果的であることを発見しました。人々は概してサインインに不満を抱いているため、プロセスを簡単かつ迅速にするものはすべてプラスに働きます。
これらのセキュリティ上の利点に加えて、パスキーによって運用コストを大幅に削減できる可能性があります。ユーザーに送信されるSMS OTPの数を減らすことができ、ユーザーベースが大きい場合はそのコストが膨大に積み重なります。さらに、パスワードやMFAの復旧がカスタマーサポートチームに与える負担も排除できるコスト要因です。
それに加えて、パスキーはユーザーのログイン成功率とログイン時間を改善し、最終的にコンバージョン率の向上につながります。これは、eコマース、小売、旅行などの業界においてトップラインの成長を牽引する主要な推進力となります。
パスキーの導入を検討している多くの組織にとっての最終的な目標は、完全にパスワードレスに移行することです。この目標を達成するには、通常、完了しなければならない4つのフェーズがあります。これらのフェーズが進行する速度は、組織の技術的能力、ログインパターン、ユーザーベースに大きく依存します。場合によっては、より安全な認証の導入を求める公的な圧力や財政的な制約などの外部要因も影響する可能性があります。
パスキーの統合はパスキープロジェクトを成功させるための1つのステップに過ぎないため、これら4つのフェーズを順を追って説明しましょう。
完全なパスワードレスシステムへの移行における最初のステップは、ログイン方法としてパスキーを統合することです。この段階では、まだパスキーを導入していないユーザーでもアカウントにアクセスできるように、パスワードやその他の認証方法がフォールバックとして残されます。統合を成功させるには、既存のログインフローやセキュリティポリシーとのシームレスな互換性が必要です。組織は、パスキーの作成をシンプルにすることに重点を置き、技術的知識の有無に関わらず、ユーザーが摩擦なく新しい認証方法を採用できるようにする必要があります。
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パスキーが統合された後の次の課題は、ユーザーへのパスキーの普及を促進することです。多くの組織はこのフェーズの重要性を過小評価していますが、ユーザーの広範な普及がなければ、パスキープロジェクトは失敗する可能性が高くなります。目標は、可能な限り多くのユーザーにパスキーの作成と使用を促し、理想的にはそれをデフォルトのログイン方法にすることです。
普及を促進するための主要な戦術には、積極的なユーザー教育、パスキーの作成を促すUIナッジ、切り替えを行ったユーザーに報いるインセンティブプログラムなどが含まれます。組織は、次のフェーズに進む前に、アクティブユーザーの50〜80%がパスキーを利用するといった、普及の限界値を設定する必要があります。普及が重要である理由についてより深く理解するには、普及率の低さがパスキープロジェクトを危険にさらす理由に関する詳細な記事を参照してください。
パスキーの普及がクリティカルマスに達すると、組織はパスワードの段階的な廃止を開始することができます。ただし、時期尚早にパスワードを削除したり、慎重な計画なしに削除したりすると、ユーザビリティの問題やサポートリクエストの増加につながる可能性があります。段階的なアプローチを推奨します。
ユーザーを完全なパスワードレス認証へと戦略的に導くことで、組織はユーザーエクスペリエンスを損なうことなくセキュリティを最大化できます。
パスワードが廃止されると、アカウント復旧メカニズムは堅牢で安全なものでなければなりません。従来の復旧方法は、サポートチケットやメールによるリセットなどの手作業による介入に依存することが多く、これらはセキュリティリスクと運用コストをもたらす可能性があります。組織は、ユーザーエクスペリエンスを向上させながらセキュリティを維持する、最新のセルフサービスによるアカウント復旧ソリューションを実装する必要があります。
自動化されたアカウント復旧の重要な要素には、以下が含まれます。
多くの組織は、コストを削減し、ユーザビリティを向上させるために、パスワードレスへの移行とは独立して、自動化された復旧プロセスにすでに投資しています。しかし、パスキー主導のエコシステムにおいては、これらのメカニズムはセキュリティを維持し、摩擦を減らすためにさらに重要になります。
これら4つのフェーズに基づいて、購入か内製かの決定を評価するお手伝いをします。したがって、パスキープロジェクトの長期的な成功のためには、すべてのフェーズを念頭に置くことが非常に重要であり、単にパスキーを統合するだけではありません(統合自体を目標とすることもできますが、それではパスキーの可能性を十分に活かしきれません)。
DIYと外部のパスキーソリューションのどちらを選択するかは、企業の技術リソース、セキュリティの優先順位、導入の規模、長期的なパスキー戦略によって異なります。次のセクションでは、最適な決定を下すための重要な側面について詳しく説明します。
以下の表は、評価が必要なさまざまな基準を示しています。どちらの説明に傾いているかに基づいて、異なるポイントが提供されます。
評価マトリックスの使用方法:
各基準について、企業がよりシンプルなソリューションを必要としているか、それともより手の込んだソリューションを必要としているかを選択します。
パスキー内製・購入ガイドの完全版を無料ダウンロードして、すべての評価基準にアクセスしてください。
パスキーソリューションは購入すべきか、内製すべきか?
DIYとベンダーソリューション(SaaSおよびオンプレミス)の比較、主な課題、コスト、ベストプラクティスなど、パスキー導入のための完全なチェックリストを入手してください。

パスキーソリューションを内製するか購入するかを決定する際には、パスキー展開の単一のフェーズだけでなく、プロセス全体に目を向けることが重要です。短期的にはパスキーをMVPとして提供することが優先される場合でも、長期的な影響、特に普及の推進について予測しておく必要があります。以下では、普及が他のほとんどの要素よりも重要である理由を強調しながら、このガイドの使用方法と結果の解釈について推奨事項を示します。
パスキーソリューションがどれほど高度であっても、ユーザーがパスキーを作成し、ログインに使用して普及させなければ、プロジェクト全体がリスクにさらされます。私たちの経験では、組織はユーザーをパスワードから移行させるために必要な労力を過小評価しがちです。技術的なレベルでパスキーをシームレスに実装したとしても、普及率が低いと以下の結果を招きます。
パスワードの削減または完全な廃止に向けた有意義な前進を図るには、通常、ユーザーベースの50%、あるいは80%以上という高い普及率が必要です。GoogleやAmazonのような組織は、明確な普及目標を設定し、A/Bテスト、ユーザー教育キャンペーン、UIナッジを体系的に実施して、パスキーが広く受け入れられるようにしています。普及に向けたこの集中的な取り組みは任意ではありません。パスキーの導入を単なる機能から目に見える競争上の優位性へと変えるのがこの取り組みなのです。
このガイドは、ジャーニーのあらゆる段階でパスキーの実装に関する情報に基づいた意思決定を行えるように設計されています。
このうち、フェーズ2(普及率の向上)が最も重要です。各セクションを個別に評価することもできますが、長期的な成功とROIは、最初から普及の促進をどれほど真剣に取り組むかにかかっていることが多い点を覚えておいてください。
パスキー実装を決定する初期段階にある場合は、評価マトリックスの最初のセクション(パスキーの統合)から始め、経営陣、IT部門、プロダクトオーナー、その他の主要な意思決定者と記入してください。以下のように自問してください。
これらの質問に前もって答えておくことで、パスキープロジェクトが行き止まりになるのを防ぐことができます。普及の計画を怠った組織は、何年にもわたってパスワードから抜け出せず、セキュリティとユーザーエクスペリエンス戦略全体の価値を低下させることになりがちです。
マトリックス全体を通じて、各評価基準は**複雑さが最も低い(1)から複雑さが最も高い(5)までのどこかに該当します。回答が中立ゾーン(3)**を越えて複雑な方向にシフトするほど、専門のパスキーベンダーを利用するべき強い理由となります。
これらの要因は、技術的にも組織的にも、社内チームを圧倒する可能性があります。マネージドパスキーソリューションは、DIYアプローチよりもはるかに早く普及を促進するために、実証済みのベストプラクティス、迅速なアップデート、実世界の専門知識を提供できることがよくあります。
パスキーのスペシャリストとして、私たちCorbadoは強い見解を持っています。パスキーがロードマップにあり、普及を積極的に推進する最先端の実装を求めている場合、Corbado Connectは規模の大きい複雑さに対処するのに役立ちます。その理由は以下の通りです。
ソリューションに組み込まれた普及推進機能: 当社のプラットフォームは、スマートなナッジ、分析、継続的なA/Bテストを通じてユーザーのオプトインを最大化するように設計されており、これによりコスト削減も促進されます。
次のステップ:
パスキーに包括的にアプローチし、普及を主要な目標の1つにすることで、最高の結果を得ることができます。それはつまり、より強力なセキュリティ、簡素化されたログイン、そしてパスワードレスな未来への確実な道のりです。クライアントが高いパスキー普及率を達成するために私たちがどのように支援しているか、Corbado Connectについての詳細に興味がございましたら、いつでもご相談をお受けいたします。
「内製か購入か?」という質問に答えるための適切なアプローチの決定方法について説明しました。次は、パスキー導入の成功をどのように評価するかを分析します。そのため、パスキープロジェクトの入力KPIと出力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フロー、技術的な実装を微調整することを可能にします。
出力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、ブラウザ、デバイスなど)および特定のユースケース(クロスデバイスログインなど)ごとに追跡することで、普及のパターンや潜在的な摩擦ポイントに関するより深い洞察を得ることができます。
入力(例:受け入れ、作成)と出力KPI(例:ログイン率、フォールバックの使用)の両方を正確に測定するには、以下の3つの主要なソースからデータを収集する必要があります。
パスキー受け入れ率やパスキー作成成功率のような指標を計算するには、サインイン後のナッジを見るユーザー数、「はい、パスキーを作成します」をクリックする数、そして実際にパスキー作成を完了する数を検出する必要があります。これには、以下をキャプチャするためのJavaScript(またはネイティブモバイル)イベントトラッキングが必要です。
また、特定の壊れたパスを検出するために、受け入れ率を特定のOS / ブラウザのバージョンと結びつけるためのユーザーエージェント解析または**クライアントヒント(Client Hints)**も必要になります。
ユーザーがフロントエンドで登録を開始した後、サーバーは新しいパスキーが実際に保存されたかどうかを確認する必要があります。各資格情報の作成イベントを記録するデータベース、または外部のアイデンティティプロバイダーのAPIにアクセスする必要があります。このリポジトリは、ユーザーごとに存在するパスキーの数を数え、最終的な結果(成功または失敗)を追跡するのに役立ち、登録の完了に終わった試行を正確に把握することができます。
フォールバック率などの指標については、現在の認証ログとプロセスを確認する必要があります。これらのログをフロントエンドイベントと統合することで、ユーザーがパスキーログインを開始し、エラーを受け取り、フォールバックログイン(SMSやパスワードなど)に切り替えたかどうかを確認できます。
最後に、パスキーログイン時間とレガシーログイン時間の比較などの時間ベースのKPIの測定は、クライアントとサーバーの両方のタイムスタンプに依存します。多くの組織は成功したサインインしか記録しないため、摩擦とフォールバックを真に測定するには、部分的または失敗したパスキーフローの計装を追加する必要があります。プライバシーや規制上の制約を尊重しながら、これら3つのデータソースを統合することは、予想以上に複雑になることが多く、組み込みの分析とイベントトラッキングを提供する専用のパスキープラットフォームを導入するチームが直面するもう1つの要因です。
Corbado Connectコンポーネントは、認証プロセスを開始するすべてのユーザーに対して一意のプロセスを自動的に生成することで、記載されているすべてのデータポイント(数百の異なるデータポイント)を暗黙的に収集します。シームレスな統合を通じて、Corbadoはお客様の既存のソリューションからも認証指標を収集します。この包括的なビューにより、ユーザーのための改善点を正確に特定し、お客様側で追加の労力をかけることなく、すべての重要なパスキーKPIに関する包括的なインサイトを提供します。
さらに、以下の出力KPIへの影響も、パスキー導入の成功後に現れるはずであり、その大部分はすでに企業内で収集されています。
運用およびコスト削減の指標
ビジネスとUXへの影響の指標
パスキーの入力KPIと出力KPIを具体的に追跡し、それらを他のデータと関連付けることで、組織はパスキー展開の影響を定量化し、データ主導の改善を行って普及を最大化し、コストを削減し、セキュリティを強化することができます。
適切なパスキーソリューションの選択は、特定の課題、セキュリティ要件、およびコストの考慮事項によって異なります。以下は、さまざまなセクターにおける内製 vs 購入の決定に関する主な推奨事項です。
主な考慮事項:
推奨事項:
ほとんどの銀行や金融機関は、社内で構築するよりもパスキーベンダーのソリューションに依存すべきです。パスキーインフラストラクチャを内部で管理すると、従来のIT専門知識を超える隠れた複雑さが生じるためです。パスキー認証を大規模に実装するには、継続的な最適化とアップデート、WebAuthnの互換性管理、およびレガシーなバンキングシステムとのシームレスな統合が必要ですが、これらはすべてパスキーベンダーがすでに対応しています。
Ubank、Revolut、Finomなどの銀行はパスキー導入の最前線に立っており、セキュリティを強化しながらユーザーエクスペリエンスを向上させるテクノロジーの可能性を認識しています。パスキーのROI分析では、継続的なメンテナンスやアップデートに投資するよりも、パスキーソリューションを購入する方が有利になることが多く、実装により詐欺の試みや認証関連のサポートコストが大幅に減少することが示されています。
例: Armstrong Bank、First Financial Bank、Ubank、Revolut、Finom、Neobank、Cathay Financial Holdings、Stripe、PayPal、Square
主な考慮事項:
推奨事項:
パスキーベンダーのソリューションは、認証を簡素化しながらコンプライアンス要件を満たすための最も効果的な方法です。パスキーベンダーはセキュリティパッチ、コンプライアンスアップデート、認証の信頼性を処理し、ITチームの負担を軽減します。
例: CVS Health、Caremark、Helsana、NHS、Swica
主な考慮事項:
推奨事項:
eコマースプラットフォームは、高い普及率を提供するパスキー実装プロバイダーから最も恩恵を受けます。AmazonやShopifyなどの主要プラットフォームはパスキー認証を実装しており、eコマースにおけるこのテクノロジーの普及の拡大を示しています。現実のデータでは、最初のパスワードログインの27%以上が失敗するのに対し、パスキーベースの認証は、以前の導入事例で示されているように、最大95〜97%のログイン成功率を達成できることがわかっています。パスキーのROI分析では、コンバージョン率の向上と詐欺による損失の減少によって、投資がすぐに正当化されることが示されています。
Amazonは最近、100%のパスキー普及とパスワードの完全な廃止という野心的な目標を設定したと述べました。
Googleはまた、パスキーを操作するトライアルユーザーは、そうでないユーザーに比べて有料顧客にコンバージョンする可能性が20%高いことも発見しました。
例: KAYAK、Amazon、Mercari、Best Buy、eBay、Home Depot、Shopify、Target
主な考慮事項:
推奨事項:
ほとんどの旅行会社は、セキュリティとユーザーエクスペリエンスを向上させるためにパスキーソリューションを実装する必要があります。Kayakや主要な航空会社などの大手企業は、すでにパスキー認証を利用してユーザーエクスペリエンスを向上させています。構築済みのソリューションは、より強力な不正検出、シームレスなログインエクスペリエンス、即時のマルチデバイスサポートを提供します。ホスピタリティ部門は、パスキーの実装によるチェックイン時間の短縮とセキュリティ向上の恩恵を特に受けており、すべてのタッチポイント(アプリ、キオスク、ウェブ、パートナープラットフォーム)でのスムーズな認証を確保しています。
例: Air New Zealand、Bolt、Grab、Uber、Hyatt
主な考慮事項:
推奨事項:
外部のパスキーソリューションは、迅速な導入と規制コンプライアンスに最適です。保険プロバイダーは、パスキーを実装した後、認証関連のサポートチケットが大幅に減少したと報告しています。カスタマイズ可能な認証フローと統合された本人確認を備えたパスキー実装プロバイダーは、顧客のログインをシンプルに保ちながらセキュリティを確保します。パスキーのROI分析は、パスワードのリセットや不正による損失の減少がベンダーのコストを相殺することを示唆しています。
例: Branch
主な考慮事項:
推奨事項:
政府機関にとって、厳格なセキュリティ基準を満たしつつアクセシビリティを確保する専用のパスキーソリューションは不可欠です。VicRoadsでの実装の成功は、政府組織が、コンプライアンス要件とセキュリティの更新を自動的に処理する外部のパスキーソリューションから最も恩恵を受けることを示しています。したがって、エンタープライズレベルのセキュリティを提供し、マルチデバイス認証をサポートし、すべての市民に対応する適応型認証フローを提供するパスキー実装プロバイダーを選択してください。
例: VicRoads、myGov、State of Michigan
主な考慮事項:
推奨事項:
通信プロバイダーや公益事業者にとって、外部のパスキーソリューションを採用することが推奨されるアプローチです。これらの業界の規模、複雑さ、セキュリティ要件を考慮すると、マネージドパスキープロバイダーは、コンプライアンス、高可用性、既存の認証インフラストラクチャとのシームレスな統合を確保します。通信大手やデジタルファーストの公益事業者は、不正行為を減らし、ユーザーエクスペリエンスを向上させるためのセキュリティ近代化の取り組みの一環として、すでにパスキーを取り入れています。さらに、パスキーの実装をアウトソーシングすることで、継続的なメンテナンス、セキュリティアップデート、規制コンプライアンスがプロバイダーによって処理されるため、社内で構築するよりも総所有コスト(TCO)が低くなります。
例: Deutsche Telekom、Telstra、SK Telecom
主な考慮事項:
推奨事項:
ほとんどのB2B SaaSプロバイダーにとって、外部パスキーの実装が最適な選択肢です。実装は通常、社内開発よりも高速です。Notion、Hubspot、VercelなどのデジタルB2B企業は、認証セキュリティを強化するためにすでにパスキーを取り入れています。メンテナンス、アップデート、コンプライアンス要件がプロバイダーによってカバーされるため、総所有コストは社内開発よりも大幅に低くなります。
例: Canva、DocuSign、Notion
パスキーは認証のグローバルスタンダードとなっており、エンドユーザーのログインを簡素化しながらセキュリティを強化しています。企業がパスキーの実装方法を評価する際、社内ソリューションを構築するか、専門のパスキーベンダーを活用するかを決定する必要があります。DIYの実装は完全な制御を提供しますが、高度な技術的専門知識、開発リソース、継続的なメンテナンスを必要とします。対照的に、パスキーベンダーはより迅速でスケーラブルかつ費用対効果の高いアプローチを提供し、高い普及率、シームレスなユーザーエクスペリエンス、進化するセキュリティ基準への準拠を確保します。
このガイドでは、以下の重要な質問に対処しました。
パスキーを実装し、パスワードレスを実現するにはどのようなコンポーネントが必要か?
パスキーの展開を成功させるには、FIDO2/WebAuthnインフラストラクチャ、シームレスなUXフロー、フォールバックメカニズム、安全なアカウント復旧オプションが必要です。企業はまた、クロスプラットフォームの互換性とセキュリティコンプライアンスも考慮しなければなりません。
パスキーを社内で実装すべきか、それとも外部ベンダーを利用すべきか?
社内開発は制御を提供しますが、高い複雑さ、継続的なメンテナンスコスト、セキュリティ上の責任が伴います。ほとんどの大規模な消費者向け組織は、迅速な導入、運用コストの削減、技術的オーバーヘッドの軽減を提供する外部パスキーソリューションから恩恵を受けます。
オープンソースライブラリがある中で、パスキーベンダーを利用するメリットは何か?
オープンソースのWebAuthnライブラリは出発点を提供しますが、エンタープライズレベルのセキュリティ、パスキーに最適化されたユーザーエクスペリエンス、普及を促進する機能が不足しています。パスキーベンダーは、シームレスな展開、スケーラビリティ、最適化されたユーザー普及戦略を確実に行い、より良いROIをもたらし、ユーザーと開発者の両方の摩擦を減らします。
パスキーソリューションを構築する上での最大の課題は何か?
社内のパスキーシステムを開発するには、WebAuthn、マルチデバイスサポート、パスキー普及に関する深い専門知識が必要です。継続的なデバイスとブラウザの複雑さを維持し、高い普及率を確保することは、複雑さをさらに増大させます。
パスキーを社内で実装する際のリスクは何か?
企業は、高い開発コスト、長引く導入スケジュール、継続的なセキュリティメンテナンスの負担といったリスクに直面します。コンプライアンス違反、セキュリティの脆弱性、低いユーザー普及率は、パスキー導入の成功を狂わせる可能性があります。ベンダーが管理するパスキーソリューションは、組み込みのセキュリティと規制コンプライアンスを備えた、実証済みでスケーラブルな認証インフラストラクチャを提供することで、これらのリスクを軽減します。
Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey 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エキスパートに相談する →
内製化には、高度なWebAuthnの専門知識、継続的なブラウザやデバイスの互換性管理、専任のセキュリティメンテナンスが必要です。企業は、導入スケジュールの長期化、コンプライアンス違反、低いユーザー普及率などのリスクを負います。銀行や医療などの規制の厳しい業界では、PSD2、HIPAA、NISTへの準拠がさらに複雑さを増しますが、パスキーベンダーはこれらに継続的に対応しています。
組織は、パスワードを廃止する前に、アクティブユーザーの50〜80%がパスキーで認証している状態にする必要があります。時期尚早にパスワードを廃止すると、サポートへの問い合わせやユーザビリティの問題が増加します。段階的なアプローチでは、ユーザーが継続的にパスキー経由で認証しているアカウントから開始し、複数のナッジ(複数回のプロンプトによりモバイルでの受け入れ率は最大85%に達します)を活用し、データ主導のインサイトに基づいて拡大していきます。
パスキー受け入れ率(ベンチマーク:初回ナッジで50〜75%、複数回ナッジでモバイルでは最大85%)や、ほぼ100%を目標とする作成成功率などの入力KPIを追跡します。出力KPIとしては、数週間以内に20%以上、12か月で50%以上のパスキーログイン率を目標とします。すべての指標をOS、ブラウザ、デバイスごとにセグメント化し、摩擦のポイントを特定します。
ほとんどのパスキープロジェクトは、技術的な問題よりも、ユーザーの普及率の低さによって失敗します。パスワードへの依存が続くと、セキュリティのメリットが損なわれ、SMS OTPやパスワードリセットの削減によるコスト削減効果が失われ、ユーザーエクスペリエンスが分断されます。GoogleやAmazonは、普及を明確なターゲットとした継続的なA/Bテスト、UIナッジ、構造化されたユーザー教育キャンペーンを通じてこの問題に対処しています。
銀行、医療、政府機関、eコマース、通信、保険セクターは、PSD2、HIPAA、NISTなどの規制要件と、大規模なユーザーベース、複雑なレガシーインフラストラクチャが組み合わさっているため、パスキーベンダーソリューションから最も恩恵を受けます。Amazonは、100%のパスキー普及とパスワードの完全な廃止という目標を設定しており、これらの導入が必要とするコミットメントの規模を示しています。
関連記事
目次