WordPressAI時代の脅威と5項目の対応手順、サイトヘルスの意味

WordPressの管理画面で「サイトヘルス」を開いたら、黄色い丸に「改善が必要」の文字。そして「1件の致命的な問題」。

初めて見ると不安になりますが、落ち着いて1項目ずつ対応すれば問題ありません。ただし「あとでまとめてやろう」は、もう通用しません。生成AIの進化によって、WordPressを取り巻く攻撃環境はこの1〜2年で根本的に変わったからです。

この記事では、まずなぜ更新の遅れが致命的になったのかを最新データで確認したうえで、実際のサイトヘルス画面の各項目をどう対応すべきかを解説します。

【前提】AIが攻撃速度を変えた——数時間で無差別攻撃が始まる時代

サイトヘルスの対応手順に入る前に、2026年時点の攻撃環境を押さえておく必要があります。ここを理解していないと、対応の優先順位を間違えます。

脆弱性探索のコストが劇的に下がった

WordPressはオープンソースであり、ソースコードが誰でも閲覧できます。これは開発の透明性という長所である一方、LLMによる自動コード監査の格好の標的でもあります。

象徴的な事例が2026年7月に起きました。

Searchlight Cyberの研究者Adam Kues氏が、最新の安定版WordPressのソースコードをLLMエージェントに監査させたところ、未認証状態からリモートコード実行（RCE）に至る複数段階のエクスプロイトチェーンを約10時間で自律的に構築しました。かかったモデル利用料は、200ドルのサブスクリプションの按分でおよそ25ドルです（Searchlight Cyber／XDA Developers）。

この「wp2shell」と呼ばれる攻撃チェーンは、REST APIのバッチ処理におけるルート混同（CVE-2026-63030、CVSS 9.8）とWP_Queryのソースインジェクション（CVE-2026-60137、CVSS 7.5）を連鎖させるもので、プラグインを一切入れていないWordPressでも成立するものでした。

従来であれば、熟練のセキュリティ研究者が数週間かけても完成させられるか分からない水準の作業です。それが10時間・25ドルになった——ここが決定的な変化です。

補足（過度な単純化を避けるために） この25ドルという数字は「誰でも25ドルでゼロデイが買える」という意味ではありません。研究者は対象の選定、探索範囲の制約、出力の検証に相応の専門性と時間を投入しています。とはいえ、探索段階の限界費用が劇的に下がったという事実は変わりません。

公表から「5時間」で大量攻撃が始まる

脆弱性が公表されてから実際の攻撃が始まるまでの猶予は、すでに「数日」ではありません。

Patchstackが2026年2月に公開した年次レポート『State of WordPress Security in 2026』によると、深刻度の高い脆弱性が公表されてから大規模な悪用が観測されるまでの加重中央値は「5時間」です。また、影響の大きい脆弱性の約半数は公表から24時間以内に悪用されています（Patchstack）。

さらに深刻なのは、公表時点で公式パッチが存在しない脆弱性が46%にのぼる点です。つまり「更新すれば直る」とは限らない状態で、攻撃コードだけが先にばらまかれます。

先ほどのwp2shellも同様でした。修正版（7.0.2 / 6.9.5 / 6.8.6）が2026年7月17日に公開された翌日以降、GitHub上にPoCが流通し、複数のセキュリティベンダーが実際の攻撃を観測。米国CISAは7月21日に両CVEを「既知の悪用脆弱性（KEV）カタログ」へ登録しました。

脆弱性の発見件数そのものが増えている

同レポートによれば、2025年にWordPressエコシステムで新たに確認された脆弱性は11,334件で、前年比42%増。うち91%がプラグイン、9%がテーマに起因します（コア本体は6件のみ・いずれも低リスク判定）。

増加の背景としてレポートが名指ししているのが「vibe coding」——開発者がLLMでプラグインのコードを生成し、自分で監査できないまま公開してしまう流れです。皮肉なことに、AIは攻撃側の探索を加速させると同時に、脆弱なコードの供給量そのものも増やしています。

防御側もAIを投入している

一方的な話ではありません。防御側もAIエージェントを実戦投入しています。

セキュリティベンダーWordfenceは、複雑な脆弱性チェーンの発見に特化したAI研究エージェント「Argus」を運用しており、2026年7月30日には、人気テーマAvadaとFusion Builderにまたがる6つの欠陥を連鎖させた未認証RCE（CVE-2026-18431、CVSS 9.8）を約2時間で発見し、動作するPoCコードまで自動生成しました（Wordfence）。熟練の研究者でも数週間〜数か月かかりうる、あるいは最後まで繋がらないかもしれない類の脆弱性です。

Wordfenceは同種の手法が攻撃側にも使えることを理由に、Argusの内部構造を公開していません。これは防御側と攻撃側のAI軍拡競争であり、サイト運営者はその戦場の上にいます。

Wordfenceプラグインは、無料版で試して、自分にあっていれば有料版にアップグレードして下さい。個人的には入れた方が良いと思っています。

結論：月1回の手動更新では守れない

以上を踏まえると、従来の「月に一度まとめて更新する」という運用は、公表から5時間で到達しうる攻撃に対して構造的に間に合いません。

必要なのは次のパラダイム転換です。

セキュリティリリースの自動適用（人間の判断待ちを挟まない）
バーチャルパッチ（仮想パッチ）：公式パッチを待たず、WAFやPHP層で悪用リクエストを遮断する
ファイル変更の制限：攻撃の最終段階であるバックドア設置やファイル書き換えを、本番環境のアーキテクチャ側で封じる

この前提を持ったうえで、サイトヘルスの画面を見ていきましょう。サイトヘルスは「更新漏れを検知する最後の砦」として機能します。

サイトヘルスとは？

サイトヘルスは、WordPressサイトの技術的な健康状態を自動診断してくれる標準機能です。WordPress 5.2から搭載されました。

アクセス方法

管理画面左メニュー → ツール → サイトヘルス
または、ダッシュボードの「サイトヘルスステータス」欄のリンクから

セキュリティ、パフォーマンス、更新状況などをチェックし、問題があれば「致命的な問題」「おすすめの改善」に分類して表示してくれます。

画面の構成を理解する

2つのタブ

タブ	内容
ステータス	注意が必要な項目の一覧。実際に対応するのはこちら
情報	WordPressのバージョン、プラグイン数、サーバー環境、データベース情報などの閲覧専用データ。サポートに状況を伝えるときに便利

総合評価は2段階

画面上部の表示は「良好」か「改善が必要」のどちらかです。

ここで大事なポイントがあります。

「改善が必要」＝サイトが壊れている、ではありません。

おすすめの改善が1件でも残っていると「改善が必要」と表示される仕様です。環境上どうしても対応できない項目もあるため、すべてを緑にすること自体を目的にする必要はありません。優先すべきは「致命的な問題」のほうです。

3つの区分

致命的な問題 — セキュリティやパフォーマンスに重大な影響。最優先で対応
おすすめの改善 — 対応したほうがよいが、緊急性は低い
テスト通過 — 問題なしと判定された項目（画面下部の「テスト通過」を開くと確認できます）

今回の診断結果まとめ

今回の画面に表示されていたのは、以下の5項目です。

区分	項目	分類	優先度
致命的	WordPressの更新が可能（7.1.1）	セキュリティ	最優先・即日
改善	停止中のプラグインを削除してください	セキュリティ	高
改善	デフォルトテーマを利用可能にしましょう	セキュリティ	中
改善	永続オブジェクトキャッシュを使用してください	パフォーマンス	低（環境次第）
改善	ページキャッシュは検出されませんでした（レスポンスは良好）	パフォーマンス	低（対応不要も可）

以下、1つずつ見ていきます。

【致命的】WordPressの更新が可能（7.1.1）

なぜ「致命的」なのか

前段で見たとおり、アップデート情報の公開は「どこに穴があるか」の公開とほぼ同義です。更新を先延ばしにするほど、公開済みの攻撃コードに晒される時間が伸びていきます。

今回表示されている WordPress 7.1.1 は、まさにセキュリティリリースです。

WordPress公式の発表によると、7.1.1ではセキュリティに関する11件の修正に加え、コア部分で17件、ブロックエディターで19件のバグ修正が行われており、開発チームは利用者に早急な更新を呼びかけています。修正内容には、一部の関数やテーマにおける格納型クロスサイトスクリプティング（XSS）、細工したURLによって非アクティブなテーマを自動インストールさせてプレビューできてしまう問題、認証済みユーザーによるREST APIのパストラバーサルなどが含まれます。

なお、セキュリティ修正は対象となる旧ブランチにもバックポートされますが、公式にアクティブサポートされているのは常に最新バージョンのみです。「うちは古いバージョンで安定しているから」という運用は、もはや成り立ちません。

更新前に必ずやる3つのこと

急いで更新ボタンを押す前に、この3つだけは押さえてください。

1. バックアップを取る

最低でも「WordPressファイル一式」と「データベース」の両方です。

サーバーのバックアップ機能（多くのレンタルサーバーに標準搭載）
プラグイン（UpdraftPlus、BackWPupなど）
サーバーのコントロールパネルからphpMyAdmin経由でDBエクスポート

いずれかの方法で、更新直前の状態を残しておきます。

2. テーマ・プラグインの対応状況を確認する

有料テーマや多機能プラグインを使っている場合、新しいメジャーバージョンへの対応が遅れることがあります。公式サイトやサポート情報で対応アナウンスが出ているかを確認してください。

3. できればステージング環境で試す

本番と同じ構成のテスト環境がある場合は、そちらで先に更新して表示崩れやエラーがないかを確認します。サーバーによってはステージング機能が標準提供されています。

ただし、セキュリティリリース（7.1.1のようなマイナー更新）については、検証を理由に何日も止めるのは本末転倒です。バックアップさえ確保できていれば、即日適用を優先してください。

更新手順

管理画面 → ダッシュボード → 更新
まずプラグインとテーマを最新にする
WordPress本体の「今すぐ更新」をクリック
更新後、フロント画面・投稿編集画面・お問い合わせフォーム・カート機能など主要動線を目視チェック

更新後に不具合が出たら

プラグインを1つずつ停止して原因を切り分ける
テーマ起因が疑われる場合は、一時的にデフォルトテーマに切り替えて確認（← これが後述の「デフォルトテーマ」項目が重要な理由です）
復旧できない場合はバックアップから戻す

自動更新の設定は「見直すべき」項目

WordPressには自動更新機能があります。かつては「自動更新は怖いから手動で」という考え方が一般的でしたが、攻撃までの猶予が5時間という環境では、判断の重心が変わりました。

マイナーリリース（セキュリティ修正）は自動ON を強く推奨 — 人間の確認を待つ数日のほうがリスクが大きい
メジャーリリースは手動 — 大きな仕様変更が入るため、テーマ・プラグインの対応確認後に実施
プラグインの自動更新 — 特に利用者数の多いプラグインはONを検討。[プラグイン]一覧の「自動更新を有効化」から個別に設定できます

自動更新をONにする前提条件は、バックアップが自動で取得されていることです。この2つはセットで考えてください。

【改善】停止中のプラグインを削除してください

何が問題なのか

「停止中なら動いていないから安全」と思われがちですが、違います。

停止中のプラグインも、プログラムファイル自体はサーバー上に残っています。脆弱性を持つファイルが直接URLで呼び出されてしまうケースがあり、実際にこの手口を使った攻撃は珍しくありません。さらに、停止中のプラグインは更新されないまま放置されやすく、古いコードが残り続けます。

前段で見たとおり、新規脆弱性の91%はプラグイン由来です。使っていないプラグインを置いておくことは、使っていない裏口の鍵をかけ忘れているのと同じです。

使わないものは「停止」ではなく「削除」が正解です。

対応手順

管理画面 → プラグイン → インストール済みプラグイン
「停止中」タブで一覧を確認
不要なものにチェックを入れ、一括操作から「削除」

削除前の判断ポイント

データが消える可能性：問い合わせフォームやSEO系プラグインは、削除時に設定やデータベースの内容も消える場合があります。再利用の可能性があるなら設定をエクスポートしておく
トラブルシューティング用：不具合検証のために一時的に停止しているものは残す
判断がつかないもの：プラグイン名で検索して機能を確認してから削除

【改善】デフォルトテーマを利用可能にしましょう

何が問題なのか

デフォルトテーマ（Twenty Twenty-Fiveなど、WordPress純正のテーマ）が1つもインストールされていない状態です。

これが問題になるのは、トラブルが起きたときです。

使用中のテーマでPHPエラーが発生してサイトが真っ白になった場合、WordPressは自動的にデフォルトテーマへ切り替えて復旧を試みます。その受け皿がないと、この自動フォールバックが機能しません。また、不具合の原因が「テーマなのか、それ以外なのか」を切り分ける際にも、デフォルトテーマへの一時切り替えは基本手順です。

対応手順

管理画面 → 外観 → テーマ → 新規追加
最新のTwenty系テーマをインストール（有効化はしない）

デフォルトテーマはインストールしておくだけで役割を果たします。有効化する必要はありません。

注意点

親テーマを削除しない：AFFINGERやSWELLなどで子テーマを使っている場合、親テーマは「使っていないように見えて必須」です。停止中テーマの整理で誤って削除しないよう注意
テーマも攻撃対象：前段で紹介したAvadaの事例のように、テーマとその同梱プラグインが未認証RCEの起点になることがあります。デフォルトテーマも含め、インストールしたものは更新対象として扱ってください

【改善】永続オブジェクトキャッシュを使用してください

何を言っているのか

WordPressはページを表示するたびに、データベースへ何度も問い合わせを行います。オブジェクトキャッシュは、この問い合わせ結果をメモリに保存して使い回す仕組みです。

デフォルトのWordPressはページ表示ごとにキャッシュを捨てる「非永続」方式なので、RedisやMemcachedを使ってリクエストをまたいで保持する「永続オブジェクトキャッシュ」を推奨します、という警告です。

対応が必要かの判断

結論：多くの中小規模サイトでは、対応しなくても問題ありません。

永続オブジェクトキャッシュが効果を発揮するのは、主に以下のようなケースです。

投稿数・商品数が非常に多い
アクセス数が多く、DB負荷が問題になっている
会員サイトやECサイトなど、動的処理が多い

一方で、共有レンタルサーバーではRedisやMemcachedが利用できないプランが大半です（対応状況は契約中のサーバーの仕様ページで確認してください）。利用できない環境では、この警告は消せません。

これはセキュリティ項目ではないため、対応不可と割り切って次に進んで構いません。限られた時間は、本体更新とWAFの整備に使うべきです。

対応できる場合の手順

サーバーがRedis／Memcachedに対応しているか確認（VPS、専用サーバー、一部のマネージドWordPressホスティングなど）
サーバー側でRedis等を有効化
接続用プラグイン（Redis Object Cacheなど）を導入・設定

【改善】ページキャッシュは検出されませんでしたが、サーバーのレスポンスは良好です

これは警告ではなく「報告」

項目名をよく読んでください。後半に「サーバーのレスポンスは良好です」と書かれています。

これは「キャッシュは無いけれど、表示速度に問題は出ていませんよ」という報告です。緊急性はありません。

ページキャッシュとは、生成済みのHTMLを保存して次回以降そのまま返す仕組みで、表示速度の改善に直結します。ただしレスポンスが既に良好なら、導入しなくても実害はありません。

導入を検討したほうがいいケース

PageSpeed Insightsやサーチコンソールの「ウェブに関する主な指標」で改善余地が指摘されている
アクセス増加時に表示が重くなる
将来的にアクセス数の増加が見込まれる

導入する場合の選択肢

優先順位1：サーバー側のキャッシュ機能

多くのレンタルサーバーがコントロールパネルから有効化できる高速化機能を提供しています。プラグインより軽量で競合も起きにくいため、まずこちらを検討します。

優先順位2：キャッシュプラグイン

WP Super Cache、LiteSpeed Cache、W3 Total Cacheなどが代表的です。

導入時の最重要注意点

キャッシュ系の機能を複数同時に有効化しないでください。

サーバー側キャッシュとキャッシュプラグイン、あるいは複数のキャッシュプラグインを併用すると、更新内容が反映されない、レイアウトが崩れる、ログイン状態がおかしくなるといったトラブルの原因になります。必ずどれか1つに絞るのが鉄則です。

また、導入後は以下を必ず確認してください。

記事を更新したらフロント側に反映されるか
お問い合わせフォームが正常に送信できるか
ログイン中の管理バーが表示されるか

「テスト通過」もたまには開いてみる

画面下部の「テスト通過」を開くと、問題なしと判定された項目が一覧できます。

SSL（HTTPS）が有効か
PHPのバージョンは適切か
REST APIが正常に動作しているか
自動更新が機能しているか
データベースサーバーのバージョン

など、サイトの土台に関わる項目が並びます。問題がないうちは読み飛ばして構いませんが、「今は通過しているが、いずれ警告に変わる項目」（PHPバージョンなど）もあるため、半年に一度は目を通しておくと安心です。

対応の優先順位まとめ

優先度	項目	目安の対応時期
★★★	WordPress本体の更新（7.1.1）	即日。バックアップ後に実施
★★☆	停止中のプラグイン削除	1週間以内
★★☆	デフォルトテーマの導入	1週間以内（インストールのみ・有効化不要）
★☆☆	ページキャッシュ	表示速度に課題があれば検討
☆☆☆	永続オブジェクトキャッシュ	環境が対応していなければ対応不要

上2つを片付ければ、セキュリティ面のリスクは大きく下がります。下2つはサーバー環境とサイト規模によって「対応しない」が正解になり得る項目です。

サイトヘルス対応だけでは足りない——運用側の3つの手当て

サイトヘルスは「現時点での設定不備」を教えてくれますが、まだ公表されていない脆弱性や、パッチが提供されていない脆弱性は検知できません。前段で見たとおり、公表時点でパッチがない脆弱性は46%にのぼります。

そこで、以下の3層を併せて整備します。

1. WAF／バーチャルパッチ（仮想パッチ）

公式アップデートを待たずに、悪用リクエストそのものを遮断する層です。

サーバー標準のWAF：多くのレンタルサーバーが無料で提供しています。まず有効化されているか確認してください
セキュリティプラグイン：Wordfence、Patchstack（有料版に仮想パッチ機能あり）、SiteGuard WP Pluginなど
CDN型WAF：Cloudflareなど

実際、前段のwp2shellでは、パッチ適用までの暫定対策としてWAFで該当するREST APIエンドポイントを遮断する運用が推奨されました。「更新までの数時間を凌ぐ層」があるかどうかが、被害の有無を分けます。

2. ファイル変更の制限

攻撃の最終段階は、多くの場合バックドアの設置やファイルの書き換えです。ここを封じます。

wp-config.php に define('DISALLOW_FILE_EDIT', true); を追加し、管理画面からのテーマ・プラグイン編集を禁止する
本番環境でのファイル書き込み権限を必要最小限に絞る
ファイル改ざん検知の仕組みを入れる（セキュリティプラグインの多くが対応）

大規模な運用では、本番環境のファイルシステムを読み取り専用にするイミュータブルな構成への移行も進んでいます。

3. ログイン防御

機械学習を用いたパスワード推測により、従来型の総当たり攻撃より的中率の高いログイン試行が行われています。

管理画面URLの変更
ログイン試行回数の制限
二段階認証の導入（最も効果的）
使っていない管理者アカウントの削除

定期メンテナンスのチェックリスト（AI時代版）

「月1回の点検」ではなく、自動化を前提に、人間は確認に回る構成に変えます。

常時（自動化しておく）

[ ] WordPress本体のマイナー（セキュリティ）リリースの自動更新をON
[ ] バックアップの自動取得
[ ] WAF／セキュリティプラグインの有効化
[ ] 脆弱性アラートの通知受信設定

週1回（5分）

[ ] 更新通知の有無を確認し、残っていれば適用
[ ] サイトヘルスに「致命的な問題」が出ていないか確認
[ ] 自動バックアップが正常に走っているか確認

月1回

[ ] プラグイン・テーマの更新を適用し、主要動線を動作確認
[ ] 管理者アカウントの棚卸し

半年に1回

[ ] 使っていないプラグイン・テーマを削除
[ ] 「テスト通過」の項目にも目を通す
[ ] PHPバージョンの対応状況を確認

随時（即応）

[ ] 深刻度の高い脆弱性情報が出たら、その日のうちに更新またはWAFでの遮断

まとめ

サイトヘルスの画面は、項目名だけを見ると難解ですが、整理するとシンプルです。

「致命的な問題」は即日対応する — AIによって攻撃コードの生成コストが下がり、公表から数時間で無差別攻撃が始まる時代です
「おすすめの改善」は内容を見て判断する — 環境上対応できない項目もあり、全部を緑にする必要はありません
更新の前には必ずバックアップ — これだけは例外なく
サイトヘルスは最低ラインであって、十分条件ではない — WAF・バーチャルパッチ・ファイル改ざん対策を併せて整える
自動化できるものは自動化する — 人間の判断を待つ数日が、そのままリスクになります

攻撃側のコストは下がり続けています。同じ技術は防御側にも使えますが、何も手を打たないサイトだけが、一方的に不利になっていく構図です。

まずはバックアップを確認して、今日中に本体を最新版にしてしまいましょう。

参考・出典

AI時代の脅威動向

Patchstack『State of WordPress Security in 2026』（2026年2月公開）：patchstack.com — 2025年の新規脆弱性11,334件（前年比42%増）、うち91%がプラグイン由来、公表から大量悪用までの加重中央値5時間、公表時点でパッチ未提供46%
Adam Kues / Searchlight Cyber「wp2shell」研究記事：slcyber.io — LLMエージェントによる未認証RCEチェーンの自律生成（約10時間・約25ドル）
XDA Developers による解説記事：xda-developers.com
Wordfence「Argus」解説：wordfence.com — AIエージェントによるAvadaテーマの6段階チェーン発見（CVE-2026-18431、CVSS 9.8）

WordPress公式情報

サイトヘルス画面の解説：ja.wordpress.org
WordPress 7.1.1 リリースノート：wordpress.org/news（2026年9月17日公開）
7.1.1の脆弱性概要（日本語）：Security NEXT