AIがゼロデイを自動発見する時代に中小企業のWordPressは何をすべきか

ゼロデイが「例外」でなくなった

生成AIによる脆弱性の自動発見が進み、これまで人間が見落としていた欠陥が短時間で見つかるようになりました。2026年4月のAnthropic「Claude Mythos Preview」発表（外部サイト）はその象徴的な出来事で、AIが主要なOSやブラウザの未知の脆弱性を自律的に大量発見できることを実証しています（Mythos自体は攻撃者には公開されておらず、Project Glasswingという防御側の連合にのみ提供されています）。ここで確認できているのは、見つかる速さと量が変わったことまでです。MythosもこのあとのCodexの事例も、防御側が自ら探して開発元へ知らせたもので、攻撃に使われたという報告ではありません。それでも運用側から見ると、修正が出るまでのあいだ手の打ちようがない期間は、以前より起きやすくなります。

実際、2026年6月にはOpenAIのコーディングエージェント「Codex」が、nginxやApache httpdなど主要なWebサーバーソフトウェアに共通する未知の欠陥（CVE-2026-49975、通称「HTTP/2 Bomb」）を、コードを読むだけで自動的に発見しています。個別には10年以上前から知られていた手法の組み合わせで、人間の研究者は見過ごしていました。WordPressそのものだけでなく、それを支える基盤ソフトウェアの側でも、AIによる脆弱性発見はすでに現実になっています。

中小企業がすべての脆弱性を先回りで塞ぐのは現実的ではありません。攻撃の対象になる部分そのものを減らす方向に、考え方を切り替える必要があります。更新を追う運用で危険が収まるかは、記事の最後に挙げた次の記事で扱っています。

まず削るべきもの

• 使っていないプラグイン・テーマ：有効・無効を問わず、使っていないものは削除する。導入数が多いほど攻撃の入り口が増える。
• 不要な公開範囲：管理画面へのアクセス元を制限し、公開しなくてよい機能を閉じる。
• 放置されたアカウント：使われていない管理者アカウントを整理し、パスワードを見直す。

攻撃の入り口を構造的に減らす

攻撃の入り口そのものを取り除く方法は、公開側でプログラムを動かさない構成にすることです。WordPressのページを事前に作り置きする“表示専用”の構成（WordPress静的移行）にすれば、WordPress本体とプラグインに由来する未知の脆弱性は、公開側から外れます。ただし公開側にはWebサーバーと配信の仕組みが残り、そちらの脆弱性は残ります。実際、2026年6月に見つかったnginxとApache httpdに共通する欠陥は、WordPressの有無に関わらず影響します。減らせるのは入り口の数であって、ゼロにはなりません。

記事の編集は管理画面で続けられるため、日々の運用は大きく変わりません。攻撃の対象になる部分だけを公開側から切り離す、という発想です。

機能ごとに、どこまで適用できるかが分かれる

どこまで適用できるかは、いま動いている機能ごとに分かれます。次の表を、自社のサイトで動いているものに当てはめてください。

フォームとサイト内検索は、別の仕組みへ預けられることが多い部分です。方式ごとの違いと、選ぶ前に確かめる項目はフォームや検索を公開側の処理なしで動かす方法にまとめています。

行き先が「作り替えの検討へ回す」になった機能が売上の中心にあるなら、静的移行だけでは届きません。閲覧側だけを先に移し、購入や予約は別に作る、という分け方になります。

段階的な実行計画

• 棚卸し：現在のプラグイン・動的機能・公開範囲を洗い出す。
• 優先度づけ：攻撃の入り口になりやすい部分と、静的移行しやすい部分を切り分ける。
• 移行と引き継ぎ：影響の小さいページから静的移行し、運用手順を引き継ぐ。

費用対効果の考え方

静的移行には初期費用がかかります。月々の保守作業（更新確認・バックアップ・監視）は、公開側から外した範囲にかかっていた分だけ減ります。侵害が起きたときの復旧費用と機会損失は、避けられると約束できるものではありません。入り口が減る分だけ、起こる可能性が下がります。継続してかかる費用と、事故が起きたときの損失の両方を並べて比べてください。

具体的な費用の目安と変動要因は、料金・見積の考え方を確認するページにまとめています。