Cloudflare EmDashとは？料金・WordPress移行・プラグインの実仕様【v0.29.0/2026年7月】

EmDashは、Cloudflareが2026年4月1日に公開したオープンソースCMSです。「WordPressの精神的後継（spiritual successor）」を掲げ、PHPではなくTypeScriptとAstroで書かれ、プラグインをサンドボックスで隔離実行します。公開直後の記事は初期リリース時点の情報で止まっていますが、開発は速く、2026年7月10日には [email protected] がリリースされました。本記事は公式リポジトリ（emdash-cms/emdash）と公式ドキュメントを2026年7月13日時点で確認し、「結局いくらかかるのか」「WordPressからどう移すのか」「日本語は使えるのか」という実務の疑問に、仕様ベースで答えます。

まとめ

• 現在地：ステータスは「ベータプレビュー」のまま。最新版は [email protected]（2026年7月10日）。ライセンスはMIT、リポジトリは emdash-cms/emdash（2026年7月13日時点で約11,100スター、フォーク約1,030、オープンIssue約200）。
• 料金：EmDash本体は無料（MIT）。ただしプラグインのサンドボックス実行に使うDynamic WorkersはCloudflareの有料アカウントが前提で、Developer Platformは月額5ドルから。無料枠だけで動かすなら worker_loaders を無効化してプラグイン機能を切るか、Node.js＋SQLiteで自己ホストする。
• 移行：WordPress側に専用のエクスポータープラグインを入れる必要はない。標準の「ツール→エクスポート」で出したWXR（.xml）を管理画面のインポートウィザードに読ませる方式が推奨で、ほかにWordPress.com連携とREST APIによる事前調査がある。
• Cloudflare専用ではない：DBはSQLite/D1/Turso/PostgreSQL、ストレージはR2/S3互換/ローカルを選べる。Node.js環境でもサンドボックス実行が可能（@emdash-cms/sandbox-workerd）。
• 向き・不向き：Astroで新規に作るサイト、編集者がコードを触らない中小規模サイトには現実的な選択肢。WooCommerce相当のEC要件や、既存プラグイン資産に依存した大規模サイトは今の段階では見送るべき。

EmDashの現在地：v0.29.0とベータプレビューの実態

公開から3か月で0.29.0、それでもステータスは「ベータプレビュー」

公式リポジトリ emdash-cms/emdash は2026年4月1日に作成され、最初の公開版は0.1.x系のデベロッパープレビューでした。その後リリースは細かく刻まれ、2026年7月10日に [email protected]、同日に [email protected]、@emdash-cms/[email protected] などの周辺パッケージも同じバージョンで揃っています。READMEのStatusは現在も「beta preview」で、安定版（1.0）の到達宣言は出ていません。

0.x台のうちは破壊的変更が入り得るため、本番投入するなら更新履歴を追う体制が要ります。公開直後の解説記事にある「v0.1.0のデベロッパープレビュー」という記述は、すでに現状と合いません。

「WordPressの後継」を名乗る根拠＝プラグイン起因96%という脆弱性統計

EmDashが繰り返し引くのは、Patchstackの調査（State of WordPress Security in 2024）が示した数字です。2024年にWordPressエコシステムで報告された新規脆弱性のうち、96%がプラグイン由来でした。WordPressのプラグインはPHPスクリプトとして本体に直接フックし、データベースとファイルシステムに無制限にアクセスできます。1本の脆弱なプラグインがサイト全体を明け渡す構造そのものを、EmDashは設計で潰しにいきました。

WordPress本体の進化と比べたい場合は、WordPress 7.0の概要と2026年5月リリースの位置付けも併せて確認してください。EmDashは「WordPressが直せない部分」を主張しているため、WordPress側の現状を押さえたほうが判断がぶれません。

無料で使えるか：Dynamic Workersは有料アカウントが前提

「サーバーレスだからリクエストがなければ課金ゼロ」という説明だけでは、実務の答えになりません。EmDashのREADMEには重要な注意書きがあり、プラグインを安全に動かすためのDynamic Workersは、Cloudflareの有料アカウントでのみ利用できます。ここを外すと、無料枠のつもりで始めて最初のデプロイで詰まります。

プラグインを使うなら月額5ドルからのDeveloper Platform

公式が案内する導線は、Cloudflare Developer Platformの有料プラン（月額5ドルから）へのアップグレードです。プラグインを使わない構成にするなら、wrangler.jsonc の worker_loaders ブロックをコメントアウトしてプラグイン機能を無効化する、という回避策がREADMEに明記されています。つまり「無料で使えるか」への正確な回答は、プラグインなしなら無料枠の範囲で動かせる、プラグインを使うなら有料です。

D1・R2・Workersそれぞれの無料枠と課金体系は、Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめで個別に確認できます。EmDashのコストはEmDash本体（MITで無料）ではなく、この土台側で決まります。

Docker・Node.js自己ホストという逃げ道

EmDashはCloudflare専用ではありません。Node.js＋SQLiteで自前のサーバーに置けますし、リポジトリには Dockerfile と compose.yaml が同梱されています。この構成でもサンドボックスは諦めなくてよく、Node.js環境では @emdash-cms/sandbox-workerd（2026年7月10日時点で0.2.0）をサンドボックスランナーとして指定すれば、マーケットプレイスのプラグインを隔離実行できます。開発時は miniflare をdev依存に入れるとサンドボックスの起動が速くなります。

アーキテクチャ：Astro統合とポータブルな抽象化

前提はAstro 6とNode.js v22.12以上

EmDashはAstroインテグレーションとして動きます。packages/core のpeerDependenciesは astro >=6.0.0-beta.0、@astrojs/react >=5.0.0-beta.0、React 18以上。公式のGetting StartedはNode.js v22.12以上を要求し、奇数バージョンのNode.jsはサポート対象外と明記しています。導入は次の1行で、テンプレート（blog / marketing / portfolio）を選んで雛形が生成されます。

npm create emdash@latest

Astroの設定にEmDashを足せば、管理画面・REST API・認証・メディアライブラリ・プラグイン機構が一式付いてきます。

// astro.config.mjs
import emdash from "emdash/astro";
import { d1 } from "emdash/db";

export default defineConfig({
  integrations: [emdash({ database: d1() })],
});

Astroそのものの立ち位置や、Reactとの使い分けに迷う場合はAstroとReactの違いと使い分け｜AstroでReactを使う方法を先に読むと、EmDashが「フレームワークに密結合したCMS」である意味がつかめます。

差し替え可能なDB・ストレージ・セッション

EmDashはSQLクエリビルダにKysely、ストレージにS3 APIという移植性のある抽象を挟んでいます。Cloudflare前提に見えて、逃げ道が確保されています。

Portable Text保存が生むマルチチャネル配信

WordPressは本文をHTML文字列として保存し、メタ情報をHTMLコメントに埋め込みます。この設計が、コンテンツをDOM表現に縛りつけてきました。EmDashは編集にTipTapを使い、保存形式は構造化JSONのPortable Textです。同じ本文をWebページ・アプリ・メール・APIレスポンスへ、HTMLをパースし直さずに流し込めます。全文検索はSQLiteのFTS5、認証はパスキー（WebAuthn）を第一手段としつつOAuthとマジックリンクを代替に用意し、権限はAdministrator / Editor / Author / Contributorの4ロールです。パスキーは第一手段であって唯一の手段ではないため、「パスワード漏洩リスクがゼロになる」とまでは言えません。

プラグイン：capabilities宣言による権限の限定

ビルド時のディスクリプタと実行時のdefinePluginを分ける2ファイル構成

EmDashのプラグインは2つの部品に分かれます。ディスクリプタ（index.ts）はID・バージョン・宣言するcapabilities・エントリポイントを持ち、astro.config.mjs から読まれてビルド時にViteで評価されます。プラグイン定義（definePlugin()、通常は sandbox-entry.ts）はフックやAPIルートといった実行時のロジックだけを持ちます。両者は実行環境が違うため、必ず別ファイルに置きます。definePlugin() の中にIDやcapabilitiesを書く旧来の書き方は、現行APIでは通りません。

// src/index.ts — ディスクリプタ（ビルド時にViteで評価）
import type { PluginDescriptor } from "emdash";

export function notifyOnPublish(): PluginDescriptor {
  return {
    id: "notify-on-publish",
    version: "1.0.0",
    format: "standard",
    entrypoint: "@my-org/notify-on-publish/sandbox",
    capabilities: ["content:read", "email:send"],
  };
}

// src/sandbox-entry.ts — 実行時のロジック
import { definePlugin } from "emdash";
import type { PluginContext } from "emdash";

export default definePlugin({
  hooks: {
    "content:afterSave": {
      handler: async (event, ctx: PluginContext) => {
        if (event.content.status !== "published") return;
        await ctx.email.send({
          to: "[email protected]",
          subject: `New post: ${event.content.title}`,
        });
      },
    },
  },
});

capabilityの名前は content:read、media:read、network:request、users:read、email:send のように「対象:操作」の順です。content:read だけを宣言したプラグインは ctx.content.get() と ctx.content.list() しか呼べず、ctx.content.create() を試みれば権限エラーで落ちます。ストレージ（ctx.storage）とKV（ctx.kv）はプラグインごとにスコープが切られており、宣言なしで使えます。マーケットプレイスからインストールするときは、宣言されたcapabilitiesが同意ダイアログとして管理者に提示され、承認しなければ入りません。

標準（サンドボックス可）とネイティブの権限差

プラグインは2形式です。標準（standard）はマーケットプレイス（marketplace.emdashcms.com）からワンクリックで入り、Cloudflareではアイソレート、それ以外の環境ではインプロセスで動きます。他人が作ったプラグインを入れるならこちらで、サンドボックス実行時はcapabilitiesが強制されます。ネイティブは React製の管理画面や直接のDBアクセス、独自Astroコンポーネントが要るときの逃げ道で、常にホストと同一アイソレートで動き、マーケットプレイスには公開できません。

ここに落とし穴があります。ネイティブ形式ではcapabilitiesの宣言は文書化にすぎず、強制されません（プロセスへのフルアクセスを持つ）。宣言的な権限制御という売りが効くのはサンドボックス実行時であり、plugins: [] に置いたプラグインはWordPressと同じ「全権」に戻ります。設定ファイルの sandboxed: [] と plugins: [] のどちらに書くかは、単なる置き場所ではなくセキュリティ境界の選択です。なお、中央マーケットプレイスとは別に、実験的な連合型レジストリも用意されています。

一次プラグイン8本対WordPress6万本というギャップ

公式リポジトリの packages/plugins にある一次プラグインは、テスト用を除くとフォーム、埋め込み、監査ログ、AIモデレーション、Webhook通知、カラー、フィールドキット、ATProtoの8本です。サードパーティ製もSEOやアナリティクス、コマース系が出始めていますが、WordPressの6万本超という規模とは比較になりません。今のEmDashは「既製プラグインを組み合わせて作るCMS」ではなく、「必要な拡張は自分で書く前提のCMS」です。この一点だけで、社内に継続的にコードを書ける人がいないサイトは候補から外れます。

WordPressからの移行：専用エクスポーターは要らない

WXR・WordPress.com・REST probeの使い分け

「emdash exporter plugin」を探している人が多いのですが、WordPress側に専用プラグインを追加インストールする必要はありません。WordPress標準の「ツール → エクスポート → すべてのコンテンツ」で出力したWXR形式の.xmlを、EmDashの管理画面（Admin → Settings → Import → WordPress）にアップロードするのが公式の推奨ルートです。

ウィザードは.xmlをブラウザ内で解析し、検出した投稿タイプごとに「新しいコレクションを作る／既存に不足フィールドを足す」を提示します。取り込みはWordPressのID照合で行われるため、再実行しても重複は作られません。メディアは本文取り込み後に別途ダウンロードでき、コンテンツハッシュで重複排除し、本文中のURLも自動で書き換わります。

Gutenbergブロックの変換と、変換できないもの

本文はGutenbergブロックからPortable Textへ変換されます（core/paragraph→block、core/heading→見出しレベル付きblock、core/image→imageなど）。クラシックエディタのHTMLも、<strong> や <a> がスパンのマークに変換されます。変換ルールに無いブロックは htmlBlock として元のHTMLのまま保持されます。壊れはしませんが、そのままでは構造化の恩恵を受けられないので、移行後に手で直すか、カスタムのPortable Textコンポーネントを書いてレンダリングすることになります。独自ブロックを多用したサイトほど、この後処理が移行コストの本体になります。

カスタムフィールド・ACF・リダイレクト

投稿メタとACFフィールドはインポート時に解析され、値からフィールド型が推論されます（数値文字列→number、ISO日付→date、シリアライズされたPHP/JSON→json、_thumbnail_id のようなID→reference）。_edit_ や _wp_ で始まる内部フィールドは既定で隠され、SEOプラグインのフィールドは seo オブジェクトにまとめられます。ACFのリピーターとフレキシブルコンテンツはJSONとして入るため、構造化したいなら受け皿のフィールドを自分で定義する必要があります。

インポート後にはリダイレクトマップ（/?p=123 や旧パーマリンクから新URLへ、/feed/ から /rss.xml へ）がJSONで生成されます。これをCloudflareのリダイレクトルール、ホスティング側の設定、あるいはAstroの redirects のいずれかに適用します。SEO資産を落とさないための工程なので、移行作業のチェックリストに必ず入れてください。100MBを超える大きなエクスポートは、WordPress側で投稿タイプごとに分割して出し、CLIの --resume を使って順に取り込むのが公式の助言です。

なお、WordPressを完全に捨てずに表示側だけ切り離す道もあります。判断材料としてヘッドレスアーキテクチャのメリット：なぜヘッドレスWordPressが注目されるのかも比較検討に入れておくと、移行の是非を落ち着いて決められます。

AIエージェント連携とx402課金

コンテンツ操作を自動化するCLIと組み込みMCPサーバー

EmDashはCLIとMCPサーバーを標準で持ちます。CLIは npx emdash 配下で、開発サーバー起動（dev）、ライブスキーマからの型生成（types）、ログイン（login／認証情報は ~/.config/emdash/auth.json）、コンテンツ操作（content list/get/create/update/publish/schedule）、スキーマ操作（schema）などをカバーします。人が管理画面で行う操作を、そのままスクリプトやエージェントから叩ける設計です。

npx emdash types
npx emdash content create posts --data '{"title": "Hello"}'
npx emdash content schedule posts 01ABC123 --at 2026-08-01T09:00:00Z

加えてMCPサーバーが組み込まれているため、ClaudeやChatGPTなどのAIツールからサイトを直接操作できます。プラグインやテーマ開発用のスキルファイルもリポジトリに同梱されています。

x402の主用途＝人間は無料・ボットは課金というボット限定モード

x402対応は @emdash-cms/x402 パッケージが担い、EmDash以外のAstroサイトにも単体で組み込めます。仕組みはHTTPネイティブで、支払いなしで有料リソースを要求したクライアントには 402 Payment Required と機械可読な支払い指示が返り、対応クライアントは自動で支払って再試行します。

公式ドキュメントが最も一般的な用途として挙げるのは、汎用の課金ではなくボット限定モードです。AIエージェントやスクレイパーには課金しつつ、人間の読者には無料で読ませます。設定例は botOnly: true、ボットスコア閾値30、既定価格0.01ドル、決済ネットワークはBaseメインネット（eip155:8453）。判定は request.cf.botManagement.score を読むため、Bot Managementを有効にしたCloudflare配信が前提です。ローカル開発やCloudflare以外にデプロイした環境ではボット判定データが存在せず、全リクエストが「人間」扱いになって課金は行われません。ここも料金の話と地続きで、Bot Management系の機能はCloudflare側の契約に依存します。実装上の狙いは学習クローラーへの課金であり、一般読者向けのペイウォールとは別物として設計されています。

日本語対応と導入判断

管理画面の日本語UIとAstro設定を共有するi18nルーティング

管理画面の日本語UIは同梱済みです。packages/admin/src/locales に ja を含む20以上のロケール（ar / de / es / fr / ko / zh-CN など）が入っており、翻訳基盤にはLinguiを使っています。日本語だけのサイトなら、i18n設定を書かずにそのまま運用できます。

コンテンツ側の多言語は、Astro組み込みのi18nルーティングと統合されています。astro.config.mjs の i18n ブロック（defaultLocale、locales、fallback）をEmDashがそのまま読み、ロケール一覧とフォールバック連鎖を共有します。翻訳はそれぞれが独立したコンテンツエントリで、スラッグ・公開状態・リビジョン履歴を個別に持つため、日本語版を公開したまま英語版を下書きで進める、といった運用ができます。

採用してよい場面と、見送るべき場面

結論を言い切ります。Astroで新規にコーポレートサイトやブログ、LPを作り、社内にTypeScriptを書ける人が1人以上いるなら、EmDashは現時点でも選ぶ価値があります。単一デプロイでフロントとCMSが完結し、型生成でスキーマ変更が壊れた箇所をビルド時に検出でき、プラグインの権限が宣言的に絞られている利点は、他のヘッドレスCMSでは同時に手に入りません。

逆に、次に当てはまるなら今回は見送るべきです。WooCommerceに依存した大規模ECは代替の実装量が現実的ではありません。既存の有名プラグイン（会員制、予約、フォーム連携など）の機能をそのまま持ち込みたい場合も、エコシステムの規模差から自作が前提になります。Astro以外のフレームワークを使うプロジェクトでは、そもそもEmDashは選択肢に入りません（EmDashはAstroと密結合であり、汎用ヘッドレスCMSではない）。そしてバージョンが0.x台でベータプレビューを名乗る以上、更新に追随できない運用体制での本番投入は、いずれ塩漬けを招きます。

よくある質問

EmDashは無料で使えますか？

EmDash自体はMITライセンスで無料なので、費用はすべて土台側で決まります。無料枠で動かせるのは「プラグインなし」の構成までで、worker_loaders を無効化する必要があります。プラグインをサンドボックス実行するDynamic Workersは有料アカウント（Developer Platform、月額5ドルから）が前提です。x402のボット限定課金を使う場合はさらにBot Managementの有効化が要ります。Cloudflareに一切課金したくない場合は、Node.js＋SQLiteの自己ホストにすればサンドボックス（@emdash-cms/sandbox-workerd）ごと無料で運用できます。

WordPressから移行するのに専用のエクスポータープラグインは必要ですか？

不要です。WordPress標準の「ツール → エクスポート」で出力したWXR（.xml）を、EmDash管理画面のインポートウィザードにアップロードします。WordPress.comホストの場合はOAuth連携、移行前の内容確認だけならREST API経由のプローブも使えます。取り込みはWordPressのID照合で行われるので、再実行しても重複は増えません。

Cloudflare以外でも動きますか？Dockerは使えますか？

動きます。データベースはSQLite・Turso・PostgreSQL、ストレージはS3互換サービスやローカルファイルシステムを選べます。リポジトリには Dockerfile と compose.yaml が同梱されており、Node.js v22.12以上（奇数バージョンは非対応）の環境で自己ホストできます。プラグインのサンドボックスもNode.js側で @emdash-cms/sandbox-workerd を指定すれば利用可能です。

EmDashのCLIでは何ができますか？

npx emdash dev での開発サーバー起動、npx emdash types でのライブスキーマからのTypeScript型生成、npx emdash content による記事の一覧・取得・作成・更新・公開・予約公開、npx emdash schema でのスキーマ操作などです。認証は emdash login で ~/.config/emdash/auth.json に保存されます。CLIとMCPサーバーがあるため、AIエージェントからのコンテンツ運用も同じ経路で行えます。

本番の企業サイトで今すぐ採用してよいですか？

ステータスがベータプレビュー（0.x系）である点を許容できるかが分かれ目です。更新を追える体制があり、Astroで新規構築する中小規模サイトなら実用段階に入っています。既存プラグイン資産に依存する大規模サイトやWooCommerce前提のECは、代替実装のコストが大きいため現段階では推奨しません。

関連記事

• WordPress 7.0の概要と2026年5月リリースの位置付け
• Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ
• AstroとReactの違いと使い分け｜AstroでReactを使う方法【2026年版】
• ヘッドレスアーキテクチャのメリット：なぜヘッドレスWordPressが注目されるのか