プラグインとテーマ、追加した後まで管理できていますか

導入済みのプラグインやテーマについて、継続・更新・代替・撤去のどれを検討すべきか、その判断に必要な確認事項が分かります。

専門知識だけで安全性を見極めようとせず、「何のために使い、誰が保守し、問題があれば何に置き換えるか」を整理していきます。

A社は、追加機能の一覧を受け取っている

従業員20名のA社は、お知らせと問い合わせフォームのある企業サイトを運営しています。兼任の社内担当者がおり、制作会社と保守契約を結んでいます。

A社ができているのは、導入済みのプラグインとテーマの一覧を、保守先から受け取っていることです。

一方、一覧にある機能のうち、更新を自動で行うもの、事前確認をしてから行うもの、別のサービスに依存するものまでは整理していません。

制作会社に悪意や怠慢があるわけではありません。更新後の業務確認などについて、対応範囲の認識が十分に共有されていなかった、という設定です。

※A社は説明用の想定事例であり、実在の顧客・被害事例ではありません。事故や不具合についての記述も、もし起きた場合を考えるための想定です。

プラグインは機能を追加するもの、テーマは表示やデザインを担うものです。本体とは別の開発者が保守している場合があり、機能を足すほど、用途や更新状況を確認する対象も増えます。

ただし、個数だけで危険度を決めることはできません。どのような処理を行い、どこに確認が必要かを見ていきましょう。

入力処理は、フォームや設定画面などから受け取った情報を扱う処理です。内容を確かめずに保存したり表示したりすると、想定しないデータを処理してしまうおそれがあります。WordPressの開発資料では、入力の検証や、出力時に安全に扱うための処理を求めています。WordPress Developer Resources「Security」

ファイルアップロードは、画像や資料をサイトへ送る機能です。受け入れるファイルの確認が不十分だと、意図しない種類のファイルまで受け入れる問題につながります。公式の開発資料も、ファイルの確認を省く処理や、無制限のアップロードに注意を促しています。WordPress「Common issues」

認可は、「その人が、その操作をしてよいか」を確認することです。追加機能側で権限を確かめなければ、本来許されていない変更を受け付けるおそれがあります。WordPress「Checking User Capabilities」

ここで利用者がコードを読む必要はありません。自社で使う機能について問題が公表されたとき、保守先に影響と対応を確認できることが大切です。

脆弱性・攻撃・被害の区別は、第1回で説明しています。

第1回：WordPressは危険なのか？ 仕組みと責任分担から考える企業サイトの安全

一覧の「用途」を確認するときは、その機能がどんなデータや権限に触れるかも、保守先に説明してもらいましょう。

WordPressの公式資料では、プラグインやテーマを信頼できない入手元から取得せず、公式ディレクトリや信頼できる事業者を利用する考え方が示されています。Hardening「Security Themes」

公式ディレクトリは、WordPress.orgで提供される配布一覧です。プラグインの審査では、セキュリティ、互換性、ガイドラインへの適合などを確認すると説明されています。Plugin Developer FAQ「Submissions and Reviews」

ただし、この説明を「掲載されていれば、将来も含めて安全が保証される」と読むことはできません。掲載後も、更新や開発元の告知を確認する必要があります。

配布物の安全性と、利用条件を分けて考える

出所不明の配布物では、誰が何を変更したのか、更新をどこから受け取れるのかを確認しにくくなります。

一方、再配布や改変されたソフトウェアを、一律に「違法コピー」と呼ぶのは適切ではありません。WordPressのPlugin Developer FAQにも、GPLv2以降で許諾されたプラグインについて、著作権表示やクレジットを保つ条件で派生版を作れるという説明があります。これは、WordPress公式ディレクトリのプラグインの作者に向けた説明です。Plugin Developer FAQ「Someone posted a copy of my plugin! What do I do?」

個別の配布物を利用できるかは、そのライセンスと条件を確認してください。利用条件を満たすことと、安全性やサポートが確保されることは別の確認事項です。

独自機能は、引き継ぎ条件も確認する

制作会社が作った独自プラグインについては、次を確認することを提案します。

• ソース、つまりプログラムの元の記述を、どの条件で引き継げるか。
• 不具合や脆弱性が見つかったとき、誰が修正するか。
• 別の保守先による利用・改修が、ライセンスや契約で認められるか。

独自開発であること自体を問題にするのではなく、担当が変わっても保守を続けられるかを見るための質問です。外注終了時のアカウント停止は、第3回で扱います。

依存関係とは、その機能が別の仕組みに支えられている関係です。例えば、フォームの入力画面はプラグイン、送信は外部サービスという構成もあります。地図や予約機能が外部サービスに頼る場合もあります。

一覧には、機能名だけでなく「何とつながっているか」も記録しましょう。依存先の仕様変更や終了があれば、プラグインを更新するだけでは対応できない場合があるからです。

更新の情報源には、WordPress管理画面の通知や開発元の告知があります。管理画面で更新の案内が表示される仕組みは、公式資料でも説明されています。WordPress「Plugin and themes auto-updates」

脆弱性の情報を調べる場所としては、国内外で公開される脆弱性対策情報を扱うデータベース、JVN iPediaもあります。JVN iPedia

ただし、更新のお知らせと、脆弱性への緊急対応が必要という知らせは、同じではありません。更新内容を確認し、自社の使用版が対象かを調べる必要があります。

運用上は、通知を受け取る人と、対応を判断する人を分けて決めることを提案します。同じ人が兼ねても構いませんが、不在時の代わりも必要です。

A社なら、社内担当者が通知を受け、技術的な影響を保守先に確認し、業務を止める判断が必要なら経営側へつなぐ流れが考えられます。

通知先が個人メールだけだったり、退職者のままだったり、受信者が分からなかったりする場合は、引き継ぎ方法を見直しましょう。

個別の脆弱性に対応するときは、影響を受ける版、問題が起きる条件、修正版、公表日、調べた日を保守先に記録してもらうと、判断の理由を後から確認できます。データベースに見当たらないことだけで、安全だとは判断しません。

公式資料では、WordPress 5.5以降、プラグイン・テーマごとに自動更新を選べると説明されています。初期設定では1日2回の実行が予定され、成功・失敗についてサイト所有者にメール通知が送られます。

一方、ホスティング会社やプラグインによって機能が無効になっている場合があります。実行はWordPress Cronという定期処理の仕組みに依存し、問題の確認先としてSite Health、つまりサイトの状態を確認する画面が案内されています。WordPress「Plugin and themes auto-updates」

同資料の最終更新日は2023年1月13日です。ホスティング環境や設定により挙動が異なるため、利用中のサイトの設定と実行状況は保守先に確認してください。

「有効にした」と「確認できた」を分ける

自動更新を使う場合も、設定しただけで管理が終わるわけではありません。ここからは、運用上の確認方法の提案です。

まず、予定どおり実行されたか、使用版が変わったか、失敗通知を誰が確認するかを決めます。次に、問い合わせや予約など、業務で使う機能が動くかを確認します。

更新成功の通知と、問い合わせが届くことの確認は別です。 A社なら、表示の確認に加え、テスト用の情報でフォームを送信し、受信まで確かめる担当を決められます。

本番とは別の環境で、影響を確かめる

ステージングとは、本番とは別に用意する確認用環境です。重要な機能について更新を試し、問題がないか確かめてから本番へ反映する用途に使います。

「更新すると壊れるかもしれない」という不安は、確認する場所や作業時間、問題時の対応担当が決まっていないと、更新の先送りにつながりがちです。担当者を責めるより、試せる環境と判断手順を整えましょう。

確認用環境では、実際の個人情報や秘密情報を必要以上に複製せず、テストデータを使う方法を検討します。外部へのメール送信や予約登録も、本番へ影響させない設定を確認します。アクセス権と認証の管理は第3回で扱います。

すべての環境差や不具合を事前に再現できるわけではありません。本番への反映後も確認が必要です。

公式資料では、自動更新を有効にする前に、問題時に以前の状態へ戻せるようバックアップを備えることも案内されています。同資料「Perform regular automatic backups of your website」

通常の更新は確認を挟んで進め、緊急性が高い問題は対応を早めるなど、機能と状況に応じた運用を保守先と決めておきましょう。

公式ディレクトリでプラグインが閉鎖される理由として、FAQにはガイドライン違反、セキュリティ上の問題、作者の希望が挙げられています。Plugin Developer FAQ「Closed Plugins」

掲載停止だけで、脆弱性や不正があったと断定しないことが大切です。 開発終了、掲載停止、長期間更新がない状態も、同じ意味ではありません。

開発元や保守者が変わった場合も、変更の内容や、今後の更新・問い合わせ窓口を確認する機会になります。

ここからは、対応を検討する順番の提案です。

まず、公表されている理由と開発元の説明を確認します。次に、自社で使っている版への影響、修正版、保守継続の予定を保守先に調べてもらいます。理由が分からなければ、その点も「未確認」として残します。

長期間更新されていないことは、確認を始める目安です。それだけで危険とは断定しません。一方、直近に更新されたという理由だけで、自社環境での安全や動作が保証されるわけでもありません。

悪用が確認されている問題については、通常の更新日を待たず、一時停止・影響を抑える措置・緊急更新の要否を専門家と判断する運用を提案します。停止が業務に与える影響も、経営側と共有します。

更新後の不具合で旧版に戻す場合も、既知の弱点が残る版への巻き戻しを恒久対策にしないことが重要です。一時的な対応が必要なら、公開範囲や再対応の期限も含めて相談しましょう。

公式資料では、使っていないプラグインは削除するよう案内されています。Hardening「Plugins」

実作業では、使われていないかを利用部署に確認し、必要なデータや連携への影響を保守先に調べてもらってから進めます。「用途が分からない」と「不要」は同じではありません。

判断の材料は、用途と必要性、入手元と保守担当、使用版、依存関係、更新方式、動作確認、代替手段、撤去時の業務影響です。

使い続けるなら、誰がいつ確認するかを決めます。更新するなら、作業と確認を組み合わせます。代替するなら、データや連携の移行を考えます。撤去するなら、失われる機能と業務への影響を確認します。

分からない項目は、「未確認」と記録して構いません。 技術的な判定を社内担当者だけで抱え込む必要はありません。

役割は次の目安で示します。契約や社内体制に合わせて調整してください。

• 経：経営者が決める
• 担：社内担当者が行う
• 専：専門家に依頼する

「専」は、必要な知識を持つ社内技術者が担う場合も含みます。

この表は危険度を採点するものではありません。長期未更新などの目安は、確認を始めるきっかけとして使います。

A社なら、受け取っている一覧から、問い合わせに関わる機能を一つ選び、次のように確認できます。

この機能は、どこから更新情報を受け取り、誰が対応を判断していますか。更新後の確認範囲と、保守が終わった場合の選択肢も教えてください。

追加機能の管理は、導入時の選定だけでは終わりません。通知を受け、対応を判断し、更新後に確かめ、必要なら使い続けない判断をするところまで含みます。

まずは一覧の一つの機能について、用途・保守担当・通知先を確認してみてください。

第3回では、不正ログインやWordPressの外側の侵入経路、人と権限の管理を扱います。外注終了時のアカウント停止や、確認用環境へのアクセス管理も、そこで整理します。

関連記事

• 第1回：WordPressは危険なのか？ 仕組みと責任分担から考える企業サイトの安全
• 第3回：誰がどこまで操作できるか。アカウントと権限を見直す（2026-10-20公開予定）
• 第4回：異常に気づく・安全に戻す・再公開する。事故対応の備え（2026-10-21公開予定）
• 第5回：WordPressを続けるか、構成を変えるか。運用と総費用で選ぶ（2026-10-22公開予定）

出典と情報確認日

情報確認日：2026年10月10日。仕様や資料は変更される場合があります。個別サイトへの適用は、利用環境と契約内容を確認してください。

• WordPress：Plugin and themes auto-updates
• WordPress Developer Resources：Plugin Developer FAQ
• WordPress Developer Resources：Hardening WordPress
• WordPress Developer Resources：Security
• WordPress Developer Resources：Common issues
• WordPress Developer Resources：Checking User Capabilities
• JVN iPedia：JVN iPediaとは？

本記事は一般的な解説であり、特定のサイトやプラグインを診断した結果ではありません。