2026 年 5 月、Google I/O 2026 のセッション Modernize authentication with passkeys, digital credentials, and more（Chrome Developers 2026-05-21） で、**パスキー（WebAuthn/FIDO2）とデジタルクレデンシャルが「Web ログインの新しい標準」として改めて打ち出されました。ブラウザ横断の同期、条件付き UI（Conditional UI）、デジタル ID の提示まで含めた認証体験が一気に整備され、「パスワードを残す合理的な理由が薄れていく」**潮流が決定的になりつつあります。
弊社では受託で 「ログイン認証をパスワードレスにしたい」という相談が、ここ半年で目に見えて増えています。とはいえ自社の情シスだけで WebAuthn の実装・端末リカバリ設計・レガシー対応まで握り切るのは負荷が高く、設計から運用保守まで受託で支えるのが現実解です。本記事では、認証の土台を扱う前提知識として Web セキュリティの基礎 を踏まえつつ、SaaS 認証基盤の移行受託プレイブック の延長線上で「企業パスワードレス認証移行」を整理します。
なぜ「パスキーが分水嶺」なのか
パスワード＋SMS（OTP）認証とパスキー/パスワードレスを、受託で説明するときの観点で並べると差は明確です。
| 観点 | パスワード＋SMS 認証 | パスキー / パスワードレス |
|---|---|---|
| フィッシング耐性 | 弱い（入力情報を抜かれる） | 強い（オリジン束縛で原理的に流出しない） |
| 運用コスト | リセット対応・SMS 送信費が継続発生 | 端末側完結でランニングが下がる傾向 |
| UX | 入力・待ち時間・離脱が多い | 生体認証でワンタップ、離脱が減る傾向 |
| リカバリ | 「秘密の質問」など脆弱な経路が残る | 設計次第（複数端末同期＋代替経路が前提） |
| 対応ブラウザ | ほぼ全環境 | 主要モダンブラウザ・OS で広く対応済み |
| クレデンシャル管理 | サーバに秘密情報を保持 | 公開鍵のみ保持、漏洩時の被害が小さい |
ポイントは 「パスワードを盗む」攻撃が原理的に成立しにくくなることです。フィッシングや総当たり、使い回しによる被害は依然として深刻とされており、サーバ側に秘密を持たない設計へ移れることが受託で最も訴求しやすい価値になります。
受託案件で活きる 3 つの構造変化
構造 1: 「認証は内製」から「設計は受託」へ
WebAuthn の RP（Relying Party）実装、端末紐付け、同期パスキーと端末固有パスキーの使い分けは、一度の構築で終わらず継続的な設計判断を要します。情シスが日常運用で抱えるには重く、設計・実装を受託、運用は共同という分担が定着しつつあります。土台のリスク整理は Web セキュリティの基礎 の考え方をそのまま使えます。
構造 2: ログイン UX が「事業 KPI」になった
パスワードレス化は単なるセキュリティ施策ではなく、ログイン離脱率・コンバージョンに直結します。入力ストレスの削減という意味では 入力フォーム最適化（EFO） と同じ発想で、「認証は最大のフォーム」として CV 改善の文脈で語れるのが受託の提案力になります。
構造 3: 認証基盤の「内製化／脱 SaaS」志向
価格変動やデータ主権の観点から、認証を自前で握る動きが続いています。SaaS 認証基盤の移行受託プレイブック で扱った「認証層を独立コンポーネントとして握る」発想は、パスキー導入でも同じです。IdP を握りつつパスキーを足す設計が現実的な落としどころになります。
受託で提供する「企業パスワードレス認証移行」5 フェーズ
フェーズ 1: 現状診断
- 既存認証方式（パスワード／SMS／TOTP／SSO）の棚卸し
- 対象ユーザー層・端末・ブラウザ分布の把握
- リスク評価（フィッシング・リセット工数・離脱率）
- 移行スコープと優先アカウント（管理者・一般・外部）の確定
フェーズ 2: 設計
- IdP／RP の構成設計、同期パスキー vs 端末固有の方針決定
- リカバリ経路（複数端末・代替認証・サポート窓口）の設計
- フォールバック認証（移行期間の併用）方針
- 監査ログ・権限設計、デジタルクレデンシャル活用の検討
フェーズ 3: PoC
- 限定ユーザーで WebAuthn 登録・認証フローを実装
- Conditional UI（自動補完ログイン）の動作検証
- 端末・ブラウザ横断の互換性テスト
- 計測ポイント（登録率・成功率・離脱）の埋め込み
フェーズ 4: 段階移行
- オプトインでのパスキー登録誘導 → デフォルト化
- パスワードは「無効化」ではなく「段階的縮退」
- ヘルプデスク向けの運用手順・FAQ 整備
- 移行率・問い合わせ数のモニタリング
フェーズ 5: 運用レビュー（継続）
- 月次での登録率・認証成功率・インシデントのレビュー
- ブラウザ／OS のアップデート追従
- リカバリ経路の不正利用監視
- パスワード完全廃止に向けたロードマップ更新
受託向け技術スタック標準セット
| レイヤ | 推奨 | 代替 |
|---|---|---|
| IdP / 認証基盤 | 既存 IdP に WebAuthn を追加 | 自前 RP 実装（OSS 認証ライブラリ） |
| パスキー基盤 | プラットフォーム標準（OS・ブラウザの同期パスキー） | FIDO2 セキュリティキー（高保証アカウント向け） |
| デジタルクレデンシャル | ブラウザの ID 提示 API を将来対応として設計 | 当面は標準 OIDC で代替 |
| フォールバック認証 | TOTP（認証アプリ） | マジックリンク（移行期間限定） |
| 監査ログ | 認証イベントの集中ログ＋アラート | SIEM 連携 |
| 計測 | 登録率・成功率・離脱のダッシュボード | 既存解析ツールにイベント送信 |
技術名はプロダクト構成に合わせて選定します。「最新を全部入れる」より、移行期間の併用を前提に枯れた構成で固めるのが受託の鉄則です。
どの案件に必要か / 不要か
| 移行を推奨するケース | 急がなくてよいケース |
|---|---|
| 会員 / 顧客ログインを持つ BtoC・BtoB SaaS | ログインのない静的サイト |
| パスワードリセット問い合わせが多い | ユーザー数が少なく運用負荷が軽い |
| フィッシング・なりすましリスクが高い業界 | 短命なキャンペーンサイト |
| ログイン離脱率を改善したい | 既に SSO で十分に運用できている |
| 管理者・特権アカウントの保護を強化したい | 認証要件が極めて単純 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 移行スコープ | 対象アカウント・併用期間・完全廃止の有無 | パスワード廃止時期の合意 |
| リカバリ責任 | 端末紛失時の復旧手順と責任分界 | サポート窓口の運用主体 |
| 互換性保証 | 対応ブラウザ・OS・最低要件の明記 | 非対応端末ユーザーの扱い |
| セキュリティ要件 | ログ保管・監視・インシデント対応 | 通報フローと SLA |
| 運用保守 | 月次レビュー・アップデート追従の範囲 | 保守の終了条件 |
| データ取り扱い | 公開鍵・認証イベントの保管と委託範囲 | 個人情報の取扱責任 |
特に 「リカバリ責任」と「パスワード完全廃止の時期」は揉めやすい論点です。契約段階で明文化しておくことが、受託・顧客双方を守ります。
価格モデル — 企業パスワードレス認証移行パッケージ
| プラン | 内容 | 目安価格（税別） |
|---|---|---|
| 診断 / PoC | 現状診断・移行設計・限定 PoC | 150 万円〜 |
| Lite（月額） | 監視・軽微改修・月次レビュー | 15 万円/月〜 |
| Standard（月額） | 運用＋改善提案＋互換性追従 | 35 万円/月〜 |
| Enterprise（月額） | 複数システム・特権管理・SLA 強化 | 80 万円/月〜 |
| 初期構築（一括） | 設計〜段階移行までの一括構築 | 500 万円〜 |
金額は案件規模・対象ユーザー数・既存構成により変動します。「初期構築＋運用月額」の組み合わせを基本とし、診断のみのスポット契約から始める案件が多い傾向です。
顧客側 ROI 試算
| 効果項目 | 試算の考え方 |
|---|---|
| パスワードリセット問い合わせ削減 | 月間リセット件数 × 1 件あたり対応工数の削減 |
| フィッシング被害削減 | 原理的にフィッシング耐性が高まり被害リスクが低下するとされる |
| ログイン離脱率改善 | ワンタップ認証で離脱率が下がる傾向 → CV 増 |
| ヘルプデスク工数削減 | リセット・ロック解除対応の削減で人件費を圧縮 |
| SMS 送信費削減 | OTP 送信費の継続コストを縮減 |
たとえばヘルプデスク時給を 3,000 円と仮定し、パスワード関連の問い合わせ対応が月 100 件・1 件 15 分削減できれば、月あたり約 7.5 万円（年間 約 90 万円）の工数削減になります。離脱率改善による CV 増を加味すると、初期構築費は概ね 1〜2 年程度で回収できるレンジに収まる案件が多い、というのが受託での目安です（数値は前提により変動します）。
ハマりやすい 5 つの落とし穴
落とし穴 1: パスワード完全廃止を急ぎすぎる
いきなりパスワードを無効化すると、非対応端末や登録未完了ユーザーが締め出されます。「縮退 → 任意 → 既定 → 廃止」の段階設計が必須です。
落とし穴 2: リカバリ設計の欠如
端末紛失・機種変更時の復旧経路を用意しないと、サポートが破綻します。複数端末同期＋代替認証＋有人窓口を最初から設計します。
落とし穴 3: レガシーブラウザ・端末
古い端末や法人管理下の制限ブラウザでは挙動が異なります。最低要件の明記とフォールバックを契約に含めます。
落とし穴 4: 共有端末・キオスク
複数人で使う端末では同期パスキーが噛み合いません。共有端末は別認証方式として切り分けます。
落とし穴 5: 管理者アカウントの扱い
特権アカウントは保証レベルを上げる必要があります。セキュリティキーの併用や追加検証を設計し、一般ユーザーと同列にしないことが重要です。
90 日アクションプラン
| 週 | 主なタスク |
|---|---|
| Week 1〜2 | 現状診断・ユーザー/端末分布の把握 |
| Week 3〜4 | 移行設計・リカバリ／フォールバック方針確定 |
| Week 5〜6 | PoC 実装（限定ユーザーで登録・認証） |
| Week 7 | 互換性テスト・計測ポイント整備 |
| Week 8〜9 | オプトイン提供開始・運用手順／FAQ 整備 |
| Week 10〜11 | 既定化（新規はパスキー優先）・モニタリング |
| Week 12 | 移行率レビュー・改善反映 |
| Week 13 | 運用保守へ移行・廃止ロードマップ更新 |
まとめ
Google I/O 2026 の発表が示すとおり、パスワードレスはもはや「先進的な選択」ではなく「標準への移行」です。とはいえ、設計・リカバリ・レガシー対応・運用までを自社だけで握り切るのは負荷が高く、診断から運用保守までを受託で支えることで、安全かつ離脱を増やさずに移行を進められます。「まず現状診断から」というスポット相談も歓迎です。自社のログイン刷新を検討中の方は、ぜひ お問い合わせフォーム からご相談ください。
Sources
- Modernize authentication with passkeys, digital credentials, and more（Chrome Developers 2026-05-21）: https://developer.chrome.com/blog/io26-web-identity?hl=en
- Web セキュリティ入門
- Better Auth/Supabase/Clerk 認証移行受託
- EFO（入力フォーム最適化）
