WordPressプラグインの選び方｜導入・停止・削除の判断表

1. 追加する機能を一文で決める

「問い合わせフォームを設置し、管理者が受信できるようにする」のように必要な結果を書きます。テーマ、サーバー、既存プラグインに同じ役割がないか確認します。たとえばキャッシュを複数の場所で設定すると、どこを消せば表示が更新されるか分からなくなることがあります。

機能が重なる場合は、片方を削除する前に、各設定が何を担当するかを書き出します。SEO機能ならタイトル・サイトマップ・リダイレクトなど別の役割も持っているかもしれません。一つの機能が重複していることと、全体が不要なことは区別します。

2. 候補の公開情報と運用条件を確認する

スマホでは表を横にスクロールできます。

配布元は公式ディレクトリや開発元を確認し、出所不明の改変版を使わないようにします。インストール・更新・削除の基本操作はWordPress公式のプラグイン管理を参照できます。

3. 一つの代表操作で導入前後を比べる

1. 変更前のファイル・データベースを保存し、戻す方法を確認する。
2. 検証環境で候補を導入し、必要な設定だけを行う。
3. 目的の機能だけでなく、主要ページ・編集・フォームなど既存機能も確認する。
4. 採用した理由、バージョン、設定場所、契約更新先を台帳へ残す。

フォームなら入力エラーと受付後の通知、キャッシュなら更新後の反映など、役割に合う操作を試します。検証環境から顧客へのメールや本番課金が発生しないようにする点はステージングの確認表を参照してください。

4. 停止と削除を分け、依存する表示を確認する

停止は機能の無効化、削除はファイルや、製品によっては保存データも取り除く操作です。削除しても設定が残る場合もあります。商品データ、フォーム履歴、独自ブロック、ショートコードなど、プラグインがないと読めない内容がないか先に調べます。

必要なデータを移し、置き換え後の表示を確かめてから不要なものを削除します。停止中だから放置してよいと考えず、今後使う必要と管理方法を決めます。親テーマや他プラグインが必要とする機能まで一緒に削除しないでください。

5. 機能台帳で更新と引継ぎを楽にする

台帳の記入例：「名称／目的／設定画面／関連ページ／保存するデータ／更新担当／ライセンスの期限／戻し方」。ログイン情報そのものは書かず、適切な保管場所を別途管理します。

削減の目標を「10個以下」のような数にせず、重複した機能や使わない処理を減らします。保守は更新前後の作業票、保存はバックアップの保存先へ進んでください。製品選びに迷うときは、まず必要な機能の一文へ戻ると候補を絞れます。

6. 「SEOプラグインが2つある」を、機能ごとに分けて判断する

次のA・Bは例の構成です。実在する製品名や、特定製品を検証した結果ではありません。AとBの両方を使っているサイトで、「SEOという名前が同じなので片方を削除したい」と考えた場面を例にします。

スマホでは表を横にスクロールできます。

この構成でAを丸ごと削除すると、タイトルの重複を解消できても、サイトマップや過去記事の説明文を引き継げないかもしれません。Bを消す場合は、旧URLの転送が止まる可能性があります。先に製品ごとの機能を無効にできるかを調べ、最終的な担当を一つずつ決めます。

入れ替えの前後で照合する3つのURL

1. 過去の記事：説明文やタイトルを個別設定したページ。新しい担当へ切り替えても、意図した内容が公開HTMLへ出るかを確認。
2. 新しい記事：個別設定がない場合の既定値を確認。過去記事だけ正常でも、今後の記事の設定が空になる構成は見逃さない。
3. 移転前のURL：以前から使っている転送先へ進むか確認。転送ループや、無関係なトップへの転送に変わっていないかを確認。

さらにサイトマップのURLと掲載対象を確認します。「設定をエクスポートできた」は移行完了ではありません。移行先へ読み込んだ後の表示・転送・出力を照合して初めて、その範囲を確認済みにします。製品ごとに保存形式が違うため、共通の一括移行方法がない場合もあります。

7. 削除ボタンを押す前に、残したいものから逆算する

停止とアンインストールでデータの扱いが異なることは、WordPress公式のアンインストール処理の説明に示されています。ただし個々の製品がどの処理を実装するかは異なるため、削除後にデータが残るとも、完全に消えるとも一律には判断できません。

停止中の表示を確かめる場合も、本番で突然切り替える前に検証用コピーを使います。フォーム・会員・予約などの機能は、見た目の確認に加えて、保存データと通知・決済の接続先を調べます。

• 停止しても本文が読める：独自ブロック、ショートコード、一覧表示が残っていないか。確認はトップだけでなく、その機能を使うページで行う。
• 必要なデータを利用できる：エクスポートファイルがあるだけでなく、移行先や保管用の環境で内容を読めるか。
• 代替の担当が決まっている：転送、通知、定期処理など画面に出ない役割も引き継いだか。
• 削除時の扱いが分かる：開発元の資料、削除時の選択肢、契約終了時の外部データの扱いを確認したか。

一つでも未確認なら、その時点では「削除候補」と記録し、削除済みにはしません。再開する条件を「転送ルールの照合完了」「保存データを別環境で読めることの確認」のように具体化します。放置を続ける理由にせず、確認担当と期限を決めます。

新規導入を見送れる場合もある

必要なのが「質問を開閉して読む」だけなら、既存の編集機能やHTMLで足りるかを先に試せます。当サイトの開閉するFAQ見本はHTMLの標準要素を使っています。これは独自PHPサイト上の見本で、WordPressの全テーマや権限設定で同じ表示になると検証したものではありません。WordPressへ使う場合は、保存後の公開表示と編集者の権限を別に確認します。

一方、質問の一括管理、承認手順、複数言語の同期などが必要なら、開閉だけでは目的を満たしません。「追加しない」を先に結論にせず、必要な結果と運用担当から選びます。

WordPress変更判断・引継ぎシートを保存する（TXT）。機能担当表と、採用・移行・削除の保留理由を記入できます。