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

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

生成AIによる脆弱性の自動発見が急速に進み、未知の脆弱性が短時間で大量に見つかる状況が現実になりました。2026年4月のAnthropic「Claude Mythos Preview」発表（外部サイト）はその象徴的な出来事で、AIが主要なOSやブラウザの未知の脆弱性を自律的に大量発見できることを実証しています（Mythos自体は攻撃者には公開されておらず、Project Glasswingという防御側の連合にのみ提供されています）。これまで「まれに起きる例外」として扱われてきたゼロデイ攻撃を、常に起こりうる前提として運用を設計する必要があります。

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

中小企業がすべての脆弱性を先回りで塞ぐのは現実的ではありません。攻撃の対象になる部分そのものを減らす方向に、考え方を切り替える必要があります。同じ変化がWordPress運用全体に与える影響は、更新を追う運用で危険が収まるかを確認するにまとめています。

まず削るべきもの

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

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

最も確実に攻撃の入り口を減らす方法は、公開側でプログラムを動かさない構成にすることです。WordPressのページを事前に作り置きする“表示専用”の構成（WordPress静的移行）にすれば、未知の脆弱性が公開側に残らなくなります。

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

段階的な実行計画

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

費用対効果の考え方

静的移行には初期費用がかかりますが、月々の保守作業（更新確認・バックアップ・監視）の手間が減り、侵害が起きた場合の復旧費用と機会損失を避けられます。継続的にかかるコストと事故時の損失の両面で判断すると、投資の回収期間が見えやすくなります。

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