月: 2026年7月

ログイン画面からパスワード入力欄が消えていく流れが、ここ数年で少しずつ現実味を帯びてきた。指紋や顔認証、あるいは端末の画面ロックだけでサインインできるパスキーという仕組みが、主要なブラウザとプラットフォームにひととおり行き渡ったからだ。ただ、身の回りの中小企業サイトを見渡すと、まだパスワード入力欄が主役のままという現場も多い。実際のところ、どこまで広がっているのか。制作者として知っておきたい現状と、導入をどう見極めるかを整理してみたい。

パスワードをやめる話が、ようやく形になってきた

パスキーは、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でもウェブ制作の現場で認証まわりの相談を受けることがあるが、パスキーはまだ「知っておくべき次の選択肢」という段階だと感じている。無理に急ぐ必要はない一方で、大手サービスで当たり前になれば、利用者の期待値も追いついてくる。仕組みの成り立ちと、いまの普及の偏り、そして実装の細かな落とし穴をおさえておけば、いざ必要になったときに落ち着いて向き合える。パスワードのない世界は、まだ地平線の向こうにあるが、確実に近づいてきている。

ウェブサイトで何かを開いたり閉じたりする操作は、どんなサイトにもあります。ハンバーガーメニューの開閉、問い合わせ前に表示するモーダル、よくある質問のアコーディオン、小さなツールチップ。こうした開閉パーツは長らくJavaScriptのライブラリで組むのが当たり前でした。ところが2026年に入り、ブラウザ標準の機能だけで同じことができる場面がぐっと増えています。

節目になったのが、2026年5月に公開されたSafari 26.5です。ここでopen擬似クラス(:open)が実装され、ChromeやFirefoxと足並みがそろいました。地味な追加に見えますが、標準機能だけで開閉UIを組む流れを後押しする一歩です。詳しくはWebKitの公式ブログでも解説されています。

open擬似クラスが開いた状態をまとめて扱う

:openは、要素が開いている状態にスタイルを当てるための擬似クラスです。対象はdetails要素やdialog要素、それにselect要素や、日付や色を選ぶinput要素のピッカーが開いたときまで含みます。開閉する部品を、種類を問わず同じ書き方で整えられるのが利点です。矢印の向きを変える、背景色を切り替えるといった見た目の調整を、状態ごとにCSSの中で完結させられます。

これまでは[open]属性セレクタで開閉状態を拾っていました。ただしこの書き方が効くのはdetails要素とdialog要素だけで、select要素やinput要素には使えませんでした。細かな差に見えますが、開閉するあらゆる要素を一貫した書き方で扱えるようになった意味は小さくありません。要素の種類ごとに別々のセレクタを覚える負担が減り、スタイルの見通しも良くなります。詳しい対応状況はMDNで確認できます。

標準タグだけで組める開閉パーツ

開閉UIの部品は、ここ数年でブラウザ側にそろってきました。モーダルはdialog要素のshowModalで開けます。背景を暗くする処理やフォーカスの閉じ込め、Escキーで閉じる動きまで、ブラウザがはじめから面倒をみてくれます。ちょっとしたメニューや吹き出しは、HTMLにpopover属性を足すだけで開閉できます。Popover APIは2025年4月に主要ブラウザで安定して使えるようになり、いまでは前提として組み込める土台になりました。popover属性を付けた要素は、外側をクリックしたりEscキーを押したりすると自動的に閉じます。いわゆるライトディスミスの挙動を、自分で書かなくてもブラウザが用意してくれます。

よくある質問のアコーディオンは、details要素とsummary要素だけで作れます。開いたときの見た目は:openで整えれば、開閉の状態管理をJavaScriptで書く必要はありません。ポップオーバーが表示中かどうかは:popover-openでも拾えます。Safari 26.5では、どの要素がポップオーバーを開いたかを知るための仕組みも加わり、複数の開閉部品が絡む画面でも扱いやすくなりました。ボタンを押すと候補が開くドロップダウンのような部品も、こうした標準機能の組み合わせで素直に表現できます。素朴なHTMLの積み重ねで、これまで外部ライブラリに任せていた動きの多くがまかなえます。

制作現場にとっての意味

標準機能に寄せる利点は、まずコードが軽くなることです。開閉のためだけに読み込んでいた外部ライブラリを減らせば、ページの表示は速くなり、保守の手間も下がります。加えて見落としがちなのがアクセシビリティです。dialog要素やpopover属性は、キーボード操作やスクリーンリーダーへの対応がはじめから組み込まれています。自前で作った開閉UIにありがちな、フォーカスが迷子になる、Escキーで閉じないといった不具合を避けやすくなります。ブラウザ標準の挙動に乗るぶん、環境による見え方や操作感のばらつきも抑えやすくなります。

中小企業のサイトでも、問い合わせ導線のモーダルやFAQのアコーディオンなど、使いどころは多いはずです。たとえば、以前はプラグイン頼みで組んでいたFAQの開閉を、details要素と:openだけに置き換えれば、依存が減って動作も安定します。ただし現状では、古いブラウザ向けのフォールバックや、凝ったアニメーションでのCSSとの併用など、細かい調整が要る場面は残ります。それでも、開閉UIの土台をブラウザ任せにできる範囲は着実に広がっています。新しく組むときは、まず標準機能だけで足りるかを出発点に考える価値が出てきました。手が込んだ実装に進むのは、それで届かないところを見極めてからでも遅くありません。