パスキーとは｜FIDO2・WebAuthnの仕組みと実装7つの注意点

パスキーとは何か

パスキーとは、FIDO標準に基づく認証情報で、スマートフォンやPC、ハードウェアセキュリティキーに保存されるものです。FIDO Alliance は、ユーザーが「端末のロックを解除するのと同じ操作（生体認証・PIN・パターン）」でサインインできる仕組みとして定義しています。

ここで誤解されやすい点があります。指紋や顔のデータがサーバに送られるわけではありません。 生体認証はあくまで「端末内の秘密鍵を使ってよいか」を確認するためのローカルな鍵開けです。サーバはその結果として生成された署名だけを受け取ります。

登録時に鍵ペアが作られ、秘密鍵は認証器（端末のセキュアな領域やセキュリティキー）に残り、公開鍵だけがサービス側に保存されます。ログインのたびにサーバがランダムなチャレンジを送り、端末が秘密鍵で署名し、サーバが公開鍵で検証する。これがパスキーの中核です。

パスワード・従来のMFAと何が違うか

最大の違いは、共有秘密が存在しないことです。

パスワードは「ユーザーとサーバが同じ文字列を知っている」前提で成り立ちます。だからサーバ側のDBが漏れれば危険ですし、ユーザーが偽サイトに入力すれば、その文字列はそのまま攻撃者のものになります。SMSのワンタイムコードやTOTPも、結局は「画面に表示された値を人間が転記する」構造のため、リアルタイムの中継型フィッシングには抜かれます。

パスキーにはこの弱点がありません。

なぜフィッシングに強いのか

フィッシング耐性の理由は、生体認証ではなくオリジン（ドメイン）の束縛にあります。

パスキーは登録時に RP ID（Relying Party ID＝サービスのドメイン単位の識別子）と紐づきます。認証時は、ブラウザが生成するクライアントデータに実際にアクセスしているオリジンが含まれ、サーバはそれを含む署名対象データを検証します。偽サイトのドメインは本物と異なるため、検証で不一致として弾かれます。ユーザーが騙されていても、プロトコルの側で成立しません。

ここが「人間の注意力に依存しない」と言われる所以です。

ミニFAQ：パスキーを登録した端末を他人に渡したら、その人はログインできますか。

端末のロック解除（生体認証・PIN）を突破できなければ秘密鍵は使えません。ただし端末のPINが単純で、かつ相手がそれを知っている場合は成立しえます。パスキーは「端末の所持」と「端末のロック解除手段」の2要素に守られている、と理解するのが正確です。

FIDO2・WebAuthn・CTAPの関係を整理する

用語が多く混乱しやすい領域なので、先に全体像を置きます。FIDO2は一般にWebAuthnとCTAPを中心とするFIDOの認証仕様群を指し、WebAuthnはブラウザAPI、CTAPは認証器との通信プロトコル、パスキーはそれらを使った認証情報の形態です。厳密には仕様群の呼称であり、2つの仕様を足したものという理解は簡略化である点に注意してください。

「FIDO2とパスキーはどちらが新しいのか」という問いの立て方自体がズレています。レイヤーが違うためです。FIDO2という規格の上で作られる鍵をパスキーと呼ぶ、という関係になります。

仕様の最新動向を確認してから着手する

WebAuthnはW3Cで仕様が更新され続けています。執筆時点（2026年10月）で公式サイトから確認できる最新の勧告は Web Authentication: An API for accessing Public Key Credentials - Level 3 で、2026年8月25日にW3C勧告（Recommendation）となりました。Level 2（2021年4月）からの更新にあたります。

実装に入る前に、W3Cの該当ページで現在の最新レベルと差分を確認してください。認証仕様は数年単位で更新され、ブラウザ側の実装追従にも時間差があります。記事や書籍の情報だけで判断すると、古いオプション名のまま書いてしまうことがあります。

実装ガイドとしては、ブラウザベンダ横断の情報がまとまっている passkeys.dev と、Googleのパスキー開発者向けドキュメント が参照しやすいです。

パスキーの認証フロー

パスキーの処理は、登録（Registration）と認証（Authentication）の2つに分かれます。どちらもサーバがチャレンジを発行し、認証器が署名し、サーバが検証するという骨格は同じです。

登録（Registration）で起きていること

登録は、鍵ペアを作ってサーバに公開鍵を預ける工程です。

1. サーバがランダムなチャレンジと、ユーザー情報・RP ID などを含むオプションを生成して返す

2. ブラウザがWebAuthnのcredential作成APIを呼び、認証器に鍵ペア生成を依頼する

3. ユーザーが生体認証やPINで承認する

4. 認証器が鍵ペアを生成し、秘密鍵を内部に保存、公開鍵とクレデンシャルIDを返す

5. サーバがチャレンジ・オリジン・RP IDハッシュを検証し、公開鍵とクレデンシャルIDをユーザーに紐づけて保存する

サーバが保存するのは、クレデンシャルID・公開鍵・署名カウンタ・認証器の種別情報などです。秘密鍵は一度もネットワークを通りません。

認証（Authentication）で起きていること

認証は、預けた公開鍵で署名を検証する工程です。

サーバが新しいチャレンジを発行し、ブラウザがcredential取得APIを呼びます。認証器はユーザーの承認を得たうえで、チャレンジとクライアントデータ、認証器データをまとめて秘密鍵で署名します。

サーバ側の検証で確認すべき項目は、おおむね次の通りです。

• チャレンジが自分で発行したものと一致し、使い回されていないか

• オリジンが期待するものと一致しているか

• RP IDのハッシュが一致しているか

• ユーザー検証（UV）フラグが、ポリシー上必要なら立っているか

• 公開鍵で署名が正しく検証できるか

このうちチャレンジとオリジンの検証を省くと、フィッシング耐性という最大の利点が失われます。ライブラリ任せにする場合も、何を検証しているかは把握しておいてください。

トークンの発行・管理まで含めた設計は、JWTとは｜仕組み・セッション認証との違い・実装の注意点 と合わせて読むと整理しやすいはずです。認可の話は OAuth 2.0とは｜認可の仕組み・4つのグラントとPKCEを解説 にまとめています。パスキーは「誰であるか」を確かめる認証、OAuthは「何を許すか」を決める認可であり、役割が異なります。

同期パスキーと端末固定パスキーの違い

パスキーには大きく2種類あります。どちらを前提にするかで、復旧設計もセキュリティ要件も変わります。

同期パスキーとデバイス固定パスキー

同期パスキー（Synced Passkey）は、iCloudキーチェーンやGoogleパスワードマネージャーなどのクラウド経由で、ユーザーの複数端末に同期されるものです。端末を買い替えても引き継がれるため、一般利用者向けサービスでは現実的な選択肢になります。

デバイス固定パスキー（Device-bound Passkey）は、その端末やセキュリティキーから出ません。FIDOセキュリティキーに保存されるものが代表例です。所持の保証が強く、プラットフォーム事業者の同期に依存しない一方、紛失時の影響は大きくなります。

どちらを選ぶかの判断基準

一般利用者向けのサービスであれば、同期パスキーを前提に設計するほうが運用は現実的です。端末の紛失・買い替えが日常的に起きるためです。

一方、金融・医療・基幹系など、所持の保証を厳格に求める領域ではデバイス固定パスキーやセキュリティキーの併用が検討されます。ゼロトラストの文脈で認証強度を上げる設計は ゼロトラストとは｜境界型との違い・主要技術・案件動向を解説 でも触れています。

なお、認証器から得られる情報を手がかりに、同期前提の鍵かどうかを推定できる場合があります。ただし認証器の実装差やプラットフォーム差があるため、一律の判定を前提にした設計は避けたほうが安全です。高権限操作だけ条件を強めるといったポリシーを組む場合も、判定が外れたときの代替経路を用意してください。

パスキー実装7つの注意点

ここからは実装で実際に詰まりやすい点を7つ挙げます。いずれも、後から直すのが高コストになりやすい箇所です。

1. RP IDは頂点ドメインで先に決め打つ

最初に決めるべきで、かつ後から変更が効かないのがRP IDです。

RP IDには方向性があります。example.com で登録したパスキーは app.example.com から利用できますが、app.example.com で登録したパスキーを example.com から使うことはできません。サブドメインで登録してしまうと、後でドメイン構成を変えたときに既存のパスキーが使えなくなります。

最初のユーザー登録を始める前に、将来のサブドメイン構成まで見据えて頂点ドメインを選んでください。ここだけは実装着手前の意思決定です。

2. user.idに個人情報を入れない

user.id はアカウントを指す不透明なハンドルであり、表示用の識別子ではありません。WebAuthnの仕様上の上限は64バイトです。

ここにメールアドレスやユーザー名を入れると、その値がクレデンシャルに焼き込まれ、あとから変更（ローテーション）できなくなります。メールアドレス変更が可能なサービスでは実害が出ます。ランダムなバイト列やUUIDを割り当て、内部でアカウントに紐づけてください。

3. ユーザー名なしログインにはdiscoverable credentialが要る

「ユーザー名を入力せずにログイン」を実現したい場合、discoverable credential（認証器側が自分で鍵を見つけられる形式の認証情報）が必要です。現在はdiscoverable credentialと呼ばれることが多く、従来のresident keyに相当します。登録時のオプションでresidentKeyを required として要求します。

これを指定していないと、認証時に対象クレデンシャルのリストをサーバから渡す必要があり、結局ユーザー名の入力を先に求めることになります。UXの要件とオプション指定がずれていると、設計意図と実装が食い違ったまま進みます。

4. Conditional UIは別物として実装する

パスワード入力欄の自動入力候補にパスキーを出す「Conditional UI」は、通常の認証呼び出しとは別の実装です。

入力欄に autocomplete 属性として username webauthn を指定し、取得APIの呼び出し時に mediation を conditional に設定します。これを忘れると、ページ表示と同時にモーダルが開いてユーザーの操作を塞いでしまいます。離脱に直結する部分なので、実機での確認を必ず入れてください。

5. アカウント復旧を先に設計する

パスキーはアカウント復旧の問題を解決しません。移動させるだけです。

端末をすべて失ったユーザーをどう救済するかを決めずに本番投入すると、サポート対応の負荷が跳ね上がります。一般的な移行では、初期段階でパスワードを即時廃止しない設計のほうが安全です。移行期は、パスキーを主要な手段としつつ、既存のパスワードやメールリンク、バックアップコードなどを併存させるのが現実的です。高いセキュリティ要件があり、利用端末を管理下に置ける環境では、より早い段階でパスワードを廃止する判断もありえます。

ただし、弱い復旧手段を残すとそこが攻撃面になります。「パスキーでログインできるのに、SMSワンタイムコードでも入れる」状態は、結局SMSの強度まで全体が落ちます。復旧手段の強度は意識的に設計してください。

6. 署名カウンタとattestationの扱いを決めておく

署名カウンタは、認証器によってはクローン検知の補助に使える値です。認証のたびに増える実装がある一方、同期パスキーでは常に0を返す実装もあります。そのためカウンタの不整合をもって一律にブロックすると、正規ユーザーを締め出すおそれがあります。どう扱うかをポリシーとして決めておいてください。

attestation（認証器の出自の証明）も同様です。一般利用者向けサービスでは必須にしないことが多く、取得するとプライバシー上の考慮も増えます。企業内で認証器を限定したい場合に検討する、という位置づけが扱いやすいです。

7. クロスデバイス認証と複数登録を見込む

PCでログインする際に、スマートフォンのパスキーをBluetooth経由で使うハイブリッド方式があります。CTAPがこの近接確認を担います。

実装上は、ユーザーが複数のパスキーを登録できることを前提にしてください。1アカウント1パスキーに制限すると、端末追加のたびに登録し直しが必要になり、紛失時のリスクも上がります。登録済みパスキーの一覧表示と個別削除をユーザー自身ができる管理画面も、あわせて用意すべきです。

ミニFAQ：既存のパスワード認証を残したまま、パスキーを後から追加導入できますか。

できます。むしろ段階的な追加が一般的な進め方です。ログイン後の設定画面で任意登録できるようにし、登録済みユーザーには次回以降パスキーを優先的に提示する、という順序で広げると影響範囲を抑えられます。

ケース別の導入判断

同じパスキー導入でも、サービスの性質によって優先順位が変わります。

一般利用者向けサービスの場合

優先すべきはカバレッジとUXです。同期パスキーを前提に、Conditional UIで既存のログイン画面に自然に溶け込ませる形が無難です。未対応環境のユーザーが一定数残るため、従来手段の併存は必須と考えてください。

パスワードリセットの問い合わせ削減が、導入効果として語られることが多い領域でもあります。ただし効果はサービスの利用頻度やユーザー層に左右されるため、導入前後の計測を設計に含めておくと判断材料になります。

社内システム・業務システムの場合

IdP（Identity Provider）側の対応状況が起点になります。自前実装よりも、IdaaS製品の機能として有効化するほうが早いケースが多いです。デバイス固定パスキーやセキュリティキーの配布と組み合わせ、端末管理ポリシーと一体で設計されます。

この領域の実務や製品の違いは 認証基盤・IDaaSエンジニアのフリーランス案件動向｜単価・必要スキル・主要製品 で詳しくまとめています。

パスキー実装チェックリスト

着手前と本番投入前に確認したい項目を整理しました。

この表をそのまま設計レビューの観点として使えるようにしています。

フリーランス案件でパスキーはどう扱われるか

公開案件ベースでは、パスキー単体の案件よりも、認証基盤の刷新やIDaaS導入、セキュリティ強化施策の一部として要件に含まれる例が多く見られます。

公開案件の募集要件を見ると、OAuth 2.0・OIDC・SAMLといった既存の認証認可の理解とセットで、パスワードレス対応の経験が挙げられている例が見られます。認証そのものより、既存システムへの移行設計や運用設計ができるかを問われることが多い領域です。

単価の目安は、月60〜100万円前後の募集が中心帯です。

この数字の母集団を補足します。2026年10月時点で、首都圏中心の主要フリーランスエージェント数社の公開案件ページを対象に、認証基盤・ID管理まわりの募集を数十件程度確認した範囲での観測です。週4〜5日・準委任の案件を中心に見ています。あくまで公開案件ベースの観測であり、媒体や時期、地域の偏りによって大きくぶれます。パスキーを明示した公開案件は母数自体が多くないため、観測ベースの目安として読んでください。

上振れしやすいのは、IDaaS製品の導入実績に加えて、移行計画の策定や関係部署との要件調整まで担える人です。具体的には、既存の認証基盤を持つ事業会社で移行プロジェクトを設計した経験があり、情報システム部門やセキュリティ部門との調整を自分で進められる層が該当します。実装者というより、設計と合意形成を引き受けられる立場が条件になります。

なお、非公開で打診される案件は個別性が強く、ここで挙げた公開案件の目安とは別物として考えたほうが安全です。

職種としての市場感は セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジ 、脅威動向の全体像は 情報セキュリティ10大脅威2026｜組織編の全順位とエンジニアの対策 を参照してください。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は『【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？』で整理しています。

認証まわりの案件を実際に探す場合は、フリコンの案件一覧から条件を絞り込めます。

まとめ

パスキーとは、公開鍵暗号によってサーバ側に共有秘密を置かない認証情報であり、ドメインと署名が結びつくことでフィッシングに強い仕組みです。実装の成否を分けるのは暗号処理ではなく、RP IDの決定とアカウント復旧の設計にあります。

要点を整理します。

• サーバが保管するのは公開鍵のみ。秘密鍵と生体情報は端末から出ない

• FIDO2は規格の総称、WebAuthnはブラウザAPI、CTAPは認証器との通信、パスキーは認証情報そのもの

• 執筆時点の最新仕様はWebAuthn Level 3（2026年8月25日にW3C勧告）。着手前に公式で最新を確認する

• RP IDは頂点ドメインで先に確定する。後からの変更はできない

• user.idには個人情報を入れない（64バイト以内の不透明な値にする）

• 同期パスキーと端末固定パスキーは復旧設計が異なる。どちらを前提にするかを先に決める

• パスキーは復旧の問題を移すだけ。初日にパスワードを消さない

次のステップとしては、まず自社サービスの頂点ドメインを確定し、対応ブラウザの判定と復旧経路の棚卸しから着手するのが手戻りの少ない順序です。そのうえで、登録導線をログイン後の設定画面に置く形から小さく始めてください。

参照した一次情報は以下の通りです。

• FIDO Alliance｜Passkeys

• W3C｜Web Authentication: An API for accessing Public Key Credentials - Level 3

• passkeys.dev

• Google for Developers｜Passkeys