記事 Aug 14, 2026

パスキーとは何か〜パスワードに代わる新しい認証方式を整理した

パスキーについて仕組みやその他認証方式との違いを調査し、まとめました。

はじめに

最近多くのサービスで「パスキーでログイン」という選択肢を見かけます。指紋や顔認証でパッとログインできて便利、くらいの理解で使っている人も多いはずです。

かくいう私もその1人でした。

今回色々と調べてみた結果をまとめてみます。

パスキーとは

パスキー（Passkey）とは、公開鍵暗号方式を用いた、パスワードを使わないログイン方法です。

W3Cが策定したWebAuthnとFIDOアライアンスが策定したCTAPから成る FIDO2という標準規格の上に成り立っており、Apple・Google・Microsoftが共同で普及を推進しています。

利用者から見た体験はシンプルで、ログイン画面で指紋や顔、画面ロック用のPINなどを使って本人確認するだけです。メールアドレスとパスワードを入力していた従来のログインが、指紋や顔、PINでの本人確認一つに置き換わるイメージです。

注意したいのは、指紋や顔のデータそのものがサービス側に送信されるわけではないという点です。これらは端末をロック解除するための手段に過ぎず、認証の実体は次に説明する公開鍵暗号方式にあります。

よくある誤解

「パスキー＝生体認証」だと思われがちですが、生体認証は端末のロックを解除する手段の一つに過ぎず、PINやパターンでも同様に使えます。生体情報自体がパスキーの実体ではありません。前述の通り鍵ペアはサービスごとに独立して生成されるので、1つの指紋・顔データが全サービスで共有されるわけでもありません。

また、パスキーがあってもパスワードが完全に不要になるとは限りません。多くのサービスは移行期間中で、初回登録や復旧手段としてパスワードが残っていることが多いのが実情です。逆に「1つの端末でしか使えない」というのも誤解で、同期パスキーであれば同じアカウントでサインインした複数端末から利用できます。

パスワード認証との根本的な違い

パスワード認証とパスキーの最大の違いは、サービス側が「秘密の情報」を保持するかどうかです。

項目	パスワード認証	パスキー
サーバーが保持する情報	ストレッチング＋ソルト付きハッシュ値など	公開鍵（漏洩しても悪用不可）
利用者が管理する情報	パスワード（記憶 or パスワード管理ツール）	なし（秘密鍵は端末内のセキュアな領域で管理）
フィッシング耐性	低い（正規サイトと誤認すると入力してしまう）	高い（ドメインが一致しない限り認証できない）
使い回しのリスク	あり（同じパスワードを複数サービスで利用）	なし（サービスごとに異なる鍵ペアを生成）
総当たり・漏洩の影響	大きい（DB漏洩でパスワードが流出）	小さい（公開鍵だけが漏れても再現不可能）

パスワードは「サーバーと利用者の双方が同じ秘密を知っている」ことを前提にした仕組みです。だからこそ、サーバー側のデータベースが漏洩すれば大きな被害につながりますし、利用者がパスワードを使い回していれば他サービスへの攻撃にも波及します。

パスキーはこの前提そのものを取り払い、秘密の情報をサーバーに一切送らずに済むように設計されています。

SMS認証・認証アプリ（TOTP）との違い

「パスワード + SMSコード」や「パスワード + Google Authenticatorなどの認証アプリ（TOTP）」を多要素認証として使っている人は、パスキーとの違いがピンとこないかもしれません。

これらはあくまで「パスワードに追加でもう1要素を求める」仕組みであり、パスワード自体の弱点（使い回し・フィッシング耐性の低さ）は解消されません。

方式	仕組み	フィッシング耐性	主な弱点
パスワード + SMS認証	パスワード認証後、SMSで届く数字を入力	低い（偽サイトにパスワードとコードの両方を入力してしまう）	SIMスワップ詐欺、SMS傍受
パスワード + TOTP認証アプリ	パスワード認証後、30秒ごとに変わる数字を入力	低い（コードも偽サイトにそのまま入力できてしまう）	シード値の漏洩、偽サイトへのリアルタイム転送（中間者攻撃）
パスキー	秘密鍵による署名のみ	高い（ドメイン不一致だと認証情報自体を提示できない）	端末紛失時の復旧手段の設計が必要

SMSコードやTOTPのコードは「利用者が読み取ってサービスに入力する」文字列であるため、フィッシングサイトが即座にそれを正規サイトへ中継してしまう「リアルタイムフィッシング（Adversary-in-the-Middle）」を防げません。

一方、パスキーによる署名処理はブラウザとOSが仲介するため、そもそも利用者がコードを見て入力するという操作が発生しません。この「人間を経由しない」という点が、他の多要素認証とパスキーの本質的な違いです。

パスキーの仕組み　公開鍵暗号方式

パスキーの中核にあるのは公開鍵暗号方式です。

パスキーを登録すると、端末上で秘密鍵（Private Key）と公開鍵（Public Key）のペアが生成されます。秘密鍵は端末のセキュアエンクレーブやTPMなど、OSレベルで保護された領域に保存され、平文の状態で端末の外に取り出すことはできません。サーバーに登録されるのは公開鍵だけです。

なお、Apple/Googleなどが提供する「同期可能パスキー」の場合、秘密鍵に相当するデータはエンドツーエンドで暗号化された状態でクラウド（iCloud Keychain、Google Password Manager等）に同期され、他デバイスへ復元されます。一方、Microsoft Authenticator等で作成される「デバイスバウンド型パスキー」は、生成されたハードウェアから一切出ることなく、同期もされません。

ログイン時の流れは次のようになります。

サーバーがランダムな「チャレンジ」と呼ばれるデータを生成し、端末に送る
端末は生体認証やPINでロックを解除し、チャレンジと現在アクセスしているサイトのオリジン（ドメイン）情報を合わせて秘密鍵で署名する
端末は署名済みのデータをサーバーへ返す
サーバーは登録済みの公開鍵を使って署名を検証し、本人であることを確認する

秘密鍵がサーバーに送られることは一度もありません。仮にサーバーが不正アクセスを受けて公開鍵が流出したとしても、公開鍵だけから秘密鍵を復元したり、有効な署名を偽造したりすることは（数学的に）できません。（※ただし、公開鍵とアカウント情報の組み合わせ自体が漏洩することによる間接的なリスクは別途考慮が必要です）

WebAuthn / FIDO2との関係

パスキーは、ブラウザやOSが実装するWebAuthn APIを通じて利用されます。

// 登録時（イメージ）
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: base64UrlDecode(serverResponse.challenge), // サーバーが発行したチャレンジ
    rp: { name: "Example Service", id: "example.com" },
    user: {
      id: new Uint8Array([...]),
      name: "user@example.com",
      displayName: "Example User",
    },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }], // -7 = ES256（楕円曲線暗号）
  },
});

// 認証時（イメージ）
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array([...]),
    rpId: "example.com",
  },
});

WebAuthnはブラウザとOSが提供する標準APIであり、開発者が独自に暗号処理を実装する必要はありません。鍵の生成や署名、セキュアな保存は全てOSやブラウザ、認証器（Authenticator）が担当します。

※実装に関する細かい検証は別途別記事にて行う予定です。

パスキーがフィッシングに強い理由

パスワード認証がフィッシングに弱いのは、「利用者が偽サイトを本物だと信じて入力してしまう」ことが原因です。どれだけ複雑なパスワードを設定していても、偽サイトに入力してしまえば意味がありません。

パスキーではこの問題が構造的に発生しません。

登録時、パスキーはRP ID（Relying Party ID、多くの場合サービスのドメイン）と紐づけて生成されます。認証時、ブラウザは現在アクセスしているドメインとRP IDが一致するかを自動的に検証し、一致しない限り秘密鍵へのアクセスを許可しません。

例えばexample.comで登録したパスキーは、見た目のよく似たexamp1e.comのようなフィッシングサイトを利用者が偽サイトと気づかず訪問しても、ドメインが一致しないためブラウザはパスキーを提示すらしません。「だまされて認証してしまう」余地がそもそも存在しないわけです。

利用者の注意力に頼るのではなく、ブラウザとOSがドメインの一致を機械的にチェックする点が、パスワードとの決定的な違いです。

同期パスキーとデバイスに紐づくパスキー

すべてのパスキーがクラウド経由で同期されるわけではない点にも注意が必要です。iCloudキーチェーンなどクラウドに保存される「同期パスキー」は複数端末で共有でき、個人利用ではこちらが主流です。対して、端末やセキュリティキーの中にしか存在しない「デバイスに紐づくパスキー」は同期されず、紛失すると復元できません。YubiKeyのような物理セキュリティキーで作成したパスキーは、原則としてそのキーの外に出ません。紛失時の可用性よりも「鍵が絶対に外部へ漏れない」ことを重視する企業システムでは、こちらが選ばれることもあります。

プライバシー面のメリット

パスキーは安全性だけでなく、プライバシーの面でもいくつか利点があります。鍵ペアはサービス（RP ID）ごとに個別に生成されるため、複数のサービスで同じ鍵が使い回されることはなく、事業者間で利用者を突き合わせる識別子として悪用できません。指紋や顔のデータも端末内の処理だけに使われ、サービス側はもちろんOSベンダーにも送信されません。サーバーに保存されるのは公開鍵だけなので、パスワードのように「盗む価値のある情報」がそもそも存在せず、データベース漏洩時の影響範囲も大きく異なります。

「同じ生体情報が複数のサービスで共有されているのでは」という誤解を持つ人もいますが、実際には認証器の中で生成された鍵ペアがサービスごとに分離されており、生体情報そのものが外部とやり取りされることはありません。

実際のログインフロー

利用者視点でのログイン体験は次のようになります。

サービスのログイン画面で「パスキーでサインイン」を選択（あるいはメールアドレス入力のみで自動的に候補が表示される）
OSがパスキーの候補を提示する（登録済みのアカウント一覧など）
指紋・顔認証・PINで本人確認
ログイン完了

パスワードの入力欄自体が存在しないため、フォームにパスワードを打ち込む、コピー&ペーストする、といった操作は発生しません。

これまでは多要素認証（MFA）として別途SMSコードなどを求められることもありましたが、パスキー自体が「本人が所有する端末」と「生体情報またはPIN」を組み合わせた認証なので、単体で多要素認証相当の強度を持ちます。

なお、多くのブラウザは「Conditional UI（自動入力）」という仕組みに対応しており、ユーザー名の入力欄をタップした時点でOSが保存済みのパスキー候補を自動表示できます。利用者はログインボタンを押す前の段階でパスキーを選ぶだけでよく、パスワード用の入力欄をそのまま流用しながらパスキーへ段階的に移行できるのも特徴です。

自前でWebAuthnを実装するのが難しい場合は、Auth0やFirebase Authentication、Clerkといった認証基盤サービスの多くがパスキーに対応しており、それらを利用して段階的に導入する選択肢もあります。

対応状況と導入するかどうかの判断

2026年時点で、iOS/Android/Windows/macOSの主要OS、Chrome/Safari/Edge/Firefoxの主要ブラウザはいずれもパスキーに対応しています。

対応サービスも急速に増えています。Google / Apple / Microsoftはアカウント設定からパスキーを登録でき、GitHubは2段階認証の一種として対応、Amazon / PayPal / eBayといったECサイトでもログインに使えます。X（旧Twitter）もモバイルアプリでパスキーログインに対応しています。

一方で、次のような点は把握しておく必要があります。

サービス側の実装が必要: WebAuthnのAPIを利用したバックエンド・フロントエンドの実装が必要で、既存のパスワード認証システムに追加する形で段階的に導入するのが一般的
完全にパスワードを廃止できるとは限らない: 多くのサービスは移行期間としてパスワードと併用しており、パスキー単体で全利用者をカバーするにはまだ時間がかかる
アカウント復旧の設計が重要: 端末を全て紛失した場合の復旧手段（バックアップコードなど）を別途用意しておく必要がある
エンタープライズでの管理: 退職者の端末に残ったパスキーの無効化など、組織で導入する場合は運用ルールの設計が求められる
エコシステム間の移行: Appleの端末で作成した同期パスキーを、そのままGoogleのパスワードマネージャーへ直接エクスポートすることは現状できない。将来的にはCredential Exchange Protocol（CXP）のような業界標準による相互運用が見込まれているが、現時点では移行手段が限定的な点は認識しておく必要がある

パスキーは「便利になる」だけでなく、「フィッシングによる認証情報の窃取」という現在最も一般的な攻撃手法そのものを構造的に防げる点が、セキュリティ上の大きな利点です。

まとめ

パスキーの核は、秘密鍵を端末から一切出さず、サーバーには公開鍵しか渡さないという公開鍵暗号方式にあります。WebAuthn / FIDO2という標準規格の上に成り立っているので独自の暗号実装は不要ですし、ドメインの一致をブラウザ・OSが自動検証する仕組み上、構造的にフィッシングに強いのが最大の特徴です。SMSやTOTPと違って人間がコードを読み取って入力する過程自体がないので、リアルタイムフィッシングにも対応できます。

パスワードは長年Web認証の主役でしたが、使い回しやフィッシングといった弱点を利用者の注意力だけで解決するのには限界がありました。パスキーはそれを仕組みで解決しようとする現実的な代替手段で、今後も対応サービスは増えていくはずです。まずは自分のGoogleやAppleアカウントで一度試してみると、仕組みの理解が早いと思います。