# Cloudflare が WordPress の後継 CMS「EmDash」を作ったので触ってみる WordPress は 2003 年の登場以来、インターネット上のWebサイトの 43% 以上を支え続けています[^wordpress]。これほどの規模で普及したソフトウェアは他にほとんどなく、「誰でもサイトを作れる」という体験を多くの人に届けた偉大なプロジェクトです。 ただ、23 年という年月は技術の世界では相当な重みがあります。WordPress が生まれたころ、AWS EC2 は存在せず、サーバレスなどという概念もありませんでした。プラグインは PHP スクリプトがそのままデータベースやファイルシステムに触れる設計のまま今に至り、[96% のセキュリティ問題がプラグイン起因](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2025/)という状況は変わっていません。 WordPress のこの設計課題に正面から向き合う形で、Cloudflare が 2026年4月1日に「EmDash」を発表しました。WordPress の後継を名乗る TypeScript 製のオープンソース CMS です。発表日がエイプリルフール当日だったので、最初は半信半疑でしたが、GitHub リポジトリを確認すると本物でした。セットアップから、マーケティングテンプレートにブログを乗せるところまで試してみたので、詰まったポイントも含めて解説していきます。 ## EmDash とは何か [EmDash](https://github.com/emdash-cms/emdash) は Astro[^astro] を中心に据えた TypeScript 製の CMS です。MIT ライセンスで、WordPress との互換性を目指しながらも「WordPress のコードは一切使わずにゼロから作り直した」と明言しています。 WordPress との最大の違いはプラグインの動作モデルです。WordPress のプラグインはサイト全体と同じ実行コンテキストで動くため、プラグインがデータベースやファイルシステムに自由にアクセスできます。EmDash では各プラグインが独立した [Dynamic Worker](https://developers.cloudflare.com/workers/runtime-apis/bindings/worker-loader/) のサンドボックスで動作し、プラグインが宣言したケイパビリティ[^capability]以外には一切アクセスできません。 たとえば「記事が公開されたときにメールを送るプラグイン」を書くとこうなります。 ```typescript import { definePlugin } from "emdash"; export default () => definePlugin({ id: "notify-on-publish", version: "1.0.0", capabilities: ["read:content", "email:send"], hooks: { "content:afterSave": async (event, ctx) => { if (event.collection !== "posts" || event.content.status !== "published") return; await ctx.email!.send({ to: "editors@example.com", subject: `New post published: ${event.content.title}`, text: `"${event.content.title}" is now live.`, }); }, }, }); ``` このプラグインは `read:content` と `email:send` の 2 つしか宣言していないため、物理的にそれ以外の操作は一切できません。外部ネットワークへのアクセスも、許可されたホスト名だけに絞れます。WordPress のプラグインが「何でもできる」のと対極にある設計だと思います。 > [!WARNING] > Dynamic Workers を使ったプラグイン機能は 2026年4月4日時点、Cloudflare の有料プランが必要です。 他にも x402[^x402] による有料コンテンツのしくみや、内蔵の MCP サーバ[^mcp]、WordPress からのコンテンツ移行機能など、「昨今の生成AI時代に作るならこうする」という思想があちこちに垣間見えます。 ## セットアップ 今回は pnpm を使ってプロジェクトを作成します。`pnpm create emdash@latest` を実行すると、対話形式でテンプレートとデプロイ先を選べます。 今回はマーケティングページのテンプレートで Cloudflare Workers へのデプロイを選択しました。 ```bash — E M D A S H — ┌ Create a new EmDash project │ ◇ Project name? │ sui-corporate-example │ ◇ Where will you deploy? │ Cloudflare Workers │ ◇ Which template? │ Marketing │ ◇ Which package manager? │ pnpm │ ◇ Install dependencies? │ Yes │ ◇ Project created! │ ◇ Dependencies installed! │ ◇ Next steps ───────────────╮ │ │ │ cd sui-corporate-example │ │ pnpm dev │ │ │ ├────────────────────────────╯ │ └ Done! Your EmDash project is ready at sui-corporate-example ``` `pnpm run dev` を実行するとコンテンツが何もないまっさらなマーケティングページが表示されます。 ![初期状態のマーケティングページ](https://pub-151065dba8464e6982571edb9ce95445.r2.dev/images/d6eaee72a76d2f82fc211df355089249.png) 殺風景なので公式が用意しているシードデータを流し込みましょう。 ```bash npx emdash seed seed/seed.json ◐ Loading seed file... ✔ Seed file is valid ◐ Running migrations... ✔ Applied 31 migrations ◐ Applying seed... ✔ Seed applied successfully! ℹ Settings: 2 applied ℹ Collections: 1 created, 0 skipped, 0 updated ℹ Fields: 2 created, 0 skipped, 0 updated ℹ Menus: 1 created, 3 items ℹ Content: 3 created, 0 skipped, 0 updated ✔ Done! ``` 実行したあと「完了した」と出ているのに、ブラウザを見てもコンテンツが反映されていません。 試しに管理画面(`/_emdash/admin`)へ遷移してサイト名を入力したところ、そこで初めてセットアップの API ログが流れているのが見えて、反映されることが分かりました。 なお管理画面の初期セットアップを完了した後は、シードデータが反映されてこのような状態になります。 ![シードデータ反映後のマーケティングページ](https://pub-151065dba8464e6982571edb9ce95445.r2.dev/images/aabe26e0f848869a84f8f3b2153c38b8.png) ## Seed と DB のしくみでハマる EmDash は管理画面の初期セットアップを完了するまで seed が実 DB へ反映されません。 `http://localhost:4321/_emdash/admin/setup` にアクセスして、サイト名と管理者を作成する初回セットアップを終えて初めてコンテンツが見えます。 ログを見ると理由が分かります。`POST /_emdash/api/setup` が呼ばれた直後に画像のダウンロードとアップロードが走っています。初期セットアップの完了が seed 適用のトリガになっている設計です。 ``` [302] /_emdash/admin [200] /_emdash/admin/setup [200] /_emdash/api/setup/status 📥 Downloading: https://images.unsplash.com/photo-1461749280684-dccba630e2f6?w=1200&h=800&fit=crop ✅ Uploaded: building-long-term.jpg 📥 Downloading: https://images.unsplash.com/photo-1499750310107-5fef28a66643?w=1200&h=800&fit=crop ✅ Uploaded: case-for-static.jpg [200] POST /_emdash/api/setup 501ms ``` 「サイト名を設定しないとコンテンツが反映されない」ではなく、「初期セットアップを完了しないと、その環境の DB への seed 適用が終わらない」というしくみになっています。 EmDash における seed は設定ファイルではなく、DB 初期化のための投入データです。`seed.json` を置くだけでは不十分で、その内容が実際に対象 DB へ適用されていなければなりません。 ## テンプレートを移植する EmDash の公式テンプレートはマーケティング・ブログ・ポートフォリオの 3 種類があります。 実際のマーケティングページでは、製品への理解を深めてもらうためにブログも必要になるケースが多いと思います。 今回選んだマーケティングテンプレートにはブログページが含まれていないので、ブログテンプレートからコンポーネントを移植してみましょう。 移植作業はシンプルで、以下のファイルをブログテンプレートからコピーして `src/pages/posts/` ディレクトリを作るだけで基本的な構成が動きます。 - `src/components/PostCard.astro` - `src/components/TagList.astro` - `src/pages/posts/index.astro` - `src/pages/posts/[slug].astro` - `src/pages/category/[slug].astro` - `src/pages/tag/[slug].astro` - `src/pages/search.astro` - `src/pages/rss.xml.ts` - `src/utils/reading-time.ts` 詳細な移植内容は[こちらのコミット履歴](https://github.com/Suntory-N-Water/sui-corporate-example/commit/f241053daa2f6c17aaa7d8d11c2cb5479b46a3f6)を見てください。 CSS 変数(`--color-accent` など)はマーケティングテンプレートのものが使われるので、レイアウトが崩れることなくテーマが統一された状態でブログが表示されます。 ## 実際にブログを公開してみる 移植後は管理画面(`/_emdash/admin`)からブログ記事を追加できます。ログインはパスキー[^passkey]ベースなのでパスワードがいりません。Cloudflare の発表ブログでも、*passkey-based authentication by default* と説明されています。管理画面も SPA[^spa] として作られていて、コレクション(投稿タイプ)の作成からフィールド定義まで、すべてブラウザ上で完結するようになっています。 ![管理画面ダッシュボード](https://pub-151065dba8464e6982571edb9ce95445.r2.dev/images/a6477056d479d40d29e7409f1aae23a6.png) コレクション一覧からブログ記事の管理画面を開くと、seed.json で投入済みの記事が並んでいます。 ![記事一覧画面](https://pub-151065dba8464e6982571edb9ce95445.r2.dev/images/29e8434cd5aff17ad5bbe6594670a21c.png) エディタはマークダウン記法に対応していて、記入しながらプレビューが確認できます。 ![ブログエディタ](https://pub-151065dba8464e6982571edb9ce95445.r2.dev/images/138fdf4e19ee2ead56cd379a3f6efec3.png) 公開すると、こんな感じでブログページに反映されます。思ったよりスムーズに移植できましたね。 ![公開後のブログページ](https://pub-151065dba8464e6982571edb9ce95445.r2.dev/images/c1085475bf5dbce35666b0bb226f6b61.png) 公開後のブログ URL はこちらです。 https://sui-corporate-example.ayasnppk00.workers.dev/ 気になるところとしては、Markdown をそのままペーストすると書式が自動で反映されないケースがありました。 α版ですので、こういった細かい課題はまだ残っているところだと思います。 ## サイトのレイアウトを修正する テンプレートの移植が完了したら、サイト全体のレイアウトを調整していきましょう。 ヘッダやフッタの構成を変える場合は Astro ファイルの変更が必要になりますが、今回は全体のフォントや色合いなどを CSS の修正だけで調整していきます。 CSSは `theme.css` が本来のカスタマイズ用ファイルになりますが、現状は `Base.astro` の `