EmDashはWordPressの本当の代替になり得るか？

EmDashは、プラグインへの依存が少ないコンテンツ中心のサイトで、Astroでの開発に慣れたチームであれば、すでにWordPressの代替として使えます。ただし、PHPテーマや特定のWordPressプラグイン、有料拡張機能に依存しているサイトを、そのまま置き換えられる段階にはまだありません。

プラグイン経由でWordPressサイトを侵害された経験のあるクライアントは、決まって「もっと安全な選択肢はないのか」と尋ねます。EmDashが「WordPressの精神的後継」というキャッチコピーとともにバージョン1.0に到達したことで、多くの制作会社が改めてこの問いに向き合い始めました。

本記事では、プラグインのセキュリティモデル、ホスティング要件、移行、そして失うものの4つの観点から、EmDashとWordPressを比較します。

EmDash CMSとは？

EmDashは、Astro上に構築されたオープンソースのTypeScript製CMSです。MITライセンスで提供され、CloudflareまたはNode.jsサーバー上で動作します。CloudflareによるEmDash 1.0の発表では、「本番環境のWebサイトを支える準備が整った」安定版の無料オープンソースCMSと位置付けられています。

役割ごとに異なる利用方法が用意されています。開発者はAstroでサイトを構築し、編集者はEmDashの管理画面で作業します。AIエージェントは、API、CLI、または組み込みのModel Context Protocol（MCP）サーバーを通じてコンテンツの読み取りや変更を行えます。新しいサイトの雛形は次のコマンドで作成できます。

npm create emdash@latest

Cloudflareによると、同社は1.0リリースに先立つ8月に、自社ブログをEmDashへ移行したとのことです。

EmDashのプラグインモデルはWordPressとどう違うのか？

両者の最大の違いはプラグインモデルにあります。WordPressでは、すべてのプラグインがサイトと同じPHPプロセス内で動作し、データベース、ファイルシステム、ネットワークにアクセスできます。一方、サンドボックス化されたEmDashプラグインは隔離された状態から始まり、必要な機能を一つひとつ要求しなければなりません。

CloudflareのEmDash 1.0の記事によると、サンドボックス化されたプラグインに与えられるのは自身専用のプライベートストレージのみです。サイトのコンテンツ、メディア、ユーザー、シークレット、環境変数、ファイルシステム、ネットワークは、デフォルトですべて閉ざされています。それ以外のものにアクセスするには、モバイルアプリの権限と同様に、プラグインが必要性を宣言し、サイト管理者が承認する必要があります。Cloudflareが挙げている例は画像最適化プラグインで、メディアの読み取りと管理は要求しますが、ユーザーのコンテンツは読み取れません。

EmDashのプラグインレジストリは分散型です。AT Protocol上に構築されており、パブリッシャーは自身のパッケージとリリースのレコードに署名し、自分のAtmosphereアカウントに保存します。EmDashのカタログがモデレーションによって掲載を非表示にしても、プラグインとそのリリース履歴の所有権はパブリッシャーに残ります。

ただし、サンドボックスには例外が1つあります。設定リファレンスによると、plugins配列はAstroサイトと同じプロセスを共有するプラグイン用であり、ネイティブプラグインはここに記述します。これらのプラグインは隔離されずに動作します。なお、レジストリからインストールしたプラグインは必ずサンドボックスを経由します。

EmDashはCloudflareとNode.jsのどちらでホストすべきか？

EmDashはCloudflareとNode.jsのどちらでもホストできますが、サンドボックスの動作はそれぞれ異なります。Cloudflareは費用がかかる分、より多くの制限を強制します。Node.jsのランナーは追加費用がかからない代わりに、強制される制限が少なくなります。

これらの要件はプラグインサンドボックスのドキュメントに記載されています。ランナーがない場合、EmDashはsandboxed: []に列挙されたすべてのプラグインをスキップします。自分で設定したレジストリの閲覧は引き続き可能ですが、サンドボックス化されたプラグインのインストールや更新はSANDBOX_NOT_AVAILABLEエラーで停止します。サイトのその他の部分は通常どおり動作します。

Node.jsの場合は、Nodeアダプターとサンドボックスランナーをインストールし、設定ファイルでランナーを指定します。

npm install @astrojs/node @emdash-cms/sandbox-workerd workerd

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";
import emdash from "emdash/astro";
import { sqlite } from "emdash/db";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
  integrations: [
    emdash({
      database: sqlite({ url: "file:./data/emdash.db" }),
      sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox",
    }),
  ],
});

ケーパビリティのドキュメントでは、Node.jsのランナーが強制するのは30秒のウォールタイム制限のみであることが明記されています。サイトでCPU、メモリ、サブリクエストの制限を設定している場合、スタンドアロンのworkerdではそれらを適用できないため、ランナーは警告をログに出力します。つまりNode.js上では、CPUを過剰に消費するプラグインも、ウォールタイム制限に達するまでは停止されません。

WordPressからEmDashへはどのように移行するのか？

EmDashが移行するのはコンテンツであり、コードではありません。コンテンツインポートのドキュメントには、コンテンツをインポートする方法として、WordPress eXtended RSS（WXR）ファイルを使う方法と、EmDash Exporterプラグインを導入したサイトに接続する方法の2つが挙げられています。WordPress.comには専用のインポート元が用意されていないため、WordPress.comのサイトもWXRエクスポートまたはEmDash Exporterを使用します。

WordPress移行ガイドでは、1.2.0より古いExporterを使うと、コメント、メニュー、ロゴ、ファビコンが何の通知もなく欠落すると警告しています。インポート自体は完了し、欠落項目も一切表示されません。作業を始める前に、Exporterのバージョンを必ず確認してください。テーマとプラグインについては、EmDashのREADMEに、エージェントスキルがプラグインやテーマの移植を支援すると記載されています。とはいえ、その支援があっても作り直しは覚悟しておくべきです。

WordPressが依然として優位な点は？

WordPressには、実用面で4つの優位性が残っています。テーマとプラグインのエコシステムが圧倒的に大きいこと、ほぼすべてのホスティングサービスが対応していること、編集者がすでに操作に慣れていること、そして有料プラグインの成熟した市場があることです。1.0のローンチ時点で、CloudflareはEmDashのレジストリが無料プラグインのみに対応しており、有料プラグインは今後対応予定であると述べていました。

2つ目の差はホスティングです。WordPressはほぼどのPHPホスティングでも動作します。一方、EmDashのプラグインサンドボックスをフルに活用するには、Cloudflareの有料プランか、自前で運用するNode.jsサーバーが必要です。

3つ目のコストは編集者に関わるものです。EmDashの管理画面は編集者にとって初めて触れるものであるため、クライアントを移行するにはコンテンツの移行だけでなく、スタッフの再教育も必要になります。複数のWordPress代替を検討している場合は、11tyとWordPressの比較を読むと、静的サイトファーストの選択肢でこうしたトレードオフがどう表れるかがわかります。

今すぐEmDashを試すべき人、待つべき人

今すぐ試すべきケース：

• ブログ、ドキュメント、マーケティングページなどのコンテンツサイトを構築しており、チームがすでにAstroで開発している。
• プラグインのサプライチェーンリスクが、自社やクライアントにとって現実的な懸念となっている。
• API、CLI、MCPサーバーを通じて、エージェントにコンテンツを扱わせたい。

待つべきケース：

• サイトが特定のWordPressプラグイン、商用テーマ、またはWooCommerceのような機能に依存している。
• レジストリから有料プラグインを利用する必要がある。
• 安価な共有PHPホスティングを使わざるを得ない。

Cloudflareにデプロイする場合は、2026年9月28日にオープンベータとなった新しいCloudflare CLIであるcfもチェックしておきましょう。cfはcloudflare.config.tsファイルを通じてWorkersの設定とバインディングを管理します。なお、wrangler.jsoncで設定されたプロジェクトは引き続きWranglerで扱います。

EmDashは、特定の種類のサイトにとっては本当の意味でのWordPress代替です。それは、コンテンツ主導でプラグインへの依存が少なく、エコシステムの規模よりもサンドボックス化されたプラグインを重視する、Astroに対応できるチームが構築するサイトです。それ以外のサイトについては、試験導入する価値はあるものの、本格的な乗り換えにはまだ早い段階です。次の一手としては、実際のクライアントサイト1件のWXRエクスポートをインポーターにかけ、何が欠落するかを洗い出してみるとよいでしょう。

よくある質問

EmDashはURLだけでWordPressサイトをインポートできますか？

いいえ。EmDash Exporterプラグインがない場合、サイトのURLから行えるのは、公開されているWordPress REST APIの確認だけです。この確認により、サイトがWordPressで動作していることや、公開されている投稿・固定ページ・メディアの件数は把握できますが、何もインポートはできません。インポートするには、WXRエクスポートファイルをアップロードするか、WordPressサイトにEmDash Exporterをインストールし、WordPressのアプリケーションパスワードで接続してください。後者の方法では、公開REST APIでは公開されていないコンテンツにもアクセスできます。

EmDashへのインポート時、Gutenbergブロックやプラグインのブロックはどうなりますか？

EmDashはGutenbergのマークアップをPortable Textに変換し、クラシックエディターのHTMLも同じコンバーターで処理します。「最新の投稿」や多くのプラグインブロックのように、WordPressがサーバー側で生成するブロックは、投稿内にマークアップを保存していません。インポーターはこれらを元のブロックコメントのみを含むHTMLブロックとして保持しますが、サイト上には何も表示されないため、作り直すか削除する必要があります。再利用ブロックはEmDashのセクションになります。

WordPressの下書き、予約投稿、非公開投稿のステータスはEmDashでも維持されますか？

公開状態が維持されるのは公開済みの投稿のみです。EmDashのインポーターはWordPressのpublishステータスをpublishedにマッピングし、draft、pending、private、future、trash、および不明なステータスはすべて下書きになります。そのため、予約投稿と非公開投稿はインポート後に手動で確認する必要があります。EmDashの移行ガイドでは、DNSを切り替えたりWordPressサイトを廃止したりする前に、ステータスごとのエントリ数を確認し、ログアウト状態の訪問者に下書きが表示されないことを確認するよう推奨しています。

EmDashはどのデータベースとストレージバックエンドに対応していますか？

EmDashはSQLにKysely、ストレージにS3 APIを使用しているため、データにはSQLite、Cloudflare D1、TursoまたはlibSQL、PostgreSQLを、メディアにはCloudflare R2、AWS S3、任意のS3互換サービス、またはローカルファイルシステムを利用できます。なおCloudflare上では、サイト自体がどのデータベースアダプターを使用していても、サンドボックス化されたプラグインはDBという名前のD1バインディングを通じて読み書きを行います。