WordPress引き継ぎ案件のプラグイン整理：削除判断の手順と確認3点

引き継いだWordPressの管理画面でプラグイン一覧を開くと、有効・無効が混在した状態に直面することがある。
「何を消せるか」の判断基準がないまま削除を始めると、見えないところで機能が壊れる。
削除判断で詰まる原因の大半は、プラグインが「何をしているか」より「今も使われているか」を確認する手順を知らないことにある。
自分が過去の引き継ぎ案件で実際に踏んだ手順をもとに、現状把握→判断→段階削除の流れをまとめる。

引き継いだ直後にやること：現状把握3ステップ

整理を始める前に、現状を記録しておく。
「後で元に戻せる状態」を作ってから動くのが、引き継ぎ案件での鉄則だ。

バックアップを取る

プラグインに触れる前に、サーバー側のバックアップとは別にWordPress側でも1本取っておく。
UpdraftPlusなど外部ストレージに保存できるプラグインを一時的に使うのが確実だ。
「サーバー側に任せているから大丈夫」という案件でも、作業直前のスナップショットは自分で持つことにしている。

有効化プラグインの全量を書き出す

管理画面のプラグイン一覧から、有効化されているものを全件テキストにメモする。
スクリーンショットでも可だが、プラグイン名と有効/無効の状態が確認できる形で残す。
この一覧が、後のロールバック手順でも使える。

各プラグインの使用箇所を確認する

プラグイン名だけ見ても「使っているかどうか」は分からない。
確認すべき箇所は次の3点だ。

1. ページ内にショートコードや専用ブロックが使われていないか
2. ウィジェットエリアへのプラグイン由来ウィジェットの配置状況
3. 設定画面が初期値のまま手付かずになっていること

設定が初期値のままのプラグインは、インストールしたが使われていないケースが多い。
テーマを途中で変更した案件では、旧テーマ向けに入れた機能プラグインが無効化もされずに残っていることがある。
プラグインが増える構造的な原因の大半はこれで、「試して放置」「テーマ変更後の残骸」が重なった結果だ。

削除できるかを判断する3つの確認軸

判断に迷うプラグインは、以下の3軸で確認する。
全部クリアしたものが「削除しやすい候補」になる。

自分が過去の引き継ぎ案件で整理したとき、有効化されているプラグインの中に「設定画面が初期値のまま・ショートコードも未使用」なものが複数あった。
前任者が試しにインストールしたまま放置したパターンだ。

ページ仕分けとまったく同じ構造で、引き継ぎ案件のプラグインも仕分けすると3〜4割は「なくても困らない」ものが残っている場合がある。
ページ整理との考え方についてはリニューアル準備の記事も参考にしてほしい。

削除判断のあとで見落としやすいのが競合リスクだ。
jQueryを使うプラグインが複数入っていた場合、削除後に別プラグインが誤動作するケースがある。
競合による二重読み込みの診断はこちらの記事に手順をまとめている。

無効化→様子見→削除の段階的な進め方

削除の前に「無効化してから様子を見る」ステップが必要だ。
いきなり削除すると、問題が起きたときの原因特定が難しくなる。

自分の案件では次の手順で進めた。

1. 無効化：削除候補を無効化し、フロントと管理画面の表示・フォームの動作を確認する
2. 様子見：1〜2週間はそのまま放置。クライアントから「機能が壊れた」という連絡がなければ次のステップへ
3. 削除：様子見期間が終わったら削除を実行。この時点で再度バックアップを取っておくと安心

無効化と削除の最大の違いは「即時リカバリできるかどうか」だ。
無効化の段階なら有効化ボタン1つで元に戻せる。
削除済みの場合はバックアップからの復元が必要になり、作業コストが大きく変わる。

複数のプラグインを同時に無効化しないことも重要だ。
1つずつ進めないと、問題が起きたときにどのプラグインが原因かを特定できなくなる。

無効化で1〜2週間様子を見るだけで、「消しても大丈夫か」の確証が取れる。
削除を急ぐ理由は基本的にない。

整理後に問題が起きた場合のロールバックは、ステップ1で書き出したプラグイン一覧と作業前のバックアップが頼りになる。
「整理前にどんな状態だったか」の記録がなければ、元に戻す作業も手探りになる。

まとめ

• 整理前に必ずバックアップ＋プラグイン一覧の書き出しをする
• 削除候補は「機能使用状況・代替手段・開発継続性」の3軸で判断する
• 無効化→1〜2週間様子見→削除の順で1本ずつ進める
• 削除済みの復元にはバックアップ復元が必要。事前の記録が命綱になる

保守引き継ぎ案件でプラグイン整理や実装判断に詰まったら、Buildに気軽に声をかけてください。