WordPressに限界を感じたエンジニアが、EmDashにベットする理由

WordPressでサイト制作をしてきたけど、正直もう限界を感じている。

PHPベースの技術スタック、管理画面を開くだけで億劫になる執筆体験、サーバー保守のコスト。ソフトウェアエンジニアとして、もっとモダンな環境で書きたいという欲求がずっとあった。

そんな中、Cloudflareが本気でWordPressを潰しにきているCMSを出した。EmDashだ。

この記事では、自分がEmDashへの移行を決めた理由と、その過程で得られる副次的な価値について書く。

EmDashの現在地(2026年4月時点)

• Cloudflare発、2026年4月1日launched、v0.1.0のベータ
• Astro + TypeScript + Cloudflare Workers ベース
• 本番利用は非推奨、プラグインエコシステム未成熟
• AI-native CMS(MCPサーバー標準搭載、構造化コンテンツ)
• 業界評価は割れている。Joost de Valk は肯定的、Automattic側は批判的
• 非エンジニア向けのワンクリックセットアップは、現時点では満たしていない

発信資産を育てるドメインに絞る

まず前提として、自分は複数のブログを運営していた。しかし、複数メディアの並行運営は発信を薄める。どちらも中途半端になり、どちらも育たない。

そこで、屋号を冠したドメイン「自分にとっての事業メディア」に集中することにした。他のサイトは静的化してアーカイブ、メンテフリーにする。発信資産を一本に絞る決断だ。

なぜツールごと変えるのか

ドメインを絞るだけなら、WordPressのままでもいい。でも、WordPressには3つの不満があった。

書くまでの心理的ハードル。 管理画面を開くのが億劫。ブラウザでログインして、重い管理画面を待って、やっとエディタにたどり着く。この摩擦が、書く頻度を下げていた。

保守コスト。 レンタルサーバー代、WordPressやプラグインのアップデート対応、セキュリティパッチ。本業ではないのに、運用に時間を取られる。非エンジニアでもできるから1つ1つは簡単だが、ちりも積もればなんとやらだ。

技術スタックとしての限界。 PHPベースで、モダンなフロントエンド開発との乖離が大きい。ソフトウェアエンジニアとして、もっと触りたい技術で構築したかった。

これらの不満を解消するために、ツールごと変えることにした。

EmDashにベットする理由

数あるCMSの中で、なぜEmDashなのか。理由は5つある。

Cloudflare社が開発している。 インフラの巨人が本気で作っているCMSだ。継続性とスケーラビリティに不安がない。

フロントがAstro。 しかもAstroもCloudflare傘下になった。Cloudflareのエコシステムの中で、Astroが中心的な役割を担っていくことが見えている。自分は元々Astroを扱っていたので、技術スタックの親和性が高い。

AIフレンドリーを明確に宣言している。 これは単なるマーケティング文句ではない。EmDashの設計自体がAIエージェントを中心に据えている。具体的には、AIエージェント用のスキル機構がデフォルトで用意されていて、いくつかのスキルがすでに同梱されている。TypeScriptベースでAIとの相性が良く、CLIも用意されている。AIと協働しながらサイトを構築・運用する未来が見える。

WordPressを明確にライバル視している。 公式がWordPressを競合として名指ししている。これは本気度の表れだ。中途半端なプロダクトではなく、WordPressを置き換えるつもりで作っている。

自分の技術スタックとの親和性。 Astroは扱っていた。Cloudflareも扱っていた。EmDashは、自分にとって「新しいけど馴染みがある」という絶妙なポジションにある。

移行で同時に回収する4つの価値

この移行は、単なるツール変更ではない。4つの価値を同時に回収する動きだ。

コスト削減。 レンタルサーバーが不要になる。Cloudflareのエッジで動くので、運用コストが大幅に下がる。

新しい収入源の種。 EmDashでのサイト構築を受託できるようになる。WordPressに代わる選択肢として提案できる武器が増える。

連載コンテンツ化。 この移行プロセス自体がブログのネタになる。学びながら書き、書きながら学ぶ。

技術キャッチアップ。 Astro、Cloudflare Workers、AIエージェント連携。業務で日々培っている経験が直接活きる。

需要の予測

• 現時点: 受託ニーズはほぼゼロ
• 6-12ヶ月: Astro+Cloudflareを既に使っているテック企業、セキュリティ重視の企業から出てくる可能性
• 1-3年: 3シナリオ

EmDash開発自体を主軸にするつもりはないが、先行者有利の側面もあるし、EmDashを構成する技術自体はモダンかつ将来性がある認識なので、やっていて損はないと信じている。（そもそも技術習得に損も得もないが）

余談：この記事もSlack起点で書いている

書くハードルを下げるために、Slackから投稿できるフローを構築した。この記事も、Slackのスレッドにメモを書き溜めるところから始まっている。

普段開いているUIを起点にすることで、「さあ書くぞ」という気合いが不要になる。断片から始めて、後で組み立てる。継続の本質は根性ではなく、仕組みとの摩擦をいかに減らすかだ。

詳しい執筆フローについては、別の記事で書く予定。（そう言っておきながら実際に書かれているケースをあんまり見かけないが。頑張る）

注意点：仕組み作りを目的化しない

最後に自戒を込めて。

仕組みを作り込むのに時間を使いすぎないこと。70点で動かして、書きながら改善する。完璧な仕組みを作ってから書き始めると、仕組み作りが目的化する。

まずは書く。書きながら直す。それだけだ。（なんかかっこいい）