セキュリティ ソフトウェア 公開日 2026.04.21 更新日 2026.04.21

WordPress保守で最低限やるべきセキュリティ確認とは?更新・権限・バックアップの基本

WordPress保守で最低限やるべきセキュリティ確認を、更新、管理者権限、MFAバックアップ、プラグイン整理、WAF、ログ確認の観点から実務向けに整理します。

先に要点

  • WordPress 保守で最低限やるべきセキュリティ確認は、`更新` `管理者権限` `MFA` `バックアップ` `不要なプラグイン整理` `WAFやログ確認` の6〜7項目です。
  • 事故が起きやすいのは、古いプラグイン放置、管理者アカウントの増えすぎ、バックアップ未検証、停止しただけの不要テーマ放置、侵害後の初動未整理です。
  • 公開サイトでは、`改ざんされてから直す` より、月次や週次の確認項目を先に決めて保守契約に含める方が現実的です。

WordPress サイトの保守では、表示崩れや文言修正だけでなく、セキュリティ確認をどこまでやるかがかなり大事です。
ただ、実務では セキュリティも見ます とだけ書かれていて、実際に何を確認するのか曖昧なまま進みやすいです。

その状態だと、アップデートを止めたまま何カ月も過ぎたり、管理者アカウントが増えたままだったり、バックアップ はあるのに戻したことがなかったりします。
問い合わせフォームやログイン画面を持つ WordPress サイトでは、この手の放置がそのまま事故の入口になりやすいです。

この記事では、WordPress 保守で最低限やるべきセキュリティ確認を、制作会社、フリーランス、小規模運用の実務に寄せて整理します。
月額保守や契約の線引きから見たい場合は、保守契約書で最低限入れたい項目とは?対応時間・対象範囲・免責の決め方 もつながりやすいです。

この記事では、2026年4月22日時点で WordPress.org の Hardening WordPress / Upgrading WordPress / FAQ My site was hacked と、CISA の小規模組織向けサイバーセキュリティ資料を確認しながら整理しています。WordPress.org では古いバージョンを保守しないこと、信頼できる配布元を使うこと、二段階認証や SFTP、バックアップ、ログ確認が重要だと案内されています。ここでは法的助言ではなく、保守実務で事故を減らすための整理としてまとめます。

結論:まずは「更新・権限・バックアップ・入口防御」を固定で回す

WordPress 保守で最低限やるべきセキュリティ確認は、全部を高度にやることではありません。
まず次の項目を固定で回すことが大事です。

  1. 本体、プラグイン、テーマ、PHP の更新状況を確認する
  2. 管理者アカウントと MFA を見直す
  3. バックアップ取得と復元確認を行う
  4. 使っていないプラグインやテーマを整理する
  5. ログイン画面、問い合わせフォーム、管理画面の入口防御を確認する
  6. WAF、ログ、改ざん兆候の確認を続ける
  7. 侵害時の初動を決めておく

この順番にしておくと、毎月何を見るのか を説明しやすく、保守契約の範囲にも落とし込みやすいです。

WordPress保守で最低限やるべきセキュリティ確認一覧

最初に全体像を表で見ます。

確認項目 最低限やること 放置すると起きやすいこと
更新 本体、プラグイン、テーマ、PHP の更新可否を確認する 既知脆弱性を狙われやすくなる
管理者権限 不要アカウント削除、権限棚卸し、MFA 導入 乗っ取り時の被害が一気に広がる
バックアップ ファイルとDBの取得、世代管理、復元確認 侵害や更新失敗から戻せない
プラグイン・テーマ整理 不要なものを止めるだけでなく削除も検討する 古いコードや管理不能な部品が残る
入口防御 ログインURL周辺、問い合わせフォーム、管理画面の保護 総当たり、スパム、管理画面侵入の足場になる
監視 ログ、改ざん兆候、証明書期限、通知異常を確認する 侵害や不正送信に気づくのが遅れる

1. 本体・プラグイン・テーマ・PHP の更新を止めない

WordPress.org の Hardening WordPress でも、古い WordPress はセキュリティ更新の対象外であり、更新を続けることが重要だと案内されています。
特に WordPress 本体だけでなく、プラグインとテーマも保守対象に入れておかないと、入口が残ります。

実務で見ると、次のような放置が起きやすいです。

  • 本体は更新したが、プラグインが古い
  • プラグインは更新したが、テーマが何年も古い
  • サーバー側の PHP が古く、更新しづらい
  • 自動更新を切ったまま誰も見ていない

更新は 入れれば終わり ではありません。
小規模サイトでは、更新前バックアップ、更新後の表示確認、問い合わせフォーム送信確認、管理画面ログイン確認まで含めて保守項目にした方が安全です。

2. 管理者アカウントを増やしすぎない

侵害時に効いてくるのは、脆弱性だけではありません。
誰が管理者権限を持っているか、退職者や外部委託のアカウントが残っていないかもかなり重要です。

最低限、次を確認します。

  • 管理者アカウントが必要な人数に絞られているか
  • 共用アカウントを使っていないか
  • パスワードが使い回されていないか
  • 管理者に MFA を付けられるか
  • 復旧コードや引き継ぎ手順があるか

WordPress.org でも、強いパスワードに加えて二段階認証を使うことが勧められています。
まずは管理者だけでも MFA を前提にすると、総当たりや漏えいパスワード経由の事故をかなり減らしやすいです。

3. バックアップは「ある」ではなく「戻せる」を確認する

バックアップ があると言っても、実際には次のどれかで止まっていることがよくあります。

  • DB しか取っていない
  • ファイルしか取っていない
  • 同じサーバーの中だけに置いている
  • 何世代あるか分からない
  • 復元したことがない

WordPress.org でも、堅牢化の中でバックアップと復旧計画の重要性が強調されています。
更新失敗や侵害対応では、戻せるか がそのまま初動の速さになります。

実務では、少なくとも次を決めておくとかなり違います。

  • ファイルとDBの両方を取る
  • サーバー外にも保管する
  • 世代を残す
  • 月1回でもよいので復元確認をする
  • 復元に必要な手順を運用メモに残す

4. 使っていないプラグインやテーマを残しすぎない

WordPress の事故では、今まさに使っている部品だけが問題になるとは限りません。
止めただけで残っているプラグインや、テスト用に置いたままのテーマが保守漏れになることがあります。

ここで大事なのは、無効化したから安心 と考えないことです。
不要なものは、互換性確認やバックアップを取ったうえで、削除まで検討した方が管理しやすくなります。

また、導入元もかなり大事です。
WordPress.org の Hardening WordPress でも、プラグインやテーマは信頼できる配布元に絞るべきだと案内されています。
実務では、無料だから入れる より、更新頻度、開発継続性、レビュー状況、互換性情報を見た方が安全です。

5. ログイン画面・問い合わせフォーム・管理画面の入口を守る

WordPress サイトで攻撃を受けやすい入口はかなり偏っています。
特に見られやすいのは、ログイン画面、管理画面、問い合わせフォーム、XML-RPC まわりです。

最低限の入口防御としては、次のような考え方が現実的です。

  • ログイン試行回数制限や不正アクセス制御を入れる
  • 不要な管理者入口を減らす
  • 問い合わせフォームのスパム対策を入れる
  • ホスティングやCDNWAF が使えるなら検討する
  • 管理画面へのアクセス元制限を検討する

ただし、WAF を入れれば終わりではありません。
WAF は前段で怪しいアクセスを減らすのに有効ですが、更新停止や権限管理の甘さを置き換えるものではありません。

問い合わせフォームの入口対策を深く見たい場合は、問い合わせフォームのスパム対策|reCAPTCHAだけに頼らない実務対応 もつながります。

6. ログと改ざん兆候を定期的に見る

侵害は、サイトが真っ白になる形だけでは起きません。
実務では、次のような異変で気づくことが多いです。

  • 問い合わせ通知だけ急に届かない
  • 不審な管理者アカウントが増えている
  • 外部への不審なメール送信が発生している
  • 検索結果に意図しないページが出る
  • ホスティング会社から改ざん通知が来る
  • ファイル変更日時がおかしい

CISA でも、小規模組織向けの基本対策としてログ取得と定期監視、バックアップを強く勧めています。
WordPress 保守でも、ログを全件細かく読むより、高リスクな異常を見つける ことから始める方が現実的です。

たとえば次は保守項目に入れやすいです。

  • 管理者ログイン失敗の急増
  • 管理者追加や権限変更
  • フォーム送信失敗や通知エラー
  • 改ざん検知やマルウェア検知の通知
  • SSL 証明書期限切れの予兆

小規模サイトの監視全体を整理したい場合は、小規模サイトの監視は何から始める?死活監視・SSL・バックアップ確認の基本 もあわせて読むと流れがつかみやすいです。

7. 侵害されたときの初動を決めておく

WordPress.org の FAQ My site was hacked では、侵害を疑ったときに、アクセス制御の見直し、全パスワード変更、バックアップ取得、更新、ローカル環境のスキャン、ホスティング会社への確認などが案内されています。
この内容は、保守運用でそのまま初動チェックリストにしやすいです。

少なくとも、次は決めておくと止まりにくくなります。

  1. 連絡先は誰か
  2. サイトを一時停止する判断者は誰か
  3. パスワード変更と管理者棚卸しを誰がやるか
  4. バックアップから戻す条件は何か
  5. ホスティング会社や外部ベンダーへ誰が連絡するか
  6. 原因調査と再発防止をどこまで別見積にするか

ここを決めないまま事故が起きると、復旧より先に 誰が判断するのか で止まりやすいです。

保守契約に入れやすい項目と別見積にしやすい項目

WordPress 保守で揉めやすいのは、セキュリティ確認の中に 定期確認障害対応改修 が混ざることです。
契約では次のように分けると説明しやすいです。

項目 月額保守に入れやすい 別見積にしやすい
更新 軽微更新、更新可否確認、更新後の基本確認 大規模互換性検証、テーマ改修を伴う更新
権限管理 不要アカウント確認、MFA運用確認 認証方式の刷新、SSO連携
バックアップ 取得確認、世代確認、軽い復元演習 侵害後の本格復旧、データ修復
入口防御 WAFルール確認、ログイン保護の見直し 全面的なセキュリティ再設計
事故対応 一次切り分け、初動連絡 マルウェア駆除、原因調査、再発防止の実装

まず最初の1カ月でやるとよい確認順

初回保守でいきなり全部を細かく見るのは重いです。
まずは次の順で着手すると進めやすいです。

  1. 本体、プラグイン、テーマ、PHP の更新状況を棚卸しする
  2. 管理者アカウントと MFA の状況を確認する
  3. バックアップ の取得先と復元可否を確認する
  4. 不要プラグイン、不要テーマを洗い出す
  5. 問い合わせフォーム、ログイン画面、管理画面の入口防御を確認する
  6. ログ、通知、SSL 期限、改ざん兆候の見方を決める
  7. 侵害時の初動連絡先と判断者を決める

この7つが回るだけでも、ただ更新通知を眺めているだけの保守 からかなり前進します。

まとめ

WordPress 保守で最低限やるべきセキュリティ確認は、派手な対策を大量に入れることではありません。
更新、権限、MFAバックアップ、不要プラグイン整理、入口防御、ログ確認を固定の確認項目として回し、事故時の初動まで決めておくことが大事です。

特に小規模サイトでは、WAFを入れたから安心 バックアップがあるから大丈夫 止めたプラグインは無害 といった思い込みが残りやすいです。
実務では、戻せるか、入れるか、気づけるか、止められるかまで含めて保守項目にすると、かなり事故を減らしやすくなります。


参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。