WordPressからの移行をお手伝いします｜EmDash・PHPに依存しないCMSへの引っ越し

「PHPの緊急アップデートが出たらしい。うちのWordPressは大丈夫なのか、誰に聞けばいいのかもわからない」。2026年10月下旬、こういう不安を抱えた方は少なくないはずです。

綴（Tsudzuri）は、WordPressからEmDashへの引っ越しと、EmDash以外も含めたPHPに依存しないCMSへの移行をお手伝いしています。ただし、全員に移行をすすめるわけではありません。PHPを更新して今のWordPressを続けられるなら、その道も同じ重さで提案します。この記事では、相談してほしい状況、引き受けられる作業の範囲、進め方、そしてこのサイト自体がEmDashで動いている実例まで、判断に必要な材料を順に並べました。

こんな状況なら、一度相談してください

いま困っていることが「脆弱性への不安」「保守の重さ」「止まったままのPHPのバージョン」のどれかなら、相談する価値があります。ポイントは3つです。

• PHPの緊急アップデートに追いつけていない
• 更新と保守そのものが負担になっている
• サーバーやPHPのバージョンが古いまま止まっている

PHPの緊急アップデートに追いつけていない

2026年10月21日（UTC）、PHPの開発チームが深刻度の高いセキュリティ更新を公開しました。修正版は 8.5.12・8.4.27・8.3.36・8.2.35 です。php.netの公式発表では、認証なしで外からコードを実行されるおそれがあるとされています。

これはPHP本体の問題なので、WordPress本体やプラグインを更新しても直りません。サーバー側のPHPを上げる必要があります。同じ系列の中での更新（たとえば 8.3 系なら 8.3.36 へ）は、レンタルサーバーなら事業者の対応待ちです。PHP 8.1 以下には通常の修正版が出ていません。php.net が出したのは最小限のソース修正だけなので、サーバーの管理画面などで 8.2 以上へ切り替える必要があります。自分で管理するサーバーなら、どちらも自分で上げますが、どちらなのかわからない時点で、一度相談してほしいと考えています。

脆弱性の中身と、いまやるべき確認は「PHPに緊急の脆弱性2件（2026年10月）WordPressサイトで今日やること」にまとめました。

更新と保守そのものが負担になっている

本体・テーマ・プラグインの更新通知が来るたびに、表示が崩れないか心配しながらボタンを押す。そんな運用が続いているなら、問題は今回の脆弱性だけではありません。更新を確かめる人や時間が足りていないなら、体制か仕組みのどちらかを見直す時期です。WordPressのままでも、ステージング環境で試してから反映する形にすれば不安は減らせます。EmDashに移っても、更新作業そのものはなくなりません。

問題は穴そのものより、体制です。

担当者が退職して、管理画面のパスワードしか引き継がれていないという状態のサイトも、制作の現場ではよく見かけます。

サーバーやPHPのバージョンが古いまま止まっている

WordPressの公式は、PHP 8.3 以上を動かせるサーバーを推奨しています（WordPressの動作環境）。古いPHPのまま動いているサイトは、テーマやプラグインが新しいPHPで動くかの確認から始まります。ここで「直すより移したほうが早い」と判断できる場合もあれば、逆の場合もある。どちらになるかは中を見てから決めます。

テーマとプラグインが新しいPHPで問題なく動くと確かめられれば、サーバーのPHPを上げるだけで済むので、移行の見積もりより先にその確認をする価値があります。

お手伝いできる範囲

現状の調査から公開後の保守まで、ひとりで通して引き受けられます。下の表は、それぞれの作業と、その根拠になっている実装や実績を並べたものです。

取り込み機能で運べるもの、人の手が要るもの

EmDashには、WordPressからの取り込み機能が管理画面に入っています。上のスクショのように、入口は3つです。1つ目は、WordPress側にEmDash Exporterプラグインを入れて移行キーで接続する方法。2つ目は、サイトのURLを入れてWordPress側で接続を承認する方法です。Exporterを入れていない場合、URLからできるのはWordPressかどうかの判定と件数の確認までです。3つ目は、WordPressの書き出しファイル（WXR、.xml）を直接アップロードする方法です。

記事・固定ページ・画像・カテゴリとタグは、この機能で機械的に運べます（公式の移行ガイド）。画像は取り込みのときに旧サイトから取得するので、取り込みが終わるまで旧サイトは止めません。カスタム投稿タイプやカスタムフィールドの値は、EmDash側に対応する定義を用意してから運びます。一方で、プラグインが担っていた機能、つまりフォームや独自のショートコードなどは作り直しです。工数の差が出るのは、運べない側の量です。だから調査の段階で、そこを先に洗い出します。

工数を決めるのは、運べない側。

手順の細かい話はWordPressからEmDashへ移行する手順で書いています。

制作会社からも、事業者さんからも受けています

依頼の入り口は2つあり、どちらも普段から受けている形です。ポイントは2つです。

• 制作会社の案件に、実装担当として入る
• 事業者さんから直接、相談から公開まで受ける

制作会社からの依頼（実装パートナーとして）

デザインは御社、実装と移行作業は綴、という分け方です。これまでもデザインカンプを受け取ってWordPressテーマに組む案件を何件も担当してきました。移行案件でも同じで、ディレクションとお客さまとの窓口は御社のまま、裏側の作業を引き受けます。

窓口は御社、手は綴。

移行案件の難しさは、WordPressの中身とEmDash側の両方を読める人が要ることです。私はWordPressのカスタム投稿タイプやカスタムフィールドを組んできた側なので、移行元の構造を読むところから入れます。

事業者さんからの直接依頼

サイトの持ち主から直接、相談を受けることもできます。この場合はヒアリングと情報設計から入ります。

実例として、ペライチで作られていた1ページのサイトを、多階層のWordPressサイトへ作り直した案件があります（みらいベースの制作実績）。元の世界観を保ったまま、拠点やアカデミーが増えてもスタッフが自分で更新できる形にしました。デザインと情報設計から作り直した案件ですが、既存のサイトを運用しやすい別の仕組みへ移した点で、移行と地続きの仕事です。

進め方は7ステップです

相談から保守までを7つに分け、各段階で何を決めるかを先に共有します。いきなり作り始めることはしません。

調査で洗い出すもの

2つ目の「調査・棚卸し」で、移行の手間はほぼ決まります。見るのは次の5つです。

• ページと記事の数、カスタム投稿タイプの有無
• 入っているプラグインと、それぞれが担っている機能
• お問い合わせなどのフォームと、送信先のメールアドレス
• いまのURLの形（日付入りか、?p=123 のような形か）
• 計測タグ（Googleアナリティクスなど）の設置場所

URLの形と計測タグは公開後に気づくと直しにくいので、調査の時点で旧URLの一覧とタグの置き場所を控えておくと、公開日の作業が軽くなります。

公開までに必ずやること

確認はテスト環境で一周してから、本番に進みます。URLが変わるページには転送（リダイレクト）を用意し、旧サイトは問題がないと確かめられるまで動かしたままにしておく。この2点を守れば、検索からの流入を大きく落とさずに引っ越しやすくなります。転送の置き場所の考え方は旧URLの受け皿をどこに置くかで詳しく書いています。

このサイト自体がEmDashで動いています

人にすすめる前に、自分のサイトで使っています。いま読んでいるtsudzuri.comは、AstroとEmDashで作り、Cloudflareで動かしているサイトです。

構成と、PHPが関係しない理由

公開しているサイトは、Cloudflare Workers の上で動いています（Cloudflare Workersの公式ドキュメント）。記事のデータは D1、画像は主に R2 に置いています。サーバーにPHPがそもそも入っていません。今回のPHPの脆弱性はこのサイトには関係しません。EmDashはAstroの上で動くCMSで、動かすのにPHPを必要としません（EmDashの公式ドキュメント）。

ただし「PHPがない＝何もしなくていい」ではなく、npmの依存パッケージの更新は自分で続けています。EmDashとPHPの脆弱性の関係は、EmDashへの影響を整理した記事で詳しく書いています。

運用してわかっていること

開発は手元のパソコンで、同じコードをNode.jsとSQLiteで動かして確かめる形です。上のスクショはその管理画面です。本番に出すときは、環境変数ひとつで Workers・D1・R2・KV の構成に切り替わる作りにしてあります。

予約した記事は5分ごとに動く定期実行で公開され、記事ページの構造化データはEmDashが自動で出力します。パンくずの構造化データは自分で組み、OGPはEmDashの出力に画像や記事の情報を渡す形で整えました。移行のお手伝いでも、同じ考え方で組み込めますが、予約公開の定期実行はCloudflare側の設定（Cron Trigger）が前提です。構成の全体はこのポートフォリオの舞台裏で紹介しています。

弱いところもあります。EmDashは2026年に公開されたばかりで、日本語の情報も扱える人もまだ少なく、プラグインの選択肢もWordPressより限られます。1.x系への更新では、本番のデータベースへ移行を手で流す作業も要りました。こうした点も含めて、続けるか移るかをご提案します。

よくある質問

WordPressを続ける選択肢もありますか？

あります。サーバーのPHPを修正版に上げられて、テーマとプラグインの更新も回っているなら、WordPressを続けるのは十分にまともな選択です。相談を受けた場合も、まずその道が取れるかを確かめます。移行は、更新を続ける体制が作れないときや、リニューアルの時期と重なるときに検討すれば間に合います。

移行先はEmDashしか選べませんか？

EmDash以外も選べます。更新頻度が低いサイトなら、Astroで静的なサイトにして、CMSを持たない形も一つの選び方です。記事を頻繁に足すなら、外部のヘッドレスCMS（表示部分を持たず、管理画面とAPIで記事データを渡すCMS）とAstroを組み合わせる方法もある。選び方はPHPに依存しないCMSを比べた記事にまとめています。

費用や期間はどのくらいかかりますか？

サイトの規模と、作り直しが要る機能の量で大きく変わります。一律の金額や期間はお伝えしていません。調査で棚卸しをしたうえで、内容に合わせた見積もりと予定をお出ししますが、「移せるかどうかだけ知りたい」という段階のご相談でも大丈夫です。

まとめ

PHPの修正版が出た直後のいまは、慌てて移行を決めるより、まず現状を正しく知ることが先です。今のWordPressを続けるのか、引っ越すのかを決める材料をそろえるところから手伝えますので、お問い合わせから気軽に声をかけてください。制作会社の方からの、実装パートナーとしてのご相談も受けています。

本記事は2026年10月時点の情報です。