WordPressのセキュリティリスクと保守コストを下げる、2つの移行先
PHP2Shellの脆弱性で明らかになった、WordPress保守の構造的な負担。保守範囲を極小化する2つの移行先を、エンジニアでない方向けに解説します。

2026年10月21日、プログラミング言語のPHPに「PHP2Shell」と呼ばれる脆弱性が公表されました。
ログインすら必要とせず、サイトを乗っ取れてしまうという内容です。
WordPressはPHPの上で動いています。
この脆弱性の影響を、そのまま受けることになります。
WordPressは、守るべき場所が4つある
WordPressは、本体・プラグイン・PHP・サーバーという4つの場所を、すべて最新の状態に保ち続ける必要があります。
しかも、すべてを最新にしていても、新しく見つかった欠陥が原因で入られることがあります。
守る場所が多いということは、穴ができやすい、ということでもあります。
その保守、本当に回っていますか
ホームページを制作会社に依頼して作った場合、保守契約を結んでいなければ、脆弱性が見つかっても更新はしてもらえません。別途、保守作業の依頼が必要です。
更新そのものも、ボタンひとつでは済みません。
バックアップを取り、影響がないか調べ、更新し、きちんと動くか確認する。この4つを、ひとつずつ実施する必要があります。
そのため、原則として無料で保守対応ができる作業ではありません。
責任ある制作会社ほど、保守対応の必要性をきちんと説明し、正当な対価を示したうえで保守契約を結びます。
放置していたサイトほど、今回の対応が重くなった
今回のPHP2Shellの修正自体は、バージョンの枝番を上げるだけの小さな修正です。
ただし、サポートが切れたバージョンのPHPを使っているサイトには、この小さな修正が提供されません。
その場合、サポートされている新しいバージョンまで、一段上の大きなアップデートが必要になります。
PHPのバージョンを大きく上げると、WordPress本体や使っているライブラリも、合わせて新しくする必要があります。
影響する範囲が一気に広がり、動かなくなった箇所の修正や、別の仕組みへの置き換えが必要になります。
日頃の保守を怠ってきたことの帰結が、今回の対応で、はっきりと見える形になりました。
保守そのものを小さくする、という発想に変える
ここまでの話を踏まえると、守る範囲を極小化した構成に移行することが、セキュリティリスクと保守コストを構造的に下げることにつながります。
これを機に、一度見直していただきたいと思っています。
私が推奨する方法は2つあります。
ひとつは、WordPressから静的サイトへ移行する方法です。
もうひとつは、WordPressを残しながら、外からは見えない状態にする方法です。
静的サイトは、サーバー側の攻撃される面を極小にする
静的サイトとは、HTML・JavaScript・CSS・画像など、ブラウザに直接配信されるファイルだけで構成されたサイトのことです。
サーバー側で動くプログラムがないため、サーバーへの攻撃経路がWeb上に公開されません。
公開されているサイトを足がかりにした侵入は、構造的に起こりにくくなります。
ただし、リスクがゼロになるわけではありません。
ホスティングやドメインの管理アカウント、埋め込んだ外部サービスなど、別に守るべき場所は残ります。
更新が少ない、またはAIに任せられるなら「静的化」
更新のほとんどをAIエージェントに任せられる、あるいは更新自体がほとんど発生しないサイトであれば、丸ごと静的サイトに移行する方法が合います。
管理画面は持ちません。更新するときは、AIや制作会社にページを作り直してもらいます。
複数人で記事を更新する必要がある場合は、「EmDash(エムダッシュ)」という選択肢があります。
こちらはWordPressのように管理画面を持ち、権限を分けて記事を管理できます。
下書き、確認、予約投稿、公開という運用の流れが必要な場合や、AIを使わずに管理画面上で記事を書きたい場合は、この方法が向いています。
一方でAIエージェントを使って更新することもできるので、柔軟な運用が可能です。
WordPressを残したいなら、「隠す」という選択肢もある
今までとほぼ同じようにWordPressで管理したい場合は、「Shifter」というサービスへの移行が選択肢になります。
訪問者からは静的サイトに見えるため、攻撃できる経路が限定されます。
WordPressの操作を行いたい時だけ、サービス経由でアクセスします。
サーバーの管理もサービス側に任せられます。
実際に今回のPHP2Shellへの対応でも、Shifterは当日中にPHPの更新を終えています。
メンテナンス中はWordPressの管理画面を操作できない時間がありましたが、公開しているサイト自体は影響を受けませんでした。
参考: PHP2Shell対応に関するお知らせ(Shifter公式ブログ)
一部、制約もあります。サービス特性上、適さないユースケースもあります。
問い合わせフォームなどは、そのままでは動かないため、変更が必要です。
まずは、サイトの状態を一緒に確認しませんか
ご自身のサイトのセキュリティがどれくらい大丈夫か、どちらの移行パターンが当てはまるか、実際に移行を相談できるか。
状況がよく分からなくても、相談の仕方が分からなくても構いません。
対象のサイトが分かれば、こちらで確認して、最適な構成をご提案します。
ご相談・ご依頼は、FlowCraftの相談フォーム からお願いします。