ログイン画面からパスワード入力欄が消えていく流れが、ここ数年で少しずつ現実味を帯びてきた。指紋や顔認証、あるいは端末の画面ロックだけでサインインできるパスキーという仕組みが、主要なブラウザとプラットフォームにひととおり行き渡ったからだ。ただ、身の回りの中小企業サイトを見渡すと、まだパスワード入力欄が主役のままという現場も多い。実際のところ、どこまで広がっているのか。制作者として知っておきたい現状と、導入をどう見極めるかを整理してみたい。
パスワードをやめる話が、ようやく形になってきた
パスキーは、FIDO Allianceとブラウザ標準のWebAuthnを土台にした認証方式だ。端末の中に秘密鍵を保管し、サーバーには公開鍵だけを預ける。ログイン時にはその鍵ペアで署名をやり取りするので、パスワードのように入力した文字列が盗まれたり、偽サイトに打ち込んでしまったりする余地がない。フィッシングに強いと言われるのはこのためだ。
振り返れば、パスワードの弱さを補う工夫はずっと続いてきた。SMSで送る確認コードや、認証アプリが表示する使い捨ての番号を組み合わせる二要素認証がその代表だ。ただ、これらは入力の手間が増えるうえ、SMSは横取りされる危険が指摘され、偽サイトに確認コードごと打ち込んでしまう事故も後を絶たなかった。パスキーは、そもそも打ち込む秘密を作らないという発想で、この積み重なった課題を根本から解こうとしている点が違う。
考え方そのものは2022年ごろから提唱されていたが、規格や運用の裏付けが整ってきたのはここ最近のことだ。米国のNIST(米国立標準技術研究所)は2025年7月に認証基準の改訂版であるSP 800-63-4を確定させ、パスキーを一定の保証レベルを満たす認証手段として正式に位置づけた。規制やガイドラインの側からも後押しが加わり、単なる新機能ではなく、標準的な選択肢のひとつとして扱われ始めている。
主要プラットフォームが出そろった
普及を支えているのは、利用者が特別な準備をしなくても使える環境が整った点だ。AppleのiCloudキーチェーン、GoogleのGoogleパスワードマネージャー、MicrosoftのEntra IDが、いずれも標準でパスキーに対応している。加えて1PasswordやBitwardenといったパスワード管理ソフトも受け皿になり、端末をまたいで鍵を同期できるようになった。
数年前までは、鍵を作った端末を失くしたらどうするのかという不安が導入の足かせだった。クラウド同期が当たり前になったことで、その懸念はかなり薄れている。利用者から見れば、スマートフォンの生体認証でそのままウェブサービスにログインできる感覚に近い。土台が広く共有されたことが、これまでとの大きな違いだ。
実際にどこまで広がっているのか
では、世の中のサイトはどれくらい採用しているのか。ここに興味深い調査がある。2026年のPAM(受動・能動測定)会議で発表された「State of Passkey Authentication in the Wild」という論文だ。研究チームはFidentikitという計測用のクローラーを作り、UI要素やDOM構造、WebAuthnの呼び出し、通信パターンなど43の判定基準を用意して、アクセス数上位10万サイトを一斉に調べた。
結果はどうだったか。調査対象のうち11.3%がパスキーに対応していたという。これは、人手でまとめた既存の対応サイト一覧と比べて62倍という数字で、実際の普及は想像以上に進んでいたことになる。ただし手放しでは喜べない。対応が確認できたのはアクセス数の多い人気サイトに偏っており、しかも自前で実装するのではなく、外部のIDプロバイダー経由で提供しているケースが目立った。裾野が広がったというより、大手が先行しているという構図が見えてくる。
この偏りは、制作の現場感覚とも重なる。大手のように専任の担当者や潤沢な予算があれば、外部のIDプロバイダーを組み込んだり、独自にWebAuthnを実装したりする余力がある。一方で、少人数で運用する会社サイトや小さな会員制サービスでは、既存のログイン機構に手を入れること自体が負担になりやすい。技術が広く使える状態になっても、実際に運用へ載せるかどうかは、体制や優先順位に左右される。数字の裏側には、こうした現場ごとの事情がにじんでいる。
普及を測りにくくしている「見えなさ」
この調査からもうひとつ読み取れるのは、パスキーが外から見えにくい形で埋め込まれているという事実だ。論文によれば、パスキー対応の82.3%は、JavaScriptを実行してAPIの動きを観測しないと検出できなかった。静的なHTMLを眺めるだけでは対応の有無すら判別できない、というわけだ。
実装の仕方もばらばらだ。「パスキーでサインイン」というボタンをはっきり見せるサイトもあれば、複数の手順の奥に隠しているサイト、入力欄に候補を出す条件付きの方式に頼るサイトもある。標準化された案内の入り口が存在しないため、利用者にとっても、どこでパスキーが使えるのか一目では分からない。制作の現場から見ると、この不統一さこそが、パスキーがまだ日常に溶け込みきっていない理由のひとつに思える。使える技術と、使いやすい体験は別物だということだ。
サーバーと端末のズレをそろえるSignal API
実装のつまずきどころとしてよく話題になるのが、サーバー側の登録情報と、端末やパスワード管理ソフトが覚えている鍵情報のズレだ。利用者が管理画面で鍵を削除しても、手元のパスワード管理ソフトには古い鍵が残り、ログイン画面で使えない候補が出てきてしまう。地味だが、迷わせる原因になる。
これを解消するために用意されたのがWebAuthn Signal APIだ。Chromeではバージョン132以降のデスクトップとAndroidで使える。サーバー側の状態を鍵の保管側に伝えるための仕組みで、大きく三つの手段がある。無効になった鍵を知らせるsignalUnknownCredential、有効な鍵の一覧をまとめて送るsignalAllAcceptedCredentials、そして利用者名や表示名の更新を伝えるsignalCurrentUserDetailsだ。これらを使えば、Googleパスワードマネージャーのような対応済みの保管側が、実体に合わせて古い候補を消したり整えたりできる。地味な機能だが、こうした細部の詰めが、実際の使い勝手を左右する。
中小企業サイトはどう構えるか
では、規模の大きくないサイトを預かる制作者はどう向き合えばよいか。まず、いますぐ全面移行を迫られる話ではない、というのが率直なところだ。調査が示すとおり、先行しているのは大手であり、一般的な会員サイトや小規模なサービスでは、パスワードと併用しながら段階的に取り入れる形が現実的だろう。
取り入れる場合のコツも見えてきている。既存のパスワードでログインした直後に「パスキーを作りませんか」と促す自動移行の流れを用意すると、利用者はほとんど手間を感じずに登録できる。導入例では、こうした案内がなめらかなサイトで、半年のうちに5割から7割の利用者が自発的にパスキーへ切り替えたという報告もある。押しつけずに、自然な導線として置くことが鍵になる。
RESONIXでもウェブ制作の現場で認証まわりの相談を受けることがあるが、パスキーはまだ「知っておくべき次の選択肢」という段階だと感じている。無理に急ぐ必要はない一方で、大手サービスで当たり前になれば、利用者の期待値も追いついてくる。仕組みの成り立ちと、いまの普及の偏り、そして実装の細かな落とし穴をおさえておけば、いざ必要になったときに落ち着いて向き合える。パスワードのない世界は、まだ地平線の向こうにあるが、確実に近づいてきている。
