WordPress にパスキーを導入するとき、プラグインを入れる前に確認しておくと詰まらない項目があります。
先に一覧を置きます。
| 確認すること | 満たさないと |
|---|---|
| PHP 8.2 以上（Web と CLI の両方） | 有効化できない。環境によっては WP-CLI が落ちる |
| HTTPS で運用している | ブラウザがパスキーの登録を拒否する |
| ドメインが固まっている | 移転や www の有無変更で、登録済みの鍵が使えなくなる |
| 締め出されたときの経路 | 端末を失くすと管理画面に入れない |
3つ目と4つ目は、入れる前に決めておかないと後で困ります。 順に書きます。
1. PHP のバージョン
8.2 以上が要ることが多い
パスキーの実体は WebAuthn という仕様で、暗号処理を自前で書くのは現実的ではありません。PHP のライブラリを使うことになります。
そして、そのライブラリの PHP 要求が、そのままプラグインの要求になります。
主要な WebAuthn ライブラリは、新しい系列で PHP 8.2 以上を要求します。WordPress 本体はもっと古い PHP でも動くので、**「WordPress のバージョンは足りているのに有効化できない」**ということが起こります。
Web と CLI で、バージョンが違うことがある
ここが、いちばんはまりやすいところです。
レンタルサーバーでは、管理画面で設定した PHP のバージョンが Web 側にしか効いていないことがあります。SSH で入ったときの CLI は、古いままだったりする。
php -v
wp --info
この2つを両方確認してください。
wp --info の出力に含まれる PHP のバージョンが、php -v と食い違うことがあります。
何が起きるか
CLI 側が古いと、WP-CLI からプラグインが読み込まれた時点で落ちます。
Composer は composer.json の PHP 要求を検査する platform_check.php を生成します。オートローダーの読み込み時にこれが走り、要求を満たしていないと例外が飛びます。
つまり、Web からは普通に見えているのに、WP-CLI のコマンドが1つも通らないという状態になりえます。
プラグイン側で防ぐ
自分でプラグインを書く場合は、オートローダーを読む前に確認します。
if (PHP_VERSION_ID < 80200) {
add_action('admin_notices', function () {
echo '<div class="notice notice-error"><p>'
. esc_html__('PHP 8.2 以上が必要です。', 'text-domain')
. '</p></div>';
});
return;
}
require_once __DIR__ . '/vendor/autoload.php';
あわせて、プラグインヘッダに要求を書いておきます。
/**
* Requires PHP: 8.2
*/
これがあると、WordPress が有効化の時点で止めてくれます。
2. HTTPS が必須
仕様として決まっています
WebAuthn は、セキュアなコンテキストでしか動きません。 http:// のページでは、ブラウザがパスキーの登録・認証を拒否します。
プラグインの制限ではなく、ブラウザ側の仕様です。
localhost は例外
開発環境では、http://localhost が例外として扱われます。ここだけは HTTPS なしで動きます。
ただし、http://192.168.x.x や http://mysite.local は対象外です。ローカルネットワーク内の別マシンから試そうとすると、そこで止まります。
開発環境で試すなら
localhost で動かすのが、いちばん手間がありません。
別ホスト名で試したい場合は、ローカルに証明書を用意して HTTPS にする必要があります。最近のローカル開発環境は、HTTPS を有効にする設定を持っているものが多いので、そちらを使うほうが早いです。
3. ドメインが固まっているか
入れる前に決めておくべき、いちばん重要な項目です。
鍵はドメインに紐づきます
WebAuthn では、RP ID（Relying Party ID） という値で鍵とサイトを結びつけます。これは実質的にドメイン名です。
登録したパスキーは、そのドメインでしか使えません。 これがフィッシング対策の仕組みそのものなので、緩めることはできません。
詰まるパターン
www の有無を変えた。 example.com と www.example.com は、扱いが変わります。統一していないと、片方で登録した鍵がもう片方で使えない、ということが起こります。
ドメインを移転した。 old.example.com から new.example.com へ移すと、登録済みのパスキーは全部使えなくなります。
サブドメインで運用していた。 RP ID を親ドメインにしていれば、サブドメイン間で共有できます。ただし設定次第なので、あとから変えると既存の鍵が無効になります。
だから、先に決める
ドメインを変える予定があるなら、変えてから導入するほうが楽です。
導入後に変えると、利用者全員に登録し直してもらうことになります。
そして、www の有無は先に統一しておいてください。 リダイレクトを入れて、片方に寄せる。これは SEO の観点でもやっておく作業です。
4. 締め出されたときの経路
ここを決めずに入れると、いちばん困ります。
パスキーだけにすると、端末を失った時点で終わる
パスキーの秘密鍵は、利用者の端末から出ません。 それが安全の理由ですが、端末を失うと鍵も失います。
パスワードを完全に無効化してしまうと、そこで管理画面に入れなくなります。
最低限、用意しておくもの
複数の端末に登録しておく。 スマートフォンとパソコンの両方に。1台失っても、もう1台で入れます。
パスワードを残しておく。 完全に無効化しない。日常はパスキー、いざというときはパスワードという形。
リカバリーの手段を用意する。 使い捨てのコードを発行しておく、といった仕組みです。プラグインによって、あるものとないものがあります。
最後の手段を知っておく
それでも入れなくなった場合の経路を、先に確認しておいてください。
WP-CLI が使える環境なら、コマンドからパスワードを再設定できます。
wp user update ユーザー名 --user_pass='新しいパスワード'
WP-CLI が使えない場合は、データベースを直接触るか、FTP でプラグインのフォルダ名を変えて無効化することになります。
この経路が自分の環境にあるかどうかを、導入前に確認してください。
導入する順番
詰まりにくい順です。
1. php -v と wp --info で、Web と CLI の PHP を確認する
2. HTTPS になっているか確認する
3. www の有無を統一する。ドメイン移転の予定があるなら、先に済ませる
4. 自分のアカウントで、パスキーを1つ登録する
5. 別のブラウザ、または別の端末で、ログインできるか試す
6. 2台目の端末にも登録する
7. パスワードでもまだ入れることを確認する
8. そのうえで、他の利用者に案内する
5番と7番を飛ばさないでください。 登録できたことと、ログインできることは別です。
既存のプラグインとの関係
2要素認証のプラグインを入れている場合、パスキーとの併用で挙動が変わることがあります。
パスキー自体が「持っているもの（端末）」と「本人であること（生体認証など）」を両方確認するので、そこにさらに2要素を重ねると、ログインが煩雑になります。
プラグイン側が連携に対応しているかを確認して、対応していれば任せる。していなければ、どちらかに寄せることになります。
ログイン画面をカスタマイズしているテーマやプラグインとも、競合することがあります。まずステージング環境で試すほうが安全です。
まとめ
-
PHP 8.2 以上。Web と CLI の両方を確認する（
php -vとwp --info） - CLI が古いと、WP-CLI がプラグイン読み込みの時点で落ちることがある
- 自分で書くなら、オートローダーの前に
PHP_VERSION_IDを確認してreturn -
HTTPS 必須。 localhost だけが例外。
192.168.x.xは対象外 - 鍵はドメインに紐づく。 移転すると全部使えなくなる
- www の有無は先に統一する
- 端末を失ったときの経路を、導入前に決める
- 複数端末に登録する／パスワードを残す／リカバリー手段を用意する
- 最後の手段は
wp user update。使える環境か確認しておく - 導入後、別の端末でログインできることまで確認する
パスキー自体は、入れてしまえば日常の手間が減ります。詰まるのは、たいてい導入の前後でした。
上の4つを先に確認しておくと、あとが楽になります。
自分でも WordPress 向けのパスキープラグインを作って公開しています。上に書いた確認項目は、そのときに実際に踏んだものです。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。
