メインコンテンツへスキップ

用語比較

パスキーとパスワードの違い

一言でいうと

パスワードは文字列の秘密を使い、パスキーは登録先に結び付く公開鍵の仕組みで認証する。対応サービスでパスキーを選ぶ際は、同期型かデバイス固定型か、利用者確認、紛失時の復旧と既存の認証手段まで確認する。パスキーを追加しただけでパスワード廃止・全セッション失効まで完了するとは扱わない。

判断表を見る

パスキーとパスワードは何が違う?フィッシング耐性、保存、MFA、移行・復旧など7軸で比較します。同期型とデバイス固定型の選び方、Googleで既存の認証手段が残る条件、NISTの文字数要件を解説。紛失時の判断と4状態の確認、無料の復旧・失効記録で、個人と情シスの導入を支えます。

難易度
初級
想定読者
個人利用者・情シス・認証機能の提供者
所要時間
約12分
最終確認
2026-10-30
パスキーとパスワードの2枚のカードと確認項目を並べた、認証方式比較のイメージ図
CyberLens制作の既存図版。認証方式を比較するイメージで、生体情報、秘密鍵、実際の認証画面を表示するものではありません。
  • 1. 保存と利用先を確認

    同期型・固定型、保存プロバイダー、対象サービスと組織の方針をそろえる。

  • 2. 認証と復旧を確認

    利用者確認、新しい認証、予備手段と正規の復旧を許可された範囲で確認する。

  • 3. 残るアクセスを整理

    不要な登録・既存セッションの状態と、未確認の利用先を別々に記録する。

編集部のパスキー移行フロー。通常の機種変更と紛失・侵害疑いを分け、ログイン復旧と不要なアクセスの停止をそれぞれ確認する。

パスワードとは

本人確認に使う秘密の文字列。利用者はサービスごとに固有の値を管理し、提供側は平文ではなく適切なハッシュ化等で保護する必要がある。文字列を入力するだけでは接続先の正当性に暗号的に結び付かない。

パスキーとは

FIDO/WebAuthnを用いる公開鍵の認証情報。サービスへ公開鍵を登録し、認証器側の秘密鍵で認証する。同期型とデバイス固定型があり、生体認証そのものではない。端末のロック解除や利用者確認の方法も分けて理解する。

違いの比較表

比較軸 パスワード パスキー
仕組み 秘密の文字列で本人確認。サービスごとに固有の値を管理 登録先に結び付く公開鍵認証。鍵の保存と利用者確認を管理
防御 入力先を誤るフィッシングや使い回しに注意 フィッシング耐性がある。端末侵害・復旧・残るセッションは別に対処
保存 記憶やパスワード管理サービス。保存・同期・復旧を確認 プロバイダーで同期する型か、特定の端末・キーに固定する型かを確認
MFA パスワードだけでは単一要素。別の要素と組み合わせる 利用者確認等の条件を満たせば多要素になり得る。画面の回数では数えない
移行 既存のログイン・MFA・復旧経路と管理方針を確認 登録、利用成功、旧手段の整理を別々に確認。追加だけで廃止とはしない
復旧 リセットや回復手段の本人確認と管理が必要 同期先の復旧、予備の認証手段、サービス側の登録削除を分ける
費用と運用 管理サービスの契約、問い合わせ・リセット支援の工数 対応環境、認証器・予備手段、同期先、導入・紛失時の支援を比較

方式を選んだら、機種変更・紛失時の記録へ

保存先・利用先・新しい認証・登録とセッションの状態・残件を、秘密情報なしで記録する。判断表で不足した条件を、次の記録へ引き継げます。

無料のパスキー復旧・失効記録を開く

使い分け

  • 個人の重要アカウントで、対応環境と正規の復旧方法を確認できるならパスキーを検討する。未対応サービスでは固有のパスワードと利用可能なMFAを維持する。
  • 複数の自分の端末で使うなら同期型の保存先と復旧条件を確認する。組織が鍵の持ち出し不可を要件とするなら、承認されたデバイス固定型・管理条件を照合する。
  • 移行や機種変更は重要な利用先ごとに新しい認証を確認してから旧端末を整理する。紛失・盗難や不審な操作があるときは、復旧テストの終了を待たず報告・アクセス制限を進める。

パスキーはMFAになる?画面の数と認証要素を分ける

2026年のNCSCの解説は、利用者確認を伴うFIDO2認証が多要素認証を構成すること、端末や認証情報を管理するサービスの保護・復旧も重要であることを説明している。PINや生体等で鍵の利用者を確認することと、鍵に触れて操作したことだけを同じと扱わない。

NIST SP 800-63B-4やOWASPの資料も、利用者確認の有無を分けて扱う。サービス提供者は保守されるライブラリと公式手順で応答・利用者確認・登録先の条件を検証し、画面に指紋の絵が出たことだけで必要な認証強度を満たしたとしない。

利用者は、生体情報を相手のWebサイトへ入力していると理解しない。Googleの機能例では生体情報は端末に保存されGoogleと共有されないと説明される。認証器・保存先・利用先の条件を確認し、PINや回復コードをメールやチャットの相手へ渡さない。

同期型とデバイス固定型の違い:保存先と予備手段で選ぶ

FIDO Allianceは、パスキーには複数端末へ同期する型と、特定のデバイスに固定する型があると説明している。秘密鍵が必ず一台の外へ出ないとは一般化しない。同期型では同期アカウントの保護・正規の復旧、固定型では予備の認証器や別の公式回復経路を確認する。

別の端末でパスキーを使ってログインすることと、鍵自体をその端末へ同期・複製することは別。保存プロバイダーを変えた場合や、組織で同期先が制限される場合は、同じメールアドレス・電話番号だけで鍵が使えると考えず、保存先・利用先・管理者の条件を照合する。

共用端末や自分で管理しない端末には、自分用のパスキーを安易に登録しない。会社で認められない同期先へ個人判断で移し替えたり、対応が不明な組み合わせを全員へ一括適用したりする前に、承認された環境で確認する。

移行・紛失時の確認手順:追加・認証・失効を分ける

Googleアカウントの公式案内では、パスキー追加は現在の認証要素・復元要素を変更・削除しない。Google Workspaceでは管理者の方針によりパスキーのみでログインできない条件もある。これはGoogleの機能例であり、すべてのサービスの同じ動作を保証しない。

編集部の受入確認例は4状態。①登録、②既存セッションに依存しない新しい認証、③承認された予備手段・正規の復旧、④不要になった登録と残るアクセスの整理、を利用先ごとに確認する。通常の移行では唯一の旧端末・認証器を先に消去せず、合成データ・許可されたテスト環境を使う。

紛失・侵害疑いでは、端末の保護、サービス側のパスキー登録、既存セッション、同期先へのアクセスを別に確認して、報告・制限と復旧を並行する。新端末へログインできても、旧端末や不審なアクセスの停止まで完了したとは扱わない。記録へPIN・鍵・回復コード・QRコードを含めない。

パスワードが残る場合の文字数・運用・費用の確認

NIST SP 800-63B-4は、単一要素で使うパスワードの最低15文字を要求し、MFAの一部としてだけ使う場合は最低8文字を許容する条件を示す。これは同文書の設計要件であり、「どのサービスも8文字で十分」という意味ではない。利用先や組織の現行要件を確認し、固有の長い値を管理する。

パスキーへの対応がないサービスや残す回復経路についても、パスワード管理とMFA、本人確認の運用を維持する。文字数だけで安全と判定せず、漏えい・不審な操作が疑われる場合の変更・調査・セッション対応を正規の窓口と確認する。

見積は認証器の本体だけでなく、予備手段、対応するOS・ブラウザ・SaaSプラン、保存先の契約、端末交換・窓口支援を含める。たとえば重要サービス3つに4状態を割り当てると12確認という計画例になるが、実施実績や安全性の保証ではない。無料の復旧・失効記録で対象と残件を整理してから導入範囲を広げる。

よくある誤解

  • パスキーの追加、パスワード廃止、不要な認証器の登録削除、既存セッションの終了は同一操作ではない。
  • 同期型と固定型のどちらでも、保存先・端末・復旧の条件を確認する。「絶対に侵害されない」という方式は約束しない。
  • パスキーの利用成功は、その利用者へすべての業務権限を許してよい根拠にはならない。認証と認可を分ける。

よくある質問

パスキーを使えばMFAではなくなりますか?

画面の回数では判断しません。鍵の所持に加えてPIN・生体等による利用者確認を行い、サービス側の要件を満たす構成は多要素認証になり得ます。鍵への操作だけと利用者確認を分け、実装とポリシーを確認します。

パスキーを追加すればパスワードや復旧方法は削除されますか?

追加だけで削除されたとは扱いません。Googleアカウントでは、パスキー追加は既存の認証要素・復元要素を変更・削除しないと案内されています。他のサービスも個別に確認し、通常移行では新しい認証と予備手段を確認してから旧手段を整理します。

スマホを失くしても同じ電話番号ならパスキーは戻りますか?

電話番号だけでは判断できません。同期型か固定型か、保存プロバイダーの正規の復旧、利用先の登録と組織ポリシーを確認します。紛失時は報告・アクセス制限と復旧を並行し、新端末での成功を旧端末の失効完了と同一視しません。

編集・確認情報

FIDO Alliance、NIST SP 800-63B-4、Google、OWASP、NCSCの公開資料を照合し、同期・固定、MFA条件、既存手段、移行・復旧の確認を改訂しました。個別環境の対応保証・動作試験・専門家の個別監修ではありません。 最終確認日は 2026-10-30 です。

参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。

ESC