WordPress プラグイン 脆弱性の対応が追いつかない制作会社へ──入れる前の選定基準と、入れたあとの棚卸しで守る対象を減らす

この記事は、WordPress プラグイン 脆弱性の対応に追われる制作会社が、選定と棚卸しで守る対象そのものを減らす方法を扱います。

「便利だから入れた」プラグインが、5年後の保守を重くする

「このサイト、プラグインが38個入っているんですが、半分は何に使っているかわかりません」

引き継いだサイトを開くと、こういう状態は珍しくありません。
制作のときに担当者が「便利だから」と入れ、そのまま誰も見直していない。

プラグインは、入れた日から保守の対象になります。
1つ増えるごとに、更新の確認と、脆弱性の情報を追う手間が増えていきます。

プラグインの選定と棚卸しとは、入れる前に「続くか・要るか」を確かめ、入れたあとに「まだ要るか・まだ続いているか」を定期的に確かめる管理である

黒字化の外科医です。プラグインの脆弱性を、入口と出口の両方で減らす管理を解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

選定と棚卸しが必要な理由は、三つあります。

第一に、使われていないプラグインも、守る対象だから。
IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」は、不要なサービスやアプリケーションがないか、不要なアカウントが登録されていないかを、確認項目に挙げています。使っていない機能は、守る手間だけが残ります。

第二に、開発が止まると、更新では守れなくなるから。
WordPress.orgの公式ディレクトリでは、最新の主要なリリースで検証されていないプラグインに注意書きが出ます。配布が停止されたプラグインは、ダウンロードできない旨が表示されます。配布が止まっても、すでに入っているサイトからは消えません。

第三に、選定の基準がないと、担当者ごとに違うものを入れるから。
同じ機能に、サイトごとに別のプラグインが入っていると、脆弱性の情報が出るたびに、確認する相手が増えます。

今すぐ試せる：プラグインの一覧から棚卸しの候補を出すプロンプト

私はWeb制作会社で、お客様のWordPressサイトのプラグインを棚卸ししています。
次の一覧をもとに、見直しの候補を整理してください。

【プラグインの一覧】
・名前／有効か無効か／バージョン／最終更新日／何に使っているか
〔一覧を貼る〕

【サイトの情報】
・WordPressのバージョン：〔　〕
・EC、会員、フォームなど、個人情報を扱う機能：〔　〕

1. 「無効のまま入っている」「用途が不明」「最終更新が古い」を、それぞれ一覧にする。
2. 同じ機能を持つプラグインが重なっていないか確認する。
3. 「削除候補」「置き換え候補」「継続」に分け、理由を書く。

最終更新日だけで危険と断定しないこと。判断できないものは「要確認」とすること。

プラグイン管理工場：選定基準・棚卸し台帳・見直しの頻度

1. 入れる前の選定基準（社内ルール）

□ 本当にプラグインが必要か（テーマや本体の機能、数行のコードで足りないか）
□ 公式ディレクトリ、または開発元が明確な配布元から入手できるか
□ 最近も更新が続いているか（更新履歴を確認）
□ 現在のWordPressのバージョンで検証されているか
□ サポートの窓口があり、質問に回答されているか
□ 同じ機能で、自社がほかのサイトで使っているものがないか
□ 有料の場合、ライセンスの名義と更新の期限を誰が管理するか

最後の2つが、制作会社にとって大切です。使うプラグインを社内でそろえると、脆弱性の情報が出たときに、確認する相手が少なくなります。

2. 棚卸し台帳の項目

サイト名／プラグイン名／用途／有効・無効／バージョン
最終更新日（配布元）／自動更新の可否／改変の有無
ライセンスの名義と期限／導入した人と日付／次の見直し日

「用途」と「導入した人」が空欄のものは、削除の候補です。誰も説明できないプラグインは、誰も守れません。

3. 見直しの頻度と判断

・毎月：定期更新のときに、無効のまま入っているものを確認
・半年ごと：台帳を全件見直し、「削除・置き換え・継続」を判断
・脆弱性の情報が出たとき：台帳で、該当するサイトを数分で特定

【判断の目安】
無効のまま3か月以上 → 削除を提案
最新の主要リリースで未検証、更新も止まっている → 置き換えを提案
改変して使っている → 改変の内容を記録し、更新の方法を決める

4. お客様への説明の一文

サイトの安全を保つため、使われていないプラグインを整理し、
開発が続いていないものは、同じ機能の別の方法への置き換えをご提案します。
作業の範囲とお見積りは、別途お送りします。

置き換えは、制作の仕事です。保守の月額の中で無償でやらず、見積もりを出します。

▶ WordPress 脆弱性のたびに社長が夜中に更新している制作会社へ──更新の方針、検証、緊急時の判断基準、お客様との取り決めで「体制」にする

構造的なリスク

逆説を指摘しておきます。

プラグインを減らそうとして、機能を自作のコードで置き換えると、今度はそのコードを自社が守ることになります。
公式ディレクトリのプラグインには、少なくとも、開発者と、脆弱性を報告する窓口があります。自作のコードには、自社しかいません。

減らす目的は、数を減らすことではなく、「誰が守るのか」がわかる状態にすることです。

よくあるQ&A

Q. 最終更新日が古いプラグインは、すぐに消すべきか？

すぐに危険とは限りません。機能が小さく、変更の必要がないものもあります。脆弱性の情報が出ていないか確認し、置き換えの候補として台帳に記録してください。

Q. お客様が自分でプラグインを入れてしまう。

保守契約に「お客様が追加したプラグインの扱い」を書いておきます。追加する前に相談してもらうか、追加した分は棚卸しで報告し、対応は別料金とします。

Q. 棚卸しの作業は、どのくらいの時間がかかるのか？

自社の記録で測ってください。最初の1回は時間がかかりますが、台帳ができれば、2回目からは差分の確認で済みます。

最後に

プラグインの脆弱性は、更新の速さだけでは追いつきません。

入れる前に選び、入れたあとに棚卸しをして、守る対象を自分で決めた会社だけが、保守の手間を増やさずに、お客様のサイトを守り続けられるのです。

ECサイトの脆弱性と保守の取り決めは、こちらで扱っています。

▶ EC-CUBE 脆弱性の告知を「お客様が自分で見るもの」にしていないか──ECサイトの脆弱性対応と、構築した制作会社が結ぶべき保守の取り決め

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #WordPress #プラグイン #脆弱性 #セキュリティ #制作会社経営 #中小企業 #保守契約 #棚卸し #Web制作