WordPressから他のCMSへ移行する方法｜CloudflareのEmDashをおすすめする理由

PHPの緊急更新で、見直したいサイトの保守

ホームページの担当者が書きたいのは、新しい実績やサービスのお知らせ。それなのに、PHPの更新通知が届くと「今のテーマは動くのか」「フォームは止まらないか」と、確認する仕事が増えてしまいます。

PHPは、サーバー上でWordPressを動かすために使われているプログラミング言語です。普段の記事編集では意識しなくても、サイトを動かす側では更新が必要になります。

2026年10月21日、PHPで重大な脆弱性2件に対応するセキュリティリリースが公開されました。予告された時刻は日本時間の23時、午後11時です。IPAの事前案内では、公開に備えてPHPの利用状況や更新方法を確認するよう呼びかけていました。

公開された修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35。PHP公式は、認証なしでサーバー上のコードを実行されるおそれがあるとして、速やかな更新を勧めています。つまり、ログイン画面のパスワードを強くするだけでは対処できない種類の問題です。PHP公式のセキュリティ情報で、利用中の系列に対応する修正版を確認してください。

今回の問題はPHPそのものにあり、WordPressだけに限りません。WordPress本体を最新版にしても、サーバー側のPHPまで更新されるとは限らないため、まず契約中のサーバー会社か保守担当者に対応状況を確認する必要があります。配布元が修正を取り込む場合もあるので、画面のバージョン番号だけで判断せず、提供元の案内と照合します。

WordPress公式のX投稿も、ホスティング事業者の更新計画を確認し、PHPを更新するよう案内しています。

なお、IPAは事前案内の時点で、この2件を悪用した攻撃を確認したわけではないと明記しています。脆弱性の公表、攻撃のおそれ、実際の被害は別の話です。移行を検討する場合も、現在のサイトの修正対応を先に進めてください。

WordPressで負担になるのは、更新のたびの確認

WordPressの強みは、テーマやプラグインを多くの中から選べることです。予約機能やネットショップがすでに事業の中心なら、その資産を使い続けるのも十分に成り立つ選択です。

ただ、運用が長くなると、WordPress本体、PHP、テーマ、プラグインの組み合わせを確認する場面が増えます。古いプラグインが新しいPHPで動くか分からず、更新を先送りする。担当者が変わって、何のために入れたプラグインか分からなくなる。こうした状態では、記事を1本追加する以外の仕事が積み上がってしまうんですよね。

WordPress公式の安全対策でも、継続的な更新と信頼できるプラグインの利用が案内されています。問題になるのは、CMSの名前だけではありません。自社で保守できる構成になっているかどうかです。

そこで、ニュースや実績、ブログが主な更新対象なら、必要な機能を整理したうえでEmDashへ移す方法をおすすめします。移行に合わせて、日々の更新をAIへ依頼する運用も作れます。

EmDashなら、AIに記事や画像の更新を頼める

EmDashは、Cloudflareが開発する、ソースコードが公開されたCMSです。CMSとは、記事や画像を管理し、ホームページに表示するための仕組み。EmDashではWordPressを動かすPHPを使わず、Astroというサイト制作の仕組みと組み合わせて画面を作ります。EmDash公式の概要

特徴の一つが、AIとサイトをつなぐMCPへの標準対応です。MCPは、AIが外部のツールを使うための共通の接続方式。Claude CodeやCodexから接続すると、許可した範囲で記事を読んだり、下書きを作ったり、画像を登録したりできます。EmDashのAI連携

例えば「このメモをニュースの下書きにして、写真を1枚入れて」と頼む。担当者は管理画面で内容を確かめてから公開する。毎回、ページ全体のHTMLを触らなくてもよい形にできます。AIに頼める場所と、人が確認する場所を決めておくイメージです。

当社のコーポレートサイトでは、ニュース・実績・注目のサービスに更新項目を絞りました。会社案内などの固定部分は静的なまま残し、担当者が普段使う入力欄だけを用意しています。AIを使わず、画面から入力する運用も選べます。

PHPを使わなくなっても、保守は続く

サイトをPHPに依存しない構成へ移せば、そのサイトのPHP更新は不要になります。一方、EmDash本体や関連ソフトウェアの更新、権限の見直し、バックアップは引き続き必要です。旧WordPressや別のPHPシステムを残す場合、その保守も続きます。

プラグインの動かし方にも違いがあります。EmDashのサンドボックス型は、専用の環境でプラグインを動かし、触れるデータなどを権限で制限する設計です。ただし、ネイティブ型はサイト本体と同じ実行環境で動くため、同じ隔離を前提にはできません。「EmDashにすれば攻撃されない」と考えるのは早いです。プラグイン形式の公式比較

記事は取り込み、デザインや機能は作り直す

WordPressの記事、固定ページ、カテゴリー、画像などは、EmDashの移行機能で取り込めます。方法は、WordPressから書き出したXMLファイルを使うか、WordPress側にEmDash Exporterを入れて接続するかの2通りです。公式の移行手順

ただし、テーマやプラグインを、そのままEmDashへ持っていくことはできません。デザインはAstro側の画面として再現し、問い合わせ、予約、決済などは必要な機能ごとに用意します。ページ作成プラグイン独自のデータや、ショートコードも個別に確認する対象です。WordPressテーマの移植

まず試すなら、会社案内とニュース、実績が中心のサイトが候補になります。複雑な会員機能やWooCommerceの受注処理まである場合は、どこまで作り直すのかを先に調べたいところです。CMS選びで迷う場合は、WordPress・Studio・Wix・EmDashの比較も参考になります。

Claude Code・Codexと進める移行手順

用意するのは、WordPressの管理権限とバックアップ、Cloudflareのアカウント、Claude CodeまたはCodexを使える環境です。加えて、移行先のコードを保存する場所と、公開前に試すための検証用URLを用意します。

このWordPressサイトをEmDashへ移行したいです。公式Docs MCPで現在の仕様を確認し、まず検証環境を作ってください。移す対象はニュース・実績・画像です。旧URLと必要な機能を一覧にして、ニュース1本と実績1件で取り込みと表示を試してください。未対応の項目は報告してください。本番のDNS変更と旧サイトの削除は、私が確認するまで行わないでください。

1. 記事・画像・URLを保存する

WordPressの「ツール → エクスポート」で「すべてのコンテンツ」を選び、XMLファイルを書き出します。この形式がWXRです。XMLに入るのは本文や画像の参照先などで、画像ファイル本体は含まれません。データベースとアップロード済み画像も、別途バックアップします。

あわせて、現在のURL、記事数、カスタム投稿の種類、使っているプラグインを一覧にします。問い合わせの送信先や解析設定も記録しておくと、移行後の確認に使えます。WXRとメディアの扱いは、インポート仕様を参照してください。

2. CloudflareにEmDashの検証環境を作る

まずAIエージェントに、公式のCloudflare向けテンプレートを使ってEmDashを構築してもらいます。公式構成では、サイトを動かすWorkers、記事などを保存するD1、画像を保存するR2の3つを組み合わせます。公開(デプロイ)に使うのは、Cloudflareの管理ツールのWranglerです。Cloudflareへの公開手順

この時点では本番ドメインを切り替えず、検証用のURLで管理画面とページ表示を確認します。Cloudflareの利用料やAIツールの契約料は別途確認が必要です。

環境を作ったら、すぐに初期設定を済ませて管理者を登録します。すぐに設定できない場合は、Cloudflare Accessなどで検証URLへのアクセスを制限してください。空のデータベースを使う公開プレビューでは、最初に初期設定を完了した人が管理者になります。検証環境の初期設定

3. 公式ドキュメントとサイトのMCPをつなぐ

AIに仕様を調べてもらう接続先は、https://docs.emdashcms.com/mcpです。公開されているドキュメント検索用で、サイトの記事を書き換える権限はありません。Docs MCPの説明

記事の読み書きに使う接続先は、移行先のドメインに/_emdash/api/mcpを付けたURLです。Claude CodeやCodexに登録し、ログインして利用を許可するOAuth、または接続用の鍵にあたる専用トークンで認証します。管理画面にログインしただけでは、MCPの認証にはなりません。

まずは検証サイトに必要な読み取り・編集権限を付け、公開権限は運用に合わせて分けます。「公開しないで」という文章だけに頼らず、トークンの権限とユーザーの役割でも制限します。WorkersやD1の作成・変更には、これとは別にCloudflare側の権限が必要です。MCPの認証と権限

MCPはAIが操作するための接続口です。つなぐだけでWordPress全体が自動移行されるわけではなく、データの取り込み、画面の作成、公開環境の設定を順に進めます。

4. データを取り込み、必要な機能を再現する

取り込みは、インポート権限を持つEmDashの管理者が行います。管理画面の「Import（取り込み）」でWordPressのXMLを読み込み、投稿の種類や項目を確認してから実行してください。画像のコピーが完了したことも確かめます。Exporter方式ではWordPress側の接続設定が必要です。サイトURLを入れ、公開REST APIで外から記事数などを確認するだけでは、記事の取り込みはできません。

ニュースにはタイトル・日付・本文、実績には画像・制作内容・期間、といった入力欄を作ります。こうした用途別の投稿欄が、カスタム投稿です。固定の会社案内まで投稿扱いにする必要はありません。問い合わせフォームは、入力画面の再現だけでなく、保存・通知メール・迷惑送信対策まで確認します。

5. 人が確認してから、公開先を切り替える

画面が表示されたら、元のサイトと見比べます。記事数が同じでも、本文中の画像や過去記事へのリンクが抜けていることはあるため、代表的なページを実際に開いて確かめます。

• ニュース・実績の件数と本文、分類、公開日、独自の入力項目の値が引き継がれているか。
• 画像が移行先から表示され、スマートフォンでも読めるか。
• 旧URLを開くと、対応する新ページへ正しく転送されるか。
• 問い合わせの保存と通知メール、解析が動くか。
• 下書きが一般公開されず、検索用タイトルやcanonicalが正しいか。

公開直前には、旧サイトでの記事と画像の追加・編集を一時停止し、最初の書き出し後に変わった内容を照合して反映します。再取り込みでは既存記事がスキップされるため、編集済みの本文まで自動で同期されるとは限りません。最後の差分を反映してから確認します。再取り込み時の扱い

canonicalは、検索エンジンに正規のURLを伝える設定です。検証用URLが残っていないかも確認します。確認が済んでから、ドメインの接続先を変えるDNSの切り替えを行い、本番でも同じ項目をチェックしてください。バックアップと旧環境は、問題があったときに戻せるよう保持します。旧環境を残す間も、必要なセキュリティ更新は止めません。

自社の移行では、更新する場所を3つに絞った

RealAIzeのコーポレートサイトは、WordPressからEmDashへ移行しました。既存の記事と画像、旧URLからの転送を引き継ぎ、日々の更新をニュース・実績・注目のサービスの3種類に整理しています。今回の制作期間は約1週間でした。移行事例の詳細

この約1週間は、当社サイトでの実績です。ページ数や独自機能、データの状態によって、ほかのサイトの期間は変わります。見た目を移すだけでなく、公開後に担当者が迷わず入力できるかまで確認しておきたいんですよね。

まずはAIエージェントにニュース1本の移行を頼んで、管理画面で編集し直せるか、画像とURLが保たれるかを試すところから始められます。そこまで確認すると、自社で進める範囲と、専門家へ任せたい範囲が見えてきます。

RealAIzeでは、WordPressからEmDashへの移行と、AIで更新できるホームページ制作を受け付けています。記事や画像を移す作業だけでなく、必要なカスタム投稿や問い合わせフォーム、公開後の更新手順まで含めて相談できるサービスです。