はじめに
WordPress 7.0の公開後、相次ぐセキュリティパッチ。
そんな状況のなか、Xを眺めていると「WordPressはオワコン」「これからはStudioだ」といった声を見かけます。
そして、2026年10月21日には、Webサイトの基盤として広く利用されているPHPにも、重大な脆弱性が見つかりました。
セキュリティ上の問題が発生したサービスを離れ、別のサービスへ移行すること自体は、選択肢のひとつです。
事業の継続性や運用体制、必要な機能、管理にかかるコストなどを考え、利用するサービスを見直すことは、むしろ合理的な判断といえるでしょう。
しかし、気になるのは、その判断に至るまでの話です。
あるサービスに脆弱性が見つかったから、もう使うべきではない。
別のサービスなら安全だ。そんな単純な話で、本当に片付けてよいのでしょうか。
今回は、WordPressのセキュリティパッチ、PHPで見つかった重大な脆弱性、そしてStudioで公表された不正アクセスと情報流出の可能性を取り上げながら、サービスの優劣だけで安全性を語る風潮について考えてみます。
WordPress 7.0、相次ぐセキュリティパッチ
WordPress 7.0の公開後、セキュリティ修正を含むアップデートが相次いでいます。
こうした更新が続けば、「また脆弱性か」「WordPressは大丈夫なのか」と感じる人がいるのも無理はありません。
実際、セキュリティ上の問題が発見され、修正が必要になったという事実は軽視できません。
脆弱性が悪用されれば、サイトの改ざんや情報漏えいなど、利用者に実害が及ぶ可能性があるからです。
ただし、ここで考えたいのは、セキュリティパッチが相次いでいることと、製品として終わっていることは、同じではないという点です。
ソフトウェアは、開発者が想定していなかった問題や、これまで発見されていなかった欠陥が見つかることがあります。
脆弱性が見つかれば、原因を調査し、修正し、利用者へ更新を提供します。
これもソフトウェアを運用するうえで欠かせない仕事です。
もちろん、パッチが提供されれば、それだけで安心できるわけではありません。
利用者が更新を適用しなければ、修正前の脆弱な状態が残ることもあります。
重要なのは、脆弱性が見つかったという事実だけでなく、どのような問題が発生し、どのような修正が提供され、利用者がどう対応すべきなのかを確認することです。
「パッチが多いからオワコン」と結論づけるのは、いささか乱暴ではないでしょうか。
なお、具体的なバージョン番号や修正内容については、WordPress公式のリリース履歴と各セキュリティ告知を確認する必要があります。
記事を公開する際には、対象となるリリースと修正内容を照合し、正確な情報を記載したいところです。
2026年10月21日、PHPにも重大な脆弱性
WordPressの話だけであれば、CMSの選択や運用の問題として議論できるかもしれません。
しかし、Webサイトを動かしているのは、CMSだけではありません。
2026年10月21日、PHPそのものにも重大な脆弱性が見つかりました。
PHPは、WordPressをはじめ、さまざまなWebアプリケーションで利用されているプログラミング言語です。WordPressを使っている場合、WordPress本体だけでなく、その動作を支えるPHPの環境もセキュリティに関係します。
つまり、WordPress本体を最新の状態にしていても、サーバー側のPHPが脆弱なバージョンのままであれば、別の問題が残る可能性があります。
反対に、PHPに問題が見つかったからといって、WordPressそのものに原因があるとは限りません。
ソフトウェアは複数の構成要素によって動いています。
それぞれの構成要素に脆弱性が見つかる可能性があり、必要な修正も異なります。
CMS本体を更新すればすべて解決する、というわけではないのです。
PHPの脆弱性に対しては、利用しているPHPのバージョンを確認し、修正版への更新が必要かどうかを判断することになります。
レンタルサーバーを利用している場合は、サーバー事業者の対応状況も確認したいところです。
CMSのバージョンだけを見て「安全だ」「危険だ」と判断することには限界があります。
では、Studioなら安全なのでしょうか
WordPressに脆弱性が見つかったとき、「WordPressはもう駄目です。これからはStudioです」と主張する人がいたとします。
では、そのStudioはどうだったのでしょうか。
2026年10月16日、Studioは同社のサービスに関連する不正アクセスと情報流出の可能性について公表しました。
公式発表では、不正アクセスによって顧客情報などが外部に流出した可能性があることが説明されています。
ここで、Studioが悪いサービスだと結論づけたいわけではありません。
今回の事案についても、原因や影響範囲、二次被害の有無など、確認すべき事項があります。
公表された事実を確認し、適切に評価する必要があります。
ただ、少なくとも、Studioを選べばセキュリティ上の問題がなくなる、というわけではないことは分かります。
WordPressに脆弱性が見つかれば、WordPressを離れればよい。
Studioで情報流出の可能性が公表されれば、今度は別のサービスへ移ればよい。
それを繰り返していけば、いつか脆弱性の存在しないサービスにたどり着けるのでしょうか。
サービスを移行することはできます。
しかし、移行した先にリスクが存在しないことまで保証されるわけではありません。
WordPressに問題が見つかれば「オワコン」と批判し、別のサービスを推奨する。
ところが、その推奨先でもセキュリティ上の問題が公表された場合、今度はどのように評価するのでしょうか。
他社の問題を指摘することと、自分が推奨するサービスを客観的に評価することは、別の話です。
他社の欠点を指摘する能力と、正しく評価する能力は別物です
今回の一連の出来事を見ていると、Xで声高に「WordPressはオワコン」と主張していた人たちの、技術的な知識だけでなく、物事を評価する姿勢そのものが問われているように感じます。
WordPressに脆弱性が見つかれば、WordPressを否定する。
PHPにも重大な脆弱性が見つかれば、今度はどう説明するのでしょうか。
さらに、推奨していたStudioでも不正アクセスと情報流出の可能性が公表されました。
もちろん、これらの問題は原因も影響範囲も異なります。
単純に同列に扱うべきではありません。
しかし、だからこそ、それぞれの事実を確認し、同じ基準で評価する必要があります。
他社の脆弱性を見つけて「オワコン」と騒ぐのは簡単です。
しかし、自分が推奨するサービスにも問題が発生したとき、同じ基準で評価できるでしょうか。
そこで初めて、技術的な判断をしているのか、それとも単に自分の好みや選択を正当化しているだけなのかが見えてきます。
他社の欠点を指摘する能力と、物事を正しく評価する能力は、別物です。
セキュリティについて語るのであれば、都合のよい事例だけを取り上げるのではなく、自分が支持するサービスについても、同じように問題点を検証する姿勢が必要ではないでしょうか。
例えば、PHPに重大な脆弱性が見つかれば、PHPではなくTypeScriptとAstroを採用するEmdashを推奨する人もいるかもしれません。
確かに、PHPに起因するリスクは避けられます。
しかし、別の技術を採用したからといって、Webサイト全体の安全性が保証されるわけではありません。
重要なのは、技術やサービスの名前だけで判断せず、どのようなリスクを減らせて、何が残るのかを正しく評価することです。
ホームページ制作者は、プラットフォームそのものを作っているわけではありません
ここで、ホームページ制作を仕事にしている人たちの立場についても考えてみます。
もちろん、Web制作に携わる人のなかには、CMSの開発やセキュリティ対策、インフラの設計まで手掛ける人もいます。
しかし、WordPressやStudioなどを利用してホームページを制作する仕事と、そのサービス自体を開発・運用する仕事は、基本的に別のものです。
WordPressを使ってホームページを制作する人が、WordPress本体のすべてのコードを開発しているわけではありません。
Studioを使ってサイトを制作する人が、Studioのクラウド環境や認証システムを構築し、運用しているわけでもありません。
制作する側が担うのは、主にデザイン、情報設計、コンテンツ制作、機能の実装、運用支援などです。
プラットフォームの脆弱性を修正したり、サービス全体のインフラを管理したりするのは、基本的には提供事業者側の役割となります。
それぞれに役割があり、それぞれに責任があります。
にもかかわらず、あるサービスで問題が発生したとき、別のサービスを使っていることだけを根拠に、自分の選択が正しかったかのように語るのであれば、それは少し違うのではないでしょうか。
利用するサービスを選ぶことと、そのサービス自体の安全性を保証することは、別の話です。
家を建てることと、地盤や土地そのものを管理することは違います。
この違いを忘れてはいけません。
地震が多い日本を離れれば、安全に暮らせるのでしょうか
今回の話を、地震に例えてみます。
地球の上に家が建っています。
日本は地震が多い国です。
大きな地震が発生し、建物が損傷したり、住宅設備に被害が出たりすることもあります。
そこで、ある人がこう言います。
「日本は地震が多くて危険です。日本に家を建てるのは、もうオワコンです。これからは別の国に家を建てましょう」
確かに、移住することはできます。
災害リスクの異なる土地を選ぶことにも意味はあります。
しかし、別の国に移住すれば、自然災害のリスクがなくなるのでしょうか。
地震の少ない土地にも、洪水や台風、山火事など、別の災害リスクがあるかもしれません。
土地を変えることで、あるリスクを減らせても、すべてのリスクがなくなるわけではありません。
さらに、家を建てる建築業者が、土地そのものを作っているわけでもありません。
建築業者がどれだけ優れた家を建てても、土地の性質や自然環境まで自由に変えられるわけではないのです。
Webサイトも、これと似た構造を持っています。
CMSやWeb制作プラットフォームは、Webサイトを構築・運用するための基盤です。
その基盤の上に、制作会社や個人の制作者がサイトを作ります。
基盤の安全性、サーバーの管理、アプリケーションの脆弱性、利用者の設定、運用方法。
それぞれ異なる要素が関係しています。
もちろん、土地とソフトウェアは同じものではありません。
ソフトウェアの脆弱性は修正でき、設定や構成によってリスクを変えられます。
それでも、住む場所を変えることと、リスクそのものを理解して管理することは違うという点では、共通しています。
日本を離れたからといって自然災害がなくならないように、WordPressを離れたからといって、Webサイトのセキュリティリスクがなくなるわけではありません。
AIの普及で、便利になったものと難しくなったもの
もうひとつ、見逃せないのがAIの普及です。
AIによって、プログラムの作成やコードの分析、エラーの調査などが、以前より手軽になりました。
これは、開発者にとって大きな恩恵です。
限られた時間でコードを調査したり、問題の原因を探ったり、修正案を検討したりできるようになりました。
しかし、便利になったのは、防御する側だけではありません。
攻撃する側にとっても、コードの分析や弱点の発見、攻撃方法の検討などを効率化できる可能性があります。
これまで専門的な知識や多くの時間を必要としていた作業の一部が、AIの支援によって容易になります。
そうなれば、脆弱性を発見されるまでの時間や、攻撃手法が広がる速度にも影響する可能性があります。
ただし、AIが普及したからといって、あらゆる脆弱性が簡単に見つかるわけでも、すべての攻撃がAIによって行われるわけでもありません。
重要なのは、AIが便利な道具であると同時に、その使い方によってはセキュリティ上のリスクにも関わるということです。
こうした環境では、どのサービスを利用しているかだけでなく、脆弱性が発見された際にどのような対応が行われるのか、修正がどれだけ迅速に提供されるのか、利用者が更新を適用できる仕組みがあるのか、といった点も重要になります。
「こちらのサービスには脆弱性が見つかりました。しかし、あちらのサービスなら大丈夫です」
そんな判断を、サービス名だけで行うのは難しくなっています。
必要なのは、特定のサービスを無条件に信頼することではなく、サービスごとの特徴とリスクを理解し、適切に管理することではないでしょうか。
サービスを変えるのは自由です。ただし、それを安全性の証明にしてはいけません
誤解のないようにしておきたいのですが、WordPressを使い続けるべきだと言いたいわけではありません。
Studioへの移行を否定したいわけでもありません。
運用に必要な人員が足りない、更新作業を管理できない、独自の機能が不要になった、サービスの保守体制に不安がある。
そうした事情があるなら、別のサービスへ移行することは合理的な選択です。
反対に、WordPressの柔軟性や拡張性が必要なら、適切な更新管理やバックアップ、アクセス制御などを行いながら使い続けるという選択もあります。
重要なのは、目的や要件、運用体制、費用、リスクを踏まえて選ぶことです。
そして、どのサービスを選んだとしても、セキュリティ上の問題が発生したときには、事実を確認し、必要な対策を取る必要があります。
WordPressでは、本体だけでなく、PHPやプラグイン、テーマ、サーバー環境も確認します。
ホスティング型のサービスでは、提供事業者のセキュリティ対策や障害・インシデントへの対応、データの取り扱い、バックアップ、外部サービスとの連携などを確認します。
サービスごとに管理できる範囲は異なります。
利用者が直接管理できない部分については、提供事業者の説明や対応方針を確認することも必要です。
こうしたことを踏まえたうえで移行するなら、サービスの変更には十分な意味があります。
しかし、あるサービスの問題を指摘し、別のサービスの名前を掲げるだけで、セキュリティに関する議論が終わったことにはなりません。
乗り換えは対策のひとつであって、安全性の証明ではないのです。
さいごに
WordPressにセキュリティパッチが相次ぎ、PHPにも重大な脆弱性が見つかりました。
Studioでも不正アクセスによる情報流出の可能性が公表されています。
それぞれ原因も影響範囲も異なります。
だからこそ、サービスの名前だけで優劣を判断せず、事実に基づいて評価することが大切です。
WordPressを使うのか、Studioを使うのか、それともEmdashのような別の選択肢を選ぶのか。
それはサイトの目的や運用体制に応じて決めればよいことです。
しかし、サービスを変えることはできても、リスクそのものをなくせるわけではありません。
「WordPressはオワコン。これからは別のサービスです」と主張する前に、考えてみてほしいのです。
その新しい家は、本当に地震が起きない土地に建っているのでしょうか？
それとも、単に住む場所を変えただけなのでしょうか？
「WordPressはオワコン」と煽る前に、まずは自分自身の評価スキルを疑ってみてはいかがでしょうか。
オワコンなのは、WordPressではなく、実はあなた自身なのかもしれません。
