「ホームページは普通に表示されているから大丈夫」
「制作会社に毎月お金を払っているので、管理してくれているはず」
そう思って、WordPressの更新状況を確認しないままになっていませんか？
サイトの見た目が変わっていなくても、WordPress本体、プラグイン、テーマ、そして動作の土台となるPHPには、更新や点検が必要です。
当方が管理に関わるサイトでも、セキュリティプラグインからSQLインジェクションやクロスサイトスクリプティングの遮断通知が届きます。普段の画面からは見えなくても、不審な通信が発生していることがあります。
専門的な作業をプロに任せることは大切です。しかし、「詳しくないので任せている」と「何を管理してもらっているか分からない」は、同じではありません。
この記事では、更新を放置するリスクと、安全に更新するための手順、保守を依頼している場合の確認ポイントを紹介します。
サイバー攻撃は、実際にどれくらい増えている？
企業の情報漏えいやサービス停止のニュースを見ると、攻撃が急増しているように感じることがあります。
ただし、攻撃の試行、セキュリティ製品の検知、実際に被害が発生した事件は、分けて考える必要があります。
NICTの「NICTER観測レポート2025」では、1つのIPアドレスあたりの年間総観測パケット数が約250万となり、観測開始以来最多になりました。前年からの増加は約7万7千パケット、約3.2％です。
一方、観測パケットの約55.0％は調査目的と推測されるスキャンでした。この数値は、日本企業の被害件数や、WordPressに対するSQLインジェクション・XSSの件数を表すものではありません。
自分のサイトへの通知が増えた場合は、ログで比較する
「最近、通知が多い」という実感は、確認を始めるきっかけになります。ただし、通知数だけで世の中全体の攻撃の増減までは判断できません。
同じ攻撃の繰り返し、検知ルールの更新、通知設定の変更などによって、件数が変わる場合もあります。
増減を確認する場合は、同じサイト・同じ設定で、月ごとの件数や検知内容、アクセス先を比較しましょう。
「攻撃をブロックしました」という通知は何を意味する？
遮断通知は、セキュリティ機能が特定の通信を不審と判断し、処理を止めたことを知らせるものです。
通知が届いたからといって、情報漏えいが起きたと決まるわけではありません。反対に、遮断できたからサイト全体が安全だと保証されるわけでもありません。
そのサイトには存在しない弱点を機械的に狙う通信が届くこともあります。また、正常な操作を誤って検知する場合もあります。
SQLインジェクションとは
SQLインジェクションは、入力処理などの弱点を利用し、データベースへの命令を不正に操作する攻撃です。
成立すると、脆弱性や権限の条件によって、保存情報の読み取り、改ざん、削除などにつながる可能性があります。
対策の基本は、問題のある処理を修正することです。プラグインに修正版が出ている場合は、その適用が重要になります。
クロスサイトスクリプティングとは
クロスサイトスクリプティング（XSS）は、Webページの表示処理などの弱点を利用して、そのページを開いた人のブラウザで不正なスクリプトを実行させる攻撃です。
表示内容の変更や情報の取得、ログイン中の利用者の権限を悪用した操作などにつながる可能性があります。
一般の閲覧者だけでなく、管理画面を開く運営者が影響を受ける場合もあります。
ブロック機能とソフトウェアの更新は役割が違う
WAFは、不審なWeb通信を検知・遮断する仕組みです。一方、ソフトウェアの更新には、既知の弱点や不具合を修正する役割があります。
入口で通信を止める対策と、サイト側の弱点を直す対策は、組み合わせて使います。
セキュリティプラグインを入れていても、WordPressやプラグインの更新を省略してよいわけではありません。防御用のプラグイン自体も、更新と設定の確認が必要です。
WordPressの更新を放置すると起こり得ること
修正済みの弱点がサイトに残り続ける
セキュリティ上の弱点を「脆弱性」といいます。
修正版が公開されても、対象の古いバージョンを使い続けていれば、その修正はサイトに反映されません。
修正の公開をきっかけに弱点の詳細が知られ、更新していないサイトが狙われることもあります。管理画面へのログインを必要とせず、外部から悪用できる問題もあります。
参考：WordPress公式「Hardening WordPress」
情報漏えい以外の被害もある
被害は個人情報の流出だけではありません。
- ページやリンクを書き換えられる
- 別のサイトへ勝手に転送される
- 不審なファイルを置かれる
- 迷惑メール送信などに悪用される
- お問い合わせや予約、購入ができなくなる
「会員情報を保存していないサイトだから関係ない」とは言い切れません。
ただし、更新が古いだけで必ず侵入されるという意味ではありません。実際の危険性は、残っている脆弱性、設定、公開している機能などによって変わります。
後から更新するほど調整が大きくなることがある
長期間更新を止めると、現在の環境との差が広がります。
古いテーマや独自コードが新しいPHPに対応していなかったり、プラグインで使っていた機能が変更されていたりすると、更新に伴う修正や検証が必要になります。
更新作業を先送りしても、将来の対応が不要になるわけではありません。むしろ、調査・修正・復旧に必要な時間や費用が増える場合があります。
更新が必要なのはWordPress本体だけではない
| 対象 | 確認したいこと |
|---|---|
| WordPress本体 | 更新通知、セキュリティ修正、現在の構成との互換性 |
| プラグイン | 修正版の有無、対応環境、開発・保守が続いているか |
| テーマ | 更新状況、独自修正への影響、PHPへの対応 |
| 独自コード・スニペット | 廃止された機能や古い書き方を使っていないか |
| PHP | 使用バージョン、サポート期限、変更後の動作 |
| サーバー環境 | サーバー会社と保守担当者の管理範囲 |
使っていないプラグインも整理する
不要なプラグインやテーマは、依存関係や保存データを確認してから削除します。
停止しているだけでは、すべてのファイルが消えるわけではありません。残っているファイルへのアクセス経路によっては、問題が残る場合があります。
一方、必要なものを確認せず削除すると、フォームや表示機能が動かなくなることがあります。用途が分からないものは、制作担当者に確認しましょう。
独自コードにも保守が必要
管理画面に更新通知が出る部分だけが、保守の対象ではありません。
テーマに直接追加した処理や、コードスニペットとして登録した処理も、新しいWordPress・プラグイン・PHPで動作するか確認が必要です。
以前は問題なく使えていた書き方が、現在のバージョンではエラーになることもあります。
関連：Contact Form 7の更新とカスタムコードの確認
PHPは「動いている」だけでは判断できない
PHPは、WordPressがサーバー上で動くためのプログラミング言語です。
WordPress本体を更新していても、サーバーで使うPHPが古いままになっている場合があります。
PHPには公式のサポート期限があります。期限を過ぎた系列では、PHP公式による修正提供が終了します。
2026年10月20日時点では、PHP 8.2のセキュリティサポート期限は2026年12月31日です。現在動いているからと安心せず、期限に余裕を持って移行を検討する必要があります。
ただし、単純に最も新しいPHPへ切り替えればよいわけでもありません。WordPress本体、テーマ、プラグイン、独自コードが対応しているか確認します。
サーバー会社独自の延長サポートがある場合は、その対象と範囲も確認しましょう。
「更新すると壊れるから、そのまま」は解決にならない
更新によって表示が崩れたり、フォームが動かなくなったりする可能性はあります。
だからこそ必要なのが、事前確認と復旧準備です。
「更新しない」という判断を続ける場合も、理由、残るリスク、暫定対策、いつまでに解消するかを明確にしておく必要があります。
1．現在の構成と更新内容を確認する
WordPress、プラグイン、テーマ、PHPのバージョンを確認し、独自修正や外部連携も洗い出します。
特に、予約・購入・決済・会員登録など、止まると業務に影響する機能を整理しておきましょう。
2．ファイルとデータベースをバックアップする
記事や設定が入るデータベースと、テーマ・プラグイン・画像などのファイルを保存します。
バックアップは「取得できた」だけでなく、保存先、保存日時、復元方法まで確認します。サイトが壊れたときに同時に失われない保存先も必要です。
3．テスト環境で確認する
可能であれば、本番とは分けた環境で更新を試します。
テスト環境から実際のお客様にメールが送信されたり、本番の決済が行われたりしないよう、外部連携にも注意します。
長期間更新していない場合は、一度にすべてを変更せず、互換性を確認しながら段階的に進める必要があります。
4．復旧できる体制で本番を更新する
作業時間、担当者、失敗した場合の戻し方を決めてから実施します。
更新順序は、使用中の構成や対応バージョンによって変わります。すべてのサイトに共通する順番を決めつけず、必要な条件を確認します。
5．表示だけでなく、実際の操作まで確認する
トップページが開けるだけでは、確認は終わりません。
お問い合わせフォームの送信と受信、予約の完了、ログイン、検索、スマートフォン表示など、サイトで必要な操作を確認します。
自動更新を使う場合も、失敗通知や更新後の動作を確認する体制が必要です。
保守会社に任せていても、確認しておきたいこと
「保守」「管理」「メンテナンス」という言葉だけでは、実際に行われる作業は分かりません。
サーバーの契約管理だけなのか、WordPressの更新も含むのか。障害時の復旧や、古い独自コードの修正まで対応するのか。契約によって範囲は異なります。
月額料金に含まれる作業を確認する
最低限、次の内容を確認しておきましょう。
- WordPress本体・プラグイン・テーマの更新
- PHPの確認と変更作業
- バックアップの取得と復元
- 攻撃・障害通知の確認
- 更新後の動作確認
- 不具合が発生した際の調査と修正
- 緊急時の連絡先と対応時間
含まれない作業があること自体は、問題ではありません。含まれていない作業を、誰が担当するのか決まっていないことが問題です。
作業報告には「何をしたか」と「何が残っているか」が必要
「異常ありません」という連絡だけでは、更新状況までは分かりません。
更新した対象と日時、動作確認の結果、更新できなかったもの、その理由と今後の予定が分かる報告を依頼しましょう。
セキュリティ修正の緊急性が高い場合に、通常の点検日を待たず対応するかどうかも確認しておくと安心です。
専門知識がなくても、管理状況は確認できる
サイト運営者がPHPを書ける必要はありません。
ただし、「最後に更新したのはいつか」「何が保守対象か」「不具合が起きたら誰に連絡するか」は、把握しておきたい情報です。
任せることは、作業を依頼することです。状況の共有や、必要な費用・対応の判断までなくなるわけではありません。
今の管理状況を確認するチェックリスト
| 確認 | 項目 |
|---|---|
| □ | WordPress本体・プラグイン・テーマの更新状況が分かる |
| □ | 使用中のPHPとサポート期限を確認している |
| □ | 更新を止めているものは、理由と対応予定が決まっている |
| □ | 不要なプラグイン・テーマ・管理者アカウントを整理している |
| □ | ファイルとデータベースのバックアップがある |
| □ | 復元方法と、復旧を担当する人が決まっている |
| □ | 攻撃や障害の通知を確認する担当者がいる |
| □ | 更新後にフォーム・予約・購入などを確認している |
| □ | 保守契約に含まれる作業と別料金の作業が分かる |
| □ | 作業報告と、未対応の課題を確認している |
チェックできない項目があったら、まず現在の状況を確認しましょう。
古いからと慌てて本番環境を一括更新するのではなく、必要な修正と復旧方法を整理してから進めることが大切です。
更新や保守の状況が分からない場合はご相談ください
ホームページは、公開して終わりではありません。使い続けるためには、更新、動作確認、バックアップ、監視を継続する必要があります。
専門知識がないことは、専門家に相談する理由になります。しかし、「分からないので任せきり」にして、何年も管理状況が見えない状態にすることは避けたいところです。
「長い間更新していない」
「保守費用を払っているけれど、内容が分からない」
「更新したらフォームが動かなくならないか心配」
そんな場合は、お問い合わせフォームからお気軽にご相談ください。相談は無料です。
調査・修正・更新作業などが必要な場合は、内容と費用をご案内したうえで進めます。