2026年10月20日に公表されたPHPの重大な脆弱性をきっかけに、Xでは「WordPressはもうやめて、CloudflareのEmDashへ」という投稿が一気に増えました。私たちライノテックも、お客様のWordPressサイトを数多く制作・保守している立場として、この数日でEmDashと周辺の選択肢をかなり深く調べました。

公式ドキュメントやソースコード、Cloudflareの利用規約の原文、実際の表示速度の計測、Xでの実務家の声まで確認したうえでの、制作会社としての見解をまとめます。先に結論です。

結論（制作・保守会社の目線）

「全部をすぐEmDashへ」は勧めません。EmDashは設計として優れていますが、1.0が出てまだ1か月。お客様のサイトを一斉に預けるには、運用の実績が足りません
既存のWordPressサイトは、まず「守り」を固める。PHP・WordPress・プラグインの更新と不要なプラグインの削除。そのうえで、必要に応じてヘッドレスWordPress（WordPressを裏に隠し、表は静的なページにする構成）で、一般の人のアクセスがPHPに届かない形にする
EmDashは、まず自社サイトで実際に運用して見極める。問題がなければ、新規制作やリニューアルの選択肢に加える
CMSの選び方より「運用の設計」が大事。お客様の更新作業、お問い合わせフォーム、ドメインとメール、管理画面への入口、利用規約まで含めて考えないと、移行した後に困ります

まず何が起きたのか：WordPressを更新しても直らない脆弱性

10月20日に公表されたのは、PHP本体の脆弱性2件（CVE-2026-109618、CVE-2026-109619）です。ログインなしで外部からサーバーを乗っ取られる恐れがあり、研究者がWordPress・Drupal・Joomlaの最新版で実際に再現したと報告されています。

WordPress本体やプラグインを更新しても直らない（サーバー側のPHPを修正版にする必要がある）
修正版は10月21日に公開。主要なレンタルサーバーは22日前後に修正を適用し、一部は予防のためにサービスを一時停止した
修正版の公開前から攻撃の試みが観測され、公開後に急増した

しかも2026年は、WordPress本体でも7月（通称wp2shell）と9月に、深刻な脆弱性が相次いでいます。私たちがこの件を重く見ているのは、「プラグインに気をつければよい」という話では済まなくなったからです。公開しているサーバーで常にPHPが動いていること自体が、狙われる入口になります。

EmDashとは：Cloudflareが作った「WordPressの精神的後継」

項目	内容
開発	Cloudflare（オープンソース、MITライセンス）
公開	2026年4月にプレビュー版、9月28日に1.0。Cloudflareは自社の公式ブログもEmDashへ移行済み
技術	TypeScript＋Astro。PHPを使わない。Cloudflare Workers上で動く（Node.jsで自前のサーバーでも動く）
プラグイン	1つずつ隔離された環境で動き、使う権限を事前に宣言する方式（サンドボックス型）。ただし隔離されない「ネイティブ型」のプラグインもあるので、区別が必要
ログイン	パスキーが標準（パスワードがないので、総当たり攻撃や漏えいが起きにくい）
管理画面	日本語に対応。投稿、固定ページ、カスタム投稿、メニュー、予約公開、サイト上でそのまま編集
AI対応	REST API、CLI、MCPサーバーを内蔵。AIから記事や画像を直接操作できる
WordPressからの移行	エクスポートファイル（WXR）や専用プラグインで、記事・画像・カテゴリなどを取り込める

4つの選択肢を比較しました

「WordPressかEmDashか」の二択で語られがちですが、実務ではその間に現実的な選択肢があります。制作・保守会社の目線で、4つを並べました。

	① 今のWordPress	② WordPress＋WAF	③ ヘッドレスWordPress	④ EmDash
構成	サーバー上のWordPressがそのまま表示	①の前にCloudflareのWAF（攻撃を止める防壁）を置く	WordPressは記事の入稿専用にして隠す。表のサイトは静的なページ	CMSごと置き換え
公開側のPHP	あり	あり（防壁つき）	なし	なし
裏側のPHP	あり	あり	あり（隠す）	なし
お客様の更新作業	今のまま	今のまま	ほぼ今のまま（反映に少し時間がかかる）	新しい管理画面に慣れる必要あり
お問い合わせフォーム	今のまま	今のまま	作り直し（PHPを通らない仕組みへ）	作り直し（公式プラグインあり）
デザイン	今のまま	今のまま	作り直し	作り直し
保守の手間	PHP・本体・プラグインの更新	①＋防壁の設定	WordPressと表のサイトの二重管理	EmDashと依存パッケージの更新
成熟度・情報量	◎	◎	○	△（1.0から1か月）
向いている場面	更新をきちんと回せる場合	すぐに防御を一段上げたい場合のつなぎ	操作は変えずに、攻撃される入口を減らしたい場合	新規制作、リニューアル、技術の見極めができる場合

見落とされがちなのが、③と④はどちらもデザインの作り直しが必要という点です。「ヘッドレスWordPressなら移行が楽」というのはCMS側の話で、表のサイトは結局作り直しになります。逆に言えば、表のサイトをAstro（EmDashの土台でもある仕組み）で作っておけば、③から④へ移るときにデザインを流用できます。

実際に計測：EmDashは表示が遅くならないか

EmDashは、アクセスがあったときにページを組み立てる方式です。「遅くならないか」と気になったので、EmDashで動いているCloudflare公式ブログと、WordPressで動いている当社サイトの応答速度を、日本から計測しました（サーバーが応答を返し始めるまでの時間、3回計測）。

サイト	1回目	2回目	3回目
Cloudflare公式ブログ・トップ（EmDash）	0.13秒	0.06秒	0.07秒
Cloudflare公式ブログ・記事（EmDash）	0.06秒	0.06秒	0.06秒
rhinotech.jp トップ（WordPress）	0.30秒	0.08秒	0.08秒
rhinotech.jp ブログ（WordPress）	0.10秒	0.08秒	0.08秒

EmDash側は、一度作ったページをCloudflareのキャッシュから返していました。表示速度の面で、WordPressより不利になることはなさそうです。ただし、データベースを日本から遠い地域に置くと、キャッシュがないときに遅くなるので、置き場所の指定が重要です。

制作会社として、実際に引っかかった5つのポイント

ここからが、一般的な紹介記事ではあまり触れられていない部分です。お客様のサイトを預かる立場で調べると、CMSの機能そのものより、周辺の設計で引っかかる点が多くありました。

1. お客様のドメインを、制作会社のCloudflareにそのまま入れてはいけない

Cloudflareの利用規約（Service-Specific Terms）には、書面での許可がない限り、自社が所有していないドメインをCloudflareに設定してはいけないという趣旨の定めがあります（原文：”Customers may not configure Zones in Cloudflare for their end customers’ Domains”）。制作会社がお客様のドメインを自社アカウントでまとめて管理する、というよくある運用は、そのままでは規約に反するおそれがあります。

お客様のサイトをまとめて運用するなら、Cloudflare for SaaS（お客様のドメインをCNAMEで向けてもらう、SaaS事業者向けの仕組み）や、Workers for Platforms（お客様ごとのプログラムを1つの基盤で動かす仕組み）を使う形になります。Cloudflare自身も、EmDash 1.0の発表でWorkers for Platformsでの運用を案内しています。ただし、想定する提供形態が規約に合うかは、実際に使う前にCloudflareへ確認すべきです。

2. ドメインとメールは、切り替え方を間違えるとメールが止まる

中小企業のサイトでは、メールの受信先（MXレコード）がサイトと同じホスト名を指していることがよくあります（当社のサイトもそうでした）。この状態でサイトだけ別の場所に切り替えると、その瞬間からメールが届かなくなります。移行前にDNSとメールの設定を必ず確認してください。Cloudflare for SaaSを使えば、DNSとメールは今の事業者のままで、サイトだけを向け直すこともできます。

3. お問い合わせフォームと自動返信は作り直しになる

WordPressのContact Form 7などはそのまま使えません。EmDashには公式のフォームプラグイン（保存・通知・自動返信・スパム対策つき）がありますが、まだ0.x系です。お客様の独自ドメインから自動返信を送るなら、SPF・DKIM・DMARC（なりすまし対策の設定）まで含めて、メール送信の仕組みを設計し直す必要があります。

4. ヘッドレスWordPressの「隠し方」には落とし穴がある

ヘッドレスWordPressで安全性を高めるには、一般の人のアクセスがPHPに届く前に止めることが要です。ところが、管理画面のURLを変えるだけでは隠したことになりません。サーバーのIPアドレスに直接アクセスされる抜け道や、REST APIの別の入口もあります。さらに、WordPressの編集画面自体がREST APIを使っているので、APIを雑に閉じると、お客様が記事を保存できなくなります。入口ごとに、誰を通すかの設計が必要です。

5. AIでの自動投稿は、EmDashでは変換が必要

EmDashは本文をHTMLではなく、Portable Textという構造化された形式で保存します。公式の変換機能はありますが、実際に移行した方からは「見出しのidが消えて目次のリンクが切れた」という報告もあります。AIで記事を自動投稿している場合は、変換後の見た目の確認が欠かせません。

実際に移行に取り組んだ方の、具体的な報告はこちらです。

https://x.com/zawa_cur/status/2112471538377376133

Xでの賛否：実務家ほど慎重

X上では「WordPressはオワコン」という強い投稿が多く拡散されていますが、制作や開発に携わる人ほど慎重でした。「制作会社として試す価値はあるが、クライアントへの提案はまだ早い」「まず自社案件で検証する段階」という声が目立ちます。EmDashのリスクを冷静に指摘している投稿も参考になります。

https://x.com/seltzer/status/2113242388151836676

私たちもこの見方に近く、「EmDashが安全だから乗り換える」ではなく「何を守りたいのか」から選ぶべきだと考えています。EmDashにも、開発の継続性、Cloudflareへの依存、利用量に応じた課金、やめたくなったときのデータの取り出しといった、WordPressとは別のリスクがあります。

ライノテックの方針

既存のWordPressサイト：PHP・WordPress・プラグインの更新と、不要なプラグインの削除を継続。必要に応じてWAFを前に置く
攻撃される入口を減らしたいサイト：少数のサイトでヘッドレスWordPressを試し、お客様の更新作業・フォーム・反映時間を確認してから広げる
EmDash：まず当社のオフィシャルサイトで実際に移行・運用し、編集画面、フォーム、AIでの投稿、バックアップと復元までを検証する
新規制作・リニューアル・移行：EmDashを選択肢に加え、EmDash制作・WordPress移行の受付を開始（2026年10月追記）

当社サイトの移行は、進めながらこのブログで事例として公開していく予定です。

よくある質問

WordPressを最新版にしていれば、今回のPHP脆弱性は大丈夫ですか？

いいえ。今回の脆弱性はPHP本体の問題なので、WordPressやプラグインを更新しても直りません。サーバー側のPHPが修正版になっているかを確認する必要があります。主要なレンタルサーバーは10月22日前後に修正を適用しています。

EmDashならセキュリティの心配はなくなりますか？

なくなりません。PHPを使わず、プラグインを隔離して動かす設計なので、WordPressで多かった種類の事故は起きにくくなります。ただし1.0が出たばかりの若い製品で、Cloudflareへの依存、アカウント管理、npmパッケージの更新といった別のリスクがあります。

ヘッドレスWordPressとは何ですか？

WordPressを記事を入れる場所としてだけ使い、表のサイトは別の仕組み（静的なHTMLなど）で表示する構成です。WordPressを外から見えない場所に隠せば、一般の人のアクセスがPHPに届かなくなります。管理画面の使い勝手は今のまま残せます。

EmDashでもお問い合わせフォームは使えますか？

使えます。公式リポジトリにフォームプラグインがあり、送信内容の保存、通知、自動返信、スパム対策（Turnstileやハニーポット）に対応しています。ただしまだ0.x系のバージョンなので、使うバージョンを固定して動作確認することをおすすめします。

移行するとメールやドメインはどうなりますか？

構成次第で、ドメインもメールボックスも今の事業者のまま移行できます。ただし、メールの受信先（MXレコード）がサイトと同じホスト名を指している場合、DNSを切り替えた瞬間にメールが届かなくなることがあるので、事前の確認が必須です。

WordPressサイトの安全性が気になる方へ

ライノテックでは、WordPressサイトのPHP・プラグインの状況確認から、ヘッドレス化やEmDashへの移行の相談まで承っています。「うちのサイトは大丈夫？」という段階でもお気軽にお問い合わせください。

料金・移行の流れ・WordPressとの違いはEmDash（エムダッシュ）制作・WordPress移行のページにまとめています。