WordPressプラグインの整理｜削除前に確認する3つの軸とバックアップ手順

2026/09/08

URLをコピーしました！

管理画面のプラグイン一覧をスクロールしていて、「これ、まだ動いていたのか」と思う行がいくつも出てくる。数年運用したサイトなら、たいてい心当たりがあると思います。

表示が遅い、更新のたびに崩れる、管理画面がもたつく。こうした症状が出たとき、真っ先に疑われるのがプラグインの多さなんですよね。

ただ、闇雲に数を減らしても状況は変わりません。まず3つの軸で削除候補を絞り、テーマ機能やコードで代替できるものを見分けます。

そのうえでバックアップを取り、1つずつ停止して問題がないか確かめてから削除する。この順番で進めることが大切です。

基準がないまま削除すると、フォームが動かなくなったり、記事の中に見慣れないコードが表示されたりします。

この記事では、削除候補をあぶり出す3つの選別軸から、停止と削除の違い、削除前のバックアップ手順までを通して整理します。

プラグインが増えると実際に何が起きるのか

遅さの正体は「数」ではなく処理の中身

10個しか入っていないのに重いサイトもあれば、40個入っていても軽快に動くサイトもあります。速度に効いてくるのは個数ではなく、それぞれのプラグインが何をしているかという中身のほう。

負荷が大きくなりやすいのは、フロント側にCSSやJavaScriptを読み込むタイプ、ページ表示のたびにデータベースへ問い合わせるタイプ、そして外部APIと通信するタイプです。

逆に、管理画面でしか動かないプラグインや、特定の投稿タイプでしか読み込まれないものは、10個あってもフロントの表示速度にはほとんど影響しません。

「Query Monitor」を有効化して記事ページを開くと、どのプラグインがどれだけクエリを発行し、どれだけ実行時間を使っているかが一覧で出てきます。感覚で犯人探しをするより、この数字を先に見たほうが早い。整理の優先順位も、ここでだいたい決まります。

使っていないプラグインを置きっぱなしにするコスト

停止しているプラグインは動作していないので、速度への影響はありません。それでも、放置をおすすめしない理由はいくつかあります。

停止中でも、ファイル自体はサーバー上の wp-content/plugins に残ったままです。脆弱性のあるコードがそこに置かれている状態は、条件によっては外部から直接ファイルを叩かれる余地を残します。

また、更新通知が毎週のように並ぶと、本当に当てるべきセキュリティ更新を見落としやすくなります。

不具合が出たときの切り分けコストも地味に効いてきます。原因調査でプラグインを一つずつ止めていく作業は、対象が15個と40個では所要時間がまるで違うんですよね。

削除候補を見つける3つの選別軸

感覚だけで選ぼうとすると、手が止まります。まずは公式ディレクトリで確認できる情報を使い、3つの軸でふるいにかけていきます。

軸1 更新が止まっていないか

最初に見るのは、プラグインページの「最終更新日」です。数年前で止まっているものは、作者がメンテナンスから離れている可能性が高いと考えられます。

WordPress.org のプラグインページでは、対応状況が古いものに「このプラグインは WordPress の最新3回のメジャーリリースに対してテストされていません」という警告が表示されます。

ただし、この文言が出ているからといって、即座に危険というわけではありません。作者が readme の記載を更新していないだけで、実際には問題なく動くケースもあります。

それでも、警告が出たまま何年も放置されていること自体は、「この先WordPress本体の仕様が変わったとき、誰も直してくれない」というサインです。

私は最終更新が3年以上前のものは、無条件で代替候補を探すリストに入れています。

公式ディレクトリからプラグインごと消えている場合は話が別で、最優先の対応対象です。ガイドライン違反か、深刻な脆弱性を理由に閉鎖された可能性があります。管理画面から更新できなくなるため、そのまま使い続けるのは避けたいところです。

軸2 検証済みバージョンとPHPの要求バージョン

同じページに「検証済み最新バージョン」と「PHPバージョン」が載っています。前者が現行のWordPressから何世代も離れている、後者がPHP7系のまま止まっている。

この2つが揃っていると、サーバーのPHPを新しくしたタイミングで動かなくなる確率が上がります。

レンタルサーバー側は定期的にPHPの推奨バージョンを引き上げてきます。そのときに巻き添えで壊れるプラグインを、あらかじめ減らしておくという考え方です。

軸3 有効インストール数とサポートの反応

有効インストール数は「10未満」「10+」「1,000+」のように幅で表示されます。数が少ないこと自体は欠点ではありません。ニッチな用途で丁寧に作られたものも当然あります。

ただ、母数が少ないプラグインは不具合の発見が遅れがちです。1万人が使っていれば誰かがすぐ報告してくれる不具合も、利用者が数十人だと誰にも気づかれないまま残ります。

インストール数とあわせて、サポートフォーラムも開いてみてください。直近の質問に返信が付いているか、未解決のスレッドが積み上がっていないかを確認します。

作者が生きているかどうかは、ここに一番はっきり出ます。

3つの軸を組み合わせて優先度を決める

3つの軸は一つずつ独立して見るのではなく、現在使っているか、代替があるかも重ねて判断します。

ここで決めるのは、削除候補とその優先度です。実際の削除は、後述するバックアップと停止・確認を経てから行います。

プラグインの状態	判断の目安
公式ディレクトリから閉鎖されている	最優先で削除。代替を探す
更新停止＋インストール数が少ない＋代替あり	削除候補の第一グループ
更新は止まっているが動作は安定、代替なし	停止せず据え置き。代替探しを継続
更新は活発だが自分は機能を使っていない	削除。使っていないものに更新の手間をかけない
更新も活発で日常的に使っている	残す

判断に迷ったときは、「これがなくなったら何が困るか」を一言で説明できるか考えてみてください。説明できないものは、たいてい削除しても困りません。

テーマ機能やコードで代替できるものを洗い出す

削除候補が出そろったら、次は「そもそも要らなかった」ものを探します。ここが一番減らせるところです。

テーマと役割が丸かぶりしている定番

多機能テーマを使っている場合、以下の機能はテーマ側に最初から入っていることが多いです。プラグインとテーマの両方で同じ処理が走っていると、表示が二重になったり、CSSが衝突して崩れたりします。

目次の自動生成、SNSシェアボタン、関連記事の表示
パンくずリスト、投稿一覧のカスタマイズ、CTAエリアの設置
画像の遅延読み込み、CSSの縮小化といった簡易的な高速化処理

WordPress本体に取り込まれた機能も見落としがちです。画像の遅延読み込みはコア標準の挙動になっていますし、XMLサイトマップも本体が出力します。

「昔は必要だったから入れた」プラグインが、いまも必要とは限らないんですよね。

テーマの設定画面を開き、いま入っているプラグインと同じ名前の項目がないか、一通り見てみてください。2つ3つはすぐ見つかると思います。

数行のコードで足りるもの

単機能のプラグインは、テーマの functions.php に数行書くだけで置き換えられるものが少なくありません。

ただし、コードを直接書く場合は、必ず子テーマか自分用の小さなプラグインとして分離してください。親テーマの functions.php に書き足すと、テーマ更新のたびに消えます。

プラグインの用途	代替の考え方
解析タグや広告タグの挿入	`wp_head` にフックして出力
絵文字用スクリプトの停止	該当アクションを `remove_action` で外す
コメント機能の無効化	管理画面の設定＋数行のコード
管理バーの非表示、ログイン画面のロゴ変更	フィルターフック1つ
特定ページへのリダイレクト	`template_redirect` で処理

コードスニペット管理用のプラグインを1つ入れ、そこへ集約する方法も現実的な選択肢です。5個のプラグインが1個にまとまるなら、十分に元は取れます。

逆に、自作に置き換えないほうがいいもの

何でもコード化すればいいというものでもありません。次の5分野は、専門のプラグインに任せたほうが安全です。

セキュリティ対策
バックアップ
お問い合わせフォーム
決済まわり
本格的なキャッシュ処理

自作コードに置き換えるということは、脆弱性が見つかったときに自分で直す責任を引き受けるということです。

そこまでの手間をかけたくない領域は、素直にメンテナンスされているプラグインを使い続けるのがおすすめです。

停止と削除は何が違うのか

「使わないから停止しておこう」で止まっている運営者は多いはずです。ただ、停止と削除では、残るものがまったく違います。

停止はスイッチを切っているだけ

プラグインを停止すると、WordPressは有効なプラグインの一覧からそのプラグインを外します。

処理は走らなくなりますが、消えるのはそれだけです。プログラムのファイルはサーバーに残り、データベースに保存された設定値も手つかずのまま残ります。

そのため、再度有効化すれば設定はそのまま復活します。不具合の切り分けで一時的に止めるときや、季節限定で使う機能には便利な状態ですが、長期保管の置き場所としてはあまり適していません。

削除してもデータベースには残る

管理画面から削除すると、wp-content/plugins 内のファイル一式は消えます。

一方、データベースに書き込まれた値が消えるかどうかは、プラグイン側が「アンインストール時にデータを消す処理」を実装しているかによって変わります。

この処理を実装していないプラグインのほうが多数派です。再インストールしたときに設定を復元できるように、という配慮でもあるので、一概に手抜きとは言えません。

その結果、使わなくなった設定値がデータベースに積み上がっていきます。

ここで見落としやすいのが、削除前にできる対策です。設定画面に「アンインストール時にすべてのデータを削除する」といったチェック項目を持つプラグインがあります。

これを先にオンにしてから削除すれば、後片付けはほぼ不要になります。削除ボタンを押す前に、設定画面を一度開いて探してみてください。

どこに何が残るのか

残る場所	残るものの例
wp_options	各種設定値、ライセンスキー、期限切れのトランジェント
wp_postmeta、wp_termmeta	記事やカテゴリーごとに保存された個別設定
独自テーブル	フォームの送信データ、アクセスログ、リダイレクト設定
wp_posts	カスタム投稿タイプで作られた投稿。管理画面から見えなくなるだけ
ファイル	uploads 配下の生成物、キャッシュ用の advanced-cache.php など
設定ファイル	wp-config.php や .htaccess への追記
WP-Cron	定期実行の予約イベント

特に注意したいのが、キャッシュ系プラグインです。wp-config.php に定数が書き足されたり、wp-content 直下に専用ファイルが置かれたりします。

プラグイン本体だけを削除すると、参照先を失ったコードがエラーを吐き、画面が真っ白になることがあります。

キャッシュ系は、プラグインの設定画面にある無効化の手順を必ず踏んでから削除してください。

残骸が積み重なると起きること

一つひとつは数KBでも、数十個分たまると効いてきます。わかりやすいのが、wp_options の肥大化です。

このテーブルには自動読み込みの指定があり、指定された値はページを表示するたびに全部読み込まれます。

WordPress 6.6以降はサイトヘルスに判定項目が追加され、自動読み込みされる値の合計がおよそ800KBを超えると「パフォーマンスに影響する可能性がある」という警告が出るようになりました。

ダッシュボードの「サイトヘルス」から確認できるので、整理の前後で数字を比べてみると効果がわかります。

削除済みプラグインが登録したままのWP-Cronイベントも残りがちです。実体のない処理を呼び出し続けるだけなので、実害は小さいものの、気持ちのいいものではありませんよね。

削除前のバックアップと安全な進め方

削除候補が決まったら、事故を避けるための準備をしてから作業に入ります。

バックアップは3種類そろえる

データベース全体のダンプ（設定値と記事データが入っています）
wp-content ディレクトリ（最低でも plugins と uploads）
削除するプラグインの設定画面のスクリーンショット

3つ目も軽視しないでください。復元が必要になる場面の大半は、サイト全体が壊れたときではなく、「あの設定、何を入れていたっけ」と思い出せないときです。

API キーや連携先の情報は、画面を撮っておくだけで後が楽になります。

サーバー会社の自動バックアップに頼りきるのも避けたいところです。何世代保存されるのか、復元の申請に費用がかかるのか、自分の契約プランの条件を先に確認しておきます。復元できないバックアップは、無いのと同じですから。

停止から削除までの5ステップ

STEP

一覧を作る

プラグイン名、用途、最終更新日、代替の有無を書き出した一覧を作る

STEP

バックアップを取る

データベースと wp-content のバックアップを取る

STEP

1つだけ停止する

候補を1つだけ停止する（複数を同時に止めない）

STEP

動作を確認する

3日から1週間、フロントと管理画面の動作を確認する

STEP

削除する

問題がなければ、データ削除の設定を確認したうえで削除する

3番目の「1つずつ」が要点です。まとめて5個止めて不具合が出た場合、原因の特定にかえって時間を取られます。急がば回れです。

3日から1週間の様子見を置くのは、止めた直後には異常が見えない処理があるためです。予約投稿、自動バックアップ、メールの自動送信のほか、週に1回しか動かない処理や、月初にだけ走る集計もあります。

確認期間内に実行日が来ない処理は、その実行時期にも動作を見てください。

削除後に確認する場所

削除したら、まずブラウザーとサーバー両方のキャッシュを消します。そのうえで、次の場所を順に開いてください。古い表示を見て安心してしまうのを防ぐためです。

トップページ
記事ページ
カテゴリーページ
お問い合わせフォーム

記事本文に [shortcode] のような文字列がそのまま出ていないかも確認します。ショートコードで機能を呼び出していたプラグインを消すと、変換されなくなった記述が本文に露出します。

記事数が多い場合は、管理画面の検索窓にショートコード名を入れて該当記事を洗い出すのが手っ取り早い方法です。

最後にサイトヘルスを開き、新しいエラーが出ていないかを見ておきます。

残った設定値をどこまで掃除するか

削除が終わったあと、データベースをどこまで掃除するか。結論から言うと、大半のサイトはやらなくても困りません。

wp_options を確認する

phpMyAdmin から wp_options テーブルを開き、option_name をプラグイン名や接頭辞で検索すると、残っている値が見つかります。サイズの大きい順に並べるなら、以下のクエリが使えます。

SELECT option_name, LENGTH(option_value) AS size, autoload
FROM wp_options
ORDER BY size DESC
LIMIT 30;

出てきた名前を検索し、削除済みプラグインのものだと確信が持てたものだけを消します。判断がつかない行は残しておく。数KBの行を1つ消すために、サイトを壊すリスクを取る意味はありません。

独自テーブルとカスタム投稿タイプ

フォーム系やログ系のプラグインは、専用テーブルを作ります。

送信データが数万件たまっていると、容量としては無視できないサイズになっているはずです。中身が本当に不要かを確認し、バックアップを取ってから削除します。

カスタム投稿タイプで作られた記事は、投稿タイプを登録するコードが消えた時点で管理画面から見えなくなります。ただし、データ自体は wp_posts に残っているため、必要なら復元も可能です。

見えないものは、しばらく置いておいても実害はほとんどありません。

掃除しなくていい場合の見分け方

手を出すべきなのは、実害が数字で見えているときだけです。次のどれにも当てはまらないなら、放置で問題ありません。

サイトヘルスで自動読み込みの警告が出ている
データベースの容量がサーバーの上限に近づいている
管理画面の表示が明らかに遅い

データベース最適化プラグインを新しく入れて掃除する、という選択もあります。ただ、プラグインを減らすために別のプラグインを入れることになります。

掃除が終わったら、それ自体も削除するところまで含めて計画してください。

よくある質問

プラグインは何個までなら大丈夫ですか: 上限の数字はありません。個数ではなく、フロントで動く処理の重さで決まります。目安を挙げるとすれば、「一覧のすべてについて、何のために入れているか即答できる状態」です。答えられない行があるなら、それが多すぎるサインです。
停止したまま置いておくのは駄目ですか: 一時的なら問題ありません。数か月使う予定がないなら、削除して必要になったら入れ直すほうが管理は楽です。設定を残したい場合は、削除前に設定画面のスクリーンショットを撮っておきます。
削除したプラグインをまた使いたくなったらどうしますか: 公式ディレクトリのものなら、同じ名前で再インストールできます。データベースに設定が残っていれば、そのまま復活することも多いです。公式ディレクトリから消えたプラグインは入手できなくなるため、削除前にファイル一式をダウンロードして手元に保管しておくと安心です。
まとめて停止して一気に確認しては駄目ですか: 本文の5ステップでは、不具合の原因を切り分けやすいよう、1つずつ止める進め方を基本にしています。不具合が出なければ、まとめて止めてもかまいません。難しいのは、不具合が出たときに原因を絞り込めなくなることです。10個以上を整理するなら、3個ずつのグループに分けて進めるくらいが現実的なバランスだと感じています。
テーマを変える予定がある場合はどうしますか: テーマ変更を先に済ませることをおすすめします。新しいテーマの内蔵機能によって、不要になるプラグインが変わるためです。順番が逆だと、削除したものをもう一度入れ直す羽目になります。