WordPressの不要プラグイン整理｜残す・削除する判断基準と安全な確認手順

WordPressのプラグイン一覧に、用途の分からない名前や無効化したままの項目が並んでいませんか。整理は必要ですが、数を減らすことだけを目標にすると、問い合わせの記録、迷惑送信対策、過去の記事の表示など、目立たない役割まで失う可能性があります。先に必要なのは、今のサイトで何を担っているかを調べることです。

この記事では、企業サイトの担当者に向けて、不要なプラグインの見分け方、無効化と削除の違い、別環境での確認、本番へ反映した後の点検までを説明します。WordPress・Contact Form 7・WooCommerceなどの公式資料を参照し、製品名や個数だけで判断しないための確認表を用意しました。説明用の企業サイトや台帳は架空例で、Acquaの顧客成果を示すものではありません。

プラグイン整理の目的は、必要な機能を管理できる状態にすること

個数から表示速度や危険度を決めない

同じ一個のプラグインでも、記事編集時にだけ役立つものと、公開ページで画像や外部データを読み込むものでは役割が違います。「何個以下なら速い」「何個以上なら危険」という個数だけの線引きでは、今のサイトの問題を説明できません。処理が動く場所、保存する情報、外部サービスへの接続、更新やサポートの状況を調べ、残す理由を説明できるようにします。

表示速度が課題なら、問題の起きているページと指標を確かめてから、関係する処理を調べます。管理のしづらさが課題なら、用途や担当の整理から始めます。脆弱性の情報がある場合は、影響する製品とバージョンを確認し、開発元や保守担当の案内に基づいて対応を判断します。一般的な棚卸しの順序と、確認済みの問題への緊急対応を混ぜないことが大切です。

「残す」「調べる」「削除候補」に分ける

最初の分類は三つで十分です。現在の業務で使い、維持する理由が分かるものは「残す」。用途、依存関係、保存データが分からないものは「調べる」。役割を終え、必要なデータの扱いや代替手段も確認できたものを「削除候補」にします。名前を知らない、最近操作していない、といった理由だけで削除候補へ進めないようにしましょう。

例えば、管理担当者が触った覚えのないフォーム連携が、営業部署への通知に使われているかもしれません。逆に、有効化されていても過去のキャンペーンだけで使った機能なら、現在の利用箇所を確認して整理を検討できます。「分からない」は放置するための分類ではなく、誰に何を確認するかを決めるための分類です。確認担当と期限を付けて管理します。

整理して改善したいことを先に記録する

「更新担当が用途を把握できる」「同じSEO情報を二重に出力しない」「使い終わった連携を終了する」など、今回の完了条件を短く決めます。表示速度を改善したいなら、対象URL、使用端末、計測方法、現状の結果も記録します。目的が曖昧なまま削除を進めると、数が減ったことだけを成果としてしまい、サイトの機能が保たれたかを見落とします。

費用の見直しも目的になる場合があります。ただし、プラグインを無効化することと、有料契約の更新を止めることは別です。ライセンス、クラウド側の保存データ、契約更新日、解約による利用制限を確認します。管理画面から消えたから支払いも終了した、と判断しないように、技術面と契約面の担当を分けて記録しておきます。

棚卸しでは、画面に見えない役割も調べる

プラグイン名と、実際の利用箇所を対応させる

WordPressのプラグイン管理の公式説明を入口に、インストール済みの名称、バージョン、有効・無効の状態を確認します。台帳にはそれだけでなく、目的、利用ページ、保存データ、更新担当、代替の有無を加えます。一覧の説明文は一般的な機能の紹介なので、自社で何を使っているかとは別に確認が必要です。

調べる場所には、公開ページ、編集画面、フォーム設定、テーマの設定、定期処理、外部サービスとの連携などがあります。過去の制作資料や変更履歴も役立ちます。制作会社へ聞く場合は、「これは何ですか」だけでなく、「現在使う画面や処理」「止めると失われるもの」「設定やデータを残す必要」を尋ねると、整理に必要な情報が集まりやすくなります。

古い記事、下層ページ、管理作業を確認対象に含める

トップページが変わらなくても、過去の記事で使っていたショートコードやブロックが表示できなくなることがあります。資料請求ページだけにあるフォーム、採用ページの募集一覧、期間限定ページの計測なども確認対象です。新しいページだけでなく、構造の違う代表ページを選び、停止前後に同じ経路をたどって確認します。

日常の更新作業も見落としやすい点です。画像を圧縮する処理、編集者の権限、投稿の複製、公開予約などは、通常の訪問画面だけでは利用を判断できません。社内の編集担当に、月に一度や年に数回の作業も聞きます。「最近使っていない」と「今後も不要」は違うため、事業の予定と合わせて整理します。

通常の一覧とは扱いが違うものを区別する

WordPressには、通常のプラグインとは別に、常時有効な形で設置されるMust Useプラグインがあります。公式説明では、専用ディレクトリに置かれ、通常のプラグイン一覧からは無効化できないことなどが説明されています。サーバー会社や制作会社が運用のために設置している場合もあるので、通常の整理手順をそのまま当てはめません。

複数サイトをまとめて管理する構成では、ネットワーク側で有効にしたものが他のサイトに関わる場合もあります。自分のサイト画面で使っていないことを、全体で不要という根拠にしないでください。管理の範囲が分からない場合は、設置担当や契約先へ確認します。運用基盤に関わるものは、用途を把握した担当者と変更範囲を決める必要があります。

公式の実例から、名前だけで判断できない理由を知る

Akismetはコメント以外のフォームでも使われる

Contact Form 7の公式ドキュメントは、Akismetを問い合わせフォームの迷惑送信対策に連携させる方法を案内しています。つまり、コメント欄を使っていないという理由だけでは、Akismetが不要だとは判断できません。フォームの設定と連携状況を調べ、止めたときに失われる役割がないかを確認します。

これは特定の製品を必ず残すという推奨ではなく、用途の確認が必要だと分かる公開仕様の実例です。迷惑送信対策を別の方法へ変えるなら、通常の相談が受け付けられることと、対策が意図どおりに働くことを確認します。切り替え後の迷惑送信件数だけでなく、正当な問い合わせが誤って止められていないかも、受付担当と確認する項目にします。

WooCommerceでは、ファイル削除と業務データの削除が分かれる

WooCommerceのインストール・アンインストールの公式説明では、通常の無効化と削除ではプラグインのファイルを取り除き、設定や注文、商品などのデータはデータベースに残ると説明しています。業務データも含めて削除するには、別の設定が必要です。この違いは、プラグインを削除すれば関係する情報がすべて消える、という理解が正しくないことを示しています。

反対に、別の製品が同じ動作をするとは限りません。削除時に何を残すかは製品の実装や設定によるため、利用中の公式案内を確認します。過去の注文や問い合わせを保管する必要がある場合は、必要な期間と閲覧方法を先に決めます。「今は販売していない」だけでは、過去の取引に必要なデータまで不要とはいえません。

WordPress 6.5で追加された依存関係の表示をどう使うか

WordPressの開発チームは、2024年3月の公式記事で、バージョン6.5に導入するプラグイン依存関係の仕組みを説明しました。プラグインが必要とする別のプラグインを宣言することで、インストールや有効化の前提を管理画面で把握しやすくするものです。追加機能が本体を必要とするような関係を、管理側でも確認する助けになります。

ただし、その表示がないことを、依存関係がない証明にしないでください。公式記事にも対象や制限が説明されており、すべてのテーマや独自実装の関係まで自動で把握する仕組みではありません。サイトで使用している製品の説明、設定、実際のコードや動作も確認します。便利な管理機能を使いつつ、表示だけで削除判断を完結させないことが、この公開例から得られる実務上のポイントです。

削除候補を絞るときに確認する三つの観点

機能が重なっていても、引き継ぐ設定を先に確認する

同じ分野の製品が複数入っている場合は、実際に有効な機能と出力を比べます。例えばSEO関連でも、タイトル、説明文、サイトマップ、リダイレクト、構造化データの担当が分かれているかもしれません。「二つあるから片方を削除」ではなく、何が重複し、どの設定を移し、どの出力を一つにそろえるかを決めます。

バックアップでも、日常の復元用と、サーバー移転用の一時的な利用では目的が異なります。キャッシュ、画像配信、セキュリティについても、プラグインの製品名だけでなく、サーバーや外部サービス側の機能を含めて確認します。代替できるかは、同じ説明が書いてあることではなく、自社で必要な処理と運用を引き継げるかで判断しましょう。

更新日や利用者数を、単独の合否条件にしない

最終更新日や利用者数は調査の手がかりですが、それだけで安全性や互換性は確定しません。更新が少ない理由、サポートの案内、動作対象、既知の問題、開発元の対応状況を確認します。用途の限定された製品や独自開発のプラグインは、一般的な利用者数が大きい製品と同じ比較ができないこともあります。

有料製品は、更新情報が公式ディレクトリではなく開発元の配布ページにある場合があります。ライセンスが切れて更新を受け取れない状態なら、開発が止まっているのか、自社の契約に問題があるのかを分けて調べます。更新の確認に使う場所と担当を台帳へ残すことで、次回から同じ調査を繰り返す負担を減らせます。

無効化済みでも、残す理由と終了予定を確認する

無効な項目は削除候補を探す入口になりますが、無効だから即座に削除してよいとは限りません。移行の直後で復旧用に保管している、次の担当が確認するために一時停止しているなどの事情がある場合は、その必要性と保管方法を確認します。必要なデータや設定を取り出したうえで、役割が終わったものを整理します。

一方で、「念のため」とだけ書いて無期限に残すと、更新や管理の対象が曖昧になります。必要なら管理された場所へ保存し、本番に置く必要があるかを検討します。未使用コードに問題がある場合の影響は製品ごとに異なるため、無効なら無条件に安全とも断定しません。現在の状態、保管目的、次の判断日をセットで記録します。

無効化・削除・データ整理を別の操作として扱う

無効化で何が起きるかを調べる

WordPressのアンインストール処理の公式説明では、無効化とアンインストールを区別しています。通常の無効化は、削除とは違う処理です。ただし、設定や一時データにどのような処理をするかは製品の実装にも関わるため、「無効化なら何も失われない」と一律には保証できません。利用中の案内を確認してから検証します。

別環境で候補を一つ無効化し、事前に選んだページと業務を確認します。変化があれば、直前の状態に戻して再現条件を調べます。一度に複数を止めると、どれが関係したか分かりにくくなります。ただし、本体と追加機能など、順序や組み合わせを考える必要がある製品は、その前提を整理したうえで確認します。

削除と再インストールだけで、元どおりになるとは限らない

削除時には、プラグインが用意したアンインストール処理によって設定やデータが消えることがあります。後から同じ製品を入れ直しても、以前の設定や履歴が自動で戻るとは限りません。削除前に、保存すべき情報と復元方法を確認します。外部サービス側の連携を解除する必要がある場合は、その手順も対象にします。

通常の管理画面で削除できる状態なら、公式に案内された方法を使います。管理画面に入れない障害対応でファイル名を変える方法などは、平常時の整理とは目的が違います。緊急対応と通常の削除手順を混同せず、作業担当に状況を伝えましょう。管理画面から消えたことだけでなく、機能とデータが意図した状態になったかを確認します。

残ったデータを「不要」と即断しない

プラグイン削除後に残るテーブルや設定には、再導入のために意図して保持されるものや、業務の履歴として必要なものがあります。名前に古い製品名が入っているだけで削除しないでください。別の機能が参照しているか、移行後の処理に必要かを調べます。データベースの整理は、プラグインのファイル削除とは別の作業として範囲を決めます。

最適化ツールが候補を表示した場合も、その表示だけで業務上の不要を判定できるわけではありません。実施するなら、対象、削除理由、バックアップ、復元方法、確認者を記録します。サイト担当者がデータの関係を把握できない場合は、無理に画面上のボタンを押して進めず、保守担当へ調査を依頼する方が判断を具体化できます。

本番へ反映する前に、戻す準備と確認範囲をそろえる

ファイルとデータベースのバックアップを確認する

WordPressの公式バックアップガイドは、一般的なサイト全体の復元にはファイルとデータベースの両方が必要だと説明しています。今回の操作で変わるものを整理し、取得日時、保存先、復元担当を記録します。バックアップファイルが存在することと、それを使って復元できることは別なので、検証環境で復元方法も確認します。

問い合わせや予約が増え続けるサイトでは、古いデータベースへ戻すと、その後に追加された情報が失われる可能性があります。戻す前提には、更新を止める時間、追加データの保全、受付を続ける方法を含めます。会社案内だけのサイトと同じ手順を、予約や受注のあるサイトへ無条件に当てはめないことが必要です。

検証環境では、外部への動作も管理する

サイトをコピーした検証環境でフォームを送ったら、本番の営業担当に通知が届くことがあります。予約、決済、会員通知なども、見た目のコピーだけでテスト用に変わるわけではありません。外部連携や通知をどう制御するかを確認し、実際の顧客や業務へ影響しない条件を整えます。検証用の個人情報や認証情報の扱いも担当者間で決めます。

一方で、すべての通信を止めた環境では、連携が正しく働くかまで確認できない場合があります。その場合は「表示は確認」「実際の受信は未確認」のように範囲を残し、許可されたテスト手順で別途確かめます。環境の制約によって動かなかったことを、プラグインの不具合と誤認しないように、準備条件を記録します。

確認期間は、日数ではなく処理の周期から決める

一定の日数が過ぎれば問題がない、と決めるのは適切ではありません。毎週のバックアップや月初の通知など、まだ実行されていない処理があるかもしれません。逆に、通常のページ表示や入力操作は、その場で代表的な経路を確認できます。機能ごとに実行のタイミングを整理し、期間を置いて確認するものと、テストで確認するものを分けます。

架空の会社案内サイトなら、「主要ページと問い合わせを当日に確認」「次の定期バックアップの結果を確認」「編集担当がお知らせを更新できるか確認」といった計画にできます。実際の順序は運用に合わせます。確認されていない処理が残る間は、その範囲を未確認として管理し、何日経ったから完了という扱いを避けます。

変更後は、表示・受付・計測をそれぞれ確かめる

見た目の変化と、業務機能の変化を分けて点検する

本番へ反映した後は、一般の訪問者として主要ページを開き、PCとスマートフォンで確認します。管理者としてログインした画面だけでは、キャッシュや権限による違いを見落とすことがあります。フォーム、資料ダウンロード、会員操作などは、事前に決めた経路で確認します。操作が完了した表示と、担当者が受信したことは別々に記録します。

SEO関連の機能を変えた場合は、タイトル、説明文、正規URL、検索公開の指定、サイトマップ、必要な転送が意図どおりかを確認します。分析用の機能を変えた場合は、計測先やイベントが途切れたり二重になったりしていないかを確認します。画面の見た目が同じでも、検索や集計に関係する出力は変わる可能性があります。

速度の結果は、同じ条件で比べる

GoogleのLighthouseのスコアに関する公式解説では、計測値が端末やネットワークなどの条件で変動することが説明されています。変更前後を比べるときは、同じURLと条件で複数回確認し、総合点だけでなく、どの指標がどう変わったかを記録します。異なるページや端末の結果を、一つの改善率にまとめないようにします。

整理と同じ日に画像圧縮やサーバー設定も変えたなら、結果をプラグイン削除だけの効果とは言えません。速度が変わらなくても、不要な契約を終了した、更新対象の役割が明確になったという成果はあります。逆に総合点が上がっても、問い合わせが届かなくなっていれば、今回の目的を達成したとは扱えません。機能と性能の両方を評価します。

異常が出たときは、変更記録から調べる

問題が起きたら、症状、対象URL、発生時刻、利用端末、直前の変更を整理します。追加で複数の設定を変える前に、どこまで正常だったかを確認します。重大な受付障害などがある場合は、合意した戻し方と連絡体制に従います。バックアップの取得以後に増えたデータがある場合は、その扱いも含めて復旧担当へ伝えます。

ログを確認するときは、公開画面へ詳しいエラーを表示しないよう、保守担当が適切な設定と保管方法を使います。WordPressの公式デバッグガイドは、開発向けのデバッグ機能とログの扱いを説明しています。記事の手順を見て本番の設定を無造作に変更するのではなく、必要な情報を安全に記録できる担当者と調査を進めます。

整理した状態を保つための運用と相談方法

新しく追加するときに、目的と終了条件を書く

プラグインを入れる前に、実現したい機能、現在の仕組みで対応できない理由、更新担当、費用、終了するときのデータの扱いを短く記録します。期間限定のキャンペーン用なら、終了後の確認日も決めます。機能の試用が終わったあとに、判断の経緯だけが失われることを防ぐためです。大きな台帳でなくても、次の担当が読める形なら役に立ちます。

既存の設定を変える場合も、作業した日と確認結果を残します。プラグイン本体を更新しただけなのか、機能を有効化したのか、外部契約を変更したのかを区別します。記録を続けることで、不具合が起きたときに調べる範囲を絞りやすくなり、制作会社が変わる際の引き継ぎ材料にもなります。

保守を依頼するときは、削除数ではなく確認範囲で比べる

制作会社へ依頼する場合は、用途調査、依存関係の確認、バックアップと復元、別環境での検証、本番反映、反映後の点検がどこまで含まれるかを確認します。「不要プラグインを何個削除」という件数だけでは、作業の内容を比べられません。現状が不明なら、調査後に作業範囲と費用を確定する段階を設ける方法もあります。

相談時には、サイトのURL、気になっている症状、分かる範囲の管理状況、停止できない機能を共有します。認証情報は、共有方法と対象範囲を決めてから必要なものを渡します。依頼先を変更する予定もある場合は、ホームページ引き継ぎの確認項目と合わせて、契約・権限・データを整理すると話を進めやすくなります。

最初の一歩は、用途不明の項目を調べること

この記事を読んで最初に行うことは、一括削除ではありません。プラグイン一覧を確認し、用途が分かるものと、確認が必要なものを分けます。次に、現在の問い合わせや更新の流れと対応させ、利用箇所を調べます。その結果から、必要な機能を保ちながら整理できる候補を決めていきます。

AcquaへのWordPress保守・整理の相談では、何のために入っているか分からない、更新が不安、引き継ぎ資料がないといった状況から共有してください。必要な調査と確認の範囲を整理できます。管理できる状態に整えることが、日々の更新と、次のサイト改善を進める土台になります。

一次資料の確認日：2026年9月9日。製品の動作は利用中のバージョン・設定で確認してください。本記事の製品例は公式資料に基づく仕様の紹介で、Acquaが担当した顧客事例や、特定の速度改善率を保証するものではありません。