先に要点
WordPress サイトの保守では、表示崩れや文言修正だけでなく、セキュリティ確認をどこまでやるかがかなり大事です。
ただ、実務では セキュリティも見ます とだけ書かれていて、実際に何を確認するのか曖昧なまま進みやすいです。
その状態だと、アップデートを止めたまま何カ月も過ぎたり、管理者アカウントが増えたままだったり、バックアップ はあるのに戻したことがなかったりします。
問い合わせフォームやログイン画面を持つ WordPress サイトでは、この手の放置がそのまま事故の入口になりやすいです。
更新
プラグイン更新を止めてよいか
プラグイン更新を止めてよいケースがあるのか、互換性確認をどう進めるかを先に整理したい場合は、WordPressでプラグイン更新を止めていいケースはある？互換性確認の進め方を整理 もあわせて読むとつながりやすいです。
侵害後
改ざんされたときの初動
実際に改ざんや侵害が起きたあと、何から手を付けるかを順番で整理したい場合は、WordPressサイトが改ざんされたときの初動｜停止・復旧・再発防止の順番 もあわせて読むとつながりやすいです。
サーバー
PHP の更新判断
サーバー側の PHP 更新をどこで判断するかまで見たい場合は、PHPのバージョン更新はなぜ必要？古いまま放置しない判断基準と確認手順 もつながりやすいです。
この記事では、WordPress 保守で最低限やるべきセキュリティ確認を、制作会社、フリーランス、小規模運用の実務に寄せて整理します。
月額保守や契約の線引きから見たい場合は、保守契約書で最低限入れたい項目とは？対応時間・対象範囲・免責の決め方 もつながりやすいです。
この記事では、2026年4月22日時点で WordPress.org の Hardening WordPress / Upgrading WordPress / FAQ My site was hacked と、CISA の小規模組織向けサイバーセキュリティ資料を確認しながら整理しています。WordPress.org では古いバージョンを保守しないこと、信頼できる配布元を使うこと、二段階認証や SFTP、バックアップ、ログ確認が重要だと案内されています。ここでは法的助言ではなく、保守実務で事故を減らすための整理としてまとめます。
結論：まずは「更新・権限・バックアップ・入口防御」を固定で回す
WordPress 保守で最低限やるべきセキュリティ確認は、全部を高度にやることではありません。
まず次の項目を固定で回すことが大事です。
- 本体、プラグイン、テーマ、PHP の更新状況を確認する
- 管理者アカウントと MFA を見直す
- バックアップ取得と復元確認を行う
- 使っていないプラグインやテーマを整理する
- ログイン画面、問い合わせフォーム、管理画面の入口防御を確認する
- WAF、ログ、改ざん兆候の確認を続ける
- 侵害時の初動を決めておく
この順番にしておくと、毎月何を見るのか を説明しやすく、保守契約の範囲にも落とし込みやすいです。
WordPress保守で最低限やるべきセキュリティ確認一覧
最初に全体像を表で見ます。
| 確認項目 | 最低限やること | 放置すると起きやすいこと |
|---|---|---|
| 更新 | 本体、プラグイン、テーマ、PHP の更新可否を確認する | 既知脆弱性を狙われやすくなる |
| 管理者権限 | 不要アカウント削除、権限棚卸し、MFA 導入 | 乗っ取り時の被害が一気に広がる |
| バックアップ | ファイルとDBの取得、世代管理、復元確認 | 侵害や更新失敗から戻せない |
| プラグイン・テーマ整理 | 不要なものを止めるだけでなく削除も検討する | 古いコードや管理不能な部品が残る |
| 入口防御 | ログインURL周辺、問い合わせフォーム、管理画面の保護 | 総当たり、スパム、管理画面侵入の足場になる |
| 監視 | ログ、改ざん兆候、証明書期限、通知異常を確認する | 侵害や不正送信に気づくのが遅れる |
1. 本体・プラグイン・テーマ・PHP の更新を止めない
WordPress.org の Hardening WordPress でも、古い WordPress はセキュリティ更新の対象外であり、更新を続けることが重要だと案内されています。
特に WordPress 本体だけでなく、プラグインとテーマも保守対象に入れておかないと、入口が残ります。
実務で見ると、次のような放置が起きやすいです。
プラグイン
本体だけ新しい
本体は更新したが、プラグインが古い。
テーマ
テーマが何年も古い
プラグインは更新したが、テーマが何年も古い。
サーバー
PHP が古い
運用
誰も見ていない
自動更新を切ったまま誰も見ていない。
小規模サイトでは、更新前バックアップ、更新後の表示確認、問い合わせフォーム送信確認、管理画面ログイン確認まで含めて保守項目にした方が安全です。
2. 管理者アカウントを増やしすぎない
侵害時に効いてくるのは、脆弱性だけではありません。
誰が管理者権限を持っているか、退職者や外部委託のアカウントが残っていないかもかなり重要です。
最低限、次を確認します。
WordPress.org でも、強いパスワードに加えて二段階認証を使うことが勧められています。まずは管理者だけでも MFA を前提にすると、総当たりや漏えいパスワード経由の事故をかなり減らしやすいです。
3. バックアップは「ある」ではなく「戻せる」を確認する
バックアップ があると言っても、実際には次のどれかで止まっていることがよくあります。
WordPress.org でも、堅牢化の中でバックアップと復旧計画の重要性が強調されています。
更新失敗や侵害対応では、戻せるか がそのまま初動の速さになります。
実務では、上の右側の項目を少なくとも決めておくとかなり違います。
4. 使っていないプラグインやテーマを残しすぎない
WordPress の事故では、今まさに使っている部品だけが問題になるとは限りません。
止めただけで残っているプラグインや、テスト用に置いたままのテーマが保守漏れになることがあります。
不要なものは、互換性確認やバックアップを取ったうえで、削除まで検討した方が管理しやすくなります。
WordPress.org の Hardening WordPress でも、プラグインやテーマは信頼できる配布元に絞るべきだと案内されています。実務では、「無料だから入れる」より、更新頻度、開発継続性、レビュー状況、互換性情報を見た方が安全です。
5. ログイン画面・問い合わせフォーム・管理画面の入口を守る
WordPress サイトで攻撃を受けやすい入口はかなり偏っています。
特に見られやすいのは、ログイン画面、管理画面、問い合わせフォーム、XML-RPC まわりです。
最低限の入口防御としては、次のような考え方が現実的です。
- ログイン試行回数制限や不正アクセス制御を入れる
- 不要な管理者入口を減らす
- 問い合わせフォームのスパム対策を入れる
- ホスティングやCDNの WAF が使えるなら検討する
- 管理画面へのアクセス元制限を検討する
問い合わせフォームの入口対策を深く見たい場合は、問い合わせフォームのスパム対策｜reCAPTCHAだけに頼らない実務対応 もつながります。
6. ログと改ざん兆候を定期的に見る
侵害は、サイトが真っ白になる形だけでは起きません。
実務では、次のような異変で気づくことが多いです。
- 問い合わせ通知だけ急に届かない
- 不審な管理者アカウントが増えている
- 外部への不審なメール送信が発生している
- 検索結果に意図しないページが出る
- ホスティング会社から改ざん通知が来る
- ファイル変更日時がおかしい
CISA でも、小規模組織向けの基本対策としてログ取得と定期監視、バックアップを強く勧めています。
WordPress 保守でも、ログを全件細かく読むより、高リスクな異常を見つける ことから始める方が現実的です。
ログイン
失敗の急増
管理者ログイン失敗の急増。
権限
管理者追加や権限変更
管理者追加や権限変更。
フォーム
送信失敗や通知エラー
フォーム送信失敗や通知エラー。
検知
改ざん・マルウェアの通知
改ざん検知やマルウェア検知の通知。
証明書
期限切れの予兆
SSL 証明書期限切れの予兆。
上のカードは、保守項目に入れやすい監視の例です。小規模サイトの監視全体を整理したい場合は、小規模サイトの監視は何から始める？死活監視・SSL・バックアップ確認の基本 もあわせて読むと流れがつかみやすいです。
7. 侵害されたときの初動を決めておく
WordPress.org の FAQ My site was hacked では、侵害を疑ったときに、アクセス制御の見直し、全パスワード変更、バックアップ取得、更新、ローカル環境のスキャン、ホスティング会社への確認などが案内されています。
この内容は、保守運用でそのまま初動チェックリストにしやすいです。
少なくとも、次は決めておくと止まりにくくなります。
ここを決めないまま事故が起きると、復旧より先に「誰が判断するのか」で止まりやすいです。
保守契約に入れやすい項目と別見積にしやすい項目
WordPress 保守で揉めやすいのは、セキュリティ確認の中に 定期確認 と 障害対応 と 改修 が混ざることです。
契約では次のように分けると説明しやすいです。
| 項目 | 月額保守に入れやすい | 別見積にしやすい |
|---|---|---|
| 更新 | 軽微更新、更新可否確認、更新後の基本確認 | 大規模互換性検証、テーマ改修を伴う更新 |
| 権限管理 | 不要アカウント確認、MFA運用確認 | 認証方式の刷新、SSO連携 |
| バックアップ | 取得確認、世代確認、軽い復元演習 | 侵害後の本格復旧、データ修復 |
| 入口防御 | WAFルール確認、ログイン保護の見直し | 全面的なセキュリティ再設計 |
| 事故対応 | 一次切り分け、初動連絡 | マルウェア駆除、原因調査、再発防止の実装 |
まず最初の1カ月でやるとよい確認順
初回保守でいきなり全部を細かく見るのは重いです。
まずは次の順で着手すると進めやすいです。
この7つが回るだけでも、ただ更新通知を眺めているだけの保守 からかなり前進します。
WordPress保守セキュリティのよくある質問
Q. 自動更新はオンにすべきですか？
A. セキュリティパッチは即時自動、メジャーバージョンは手動が推奨です。プラグイン全自動は競合事故のリスクがあるので、重要なものは手動 + 検証環境テスト が安全です。
Q. 不要なプラグインを削除する判断基準は？
A. 最終更新が2年以上前、サポート切れ、脆弱性報告がある、使っていない、のどれかに該当すれば削除候補です。プラグインは数を減らすほどリスクが減ります。
Q. WAF やセキュリティプラグインは必須ですか？
A. 公開サイトなら強く推奨です。Cloudflare WAF(無料)+ Wordfence や SiteGround Security 程度で、攻撃の大半は防げます。管理画面 URL の隠蔽 も基本対策です。
Q. 管理者アカウントは1つで運用すべきですか？
A. 必要最小限が原則です。各人の個別アカウント、MFA 必須、退職者の即削除、デフォルト admin ユーザー名の変更、で侵入の起点を減らします。
Q. バックアップはどこに保存すべきですか？
A. 同サーバー内だけはNG。別のクラウドストレージ 別アカウント Object Lock 対応 のいずれかを併用し、3-2-1ルール(3コピー、2メディア、1オフサイト)に従います。
Q. 改ざんに気づく方法は？
A. Wordfence Live Traffic、ファイル整合性チェック、Cloudflare の Hotlink 検知、Google Search Console のセキュリティ問題通知、外形監視サービスのコンテンツ変更検知、などが組み合わせ可能です。
Q. 侵害された場合の初動は？
A. 感染ファイル特定、サーバー隔離(メンテモード)、バックアップから復旧、原因脆弱性の修正、パスワード全変更、Search Console 報告、再審査リクエスト、の流れです。まず復旧、後で原因究明 の順で動きます。
まとめ
WordPress 保守で最低限やるべきセキュリティ確認は、派手な対策を大量に入れることではありません。
更新、権限、MFA、バックアップ、不要プラグイン整理、入口防御、ログ確認を固定の確認項目として回し、事故時の初動まで決めておくことが大事です。
特に小規模サイトでは、WAFを入れたから安心 バックアップがあるから大丈夫 止めたプラグインは無害 といった思い込みが残りやすいです。
実務では、戻せるか、入れるか、気づけるか、止められるかまで含めて保守項目にすると、かなり事故を減らしやすくなります。
参考リンク
- WordPress.org Developer Resources: Hardening WordPress
- WordPress.org Developer Resources: Upgrading WordPress
- WordPress.org Documentation: FAQ My site was hacked
- CISA: Level Up Your Defenses—Four Cybersecurity Best Practices for Businesses
- CISA: Back Up Business Data