WordPressは使い続けて大丈夫？PHP脆弱性後の運用方法と判断基準

企業サイトでWordPressを使い続けてよいのでしょうか。

結論から言えば、WordPressを一律にやめる必要はありません。安全に運用する方法も一つではありません。 現在の構成を堅牢化する、管理型WordPressへ移す、公開側を分けてヘッドレス化する、WordPress以外へ移行する。必要な機能と運用体制に応じて、この中から選びます。

ヘッドレス化は、安全に運用するための選択肢の一つです。公開面を分ける必要があり、二つのシステムを継続管理できる企業に向いています。今回の緊急対応はPHPの更新です。どの方法を選ぶ場合も、最初にPHPを更新し、そのあとで「誰が更新するか」「どこまで公開するか」「何の機能が必要か」「障害時に戻せるか」を確認します。

PHPの重大脆弱性が出たら、WordPressをやめるべきなのか

今回最初に行うのは、PHPの更新確認です。

2026年10月21日、PHPは認証されていない第三者による遠隔コード実行につながる、2件の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）を修正しました。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。

PHP公式のセキュリティ情報は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含む、Webリクエストを処理するすべてのPHP環境が対象だとしています。特にmod_phpでは、WordPressなどのアプリケーションが動き始める前に攻撃が成立する実証例があるため、WordPressのセキュリティプラグインだけでは修正できません。

WordPress公式も、今回の脆弱性はPHP側の問題であり、この件に対応するWordPress本体の更新は予定していないと案内しています。

なお、Linuxディストリビューションや長期サポート事業者が修正をバックポートしている場合があります。画面に表示されたPHPの番号だけで未対応と決めず、利用中のサーバー会社が修正を適用済みか確認してください。PHP 8.2は2026年12月31日に公式サポート終了予定なので、8.2を使う環境では今回の修正に加え、その先の移行計画も必要です。

今日確認する4項目

「ツール → サイトヘルス → 情報 → サーバー」でPHPの表示を確認する
「今回の2件への修正は適用済みか」をサーバー会社または保守担当へ聞く
更新前のバックアップと、更新後の表示・フォーム・管理画面の確認手順を用意する
PHP、WordPress本体、プラグインの更新責任者と連絡先を確認する

PHP公式は「完全な解決は更新」としています。CMSの構成を検討するのは、この緊急対応を済ませてからです。

安全に運用する方法は、5つの基準で選ぶ

選択肢は、現在の構成の堅牢化、管理型WordPress、ヘッドレスWordPress、WordPress以外への移行です。どれが適切かは製品名だけでは決まりません。次の5項目を同じ重さで確認します。

判断基準	確認すること	継続しやすい状態	構成を見直すサイン
更新責任	PHP、WordPress、プラグイン、OSを誰がいつ更新するか	担当、期限、緊急時の連絡先が決まっている	契約範囲と担当者が分からない
公開範囲	管理画面、API、元サーバー、DBへ誰が到達できるか	必要な人とシステムだけに限定している	インターネットからの到達経路を把握していない
必要機能	EC、会員、予約、検索、フォームなど何が必要か	必要機能と依存するプラグインを説明できる	使っていない機能やプラグインが残っている
復旧能力	監視、バックアップ、復元、改ざん時の手順があるか	異常を検知でき、復元を試している	バックアップの保存先や戻し方が不明
運用能力	選んだ構成の更新、監視、復旧を誰が担うか	必要な担当と手順が決まっている	制作会社を含めても仕組みを説明できない

最後の「運用能力」は見落とされやすい項目です。特にヘッドレス化では、WordPressに加えて表示用システム、ビルド、公開、監視も管理対象になります。二つのシステムを継続管理できなければ、ヘッドレス化は適切な選択になりません。

ヘッドレスWordPressとは何か。安全性はどこで変わるのか

ここからは、選択肢の一つであるヘッドレスWordPressを詳しく見ます。これは、記事を管理するWordPressと、読者が見る画面を分ける構成です。ただし、分け方によって安全性も運用負担も変わります。

構成1：読者のブラウザから公開中のWordPress APIを呼ぶ

読者のブラウザ ──→ WordPress REST API ──→ PHP・DB

表示画面を分けても、読者側からWordPressのAPIへ到達します。公開してよい記事データと、認証が必要な操作を厳密に分けなければなりません。元サーバーも外部公開されたままなら、攻撃対象を減らす効果は限定的です。

構成2：表示用サーバーだけがWordPress APIを呼ぶ

読者 ──→ 表示用サーバー ──→ 非公開のWordPress API ──→ PHP・DB

WordPressの元サーバーを非公開にし、表示用サーバーだけが接続できれば、公開範囲を絞れます。一方、常時稼働する表示用サーバーはWordPressへ接続する認証情報を持ちます。新たに必要になるのが、表示用サーバー、API認証、秘密情報の管理です。

構成3：更新時にページを生成し、CDNから静的配信する

編集者 ──→ 非公開のWordPress
                 ↓ 更新時だけ取得
            ビルド・公開処理 ──→ CDN ──→ 読者

普段の閲覧経路からWordPressとPHPを外せるため、公開面を最も小さくしやすい構成です。その代わり、記事更新から公開までにビルド処理が入り、失敗時の通知、再実行、ロールバックが必要になります。

Next.jsのISR（Incremental Static Regeneration）は、生成済みページをキャッシュしながら更新できる仕組みです。すべてをファイルとして書き出す構成とは違い、Next.jsの公式文書が説明するサーバーキャッシュ、再検証、複数インスタンス間の整合性も管理します。

評価すべきなのは、読者からWordPressへ至る経路が残っているか、更新処理を誰が維持できるかです。

ヘッドレス化を選ぶ場合、「WordPressをセキュアな環境に置く」とは何か

ヘッドレス化を選び、WordPressを裏側へ置くときは、次の対策を一つのまとまりとして設計します。

対策	実務で確認すること
更新	PHP、WordPress、プラグイン、テーマ、OSを更新する。公開制限は脆弱性修正の代わりにならない
元サーバーの隔離	VPN、アクセスプロキシ、IP制限などで編集者とビルド環境だけに接続を絞る。CDNやWAFを迂回できないことも確認する
権限と認証	管理者を最小限にし、多要素認証を使う。APIは読み取りと更新の権限を分ける
不要機能の削減	未使用のプラグインとテーマを削除し、XML-RPC、コメント、外部APIを必要な範囲に絞る。REST APIの全面停止は避ける
秘密情報と連携	認証情報をコードへ入れず、連携ごとに発行・更新する。Webhookは署名、回数制限、再送対策を確認する
復旧	DB、画像、設定、表示側コード、公開済み成果物を保存し、復元を試す
監視	不審なログイン、APIエラー、ビルド失敗、改ざん、更新失敗を誰が確認するか決める

認証付きAPIでは主パスワードを共有せず、取り消し可能なApplication Passwordを連携ごとに使えます。個別発行・失効・更新はWordPress公式文書、二段階認証と管理画面でのファイル編集停止はHardening Guideが解説しています。

ヘッドレス化で減るリスクと、新しく増えるリスク

ヘッドレス化は、リスクを消す施策ではありません。リスクの置き場所を変える施策です。

減らしやすいリスク

読者からWordPress、PHP、DBへ直接到達する経路
WordPressテーマ側の表示処理に対する攻撃
公開ページへの大量アクセスがWordPressへ直接届く負荷
サイト改ざんがそのまま公開画面へ反映される可能性

新しく管理するリスク

Next.jsなど表示側フレームワークの脆弱性
Node.jsとnpmパッケージ、間接依存を含む更新
Gitリポジトリ、CI/CD、ビルドサービスの権限
APIキー、Application Password、Webhook署名鍵の漏えい
キャッシュが更新されず、古い内容を配り続ける問題
ビルド失敗で記事を公開・修正できない問題
WordPressと表示側で監視・障害対応が二重になる負担

OWASP Top 10:2025は、依存ライブラリだけでなく、ビルドシステムや配布基盤を含むソフトウェア供給網の失敗を主要リスクに挙げています。WordPressのプラグインを減らしても、表示側で管理できない依存関係を増やせば、全体の安全性が上がるとは限りません。

最も安全なのは、最も新しい構成ではありません。責任者が把握し、更新し、異常時に戻せる構成です。

通常運用、管理型、ヘッドレス、移行のどれを選ぶべきか

選択肢は「WordPressを続けるか、捨てるか」の二つではありません。

選択肢	合う状態	主な利点	主な注意点
通常のWordPressを堅牢化	動的機能が多く、社内または保守会社に更新担当がいる	構成が比較的単純。既存機能を維持しやすい	公開面が広くなりやすく、継続的な更新が必須
管理型WordPressへ移す	自社でサーバー管理を抱えたくない	PHPや基盤更新を契約範囲に含めやすい	サービスごとに責任範囲、制限、復旧条件が違う
実行時API型ヘッドレス	アプリ連携、リアルタイム情報、個別表示が必要	表示設計の自由度が高い	常時稼働する表示側とAPI認証を管理する
静的配信型ヘッドレス	会社案内、採用、記事、事例など公開情報が中心	閲覧経路からWordPressを外しやすい	ビルド、プレビュー、キャッシュ、公開失敗を管理する
WordPress以外へ移行	WordPressの編集画面や既存資産を残す理由が少ない	必要機能に合わせて構成を単純化できる	移行、教育、URL、データ変換の負担がある

判断を短く整理すると

WordPressの編集画面と既存記事を残す必要がない
他CMSや静的サイトも含めて比較します。
EC、会員、予約、個別表示などの動的機能が多い
通常のWordPress、管理型WordPress、実行時API型を中心に検討します。
会社情報、採用、記事、事例が中心で、公開面を小さくしたい
静的配信型ヘッドレスが候補になります。
ビルド、公開、Node.js、依存関係を管理する担当がいない
ヘッドレス化を急がず、管理型WordPressや現行構成の堅牢化を優先します。

セキュリティへの不安だけでヘッドレス化を選ぶと、運用できない仕組みを増やすおそれがあります。編集体験、必要機能、公開速度、障害対応、数年分の運用費まで含めて判断してください。

ヘッドレス化するとSEOは良くなるのか

ヘッドレス化だけで検索順位が上がることはありません。表示速度を改善しやすい一方、SEOに必要な処理を表示側で実装し直す必要があります。

既存URLを維持する。変更する場合は301リダイレクトを設定する
ページごとのtitle、meta description、canonicalを出力する
XMLサイトマップとrobots設定を引き継ぐ
Article、BreadcrumbListなど必要な構造化データを出力する
下書き、公開日時、更新日時、カテゴリー、タグを移行する
404とリダイレクトを公開前に一覧で確認する
本文と主要リンクを初期HTMLへ含める

Google Search Centralは、GoogleがJavaScriptを実行できる一方、利用者とクローラーの速度や、JavaScriptを実行できないボットを考慮し、サーバー側レンダリングまたは事前レンダリングを推奨しています。

既存記事とURLを保てるかどうかは、WordPressかヘッドレスかより、移行設計の精度で決まります。

制作会社・保守会社へ確認したい12項目

構成変更を決める前に、現在の管理会社や制作会社へ次の質問を送ってください。

今回のPHP脆弱性への修正は、どのサーバーへ、いつ適用されたか？
PHP、OS、WordPress本体、プラグイン、テーマの更新責任は誰にあるか？
緊急脆弱性では、何時間または何営業日以内に確認・対応する契約か？
管理画面、REST API、XML-RPC、元サーバー、DBはどこから到達できるか？
使用中・未使用のプラグインとテーマを一覧にできるか？
管理者権限とAPI用認証情報を持つ人・システムは何件あるか？
バックアップ対象、保存先、保存期間、最後の復元テスト日は？
改ざん、ログイン異常、更新失敗、ビルド失敗を誰が検知するか？
ヘッドレス化する場合、ブラウザ・表示用サーバー・ビルドのどこからWordPressへ接続するか？
Node.js、表示側フレームワーク、npm依存関係は誰が更新するか？
URL、リダイレクト、メタ情報、構造化データをどう引き継ぐか？
通常WordPress、管理型WordPress、静的配信型、他CMS移行を同じ条件で比べたか？

答えが曖昧な項目は、そのまま構成を変えても残る運用上の弱点です。

よくある質問

WordPressは危険なCMSなのでしょうか

WordPressだから一律に危険とは言えません。PHP、WordPress本体、プラグイン、テーマ、サーバー設定、認証、監視、更新体制の組み合わせでリスクが変わります。更新責任や公開範囲が分からない状態は見直しが必要です。

ヘッドレスWordPressにすれば、今回のPHP脆弱性を回避できますか

回避策にはなりません。WordPressの元サーバーではPHPが動くため、修正版への更新が必要です。静的配信によって普段の閲覧経路からWordPressを外せば公開範囲は減らせますが、脆弱なPHPを残してよい理由にはなりません。

WAFやセキュリティプラグインがあればPHP更新を待てますか

今回の件では推奨できません。PHP公式は、更新だけが完全な解決だとしています。WAFなどは特定の攻撃経路を減らす補助策であり、修正版への更新を置き換えません。

REST APIはすべて止めたほうが安全ですか

一律停止は適切ではありません。WordPressの管理画面やプラグインもREST APIを利用します。公開記事の読み取り、管理操作、外部連携を分け、不要な経路と権限を減らします。

既存の記事やURLは残せますか

設計すれば残せます。記事、カテゴリー、タグ、画像、SEO情報を移行し、同じURLで表示できます。ただし、ショートコードやプラグイン独自データは個別確認が必要です。

ヘッドレス化すると費用は下がりますか

一般には、初期構築と運用対象が増えます。サーバー負荷や障害影響を減らせる場合はありますが、WordPressと表示側の両方を更新する費用、ビルド、監視、プレビュー、障害対応を含めて比較する必要があります。

まとめ：更新と復旧を続けられる構成を選ぶ

今回のPHP脆弱性への答えは、修正版への更新です。その後の選択肢として、現在の構成の堅牢化、管理型WordPress、ヘッドレス化、他CMSへの移行を同じ条件で比べます。

公開情報が中心で、WordPressの編集資産を残しながら閲覧経路を分離したい場合、静的配信型のヘッドレスWordPressは有力な選択肢になります。一方、動的機能が多い、または二つのシステムを運用できない場合は、通常構成の堅牢化や管理型WordPressのほうが合理的です。

SIMCODEの公式サイトでは、記事管理をWordPressに残し、表示側をNext.jsで分けています。既存記事、カテゴリー、タグ、画像、URLを維持しながら構成を移した考え方は、「Next.js × ヘッドレスWordPressで構築した、スクロール連動動画サイトリニューアルの実装設計」にまとめています。

これはすべての会社に勧める構成ではありません。通常WordPress、管理型WordPress、ヘッドレス、他CMSを同じ条件で比べ、自社が更新と復旧を続けられる構成を選ぶことが、長期的な安全性につながります。