2026年9月28日、Astro 向けの CMS「EmDash 1.0」が安定版として公開されました。公式サイトには、かなり印象に残る言葉が掲げられています。
EmDash is the spiritual successor to WordPress
日本語にすると「EmDash は WordPress の精神的後継」といった意味です。この表現を見て、「WordPress の次に使う CMS なのか」「今の WordPress サイトをそのまま移せるのか」と気になった方もいるのではないでしょうか。
先に結論をお伝えすると、EmDash は WordPress の公式な後継でも、WordPress と互換性のある派生版でもありません。 投稿、固定ページ、メディア、メニューなど、WordPress で親しまれてきた考え方を受け継ぎながら、Astro と TypeScript を前提に作られた別の CMS です。
WordPress からコンテンツを取り込む機能はありますが、WordPress のテーマやプラグインは動きません。既存サイトから移行する場合は、文章や画像を移す作業と、デザインや機能を作り直す作業を分けて考える必要があります。
この記事では、2026年9月29日に確認した公式情報を基に、EmDash 1.0 の仕組み、試し方、運用費、WordPress から移せるもの、両者の棲み分けを整理します。
EmDash は Astro 向けのフルスタック CMS
EmDash は、Astro で作る Web サイトへ管理画面やデータベースを組み込むための、オープンソース CMS です。Astro は、コンテンツを中心とした Web サイトを構築するためのフレームワークです。HTML に近い書き方でページを作りながら、必要に応じてサーバー側の処理も加えられます。
「フルスタック CMS」と呼ばれているのは、記事を編集する管理画面だけではなく、公開ページからコンテンツを読み出す仕組み、データベース、メディア保存、API などを一つの Astro アプリケーションへまとめられるためです。
TypeScript は、JavaScript に型の検査を加え、データの形や関数の使い方の間違いを開発時に見つけやすくする言語です。
公式ドキュメントの構成を、役割ごとに分けると次のようになります。
| 構成 | 主な役割 |
|---|---|
| Astro | 公開ページ、URL、レイアウト、コンポーネントを作る |
| TypeScript | 公開画面や独自機能の処理を書く。データ項目の型も確認できる |
| EmDash 管理画面 | 投稿、固定ページ、メディア、メニュー、タクソノミー（カテゴリーやタグのように内容を分類する仕組み）などを編集する |
| EmDash ランタイム | 公開状態、データ取得、プラグイン、API など CMS の動作をまとめる |
| データベース | 記事、ユーザー、設定、コンテンツの項目定義などを保存する |
| メディアストレージ | アップロードした画像やファイルを保存する |
| MCP、REST API、CLI | AI ツールや外部プログラム、コマンドから CMS を操作する窓口になる |
MCP は、AI ツールが外部のサービスやデータを決められた方法で扱うための仕組みです。REST API はプログラム同士、CLI はターミナル上のコマンドから操作するための窓口です。
EmDash では、管理画面と公開サイトが同じアプリケーション内で動きます。別サービスとして CMS を契約し、API で Astro へ接続する一般的なヘッドレス CMS とは、運用する範囲が少し異なります。
一方、EmDash は画面上で自由にレイアウトを組み立てるビジュアルページビルダーではありません。文章や画像などの構造化された内容は EmDash で管理し、見た目と表示方法は Astro 側で実装するのが基本です。
AI を使わなくても利用できる
公式サイトは EmDash を「agent-ready」と表現しています。これは、AI エージェントから扱うことを想定し、MCP サーバー、REST API、CLI が最初から用意されているという意味です。
たとえば、権限を与えた AI ツールから、コンテンツの検索、下書き作成、編集、公開予約などを行える設計です。ただし、AI がなければ管理できない CMS ではありません。通常の管理画面から人が投稿やメディアを管理できます。
「AI 対応」という言葉だけを見ると、AI がサイト制作や運用をすべて代わってくれるようにも聞こえます。実際には、AI が操作できる窓口が用意されていることと、内容の正確性や公開判断を任せられることは別です。権限設計、確認、承認の流れは人が決める必要があります。
「WordPress の精神的後継」は公式な後継という意味ではない
「spiritual successor」は、EmDash 自身が掲げる位置づけです。公式サイトでは、次のように表現されています。
EmDash is the spiritual successor to WordPress
一方、公式ドキュメントの「Why EmDash」には、互換性の限界について次の記載があります。
EmDash does not run PHP, WordPress themes, or WordPress plugins.
日本語にすると「EmDash では、PHP、WordPress テーマ、WordPress プラグインは動作しない」という意味です。さらに同じ箇所で、WordPress のコンテンツは取り込めるものの、サイトのデザインや独自のプラグイン機能は Astro と EmDash 向けに実装する必要があると説明されています。
このため、「spiritual successor」は WordPress との互換性を示す技術用語ではなく、WordPress のコードを引き継いだ派生版という意味でもありません。
受け継ごうとしているのは、主に CMS としての考え方と編集体験です。
- 投稿と固定ページを管理画面から編集する
- 下書き、公開予約、リビジョンを扱う
- 画像やファイルをメディアとして管理する
- カテゴリーやタグなどのタクソノミーで整理する
- メニューやウィジェット領域を編集する
- テーマやプラグインに相当する仕組みでサイトを拡張する
これらの名前や考え方には、WordPress を使った経験がある人にも分かりやすい部分があります。ただし、裏側の技術は異なります。WordPress は PHP を中心に動き、テーマとプラグインも PHP を含むファイルで構成されます。EmDash は Astro と TypeScript を前提にしています。
「精神的後継」は、使い方の発想を受け継ぐという EmDash 側の主張であり、既存の WordPress サイトをそのまま置き換えられるという保証ではありません。
EmDash を試す方法と公開までの流れ
EmDash を使い始める方法は、大きく 3 つあります。
Playground で管理画面を試す
EmDash Playground では、ブラウザ上に試用環境を作り、管理画面の操作感を確認できます。まず投稿やメディアの編集画面を見たい場合は、この方法が最も手軽です。
ただし、Playground で操作できることと、実際のサイトを公開して運用できることは別です。本番環境ではデータベース、メディア保存、ドメイン、バックアップなども設計します。
新しい EmDash サイトを作る
ローカル環境で新規作成する場合は、Node.js 22.16 以降と npm などのパッケージ管理ツールを準備し、次のコマンドを実行します。
npm create emdash@latest対話形式で公開先やテンプレートを選び、依存パッケージをインストールします。その後、開発用サーバーを起動し、初期設定、管理者アカウントの作成、コンテンツ項目の設定、公開ページの実装へ進みます。
既存の Astro プロジェクトへ追加する
Astro 6 以降で作られた既存プロジェクトへ、EmDash、Node.js または Cloudflare 用のアダプター、管理画面用の React などを追加する方法もあります。
既存サイトへ追加する場合は、Astro の出力方法や公開環境が変わる可能性があります。現在の設定を保存し、データベースとメディア保存の方法を決めてから進める必要があります。
Cloudflare または Node.js へ公開する
公式ドキュメントでは、主に次の 2 つの構成が案内されています。
| 公開方法 | データベース | メディア保存 | 確認したいこと |
|---|---|---|---|
| Cloudflare Workers | Cloudflare D1 | Cloudflare R2 | Workers、D1、R2 の設定、利用量、無料枠、従量課金 |
| Node.js | SQLite、libSQL、PostgreSQL | ローカルディスクまたは Amazon S3 と同じ接続方式を使える S3 互換ストレージ | Node.js 対応ホスティング、永続保存、バックアップ、常時稼働 |
Cloudflare 構成では、役割の異なる 3 つのサービスを組み合わせます。
- Cloudflare Workers：EmDash のアプリケーションを動かし、公開ページや管理画面を返す実行環境
- Cloudflare D1：記事、ユーザー、設定などのデータを保存するデータベース
- Cloudflare R2：アップロードした画像やファイルを保存する場所
Workers Free は Workers の無料プラン、D1 Free はその無料プランで D1 を使う場合の料金区分です。R2 Standard の Standard は無料プランの名前ではなく、R2 の標準的な保存方式を指します。R2 Standard には毎月の無料枠があり、それを超えた利用量が課金対象になります。
Cloudflare は公式テンプレートとの組み合わせが分かりやすい一方、Node.js は利用するホスティングやデータ保存先を選べます。どちらが良いかは、既存の契約、運用できる技術、アクセス量、保存量、障害時の対応方法によって変わります。
EmDash は無料でも、サイト運用全体が無料とは限らない
EmDash 本体は MIT ライセンスのオープンソースソフトウェアで、ソフトウェア自体の利用料はありません。WordPress 本体も GPLv2 以降で提供され、ライセンス料を払わずに利用できます。
どちらも、CMS 本体が無料であることと、Web サイトを無料で運用できることは同じではありません。
| 費用・作業 | EmDash で考える内容 |
|---|---|
| CMS 本体 | MIT ライセンス。利用料は不要 |
| ドメイン | 独自ドメインを使う場合の取得・更新費 |
| ホスティング | Cloudflare Workers または Node.js 対応環境 |
| データベース | D1、SQLite、libSQL、PostgreSQL などの運用費 |
| メディア保存 | R2、S3 互換ストレージ、永続ディスクなどの保存費 |
| メール | パスワード確認や通知に使うメール配信サービス |
| 開発 | Astro によるデザイン、ページ、独自機能の実装 |
| 保守 | EmDash、Astro、依存パッケージ、DB、保存領域の更新と監視 |
| バックアップ | DB とメディアを別々に保存し、復元を確認する作業 |
2026年9月29日に Cloudflare の公式料金を確認したところ、Workers Free は 1 日 10 万リクエストまで、Workers Paid は月額最低 5 米ドルで月 1,000 万リクエストを含む内容でした。
D1 Free は 1 日 500 万行の読み取り、10 万行の書き込み、合計 5 GB の保存までです。ここでいう「行」はデータベース内のデータ件数であり、サイトの閲覧回数ではありません。1 回のページ表示でも、処理する内容によって複数行を読み取ることがあります。
R2 Standard には月 10 GB-month の保存、Class A 操作 100 万回、Class B 操作 1,000 万回の無料枠があります。GB-month は、1 か月に保存したデータ量の平均を表す単位です。Class A は主にファイルの保存など内容を変更する操作、Class B は主にファイルを読み出す操作を指します。
小規模サイトが無料枠に収まる可能性はあります。ただし、アクセス数だけでなく、管理画面や API の利用、DB の読み書き、画像容量、バックアップ、メール、独自機能によって必要な費用は変わります。
Workers Free で 1 日のリクエスト上限へ達すると、Cloudflare は Error 1027 を返します。ルート設定が fail closed の場合はエラーページになり、fail open の場合は Worker を迂回します。ただし、ページの生成自体が Worker の処理に依存する構成では、迂回しても正常に表示できるとは限りません。
また、D1 Free で 1 日の読み取り・書き込み上限へ達すると、協定世界時の午前 0 時に上限がリセットされるまでデータベースへの問い合わせが失敗します。保存済みのデータが削除されるわけではありませんが、EmDash は公開ページの表示時に D1 から記事を読み出す構成を取れるため、実装やエラー処理によっては、公開ページを閲覧できなくなったり、管理画面で更新できなくなったりする可能性があります。
一方、R2 Standard の無料枠は料金上の控除枠であり、超過分は公式料金に基づく課金対象になります。このように、無料枠を超えたときに処理が止まるサービスと、利用を継続しながら課金されるサービスを分けて確認する必要があります。
R2 は、利用前にクレジットを購入しておく方式ではありません。利用を始めるには、Cloudflare の画面で R2 のサブスクリプションを有効にし、有効な支払い方法を登録します。無料枠に収まっている月は請求額が 0 米ドルになり、超えた分は利用実績に応じて後払いで請求されます。支払い方法はクレジットカードやデビットカードのほか、PayPal、Apple Pay、Google Pay、Stripe Link などにも対応しています。
登録した支払い方法の確認や決済に失敗した場合、Cloudflare は R2 へのアクセスを停止することがあります。この状態では R2 の保存領域へアクセスするリクエストがエラーになるため、R2 に保存した画像やファイルがサイト上で表示されなかったり、管理画面からメディアを追加・参照できなくなったりする可能性があります。支払い方法を更新するまではデータが直ちに消えるわけではありませんが、Cloudflare の請求方針では、30 日以内に更新しない場合、利用量に応じて課金されるサービスのデータが削除される可能性も示されています。
Node.js 構成では、利用する仮想サーバー（VPS）やホスティング、DB、S3 互換ストレージの料金が提供元によって異なります。「EmDash は無料」という説明だけで運用費を判断せず、構成図と利用サービスを決めてから月額費用と保守作業を見積もる必要があります。（2026年9月29日確認）
WordPress と EmDash の内部構成を比べる
WordPress の言葉をそのまま EmDash へ当てはめると、テーマとプラグインの理解で混乱しやすくなります。役割の近いものを並べると、次のように整理できます。
| 役割 | WordPress | EmDash／Astro | 主な違い |
|---|---|---|---|
| CMS 本体 | WordPress 本体 | EmDash ランタイム | PHP 中心か、Astro・TypeScript 中心か |
| 管理画面 | wp-admin | EmDash 管理画面 | どちらも編集画面を持つが、画面と機能は同一ではない |
| コンテンツ | 投稿、固定ページ、カスタム投稿タイプ | コレクションとフィールド | EmDash は項目の型を明示する |
| 公開画面 | WordPress テーマ | Astro のページ、レイアウト、コンポーネント | WordPress のテーマファイルは利用できない |
| 初期雛形 | テーマのインストール | EmDash テーマ | EmDash では Astro プロジェクト一式を複製し、その後はサイト側のコードとして編集する |
| 機能拡張 | WordPress プラグイン | sandboxed plugin、native plugin | プラグイン形式と実行環境に互換性はない |
| データベース | 主に MySQL または MariaDB | D1、SQLite、libSQL、PostgreSQL | 保存先と運用方法が異なる |
| メディア | wp-content/uploads など | R2、S3 互換、ローカル保存 | DB のバックアップだけでは画像を復元できない |
| 外部操作 | REST API、WP-CLI など | MCP、REST API、CLI | EmDash は AI エージェントからの利用も前提に設計している |
EmDash の「テーマ」は WordPress テーマと同じではない
EmDash のテーマは、公開ページ、コンポーネント、設定、初期コンテンツモデルなどをまとめた Astro プロジェクトの雛形です。雛形からサイトを作成したあとは、テーマのファイルがそのサイト自身のコードになります。
WordPress のように、実行中のテーマパッケージを管理画面から切り替えたり、テンプレート階層に沿って PHP ファイルを選んだりする仕組みではありません。ページの URL は src/pages/、共通レイアウトは src/layouts/、表示部品は src/components/ など、Astro 側で実装します。
2 種類の EmDash プラグイン
EmDash には、sandboxed plugin と native plugin があります。
sandboxed plugin：分離された実行環境で動き、宣言して許可された EmDash API や外部通信先へアクセスするnative plugin：Astro サイトと同じプロセスで動き、React の管理画面部品や公開ページの表示部品など、より深い拡張を行う
sandboxed plugin は、権限を限定しやすいことが特徴です。一方、すべての拡張が自動的に安全になるわけではありません。許可する権限、外部通信、更新元、保守状況を確認する必要があります。native plugin は実行環境へ広くアクセスできるため、導入前のコード確認と更新体制がより重要になります。
WordPress プラグインは PHP を中心とした WordPress 用の仕組みです。ファイルを EmDash へコピーしても動作しないため、必要な機能を EmDash 向けに作り直すか、外部サービスへ置き換えます。
EmDash のプラグインは WordPress より安全なのか
EmDash の公式サイトは、プラグインが分離された環境で動くことを、安全性に関する特徴として紹介しています。公式資料で確認できる sandboxed plugin の主な仕組みは次の通りです。
- プラグインごとに分離された実行環境で動かす
- 記事、メディア、ユーザー、外部通信など、必要な権限をプラグイン側が宣言する
- インストール時に、発行者、検証状態、要求される権限を管理者へ表示する
- 更新で権限が増える場合は、改めて管理者の承認を求める
- 環境変数やファイルシステムへ直接アクセスさせず、外部通信先も許可されたホストへ制限する
- 配布ファイルのチェックサム、名前、バージョン、権限を検証し、設定されている場合はビルド元の証明も確認する
これらは、問題のあるプラグインがサイト全体へ与える影響を小さくするための仕組みです。WordPress プラグインの一般的な実行方式と比べ、プラグインに最初からすべての権限を渡さない点は、EmDash の設計上の強みといえます。
ただし、権限を制限する仕組みと、プラグインのコードに脆弱性や悪意がないことを確認する仕組みは別です。 許可された権限の範囲内で不適切な処理を行うプラグインや、プラグイン自身が扱うデータの不具合までは、実行環境を分けるだけでは防げません。EmDash の公式ドキュメントも、信頼できる発行者のコードだけをインストールするよう注意しています。
また、この保護は sandboxed plugin が、設定された sandbox runner 上で動いている場合に限られます。native plugin は Astro サイトと同じプロセスで動き、実行環境へ広くアクセスできます。EmDash のプラグインだから必ず分離されるわけではありません。
プラグインをチェックするエコシステムはあるのか
EmDash には、sandboxed plugin を配布するプラグインレジストリがあります。発行者の識別、配布ファイルの改変検知、権限の照合、ビルド元の証明、セキュリティ連絡先といった仕組みは用意されています。サイト運営者は、信頼するモデレーション情報の提供元を指定したり、公開直後のバージョンを一定期間インストール対象から外したりすることもできます。
一方、2026年9月29日時点の公式資料では、WordPress.org と同様の人による新規掲載時のコードレビュー、全更新を対象にした脆弱性スキャン、危険度に応じた自動的な配信停止が、EmDash の全レジストリプラグインへ適用されるとは確認できませんでした。レジストリ自体も公式ドキュメントで「Experimental」とされています。チェックサムやビルド元の証明は、配布物が途中で書き換えられていないことを確かめる仕組みであり、コードが安全であることの審査ではありません。
WordPress.org では、新規掲載時に Plugin Review Team がコードを確認します。さらに2026年9月時点では、各リリースを配信前に一定時間保留し、複数の AI モデルと Jetpack Scan で検査し、危険度が高い更新を自動的に止める仕組みが導入されています。セキュリティ問題やガイドライン違反を報告し、掲載停止を含む対応を求める窓口もあります。
これらは WordPress.org のプラグインディレクトリを通じて配布されるプラグインの仕組みです。開発元のサイトなどから直接購入・導入するプラグインに、同じ審査が適用されるわけではありません。また、WordPress.org の審査を通ったプラグインであっても、将来の更新を含めて脆弱性がないと保証されるわけではありません。
現時点では、実行中の被害範囲を制限する設計は EmDash の sandboxed plugin に強みがあり、掲載・更新時の審査と継続的な監視体制は WordPress.org の方が成熟していると整理するのが妥当です。「EmDash のプラグインは WordPress のプラグインより安全」と一括りにはできません。
WordPress から移せるものと、作り直すもの
EmDash には、WordPress の管理画面から出力した WXR ファイルを使う方法と、WordPress へ EmDash Exporter を追加して接続する方法があります。WXR は、WordPress の「ツール → エクスポート」で作成できる XML 形式のファイルです。
公式ドキュメントで確認できる範囲を整理すると、次のようになります。
| 分類 | 移行で扱えるもの | 再構築・確認が必要なもの |
|---|---|---|
| WXR | 投稿、固定ページ、カスタム投稿タイプ、カテゴリー、タグ、カスタムタクソノミー、投稿者、添付 URL など | メディア本体の取得、URL、公開状態、未対応フィールドの確認 |
| EmDash Exporter | 対応するコメント、メニュー、サイト設定、SEO 項目、タクソノミー、メディア情報、対応するカスタムフィールド | 直列化された PHP 値、ACF の繰り返し・柔軟コンテンツ、プラグイン固有構造 |
| デザイン | 直接移行する対象ではない | Astro のページ、レイアウト、コンポーネントとして再実装する |
| プラグイン機能 | 直接移行する対象ではない | EmDash プラグイン、Astro のコード、外部サービスなどで再実装する |
| URL・SEO | 一部の SEO 項目を Exporter 経由で扱える | パーマリンク、リダイレクト、正規 URL、構造化データ、サイトマップを確認する |
| 編集内容 | Gutenberg やクラシックエディターの内容を変換する | ショートコード、ページビルダー、独自ブロックの表示を個別確認する |
WXR には添付ファイル本体ではなく、元サイト上の URL が記録されます。画像を取り込む間は、元の WordPress サイトとメディアへアクセスできる状態を維持する必要があります。
また、WordPress の publish は EmDash の公開済みへ移されますが、予約、非公開、ごみ箱などは下書きとして扱われます。予約日時や公開範囲がそのまま再現されるわけではないため、公開前に 1 件ずつ確認します。
移行機能があることと、サイト全体をそのまま引っ越せることは別です。 コンテンツ、見た目、機能、URL、運用権限を分けて調査し、新しいサイトで再現する範囲を決めます。
WordPress と EmDash を 8 つの観点で比較する
| 比較する観点 | WordPress | EmDash |
|---|---|---|
| 編集体験 | 投稿、固定ページ、ブロックエディター、メディアなど、成熟した管理画面を利用できる | 投稿、固定ページ、メディア、メニュー、タクソノミーなど、WordPress に近い概念を持つ |
| 構築に必要な技術 | 管理画面だけで始めやすい構成もあり、独自開発では PHP、HTML、CSS、JavaScript などを使う | Astro、TypeScript、Node.js、データベース、ストレージの理解が必要 |
| ホスティング | PHP と MySQL／MariaDB に対応する多数のレンタルサーバーで利用できる | Cloudflare Workers または Node.js 対応環境で運用する |
| 更新・保守 | WordPress 本体、テーマ、プラグイン、PHP、DB、サーバーを管理する | EmDash、Astro、依存パッケージ、Node.js、DB、ストレージ、公開環境を管理する |
| 拡張性 | WordPress プラグインと独自開発を利用する | EmDash プラグイン、Astro コンポーネント、TypeScript で拡張する |
| エコシステム | 長年蓄積されたテーマ、プラグイン、情報、事業者がある | 1.0 公開直後で、プラグインや運用事例は今後増える段階 |
| 移行互換性 | WordPress 同士では WXR などを利用できる | WordPress のコンテンツを取り込めるが、テーマとプラグインには互換性がない |
| AI エージェント連携 | REST API や追加機能など、構成に応じて連携する | MCP、REST API、CLI を標準で用意し、エージェントからの操作を想定している |
WordPress には、長い運用実績と大きなテーマ・プラグインのエコシステムがあります。EmDash は 1.0 が公開されたばかりであり、現時点の情報だけで「WordPress の代替」や「次世代の標準」と断定することはできません。
一方、Astro で新しいサイトを作り、編集者向けの管理画面と AI エージェント用の操作窓口を同じアプリケーションへ組み込みたい場合は、EmDash が具体的な候補になります。
EmDash が候補になりやすい場合
次の条件がそろう場合は、EmDash を検証する意味があります。
- 新規サイト、または Astro で公開画面を作り直す計画がある
- 開発者が Astro、TypeScript、Node.js を扱える
- 編集者にはコードを触らず使える管理画面が必要
- DB、メディア、バックアップ、更新を運用できる
- MCP、REST API、CLI を使った自動化を検討している
- 必要な機能を EmDash 向けに実装または選定できる
特に、すでに Astro を使っており、ファイルを直接編集できない担当者にも更新を任せたい場合は、EmDash の考え方と合いやすいでしょう。
WordPress を継続する方が現実的な場合
次のようなサイトでは、キャッチコピーだけを理由に移行しない方がよいと考えています。
- 現在の WordPress サイトが安定して動いている
- 利用中のテーマやプラグインへ強く依存している
- WooCommerce、会員、予約、多言語、フォームなどの機能を運用している
- 社内担当者が WordPress の操作に慣れている
- Astro と TypeScript を保守できる担当者や依頼先がいない
- 移行後の URL、SEO、計測、外部連携を検証する予算を確保できない
WordPress を使い続ける場合にも、更新と保守は必要です。ただ、動いている仕組みを新しい技術へ移すこと自体が目的になると、利用者に見えない再構築へ時間と費用を使うことになります。
僕は、CMS の新しさよりも、誰が更新し、誰が開発と保守を続けられるのかを先に確認する方が大切だと考えています。EmDash と WordPress のどちらが優れているかではなく、サイトの目的と運用体制に合う方を選ぶのが現実的です。
自分で確認できること
EmDash を試したい段階では、次の内容を整理できます。
- Playground で管理画面の操作感を確認する
- 現在のサイトが WordPress か、Astro か、別の仕組みか確認する
- 投稿、固定ページ、画像、メニューなど、移したい内容を書き出す
- 使用中のテーマとプラグインを一覧にする
- 予約、フォーム、会員、EC など、止められない機能を確認する
- サイトを更新する人と、コードや公開環境を保守する人を分けて考える
- 現在のドメイン、サーバー、DB、メール、外部サービスの契約を確認する
本番サイトを移行する前に、検証用の EmDash サイトへ一部のコンテンツを取り込み、表示、URL、画像、編集方法を確認するのが安全です。
専門家へ相談した方がよい状態
次のような場合は、WordPress の停止や DNS の切り替えを行う前に、WordPress と Astro の両方を確認できる制作者へ相談した方がよいでしょう。
- どのプラグインが現在の機能を支えているか分からない
- 独自テーマ、独自プラグイン、ページビルダー、ショートコードを使っている
- 会員情報、注文、予約、問い合わせなど、失うと困るデータがある
- 現在の URL や検索流入を維持したい
- メディア、バックアップ、リダイレクトの移行方法を決められない
- Cloudflare または Node.js の運用担当者が決まっていない
- 移行後も更新と障害対応を続けられるか判断できない
移行を相談するときは、サイトの URL、WordPress とサーバーの管理権限、使用中のテーマとプラグイン、必要な機能、更新担当者、希望時期、予算を整理しておくと、調査範囲を決めやすくなります。最初の問い合わせにパスワードや秘密鍵を書く必要はありません。
「後継」という言葉ではなく、運用できる構成かで判断する
EmDash は、WordPress で親しまれてきた編集概念を Astro へ持ち込み、AI エージェントからも扱えるようにした、興味深い CMS です。特に、新しい Astro サイトで編集者向けの管理画面が必要な場合は、検証する価値があります。
ただし、WordPress サイトをそのまま置き換える製品ではありません。コンテンツの一部は移行できますが、デザイン、テーマ、プラグイン、独自機能、URL は別途確認し、必要に応じて作り直します。EmDash 1.0 は公開されたばかりなので、プラグイン、事例、運用ノウハウの増え方も見ていきたいところです。
オレインデザインでは、WordPress サイトの構成調査や、既存サイトを直して使うか、別の構成へ移すかを整理するご相談を受け付けています。EmDash の導入や移行を確約するものではありませんが、現在のテーマ、プラグイン、コンテンツ、管理状況を確認し、移行前に整理すべき範囲を一緒に検討できます。
現在のサイト URL、困っていること、残したい機能、更新担当者、手元にある資料を分かる範囲でまとめて、お問い合わせフォームからご相談ください。
本記事は、すべて2026年9月29日に確認できた情報に基づいています。最新の情報は必ず EmDash 公式サイト等から確認してください。
