2026年7月、WordPress本体の脆弱性の連鎖、wp2shellが公表されたとき、当社はWordPressを利用する企業向けのWeb基盤リプレイス支援を始めると発表しました。そのときに書いた立場は、脆弱性を理由に一律の移行を勧めない、まず更新と侵害の確認、移行は落ち着いてから、というものです。この立場はいまも変わっていません。

変わったのは材料です。9月に2つのことが起きました。1つは、WordPress本体にまた新しい脆弱性が出て、Cloudflareが緊急のWAFルールを配ったこと。もう1つは、7月に当社が実験で使った代替CMS、EmDashが1.0になり、安定版として使える段階に入ったことです。

この記事は、7月に「移行は落ち着いてから考える」と判断を保留した会社に向けて、いまがその「落ち着いてから」に当たるかどうかを判断する材料を並べます。移行を勧めるサイトと勧めないサイトの線引き、移行の手順、費用の目安、そして当社が自社メディアを1.0へ上げた実録です。確認日は2026年9月29日です。

結論を先に書きます。

  1. 記事とページを公開するのが主な仕事のサイトは、移行を具体的に検討してよい段階になりました。 EmDash 1.0は破壊的な変更を次のメジャー版まで入れないと宣言し、Cloudflare自身のブログが8月から本番で使っています
  2. 会員機能・決済・複雑な予約・ECを持つサイトは、要件を見てから可否を判断します。 7月の発表で書いた線引きのままで、当社が標準で移行の対象にするのはブログ・オウンドメディア・会社サイトです
  3. 判断の軸は脆弱性ではなく、運用です。 更新を回せている会社はWordPressを続けてよく、回せていない会社は移行したほうが楽になります。この2か月に5回あったセキュリティ修正のリリースは、後者の会社にとって「回せていない」ことを確認する出来事でした

7月からの経緯。何を勧め、何を勧めなかったか

7月17日にWordPressが6.9.5と7.0.2を公開し、REST APIのルート混同（CVE-2026-63030）とSQLインジェクション（CVE-2026-60137）を組み合わせたwp2shellが塞がれました。脆弱なプラグインを必要とせず、標準構成で認証なしのリモートコード実行につながる連鎖で、7月21日に米CISAが悪用確認済みの一覧に加え、22日にIPAも注意喚起を出しています。詳細は当時の記事にあります。

当社が23日に出した発表の要点は3つでした。

  • 今すぐ必要なのは移行ではなく、修正版の適用と侵害兆候の確認
  • 移行の要否は、運用負荷・更新頻度・必要な機能・セキュリティ要件を整理してから決める
  • 標準の対象はブログ・オウンドメディア・会社サイト。会員機能・決済・複雑な予約・ECは要件を確認したうえで可否を判断

同時に、サイトのURLを入れるだけで外から見える範囲の一次診断を返す無料の診断ツールを公開し、自社の実験として英語圏向けのメディアを1つ、当時ベータだったEmDashで立ち上げました。

9月の脆弱性が示したこと

7月17日のwp2shell以降、WordPressはセキュリティ修正を含むリリースを続けて出しています。公式のリリース情報を並べるとこうなります。

版 公開日 内容
7.0.2 7月17日 wp2shell（深刻1件・重要1件）
7.0.3 8月6日 複数のセキュリティ修正
7.0.4 8月12日 セキュリティ修正1件（CVE-2026-65640）
7.1.1 9月17日 セキュリティ修正11件（REST APIのテンプレート処理の認証ありパストラバーサルなど）
7.1.2 9月22日 深刻度criticalの修正1件（CVE-2026-87902）

最後の7.1.2が塞いだCVE-2026-87902は、認証なしの攻撃者が、条件がそろえばページテンプレートの解決処理にテーマ外のローカルPHPファイルを読み込ませられる脆弱性で、リモートコード実行につながり得るとリリースノートとNVDに書かれています。本体の処理（get_page_template()）の問題で、プラグインは関係ありません。Cloudflareは9月25日、通常の週次とは別に緊急のWAFリリースを出し、この脆弱性を狙う通信を止める検出をManaged Rulesetに加えました。同じリリースで、コメント欄経由のXSSを止める検出も追加されています。

wp2shellから2か月で、セキュリティ修正のリリースが5回、うち本体の深刻な穴が2回。ここから引き出せることは、WordPressが危ないという単純な話ではありません。この2か月の実績では、修正版を当てる作業が月に2回のペースで、しかも急ぎで発生したという事実です。

この実績で自社の運用を見直してみてください。7月の修正版は当てましたか。当てた日を答えられますか。8月の2回、9月の2回は。管理者アカウントの一覧を最後に見たのはいつですか。すぐ答えられる会社は、WordPressを続けてかまいません。答えに詰まる会社は、CMSの問題ではなく、更新を回す体制が無いことが問題です。移行は、その体制を持たないままでも安全側に倒せる選択肢として意味を持ちます。

なお、CloudflareのManaged Rulesetを有効にしている会社には、9月25日の検出が配られています。ただしWAFは入口を塞ぐだけで、本体の修正の代わりにはなりません。7月と同じで、更新と確認が先です。

EmDash 1.0で何が変わったか

7月の時点でEmDashはベータでした。当社の記事にも、ドキュメントと実際の挙動の食い違いを踏んだと書いています。9月28日の1.0で、次の点が変わりました。

  • 安定版の宣言。 GitHubのリリースノートに、1.0以降、破壊的な変更は次のメジャー版でしか入れない、と書かれました。1.0.1では内部向けのパスが整理され、以前の書き方が使えなくなった箇所もあります。ここが一番大きい変更です
  • 本番の実績。 Cloudflareは8月に自社ブログをEmDashへ移し、週に数百万ページビュー、正規のアクセスだけでピーク時に毎秒5,000リクエストの負荷を受けています。オブジェクトキャッシュ、Hyperdriveの接続、Workers Cacheとの連携は、その移行で生まれた機能です
  • プラグインの隔離。 プラグインは自分専用の記憶域しか持たず、記事・画像・ユーザー・秘密情報・ファイル・ネットワークには、宣言して管理者が承認した範囲でしか届きません。実行はCloudflare上ではDynamic Worker、Node.js上ではworkerdの別プロセスです
  • プラグインの登録所。 AT Protocol上に置かれ、公開者が自分のアカウントでパッケージと版の記録に署名します。EmDash側はその記録を独立に検証し、チェックサム・名前・版・要求する権限を確認してから入れます。登録所を運営する会社がプラグインを取り上げたり消したりできない設計です
  • 貢献者の広がり。 175人超、1,800コミット超、25言語への翻訳。MITライセンスのまま
  • WordPressからの取り込み。 取り込みの機能は保守が続いていて、GitHubのリリースノートによると1.0.1でWordPressの画像URLの書き換えの修正が入っています

WordPressのプラグインとEmDashのプラグインの権限の違いを並べた対比図

3つ目の隔離は、この2か月の脆弱性とつながっています。Cloudflareの発表によると、WordPressでは、プラグインは本体と同じPHPのプロセスの中で、データベースにもファイルにもネットワークにも直接触れます。問い合わせフォームのプラグインが、技術的には未公開の記事を読み、別のプラグインを書き換え、データをどこへでも送れます。入られた先に境界が無い。EmDashのサンドボックスで動くプラグインは、入られても宣言した範囲までしか届かない作りです。

移行を勧めるサイト、勧めないサイト

サイトの性格を、動的な機能の必要度と更新を回せる体制の2軸で置き、移行を勧める範囲を示した4象限

判断は2つの軸で決まります。横軸は、公開しているサイトにどれだけ動的な機能が要るか。縦軸は、更新を回せる体制があるか。

サイトの性格 更新を回せている 更新が止まりがち
記事・ページの公開が主（ブログ・オウンドメディア・会社サイト） どちらでもよい。移行すれば運用は軽くなる 移行を勧める
フォームと問い合わせ程度の動的機能 どちらでもよい 移行を勧める（フォームは移行先で作り直す）
会員機能・決済・複雑な予約・EC 要件を見て個別に判断 要件を見て個別に判断。並行して更新の体制を作る

右下の2つが、いま動くべき会社です。左の列の会社は急ぐ理由がありません。ただし、WordPressを続ける会社にも、9月の脆弱性が示した「数か月に一度の急ぎの更新」は同じように来ます。続けるなら、更新を回す担当と手順を決めることが条件です。

WordPressのサイト全体から、記事中心で、更新が止まりがちなサイトへ移行候補を絞り込む図

もう1つ、判断を急がせない材料も書いておきます。移行そのものが、脆弱性への対応にはなりません。移行の準備中も旧サイトは公開されたままなので、修正版の適用は移行と関係なく必要です。7月の順番、更新、暫定の遮断、侵害の一次確認は、今回も先です。

移行の4段階

当社が7月の発表で示した4段階を、EmDash 1.0を移行先にした場合で具体化します。

WordPressからEmDashへの移行を、緊急確認と評価・移行・計測の再構築・改善の4段階で示した図

1. 緊急確認とアーキテクチャ評価。 WordPressの版、修正版の適用状況、公開している機能、プラグインの一覧、管理者アカウントを確認します。あわせて1枚の評価資料で、続ける場合と移す場合の利点・リスク・運用負荷を並べます。ここで対象外（EC・会員制など）が分かれば、移行はしません。

2. CMSとWeb基盤の移行。 EmDashのWordPress取り込み機能で、記事・固定ページ・画像を移します。公式の移行ガイドによると、WordPressの書き出しファイル（WXR）を管理画面から取り込み、記事・固定ページ・カスタム投稿・カテゴリとタグ・著者を移せます。ブロックエディタとクラシックの本文は自動で変換され、画像は元サイトから取得して置き直し、本文中のURLも書き換わります。WordPress側に用意されている書き出し用プラグインを入れられれば、メニュー・サイト設定・SEOプラグインの値・カスタムフィールドも運べます。手作業になるのは、テーマの組み直し、ショートコードやページビルダーで作ったページの直し、リダイレクト表、そしてフォームなどプラグインに頼っていた機能です。移すのは中身だけではありません。既存URLの維持、301リダイレクト、title・description・canonical、構造化データ、XMLサイトマップ、フォームと問い合わせの到達点、ドメイン・DNS・SSL、公開前の動作確認と切り戻し手順、旧環境の安全な停止。7月に書いた一覧のとおりです。

3. 計測と集客の基盤の再構築。 GA4、Search Console、Tag Manager、Google Adsを移行先で組み直します。タグやトリガーはコードと変更履歴で管理し、担当者の記憶に依存しない形にします。移行の前後でアクセス、検索流入、問い合わせ、広告の成果を比べ、計測漏れと二重計測が無いことを確かめます。

4. 改善とAI活用。 移行後に、記事の更新や画像の管理をエージェントに任せる部分を決めます。EmDashは管理画面のほかにAPI・CLI・MCPサーバーを持つので、記事の下書きや画像の整理を人の確認つきで自動化できます。ここは移行の理由ではなく、移行後に得られる余地です。

費用と条件

EmDash自体は無料（MIT）です。動かす場所の費用が要ります。

  • Cloudflare Workersの無料枠で動く構成: 記事を書いて公開する、プラグインを使わない構成なら、無料枠で始められます。データベース（D1）と画像の置き場（R2）も無料枠があります
  • プラグインを隔離して動かす構成: Dynamic Workerを使うため、Workers Paidプラン（月5ドルから）が要ります。登録所からプラグインを入れる場合はこちらです
  • 移行の作業費: 当社の支援は、記事数・URL数・フォームの数・計測の複雑さで見積もります。続けるか移すかの当たりは、初回の無料相談で出します

作業の規模は、当社が自社サイトの更新と公式の移行ガイドから見立てた目安で、次のとおりです（1人で作業した場合）。

規模 内容 目安
小 ブログ50〜200本・固定ページ数枚・標準的なテーマ・フォームなし 2〜4日。環境の用意0.5日、取り込みと検証1日、テーマの組み直し1〜2日、リダイレクトと切替0.5日
中 会社サイト・カスタムフィールドあり・ページビルダー使用・問い合わせフォーム 2〜4週間。ページビルダーで作ったページの直しと、テーマの再現が大半
大 会員・EC・多言語・多数のプラグイン 現時点では勧めない。ECのプラグインが出そろってから

費用の判断で1つ書いておくと、WordPressの保守費用（ホスティング、有償プラグイン、更新の外注）と比べて安くなるかどうかは、サイトによります。安くするための移行ではなく、急ぎの更新に振り回されない構造にするための移行です。

当社の実録。7月のベータから1.0へ

当社は7月に、英語圏向けのメディアをEmDashのベータ版で立ち上げました。その後2か月、0.x台の更新に追随しながら運用しています。9月28日の1.0を受けて、同じサイトを1.0へ上げる作業を行いました。

結果から書くと、ソースコードを1行も変えずに、0.29.0から1.0.1へ上がりました。 作業は1時間以内です。

  • 0.29と1.0.1の間には0.30から0.42まで13回の更新が挟まっていて、公式の移行ガイドには破壊的変更が10件ほど並んでいます（キャッシュ用の補助関数の削除、コメント部品の読み込み元の変更、内部向けパスの整理、Node.js 22.16以上とAstro 6以上の要件など）。当社のサイトはどれにも当たりませんでした。プラグインを使わず、内部のパスを直接読み込んでいない、記事中心の構成だったからです
  • ビルド、型検査、デプロイの予行（実際には配らない乾式実行）、ローカルの開発サーバーでの表示確認は、すべて通りました
  • データベース（D1）の構造の移行は、0.29時点で50件が適用済みで、1.0.1では89件まで増えています。ローカルでは開発サーバーの最初のアクセスで残りの39件が自動で当たりました。本番でも同じことが起きます
  • 気をつける点が1つ。この移行は前に進むだけで、戻す手段が用意されていません。 本番に反映する前にD1のバックアップを取る、というのが当社の手順に加わりました

なお、npmには1.0.0という版も載っていますが、公式の変更履歴に「古いコードから誤って公開したもので、入れないこと」と書かれています。1.xの最初の版は1.0.1です。本番への反映は、バックアップと管理画面の目視確認を済ませてから行います。

ベータの時点で書いた不利な点のうち、ドキュメントと実挙動の食い違いは1.0で減りました。プラグインのエコシステムが小さい点は、登録所ができたばかりなので、まだそのままです。会社サイトに必要な機能の多くは、プラグインなしで足ります。

注意点

移行は脆弱性対応ではない。 上にも書きましたが、いちばん誤解されやすいので繰り返します。旧サイトの修正版の適用と侵害の確認が先で、移行はその後です。

作り込んだ機能を無理に移さない。 会員機能・決済・複雑な予約・ECは、EmDashでも他の静的寄りのCMSでも、作り直しの規模が大きくなります。要件を見て、WordPressを続けて更新の体制を作るほうが現実的な場合があります。

データベースの移行は戻せない。 EmDashの更新でデータベースの構造が変わるとき、前に進む移行だけが用意されています。本番に反映する前にバックアップを取るのを手順に入れてください。

URLと計測を軽く見ない。 移行で失われやすいのは記事ではなく、検索順位と計測の連続性です。301リダイレクトの一覧と、GA4の前後比較は、移行の成果物として必ず出してもらってください。

Bingやほかの検索エンジンの再登録。 Search Consoleだけでなく、Bing Webmasterにも移行先を登録します。忘れられがちです。

1.0より前の情報が多く残っている。 検索して出てくる解説には1.0より前に書かれたものが混ざります。1.0.1で内部向けのパスが整理されたように、以前の書き方が使えない箇所があるので、公式ドキュメントの版を確認してから真似してください。

KOIYALの見解

7月に当社が「一律の移行は勧めない」と書いたのは、脆弱性を売り文句にした移行の営業を、自分たちがしたくなかったからです。だから、移行を勧める条件を狭く書いています。記事中心で、更新が止まりがちなサイト。それだけです。

一方で、この2か月の出来事で、勧めるときの根拠は具体的になりました。セキュリティ修正のリリースが5回、うち本体の深刻な穴が2回、という実績。そして、移行先が「実験」から「Cloudflareのブログが本番で使う安定版」になったこと。7月に材料が足りずに保留した会社は、いま同じ問いに、前より少ない不確かさで答えられます。

もう1つ。EmDashが1.0で示したのは、プラグインを信用しない前提の設計です。当社がAIエージェントを会社に入れる支援で言っているのと同じ考え方で、何ができるかを先に宣言させ、それ以外を仕組みで止める。CMSでもエージェントでも、任せる範囲を宣言と権限で決めるのが、これからの標準になります。

次の行動

  1. 自社のWordPressの版と、7月から9月の5回の修正版を当てた日を確認する。答えられなければ、まず更新（最新は7.1.2）
  2. 無料の診断ツールにURLを入れ、外から見える範囲の一次診断を取る
  3. 上の表で、自社のサイトがどの箱に入るかを決める。右下なら移行の検討、左なら更新の体制づくり
  4. 移行を検討するなら、記事数・URL数・フォームの数・使っている計測ツールを1枚に書き出す

移行を検討する会社には、無料の相談をお受けしています。お問い合わせから、サイトのURLと、上の4の一覧を添えてご連絡ください。初回の打ち合わせで、続けるか移すかの当たりと、移す場合の段取りをお出しします。

参考