本ページは、パスキー（Passkey）の仕組みを初学者でも理解できる順序で整理した技術解説です。本質（なぜ安全なのか／なぜ運用が楽になるのか）を中心に説明します。
パスキー（Passkey）とは、パスワードを使わずに、安全かつ簡単にログインするための新しい認証方式です。
従来のログインでは、ユーザーが「覚えた文字列（ID・パスワード）」を入力し、サービス側がその文字列を照合する、という仕組みが一般的でした。
一方、パスキーでは次のように発想が変わります。
つまりパスキーは、
「知っているもの」で本人確認する仕組みから、「持っているデバイスで本人確認する仕組み」への転換を実現する技術です。
パスワード認証は長年使われてきましたが、構造的な弱点を抱えています。
結果として、「人のミス」や「だまされること」を前提にした仕組みになっています。
SMSやメールによるOTP（ワンタイムパスワード）は、パスワードより安全な「二要素認証」として広く使われています。
しかし、OTPにも次のような課題があります。
つまり、OTPは「パスワードを補強する仕組み」であり、パスワードの根本的な問題を解決するものではない、という位置づけになります。
という特性を持ちます。そのため、パスワード＋OTPで対策していた多くの問題を、構造的に解消できます。
| 観点 | メリット | 限界 |
|---|---|---|
| パスワード | 導入が簡単 | 使い回し／漏えい／フィッシング／リセット対応が発生 |
| OTP | 2要素で強化 | 入力が必要＝フィッシングに弱い／SMS未着等の運用問題 |
| パスキー | 秘密を送らない | 初回登録（発行）を慎重に設計する必要がある |
パスキーは、どこか一社が独自に作った技術ではありません。その基盤になっているのがFIDO2（ファイドゥー）という国際標準規格です。
FIDO2は、Apple、Google、Microsoft、金融機関、大手IT企業などが参加するFIDO Allianceによって策定されています。
FIDO2は、大きく次の2つから構成されています。
これにより、Webサービス、Webブラウザ、OS・デバイスが共通ルールで安全に連携できるようになっています。
標準規格であることにより、特定ベンダー依存を避けやすく、将来のOS・ブラウザでも使い続けられ、金融・行政・大規模SaaSでも採用できる、というメリットがあります。
つまりパスキーは、一時的な流行ではなく、今後10年以上使われることを前提に設計された認証基盤と言えます。
この章では、次のポイントを押さえました。
ただし「なぜ安全なのか？」を本当に理解するためには、パスキーの内部で使われている仕組みを知る必要があります。次章では、公開鍵・秘密鍵、なぜ秘密情報を送らなくてよいのか、といったパスキーの中核となる考え方を解説します。
従来のログイン方式では、ユーザーが「ID・パスワード」や「OTP」といった秘密の文字列を入力し、それをネットワーク越しにサービスへ送信していました。
この構造には、根本的な問題があります。
秘密情報を送る以上、盗まれるリスクをゼロにはできないという点です。
通信が暗号化されていても、偽サイト（フィッシング）やマルウェア、誤操作などにより、ユーザー自身が秘密情報を差し出してしまう可能性が残ります。
パスキーは、この前提をひっくり返します。「秘密は送らない」という前提で設計されている。それを可能にしているのが公開鍵暗号方式です。
公開鍵暗号方式では、必ずペアで使われる2つの鍵があります。
この2つは、次のような性質を持っています。
重要なのは、公開鍵から秘密鍵を逆算することはできないという点です。
パスキー認証では、サービス側：公開鍵だけを保存、ユーザー側：秘密鍵をデバイス内に保存、という役割分担になります。
ログイン時に起きていることを簡略化すると、次の流れです。
この流れでは、秘密鍵そのものは送られず、ネットワークを流れるのは「署名結果」だけです。
つまり、盗まれるべき「秘密情報」がネットワーク上に存在しないという状態を作っています。
公開鍵暗号方式を使ったパスキーがフィッシングに強い理由は、次の2点にあります。
ここまでの内容をパスキーに当てはめると、次のようになります。
つまりパスキーは、「人が秘密を扱わない」ことを前提にした認証方式と言えます。この設計こそが、高いセキュリティ・高い利便性・運用負荷の低減を同時に成立させています。
この章で押さえるべきポイントは3つ。
ただし、ここで一つ疑問が残ります。
「その秘密鍵は、誰が・どこで管理しているのか？」
次章では、User（利用者）・RP（サービス）・Authenticator（認証器）という3者の役割分担を整理しながら、パスキー全体の構造を図解で解説します。
パスキー認証は、単に「パスワードを入力しない」というだけではなく、役割を3者に分けて責任範囲を整理することで成立しています。ここでいう3者とは次のとおりです。
| 3者 | 役割 | |
|---|---|---|
| User | 利用者 | 本人確認（顔／指紋／PIN 等）を行う主体 |
| RP（Relying Party） | サービス側 | 認証結果を検証し、ログイン可否を判断する主体 |
| Authenticator | 認証器 | 秘密鍵を安全に保管し、署名を生成する主体 |
重要なのは、従来のパスワード方式と異なり、RPが「秘密情報」を保管しない設計になっている点です。Userは秘密の文字列を入力しないため、フィッシング耐性が上がり、Authenticatorは秘密鍵を外に出さないため、ネットワーク上に盗む対象が存在しません。
Userが行うことはシンプルです。基本的には「ログイン」ボタンを押し、端末に表示される本人確認（顔／指紋／PIN など）を通すだけです。
User視点では、従来よりも「楽になる」方向に設計されています。ただし、裏側では安全性が上がっており、これがパスキーの大きな特徴です。
RP（Relying Party）は、「認証結果を信頼してアクセスを許可する側」、つまりサービス提供者です。RPの役割は、次の3点に集約できます。
ここで押さえておきたいのは、RPは秘密鍵を保存しないという点です。RPが漏えいしても「秘密」が奪われにくくなるため、セキュリティ事故の性質が大きく変わります（被害が局所化しやすい）。
Authenticator（認証器）は、秘密鍵を安全に保管し、本人確認が通ったときだけ署名を作る主体です。ここがパスキーの要であり、セキュリティの根幹になります。
Authenticatorの動きをもう少し具体化すると、次のようになります。
パスキーは、RP（サービス）ごとに別々の鍵ペアを作成します。つまり、同じUserでも「Aサービス用の鍵」と「Bサービス用の鍵」は別物になります。
この設計は、従来の「同じパスワードを複数サービスで使ってしまう」問題を根本から断ち切る考え方です。ユーザーの運用努力（注意力）に依存せず、仕組みとして使い回せないようにしています。
ここでの「別の鍵」というのは、単に保存場所が違うという意味ではありません。暗号学的に完全に別のペアが生成されます。よって、Aサービスで使っていた認証情報がBサービスへ流用されることはありません。
パスワードの使い回しは、人間の習性として避けるのが難しい一方、パスキーでは構造上それが起きません。これにより、次のメリットが得られます。
パスキーは、ユーザーが頑張って「安全に使う」のではなく、安全に使わざるを得ない構造を作っています。これは、セキュリティ設計として非常に大きな転換点です。
現在のパスキーは、専用ハードウェアだけに依存せず、OSやスマホそのものがAuthenticatorとして動作します。OSが認証器を担うのは、次の理由があります。
Windowsでは、Windows Hello が本人確認（PIN／顔／指紋）を担い、秘密鍵の使用を制御します。ユーザーはPINを入力しますが、これは「サービスのパスワード」ではなく、端末内での本人確認です。PINは端末外へ送られません。
Androidでは、Googleパスワードマネージャー等がパスキー基盤として動作し、端末ロック解除（顔／指紋／PIN）を利用して署名を生成します。ユーザー体験としては「端末のいつものロック解除」とほぼ同じ操作になります。
iPhoneでは、iCloudキーチェーンがパスキーを保持し、Face ID / Touch ID / 端末パスコードによって秘密鍵の使用が制御されます。ここでも、生体情報がサービスへ送られることはなく、端末内で完結します。
OSベンダーが担うことで、ユーザーは「鍵を管理する負担」から解放されます。一方で、RP（サービス）側は、OSベンダーに認証を“丸投げ”するのではなく、自社のログイン要件・初回登録の厳格さ・監査ログなどを設計する必要があります。
顔認証・指紋認証・PINは、サービスのログイン情報ではありません。これらは端末内で「秘密鍵を使ってよいか」を判断する本人確認です。
よくある誤解として「顔や指紋がサービスに送られて照合されている」と思われがちですが、実際には逆です。サービスは顔や指紋を受け取らず、Authenticatorが「本人確認が通った」と判断した場合のみ署名が生成されます。
ここで整理しておきたいのが、本人確認（User Verification）と認証（Authentication）の違いです。
| 役割 | 相違点 |
|---|---|
| 本人確認 | 端末内で「持ち主本人か」を確認する（顔／指紋／PIN） |
| 認証 | サービス側で「正しい鍵の持ち主か」を確認する（署名の検証） |
パスキーは、この2段階をきれいに分離します。結果として、ユーザー体験は簡単になる一方、セキュリティは高くなります。
「PIN/顔/指紋が自動判定される」と感じるのは、OSが利用可能な本人確認手段を提示しているためです。ユーザーは“いつもの解除”を行い、裏側で署名が生成されます。
PINは短い数字で不安に見えるかもしれません。しかし、PINは端末内でのみ通用する本人確認で、サービスへ送られません。つまり、仮にサービス側が侵害されてもPINは奪えません。これはパスワードと決定的に異なる点です。
クロスデバイス認証とは、PCなどログイン端末に鍵が存在しない場合でも、スマホ等の別デバイスをAuthenticatorとして用いて認証できる仕組みです。
典型例は次の流れです。
クロスデバイス認証は便利ですが、「離れた場所の他人が勝手に承認できる」設計ではありません。近接通信（Bluetoothなど）を使ってその場にいることを確かめるなど、複数の条件で安全性を担保します。
| 役割 | 実施内容 |
|---|---|
| QRコード | 認証要求（セッション情報）の受け渡し |
| Bluetooth等 | 近接確認（なりすまし防止） |
| ネットワーク | 署名結果の返却 |
クロスデバイス認証は、利便性を上げながらも「秘密鍵を送らない」前提を守ります。つまり、便利になっても安全性の根本設計は崩れません。
パスキーの文脈でBig3（Apple/Google/Microsoft）が頻繁に登場するため、「彼らがプラットフォームを握っているのでは？」と感じることがあります。しかし、彼らの主な役割はAuthenticator（認証器）基盤の提供です。
一方、RP（サービス）が提供する価値は、認証器そのものではなく、次のような領域にあります。
Big3が担うのは「鍵を安全に保持して署名を作る」役割です。RPが担う「その署名をどう使って業務を成立させるか」は別領域となります。
RPを提供する企業（例：ハネソル）の運用では、誰がどの端末を使えるか、どこまでを許容するか、退職時にどう無効化するかなど、多くの設計要素があります。パスキーは「安全な部品」ですが、企業で使うには運用設計が重要です。
パスキーは、最初に「登録（発行）」が必要です。登録は、単なる設定ではなく、新しい本人確認手段の発行に相当します。登録時の流れは次のとおりです。
パスキーはログインを強固にしますが、前提として「誰のパスキーか」が正しく登録されている必要があります。もし登録時に成りすましが起きると、その後の認証は正しくても犯人を本人と認めてしまうことになります。
「ログインが簡単になるほど、登録が重要になる」
――これがパスキー運用の本質です。登録段階の厳格さが、その後の安全性を決めます。
登録後のログインは、チャレンジレスポンス方式で行われます。RPは使い捨ての問い（チャレンジ）を出し、Authenticatorは秘密鍵で署名し、RPは公開鍵で検証します。
ネットワーク上を流れるのは署名結果であり、秘密鍵は流れません。ユーザーが入力する秘密もありません。従来方式のように「盗んで使う」対象が消えるため、攻撃の成立条件が崩れます。
OTPは「本人確認の強化」にはなるものの、入力式である以上、フィッシングに弱い構造が残ります。パスキーは、入力式の秘密を排し、RPごとの鍵ペアで“正しい相手にしか使えない”認証を実現します。
| 観点 | OTP | パスキー |
|---|---|---|
| ユーザー操作 | コードを受け取り、入力する | 端末で本人確認し、ボタンで完了 |
| 盗難対象 | コードが盗まれうる | 秘密鍵は外に出ない（盗めない） |
| フィッシング耐性 | 入力するため弱い | 偽RPでは成立しない |
Webブラウザは、RP（サーバ）とAuthenticator（端末）をつなぐ橋渡しをします。RPはブラウザに対してWebAuthn APIで「登録して」「認証して」と依頼し、ブラウザがOSの機能（Authenticator）を呼び出します。
| ポジション | 役割 |
|---|---|
| RP（サーバ） | 登録／認証の開始、チャレンジ発行、検証を行う |
| WEBブラウザ | WebAuthn APIで処理を仲介する |
| Authenticator（端末） | 秘密鍵保管、本人確認、署名生成を行う |
FIDO2サーバ（＝RP側の認証基盤）が保持するのは、原則として公開情報と検証に必要な情報です。秘密鍵は保持しません。
この章のまとめとしてもう一度強調すると、秘密鍵は端末内に留まり、外部へ送られません。これがパスキーのセキュリティの基盤です。
パスキーは「ログインのための技術」に見えますが、本質は本人性の証明を、安全かつ簡単に実行できることです。つまり、ログイン以外にも、重要操作の承認や決裁の確認といった行為にも転用できます。
パスキーを使ったシステムはFIDO2/WebAuthn仕様に沿って開発すれば、自営での導入が可能です。しかし、これまで説明してきたように、フロントエンド（JavaScript）、バックエンド（PHP）、データベース（MySQL）等の多くのプログラムを構築が必要です。
ハネソルでは、パスキーを平易に既存システムに導入できるAPIをご用意しています。自営のシステム設置で技術的な壁を感じておられる事業者様は、ぜひハネソルにご相談ください。
最後までお読みくださりありがとうございます。
