なぜ「使わないプラグイン削除」がセキュリティ対策になるのか
テーマのときと同じで、プラグインも中身はすべて PHP コードです。
そして重要なのは、「有効化していなくても、サーバー上にファイルがある限り“攻撃対象になりうる”という点です。
多くの脆弱性は、
特定の PHP ファイルに直接アクセスされる
特定のエンドポイントにリクエストを送られる
ことで発動します。
このとき、プラグインが「有効か無効か」は関係なく、ファイルが存在していれば狙われる可能性があります。
だからこそ、
使っていないプラグインを無効化しただけで放置
→ 実はまだ“爆弾”として残っている
という状態になりがちです。
「使わないプラグイン削除」は、この爆弾を物理的に片付ける行為です。
プラグインが増えると何が危険になるのか
攻撃される“面”がどんどん広がる
プラグインはそれぞれが独立した機能とコードの塊です。
1つなら1つ分のリスクですが、10個あれば10個分のリスクがあります。
その中に、
更新が止まっているプラグイン
作者がメンテナンスをやめたプラグイン
公式外から拾ってきた怪しいプラグイン
が混ざっていると、そこが攻撃者にとっての「入り口」になります。
使っていないプラグインを削除するというのは、
「攻撃される可能性のある入口を減らす」＝攻撃面（Attack Surface）を削ることそのものです。
アップデート管理が破綻しやすくなる
プラグインが多いと、
どれが本当に必要なのか
どれが一時的に入れただけなのか
どれがもう役目を終えたのか
が分からなくなります。
結果として、
更新通知が大量に出る
「あとでやろう」と思って放置
古いバージョンのまま何ヶ月も放置
という状態になりがちです。
セキュリティの観点から言えば、
「何が動いているか分からない」「どれが古いか分からない」状態はかなり危険です。
不要なプラグインを削ることで、「ちゃんと面倒を見られる数」にまで減らせます。
「無効化」と「削除」はまったく別物
無効化は「止める」だけ、削除は「消す」
管理画面のプラグイン一覧には、
有効化
無効化
削除
の3つの状態があります。
無効化
WordPress の動作としてはそのプラグインを読み込まない。
ただし、ファイルは /wp-content/plugins/ に残ったまま。
削除
プラグインのフォルダごとサーバーから消える。
＝そのコードはもう実行されようがない。
セキュリティ的に意味があるのは「削除」の方です。
無効化は「今は使っていない」という宣言に過ぎず、
“そこにコードがある”という事実は変わりません。
例題：よくある「放置プラグイン地獄」
例えば、プラグイン一覧がこうなっているとします。
Contact Form プラグイン（有効）
SEO プラグイン（有効）
キャッシュプラグイン（有効）
昔試したスライダープラグイン（無効）
昔試したギャラリープラグイン（無効）
昔試したバックアッププラグイン（無効）
この「昔試した」シリーズが、まさに危険ゾーンです。
使っていないのに、コードだけはサーバーに残っている。
しかも、もうアップデートもしていない。
こういうプラグインが1つでも脆弱だった場合、
そこから侵入される可能性があります。
どのプラグインを残して、どれを削除すべきか
基本方針：役割が明確で、今も使っているものだけ残す
残すべきプラグインは、ざっくり言うと次の条件を満たすものです。
今もサイトの機能として使っている
役割がはっきり説明できる（「これは◯◯のためのプラグイン」）
定期的にアップデートされている
逆に、削除候補はこんなものです。
一時的に試しただけで、今は使っていない
何のために入れたか思い出せない
最終更新が何年も前
「何のためにあるか説明できないプラグイン」は、ほぼ確実にいらないものです。
例題：整理の判断
例えば、こんな構成だとします。
Contact Form 7（お問い合わせフォームで使用中）
Yoast SEO（SEO設定で使用中）
WP Super Cache（キャッシュで使用中）
Old Slider（昔トップページで使っていたが、今はブロックで代用）
Test Plugin（昔の検証用。今は使っていない）
この場合、
残す：Contact Form 7 / Yoast SEO / WP Super Cache
削除：Old Slider / Test Plugin
という判断になります。
実際の削除手順のイメージ
管理画面から安全に削除する
WordPress 管理画面で、
プラグイン → インストール済みプラグイン
を開きます。
削除したいプラグインが「有効化」されている場合は、
まず「無効化」ボタンを押します。
無効化すると、その行に「削除」というリンクが現れます。
「削除」をクリックすると、
そのプラグインのフォルダが /wp-content/plugins/ から丸ごと消えます。
ポイントは、「無効化で止めて満足しない」ことです。
本当にいらないと判断したものは、削除までやり切るのがセキュリティ的に正しいです。
FTP で直接消すのは“最終手段”
管理画面に入れない場合などは、
FTP やサーバーのファイルマネージャーから
/wp-content/plugins/
にアクセスし、
不要なプラグインのフォルダを削除することもできます。
ただし、これはどのフォルダがどのプラグインか理解している人向けです。
間違って必要なプラグインを消すと、サイトの機能が壊れます。
セキュリティの本質としての「プラグイン削除」
「動いていないコード」もリスクになる
プログラミングの感覚で言うと、
使っていないライブラリ
使っていないエンドポイント
使っていない設定
がプロジェクトに残っていると、
それだけで「どこからバグや脆弱性が出るか分からない」状態になります。
プラグインもまったく同じで、
今は使っていない
でもサーバーには置いてある
というコードは、
「いつ爆発するか分からない地雷」です。
「いらないコードは消す」は、
セキュリティと設計の両方の観点から、非常に重要な習慣です。
「攻撃面を減らす」という超基本のセキュリティ設計
セキュリティの世界では、
公開している機能が多いほど
動いている（置いてある）コードが多いほど
攻撃される“面積”が広がる、と考えます。
これを「Attack Surface（攻撃面）」と呼びます。
使わないプラグインを削除するのは、
この攻撃面を物理的に削る行為です。
ファイアウォールを入れる
2段階認証を入れる
ログイン試行回数制限を入れる
と同じくらい、
「不要なプラグインを消す」は強力な防御レイヤーです。
パフォーマンスとトラブルシューティングの面でもメリット大
読み込み処理や管理画面が軽くなる
有効化されているプラグインが多いほど、
ページ表示時に読み込むコードが増える
管理画面の処理が重くなる
という副作用もあります。
使わないプラグインを削ることで、
「本当に必要な機能だけが動いている」状態になり、
結果としてサイト全体のパフォーマンスも安定しやすくなります。
不具合の原因を特定しやすくなる
トラブルが起きたとき、
プラグインが10個のサイト
プラグインが40個のサイト
では、原因調査の難易度がまったく違います。
プラグインが少なければ、
「この中のどれかだろう」と当たりをつけやすい
1つずつ無効化して検証するのも現実的
という状態になります。
「プラグインを減らす」は、未来の自分のデバッグ時間も減らす行為です。
まとめ：プラグイン整理は“掃除”ではなく“防御と設計”
「使わないプラグイン削除」というのは、
攻撃される入口を減らす
アップデート管理をシンプルにする
パフォーマンスと安定性も上げる
という、かなりコスパの高いセキュリティ＆設計の改善です。
やることはシンプルです。
今使っているプラグインの役割を言語化する
「何のためにあるか分からない」「もう使っていない」ものをリストアップする
それらを無効化 → 削除まで行う
コードの世界と同じで、
「いらないものを消す」ことは、それだけで立派な技術的判断です。
一度プラグイン一覧を眺めて、「この子、本当にまだ必要？」と問い直してみてください。
それだけで、あなたの WordPress は一段セキュアで、スッキリしたシステムに近づきます。
