パスキー（Passkey）とは？FIDO2の仕組みとパスワードレス認証を現場目線で解説

2026年5月24日

「パスワードが多すぎて覚えられない。かといって使い回しは危険だとわかっている…」

情シス担当者やエンジニアからそういった声をよく聞きます。パスワード管理の問題はもはやユーザーの心がけだけで解決できる話ではなく、認証の仕組みそのものを変えなければならない段階に来ています。

そこで急速に普及しつつあるのが「パスキー（Passkey）」です。Google・Apple・Microsoftの3社が足並みをそろえて対応を進め、国内でも金融機関や大手ECサービスで導入が始まっています。

この記事では、パスキーの仕組みと基盤となるFIDO2規格、従来のパスワードやSMS認証と比べたセキュリティ効果、そして中小企業でも今日から取り組めることを現場目線でお伝えします。

TOC

パスキーとは？「パスワードを使わない認証」の正体

パスキー（Passkey）は、パスワードを使わずにデバイスの生体認証やPINで本人確認を行う認証方式です。FIDO Alliance（ファイド・アライアンス）とW3Cが策定した「FIDO2」という国際規格を基盤にしており、Apple・Google・Microsoftが「パスキー」という共通名称のもとで標準化を推進しています。

仕組みの核心は公開鍵暗号にあります。サービスに登録するとき、デバイス側で「秘密鍵」と「公開鍵」のペアが生成されます。公開鍵はサービス側のサーバーに保存されますが、秘密鍵はデバイスのセキュアエンクレーブ（専用のセキュリティチップ）に格納され、外に出ることがありません。

ログイン時は、サービスが「チャレンジ（乱数）」を送り、デバイス内の秘密鍵でそれに署名して返します。サービスは公開鍵で署名を検証するだけなので、パスワードのような「共有された秘密情報」が通信上を流れることがないのです。これが従来の認証との根本的な違いです。

FIDO2の仕組みを3つの要素で理解する

パスキーを支えるFIDO2は、以下の3つの技術要素で構成されています。

1. WebAuthn（ウェブオータン）

W3Cが策定したWeb APIで、ブラウザとWebアプリケーションがFIDO2認証を利用するための標準インターフェースです。主要ブラウザ（Chrome・Safari・Firefox・Edge）はすべて対応済みです。JavaScriptのAPIとして呼び出せるため、Webサービス側の実装コストが大幅に下がっています。

2. CTAP（クライアントからオーセンティケーターへのプロトコル）

ブラウザ・OSと、実際に認証を担う機器（オーセンティケーター）の間の通信規格です。このプロトコルによって、スマートフォンの生体認証やYubiKeyのようなハードウェアトークンを、PCのブラウザで動くWebサービスの認証に使えるようになっています。

3. オーセンティケーター（認証器）の2種類

オーセンティケーターには2つの種類があります。

・プラットフォーム型（デバイス内蔵）: iPhoneのFace ID/Touch ID、AndroidのFingerprint/PIN、Windows Hello（顔・指紋・PIN）
・ローミング型（外付け）: YubiKeyなどのUSBハードウェアトークン、NFCキー

パスキーは通常、プラットフォーム型の認証器を使います。秘密鍵はデバイスのセキュアエンクレーブに格納されるため、OSやアプリからも直接読み出せない設計になっています。

なぜパスワード＋SMS認証よりも強いのか

フィッシングへの完全耐性

パスキーの最大の強みは「フィッシング耐性」です。従来の認証では、本物そっくりの偽サイトにアクセスしてしまった場合、パスワードとSMS OTPを入力してしまえば認証情報が盗まれます。

パスキーは、認証時に「どのサービスの鍵か」をドメイン名（オリジン）に紐付けて検証します。https://example.com に登録したパスキーは、偽サイトの https://examp1e.com では絶対に機能しません。ユーザーが気づかなくても、技術的な仕組みがフィッシングをブロックするのです。

サーバー漏洩が起きても悪用できない

パスワードは、サービスのデータベースにハッシュ化されて保存されています。そのデータベースが漏洩した場合、強力なハッシュでもブルートフォース攻撃や辞書攻撃のリスクがあります。

パスキーでは、サーバーには公開鍵しか保存されません。公開鍵は名前の通り「公開しても問題ない」情報なので、データベースが漏洩しても攻撃者がなりすましに使うことは原理的にできません。

パスワードリスト攻撃の無効化

他サービスから流出した認証情報を使う「パスワードリスト攻撃」も、パスキーには通用しません。秘密鍵はデバイスから出ないため、そもそも「流出する情報」が存在しないからです。

SIMスワッピングへの耐性

SMS OTPを使うMFAは「SIMスワッピング攻撃」（電話番号を別のSIMに不正に移行させてOTPを傍受する手口）に弱い面があります。パスキーはSMSを使わないため、この攻撃が成立しません。

パスキーの具体的な利用・導入手順

1. 個人ユーザーとしてパスキーを登録する

Google・Apple ID・GitHub・Microsoft・Yahoo! Japanなど多くのサービスで、アカウント設定の「セキュリティ」または「パスワード」セクションからパスキーを登録できます。

Googleアカウントでの登録手順：

# 1. https://myaccount.google.com にアクセス # 2. 「セキュリティ」→「パスキーとセキュリティキー」を開く # 3. 「パスキーを作成する」をクリック # 4. デバイスの生体認証（指紋・顔認証）またはPINで確認 # 5. 登録完了 → 次回からパスワード入力なしでサインイン可能

2. 企業のWebアプリにWebAuthnを実装する

自社サービスや社内ツールにパスキー認証を組み込む場合、WebAuthn対応ライブラリを使います。

・Python（サーバー側）: py_webauthn
・Node.js: SimpleWebAuthn、@simplewebauthn/server
・Java: webauthn4j
・PHP: web-auth/webauthn-framework
・SaaS認証基盤（実装ほぼ不要）: Okta、Auth0、Firebase Authentication

SaaSの認証基盤を使えば、WebAuthnの実装はほぼゼロです。Oktaであれば管理画面でFIDO2を有効化するだけで、既存のSSOに組み込めます。

3. パスキーのクラウド同期と注意点

AppleはiCloud Keychain、GoogleはGoogle Password Managerを通じて、パスキーを同じエコシステムのデバイス間で同期します。iPhone・MacBook・iPadといった同一Apple IDのデバイスであれば、登録したパスキーを共有できます。

現時点での注意点として、異なるエコシステム間（AppleデバイスからAndroidへの乗り換えなど）のパスキー転送は標準化の途中です。FIDO AllianceはCross-Device Credential仕様の策定を進めており、今後改善される見込みです。

中小企業の情シスが今日からできること

・Google WorkspaceやMicrosoft 365でパスキーを有効化する: 管理者コンソールからパスキーを有効化するだけで、従業員はスマートフォンの生体認証でサインインできるようになります。追加費用は不要です。
・FIDO2対応のSSO製品を選ぶ: SSO（シングルサインオン）製品の選定時にFIDO2対応を要件に加えることで、社内システム全体のフィッシング耐性を一元的に高められます。
・ハードウェアキーは管理職・特権ユーザーから優先配布: 予算が限られる場合は、管理者アカウントや財務・経営情報にアクセスする従業員から優先的にYubiKey等を配布するのが費用対効果の高い施策です。YubiKey 5シリーズは1本6,000円前後で入手できます。
・デバイス紛失時の復旧フローを事前設計する: パスキー運用で最も重要な運用設計のひとつが、デバイス紛失・故障時のアカウント復旧手順です。バックアップコードの発行や、サポート経由の本人確認フローを事前に整備しておきましょう。

よくある誤解と注意点

誤解1：「スマホを無くしたらアカウントに入れなくなる」

パスキーはクラウドに同期されるため、同じApple IDやGoogleアカウントに紐付いた別デバイスからログインできます。また、多くのサービスは代替手段としてメール確認や本人確認フローを残しています。デバイス紛失時の復旧方法はサービスごとに事前に確認しておくことが大切です。

誤解2：「まだ対応しているサービスが少ない」

2025年時点で、主要なプラットフォームやSaaSのパスキー対応は急速に広がっています。ただし、社内の業務システムや中小規模のSaaSはまだ非対応のケースもあります。現時点では「パスワード＋MFAとパスキーの並行運用」が現実的な移行ステップです。

誤解3：「生体情報がサーバーに送られる」

生体情報（指紋・顔データ）はデバイスの外に一切出ません。サーバーには公開鍵だけが保存されます。「パスキーを使うと指紋がGoogleに送られる」という心配は不要です。

誤解4：「MFAがあれば十分で、パスキーは必要ない」

SMS認証はSIMスワッピング攻撃に弱く、TOTP（Google Authenticator等）はリアルタイムフィッシングによるOTP奪取に弱い面があります。パスキーはこれらの弱点を技術的な仕組みで解消した「フィッシング耐性MFA」と位置付けられます。MFAを使っていても、さらに強固な認証への移行を検討する価値は十分にあります。

本記事のまとめ

比較項目	パスワードのみ	パスワード＋SMS OTP	パスワード＋TOTP	パスキー（FIDO2）
フィッシング耐性	なし	低（SMSフィッシング有効）	低（リアルタイムOTP奪取可）	完全耐性
パスワードリスト攻撃	脆弱	やや脆弱	やや脆弱	無効化
SIMスワッピング	対象外	脆弱	対象外	対象外
サーバー漏洩時のリスク	高（ハッシュ解析可）	高	中	低（公開鍵のみ保存）
ユーザー体験	複雑	やや複雑	やや複雑	最もシンプル
中小企業の導入コスト	低	低～中	低～中	中（SaaS活用で低）

パスキーは「ユーザーが楽になる」だけでなく、「フィッシングが通用しない」という技術的な特性を持つ点で、これまでの認証改善策とは次元が異なります。すべてのシステムを一度に移行する必要はありませんが、まずはGoogle WorkspaceやMicrosoft 365といった既存ツールでパスキーを有効化するところから始めてみましょう。

Linuxサーバーの認証強化（SSH鍵認証・PAM設定）については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。合わせてご覧ください。