WordPress のプラグインは「何個までなら安全」という公式の上限や目安はありません。表示速度や安定性を左右するのは数そのものではなく、それぞれのプラグインが何をしているか、そして更新や管理が行き届いているかです。軽いプラグインが30個あるサイトより、重い処理をするプラグインが3個あるサイトのほうが遅いこともあります。この記事では、プラグインの数をどう考えればよいか、数が増えたときに本当に問題になる点、そして増えすぎを防ぐ具体的な管理方法を説明します。
「プラグインは○個まで」が当てにならない理由
「プラグインは20個以内に」「10個を超えると重くなる」といった目安を見かけることがありますが、根拠のある基準ではありません。プラグインには、管理画面に設定項目を1つ追加するだけのものから、全ページで大量のファイルを読み込み、表示のたびにデータベースへ問い合わせるものまであります。中身の違いが大きいため、個数だけで重さを比べても意味がないのです。
表示速度に影響するのは、主に次のような動きです。
- 全ページに CSS や JavaScript、Web フォントを読み込む
- 大きなデータを自動読み込みの設定（
wp_optionsテーブル）に保存し、毎回読み込ませる - 関連記事や閲覧数の集計などで、表示のたびに重いデータベースクエリを実行する
- WP-Cron に重い処理を頻繁なスケジュールで登録する
- 表示のたびに外部サーバーと通信する
こうした動きをしないプラグインは、数が増えても表示速度にはほとんど影響しません。逆にいえば、プラグインを1つ減らしても、それが軽いものであれば速度は変わらないということです。
数が増えると本当に困ること
速度の面では数が決め手にならない一方で、数に比例して増えていくものもあります。それは管理の負担とリスクです。
脆弱性の入口が増える
プラグインの脆弱性は、WordPress サイトが攻撃される原因として多く報告されています。プラグインが増えるほど、どれか1つに脆弱性が見つかる可能性も高くなります。無効化しただけのプラグインでも、ファイルがサーバーに残っていれば攻撃に使われることがあります。
更新の手間と不具合の確率が上がる
プラグインごとに更新のタイミングは異なります。数が多いと更新の確認だけで時間がかかり、更新を後回しにしがちになります。また、更新のたびにほかのプラグインやテーマとの組み合わせで不具合が出る可能性があり、原因の切り分けにも時間がかかります。
開発が止まったプラグインに気づきにくい
長く運用していると、開発が終わったプラグインや WordPress.org から配布停止になったプラグインが紛れ込みます。数が多いほど、こうした「放置されたプラグイン」に気づくのが遅れます。
プラグインを増やしすぎないための管理方法
1. 一覧表で役割を把握する
まず、入っているプラグインを一覧にして、それぞれの役割を書き出します。WP-CLI が使える環境なら、次のコマンドで現在の状態を確認できます。
# プラグインの名前・状態・バージョン・更新の有無を一覧にする
wp plugin list --fields=name,status,version,update
# 無効化されたまま残っているプラグインだけを表示する
wp plugin list --status=inactive表に「何のために入れたか」「どのページで使っているか」「担当者」を加えておくと、あとで見直すときに判断しやすくなります。役割を説明できないプラグインがあれば、それが整理の最初の候補です。
2. 役割が重なっているものをまとめる
SEO、キャッシュ、セキュリティ、画像最適化などは、複数のプラグインで機能が重なりやすい分野です。たとえば SEO プラグインとテーマの両方が OGP を出力している、2つのキャッシュ機能が同時に動いている、といった状態は、無駄なだけでなく不具合の原因にもなります。役割1つにつきプラグイン1つを基本に整理します。
3. テーマやサーバー、WordPress 本体の機能で代替する
テーマに目次や SEO 設定が内蔵されていたり、レンタルサーバーがページキャッシュや WebP 変換を提供していたりする場合は、それを使えばプラグインを減らせます。WordPress 本体にも XML サイトマップの出力機能があります。数行のコードで済む小さな機能（絵文字スクリプトの停止、管理バーの非表示など）は、子テーマの functions.php で置き換えることもできます。
4. 使わないプラグインは削除する
使っていないプラグインは、無効化で止めずに削除まで行います。ただし、削除の前に次の点を確認してください。
- バックアップを取る: 削除したあとで必要だと分かった場合に戻せるようにします。
- データの扱いを確認する: プラグインによっては、削除するとデータベースに保存した設定やデータも消えます。逆に、削除後も設定やテーブルが残るものもあります。説明ページや設定画面で、削除時の動きを確認しておきます。
- ショートコードやブロックが残らないか: 記事内でプラグインのショートコードを使っていた場合、削除すると記事にコードがそのまま表示されます。使われている記事を先に探しておきます。
5. ステージング環境で無効化テストをする
外してよいか分からないプラグインは、ステージング環境（本番のコピー）で1つずつ無効化して確かめます。無効化の前後で表示や機能に変化がないか、PageSpeed Insights や Query Monitor の結果がどう変わるかを記録すると、残すべきプラグインと外してよいプラグインを根拠をもって判断できます。
6. 定期的に棚卸しする
数か月に1回、一覧表をもとに次の点を見直します。
- WordPress.org のプラグインページで最終更新日と検証済みの WordPress バージョンを確認する
- 長く更新されていないものは、代わりのプラグインや別の方法を探す
- 使っているプラグインに脆弱性が報告されていないかを、WPScan や Patchstack などの脆弱性情報で確認する
自動更新の使い方
WordPress の管理画面では、プラグインごとに自動更新を有効にできます。更新漏れを防げる一方で、更新による不具合に気づくのが遅れる可能性もあります。セキュリティ系など更新を急ぎたいものや、更新で不具合が出にくい小さなプラグインは自動更新にし、表示や決済に関わる大きなプラグインは手動で更新してステージング環境で確認する、と使い分けると運用しやすくなります。管理画面の表記や機能は変わることがあります（2026年10月現在）。
まとめ
- プラグインの数に公式の目安はなく、速度を決めるのは各プラグインの処理内容
- 数に比例して増えるのは、脆弱性の入口、更新の手間、放置プラグインのリスク
- 一覧表で役割を把握し、重複をまとめ、テーマやサーバーの機能で代替できるものは置き換える
- 使わないプラグインはバックアップを取り、データとショートコードを確認してから削除する
- ステージングでの無効化テストと定期的な棚卸しで、根拠をもって整理を続ける