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

この記事は、WordPress 脆弱性の情報が出るたびに慌てるのをやめ、更新と判断を「体制」にする方法を扱います。

WordPressの脆弱性が出るたび、誰が何をするか決まっていない

「このプラグイン、脆弱性が出たらしいです。うちのお客様、何社使ってましたっけ」

夜にこの連絡が来て、社長が台帳を探し、1サイトずつ管理画面に入って更新する。
翌朝、更新したサイトの表示が崩れていて、お客様から電話が来る。

この流れを、毎回くり返していないでしょうか。
問題は、脆弱性そのものではありません。情報が来たときの動き方が、人の記憶と善意に頼っていることです。

WordPressの脆弱性対応の体制とは、情報を受け取り、危険度を判断し、検証して更新し、記録して報告する流れを、人と契約に落とした仕組みである

黒字化の外科医です。WordPressの脆弱性対応を、慌てない「体制」に変える手順を解剖します。

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

体制が必要な理由は、三つあります。

第一に、自動で守られる部分と、誰かが決めないと動かない部分があるから。
WordPress.orgの公式文書によると、本体のマイナーリリース（保守とセキュリティの更新）と翻訳は、既定で自動更新されます。一方、プラグインとテーマの自動更新は、バージョン5.5から管理者が1つずつ有効にする仕組みで、既定では動きません。

第二に、判断の基準がないと、全部を緊急にするか、全部を後回しにするかになるから。
全部を緊急にすれば、社員の時間が保守に溶けます。全部を後回しにすれば、本当に急ぐべき1件を見落とします。

第三に、お客様との取り決めがないと、更新で崩れたときに揉めるから。
「更新したら表示が崩れた。直す費用はそちら持ちで」。この一言を防ぐのは、技術ではなく契約です。

今すぐ試せる：脆弱性情報の緊急度を仕分けるプロンプト

私はWeb制作会社で、お客様のWordPressサイトの保守を担当しています。
次の脆弱性情報について、自社の対応の緊急度を仕分けてください。

【脆弱性情報】
・対象（本体／プラグイン／テーマ）と名前：〔　〕
・影響を受けるバージョンと、修正版のバージョン：〔　〕
・情報の出どころ（JVN、開発者の告知など）：〔　〕
・悪用が確認されているか：〔はい／いいえ／不明〕

【自社の状況】
・該当しそうなサイトの数：〔　〕
・そのうちECや会員機能など、個人情報を扱うサイトの数：〔　〕

1. 緊急度を「即日／3営業日以内／定期更新で対応」のどれかに分け、理由を書く。
2. 更新前に確認すべきこと（バックアップ、検証環境、影響する機能）を挙げる。
3. お客様への連絡が必要かどうかと、その理由を書く。

断定できないことは「要確認」と書き、推測で埋めないこと。
攻撃の手順は書かないこと。

AIの出力は下書きです。最終の判断は、人が一次情報を読んで行います。

脆弱性対応工場：更新方針・判断基準・検証・取り決めの4点セット

1. 更新方針の3区分

【区分A】自動更新に任せるもの
・本体のマイナーリリース（既定で自動）
・検証済みで、更新による表示崩れの実績がないプラグイン

【区分B】検証してから手動で更新するもの
・本体のメジャーリリース
・EC、会員、フォーム、決済に関わるプラグイン
・テーマ（子テーマで改変しているもの）

【区分C】更新を止めて、別の対応を考えるもの
・開発が止まっているプラグイン
・改変して使っているため、更新すると改変が消えるもの

区分Cがあるサイトは、更新では守れません。置き換えの提案につなげます。

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

2. 緊急時の判断基準

□ 自社の管理サイトに、該当するバージョンが入っているか
□ 悪用が確認されている、と一次情報に書かれているか
□ ログインしていない人でも影響を受ける種類か
□ 個人情報や決済を扱うサイトか
□ 修正版が出ているか（出ていなければ、停止や回避策を検討）

2つ以上に当てはまる → 即日
1つ → 3営業日以内
該当なし → 次の定期更新

3. 検証の手順

① 更新前に、ファイルとデータベースのバックアップを取る
② バックアップが使える状態か、確かめる
③ 検証環境で更新し、主要ページ・フォーム・決済を確認する
④ 本番で更新し、同じ項目を確認する
⑤ 作業日、更新前後のバージョン、確認結果を記録する

WordPress.orgの公式文書も、更新の前にバックアップを取り、それが使えるか確かめることを求めています。

4. お客様との取り決め（保守契約に入れる項目）

・更新の頻度（例：月1回の定期更新）
・緊急更新の扱い（判断基準と、月額に含む回数）
・更新で不具合が出たときの対応範囲と費用
・自動更新を有効にするプラグインの範囲
・お客様が自分でプラグインを入れた場合の扱い
・報告の方法（月次の作業記録）

計算例：緊急対応を月額に含めると、いくらかかるか

例：保守サイト30件、うち1件の脆弱性で該当が20サイト
1サイトの確認と更新：0.5時間
20サイト × 0.5時間 ＝ 10時間
時間単価7,645円（時間単価の記事の例）× 10時間 ＝ 76,450円

（例の数字です）

年に数回あれば、1人の数日分です。月額に含めるなら回数の上限を、含めないなら料金を、契約に書いておきます。

▶ 制作会社の「時間単価」は、年収から逆算する──人件費の係数、稼働率、目標の利益で決める、見積もりの土台になる1時間の値段

構造的なリスク

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

体制を作ると、「すべての脆弱性に即日で対応します」と約束したくなります。
けれど、その約束は守れません。修正版が出ていない脆弱性もあれば、更新するとサイトが動かなくなる場合もあるからです。

約束すべきは「即日で直す」ことではなく、「基準に沿って判断し、何をしたかを報告する」ことです。

IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」も、ソフトウェアの脆弱性対策を定期的にしているか、クラウドなどのサービスで自組織の責任範囲を把握しているか、を確認項目に挙げています。範囲を決めることが、守ることの前提です。

よくあるQ&A

Q. プラグインの自動更新は、全部有効にしたほうがいいのか？

おすすめしません。表示崩れの実績がないものから順に区分Aに入れてください。ECや決済に関わるものは、検証してから更新する区分Bに残します。

Q. 脆弱性の情報は、どこで集めればいいのか？

日本語なら、JPCERT/CCとIPAが共同で運営するJVNが一次情報の入口になります。あわせて、使っているプラグインの開発者の告知を確認します。集め方と通知の流れは、別の記事で扱います。

▶ 脆弱性情報の収集、制作会社は「見る場所」と「伝える順番」を先に決める──JVN・JPCERT/CC・IPA・CMS公式の使い分けと通知の文例

Q. 保守契約がないお客様から、脆弱性の対応を頼まれたら？

スポットの作業として見積もり、その場で保守契約を提案してください。無償で一度やると、次回も無償が前提になります。

最後に

WordPressの脆弱性は、なくなりません。なくせるのは、情報が来るたびに慌てる動き方です。

更新の方針と判断の基準を決め、お客様との取り決めに書いた会社だけが、脆弱性の対応を、社長の夜の仕事から、契約された商品に変えられるのです。

改ざんされてしまったときの初動は、こちらにまとめました。

▶ WordPress 改ざんに気づいた日、制作会社が最初の24時間でやること──隔離・保全・連絡・復旧・再発防止を、慌てて消さない順番で

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

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