パスキーとは？パスワードレス認証の仕組み・効果・自社サービスへの入れ方

パスキーは、パスワードそのものを“なくす”次の認証標準です。指紋や顔、PINで端末を解錠する感覚でログインでき、しかも設計の段階からフィッシングに強いという、これまでの認証にはなかった性質を持ちます。これは実験段階の技術ではなく、日本でもメルカリ・NTTドコモ・Yahoo! JAPAN・KDDIといった大手が、すでに数百万〜数千万規模で本番導入しています。この記事では、パスキーが実際にどう動くのか（登録と認証の中身）を標準仕様に沿って解き明かし、なぜフィッシングに強いのかを構造から説明したうえで、自社サービスにどう入れるか（自前かIDaaSか、既存ログインとどう併存させるか）までを整理します。

パスキーとは——「盗めるパスワード」が存在しない

パスキーは、FIDO標準（FIDO2）にもとづく認証情報です。中身は公開鍵暗号方式で、パスワードのように「一つの秘密文字列」を覚えて送るのではなく、登録のときに端末で「秘密鍵」と「公開鍵」のペアを作るところから始まります。そして公開鍵だけをサーバに預け、秘密鍵は端末の外に一切出しません。ログイン時は、サーバからの“問いかけ”に端末内の秘密鍵で署名して返し、サーバが預かる公開鍵で確かめます。つまり、パスワードのような“共有された秘密”をネットワークに流さない——これが本質です。

秘密鍵の置き場所も重要です。秘密鍵は、スマートフォンやPCのセキュアエレメント——AppleのSecure Enclave、Windows／AndroidのTPMや同等のセキュアな領域——に格納され、生体認証やPINで解錠したときにだけ署名に使われます。アプリやOSから鍵そのものを読み出すことはできません。ここでよくある不安に答えておくと、生体認証は端末の中で秘密鍵を解錠するために使われるだけで、指紋や顔のデータがサーバに送られることはありません。生体は「本人がその場にいる」証明であって、鍵そのものではないのです。

パスワードは「サーバとユーザーが同じ秘密を共有する」方式ですが、パスキーは「秘密を誰とも共有しない」方式です。だから、盗んで持ち去れるものが存在しません。

この違いは、情報漏えいが起きたときにはっきりします。パスワード方式では、サーバがパスワード（のハッシュ）を保管しているため、データベースが破られれば認証情報そのものが流出します。パスキーでサーバが持つのは検証用の公開鍵だけで、そこから秘密鍵は割り出せません。万一サーバ側が漏れても、攻撃者の手に渡るのは“それだけでは何にも使えない鍵”です。

WebAuthnはどう動くのか——登録と認証、二つのセレモニー

パスキーの動きは、標準仕様（W3CのWebAuthn）で二つの「セレモニー」として定義されています。一つはパスキーを作る登録セレモニー、もう一つはログインする認証セレモニーです。ここを具体的に追うと、「なぜ中継されないのか」まで腑に落ちます。

登録セレモニー——パスキーを作る

まず、ユーザーが「パスキーを作成」を選ぶと、サービス側サーバ（仕様ではRP＝Relying Party、依拠当事者と呼びます）が一度きりの乱数「チャレンジ（challenge）」を発行します。あわせて、対象アカウントの情報、サービスのドメインを表すRP ID、使ってよい暗号アルゴリズムなどをブラウザに渡します。次に、ブラウザが navigator.credentials.create() を呼び、その要求を認証器（authenticator）——スマホの生体センサ、PCのTPM、USBセキュリティキーなど——に引き渡します。

続いて認証器は、生体やPINで本人確認を求めたうえで、このサービス専用の鍵ペアを新しく生成します。秘密鍵は認証器の中に閉じ込めたまま、公開鍵と、その鍵を識別するcredential IDを返します。このとき認証器は、「この鍵は正規の認証器が作った」ことを示すattestation（構成証明）を付けることができます。ブラウザに戻るのは PublicKeyCredential というオブジェクトで、この中に公開鍵・credential ID・attestation が入っています。最後にサーバは、返ってきたチャレンジが自分の発行したものと一致するか、RP ID が正しいかなどを検証し、問題なければ公開鍵と credential ID をそのアカウントに保存します。これで登録は完了です。

認証セレモニー——パスキーでログインする

ログインのときは、この逆をたどります。まずサーバがまた新しいチャレンジを発行し、必要に応じて「このアカウントで使える credential ID の一覧」を添えてブラウザに渡します。ブラウザは navigator.credentials.get() を呼び、認証器が生体・PINで本人確認を行ったうえで、保存済みの秘密鍵でチャレンジなどに署名します。返るのは assertion（アサーション）で、署名・認証器データ（authenticatorData）・クライアント側の文脈情報（clientDataJSON）が含まれます。署名は、この authenticatorData と clientDataJSON に対して生成されます。

そしてサーバは、登録時に保存した公開鍵でこの署名を検証します。ここで確認するのは署名の正しさだけではありません。(1) チャレンジが自分の発行した最新のものと一致するか（過去の通信を録って使い回す“リプレイ”を防ぐ）、(2) origin——実際にアクセスされたサイト——が正しいか、(3) RP ID が登録時と一致するかを、あわせて突き合わせます。これらがすべて通って初めてログインが成立します。

毎回のログインで、サーバは「新しいチャレンジ」に対する「その場の署名」を検証します。だから、通信を丸ごと録画しても後から再利用できません。

FIDO2の二層構造——WebAuthnとCTAP2、そしてフィッシング耐性の正体

パスキーを支えるFIDO2は、実は二つの仕様が組み合わさった二層構造です。上の層が、いま説明したWebAuthn（W3C策定）で、ブラウザ⇄サーバ（RP）のあいだのAPI（navigator.credentials を呼ぶ部分）を定めます。下の層がCTAP2（Client to Authenticator Protocol、FIDO Alliance策定）で、ブラウザ／OS（クライアント）⇄認証器のあいだの通信を、USB（HID）・NFC・BLE（Bluetooth Low Energy）といったトランスポートの上で定めます。認証器には、端末内蔵のプラットフォーム認証器（Touch ID、Windows Hello、Androidの生体センサ）と、持ち運べるローミング認証器（USBセキュリティキーなど）があり、どちらも同じ二層の上で機能します。

この構造こそが、フィッシング耐性の正体です。理由は二つあります。第一に、秘密鍵が端末のセキュアエレメントから出ず、サーバ側も公開鍵しか持たないため、そもそも“抜き取って持ち去れる認証情報”が存在しません。サーバを破っても利用者を騙して入力させても、手に入るのは使い回せる秘密ではありません。第二に、資格情報が RP ID（オリジン）に束縛されているため、認証器は「登録された RP ID からの要求」にしか署名しません。見た目がそっくりな偽サイトは別ドメインなので RP ID と origin が一致せず、そもそも署名が出ません。本物そっくりのページを挟んで裏で本物へ中継しようとしても、origin の検証で弾かれます。FIDOがこれを「設計上のフィッシング耐性」と呼ぶのは、運用の注意ではなく仕組みそのものが中継を無効化するからです。

ユーザー検証（UV）とユーザー存在（UP）は別物です

実装時に混同しやすいのがユーザー存在（UP＝User Presence）とユーザー検証（UV＝User Verification）の違いです。UPは「誰か（人）がその場にいて操作した」ことの確認で、ボタンのタップやセンサへの接触などがこれにあたります。人がそこにいる、という最小限の証明です。一方UVは「その本人か」の確認で、生体認証やPINで所有者本人であることを確かめます。パスキーは通常UVを伴うため、端末を“持っている”所持の要素と、生体／PINという本人確認の要素を、一つの操作で同時に満たす多要素認証になります。

なぜ、そこまで効くのか——実データで見る

パスワードレス化は、セキュリティを高めるだけでなく、“ログインの通りやすさ”そのものを改善します。各社が実測値を公表しています。Googleはパスワード比でサインイン成功率が約4倍に改善したと報告し、Microsoftは自社でパスキー約98%対パスワード約32%という成功率の差を示しました。速度でも、Amazonが約6倍、Microsoftがパスワード＋多要素認証比で約8倍の高速化を報告しています。侵害の多くは認証情報の窃取から始まります。“パスワードを無くす”ことは、この攻撃面を根本から断つ発想なのです。

日本でも、もう「大手が本番導入」しています

これは海外だけの話ではありません。FIDO Allianceが公開する導入実績（World Passkey Day 2025）を見ると、国内大手の本番運用が並びます。メルカリはパスキー登録が約900万人に達し、対象サービスで2023年3月以降フィッシング被害ゼロと報告。Yahoo! JAPAN（LINEヤフー）は約2,800万人が利用し、スマホ認証の約半分がパスキーで、SMSより約2.6倍速いとしています。NTTドコモはdアカウント認証の50%超がパスキー、KDDIはau IDでのFIDO利用が1,360万人を超え、カスタマーサポートへの問い合わせが約35%減ったと報告しています。導入が“実績と効果”の段階に入っていることが、これらの数字から読み取れます。

同期パスキーとデバイスバインド——どちらを選ぶか

パスキーを設計するうえで避けて通れないのが、鍵をクラウド同期させるか、端末に固定するかの選択です。同期パスキーは、iCloudキーチェーンやGoogleパスワードマネージャーが鍵を暗号化してクラウド経由で複数端末に同期します。機種変更しても新端末で“そのまま使える”のが利点で、端末を失っても別端末から復元できるためリカバリ負荷が小さく済みます。一方のデバイスバインド型（端末固定）は、USBセキュリティキーなどの認証器に鍵を固定し、同期させません。鍵が単一デバイスから出ないぶん可用性を厳密に管理でき高い保証に向きますが、その端末を失えば鍵も失われるため予備の登録が前提になります。

実務上は、一般消費者向けサービスでは同期パスキーが利便性と復旧性で有利で、まずここから始めるのが素直です。そのうえで、管理者や特権操作など高い保証が要る箇所に限ってデバイスバインドのセキュリティキーを併用する組み合わせが現実的です。役割ごとに要求水準を分ける設計が効いてきます。

ログイン体験を決める二つの仕組み——条件付きUIとクロスデバイス認証

パスキーが「使いやすい」と感じられるかどうかは、二つの仕組みが握っています。どちらも、既存のログイン画面や別端末を無理なくつなぐための工夫です。

条件付きUI（オートフィル）——ログイン欄に候補を出す

一つ目は条件付きUI（仕様上は条件付きメディエーション、体感としてはオートフィル）です。ユーザーがログイン欄をタップすると、ブラウザとOSが協調して、「このサイトで使えるパスキー」を、ユーザー名欄の下にプライバシーを保った候補として並べます。仕組みとしては、入力欄に autocomplete="webauthn" を付け、ページ表示時に navigator.credentials.get() を mediation: "conditional" で待機させておきます。すると、ユーザーが欄を選んだときにだけ候補が現れ、選べばそのままログインできます。専用のボタンを押さないと何も起きない従来のUIより、既存のログイン画面に自然に溶け込むのが利点です。ユーザーIDを先に入力しなくても候補を出せるのは、パスキーが「先にIDを言わなくても認証器側で見つけられる」ディスカバラブルな資格情報だからです。

クロスデバイス認証——スマホを“その場の認証器”にする

二つ目はクロスデバイス認証です。手元のPCにパスキーが無くても、スマホをその場の認証器として使い、署名できます。これはCTAP2.2のハイブリッド・トランスポートで実現します。まずPCの画面にQRコードが表示され、スマホのカメラで読み取ります。次にPCとスマホがBLE（近接無線）で“物理的に近くにある”ことを確認し、スマホ側で生体認証して署名し、暗号化された経路でPCに返します。ここでBLEは近接の確認に使われ、通信そのものの安全性は上位の暗号技術で守られます。だから、遠く離れた攻撃者がQRだけを盗んで“横取り”することはできません。共有PCや出先、いつもと違うブラウザでも、手持ちのスマホのパスキーでログインできます。これが「端末をまたいでも困らない」実用水準を支えています。

SMSやマジックリンクとは、何が違うのか

「パスワードレス」には他の手段もありますが、フィッシング耐性の“質”が違います。

SMS・マジックリンク・TOTPは、いずれも「コードやリンクをユーザーが介在させる」点が共通します。ユーザーが偽サイトにコードを入力すれば、攻撃者はそれをリアルタイムに本物へ中継できます。つまり弱点は使い方の注意ではなく、方式そのものに中継の余地があることにあります。これに対してパスキーは、前述のとおりオリジン（RP ID／origin）に署名が束縛され、偽サイトではそもそも署名が生成されないため、その中継を原理的に無効化できます。ここが本質的な差です。

自社サービスに、どう入れるか

ここが実務の分かれ目です。パスキー（FIDO2／WebAuthn）をゼロから自前で実装するのは負担が大きい——チャレンジの発行と検証、公開鍵と credential ID の保存、origin／RP ID の突き合わせまで自前で抱えることになります——ため、多くは認証基盤（IDaaS）に載せるのが現実的です。ただ、IDaaSごとにパスキー対応の成熟度が違う点には注意が要ります。

つまり「認証を作るか買うか」の判断が、そのままパスキー対応の可否と工数に効いてきます。ここは 「認証は作るか買うか」、会員基盤全体の設計は 「会員基盤の正しい作り方」 にまとめています。

入れ方でもう一つ大切なのが「一足飛びにパスワードを全廃しない」ことです。現実的なのは、既存のID基盤やソーシャルログイン（LINEログインなど）と“併存”させ、まずは追加の選択肢としてパスキーを提供する段階導入です。まず既存の方法でログインしたユーザーに追加でパスキーを登録してもらい、次回以降は条件付きUIで候補をさりげなく出して使う機会を増やす。登録率が上がった段階で、パスワードへの依存を段階的に薄めます。いきなり切り替えを強いるより、“便利だから自然に移る”流れを作るほうが、離脱もサポート負荷も抑えられます。

導入で外してはいけない設計——リカバリとフォールバック

効果が大きいぶん、設計を誤ると足をすくわれます。とりわけリカバリ（復旧）設計は、パスキー導入の“実務の要”です。ここを外すと、端末を失ったユーザーがログインできなくなり、サポート窓口への問い合わせが積み上がる——いわゆる「サポート地獄」に陥ります。パスキーは鍵が端末側にあるからこそ、端末を失ったときの備えを導入と同時に用意しておく必要があります。

備えの基本は三つです。第一に、一人に複数のパスキーを登録してもらうこと。予備の端末やセキュリティキーも登録しておけば、一つを失っても締め出されません。第二に、同期パスキーを活用すること。クラウド同期される鍵なら、機種変更や端末紛失があっても別端末から復元できます。第三に、フォールバック手段を安全に用意すること。既存のIDやメール確認など、パスキーが使えないときの代替経路を残します。

もう一つ、既存パスワードとの併存は必ず“移行計画”とセットで考えます。パスワードを残したままにすると、そこがフォールバック経由のフィッシングの弱点になり得ます。そこで「パスキー登録済みのユーザーはパスワードでのログインを段階的に制限する」といった移行完了の条件を先に決めておくことが重要です。パスキーを“足す”ところから始めつつ、最終的にパスワードへの依存をどう畳むか——その出口まで最初に描くことで、併存期間の弱点を最小限に抑えられます。

▶ 全体像は 「LINEログインとは？仕組み・できること・導入の判断」 にまとめています。

参考にした一次情報：FIDO Alliance（パスキー解説、CTAP2.2仕様、World Passkey Day 2025 導入実績ショーケース／日本語）、W3C WebAuthn（登録・認証セレモニーの定義）、各社公式（Google／Apple／Microsoft の開発者・セキュリティ情報、Amazon Cognito・Auth0・Firebase の公式ドキュメント）。数値は各社公表・執筆時点で、仕様・料金・対応状況は改定される場合があるため、実装時は最新の公式情報をご確認ください。