WordPressセキュリティプラグインの選び方｜無料でやる必須設定

WordPressのセキュリティプラグインを調べ始めたものの、種類が多すぎてどれを入れればいいのか決められない。そんな状態で止まっている方は多いと思います。

この記事では、プラグインの選び方の判断軸と、無料でやっておくべき設定の手順を、実際に手を動かせるレベルまで落として解説します。サイトを自社で運用している経営者・広報担当の方、制作会社に作ってもらったWordPressを引き継いで管理している方に向けた内容です。

読み終わる頃には、入れるプラグインを1本に決めて、今日中に設定を終わらせられる状態を目指します。なお、WordPressを新しく立ち上げる段階の設定はWordPress初期設定の正しい順番と必須10項目で扱っているので、公開前の方は先にそちらを読むとスムーズです。この記事は「すでに動いているサイトを守る」話に絞ります。

Contents / 目次

1. 結論。総合型を1本入れて、無料で守れる範囲を先に固める
2. WordPressセキュリティプラグインおすすめの選び方。4つの判断軸
3. 無料でやるWordPressセキュリティ設定の手順。ステップ1〜6
4. AIに任せていい範囲と、人がやるべき範囲
5. 対策すると何が変わるか。効果のイメージ
6. よくある失敗と回避法
7. 現場の本音。プラグインより先に決まってしまうこと
8. よくある質問
9. まずは今日、5分でできることから

結論。総合型を1本入れて、無料で守れる範囲を先に固める

WordPressのセキュリティ対策でまずやるべきことは、総合型のセキュリティプラグインを1本だけ入れ、ログイン防御と更新の仕組みを固めることです。有料版の検討や、複雑なファイアウォールのチューニングはその後で構いません。

理由はシンプルで、中小企業のサイトが狙われる経路には、よく知られた型があるからです。「古い本体・テーマ・プラグインの穴」と「管理画面への総当たりログイン」は、その代表格です。ここを塞ぐだけでも、守りの土台が変わります。

攻撃者はあなたの会社を狙って調べているわけではありません。プログラムが世界中のWordPressサイトを機械的に巡回し、穴が空いているところに片っ端から侵入を試みます。だから「うちは小さいサイトだから大丈夫」は成り立ちません。

IPA（情報処理推進機構）も、ウェブサイトへの攻撃は規模の大小を問わず機械的に行われるとして、ソフトウェアの更新やパスワード管理といった基本的な対策を継続するよう呼びかけています（IPA「情報セキュリティ安心相談窓口」）。規模ではなく、設定の甘さが狙われるということです。

やることは3つだけ。優先順位はこの順番

限られた時間で成果を出すなら、次の3つを上から順に片付けてください。

• ①更新を止めない仕組みを作る：本体・テーマ・プラグインを最新に保つ。自動更新の設定と、月1回の目視確認をセットにする
• ②ログインの入口を狭くする：ログインURLの変更、試行回数の制限、画像認証、二段階認証。ここが総合型プラグインの主戦場
• ③壊れたときに戻せる状態にする：自動バックアップと、実際に復元できるかのテスト。ここが抜けている会社が本当に多い

この3つが終わっていない状態で、有料のマルウェアスキャンやWAFの細かい設定に手を出しても、投資対効果は出ません。順番を守るのが一番の近道です。

セキュリティプラグインのタイプ別の役割

「セキュリティプラグイン」とひとくくりにされていますが、役割はけっこう違います。まずタイプを理解すると、選ぶ数と組み合わせが決まります。

タイプ	主な役割	無料で足りるか	入れる本数の目安
ログイン防御特化型	ログインURL変更、画像認証、ログインロック、ログイン履歴	足りることが多い	1本
総合型（オールインワン）	ログイン防御に加えて、ファイル改ざん検知、スキャン、ファイアウォール	基本機能は無料で使える製品が多い	1本（他の防御型とは併用しない）
バックアップ型	データベースとファイルの自動保存、復元	足りる（保存先の容量は要確認）	1本
脆弱性監視型	使用中のプラグイン・テーマに既知の穴が出たら通知	通知だけなら無料枠あり	0〜1本（サーバー側で代替できる場合あり）

ポイント。入れるのは「総合型または防御型を1本」＋「バックアップ型を1本」の合計2本が基本形です。3本目からは、機能の重複と表示速度への影響を天秤にかけて判断してください。

WordPressセキュリティプラグインおすすめの選び方。4つの判断軸

プラグイン選びで見るべきは、機能の数ではありません。「更新が続いているか」「日本語で設定を理解できるか」「サーバー側の機能と重複しないか」「元に戻せるか」の4点です。この順で確認すれば、大きく外すことはありません。

軸1。最終更新日と有効インストール数を必ず見る

WordPress管理画面のプラグイン検索画面や、公式のプラグインディレクトリには、そのプラグインの「最終更新日」「有効インストール数」「動作確認済みのWordPressバージョン」が表示されます。ここを見ずに評価だけで選ぶのが、一番よくある失敗です。

判断の目安は、実際の画面に出ている情報だけで決められます。プラグインの詳細ページに、しばらくテストされていない旨の注意書きが表示されているものは候補から外してください。注意書きが出ていない場合も、最終更新日が数か月以内か、動作確認済みバージョンが自分のサイトのWordPressバージョンと合っているかを必ず見比べます。

更新の止まったセキュリティプラグインは、それ自体が穴になります。最終更新日が古いものより、直近で更新が続いているものを選んでください。

軸2。日本語で意味が分かるものを選ぶ

セキュリティプラグインは、設定項目の意味が分からないまま有効化すると、自分がログインできなくなったり、フォームが送信できなくなったりします。だから「英語のままでも我慢して高機能なもの」より、「日本語で説明が読めるもの」の方が、結果的に安全に運用できます。

候補の出し方と絞り方は、次の手順でやってください。ここまで進めれば、入れるプラグインが1本に決まります。

1. 管理画面の「プラグイン」→「新規追加」で「security」と検索する（総合型の候補が出ます）
2. 有効インストール数が多い順に上位10件ほどを見て、次の条件で足切りする。①最終更新日が数か月以内 ②動作確認済みバージョンが自分のWordPressと合っている ③「しばらくテストされていません」の注意書きが出ていない
3. 残った候補の詳細画面を開き、説明文や設定画面が日本語化されているかを確認する。日本語化されていないものは外す
4. それでも複数残ったら、次の3つを全部備えているものを選ぶ。①ログインURLの変更 ②ログイン試行回数の制限 ③画像認証。この3つがあれば、後述のステップ3の設定が1本で完結します
5. 最後に、契約中のサーバーのWAFと機能が重複していないかを見て、1本に確定する

同じ手順を「backup」で検索してバックアップ型を1本選べば、基本形の2本がそろいます。特定の製品名から入るより、この手順で自分のサイトの条件に合うものを選ぶ方が確実です。

各プラグインの機能名・設定画面の項目名は、バージョンアップで変わります。実際の設定手順や現在の対応機能は、必ず各プラグインの公式ページや管理画面のヘルプで最新の情報を確認してください。

軸3。レンタルサーバー側の機能と重複させない

契約しているレンタルサーバーに、WAF（Webアプリケーションファイアウォール）の機能が用意されていないかを確認してください。

WAFとは、不正な形のアクセスをサイトに届く前に止める仕組みのことです。玄関の前に警備員が立っているイメージだと分かりやすいと思います。

提供の有無や標準で有効かどうかはサーバー会社ごとに違います。契約中のサーバーの公式マニュアルで確認するのが確実です。

サーバーのWAFがすでに動いているのに、プラグイン側でも同じような防御を全開にすると、正常なアクセスまで止まる「誤検知」が起きやすくなります。管理画面の保存操作が403エラーで弾かれるトラブルは、この重複が原因のことが多いです。

だから最初にやることは、契約中のサーバーの管理画面を開いて、WAFが有効かどうか、二段階認証や国外アクセス制限の機能があるかを確認することです。サーバー側でできることは、プラグインでやらない。これが重複を避ける一番簡単なルールです。

軸4。設定を戻せる手段があるかを先に確認する

セキュリティプラグインは、設定を間違えると自分自身が締め出されます。ログインURLを変更してURLを忘れた、IP制限をかけて外出先から入れなくなった、というのは実際によくある事故です。

だから導入前に、FTPやサーバーのファイルマネージャーにログインできる状態を確保しておいてください。締め出された場合の最終手段は、FTPでプラグインのフォルダ名を変更して強制的に無効化することです。この逃げ道がある人だけが、安心して設定を触れます。

無料でやるWordPressセキュリティ設定の手順。ステップ1〜6

ここからは実際の作業手順です。上から順に進めてください。ステップ5の復元テストだけは時間がかかるので、別の日に分けても構いません。

ステップ1。現状を棚卸しして、不要なものを削除する

最初にやるのは、プラグインを入れることではなく減らすことです。管理画面のプラグイン一覧とテーマ一覧を開いて、次の基準で整理します。

• 使っていないプラグイン：停止ではなく削除する。停止中でもファイルはサーバーに残るため、そこに脆弱性があれば攻撃の足がかりになりうる
• 使っていないテーマ：現在のテーマと、その親テーマ、公式のデフォルトテーマ1つだけ残して削除する
• 使っていないユーザー：退職者や制作会社の作業用アカウントを確認し、不要なら削除。投稿がある場合は別ユーザーに引き継いでから削除する
• 権限の見直し：記事を書くだけの人を「管理者」にしない。「編集者」や「投稿者」に落とす

この作業だけで攻撃対象がかなり減ります。地味ですが、費用ゼロで効果が最も大きい工程です。

ステップ2。更新の方針を決めて自動化する

WordPressは、本体・テーマ・プラグインそれぞれに自動更新の設定があります。おすすめの初期設定は、本体はマイナーバージョン（セキュリティ修正）を自動、プラグインは主要なものだけ自動、メジャーバージョンアップは手動確認、という組み合わせです。

本体の自動更新の挙動は、wp-config.phpに次の1行を書くことでも制御できます。FTPまたはサーバーのファイルマネージャーでファイルを開いて追記します。書き込む前に、必ず元のファイルをコピーして手元に保存してください。

<?php
// ［前提］WordPressのルート直下にある wp-config.php に追記します。
// 「/* 編集が必要なのはここまでです ! */」の行より前に書いてください。
// 編集前に必ず wp-config.php のコピーを手元に保存すること。

// 本体のセキュリティ更新（マイナー版）だけ自動で当てる
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// 管理画面からテーマ・プラグインのコードを直接編集できないようにする
// 万一ログインを突破されても、悪意あるコードを書き込まれにくくなる
define( 'DISALLOW_FILE_EDIT', true );

2行目の設定は効果が大きいわりに副作用が少ないので、迷ったら入れてください。自分でテーマファイルを管理画面から編集している場合だけ注意が必要です。

ステップ3。セキュリティプラグインを1本入れて、ログイン周りを固める

WordPressのログインセキュリティで設定すべき項目は、製品が違ってもほぼ共通です。管理画面のメニュー名は製品ごとに異なるので、次の「機能名」で該当する設定を探してください。

設定する機能	推奨する設定値	効果
ログインページのURL変更	推測されない任意の文字列に変更し、必ずブックマーク	総当たり攻撃の大半が入口にたどり着けなくなる
ログイン試行回数の制限	プラグインの初期値のまま有効化する（値を変える場合は、社内の人が数回打ち間違えてもすぐ復帰できる範囲に収める）	1つの経路からの総当たりを大幅に遅くする（IPを変えた攻撃までは止まらない）
画像認証・CAPTCHA	ログイン画面とコメント欄に設定	機械的な自動ログインを弾く
ログイン失敗の通知	管理者メールへ通知（頻度は日次にまとめる）	攻撃の兆候に気づける
XML-RPCの無効化	下の確認手順で影響がないと分かった場合だけ無効	古い経路からの総当たりを止める
二段階認証（多要素認証）	管理者権限のユーザーは全員必須	パスワードが漏れても侵入されにくくなる

探し方の手順は次のとおりです。

1. プラグインの設定メニューを開く
2. 「ログイン」「Login」という語が入った項目を上から順に開く
3. 上の表の機能名と一致するものを見つけたら、推奨値どおりに設定して保存
4. 保存のたびに、別のブラウザ（またはシークレットウィンドウ）でログイン画面が正しく開くかを確認する

この4番目を毎回はさむと、締め出し事故はほぼ防げます。項目名が表と違って迷ったときは、そのプラグインの公式ドキュメントで機能名を検索してください。

XML-RPCの無効化は、外部からWordPressを操作する仕組みを止めるものなので、先に影響を確認してください。確認する項目は次の4つです。①スマートフォンのWordPressアプリから投稿していないか ②Jetpackなど、外部サービスと連携するプラグインを使っていないか ③他システムから記事を自動投稿する仕組みを入れていないか ④ピンバック機能を使っていないか。1つでも当てはまるなら無効化しないでください。すべて当てはまらない場合も、無効化した直後に管理画面へのログインとサイト表示、問い合わせフォームの送信を確認してください。

ログインURLの変更は、変更後のURLを必ず社内で共有してください。担当者1人しか知らない状態は、退職や引き継ぎのときに詰みます。

二段階認証まで含めた具体的な進め方は、WordPress乗っ取り対策。更新と二段階認証を今日から始める手順でも解説しているので、あわせて確認してみてください。

ステップ4。プラグインでは防げない場所を.htaccessで塞ぐ

セキュリティプラグインを入れても手が届きにくいのが、アップロードフォルダでのプログラム実行です。画像を置く場所にプログラムファイルを紛れ込ませて実行させる、という攻撃の型が昔からあります。

ここはサーバーの設定ファイルで直接塞げます。次の内容を書いたファイルを、wp-content/uploads/ の直下に .htaccess という名前で置いてください。

アクセス制御の書き方はApacheのバージョンで変わります。Apache 2.4系では Require all denied、2.2系では deny from all を使います。自分のサーバーがどちらかは、次の順で確認できます。①契約中のサーバーの管理画面で、PHPやApacheのバージョン情報が載っている画面を開く ②見当たらない場合は、WordPress管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」の項目にあるサーバー情報を見る ③それでも分からなければ、サーバー会社の公式マニュアルで確認する。現在提供されている主要なレンタルサーバーはほぼ2.4系なので、下のコードはそちらに合わせています。記述の詳細はApache公式「.htaccess ファイルの使用法」で確認できます。

なお .htaccess を置けるか、どの記述が許可されているかはサーバーの構成によって変わります。貼り付ける前に、契約中のサーバー会社の公式マニュアルもあわせて確認してください。

# ［前提］Apache系のサーバー向けの記述です。
# 置き場所は wp-content/uploads/.htaccess です。WordPress本体直下の .htaccess とは別物なので間違えないこと。
# 契約中のサーバーで .htaccess が使えるか、公式マニュアルで先に確認してください。

# 画像置き場でPHPファイルが実行されるのを止める
<FilesMatch "\.(php|php3|php4|php5|phtml|pht)$">
    Require all denied
</FilesMatch>

設置したら、必ずサイトの表示と画像の表示を確認してください。ここでエラーが出る場合は、サーバーのApacheが2.2系で、記法が対応していない可能性があります。その場合は Require all denied の行を deny from all に書き換えて試すか、サーバー会社のマニュアルで対応する書き方を確認してください。

事務所のIPアドレスが固定されている会社なら、ログイン画面自体をIPで絞るのが最強です。次の内容をWordPress本体直下の .htaccess に追記します。

# ［前提］固定IPの回線が必要です。自宅や外出先から更新する場合は使わないでください。
# 置き場所はWordPress本体直下の .htaccess。編集前に必ずバックアップを取ること。
# 設定を間違えると自分もログインできなくなります。FTPで元に戻せる状態にしてから作業してください。

<Files wp-login.php>
    Require ip 203.0.113.10   # ［ここを自社の固定IPアドレスに変更］
</Files>

ステップ5。バックアップを自動化し、復元テストまでやる

バックアップは「取っている」で終わらせず、「戻せる」まで確認して初めて対策になります。ここを飛ばしている会社が本当に多いです。

最低限の設定は次のとおりです。

• データベース：毎日自動で取得する
• ファイル一式：週1回自動で取得する
• 保存先：サーバー内だけでなく、クラウドストレージなど別の場所にも置く
• 保存世代：改ざんに気づくのが数日後になる前提で、直近数日分をさかのぼれる世代数を残す（1世代だけでは足りない）

そして年に1回でいいので、テスト環境に復元してみてください。「復元手順書が誰にも書かれていない」という状態が、有事に一番効いてきます。

ステップ6。公開前チェックリストで抜けを確認する

ここまでの作業が終わったら、次の項目を上から確認してください。そのままコピーして社内の運用ドキュメントに貼って使えます。

• 本体・テーマ・プラグイン：すべて最新。更新できないものがあれば理由をメモしている
• 不要な資産：停止中プラグイン0個、未使用テーマ0個、休眠ユーザー0人
• 管理者アカウント：ユーザー名が「admin」ではない。パスワードは12文字以上でランダム
• ログイン防御：URL変更済み、回数制限済み、二段階認証済み。変更後URLを社内共有済み
• SSL：全ページがhttpsで表示され、httpからのリダイレクトが効いている
• バックアップ：自動取得が動いている。保存先が別の場所。復元手順が文書化されている
• 連絡先：異常時に誰へ連絡するかが決まっている（サーバー会社、制作会社、社内担当）

SSLの設定に不安がある方は、SSL化しないとどうなるか。無料で対応する手順と失敗回避で手順を確認してから進めてください。

AIに任せていい範囲と、人がやるべき範囲

WordPressのセキュリティ作業でAIが本当に役に立つのは、「調べる」「翻訳する」「文書に落とす」の3つです。逆に、実際にサイトを触る判断と作業は、いまも人が確認しながらやるべき領域です。ここを混同すると、事故が起きます。

AIに任せると早い作業

具体的には、次のような使い方が現場で効きます。ChatGPT、Gemini、Claudeなど、普段使っているツールで構いません。

• 英語のセキュリティ通知の要約：プラグインから届いた英語のアラートメールを貼り付けて、緊急度と必要な対応を日本語で整理させる
• 設定項目の意味の解説：設定画面のスクリーンショットを渡し、「この項目を有効にすると何が起きるか、副作用は何か」を説明させる
• 運用ルールの文書化：更新頻度、担当者、緊急連絡先を伝えて、社内向けの運用手順書の下書きを作らせる
• 棚卸しの整理：使用中プラグインの一覧を渡して、役割の重複や、明らかに不要な候補を洗い出させる

たたき台として渡すプロンプトは、これくらい短くて十分です。あとはAIと対話しながら、自社の状況に合わせて詰めていってください。

あなたはWordPressの運用担当を支援する立場です。
以下のプラグイン一覧を見て、役割の重複・不要そうなもの・
更新が止まっていそうなものを表で整理してください。
判断できない項目は「要確認」と書いてください。

［使用中のプラグイン一覧を貼り付け］
サイトの用途：［コーポレートサイト／採用サイトなど］
更新できる人：［社内1名／外部委託など］

AIに任せてはいけない範囲

一方で、AIの出力をそのまま信じてはいけない領域がはっきりあります。プラグインの現在の機能名・設定画面のメニュー名・最新バージョンの仕様は、AIがもっともらしく間違える代表例です。存在しない設定項目を自信たっぷりに案内されることがあります。

だから、AIが「この設定をオンにしてください」と言ってきたら、必ずそのプラグインの公式ページか管理画面で実物を確認してから触ってください。手順の骨組みはAIに、最終確認は公式情報で、という分担が現実的です。

もう一つ。AIに生成させた.htaccessやPHPのコードを、確認せずに本番サーバーへ貼るのは絶対にやめてください。設定ファイルは1文字の間違いでサイト全体が500エラーになります。必ず編集前のファイルをコピーして保存し、変更後すぐに表示確認する。この2つを習慣にすれば、事故はほぼ防げます。

AIでサイトを作る流れが広がった分、この「作れるけれど運用が設計されていない」状態も増えています。生成AIで立ち上げたサイトの運用設計についてはVibe codingのサイトが詰む前の更新設計でも触れています。

対策すると何が変わるか。効果のイメージ

セキュリティ対策の効果は、売上のように増える形では見えません。代わりに「起きなくなること」と「対応時間が減ること」で現れます。

まず、ログイン防御を設定すると、管理画面へのログイン失敗の通知が減ります。攻撃が止まったのではなく、機械的なアクセスが入口にたどり着けなくなったということです。実際にどれくらい減るかは、サイトの規模や公開してからの期間で大きく変わります。

次に、更新作業の時間が読めるようになります。自動更新と月1回の点検をルール化しておくと、毎回の作業が短時間で終わります。逆に、放置期間が長いサイトほど、いざ更新するときに互換性の問題が噴き出して長時間かかります。こまめにやる方が、結果的に安くつきます。

対策していない場合に発生するコスト

被害が起きたときにかかるのは、復旧費用だけではありません。実際に起きることを順に並べると、次のようになります。

• サイト停止：調査と復旧の間、問い合わせ経路が止まる。BtoBでは商談の入口が数日消える
• 信用の毀損：ブラウザに警告が出た状態を取引先に見られる。説明と謝罪の工数が発生する
• メールが届かなくなる：サーバーが迷惑メール送信に使われると、ドメインの評価が落ちて通常のメールまで届かなくなる
• 原因調査：いつ入られたか特定するためにログを追う作業が発生する。バックアップがないと、どこまで戻せば安全か判断できない

この中で一番重いのは、実は最後の「どこまで戻せば安全か分からない」状態です。バックアップの世代が足りないと、改ざんされたデータごと復元してしまう。だからステップ5のバックアップ設計が効いてきます。

成功している会社の共通点。特別なツールを使っているわけではなく、「更新する日」と「確認する人」がカレンダーに入っています。仕組みではなく習慣で差がついています。

よくある失敗と回避法

ここからは、実際の現場で繰り返し見かける失敗です。どれも悪意なく起きるので、あらかじめ知っておくだけで避けられます。

失敗1。セキュリティプラグインを複数入れて競合する

不安になって、総合型のプラグインを2つ、さらにログイン防御特化のプラグインも入れる。この状態が起きるのは、担当者が交代したときや、制作会社が入れたものを把握しないまま追加したときです。

結果として起きるのは、次のようなトラブルです。

• ログインできなくなる：ログイン画面の認証が二重にかかって誰も入れない
• 保存操作が弾かれる：管理画面で記事や設定を保存すると403エラーになる
• 原因が分からなくなる：どのプラグインの設定が効いているのか切り分けられない

しかも防御力は足し算になりません。

回避策は、ステップ1の棚卸しで「いま何が入っているか」を先に確認することです。そのうえで役割が重なるものを1本に絞る。停止するときは、ログインURLの変更設定を元に戻してから停止してください。設定を残したまま削除すると、ログインできなくなる場合があります。

失敗2。ログインURLを変更した本人しか知らない

これは事故というより人災です。担当者がログインURLを変更し、社内共有せずに退職・異動する。残ったメンバーは管理画面にたどり着けず、更新が完全に止まります。

気づかないまま半年放置され、その間に脆弱性を突かれる、というのが最悪のパターンです。セキュリティ設定が原因で更新できなくなり、更新できないから危なくなる。皮肉ですが、よく見る流れです。

回避策はシンプルで、変更したログインURL・管理者アカウント・サーバーの管理画面情報を、パスワード管理ツールか社内の共有ドキュメントに必ず記録することです。個人のメモ帳やブラウザ保存だけにしないでください。

失敗3。WAFを入れたまま放置して誤検知に気づかない

サーバーのWAFやプラグインのファイアウォールを有効にしたあと、動作確認をせずに終わってしまうケースです。表側のページは普通に見えるので、問題に気づきません。

実際に起きるのは、問い合わせフォームの送信が特定の条件で403エラーになる、管理画面で長文の記事を保存すると弾かれる、といった症状です。フォームが止まっていても、送信者は「送れなかった」と教えてくれません。静かに問い合わせが減ります。

回避策は、WAFを有効にした直後に、必ず自分で問い合わせフォームを1件送信して、通知メールが届くかを確認することです。エラーが出た場合は、サーバー会社の管理画面でWAFのログを確認し、該当のルールを一時的に除外するか、対象のURLを除外設定に登録します。全部オフにするのではなく、引っかかった箇所だけを外すのがコツです。

失敗4。バックアップの保存先がサーバー内だけ

バックアップは取っているものの、保存先が同じサーバー内、というケースも多いです。サーバーごと侵害された場合、バックアップも一緒に暗号化されたり削除されたりします。

回避策は、保存先を必ず別の場所にも分けることです。クラウドストレージでも、月1回手元のパソコンにダウンロードするだけでも構いません。「サーバーが丸ごと使えなくなっても復旧できるか」を基準に考えてください。

現場の本音。プラグインより先に決まってしまうこと

ここは教科書的な解説には出てこない話です。実際のところ、WordPressの安全性を決めているのはプラグインの選択ではなく、「誰が、いつ、何を見るか」が決まっているかどうかです。同じプラグインを入れても、この体制がある会社とない会社で結果が全然違います。

制作会社に作ってもらったサイトほど、更新が止まりやすい

納品後の保守契約が「サーバー管理のみ」で、WordPress本体やプラグインの更新は含まれていない。この形の契約は珍しくありません。契約書には書いてあるのですが、発注側は「保守に入っているから全部見てもらえている」と思っている。この認識のズレが一番危険です。

今日できる確認は1つです。保守契約書を開いて、「WordPress本体・テーマ・プラグインの更新」が作業範囲に明記されているかを見てください。書いていなければ、その作業は誰もやっていない可能性が高いです。

内製と外注の切り分けは、この線で考える

全部を社内でやる必要はありませんし、全部を外注する必要もありません。判断の目安はこうです。

作業	おすすめ	理由
プラグインの棚卸し、ユーザー整理	社内	誰が何を使っているかは社内しか分からない
ログイン防御の設定、二段階認証	社内（初回だけ相談）	一度設定すれば運用は社内で回せる
本体のメジャーバージョンアップ	外注	テーマ・プラグインの互換性確認とテスト環境が必要
.htaccessやPHPの設定変更	外注（または要確認）	失敗するとサイト全体が止まる。復旧できる人が必要
侵害された後の調査・復旧	外注一択	侵入経路の特定と再侵入の防止は経験が要る

見落とされがちなコスト

無料プラグインを選ぶと費用ゼロに見えますが、実際にはかかるものがあります。月1回の点検と更新にかかる担当者の時間、更新で表示が崩れたときの修正、テスト環境を用意する費用です。

ここを見積もらずに「無料で済む」と判断すると、忙しい月に更新が飛び、放置が始まります。だから現実的な落としどころは、日常の運用は社内で、判断に迷う更新と有事の対応は外部に相談できる状態を作っておくことです。

正直に言うと、セキュリティ対策に「これをやれば絶対安全」はありません。できるのは、侵入されにくくすることと、侵入されても早く気づいて戻せるようにすることです。この2つに絞って考えると、やることは意外とシンプルになります。

よくある質問

まずは今日、5分でできることから

この記事を閉じる前に、1つだけやってみてください。WordPressの管理画面を開いて、プラグイン一覧で「停止中」のものが何個あるかを数えることです。1個でもあれば、それが今日削除すべきものです。

そのうえで更新体制まで整えたい方は、更新されないサイトの信用低下を直す更新体制の作り方で、担当者と頻度の決め方を確認してみてください。

ここまで読んで、「やることは分かったけれど、社内で回し続けられる自信がない」と感じた方もいると思います。そういうときは、現状の棚卸しだけでも一緒に整理させてください。何が入っていて、どこが危ないのかが分かるだけで、判断がぐっと楽になります。AI業務システム化の詳細はこちらから、お気軽にご相談ください。