WEB DESIGN CODE
Yas codeの坩堝

Webサイト運用

「PHPが危ないからWordPressは終わり」は、そんな事ありません

「PHPが危ないからWordPressは終わり」は、そんな事ありません

2026年10月21日の夜、PHPの重大な脆弱性への対応で、レンタルサーバー各社がメンテナンスを行いました。そのあと、「PHPが危ないのだから、WordPressはもう終わりだ」という言い方が、また目につくようになりました。さらに進んで、「AIに自分だけの言語を作らせれば、世界の誰にも読まれないから漏れない」と言う人もいます。

この2つは、響きは強いのですが、サイトを預かり、更新し、障害のときに直す側の説明とはずれています。この記事では、WordPressとPHPを分けて整理し、Next.jsや静的なHTMLに替えても保守が消えない理由、発注する側が制作前に聞いておきたいことを書きます。筆者はフリーランスのWebディレクター兼エンジニアとして、WordPressと、Next.jsを使ったサイトの両方を扱っています。

ネットの「オワコン説」と、自分だけの言語という話

「PHPは古い」「WordPressは穴が多いから乗り換えるべきだ」。10月のメンテナンスのあと、この言い方を目にすることが増えました。
その言い方には、一理あるが、万能な答えではないという事、全てのプロジェクトに当てはまるわけではありません。

さらには、「AIに独自の言語を作ってもらい、自分しか読めないコードにすれば、攻撃者にも読まれない」という空想を提案する人間もいます。

前半には、事実の種があります。PHPにはサポートの期限があり、期限を過ぎたバージョンは、開発元からの修正が出ません。2026年10月21日には、認証なしで外部から命令を実行されるおそれがある脆弱性2件（CVE-2026-109618、CVE-2026-109619）の修正版が公開されました。ここまでは、PHPの公式発表とIPAの事前告知で確認できる話です。

ずれているのは、その次です。PHPに弱点が見つかったことと、WordPressというCMSをやめることは、同じ判断基準ではありません。WordPressはPHPで動きますが、PHPの不具合は、PHPで動くフォーム、独自の管理画面、業務システムにも同じように関わります。開発言語を替えても、サイトやサービス、システムが稼働している以上、点検は絶対必要です。

後半の「自分だけの言語」は、守りとしても事業としても通りにくい説明です。攻撃者は、ソースコードの言語名を読んでから入るわけではありません。動いているサーバーに対して、決まった形のリクエストを送り、反応を見ます。読めないコードは、攻撃を遠ざける保証にはなりません。読める人が社内に一人しかいない状態は、その人が休んだ日、辞めた日、意見が割れた日に、直し手がいない状態です。

悪い説明：AIに独自言語を作らせれば、自分しか読めないので漏れません。

改善した説明：言語を隠しても、公開している入口は存在しています。読める人が複数いて、修正版を当てる手順がある方が、スピード感もあり、また問題が起きた場合に手戻りも可能です。

新しい言語を一度も本番で使ったことのないまま、「これなら絶対に漏れない」と言い切るのは、運用の話ではなく想像の話です。想像を否定したいのではありません。発注の判断に使うには、動かしている人が複数いるか、止まったときに誰が直すかまで含めて見る必要がある、という話です。

もう一つ、発信する人の肩書きと、運用の経験は別です。元エンジニアの経営者、コンサル、士業の方が技術の話をすること自体は珍しくありません。ただ、本番のサーバーでPHPを上げ、止まった画面を戻した経験と、解説記事を読んだ感想は、精度が違います。

WordPressの問題と、PHPの問題は別です

WordPressは、CMSの利用状況を調べているW3Techsの2026年10月27日時点の集計で、調査対象の全サイトの39.6％、CMSが判明しているサイトの58.3％を占めています。1年前の2025年10月1日は全サイトの43.3％だったので、割合は下がっています。それでも、同じ集計で2位のShopifyは5.3％です。規模が大きいこと自体が安全だ、とは言えません。ただ、テーマ、プラグイン、レンタルサーバーの対応、困ったときの情報の量が、小さいCMSとは違う、というのは事実です。

開発も止まっていません。WordPress 7.1は2026年8月19日に公開され、ホスティング向けの互換表ではPHP 8.2から8.5が並んでいます。6.9については、PHP 7.4、8.0、8.1、8.2、8.3、8.4、8.5に対応すると公式のホスティング資料に書かれています。ただし7.4、8.0、8.1はPHP側のサポートが終わっていて、WordPressは互換のために残しているだけです。本番ではPHP 8.3以降が推奨されています。

つまり、WordPress本体は「PHPを上げられない理由」にはなりにくい、ということです。上げられない現場で繰り返すのは、本体の外側です。何年も更新されていない自作プラグイン、親テーマの関数をそのまま上書きした子テーマ、管理画面の外に置いた独自のPHP、データベースへ古い書き方で接続している処理。PHP 8で削除された関数を、こうしたコードがまだ呼んでいると、本体を新しくしても画面が止まります。

WordPress.orgに更新確認で接続しているサイトのPHPを、外部の集計（SnowDriven、2026年10月26日、出典はWordPress.org）で見ると、サポートが終わったPHPの割合は33.8％です。PHP 7.4だけでも15.2％あります。この数字は「WordPressが古いPHPを強いている」という訳ではありません。本体が新しいPHPに対応したあとも、周囲のコードとサーバーの設定が追いついていないサイトが残っている、と読むのが正しいです。

納品の時点では動いていて、その後のPHP更新を契約に入れていなかった、というケースも現場では繰り返します。原因をCMSの名前に寄せる前に、止まっているのが本体なのか、プラグインなのか、自作のPHPなのかを分ける方が、次の発注に活きます。

Next.jsや静的HTMLに替えても、保守は残ります

「ではWordPressをやめて、Next.jsやAstro、静的なHTMLにすれば安全か」という質問も、セットで出てきます。公開されるページが、リクエストのたびにPHPで組み立てられない構成には、確かに減るリスクがあります。問い合わせのたびにサーバー上のPHPが動かないなら、PHPのその脆弱性は、そのページには届きません。

ゼロにはなりません。2026年10月だけを見ても、PHP以外で修正版が出ています。

Next.jsは10月14日、画像最適化でSVGを処理する経路の脆弱性（CVE-2026-96889）などを公開し、15.5.28と16.4.1で修正しました。影響を受ける範囲には10系から15.5.27までが含まれ、認証なしでコードを実行されるおそれがあるとされています。条件は「Next.jsがglibc系のLinuxで画像を処理する」などで、すべてのサイトが同じ影響を受けるわけではありません。それでも、「新しいフレームワークだから今回のPHPとは無関係」では済みません。

Node.jsは10月21日、Brotli形式の展開処理における脆弱性（CVE-2026-111497）を含む更新を出しました。修正版は22.23.4、24.22.1、26.12.1です。Node.js 20はサポートが終わっており、この修正は出ません。Next.jsのサイトは、このNode.jsの上で動きます。

静的なHTMLやAstroは、ページそのものにサーバー側のプログラムを置かないことができます。W3Techsの同じ時期の集計では、Astroは全サイトの0.2％です。割合が小さいことと、安全であることは別です。フォームの送信先、会員のログイン、決済、解析タグ、チャットの埋め込みは、静的なページの外に処理を持ちます。そこが止まれば、見た目はHTMLのままでも、問い合わせは届きません。CDNの設定ミスや、管理画面のパスワードの使い回しも、言語では防げません。

乗り換えを否定しているのではありません。筆者自身、案件によってWordPressとNext.jsを使い分けています。選ぶ基準は「名前が新しいか」ではなく、更新する人、直す人、止まったときの戻し方が、納品のあとも残るかです。

静的なページにしたあとに残る作業の例を挙げます。お問い合わせは、見た目がHTMLでも、送信先のAPIやメールの設定が別途必要です。アクセス解析のタグは、提供元がスクリプトを更新します。管理用のパスワードを共有していれば、言語とは関係なく入られます。構成を変える提案を受けたときは、「PHPが無くなる」ことと、「保守の項目が無くなる」ことを、別で確認してください。

発注前に聞いておきたいことと、保守の置き方

経営層が技術の名前を覚える必要はありません。代わりに、納品のあとに誰が手を動かすかを、制作前に聞いておくと、あとから「バージョンアップできない」が減ります。現場で差が出るのは、次のような質問です。

  1. テーマとプラグインは、何を基準に選び、誰が更新しますか。公式のディレクトリで更新が続いているものか、制作者だけが直せるものかで、PHPを上げるときの手間が変わります。
  2. PHPやフレームワークの修正版が出たとき、どのタイミングで当てますか。サーバー会社が自動で上げるのか、事前に検証してから上げるのか、止まったときの連絡先はどこか。
  3. そのサイトを直せる人は、制作者以外にいますか。自作の処理が多いほど、その人が不在のときに戻せません。WordPressの更新の仕組みに乗せている部分と、乗せられない部分を、納品時にリストでもらうと後から追えます。

悪い依頼：いつものやり方で、管理しやすいサイトをお願いします。保守は何かあったときでいいです。

改善した依頼：公開後のPHP更新と、テーマ・プラグインの更新を、月次で見る契約に含めてください。自作した処理は一覧にし、制作者以外でも直せる範囲を書いてください。

契約の置き方も、2種類に分かれます。一つは、画面が止まってから電話する契約です。直るまでの時間は、その日の予定と、コードを読めるかで変わります。もう一つは、修正版が出た週に、テスト環境で動かしてから本番へ反映する契約です。10月のPHPのように、公開から攻撃の話が広がるまでの時間が短いときは、後者の方が先に動けます。

費用だけを比べると、後者は高く見えます。比べる相手は、月額ではなく、止まった日に失う問い合わせと、情報を漏えいしたあとの連絡です。全部を制作会社に任せる必要はありません。サーバーのPHPはサーバー会社、本体とプラグインは制作会社、という分担でも足ります。分担が書面になっていないことが、止まったあとに時間を使います。

契約に書いておきたい項目は、多くありません。対象のサイト、見る周期、PHPと本体とプラグインのどれを見るか、テスト環境の有無、止まったときの連絡手段と目標時間、対象外にするもの。対象外を書くのが大事です。独自の会員機能や、外部の予約サービスまで含むのかで、見積もりも動き方も変わります。「一式で見ておく」だけだと、10月のような日に、どこから手をつけるかが決まりません。

未発見の不具合は残る。差が出るのは直る速さです

どの言語にも、どのフレームワークにも、まだ見つかっていない不具合が残っていることはあります。「穴が一つもないものに乗り換える」という選び方は、存在しない行き先を探すことになります。

差が出るのは、見つかったあとの速さです。利用者が多く、不具合を受け付ける窓口があり、修正版を配る仕組みがあるソフトウェアは、見つかった弱点が直るまでの期間が短くなりやすいです。WordPressも、PHPも、Next.jsも、Node.jsも、2026年10月に修正版を出しています。出たあとに当てる人がいるかどうかが、サイトごとの差です。

恐れ方を変えると、発注の見る場所も変わります。CMSの名前で安心するのでも、CMSの名前で避けるのでもありません。今のPHPは何か、誰が更新するか、自作の処理はどれか。この3つが答えられるサイトは、次のメンテナンスでも止まり方を小さくできます。

AIの時代になっても、この順番は変わりません。AIはコードの下書きを速くしますが、公開しているサーバーの修正版を当てる役ではありません。生成したコードを、読める人がレビューし、更新の一覧に載せる。その手間を省いたサイトほど、次のPHPやNode.jsの更新で止まりやすくなります。正しく恐れる、とは、名前で避けたり、名前で安心したりせず、直る仕組みが手元にあるかを見ることです。

自社のサイトがどのPHPで動いているか、WordPressの外に古い処理が残っていないかを、一度洗い出したい場合は、お問い合わせからご相談ください。

参考情報