WordPressの
セキュリティ対策。
守る順番から、迷わず。

START HERE

まず、この順番で進める

どれか一つで「完全に安全」にはなりません。まずは設定ミスで入れなくならず、変更後に戻れる状態を作ります。

根拠：WordPress公式・Hardening WordPress。優先順は公式の順位ではなく、復旧性と誤操作リスクを踏まえた編集判断です。

01 / 変更前の備え

「保存がある」から
「戻せる」へ

バックアップは侵入を防ぐ機能ではありません。更新失敗や誤操作の後、復旧するための備えです。

1. 保存対象と日時を確かめる。記事・設定のデータベースと、画像・テーマ・プラグインなどのファイルが対象か確認。更新直前の状態を用意します。
2. 復元する場所・人・期限を確かめる。サーバーの復元画面、保管期間、対象サイト、費用の有無を公式手順で確認。WordPressに入れない時も使える窓口を控えます。
3. 可能なら隔離先で復元し、記事と画像を開く。ファイルがダウンロードできただけでは復元成功ではありません。本番を練習台にしないでください。

保存対象の組合せと復元の詳しい手順 →

02 / 弱点を残さない

更新は、一つ変えて
一つ確かめる

本体だけでなくテーマ・プラグインも対象です。提供元の修正情報を確認し、セキュリティ更新は不要に先延ばしにしません。

1. 「ダッシュボード → 更新」を開く。現在の版、更新対象、提供元の変更履歴・必要なPHP/WordPressの版を確認します。対象が見えない場合は管理者権限や管理会社の制御も確認します。
2. 復旧準備の後、対象だけ更新する。本体は更新ボタン、プラグイン・テーマは対象を選んで更新。表示名は環境で異なります。大幅な版上げ・重要な決済機能などは複製環境で先に確認します。
3. 版と実際の動作を確認する。トップ・記事・画像を未ログインで開き、管理画面と重要なフォームを確認。フォームのボタン表示だけでメール到達まで成功とは判定しません。

自動更新は、確認を省くための設定ではない

「プラグイン → インストール済みプラグイン」の自動更新欄を確認します。必要なら対象を選び、一括操作の「自動更新を有効化 → 適用」で保存できる環境もあります。サーバーや管理用プラグインが制御している場合は、その管理方法を先に確かめてください。

根拠：本体の更新手順・プラグイン／テーマの自動更新。隔離環境で実更新・自動実行は未実証です。

03 / アカウントの入口

固有のパスワードに、
もう一つの確認を

WordPress、サーバー契約、復旧に使うメールは別々に守ります。同じパスワードを使い回さず、パスワード管理ツールで長く固有のものを保存。管理用端末・ブラウザーも更新し、不審なリンクからログインしないでください。

二要素認証（2FA）は、パスワードに加えて認証アプリなどでも本人確認する方法です。漏えい時の備えになりますが、すべての侵害を防ぐ機能ではありません。WordPressとサーバーパネルの2FAは、それぞれ設定が必要です。

Two Factorを使う場合の進め方

1. 復旧手段を確保して、正規の配布元を確認。管理者が利用できること、バックアップがあること、復旧窓口を先に確認。「プラグインを追加」で配布元・対応版を照合し、既存認証と競合しない環境で有効化します。
2. 「ユーザー → プロフィール」のTwo-Factor Optionsを開く。認証アプリ方式（Authenticator App）を設定。自分のアプリでQRを読み、アプリのコードを入力して検証します。英語表示の場合もあります。
3. 認証方式と回復用コードを保存。主な方式（Primary Method）を選び、Backup Codesなど復旧手段を用意。画面の設定を保存します。QR・秘密鍵・回復用コードは記事、スクリーンショット、共有文書に載せないでください。
4. 元のログインを残し、別のブラウザーで試す。パスワードの後にコードが求められ、正しいコードで入れることを確認。復旧手段の保管を確かめるまで、唯一の管理セッションを閉じないようにします。

入れない場合は連打せず、端末時刻・選んだアカウント・コードの期限を確認。回復用コードや管理会社の正規復旧手順を使います。記事コメントや相談文へコードを送らないでください。

根拠：Two Factor公式配布・設定案内・FAQ。設定手順は公式案内と配布コードを照合。ログイン不能時はログイン障害ガイドへ。

04 / 必要な分だけ残す

権限と追加機能を、
小さく保つ

管理者を増やさず、作業に合う権限にする

「ユーザー → ユーザー一覧」で見覚えのある利用者か、必要な権限かを確認。ユーザー名を難しくすることだけに頼らず、認証と権限を分けて考えます。

プラグインやマルチサイトでは権限が変わることがあります。隔離環境では寄稿者の「記事編集可・公開不可・プラグイン導入不可」、編集者の「公開可・サイト設定不可」を実際の権限APIで確認しました。

1. 共同作業は個別アカウントで。作業ごとに必要な権限を決め、保守委託が終わったら不要なアクセスを整理します。
2. 変更前に別の管理手段を確認。唯一の管理者を降格・削除しません。ユーザー削除では記事の削除／所有者の変更が伴うため、記事の扱いを確認します。
3. 変更後は本人の画面で確かめる。必要な作業ができ、不要な管理機能は使えないことを確認。見覚えのない管理者を見つけた場合は、単に整理せず侵害の疑いとして対応します。

使っていないプラグイン・テーマを整理する

用途と依存関係を記録し、不要と確認できたプラグインは、バックアップ → 一つ停止 → 公開画面と機能を確認 → 削除の順で整理します。停止だけではファイルは残ります。削除で設定・データも消える製品があるので、再利用する設定を先に控えてください。

テーマは「外観 → テーマ」で確認。使用中のテーマ、子テーマに必要な親テーマ、復旧用に保つ更新済みテーマを区別し、見た目が未使用だからと親テーマを消さないでください。管理された必須プラグインやドロップインを初心者判断で削除しないことも大切です。

根拠：WordPress公式の権限一覧・プラグイン管理。隔離では合成プラグインの有効化・停止もAPIで確認。削除時の全製品のデータ保持は未検証です。

05 / 通信と運営環境

HTTPSは入口。
安全全体の証明ではない

1. 未ログインで自分のサイトを開く。アドレスがHTTPSになり、ブラウザーの接続情報で証明書の警告がないことを確認。ログイン画面も確認します。
2. 画像・フォームなどの警告も確認。一部がHTTPのままだと混在コンテンツになる場合があります。警告を無視して進むのではなく、サーバーの公式SSL設定手順と対応状況を照合します。
3. 表示がおかしいなら変更を止める。サーバー側の証明書を確認せず、WordPressアドレスだけを書き換えないでください。ログイン不能や転送の循環につながることがあります。

HTTPSは通信を保護する仕組みで、脆弱なプラグインや盗まれた管理権限まで解決しません。サーバーのWAF・国外アクセス制限なども補助対策です。自分のアクセスが拒否されたからと一律に解除せず、公式の解除範囲と復帰方法を確認します。

根拠：WordPress公式・HTTPS、Xserver公式・WordPressセキュリティ設定。今回のHTTPローカル環境ではTLS・WAF・国外制限は未実証。初期設定全体は初期設定ガイドへ。

異常がある場合 / 通常点検より優先

不審な挙動があるとき、
最初にすること

知らない管理者、意図しない広告や転送、身に覚えのない記事、ホスティング会社からの警告がある場合は、更新不足の点検だけで終えません。白い画面やログイン失敗だけで侵害と断定もできません。

相談するときに伝えること

• いつ、どのURLで、どんな症状に気づいたか。
• 直前の変更と、管理会社からの警告の有無。
• 正常だった時点と、利用できるバックアップの範囲。

ログや画面を渡す場合は窓口の正規手順を使い、Cookie・パスワード・認証コード・問い合わせ本文は渡しません。必要な証拠を非公開で保全し、他の利用者へ被害が広がる恐れがある場合は公開制限を急いで相談します。

根拠：Xserver公式・不正アクセス時の対処。具体的な削除・初期化は環境依存のため、このページで一律実行は勧めません。感染除去・漏えい判定の代行はできません。

FINISH / 続けられる点検に

確認できた項目だけ、
チェックを付ける

「チェック数＝安全度」ではありません。未確認の項目を残して、次の作業を決めるためのメモです。入力は送信・保存しません。

当サイトの運用提案：更新通知が来たときは内容を確認し、設定変更後は主要機能を点検。平常時も定期的に、バックアップの成功・不要アカウント・連携・更新漏れを見直します。頻度は更新量と管理体制に合わせ、重大な注意喚起には定期日を待たず対応してください。