WordPressログインを守る方法｜Basic認証と2段階認証の違い

WordPressのログイン画面を守る方法として、「Basic認証を付ける」「2段階認証を有効にする」という説明を見かけます。名前は似ていますが、守る場所と役割は別です。

小さな宿のサイトには、予約フォーム、問い合わせ、決済、外部サービスとの連携が含まれることがあります。守りを増やすだけでなく、必要な機能を止めず、万一ログインできなくなっても戻せるように導入することが大切です。

先に結論：四つは別の役割
HTTPSはすべての土台
Basic認証とは
2段階認証とは
1. 有効にする前に復旧方法を用意する
Basic認証とApplication Passwordsを混同しない
宿サイトで先に確認する機能
安全に導入する順番
AIへは「調査」と「変更」を分けて頼む
導入前後の確認表
まとめ
参考資料

先に結論：四つは別の役割

防御	守るもの	利用者が行うこと
HTTPS	パソコンやスマートフォンとサーバー間の通信	鍵マークの付いたURLで接続する
Basic認証	WordPressへ到達する前のサーバー側の入口	共通または個別のID・パスワードを入力する
WordPressログイン	WordPress内の管理権限	WordPressの自分のID・パスワードで入る
2段階認証（2FA）	パスワードが漏れた後の不正ログイン	スマートフォンの確認コードなどを追加する

Basic認証と2段階認証は二者択一ではありません。しかし、すべての宿が同じ組み合わせにすればよいわけでもありません。まずHTTPSと強く使い回さないパスワードを整え、そのうえで管理者の2段階認証を優先します。Basic認証は、サーバー構成と外部連携への影響を確認して追加を判断します。

HTTPSはすべての土台

HTTPSは通信内容を暗号化します。ログイン画面が`http://`のままだと、認証情報を安全に送れません。Basic認証も、HTTPSなしでは認証情報をネットワーク上で十分安全に扱えないため、先にサイト全体のHTTPS化を確認します。

ブラウザのアドレスが`https://`で始まることだけでなく、WordPressの管理画面やログイン画面でもHTTPSになっているか確認してください。証明書の設定が分からなければ、契約中のレンタルサーバー会社または保守担当者へ相談します。

Basic認証とは

Basic認証は、WebサーバーがWordPressより手前で出す、もう一つの入口です。設定されているページへ行くと、WordPressの画面が表示される前にIDとパスワードを求められます。

不特定多数からログイン画面へ直接アクセスされにくくなる一方、次の点に注意が必要です。

WordPressの利用者ごとの権限管理とは別物
Basic認証のID・パスワードを共有すると、誰が使ったか分かりにくい
サーバー会社やApache・nginxなどによって設定方法が違う
/wp-admin/全体を一律に守ると、WordPressの一部機能が動かなくなる場合がある
HTTPSと組み合わせる必要がある
ログインできなくなったときの解除方法を、設定前に把握する必要がある

レンタルサーバーでは、管理画面にアクセス制限機能が用意されている場合があります。VPSでは、Webサーバーの設定と認証用ファイルを管理する技術が必要です。インターネットで見つけた設定をそのまま貼り付けず、契約先の公式手順と現在の構成を確認してください。

2段階認証とは

2段階認証は、WordPressのパスワードに加えて、スマートフォンの認証アプリが作る一時コードなどを確認する仕組みです。パスワードが漏れても、それだけではログインしにくくなります。

一般的なWordPressサイトでは、保守されている2段階認証プラグインなどを使い、利用者ごとに設定します。まず管理者権限を持つ人から有効にし、必要に応じて編集者などの利用者に対象を広げます。

有効にする前に復旧方法を用意する

スマートフォンの故障、紛失、機種変更は起こり得ます。設定時に発行されるバックアップコードは、サイトの中や普段使うスマートフォンだけへ置かず、紙または信頼できるパスワード管理ツールなどへ安全に保管します。

「困ったらプラグインのファイルを消せばよい」と考えるのは危険です。別の設定まで壊したり、問題の原因が分からなくなったりします。プラグインの公式な復旧手順、別の管理者、サーバー会社への連絡方法を事前に確認してください。

Basic認証とApplication Passwordsを混同しない

WordPressには、外部アプリがREST APIなどへ接続するための「Application Passwords（アプリケーションパスワード）」があります。通信上はHTTPのBasic認証方式を利用しますが、ログイン画面の前へ設置するサーバー側のBasic認証とは別の機能です。

名前が似ているため、AIや保守担当者へ相談するときは、次のように目的まで伝えます。

「wp-login.phpへ到達する前のサーバー側Basic認証を検討したい」
「外部ツールがREST APIへ接続するためのWordPress Application Passwordsを確認したい」

Application Passwordsも通常の管理画面ログイン用パスワードの代わりには使いません。外部連携ごとに発行し、不要になったら個別に失効できる状態にします。

宿サイトで先に確認する機能

Basic認証やセキュリティープラグインを有効にすると、管理者には見えない場所で外部通信が止まる場合があります。導入前に、次の利用状況を書き出します。

予約フォームや予約エンジンとの連携
問い合わせフォームと自動返信
決済サービスからの通知
Jetpackや外部バックアップ・監視サービス
REST APIを使うアプリや更新ツール
admin-ajax.phpを使う画面やプラグイン
サイトコントローラー、PMS、OTAなどとの連携

WordPress公式のセキュリティー資料も、/wp-admin/へサーバー側のパスワード保護を加えると、admin-ajax.phpを利用する機能が壊れる場合があると注意しています。設定直後に管理画面へ入れたから完了、ではありません。

安全に導入する順番

1. 現在の管理者と連携サービスを確認する

退職者や制作会社の不要な管理者アカウントが残っていないか確認します。共用の管理者アカウントを増やさず、一人ずつ自分のアカウントを使います。同時に、外部連携の一覧を作ります。

2. 復元できるバックアップを取る

ファイルとデータベースの両方を保存し、いつのバックアップか、誰が戻せるかを記録します。WordPress更新入門の考え方と同じく、取っただけでなく復元方法まで確認します。

3. 解除・復旧手順を先に読む

2段階認証を解除する方法、スマートフォン紛失時の連絡先、Basic認証を元へ戻す方法をメモします。操作担当者が一人しかいない場合は、サーバー会社や保守担当者へ連絡できる時間帯に作業します。

4. まず一つの管理者アカウントで2段階認証を試す

保守状況と対応バージョンを確認したプラグインを使い、一つの管理者で設定します。バックアップコードを保管し、現在の画面を閉じる前に、別のブラウザまたはプライベートウィンドウでログインを試します。

5. 必要な利用者に対象を広げる

復旧テストができたら、管理者など重要な権限を持つ利用者にも対象を広げます。設定は本人のスマートフォンで行い、認証コードやバックアップコードをチャットで共有しません。

6. Basic認証は影響を調べてから判断する

契約先の公式機能で対象範囲を指定できるか、外部サービスが認証を通過できるかを確認します。分からなければ、サーバー側の設定変更をAIへ直接任せず、制作会社やサーバー会社へ相談します。

7. 宿泊者側の動作まで確認する

最後に、ログアウト状態とスマートフォンで次を試します。

トップページと主要ページが開く
管理者がログイン・ログアウトできる
予約・問い合わせフォームを送信できる
自動返信や管理者通知が届く
決済や外部サービスのテスト通知が通る
バックアップ、監視、連携ツールに異常がない

AIへは「調査」と「変更」を分けて頼む

最初は設定を変えさせず、現在の状況と影響範囲だけを調べてもらいます。パスワード、認証コード、秘密鍵、顧客情報は会話へ貼り付けません。

このWordPressサイトで、ログイン保護を強化する前の調査をしてください。

目的:
- HTTPS、WordPressの管理者、2段階認証の有無を確認する
- Basic認証を追加した場合に影響しそうな予約、問い合わせ、
  admin-ajax、REST API、外部連携を洗い出す
- 復旧方法と確認項目を整理する

今回は読み取りと説明だけにしてください。
プラグイン導入、設定変更、ファイル編集、再起動、公開はしないでください。
秘密情報や個人情報は表示しないでください。
不明な点は推測せず、確認方法を示してください。

調査結果を人が確認してから、「どの機能を、どのアカウントへ、いつ有効にするか」を一つずつ依頼します。AIとの承認範囲はCodex・Claude CodeでWordPressを管理する安全ルールでも解説しています。