パスキー導入の手順｜パスワードレスへ段階的に移行する方法

パスキーは、フィッシングに強く、利用者がパスワードを覚えなくてよい認証方式です。主要な OS とブラウザが対応し、銀行や EC でも一般的になりました。一方で、すでに何万人もの利用者がパスワードでログインしているサービスに入れる場合、「ボタンを足して終わり」にはなりません。登録をどう促すか、パスワードといつまで併存させるか、端末を失くした人をどう救うか。ここでは既存サービスへの導入を 4 つの段階に分け、各段階で決めておくことを整理します。

第 1 段階｜パスキーの仕組みと導入方針の決定

パスキーは公開鍵暗号を使います。利用者の端末に秘密鍵、サービス側に公開鍵を置き、ログインのたびにサービスが出す一回限りの課題に端末が署名します。秘密鍵は端末から出ず、署名はサービスのドメイン（RP ID）に結び付くので、偽サイトでは使えません。フィッシング耐性はここから来ています。

導入前に決めることは 3 つです。

• どの範囲に入れるか：一般利用者向けのログインか、管理者だけか。まず管理者や社内利用から始め、次に一般利用者へ広げる順が無難です
• パスワードをいつ止めるか：止めない（併存し続ける）、期限を決めて止める、利用者ごとに任意で止められるようにする、の 3 通りがあります。後述の第 4 段階で判断しますが、方針だけは先に置きます
• 自前で実装するか、外部の認証基盤を使うか：WebAuthn の登録・認証・失効・回復を自前で正しく作るには相応の工数がかかります。外部基盤を使う場合は、利用者のデータをどこまで預けるかを確認します

第 2 段階｜WebAuthn の組み込みと、パスキー登録を促す導線

技術的な組み込みは、ブラウザ側と自社サーバー側の 2 か所です。ブラウザ側は SDK が navigator.credentials の呼び出しと機種ごとの差を吸収し、サーバー側は登録・認証の「オプションの取得」と「結果の検証」を認証基盤へ中継します。ログイン画面は自社のものを使い続けられるので、見た目や導線を変える必要はありません。

登録の導線で効くのは、次の 3 点です。

1. ログイン直後に勧める：パスワードでログインした直後は本人確認が済んでいる状態です。「次回から顔や指紋でログインできます」と一度だけ勧めると、登録率が最も上がります
2. 登録は 1 タップで終える：端末名の入力や説明画面を挟まず、OS の生体認証ダイアログにすぐ進ませます
3. 後から登録できる場所を用意する：設定画面に「パスキー」の項目を置き、複数の端末を登録・削除できるようにします

第 3 段階｜パスワードとの併存期間の運用（回復手段と監査ログ）

パスキーを登録した人にも、しばらくはパスワードでのログインを残します。この期間に確認することは、登録率、パスキーでのログイン成功率、そして回復の問い合わせ件数です。

回復手段は併存期間のうちに整えます。 端末を失くした、機種変更で同期されなかった、といった問い合わせは必ず来ます。回復の入口は、メールや SMS への一時コードか、まだ有効なパスワードのどちらかです。同じ OS のアカウントで同期される「同期パスキー」を使う人は機種変更で困りませんが、同期していない端末しか登録していない人には、2 台目の登録を勧めておきます。

監査ログを見る習慣をつけます。 登録・認証・失効が誰に対していつ起きたかを記録し、成功率が急に落ちた端末や OS があれば SDK の更新やブラウザの不具合を疑います。月間のログイン利用者数（MAU）は料金にも関わる数字なので、あわせて見ておきます。

第 4 段階｜パスワード廃止（パスワードレス化）の進め方

パスキーの登録率とログイン成功率が十分に上がったら、パスワードを止める判断をします。全員一斉に止めるのではなく、次の順で進めるのが現実的です。

• パスキーを登録済みの利用者から、任意でパスワードを無効にできるようにする
• 新規登録の利用者にはパスワードを作らせず、パスキーだけで始めさせる
• 併存期限を決めて告知し、期限後はパスワードでのログインを回復用途だけに限る

パスワードを完全に止めると、パスワードリスト攻撃と、パスワード漏えい時の対応がなくなります。ただし回復の入口が残る限り、そこが弱点になります。回復のコードの有効期限を短くし、回復後は必ずパスキーの再登録を求める、という運用まで含めて設計します。

パスキー認証基盤（IDaaS）を選ぶときの確認点

外部の認証基盤を使う場合、機能一覧より先に次の点を確認します。

1. 利用者の何を預けるか：氏名やメールアドレスまで預けるのか、公開鍵と利用者 ID の対応だけで済むのか。後者なら、既存の会員データベースを動かさずに済みます
2. ログイン画面は自社のものか：認証基盤の画面へ遷移する方式だと、ブランドと導線が変わります
3. 料金の単位：月間のログイン利用者数か、登録端末数か、API リクエスト数か。端末数やリクエスト数で課金される方式は、利用者 1 人が複数端末を登録すると費用が読みにくくなります
4. データの所在：サーバーが国内にあるか、国外の事業者の規約に従うか

まとめ｜順番を守れば、止められる

パスキーの導入で失敗するのは、技術よりも順番です。登録の導線を作らずにボタンだけ置く、回復手段を用意せずにパスワードを止める、といったことを避ければ、パスワードを段階的に廃止できます。

シャノンでは、公開鍵と利用者 ID の対応だけを預かる純国産のパスキー認証基盤「SealGate」を提供しています。ブラウザ SDK と API で既存のログインにパスキーを追加でき、併存期限の設定、監査ログ、月間ログイン利用者数の確認まで管理画面で行えます。料金と機能の詳細はSealGate のサイトをご覧ください。既存サービスへの導入をご検討の方は、お問い合わせからご相談ください。