WordPressセキュリティ対策｜制作会社ディレクター10年・300案件で固定した多層防御の優先順位フレーム

「WordPressって改ざんされやすいって聞いたんですが、まず何をすればいいですか？」――これは中小企業のWeb担当者の方からも、Web制作を始めたばかりのフリーランスの方からも、毎月のように受ける相談です。私はWeb制作会社でディレクター・プロジェクトマネージャーとして10年以上、コーポレートサイト・EC・キャンペーンサイトを中心に300案件超のWordPress構築・運用に関わってきました。上場企業のサイトリニューアル案件では、運用フェーズに入ってからの不正ログイン試行が日次1万件超を観測した時期もあり、その実データを踏まえて多層防御フレームを組み直した経験があります。本記事ではその順序固定を開示します。

結論から言うと、WordPressのセキュリティ対策は、巷で語られる表層TIPS（プラグイン羅列／ログインURL変更／キャプチャ）の組み合わせでは実務が動きません。なぜなら、表層TIPSは「個別の防御手段」を語っているだけで、「どの層をどの順番で固めるか」を語っていないからです。私が300案件で繰り返し直面したのは、Wordfenceを入れて満足し、コアの自動更新を切ったまま放置していた結果、テーマ／プラグインの脆弱性経由で改ざんを受けるパターンでした。本記事では発注側（中小企業のWeb担当者・経営者）と受注側（制作会社・フリーランス）の両方の読者を想定し、多層防御の優先順位フレームと、各層で使う判断軸を1つずつ整理します。

この記事でわかること：

WordPressのセキュリティ対策は「多層防御の優先順位フレーム」で動かす（300案件で見えた実務の現実）

まずは結論の根拠を整理します。WordPressのセキュリティ対策の入門記事や上位記事では「Wordfenceを入れる」「ログインURLを変える」「reCAPTCHAを入れる」といった表層TIPSの羅列で語られることが多いですが、これは「個別の防御手段」の整理であって「層の順序」の整理ではありません。私が300案件超のWebディレクターとして現場で見てきたのは、表層TIPSで動こうとした担当者ほど「プラグインを5本入れて満足し、コアの更新を半年放置」「ログインURLは変えたがadminユーザーのまま」という順序逆転に陥り、結果としてテーマ／プラグイン経由の改ざんを受けるケースでした。

300案件で固定された4層防御フレーム

上場企業のサイトリニューアル案件で、私が実際に組み立てたのは次の4層防御フレームです。層の順序を逆転させないこと自体が、被害確率を桁単位で下げる差別化要因になりました。

1. 第1層 ログイン経路の遮断 ── 管理画面（/wp-admin）、ログインページ（/wp-login.php）、XML-RPC、REST API の4つの侵入口を、ユーザー名強度・パスワード強度・二要素認証（2FA）・IP制限・ログインURL変更で固める。これを飛ばすと、他の3層を厚くしてもブルートフォースが日次1万件単位で殴り続ける状況になる。
2. 第2層 脆弱性管理 ── WordPressコア、有効化中の全テーマ、有効化中の全プラグインの更新運用を「いつ・誰が・どの基準で」適用するかルール化する。脆弱性経由の改ざんは、ログイン経路を固めても止められない別系統のリスク。
3. 第3層 バックアップと復旧フロー ── 月次／週次／日次の世代管理、保存先の分散（サーバー外）、復旧手順の事前リハーサル。「事故が起きる前提」で組み、第1層・第2層を突破された場合の最終防衛線として機能させる。
4. 第4層 WAF／サーバー側多層防御 ── レンタルサーバー側のWAF、CDNレベルのWAF、Cloudflareなどのリバースプロキシ、SSL/TLSの最新規格対応。アプリケーション層を超えた攻撃（DDoS／既知ペイロード）の入口で削る。

順序を守らずに第4層からスタート（WAFを入れて満足）すると、肝心の第1層（admin/弱パスワード）が露出したままになるため、攻撃者から見れば「玄関の鍵は開いているのに、外壁だけ厚い家」になります。300案件のうち、改ざんを受けたサイトの大半が「第4層は手厚いが第1層・第2層が薄い」という順序逆転でした。

なぜ「プラグイン羅列型」の対策では破綻するのか（公的データで読み解くリスク水準）

「セキュリティプラグインを2〜3本入れれば安心」という認識が、なぜ実務で破綻するのか。これは公的データを見ると構造的な理由が浮かびます。

IPA（独立行政法人 情報処理推進機構）が毎年公開する「情報セキュリティ10大脅威 2024」（出典：IPA 情報セキュリティ10大脅威 2024）では、組織向け脅威のTOP10に「ランサムウェアによる被害」「サプライチェーンの弱点を悪用した攻撃」「内部不正による情報漏えい」「標的型攻撃による機密情報の窃取」「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」「ビジネスメール詐欺による金銭被害」「脆弱性対策情報の公開に伴う悪用増加」などが並びます。WordPressサイトに直結するのは、特に「修正プログラム公開前のゼロデイ攻撃」と「脆弱性対策情報の公開に伴う悪用増加」の2つで、これらはプラグインを入れたかどうかではなく「更新運用がルール化されているか」で被害確率が大きく変わる項目です。

また、警察庁が公開する「サイバー空間における脅威の情勢」（出典：警察庁 サイバー空間をめぐる脅威の情勢）では、不正アクセス禁止法違反の検挙件数や、ランサムウェアによる被害報告件数の年次推移が公開されています。中小企業の被害報告が増加傾向にあり、特に「公開済み脆弱性を悪用した攻撃」「VPN機器・サイト等の認証情報を悪用した攻撃」が継続的に観測されています。WordPressサイトの場合、認証情報（管理者ID／パスワード）の漏えいと、プラグイン脆弱性の悪用がこの統計の主要構成要素になっており、第1層（ログイン経路）と第2層（脆弱性管理）の2つで被害の大半を予防できる構造です。

JPCERT/CC（一般社団法人 JPCERTコーディネーションセンター）の「インシデント報告対応レポート」（出典：JPCERT/CC インシデント報告対応レポート）でも、Webサイト改ざん／フィッシングサイト設置／マルウェアサイトの報告件数が四半期ごとに公開されており、CMS（WordPressを含む）の脆弱性悪用が継続的な比率で報告されています。プラグインを入れても、コア／テーマ／プラグインの更新が止まっていれば、報告件数の構造的な分母を減らすことはできません。

経済産業省と独立行政法人 情報処理推進機構（IPA）が共同で公開する「サイバーセキュリティ経営ガイドライン Ver 3.0」（出典：経済産業省 サイバーセキュリティ経営ガイドライン）では、経営者が認識すべき3原則と、CISOに指示すべき重要10項目が整理されています。中小企業のWeb担当者にとって、この「指示すべき10項目」のうちWordPressサイト運用に直結するのは「脆弱性情報の収集と適用」「インシデント発生時の体制整備」「サプライチェーン対応（外部委託先の管理）」の3項目で、これらはプラグイン購入予算ではなく、運用ルールと体制で決まる項目です。

第1層 ログイン経路の遮断（300案件で固めた最優先実装）

4層フレームの第1層、ログイン経路の遮断から具体的に整理します。WordPressのログイン経路は、表面的には「/wp-login.php」と「/wp-admin」の2つに見えますが、実際にはXML-RPC（/xmlrpc.php）とREST API（/wp-json/）の2つも認証経路として攻撃面になります。300案件の運用で観測したブルートフォース攻撃の大半は、XML-RPC経由の試行が含まれていました。

第1層で固定された5つの実装項目

制作会社10年で固定した、第1層の実装項目を順序通りに整理します。これは「全部やる」のが基本で、1つでも欠けると残りが意味を失う層です。

1. adminユーザーを使わない ── インストール直後に作成した管理者ユーザーが「admin」のままなら、即座に別名で管理者ユーザーを作成し、旧adminユーザーは削除する。攻撃者は最初に「admin」を試行するため、ユーザー名強度だけで被害確率が大きく変わる。
2. 強パスワード＋二要素認証（2FA） ── 16文字以上の英数字記号混在、辞書攻撃耐性のあるパスフレーズ。加えてGoogle Authenticator等のTOTP方式での2FA必須化。SMS方式の2FAは番号乗っ取りリスクがあるため非推奨。
3. ログインURLの変更 ── /wp-login.php を独自パスに変更する。SiteGuard WP PluginやWPS Hide Loginで実装可能。これだけでは突破される（IDS／OSINT経由で発見される）ため、単独施策ではなく「強パスワード＋2FA」と組み合わせる前提。
4. XML-RPCの無効化または制限 ── 外部連携（Jetpack等）で使用していなければ、サーバー側で /xmlrpc.php へのアクセスを遮断する。.htaccessでのIP制限が基本。
5. REST APIの認証必須化 ── /wp-json/wp/v2/users などの未認証GETを制限する。ユーザー名列挙経由の準備工作を防ぐ。

これら5項目を全て揃えて、ようやく「ログイン経路の遮断」が成立します。1つでも抜けると、攻撃者は最も弱い経路から試行を始めるため、全体の安全性は最弱項目で決まる構造になります。中小企業案件で観測した不正ログイン試行は、上場企業案件と桁が違うだけで、構造は同じです。

なお、認証情報を扱う以上、保管・運用に個人情報保護の観点が絡みます。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン」（出典：個人情報保護委員会 個人情報の保護に関する法律ガイドライン）では、安全管理措置の中で「アクセス制御」「アクセス者の識別と認証」「外部からの不正アクセス等の防止」が組織的・技術的安全管理措置として整理されています。受注側（制作会社・フリーランス）が委託契約で運用を引き受ける場合、契約書に2FA運用とパスワード管理ポリシーを明記しておくのが、後の責任分界点を整理するうえで標準です。

第2層 脆弱性管理（コア・テーマ・プラグインの更新運用ルール化）

第2層は脆弱性管理です。ここは「やる／やらない」の二択ではなく、「どの粒度・どの頻度でルール化するか」の設計問題になります。300案件で観察したのは、更新を「気が向いたとき」にやっている運用は、必ずどこかで止まり、止まったタイミングで脆弱性を踏むという事実でした。

300案件で固定された更新運用ルール

上場企業案件・中小企業案件を通して固まった、現実的に回る更新運用ルールを整理します。

1. コアのマイナー更新は自動有効化 ── セキュリティリリース（マイナー版）はWordPress 5.6 以降、デフォルトで自動更新が有効。これを手動で切らない運用が基本。
2. コアのメジャー更新は月次・ステージング先行 ── 6.x → 6.y のようなメジャー更新は、本番直適用ではなくステージング環境で動作確認後に本番反映する。月初の固定曜日に枠を取るのが現実的。
3. プラグインの更新は週次・テーマは月次 ── プラグインは脆弱性報告頻度が高いため、週次で更新通知を確認し、セキュリティ修正は即適用、機能追加は週次反映が基本。テーマは月次の見直しで充分なケースが多い。
4. 有効化していないプラグイン・テーマは削除 ── 「停止中のプラグイン」も脆弱性経由で悪用されることがあるため、半年使っていないものは削除する。
5. 更新ログの保管 ── 「いつ・誰が・何を更新したか」をスプレッドシート1枚でいいので残す。インシデント発生時の調査コストが激減する。

このルールを契約書に「保守契約の最低ライン」として明記するのが、受注側にとっても発注側にとっても透明性が高い運用です。なお、IPAの「組織における内部不正防止ガイドライン」（出典：IPA 組織における内部不正防止ガイドライン）でも、システム管理者の操作ログ保管と権限分掌が組織的安全管理措置として整理されており、更新ログを残すこと自体が「組織として安全管理措置を講じている」根拠の一部になります。

脆弱性情報の取得源

脆弱性情報の取得源は、複数のソースを並列で見るのが基本です。具体的には次の3つを最低ラインで押さえます。

• JPCERT/CC 注意喚起・脆弱性関連情報 ── JPCERT/CC 公式 でWebサイト改ざん／CMS脆弱性の情報を定期確認。
• JVN（Japan Vulnerability Notes） ── JPCERT/CCとIPAが共同運営するJVN でWordPress関連脆弱性情報をRSS購読。
• WordPress公式 セキュリティリリース ── WordPress.org Security でコアのセキュリティリリースを把握。

第3層 バックアップと復旧（最終防衛線としての世代管理）

第3層はバックアップと復旧フローです。第1層・第2層を完璧に組んでも、ゼロデイ脆弱性・サプライチェーン攻撃・内部不正など、予防では止められないインシデントが残ります。「事故が起きる前提」で組むのが第3層で、ここを薄くした案件は復旧コストが指数関数的に膨らみました。

300案件で固定されたバックアップ世代管理

制作会社10年で固まったバックアップ運用の最低ラインを整理します。

1. 日次バックアップ（直近7世代） ── ファイル＋データベースの両方。レンタルサーバーの自動バックアップ機能でカバーできるケースが多い。エックスサーバーやConoHa WINGは日次14世代の自動バックアップ機能を標準提供。
2. 週次バックアップ（直近4世代） ── サーバー外（ローカルストレージ／別クラウドストレージ）への退避。サーバー全体が侵害された場合の最終防衛線。
3. 月次バックアップ（直近12世代） ── 長期保管。リライト後の差し戻し、改ざんを後追いで発見した場合の復元に使う。
4. 復旧リハーサル（年1回） ── バックアップから実際にステージング環境を復元するリハーサル。「バックアップは取れているが復旧したことがない」状態は、事実上バックアップがないのと同じ。
5. 個人情報を含むバックアップの保管期間ルール ── 個人情報を含むデータは、保管期間と廃棄ルールを明確化する。利用目的との関連性で必要な期間に限定する運用が、個人情報保護法の要請に整合する。

サーバー選定の段階で、自動バックアップ機能の有無は重要な判断軸になります。詳細はWordPressのおすすめサーバー（PHP・キャッシュ視点）とレンタルサーバー比較（用途別マトリクス）で整理しています。バックアップ運用込みで考えると、サーバー側に世代管理機能があるかどうかは月額1,000円台の差以上の価値があるケースが多い、というのが300案件の体感です。

第4層 WAF／サーバー側多層防御（SSL/TLS・Cloudflare・サーバーWAF）

第4層はWAF（Web Application Firewall）とサーバー側の多層防御です。順序として第4層に置いていますが、これは「重要度が低い」という意味ではなく、第1〜3層を固めずに第4層から入ると効果が薄いという意味です。第1〜3層が揃った上で第4層を厚くすると、攻撃の大半を「アプリケーション層に到達する前」に削れるようになります。

サーバー側WAFの実装ライン

サーバー側WAFは、レンタルサーバーが標準提供しているものをまず有効化するのが基本です。エックスサーバー・ConoHa WING・カラフルボックス等の主要レンタルサーバーは、WAF機能を標準で提供しており、管理画面からON/OFFの切り替えと、ルールセットのカスタマイズが可能です。デフォルトでONになっているサーバーもあれば、初期設定で手動有効化が必要なサーバーもあるため、契約直後に必ず確認します。

SSL/TLSとHSTSの実装

SSL/TLSの実装は、Let’s Encryptの無料証明書で十分なケースが多く、TLS 1.2以降のみ許可、TLS 1.0/1.1は無効化するのが2026年時点の標準ラインです。HSTS（HTTP Strict Transport Security）ヘッダの設定で、HTTPアクセスを強制的にHTTPSへ昇格させ、中間者攻撃の余地を削ります。総務省「情報通信白書」（出典：総務省 情報通信白書）でも、暗号化通信の普及状況とサイバーセキュリティの動向が継続的に整理されており、HTTPS化は社会インフラとしての前提になっています。

Cloudflare等のリバースプロキシ層

大規模サイトや、DDoS攻撃が懸念されるサイトでは、Cloudflareなどのリバースプロキシ層を追加します。中小企業案件では無料プランで十分なケースが多く、IPの隠匿、Bot対策、レートリミットがWAF機能と組み合わせて有効化できます。注意点として、Cloudflare経由のリクエストはサーバーログ上の送信元IPがCloudflareのIPになるため、SiteGuardやWordfenceのIP制限機能と組み合わせる場合、Cloudflareの実IP復元機能（CF-Connecting-IPヘッダ）を有効化しておく必要があります。

セキュリティプラグイン3本の比較（Wordfence / SiteGuard / All-In-One）

第1〜4層を実装する際に使うセキュリティプラグインを、300案件で実運用した3本で比較します。「どれが最強か」ではなく「どの層をカバーするか」「運用負荷がどう違うか」で選ぶのが基本です。

300案件で固まった「2本構成」の組み合わせ

3本全部入れる必要はなく、機能重複が運用負荷を増やすため、300案件で固まった現実的な組み合わせは次の2パターンです。

• 中小企業案件の標準形：SiteGuard WP Plugin（第1層）＋ サーバー側WAF（第4層）＋ レンタルサーバー標準バックアップ（第3層）。コアの自動更新＋プラグイン週次更新ルール（第2層）で全層をカバー。
• 中〜大規模サイトの強化形：Wordfence（第1層・第2層・第4層）＋ サーバー側WAF（第4層）＋ Cloudflare（第4層）＋ 別クラウドへの週次退避（第3層）。

テーマ・プラグインの選定そのものについてはWordPressプラグインのおすすめとWordPressテーマ比較（SWELL/Cocoon/Lightning）で整理しているので、組み合わせ全体での運用負荷を見るには併読をおすすめします。

300案件で5年残った施策10選／廃れた施策10選

制作会社10年・300案件超の運用で「5年経っても残った施策」と「廃れた／非推奨になった施策」を、定着率データとして整理します。新規実装の優先順位を決める時の参考にしてください。

5年残った施策10選

1. 強パスワード＋2FA（TOTP方式）の管理者全員必須化
2. adminユーザーの廃止と別名管理者ユーザーへの切り替え
3. SiteGuard WP Plugin によるログインURL変更＋画像認証
4. XML-RPCの遮断（外部連携を使わないサイトの場合）
5. WordPressコアのマイナー更新自動有効化
6. プラグイン週次・テーマ月次の更新ルール
7. レンタルサーバー標準の日次自動バックアップ有効化
8. サーバー外への週次バックアップ退避
9. SSL/TLS（TLS 1.2以降）＋HSTS有効化
10. サーバー側WAFの有効化＋ルールセットの最低ライン適用

廃れた／非推奨になった施策10選

1. セキュリティバイ オブスキュリティ（wp-config.phpの場所を変えるだけ）単独運用
2. 「.htaccessで管理画面ディレクトリにBasic認証」のみで2FAを入れない運用
3. SMS方式の2FA（番号乗っ取りリスクの観点で非推奨）
4. セキュリティプラグインを5本以上重ねる構成（機能重複で運用破綻）
5. WAF・キャッシュ系プラグインだけで「セキュリティ対策完了」と見なす運用
6. 古いWordPress（5.5以前）のまま「動いているから触らない」運用
7. サーバー内のみ（同じディスク）でのバックアップ運用
8. FTP（暗号化なし）でのファイル転送
9. 共有レンタルサーバーでのMySQLパスワード使い回し
10. 「Wordfence入れたから安心」型の単独運用（第2層・第3層を放置）

上場企業案件・中小企業案件で繰り返し観測したのは、廃れた施策のうち1〜2項目を残したまま「全体としてセキュリティが固まった」と認識して運用が止まり、半年後にインシデントを踏むパターンでした。施策の本数ではなく、廃れた施策が残っていないかの棚卸しを年1回行うのが、300案件で固まった保守運用の基本形です。

インシデント発生時の90日復旧プロトコル（保全→通報→復旧→再発防止）

第1〜4層を組んでも、ゼロデイ脆弱性・サプライチェーン攻撃・内部不正でインシデントが起きる可能性は残ります。発生時の対応をテンプレ化しておくことで、復旧コストと二次被害を最小化できます。300案件のうちインシデントが実際に起きた案件で固まった90日復旧プロトコルを開示します。

Day 1〜3 保全フェーズ

最優先は「事実の保全」と「拡大の停止」です。改ざんされたサイトをそのままにせず、サーバー側でメンテナンスモード（503）に切り替え、ログ（アクセスログ・エラーログ・WordPressデバッグログ）と現状ファイルのスナップショットを取得します。復旧を急いで上書きすると、原因究明と再発防止に必要な証跡が消えるため、保全フェーズは復旧フェーズの前に必ず置きます。

Day 4〜7 通報フェーズ

個人情報が漏えいした可能性がある場合、個人情報保護委員会への報告が必要になるケースがあります。個人情報保護委員会の「漏えい等の報告」（出典：個人情報保護委員会 漏えい等の報告）では、報告対象となる事案と報告期限が整理されています。また、JPCERT/CCの「インシデント報告フォーム」（出典：JPCERT/CC インシデント報告）で改ざん・マルウェアサイト化の報告を行うことで、攻撃者IPの共有や類似攻撃の警戒情報につながります。サイバー犯罪に該当する場合は、警察庁または各都道府県警察のサイバー犯罪相談窓口への相談も並行します。

Day 8〜30 復旧フェーズ

復旧は「直近の正常時バックアップからの復元」が基本ですが、バックアップ時点で既に改ざんされていた可能性を必ず確認します。日次バックアップだけで遡るのではなく、週次・月次のバックアップとファイル差分を突合せ、改ざんが入った推定タイミングより前の世代から復元します。復旧と同時に第1〜2層の全項目を強化（全パスワード変更／全管理者ユーザー棚卸し／全プラグイン・テーマ・コア更新／不要プラグイン削除）します。

Day 31〜90 再発防止フェーズ

再発防止は、根本原因の特定と運用ルールの改訂で構成します。「どの層から侵入されたか」を保全フェーズで取得したログから推定し、その層の運用ルールを改訂します。改訂内容を保守契約書に反映し、次回の更新リハーサルで動作検証する流れが、300案件のうちインシデント案件で固まった再発防止プロトコルです。

FAQ（300案件で頻出した質問への回答）

Q1. セキュリティプラグインは何本入れるべき？

2本以内に収めるのが300案件の体感で機能重複が起きにくいラインです。中小企業案件の標準形はSiteGuard WP Plugin 1本＋サーバー側WAF＋サーバー側バックアップ、中〜大規模サイトはWordfence 1本＋サーバー側WAF＋Cloudflareの構成。プラグインを増やすほどPHPメモリ・更新運用・機能重複の管理コストが指数関数的に増えます。

Q2. ログインURLは変えるべき？

変えた方が攻撃の試行回数を桁単位で減らせます。ただし「ログインURL変更のみ」では、IDS／OSINTで発見されるため単独運用は避け、必ず「強パスワード＋2FA」と組み合わせます。300案件で観察した範囲では、ログインURL変更単独で安心して残りを放置した運用は、半年〜1年で別経路から侵入される傾向がありました。

Q3. 自動更新は本当に有効化すべき？

セキュリティリリース（マイナー更新）は自動有効化が現実的です。WordPress 5.6以降はデフォルトで有効になっており、これを手動で切る理由はインシデントリスクと比較して薄いケースが多い。メジャー更新は手動＋ステージング先行が基本。プラグインの自動更新は、影響範囲が大きいプラグイン（フォーム／決済／キャッシュ系）は手動、それ以外は自動でも実務が回ります。

Q4. バックアップはサーバーの機能だけで十分？

「サーバー側バックアップのみ」は第3層として不完全です。サーバー全体が侵害された場合、サーバー内のバックアップも同時に侵害されるリスクが残るため、必ず「サーバー外への退避」を最低週次で組みます。中小企業案件であれば、UpdraftPlus等のプラグインでGoogle Drive／Dropboxへの週次退避でも実務が回ります。

Q5. インシデントが起きたら必ず警察に通報すべき？

個人情報漏えいの可能性がある場合は、個人情報保護委員会への報告が必要になるケースがあります（個人情報保護法の規定）。サイバー犯罪に該当する不正アクセス／改ざんは、警察庁または各都道府県警察のサイバー犯罪相談窓口へ相談できます。JPCERT/CCへの報告は法的義務ではありませんが、攻撃情報の共有という観点で報告するケースが多い、というのが300案件のうちインシデント対応案件での実例です。報告判断は契約上の責任分界点で発注側／受注側のどちらが行うかを契約書で事前に決めておくのが基本です。

Q6. 制作会社に保守を委託するときのセキュリティ条項は？

保守委託契約書に「更新運用ルール（コア／プラグイン／テーマの頻度・基準）」「バックアップ運用（頻度・世代・保存先）」「インシデント発生時の通報体制（誰が・いつまでに）」「個人情報の取り扱い」「契約終了時のデータ引き渡し方法」の5項目を最低明記するのが、300案件で観察した標準ラインです。月額の見積もり差は、この5項目の運用ルールの粒度差で説明できるケースがほとんどです。発注時の費用観点は中小企業ホームページ制作費用（3年TCO）とホームページ保守費用相場で整理しています。

まとめ：4層フレームと優先順位で動かすWordPressセキュリティ

WordPressのセキュリティ対策は、プラグインを2〜3本入れたかどうかではなく、「①ログイン経路の遮断 → ②脆弱性管理 → ③バックアップと復旧 → ④WAF／サーバー側多層」の優先順位フレームを順序通りに固めることで実務が動きます。Web制作会社のディレクター・PMとして10年以上、300案件超のWordPress構築と運用、上場企業のサイトリニューアル案件で日次1万件超の不正ログイン試行を継続観測した経験で固まった順序固定は、層を逆転させると効果が桁単位で落ちました。

本記事の運用ラインを動かす前提として、サーバー側のバックアップ世代管理とWAFが標準提供されているレンタルサーバーを選ぶことが、第3層・第4層の運用負荷を半減させます。エックスサーバーとConoHa WINGはどちらも自動バックアップ＋WAFを標準提供しており、本記事の4層フレームを最短で組める構成です。テーマは著者情報の構造化が組みやすいSWELLを推奨します。

発注側（中小企業のWeb担当者）にとって本記事の価値は、「業者に何を依頼すべきか」「契約書のセキュリティ条項に何を書くべきか」の判断軸を持てることです。受注側（制作会社・フリーランス）にとっての価値は、「保守契約の最低ラインを言語化できる」「インシデント発生時に責任分界点が明確になる」ことです。300案件で観察した範囲では、契約書の段階でセキュリティ条項が言語化されていれば、インシデント発生時の混乱と二次被害が大幅に減りました。

本記事の4層フレームと優先順位は、2026年時点のWordPress運用の標準ラインです。年1回の棚卸しで「廃れた施策が残っていないか」「新しい脅威に対応できているか」を確認し、ルールを改訂する運用が、5年単位で運用を続けられる体制の基本になります。次の一歩として、自サイトを4層フレームに当てはめ、最も薄い層から1つずつ実装することをおすすめします。