Blog
PHP脆弱性でWordPressを見直すべき?|EmDash・Sanityなど代替CMSの選び方
PHPの重大脆弱性を理由に、すべての会社がWordPressをやめる必要はありません
WordPressの代替CMSとは、WordPressを使わずにWebサイトの記事・画像・ページ情報を管理する仕組みのことです。2026年10月21日にPHPで重大な脆弱性が公表されたことで、WordPressを含むPHP系のWeb基盤をこのまま使い続けてよいのか、不安を感じる企業は増えると考えられます。
ただし結論は『今すぐWordPressを捨てるべき』ではありません。今回の直接の問題はWordPress固有ではなくPHP側の脆弱性です。
見るべきポイントは3つです。①自社がPHPやWordPressの更新を継続的に管理できるか、②テーマやプラグインを含む保守範囲を把握できているか、③今後のコンテンツ運用やAI活用に、現在のCMS構成が合っているか。
この3点に不安がある会社にとっては、今回がCMSを見直す合理的なタイミングになります。
2026年10月21日に何が起きたのか|PHPで認証なしRCEにつながり得る2件の脆弱性が修正された
PHP公式は2026年10月21日、CVE-2026-109618とCVE-2026-109619という2件の重大な脆弱性を修正したセキュリティリリースを公開しました。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。
PHP公式の説明では、いずれも認証されていない外部からのリクエストによってリモートコード実行につながる可能性があり、Webリクエストを処理するPHP環境全般が影響対象になり得るとされています。特に重要なのは、完全な回避策ではなく『更新すること』が安全な対応として案内されている点です。
PHP 脆弱性という言葉だけを見ると開発者向けの話に見えますが、PHPを実行基盤として使うCMSやECシステムを運営する企業にとっては、サービス継続そのものに関係する運用課題です。
カラーミーショップやEC-CUBEの対応が示したのは、脆弱性そのものより『基盤更新が事業停止につながる可能性』です
今回の影響が分かりやすく表れた例が、カラーミーショップとEC-CUBEです。カラーミーショップは10月21日22時から、修正プログラムを速やかに適用するための予防的なメンテナンスとして、ショップ表示・購入手続き・管理画面などを一時停止しました。
カラーミー側では当該脆弱性を悪用した攻撃やデータ漏洩は確認されていないと明記されています。EC-CUBEもPHPのセキュリティリリースに備えるよう利用者へ事前案内を出しました。
ここで重要なのは『PHPだから危険』という単純な話ではありません。どの技術を選んでも更新は必要です。
ただ、実行基盤とCMSと公開サイトが密接に結び付いている構成では、基盤更新の影響範囲が大きくなりやすいという事実は、CMS選定の重要な判断材料になります。
今回を『WordPressの脆弱性』と呼ぶのは正確ではありません
今回公表された2件はPHP本体の脆弱性であり、WordPressだけを狙ったものではありません。WordPressはPHPで動くため影響を受け得ますが、同じPHPを使う別のCMSやWebアプリケーションも対象になり得ます。
したがって『WordPress セキュリティが危険だから別CMSに移れば安全』という言い方は適切ではありません。SanityやEmDashに移行しても、それぞれ別の依存関係、API、実行環境、認証、アップデートの管理は残ります。
違いは、リスクがゼロになるかどうかではなく、どの部分を自社が管理し、どの部分をサービス側に任せ、障害時にどこまで影響が広がる構造なのかです。CMSを乗り換える判断では、技術名よりも『運用責任の分け方』を見る方が実務的です。
今回の件だけでWordPressを即時廃止する必要はありません
今回の直接原因はPHP側です。更新体制が整っており、プラグインやテーマも適切に管理できているWordPressサイトなら、継続利用は十分に合理的です。
それでもWordPress離れが起きる可能性がある理由|問題は1回の脆弱性ではなく、保守の積み重ねです
企業がWordPressをやめたいと考える理由は、一度のセキュリティニュースだけではありません。PHP本体、WordPress本体、テーマ、複数のプラグイン、サーバー設定まで、それぞれに更新タイミングと互換性があります。
小規模な会社では、担当者が『何を更新すればよいのか』『更新して壊れたら誰に相談するのか』まで把握していないことも珍しくありません。制作会社へ保守を委託している場合でも、契約範囲が曖昧だと、緊急更新のたびに追加確認が必要になります。
今回の出来事はWordPressそのものの欠陥を示したわけではありませんが、CMSを含むWeb基盤を誰がどこまで保守するのかという問題を、経営側にも可視化しました。だからこそ、今後はWordPress 代替 CMSを比較する企業が増える余地があります。
選択肢1|WordPressを継続する:更新担当と保守範囲を明確にできるなら、依然として強い選択肢です
WordPressには、長年蓄積されたテーマ・プラグイン・運用ノウハウがあり、社内担当者や制作会社が慣れている場合の扱いやすさは大きな利点です。すでに多数の記事、会員機能、予約、フォーム、EC連携などをWordPress上で動かしている会社では、移行コストの方が大きくなることもあります。
継続する場合は、PHPとWordPress本体の更新責任者、使用中プラグイン一覧、更新前バックアップ、検証環境、障害時の連絡先を最低限明文化しておくべきです。『何かあったら制作会社に聞く』ではなく、平常時から更新フローを決めておくことが重要です。
これができるのであれば、今回のPHP脆弱性だけを理由に別CMSへ移る必要はありません。
選択肢2|EmDash:Cloudflareが『WordPressの精神的後継』として開発するAstroベースのCMS
EmDash CMSは、Cloudflareが2026年9月28日に1.0を公開した、無料・オープンソースのCMSです。Cloudflare自身が『WordPressの精神的後継』と表現しており、Astroを中心に、管理画面、データベース、メディア、公開フローまでをまとめて扱える構成になっています。
特徴的なのはプラグインの扱いです。EmDashではサンドボックス型プラグインに対して、コンテンツ、メディア、ユーザー、外部サービスなど必要な権限だけを与える設計を採用しています。
またAPI、CLI、組み込みMCPサーバーを通じてAIエージェントから操作できる点も、従来型CMSとの大きな違いです。Cloudflare Blog自体も2026年8月にEmDashへ移行しており、単なる実験プロジェクトではなく本番運用まで進んでいます。
選択肢3|Sanity:CMSと公開サイトを分離し、コンテンツを『データ』として管理したい会社に向いています
Sanity CMSは、記事や商品情報、人物情報などを構造化データとしてContent Lakeに保存し、Webサイト側からAPIで取得して表示するヘッドレスCMSです。WordPressのようにCMSがそのまま公開画面を生成する考え方ではなく、『編集する場所』と『見せる場所』を分けます。
この構成の利点は、同じコンテンツをWebサイト、アプリ、メール、SNS、自動生成ワークフローなどへ再利用しやすいことです。CATARIVEやUTATOEでもSanityを使い、記事データを公開サイトから分離して運用しています。
AIで記事候補を作る、承認済みデータだけを公開する、既存記事を別チャネルへ転用するといった仕組みを作る場合、コンテンツがAPIで扱えることは大きなメリットになります。一方で、フロントエンド開発が必要になるため、WordPressより初期設計の難度は上がります。
ヘッドレスCMS自体の仕組みや向き不向きを先に知りたい場合は
ヘッドレスCMSの基本を見るEmDashとSanityは似て見えますが、同じ種類のCMSではありません
EmDashとSanityはどちらもWordPressの代替候補として名前が挙がりやすく、AIとの相性も良い一方で、設計思想は異なります。EmDashはAstroサイトの中にCMS機能を持たせるフルスタック寄りの構成で、開発者がサイトとCMSを一体のTypeScriptプロジェクトとして扱いやすいのが特徴です。
Sanityはコンテンツ基盤を独立させ、公開側をNext.js、Astro、Nuxt、Cloudflare Workersなど好きな技術で構築できます。つまり、サイト単位で完結しやすくWordPressに近い編集体験と現代的な実装を両立したいならEmDash、複数サイトや複数チャネルでコンテンツを共有し、CMSを中核データ基盤として使いたいならSanityが候補になります。
どちらが上というより、コンテンツを『サイトの中に置くか』『組織の共通データとして持つか』の違いです。
セキュリティで比較するときは『脆弱性の数』ではなく、影響範囲と更新責任を比較します
CMS比較でよくある誤りは、『Aには脆弱性があった、Bには聞いたことがないからBの方が安全』と判断することです。新しい製品は利用者が少ないため、単純に報告件数が少ないだけという可能性もあります。
見るべきなのは、①CMS本体と公開サイトが同じ実行環境か、②拡張機能に与える権限を制限できるか、③コンテンツデータと公開画面を分離できるか、④緊急更新を誰が担当するか、⑤問題発生時に公開サイト全体を止めずに切り離せるか、という構造です。WordPress、EmDash、Sanityのどれを選んでも運用は必要です。
ただし、自社に合う責任分界を選ぶことで、緊急対応時の混乱は減らせます。今回の件を機に見直すなら、製品名より先にこの5点を棚卸しする方が効果的です。
AI時代のCMSでは『人が編集できる』だけでなく『システムから安全に編集できる』ことが重要になります
従来のCMSは、人が管理画面へログインして記事を書くことを中心に設計されてきました。これからは、AIが下書きを作る、過去記事を分析する、商品情報から複数チャネル向けの文章を生成する、承認された変更だけを公開するといった運用が増えます。
そのとき重要になるのがAPI、権限、変更履歴、承認フローです。EmDashはMCPやAPIを使ったエージェント操作を前提に設計され、Sanityは構造化データをAPIで読み書きできるため、自動化ワークフローへ組み込みやすい性格があります。
WordPressもREST APIなどで自動化できますが、既存プラグインやテーマとの組み合わせによって設計が複雑になることがあります。今CMSを選び直すなら、編集画面の使いやすさだけでなく、3年後にAIや自動化から安全に操作できるかまで含めて判断する必要があります。
WordPressから移行を検討する目安|5項目のうち3つ以上に当てはまるなら比較を始める価値があります
CMS移行は大きな作業なので、感情的に決めるべきではありません。判断の目安として、①PHP・WordPress・プラグイン更新を誰が担当するか曖昧、②使っていないプラグインが増え続けている、③更新のたびに表示崩れや互換性確認が必要、④記事データをSNS・アプリ・AIなど他用途にも使いたい、⑤Webサイトの改修をテーマの制約から切り離したい、の5項目を確認します。
3つ以上に当てはまる場合は、WordPressをやめると決めるのではなく、WordPress継続、EmDash、Sanityなどを同じ要件表で比較する段階へ進む価値があります。逆に1つ程度しか当てはまらないなら、CMS移行より現在の保守体制を整理した方が費用対効果は高い可能性があります。
CMS移行の判断は『製品比較』より先に『現在の運用棚卸し』から
記事数、フォーム、会員機能、EC連携、プラグイン、更新担当、月額保守費、障害時の連絡経路を一覧にすると、移行する価値と移行コストの両方が見えやすくなります。
移行する場合も、一度に全部を置き換えない方が安全です
WordPressから別CMSへ移るときは、全ページを一晩で切り替える必要はありません。まず現在のURL一覧と機能一覧を作り、次に記事・固定ページ・フォーム・会員機能・ECなどを分けて、移行難度を確認します。
その上で、新規記事だけを新CMSで管理する、企業サイト部分だけを新基盤へ移す、既存WordPressは読み取り専用に近い状態で残す、といった段階移行も可能です。Cloudflare BlogのEmDash移行でも、旧環境と新環境の間にルーティング層を置き、少量のトラフィックから段階的に切り替える方法が採られました。
企業サイトでも考え方は同じで、CMS移行は『引っ越し当日に全部止めて運ぶ』より、『新旧を並行させながら切り替える』方が事故を抑えやすくなります。
CMSだけでなくWeb運用全体を整理してから移行判断をしたい場合は
Company OSを見るFAQ|PHP脆弱性とWordPress代替CMSについてよくある質問
Q. 今回のPHP脆弱性があるのでWordPressは危険ですか。A. 今回はWordPress固有ではなくPHP本体の問題です。
修正版への更新と、利用中の環境が適切に管理されているかの確認が先です。Q. WordPressをやめればセキュリティ対応が不要になりますか。
A. いいえ。どのCMSでも依存ソフトウェア、認証、API、権限、更新の管理は必要です。
Q. EmDashはヘッドレスCMSですか。A. 一般的な独立型ヘッドレスCMSというより、AstroサイトとCMSを一体で扱うフルスタックCMSに近い設計です。
Q. SanityはWordPressより簡単ですか。A. 編集画面は用途に合わせて整理できますが、公開サイト側の開発が必要になるため初期構築はWordPressより専門性が必要です。
Q. どのCMSが一番安全ですか。A. 製品名だけで決めることはできません。
更新体制、権限設計、依存関係、バックアップ、障害時の切り離し方まで含めた運用設計で判断する必要があります。
まとめ|今回を『WordPressを捨てる理由』ではなく『CMSを経営基盤として見直す機会』にする
2026年10月21日のPHP重大脆弱性は、WordPressだけの問題ではありません。しかし、カラーミーショップのサービス停止やEC-CUBEの注意喚起まで広がったことで、CMSや実行基盤の更新が事業運営へ直結することが改めて可視化されました。
WordPressの保守体制が整っている会社は、慌てて移行する必要はありません。一方、更新責任が曖昧、プラグインが増えすぎている、コンテンツをAIや複数チャネルで使いたいといった課題がある会社にとっては、EmDashやSanityを含む代替CMSを比較するよいタイミングです。
判断するときは『何が新しいか』ではなく、『誰が保守するか』『障害時にどこまで止まるか』『コンテンツを今後どう使うか』の3点から選ぶと、技術トレンドに振り回されにくくなります。
現在のWordPressを残すべきか、別CMSへ移すべきかを整理したい場合は
Web/CMS構成を相談するWordPress移行・代替CMS特集
判断材料から具体的な移行手順まで、関連ガイドをまとめて確認できます。
あなたのサイト、WordPressをやめられる?
URLを入れるだけで、移行難易度・デザインやSEOの維持しやすさ・推奨構成・概算費用を自動で簡易診断します。
あわせて読みたい

WordPressからEmDashへ移行する方法|URL・画像・SEOを崩さない手順
WordPressからCloudflare EmDashへ移行する実務手順を解説。WXR・EmDash Exporter、画像、URL、301リダイレクト、SEO、フォーム、プラグイン依存まで移行前後のチェック項目を整理します。

WordPress代替CMS比較 2026|EmDash・Sanity・microCMS・Studioの選び方
WordPressから移行するならどのCMSを選ぶべきか。EmDash、Sanity、microCMS、Studioを、更新担当者・開発体制・セキュリティ責任・コンテンツ再利用・AI運用・移行負荷の6軸で比較します。

EmDash CMSとは?|Cloudflareが作るWordPressの精神的後継を解説
Cloudflareが2026年9月に正式版を公開したEmDash CMSについて、WordPressとの違い、Astro・サンドボックス型プラグイン・MCP対応、向いている企業と移行時の注意点を整理します。