Cloudflare EmDashとは？1.0の変更点・料金・WordPress移行とプラグインの実仕様【1.3.0/2026年10月】

EmDashは、Cloudflareが2026年4月1日に発表したオープンソースのCMSです。「WordPressの精神的後継」を掲げ、PHPではなくTypeScriptとAstroで動き、プラグインを隔離した実行環境で動かします。発表時はv0.1のベータでしたが、2026年9月28日にEmDash 1.0がstable（安定版）として公開され、2026年10月15日には [email protected] が出ています。v0.1当時の解説と1.x系では、料金・移行・プラグインの前提が変わっています。本記事は公式リポジトリ・公式ドキュメント・Cloudflareの料金ページを2026年10月18日に確認し、「いくらかかるのか」「WordPressからどう移すのか」「本番で使えるのか」に答えます。

まとめ

• 現在地：1.0（[email protected]、2026年9月28日）でstableになり、コアパッケージはセマンティックバージョニングに従う。最新は [email protected]（2026年10月15日）。ライセンスはMIT。ただし公式プラグインとプラグイン開発ツールはまだ0.x。
• 料金：EmDash本体は無料。CloudflareではWorkers Free（月0ドル）で管理画面・API・メディアまで動く。有料のWorkers Paid（月5ドルから）が必要になるのは、サンドボックス型プラグインを実行・インストールするときと、無料枠の上限を超える運用をするとき。
• 無料プランの止まり方：1日10万リクエストを超えるとError 1027、1回のCPU時間10ミリ秒を超えるとError 1102、D1の日次読み書き上限に達するとクエリがエラーになる。Cloudflareの上限ページはサーバーレンダリングを「通常10〜20ミリ秒」と書いており、キャッシュ無しの運用は無料枠と相性が悪い。
• 自己ホスト：Node.js 22.16以上＋SQLite・PostgreSQL・libSQLで動き、Dockerの手順も公式にある。プラグインのサンドボックスもworkerdの子プロセスで動くが、強制されるのは30秒の実行時間だけ。
• 移行：WordPressの「ツール→エクスポート」のWXRか、公式のEmDash Exporterプラグイン（GitHub配布）を使う。非公開記事は下書きとして入る。コメント・メニュー・ロゴを移すにはExporter 1.2.0以上が要る。WordPress.com向けのOAuth取り込みは無い。
• 判断：新規のコンテンツサイトや、Astroで作る企業サイトは採用候補。WooCommerceや多数のWordPressプラグインに依存するサイトは、代替の実装費が先に立つので見送る。

EmDash 1.0の安定版宣言と0.xからの互換性

1.0.1（2026年9月28日）のstable宣言とセマンティックバージョニング

公式リポジトリのREADMEは、現在のステータスを「stable and ready for production」としています。対象は emdash・create-emdash・@emdash-cms のadmin・auth・blocks・Cloudflareの各パッケージで、破壊的変更はメジャー版でだけ出します。一方で公式プラグインとプラグイン開発ツールは0.xのままで、マイナー版の間でも変わりえます。プラグインまわりのコードは、本体ほど長く固定できないと見ておくのが安全です。

なお、npmには2026年4月27日付の 1.0.0 も残っていますが、リリースノートで1.0の公開を告げているのは [email protected] です。Cloudflareの発表では、1.0までの5か月間に175人超が1,800超のコミットを入れ、管理画面は25言語に翻訳されました。Cloudflare自身も2026年8月に公式ブログをEmDashへ移行しており、1.0の発表では毎秒最大5,000リクエストの正規トラフィックを捌く前提で検証したと述べています。

0.xから1.0への更新で書き換えが必要なAPIとコマンド

1.0は0.xで非推奨にしたAPIを削除しています。公式の移行ガイドが挙げる破壊的変更は次のとおりです。

cacheCloudflare() への置き換え後は、キャッシュ削除にCloudflare REST APIを使わなくなるため、CF_ZONE_ID と CF_CACHE_PURGE_TOKEN のシークレットを消せます。プラグインの権限名は read:content のような旧名が1.x系のあいだは動き続けますが、起動時に警告が出ます。2026年10月6日からは、依存パッケージの更新とデータベース側の作業をまとめて準備する upgrade-emdash コマンドも公開されています。

EmDash 1.1〜1.3で追加された編集・認証・SEO機能

1.3.0のAI学習拒否は、SEO設定で有効にすると robots.txt にGPTBot・ClaudeBot・Google-Extendedなど8種の拒否規則と Content-Signal: search=yes, ai-train=no を出力します。検索には載せたまま学習だけ断る設定を、WordPressのようにプラグインを足さずに持てる点は運用上の差になります。

料金：EmDash本体は無料、払うのはCloudflareの使用量

無料プラン（Workers Free）で動く範囲

EmDash自体はMITライセンスで、ライセンス料はありません。Cloudflare上で動かすときの費用は、Workers・D1（データベース）・R2（メディア）・Images（画像変換）の使用量です。公式のCloudflare向けテンプレートは、有料プランでしか使えないWorker Loaderのバインディング（LOADER）をコメントアウトした状態で配られており、公式ドキュメントも「新規プロジェクトはWorkers無料プランにデプロイできる」と明記しています。管理画面・REST API・パスキー認証・メディアライブラリ・予約公開は無料プランで使えます。

無料枠の主な上限は次のとおりです（Workersの上限ページ・D1料金・R2料金、2026年10月18日確認）。

R2（メディア）とImages（画像変換）は、Workersのプランとは別建てです。R2はどちらのプランでも月10GB・Class A操作100万回・Class B操作1,000万回まで無料で、超過はストレージ0.015ドル／GB月、Class A 100万回4.50ドル、Class B 100万回0.36ドルです。画像変換はImages Freeで月5,000種類まで無料で、それを超えるには別途Images Paid（5,000種類込み・以降1,000種類ごとに0.50ドル）の契約が要ります。

無料プランが止まる地点：Error 1027とError 1102

無料プランでサイトが止まる要因は、リクエスト数・CPU時間・D1の日次読み書き上限の3つです。D1は1日の読み取り500万行か書き込み10万行に達すると、UTCの0時までクエリがエラーを返します。リクエストは1日10万件（同じくUTCの0時にリセット）を超えると、Cloudflareは Error 1027 を返します。サインイン中のユーザー向けに描画した応答はキャッシュから自動で外れるため、編集者の操作も1回ずつこの枠を消費します。テンプレートには予約公開のための毎分実行のcron（* * * * *）が入っており、1日1,440回起動する点も計算に入れておきます。

もう1つはCPU時間です。Workersの上限ページは平均的なWorkerを1リクエスト約2.2ミリ秒としつつ、「認証やサーバーサイドレンダリングを行う重めの処理は通常10〜20ミリ秒」と書いています。無料プランの上限は1回10ミリ秒で、超えると Error 1102（Worker exceeded resource limits）になります。D1やKVの待ち時間はCPU時間に数えませんが、EmDashはWorker内でページを組み立てるので、キャッシュ無しの公開ページは上限に近づきます。しかもルートルールが無く、描画中に Astro.cache.set() も呼ばれないルートは no-store になり、キャッシュされません。無料プランで運用するなら、キャッシュできる公開ページにはルートルールかキャッシュヒントを付け、キャッシュが効かない管理操作や初回描画のCPU時間はダッシュボードで計測しておくべきです。

画像変換は、元画像とパラメータの組み合わせごとに月1回だけ数えられ、Images Freeの上限は月5,000種類です。500枚の元画像にサムネイルとヒーロー画像の2サイズを作ると、それだけで1,000種類を使います。上限を超えると新しい変換は Error 9422 で失敗し、キャッシュ済みの変換だけが配信され続けます。

有料プラン（月5ドルから）が必要になる条件

サンドボックス型プラグインは、Cloudflare上ではプラグインごとにDynamic Workerとして起動します。Dynamic WorkersはWorkers Paid限定のため、プラグインレジストリから入れるプラグインと、sandboxed: [] に登録するプラグインはどちらも有料プランが前提です。設定は wrangler.jsonc の worker_loaders に LOADER を足し、Workerのエントリーポイントから PluginBridge をexportし、emdash() に sandboxRunner: sandbox() を渡します。LOADER が無いと、ビルド時に「Sandboxed plugins are disabled」の警告が出てプラグインは読み込まれません。

Dynamic Workersの課金は、日ごとに作られた固有のDynamic Workerの数で決まり、月1,000個分が込みで、超過は1個1日あたり0.002ドルです。コードかIDが変わると別個に数えます。リクエストとCPU時間は通常のWorkersの請求に合算されます。Cloudflareの料金ページにある例では、月1,500万リクエスト・平均CPU 7ミリ秒のWorkerで合計月8ドル（基本料5ドル＋リクエスト1.5ドル＋CPU 1.5ドル）です。D1をWorkers Paidで使うと、1データベースあたりの容量が10GBに、ポイントインタイム復元の期間が7日から30日に延びます。Workersの料金体系そのものはCloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方で詳しく整理しています。

Node.jsで自己ホストする：Docker・SQLite・workerdサンドボックス

Cloudflare以外で動かす構成

EmDashはデータベースをKysely、ストレージをS3 API互換で抽象化しており、Cloudflareに固定されません。Node.jsデプロイの公式手順はNode.js 22.16以上を要求し、1台構成ならSQLiteとローカルストレージ、複数台ならPostgreSQLかlibSQLとS3互換ストレージを勧めています。Dockerfileとdocker composeの例も載っています。AWSで動かす場合は、ECSやEC2のNode.jsにAmazon RDS for PostgreSQLとS3を組み合わせる形になります。

自己ホストのサンドボックスで強制されない制限

1.0では、Node.jsでもサンドボックス型プラグインが動きます。サーバーがCloudflare Workersのオープンソース実行環境 workerd を子プロセスとして起動し、プラグインをその中のサービスとして動かします（sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox"）。子プロセスに渡す環境変数は PATH・HOME・LANG などに限られ、サーバー側のシークレットはプラグインから見えません。

見落としやすいのは、強制される資源制限の差です。公式ドキュメントの表では、プラグイン1回の呼び出しに対する制限は次のように分かれます。

権限（capability）による隔離はどちらでも効きますが、無限ループや外部への大量リクエストで資源を食うプラグインを止められるのはCloudflare側だけです。自己ホストでレジストリのプラグインを入れるなら、権限だけでなく発行者と更新履歴も確認してから入れるべきです。また、Cloudflare上でも LOADER が無い状態でプラグインを plugins: [] に移すと、隔離も資源制限も無いネイティブ扱いになり、WordPressと同じ全権に戻ります。

Cloudflareでしか使えない機能

「Cloudflareへの囲い込みではないか」という指摘には、範囲を分けて答えられます。CMSの中核（管理画面・API・MCP・移行・プラグインの権限隔離）はNode.jsでも動きます。Cloudflareでしか動かないのは、Dynamic Workersによる資源制限の強制、Workers Cacheとの連携、Imagesバインディングによる画像変換、後述するx402のボット限定課金です。ボット対策や画像配信を別サービスで組める組織なら、自己ホストでも機能面の不足は小さく済みます。

アーキテクチャ：Astro統合とPortable Text

前提環境はAstro 6以上とNode.js 22.16以上

EmDashはAstroのインテグレーションとして動きます。[email protected] の package.json は、Astroを6.0.0-beta.0以上、Node.jsを22.16以上と指定しています（v0.29.0時点の22.12から引き上げ）。公式テンプレートはAstro 7系（^7.3.2）を使います。新規作成は次の1行で、対話形式でデプロイ先（Cloudflare か Node.js）とテンプレート（Blog・Marketing・Portfolio・Starter など）を選びます。

node --version   # v22.16.0 以上であること
npm create emdash@latest
# 対話で Project name: my-emdash-site ／ Install dependencies?: Yes を選ぶ
cd my-emdash-site
npm run dev
# 管理画面: http://localhost:4321/_emdash/admin

コンテンツの型はコードではなくデータベースに定義し、管理画面のスキーマビルダーから編集者が追加できます。コレクションごとに実際のSQLテーブルが作られ、開発者は npx emdash types で型を生成し、Astroのライブコレクション経由で getEmDashCollection("posts") のように読み込みます。Astro自体の位置づけはAstroフレームワークとは？特徴と使い方・Next.jsとの使い分けを解説【2026年版】を参照してください。

本文をHTMLでなくPortable Textで保存する理由

WordPressは本文をHTMLとして保存し、ブロック情報をHTMLコメントに埋め込みます。EmDashはTipTapエディタで編集した本文を、構造化JSONのPortable Textで保存します。表示形式から切り離されているため、同じ記事をWebページ・アプリ・メール・APIレスポンスへHTMLを解析せずに出し分けられます。全文検索はSQLiteのFTS5を使います。WordPressをヘッドレスにして同じことをする場合との比較は、WordPressとReactの連携方法：ヘッドレス化とテーマ組み込みの手順【WordPress 7.1・Next.js 16】が参考になります。

プラグイン：権限の宣言とatprotoのレジストリ

サンドボックス型とネイティブ型の違い

EmDashのプラグインは2形式あります。サンドボックス型は隔離された実行環境で動き、宣言して管理者が承認した操作だけができます。ネイティブ型はサイトと同じプロセスで動き、Reactの管理画面や公開ページへのHTML挿入ができる代わりに全権を持ち、npmから入れてデプロイし直す必要があります。公式ドキュメントは、React管理画面などが要らない限りサンドボックス型を選ぶよう勧めています。Patchstackの2024年版レポートは、2023年に新たに見つかったWordPressの脆弱性の97%がプラグイン由来だったと集計しており、EmDashのREADMEもこの種の統計を設計の根拠に挙げています。

権限は「対象:操作」の順で書きます。代表的なものは次のとおりです。

サンドボックス型プラグインの作り方

Cloudflareの発表ブログとREADMEには、definePlugin({ id, capabilities, hooks }) を1ファイルに書く例が載っています。1.x系の公式チュートリアルの手順はこれと違い、@emdash-cms/plugin-cli で雛形を作り、権限と保存領域をマニフェスト emdash-plugin.jsonc に、処理を src/plugin.ts に分けて書きます。雛形を作ったら cd save-log で移動して pnpm install を実行します。マニフェストの例は次のとおりです（publisher・author・security は例示の値で、実際は雛形作成時に入力した値を使います）。

// emdash-plugin.jsonc（pnpm dlx @emdash-cms/plugin-cli init save-log で生成）
{
  "slug": "save-log",
  "publisher": "did:plc:abc123def456",
  "license": "MIT",
  "author": { "name": "Jane Doe", "url": "https://example.com" },
  "security": { "email": "[email protected]" },
  "capabilities": ["content:read"],
  "allowedHosts": [],
  "storage": { "events": { "indexes": ["savedAt"] } }
}

処理側は SandboxedPlugin 型のオブジェクトをexportし、フックは { handler: async (event, ctx) => ... } の形で書きます。

import type { SandboxedPlugin } from "emdash/plugin";

const plugin: SandboxedPlugin = {
  hooks: {
    "content:afterSave": {
      handler: async (event, ctx) => {
        const savedAt = new Date().toISOString();
        await ctx.storage.events.put(`${savedAt}:${event.content.id}`, {
          savedAt,
          collection: event.collection,
        });
      },
    },
  },
};

export default plugin;

pnpm run build で dist/index.mjs（サイトが読み込む記述子）が生成され、サイト側は astro.config.mjs の sandboxed: [saveLog] に登録します。マニフェストの publisher には、後述するAtmosphereアカウントのハンドルかDIDが必要です。発表時の1ファイル例を写しても1.x系の手順にはならないので、コードは公式チュートリアルから起こしてください。

プラグインレジストリの公開・検証の仕組みとMarketplaceからの移行

1.0と同時に、中央のMarketplaceに代わって分散型のプラグインレジストリが公開されました。Blueskyと同じAT Protocol（atproto）の上に作られ、作者はAtmosphereアカウントで公開し、パッケージとリリースの記録は作者自身のアカウントに署名付きで保存されます。カタログは plugins.emdashcms.com で閲覧でき、管理画面の「Registry」から入れられます。

インストール時、EmDashはダウンロードした成果物のチェックサム・名前・版・要求権限を署名付きの記録と照合し、同意画面で権限を見せてから入れます。更新で権限が増えるときや、認証付きルートが公開ルートに変わるときは、改めて確認を求めます。2026年10月時点で扱えるのは無料プラグインだけで、有料プラグインは今後の対応予定です。0.x時代にMarketplaceから入れたプラグインは、marketplace オプションを残している間は更新・削除ができますが、レジストリ版へ自動では移りません。

WordPressからの移行：WXRかEmDash Exporter

WXR・EmDash Exporter・URL入力の取り込み方式の違い

公式の移行ガイドが案内する取り込み方式は、WXRファイルのアップロードと、WordPress側に入れるEmDash Exporterプラグインの2つです。

EmDash Exporterは GitHubのリリースページからzipで配布されており、2026年10月18日時点でWordPress.orgのプラグインディレクトリには掲載されていません（公式APIで「Plugin not found」）。最新は2026年10月12日の1.2.0で、このバージョンから移行キー方式（WordPressの「ツール→EmDash Migration」で発行してEmDash側に貼る）と、コメント・メニュー・ロゴ・ファビコンの書き出しに対応しました。1.2.0未満では、これらが黙って欠落し、欠落の報告も出ません。Exporterを入れたサイトなら、EmDash側でURLを入力し、WordPressのアプリケーションパスワード画面で承認する方法でも取り込めます。WordPress.com向けのOAuth取り込みは存在せず、WordPress.comのサイトもWXRかExporterで移します。

EmDash側は管理画面の「Import」（/_emdash/admin/import/wordpress）で、ファイルのアップロード・移行キーの貼り付け・URL入力のいずれかを行い、投稿タイプごとの取り込み先と著者の対応付けを確認してから実行します。WXRは添付ファイルの実体を含まないため、メディアの取り込みが終わるまで元のWordPressを公開したままにしておく必要があります。

WordPress移行で作り直しが必要なブロック・フィールド・URL

• サーバー側で描画するブロック：「最新の投稿」やプラグイン製のブロックは保存済みのHTMLを持たないため、元のブロックコメントだけを含むHTMLブロックとして入り、サイト上には何も表示されない。作り直すか削除する。
• カスタムフィールド・ACF：WXRでは任意のメタ値は写らず、分析結果に一覧が出るだけ。Exporter経由ならACFの値を移せるが、リレーション・画像フィールドはWordPress側のIDやURLを指したまま入る。
• 公開状態：WordPressの非公開（private）は下書き（draft）として入り、承認待ち・予約・ゴミ箱の状態も再現されない。公開前に該当記事を見直す。
• 再利用ブロックとカスタム分類：WXRの再利用ブロックはセクションとして入る。WXRのカスタム分類は、EmDash側に同じ定義が無いと割り当てごと飛ばされる。
• URLとリダイレクト：パーマリンク構造は自動で再現されない。旧URLを一覧化し、変わるURLすべてにリダイレクトを用意してから切り替える。

既存のWordPressを続けるか乗り換えるかの比較材料として、現行版の変更点はWordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順にまとめています。移行の可否判断やCMS構築をまとめて任せたい場合は、一創のWordPressサイト制作・CMS構築でも相談を受けています。

AIエージェント連携：MCPサーバー・CLI・x402

組み込みMCPサーバーとCLIでできる操作

EmDashは /_emdash/api/mcp にMCPサーバーを持ち、既定で有効です。コンテンツ・スキーマ・メディア・分類・メニュー・リビジョン・設定の読み書きと、サイト全体の書き出し・取り込みができます。認証はBearerトークンで、ブラウザで承認するOAuth 2.1（PKCE）、コマンドライン向けのデバイス認可、個人アクセストークンに対応し、トークンのスコープとユーザーの権限を別々に検査します。セッションCookieでは通りません。

CLIは emdash login でデバイス認可を通したあと、emdash content・emdash schema・emdash media・emdash menu などでサイトを操作します。1.1.0からは、訪問者のブラウザ内のAIエージェントに公開記事の検索を提供する コンポーネント（emdash/ui/webmcp-search）も加わりました。Cloudflare上でMCPサーバー自体を構築する方法はCloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータルで扱っています。

x402のボット限定課金はBot Managementが前提

@emdash-cms/x402 は、HTTP 402でコンテンツへの支払いを求める統合パッケージです。公式ガイドによると、全リクエストに支払いを求める通常モードと、ボットだけに課金する botOnly モードがあります。botOnly はCloudflareの request.cf.botManagement.score を読み、既定ではスコア30未満をボットとして課金します。

注意点は、ボット判定のデータが無いリクエストを「人間」として扱い、課金を飛ばすことです。ローカル環境、Cloudflare以外での配信、Bot Managementを有効にしていないCloudflareのゾーンでは、すべてのリクエストが素通りします。AIクローラーから確実に対価を取りたい用途で、Bot Management無しに botOnly を使っても何も止まりません。決済ネットワークは例ではBaseメインネット（eip155:8453）、ファシリテーターの既定は x402.org です。

日本語対応と導入判断

管理画面の日本語化と多言語サイトの注意点

管理画面のロケールには ja が同梱されており、日本語UIで編集できます。1.2.0で追加された admin.locales を使うと、管理画面を使う言語だけに絞って配布サイズを減らせます。一方、公式ドキュメントに日本語版はありません。

多言語サイトでは、EmDashはAstroのi18n設定をそのまま読みます。翻訳は言語ごとに別の行として保存され、言語ごとにスラッグ・公開状態・リビジョンを持てます。ここで既定言語にもURL接頭辞を付ける設定（prefixDefaultLocale: true）にすると、管理画面 /_emdash/admin が404になります。日英サイトで /ja/ と /en/ を両方付けたい場合は、Astroの既定の振り分け方のまま、前段のリダイレクトで対応します。

EmDashを採用すべき場面とWordPressに残すべき場面

採用してよいのは、新規に作るコンテンツサイト・企業サイト・オウンドメディアで、AstroやTypeScriptを書ける体制がある場合です。1.0でコアのAPIが固定され、Cloudflare自身の公式ブログという大量アクセスのサイトで稼働している以上、「まだベータだから」は見送る理由になりません。ホスティング事業者や制作会社が多数のサイトを預かる場合も、プラグインの権限を絞れる点とWorkers for Platformsでサイトごとに動かせる点が効きます。

見送るべきなのは、WooCommerce前提のECサイトと、多数のWordPressプラグインに機能を頼っているサイトです。WordPressのプラグインとテーマはそのままでは動かず、EmDashのECプラグインは1.0の発表時点で最初の1本が出たばかりです。PHPの保守体制しかない組織、サンドボックス型プラグインを使いたいのに月5ドルの有料プランを避けたい場合も、得るものより移行の手間が上回ります。CMSを選び直す段階であれば、ヘッドレスCMSのPayload CMSとは？使い方・Next.js統合・Strapiとの違いを解説【v3.90・4.0 beta】と並べて比べるのが現実的です。

よくある質問

EmDashは無料で使えますか？

EmDash本体はMITライセンスで無料です。Cloudflareの無料プラン（Workers Free）でも管理画面・API・メディアまで動きますが、1日10万リクエストと1回10ミリ秒のCPU時間が上限です。サンドボックス型プラグインを動かす・レジストリから入れるには、月5ドルからのWorkers Paidが必要です。Node.jsで自己ホストする場合の費用は構成次第で、SQLiteとローカル保存の1台構成ならサーバー代だけ、PostgreSQLやS3を使えばその利用料が加わります。

WordPressから移行するのにEmDash Exporterプラグインは必要ですか？

必須ではありません。WordPressの「ツール→エクスポート」で作るWXRファイルだけでも、投稿・固定ページ・下書き・分類・著者を取り込めます（WordPressの非公開記事はEmDashでは下書きになります）。SEO設定、ACFの値、コメント・メニュー・ロゴまで移したい場合は、GitHubで配布されているEmDash Exporter（1.2.0以上）を入れます。Exporter未導入のサイトはURLを入れても件数の確認しかできず、Exporter導入後はURL入力とアプリケーションパスワードでの承認で取り込めます。

Cloudflare以外（DockerやAWS）でも動きますか？

動きます。Node.js 22.16以上の環境で、SQLite・PostgreSQL・libSQLとS3互換ストレージを使って自己ホストでき、公式ドキュメントにDockerfileとdocker composeの例があります。プラグインのサンドボックスもworkerdの子プロセスで動きますが、CPU時間とサブリクエスト数の制限は強制されず、x402のボット限定課金やWorkers Cacheとの連携はCloudflare上でしか機能しません。

EmDash 1.0は本番環境で使えますか？

使えます。2026年9月28日の1.0でstableとなり、コアパッケージは破壊的変更をメジャー版でだけ出す方針です。Cloudflareは2026年8月から自社の公式ブログをEmDashで運用しています。ただし公式プラグインとプラグイン開発ツールは0.xのままなので、プラグインに依存する部分は更新のたびに動作を確かめてください。

npm create emdashでEmDashを始めるにはどうすればよいですか？

Node.js 22.16以上を入れたうえで npm create emdash@latest を実行し、プロジェクト名・デプロイ先（Cloudflare か Node.js）・テンプレートを選び、依存関係のインストールに「Yes」と答えます。生成されたディレクトリへ cd で移動して npm run dev で起動し、http://localhost:4321/_emdash/admin を開くと初期設定の画面が出ます。Cloudflareアカウントがあれば、READMEの「Deploy to Cloudflare」ボタンからテンプレートを直接デプロイすることもできます。

関連記事

• Cloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方
• Astroフレームワークとは？特徴と使い方・Next.jsとの使い分けを解説【2026年版】
• WordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順
• WordPressとReactの連携方法：ヘッドレス化とテーマ組み込みの手順【WordPress 7.1・Next.js 16】
• Payload CMSとは？使い方・Next.js統合・Strapiとの違いを解説【v3.90・4.0 beta】