先週、久しぶりに中小企業のWordPress案件でプラグイン障害の対応依頼が来た。プラグインの一括アップデート後に管理画面が真っ白になるという、いかにも「よくある」やつだ。
対応しながら正直なところ、「また同じ話だ」と思った。この種の障害を私は過去に何度経験したか数えきれない。個別の現場の問題というより、構造的に起きるように設計されているようなものだ、と最近では感じている。
プラグイン10〜30個構成が「標準」になった経緯
中小企業のWordPressサイトを引き継ぐとき、最初にやることのひとつは wp-content/plugins/ の中身を確認することだ。引き継いだサイトの典型的な内訳を見ると、だいたいこういう構成になっている。
| カテゴリ | 代表的なプラグイン | 本数目安 |
|---|---|---|
| SEO・解析 | Yoast SEO, MonsterInsights, WPtouch | 3〜5 |
| セキュリティ・スパム | Wordfence, Akismet, Limit Login Attempts | 2〜4 |
| パフォーマンス | WP Super Cache, Autoptimize, Smush | 2〜4 |
| フォーム・CTA | Contact Form 7, WPForms, Popup Maker | 2〜3 |
| バックアップ・移行 | UpdraftPlus, WP Migrate DB | 1〜2 |
| UI・ページビルダー | Elementor, WPBakery, Slider Revolution | 2〜5 |
| その他（案件固有） | 多言語化、ショッピングカート、会員管理など | 3〜8 |
合計すると15〜30本になる。これが「標準」として定着してしまっている。
なぜこうなるかというと、理由は単純だ。「必要な機能があったら、評価の高いプラグインを探してインストールする」というのが、WordPressにおける最も手軽な問題解決策だから。予算をかけずに機能追加できる。短期的には正しい判断に見える。制作会社側も、カスタム開発より早い。
問題は、それを繰り返した結果として積み上がった「依存関係の総量」だ。
4つの更新サイクルが噛み合わない
WordPressサイトには、互いに独立した更新サイクルを持つ4つのレイヤーが存在する。
- PHP — ホスティング環境側で管理。EOLサイクルが独自にある
- WordPress コア — 月次〜不定期でリリースされる
- テーマ — 開発元のサポート状況に依存し、廃盤になることもある
- プラグイン（10〜30本） — それぞれ独立した開発ベンダーがいる
この4つが完全に独立して動いている。PHPが8.1から8.2に上がると、対応が遅れているプラグインが静かに壊れる。WordPressコアのアップデートでAPIが変わると、テーマの表示が崩れる。あるプラグインが別のプラグインのフックをオーバーライドして、管理画面が真っ白になる。
# アクティブなプラグインの一覧をWP-CLIで確認する
wp plugin list --status=active --format=table
# 典型的な出力（20行以上になることが多い）
# name status update version
# akismet active none 5.3.1
# contact-form-7 active none 5.8
# elementor active available 3.18.0
# ...（以下20行続く）このコマンドを実行して20行以上出てきたとき、運用を考えると「何かが壊れる確率が高いサイト」だと判断するようになった。依存関係のマトリックスが大きすぎる。
今思えば、設計段階でプラグインの上限本数を決めておくべきだったと思う案件が何件もある。引き継いだ時点ですでに30本入っていて、それを減らす権限も予算もない、という状況が現実には多いのだが。
Web担当者が1人という体制の現実
依存関係の問題よりも、実際に障害対応を難しくしているのは「体制」の問題だと考えている。
中小企業のWebサイト管理者の典型的なプロフィールはこうだ。総務か広報の兼任で、IT専門ではない。Webサイトの運用は仕事全体の2〜3割。プラグインの更新は「通知が来たら押す」レベルの理解でやっている。
この体制で15〜30本のプラグインを管理するのは、構造的に無理がある。
ステージング環境でアップデートの影響を確認してから本番に適用する、などという運用は現実的ではない。「管理画面に赤バッジが出たから、全部まとめて更新ボタンを押した」——それが障害の起点になる。
# 本来あるべきフロー: ステージングで確認してから本番適用
wp --path=/var/www/staging plugin update --all
# 動作確認後に本番個別適用
wp --path=/var/www/production plugin update contact-form-7ドキュメントにはこう書いてあるけど、ステージング環境を持っている中小企業は少数派だ。持っていたとしても、ステージングと本番のPHPバージョンがずれていて再現できない、ということも起きる。
ここは改善の余地があると分かっていても、体制の問題なので技術だけでは解決しない。
「止まったら直す」と「止めない設計」のコスト比較
ここが本題だ。
「止まったら直す」運用と「止めない設計に変える」運用では、コスト構造がまったく異なる。
| 観点 | 止まったら直す（現状維持） | 止めない設計（静的化・構成見直し） |
|---|---|---|
| 初期コスト | 低い（現状維持） | 高い（移行・設計コスト） |
| 障害対応コスト | 不定期に発生（1件あたり2〜4時間） | 大幅に減少（プラグイン依存がない） |
| 月次保守コスト | 月2〜5万円（保守契約） | 月数百円〜（インフラ費のみ） |
| セキュリティリスク | CVE公表後の対応が常に発生する | 攻撃面自体が存在しない（静的化の場合） |
| 担当者依存度 | 高い（プラグイン知識が必要） | 低い（git管理、手順が明確） |
月次保守が2〜5万円かかっているサイトであれば、移行コストを12〜24か月で回収できる計算になることが多い。ただし、これはコーポレートサイト（会員機能・予約・EC等が不要なケース）に限った話だ。
「止めない設計」というのは、静的サイトジェネレーター（Astroなど）への移行か、プラグインを必要最小限に絞り込んだ軽量WordPress構成への見直しを指す。前者の方がより根本的だが、サイトの機能要件によっては後者が現実解になることもある。
運用を考えると、「障害が起きるたびに緊急対応費用を払う」関係が続くより、一度の移行コストで構造を整理した方が、発注側・受注側の双方にとって健全な関係になると考えている。
今後に向けて
ただし、すべてのWordPressサイトを静的化すべきだとは思っていない。
会員機能・予約システム・ECが必要なサイトでは、WordPressの方が現実的な選択肢になる場面がある。問題は、「本当にそれが必要か」を確認せずにWordPressを選んでいるケースが多い点だ。コーポレートサイトの多くは、ニュース更新・実績紹介・問い合わせフォームだけであれば、サーバーサイドの動的処理は不要だ。それでもプラグイン30本入りのWordPressで動いていることが普通にある。
最近は引き継ぎ前の初回ヒアリングで、「このまま保守を続ける」以外の選択肢を必ず提示するようにしている。静的化の可能性、プラグイン削減の余地、現在の月次コストと移行した場合の比較を1枚で整理して渡す。
それだけで会話の質がかなり変わる。「止まったら直す」か「止めない設計に変えるか」の判断は、最終的にはクライアントがするものだが、選択肢が見えていないと判断自体ができない。
