脱WordPressは必要？移行先の比較と安全に使い続ける判断基準

今回の問題はWordPressだけの脆弱性ではない

2026年10月21日、PHP公式は、認証なしでサーバー上のコードを実行される可能性がある2件の重大な脆弱性について、修正版を公開しました。対象の識別番号はCVE-2026-109618とCVE-2026-109619です。^[1]

PHPはWordPressの動作に使われている言語ですが、WordPress以外のWebシステムにも使われています。今回の告知は、WordPress本体や特定のプラグインだけを対象とするものではありません。

そのため、WordPressの管理画面で本体を更新しただけで、サーバー側のPHPまで対処できたと判断しないようにしましょう。サーバー会社や保守担当者に、使用中の環境が対象か、修正が適用されているかを確認する必要があります。

PHP公式では10月23日にも、特殊な設定条件に関する追加の注意事項を公表しています。移行の検討と並行して、現在の環境に必要な対処を進めることが先決です。 最新の対応状況は、PHP公式と利用中のサーバー会社の案内で確認してください。^[1][2]

AIによる攻撃の高度化と、個別の被害原因を分けて考える

AIが攻撃の効率や精度を高めることへの懸念には根拠があります。英国のNCSCは、AIがサイバー侵入の一部を効率化し、脅威の頻度や強度を高めると評価しています。また、脆弱性の公開から悪用までの時間が、さらに短くなると予測しています。^[3]

こうした状況では、脆弱性の発表を把握し、対象を確認して修正するまでの速さが重要になります。

ただし、「AIの普及によって情報漏えいが増えている」「最近の企業被害は今回のPHPの問題が原因」と、個々の事案を一括りにすることはできません。不正アクセスや漏えいの原因は、各社の公表内容や調査結果に基づいて確認する必要があります。

1．別の言語やCMSに移行しても、脆弱性への対応は続く

PHP以外の技術でも、重大な脆弱性は発見されています。

例えばReact公式は2025年12月、React Server Componentsの一部パッケージに、認証なしでコードを実行される重大な脆弱性があると公表しました。これはJavaScriptの言語仕様そのものの問題ではなく、特定のサーバー側コンポーネントの問題です。Reactを使うすべてのサイトが対象になるわけでもありません。^[4]

この事例からも、採用する言語名だけで安全性を判断することはできません。言語の実行環境、CMS、追加ライブラリ、サーバー設定など、実際に使っている構成を把握する必要があります。

移行によって攻撃される入口を減らせる場合はあります。ただし、その効果は移行先の構成と運用次第です。別のCMSを自社サーバーに設置するなら、そのCMSやサーバーの更新を引き続き管理することになります。

2．大手企業の情報漏えいと、自社サイトの問題を混同しない

Webサイトの改ざん、問い合わせ情報の流出、社内ネットワークへの侵入、業務システムの停止は、それぞれ確認すべき対象が異なります。共通の原因で起こる場合もありますが、同じ問題とは限りません。

例えば、公式サイトを静的ページに変えても、予約管理サービスのアカウントが乗っ取られれば、そちらに保存した情報が危険にさらされます。フォームの情報をメールで受け取っている場合には、メールアカウントも管理対象になります。

大手企業の被害報道に接したときも、企業規模やセキュリティの宣伝文句から自社の安全性を推測するのではなく、どこから侵入され、何に影響したのかを分けて考えましょう。

自社では、公開サイト、予約、フォーム、メール、顧客管理などを一覧にし、担当者とデータの保存先を確認するところから始めます。

3．プラグインで実装した機能を、移行後も使えるか

WordPressをやめる前に、現在のサイトで使っている機能を洗い出しましょう。

プラグインを削除すれば管理対象は減りますが、それが担っていた業務まで不要になるわけではありません。代わりの仕組み、設定作業、毎月の費用まで含めて比較する必要があります。

4．SEO・AEOに必要な更新環境を維持できるか

SEOや、AIによる回答・検索を意識したAEOに取り組む場合には、必要な情報を継続して公開・修正できる環境が重要です。

例えば、営業時間や料金が変わったときにすぐ修正できるか、顧客から新しく寄せられた疑問に答えるページを追加できるか、といったことです。更新のたびに制作会社への依頼やコード編集が必要になると、発信が滞る可能性があります。

ただし、更新回数を増やすだけでSEOやAEOの成果が上がるわけではありません。利用者の疑問に答える内容、情報の正確さ、検索システムが内容を取得できる構成を維持することが前提です。Googleも、検索のAI機能に対して従来のSEOの基本が引き続き有効であり、特別な追加要件はないと説明しています。^[5]

記事発信が集客の中心になっている場合は、移行先の管理画面で実際に記事を作り、画像や表の追加、公開前の確認、既存記事の修正まで試してから判断しましょう。

編集環境を維持しながら、公開側を簡素化できる

例えば、担当者はCMSの管理画面で記事を編集し、その内容から静的ページを生成して公開する構成が考えられます。公開サーバーでCMS本体を動かさずに済むため、管理機能と公開部分の接点を減らす設計ができます。

ただし、ヘッドレスCMSだから必ず静的ページになるわけではありません。アクセスのたびにサーバーでページを生成する構成もあり、実際の仕組みによって保守対象は変わります。

公開処理やAPIなど、新しく管理する部分もある

ヘッドレスCMSでは、公開サイトのプログラム、APIの認証情報、記事を公開する処理、プレビュー環境なども設計・管理します。

従来はプラグインで実現していた目次、関連記事、検索、SEO設定などを、別途実装する必要が生じることもあります。記事を編集できても、公開処理が止まっていればサイトには反映されません。

導入時には、編集者の使いやすさと、公開までの流れを保守できる担当者がいるかを確認しましょう。WordPressをヘッドレス化する方法もありますが、その場合はWordPressとPHPの保守が残る点にも注意が必要です。

判断と対応ができる管理者を決める

管理者は社内の専任者に限りません。外部の保守会社でも構いませんが、実際に対応できる範囲を明確にする必要があります。

バックアップは、取得しているだけでなく復元できるかを確認します。また、改ざん前のデータを戻しても、侵入口となった原因が残っていれば再び被害を受ける可能性があります。復旧と原因への対処を一緒に進められる体制が必要です。

不要な機能を減らし、把握できる構成にする

サイトのコンパクト化では、ページ数だけでなく、管理対象となる機能や連携を減らすことを考えます。

使っていないプラグイン、放置されたテストサイト、退職者のアカウント、不要な外部連携などを整理すれば、確認すべき対象を減らせます。一方、サービスを分けすぎると管理するアカウントや契約が増えるため、全体を把握できる範囲に収めることも重要です。

目指すのは、自社に必要な機能があり、管理対象とデータの保存先が分かり、緊急時に変更・停止・復旧できるサイトです。