WordPressから静的HTMLへ移行すべきか PHP脆弱性とAIエージェント時代の答え

10月21日の夜、高市首相がXで「今夜に対応して頂きたい大至急のお願い」と呼びかけました。PHPというプログラミング言語に重大な脆弱性が2件見つかり、修正版が日本時間の23時に出るので、すぐに当てる準備をしてほしい。当てるのが難しければ、サイトを一時的に止めることも有効策の一つだ、という内容です。実際に財務省などが、PHPで動く一部のページを一時停止しました。

この騒ぎのあと、Xでは「WordPressはもう終わり」「静的HTMLで十分」という投稿が目立ちました。実際に移行を考え始めたという声もあります。

筆者の答えを先に書くと、更新の少ない名刺代わりのサイトなら、静的HTMLへの移行はありだと思います。ただ、ブログやお知らせのように記事が増え続けるサイトを、手書きのHTMLにするのはおすすめしません。そして、どちらを選ぶにしても、AIエージェントの存在を前提に考え直す時期に来ていると思います。静的なサイトのいちばんの弱点だった「更新の手間」が、大きく変わったからです。

狙われたのはWordPressではなくPHP。WordPressを更新しても直らない

PHPの公式の発表によると、10月21日に公表された脆弱性は2件で、どちらもログインなしで外からサーバー上のプログラムを動かされる恐れがあるものです。深刻度はどちらもCVSS 9.2(10点満点)。PHP-FPMやApacheのmod_phpなど、Webのリクエストを処理しているPHPはすべて対象で、修正版は8.5.12、8.4.27、8.3.36、8.2.35です。8.1以前には、PHPのプロジェクトから通常の更新版は出ません。今回は深刻さを踏まえて、7.4から8.1向けに最小限の修正のソースが公開され、OSの配布元などが独自に修正を出す場合もある、とされています。

10月23日には、追加の告知も出ました。特殊な設定とプログラムの組み合わせでしか起きない別の経路(CVE-2026-115560)で、次の定期の更新で直す予定です。それまでの備えとして、セッションのアップロード進捗の機能を切っておくよう勧めています(動いている途中でセッションの保存形式を切り替えないアプリなら、対象外とされています)。修正版にしたから終わり、ではなく、サーバー会社の最新の案内まで見ておく必要があります。

国内ではIPAとJPCERT/CCが注意喚起を出しています。実際に攻撃が成功したという公的な発表は、この記事を書いている10月25日の時点で見当たりません。ただ、Amazonは、公表前の10月17日から攻撃の試みを観測していたと発表しています。

押さえておきたいのは、問題がWordPressではなくPHPにあることです。WordPressの公式の発表も、今回の脆弱性はWordPress固有のものではなく、WordPressの更新は必要ないし予定もない、と明言しています。WordPressやプラグインを最新にしても、PHPが古いままなら直りません。逆に、WordPressを使っていなくても、PHPで動くサイトなら同じように対象です。

「世界のWebサイトの7割はPHP」という話もよく見かけますが、W3Techsの69.2%という数字は、「サーバー側の言語がわかるサイトのうち」の割合で、全サイトの7割という意味ではありません。そのPHPのサイトの中で最大の勢力がWordPressで、全サイトの39.6%を占めます(どちらも2026年10月25日に確認)。

ここまでが公式の発表で確かめられる事実です。ここから先は筆者の考えになります。WordPressが話題の中心になったのは、利用するサイトがそれだけ多いことが大きいと思います。

静的HTMLが強いのは、アクセスのたびに動くプログラムがないから

WordPressのサイトでは、キャッシュされていないページを誰かが開くと、サーバーの上でPHPのプログラムが動き、データベースから記事を取り出してページを組み立てます。今回の脆弱性は、PHPがWebのリクエストを処理する、その経路から届くものでした。

静的HTMLは、できあがったページのファイルを、そのまま返すだけです。HTMLはページの構造を書くための文書の形式で、サーバーの上で何かを計算するプログラムではありません。だから、PHP2ShellのようにPHPの実行環境を狙う攻撃は、入口そのものがなくなります。公開しているサイトにデータベースもログイン画面もなければ、そこを総当たりされる心配もありません。

ただ、静的HTMLにすれば安全、というほど単純ではないと思います。入口がなくなるのはサーバーの上のプログラムで、ほかの入口は残るからです。

一つは、ページを見に来た人のブラウザです。HTMLのページの中では、たいていJavaScriptが動いています。

• 作りの甘さ: 外から入ってきた文字列をそのままページに埋め込むと、他人のスクリプトが動いてしまうことがあります(XSSと呼ばれる攻撃です)
• 古い部品: 古いJavaScriptのライブラリを使い続けると、知られた脆弱性が残ります
• 外から読み込むスクリプト: 解析タグや広告、便利なライブラリを外部のサーバーから読み込んでいると、その配信元が乗っ取られたときに巻き込まれます。2024年には、polyfill.ioというJavaScriptの配信元が持ち主ごと変わり、読み込んでいたサイトの閲覧者が別のサイトへ飛ばされる事件がありました

もう一つは、サイトを公開する側のアカウントです。ファイルを置いているGitHubやホスティングのサービス、ドメインの管理画面に入られれば、静的なサイトでも中身を書き換えられます。公開サイトのログイン画面がなくなっても、こちらのパスワードと二段階認証は欠かせません。

フォームも同じです。HTMLだけでは、送信された内容を受け取る先がありません。外部のフォームサービスを使えば、受け取る仕組みはその会社に任せられますが、どのサービスを選び、集めた個人情報をどう扱うかの責任は、使う会社に残ります。自前で受け取るなら、そこはサーバーでプログラムが動く入口になります。

静的HTMLの弱点だった「更新の手間」は、AIエージェントで大きく減った

それでも多くの会社がWordPressを選んできたのは、更新が楽だからだと思います。管理画面にログインして、文章を書いて、公開ボタンを押す。静的HTMLだと、こうはいきませんでした。1か所直すにも、ソースを開いて、該当の箇所を探して、直して、ブラウザで見た目を確かめて、FTPでサーバーに上げる必要があります。

この手間を減らしたものは、3つに分けて考えるとわかりやすいと思います。

• FTPをなくしたのは、公開の仕組み: VercelやCloudflare Pagesのようなサービスなら、コマンド1つで直接公開できますし、GitHubにファイルを送って自動で反映させることもできます。これはAIの登場より前からある仕組みです。GitHubを通すと変更の履歴が残り、問題があればすぐ前の状態に戻せるので、当社はこちらを使っています
• ページをまたぐ修正をなくしたのは、ビルドの仕組み: 記事を1本足せば、一覧やサイトマップが自動で作り直されます(次の章で触れます)
• ソースを探して直す手間を減らしたのが、AIエージェント: Claude CodeやCodexに「お知らせを1本追加して」「この一文を直して」と頼めば、ソースの中から該当の場所を探し、直し、ビルドしてプレビューで確かめるところまで進めてくれます

最後のひとつが加わったことで、HTMLやコードを書けない人でも、静的なサイトを更新できるようになりました。筆者は、ここがこの1年でいちばん大きな変化だと思っています。

当社のサイトはNext.jsで作っていて、ブログの記事はMarkdownのファイルです。GitHubと自動の公開の仕組みを最初に整えてあるので、執筆、画像の作成、第三者の目でのレビューまでをAIエージェントと回し、原則1日1本のペースで公開できています。

10月24日には、ブログに出していた相談窓口のバナーとポップアップを外すと決めました。関係するファイルを探して消し、説明の資料まで直す作業はCodexに任せ、数分で終わっています。ただ、人の仕事がなくなったわけではありません。外すかどうかを決めたのは私ですし、AIがビルドを通したあと、変更の中身を確かめ、プレビューで目で見てから、私がOKを出して公開しています。AIが引き受けたのは、ファイルを探して直す手作業の部分です。

それでも、手書きのHTMLを勧めないサイト

AIで更新が楽になったからといって、どんなサイトも手書きのHTMLにすればいい、とはならないと思います。

記事が増え続けるサイトでは、記事のページだけでなく、一覧、カテゴリやタグのページ、関連記事、検索、サイトマップまで、記事を1本足すたびにあちこちを直す必要があります。手書きのHTMLでこれをやると、AIに頼んだとしても、直すファイルが記事の数だけ増えていきます。どこか1か所で直し忘れれば、一覧に載らない記事ができる。たくさんの商品や事例のような、形の揃ったデータを並べるサイトも同じです。

こうしたサイトに向くのは、記事や商品の中身をMarkdownやデータのファイルで持ち、ビルドのときに静的なページへ書き出す仕組みです。当社のサイトもこの形で、一覧やタグのページは記事のファイルから自動で作られます。見に来た人が開くページは書き出したHTMLなので、そのページについては、アクセスのたびにサーバーでプログラムを動かさずに済みます。Next.jsのほか、Astroのような同じ役割の仕組みもあります。

移行の前に考えておきたいことも、いくつかあります。

• URLが変わると、検索の評価を失うことがある: 古いURLと新しいURLの対応を用意して、転送の設定をします。規則で置き換えられないURLは、個別に設定が要ります
• フォームの受け取り先: 外部のサービスにするか、自前で作るかを決めます
• 更新と公開を誰が担うか: AIエージェントに頼む人が、公開の操作と公開前の確認をできるか。社内の誰が見てもわかる管理画面がない、という代償はあります

脆弱性への対応もAIで速くなる。ただし入口がなくなるわけではない

当社のようなNext.jsのサイトは、静的HTMLと比べてどうなのか。サイトの側で動くものに絞って並べると、こうなります。

	アクセスのたびに動くプログラム	データベース	管理画面
一般的なWordPress	キャッシュされていないページで動く	あり	あり
当社のサイト	フォームの受け取りなど一部だけ	なし	なし
HTMLだけのサイト	なし	なし	なし

当社のサイトは、ページの大半をビルドのときにHTMLとして書き出していて、PHPも使っていないので、今回の脆弱性の影響はありません。ただ、問い合わせや診断、資料の申込のフォームを受け取る部分は、アクセスのたびにサーバーでプログラムが動きます。静的HTMLの章で挙げた、見に来た人のブラウザと公開する側のアカウントという入口は、どの形でも残ります。当社も解析のタグを外から読み込んでいます。

そしてNext.js自体にも、2025年12月に深刻度10.0(最高点)の脆弱性が見つかっています。React Server Componentsという仕組みの通信の処理にあった問題で、App Routerを使うNext.js 15・16のアプリが対象でした。当社のサイトもApp Routerを使っています。2026年6月に、すでに直ったバージョンで作ったので影響はありませんでしたが、「Next.jsだから安全」とは言えません。

違いが出るとすれば、脆弱性が見つかったあとの動きだと筆者は見ています。当社のように、部品の一覧(package.json)とビルドの仕組みがリポジトリにまとまっていれば、AIエージェントに「このサイトは対象か調べて、対象ならバージョンを上げて、ビルドが通るか確かめて」と頼めます。調べて直すまでの手作業を、AIに任せられるわけです。WordPressでも、契約しているサービスによってはサーバー会社がPHPを更新してくれますし、本体やプラグインの自動更新もあります。何を自動で更新してくれる契約なのかは、一度確かめておく価値があります。どちらが速いかは、仕組みの違いよりも、誰がどこまで面倒を見る体制になっているかで決まると思います。

AIに任せるなら、守っておきたいこともあります。AIが直したものを、人が中身を確かめずに公開しないこと。当社では、記事もサイトの変更も、公開の前に必ず私がOKを出す決まりにしています。AIが速く直せるということは、間違いも速く公開できてしまうということでもあるからです。

最後に、移行を決める前にまずやること

どんなサイトに何が向くかを、筆者の考えでまとめるとこうなります。

サイトの使い方	向く形	前提
会社の紹介と連絡先だけ。更新は年に数回	静的HTML。更新はAIエージェントに頼む	公開先のサービス(VercelやCloudflare Pagesなど)を扱える担当者か、保守を頼める会社がいる
ブログやお知らせ、事例を増やしていく	ビルド時にページを書き出す仕組み(Next.js、Astroなど)+AIエージェント	同上。加えて、公開前に変更を確かめる人がいる
社内の何人もが、管理画面から更新したい	WordPressを続けて保守を徹底するか、外部のCMSサービスを使う	PHPやプラグインの更新を誰が受け持つかが決まっている

そのうえで、移行を考えるより先にやることがあります。PHPで動いているサイトがあるなら、そのバージョンを確かめ、修正版になっているかを見ることです。WordPressなら、管理画面の「ツール」から「サイトヘルス」の「情報」で確かめられます。レンタルサーバーなら、10月23日の追加の告知も含めて、サーバー会社の案内を見てください。そして、もう誰も更新していない古いWordPressのサイトが残っているなら、移行より先に止めることを考えたほうがいいと思います。

表の「前提」の列に並べたことが、筆者はいちばん大事だと考えています。それぞれのサイトがなぜ止まったのかは外からはわかりませんが、今回のように修正版が夜に出て、すぐ当てるよう求められたとき、誰が判断し、誰が当てるのかが決まっていなければ動けません。静的HTMLに移っても、AIエージェントを入れても、その問いは消えません。WordPressを続けるか移るかを決める前に、更新とパッチと公開の確認を誰が受け持つのかを決める。順番はそちらが先だと思います。