Cloudflareは2026年4月初旬にemdash CMS v0.1.0プレビューをリリースしました。売り文句：オープンソース、MITライセンス、Astro優先、機能が限定されたプラグイン、投稿タイプごとのデータベーステーブル、MCPを介したファーストクラスビルダーとしてのAIエージェント。Maciek Palmowskiはmaciekpalmowski.devで鋭い初期レビューを書き、アーキテクチャ上の約束とエディタ体験の妥協を捉えました。これは、コードベース、ドキュメント、そしてこのプロジェクトが実際に何を目指しているのかを掘り下げた後の私の正直な見方です。
短く言うと：アーキテクチャの選択は正しい。エディターの選択は疑問の余地がある。価格は比類のない安さ（無料、MIT）。マーケティング上の対象層より実際の対象層は狭い。それは問題ない。すべてのチームにとって適切なWordPress代替は存在しない。以下が詳しい説明だ。
emdashが実際に何であるのか、1段落で
emdashはTypeScriptで書かれたコンテンツ管理システムで、Astroで構築され、デフォルトではCloudflare Workersにデプロイされ、Node.jsフォールバックがあります。3つのアーキテクチャ上の違いを持つWordPressの後継として自らを位置づけます：（1）プラグインの権限は暗黙的でオールアクセスではなく明示的で機能が限定されている、（2）各投稿タイプはWordPressのwp_posts/wp_postmetaパターンに無理矢理入れられるのではなく独自の専用データベーステーブルに存在する、（3）AI統合は組み込みのMCPサーバーとエージェントがコンテンツをきれいに読み書きできるJSON CLIを介してファーストクラスです。オープンソース、MITライセンス、2026年4月現在v0.1.0プレビュー。
emdashについて何が正しいのか
プラグインのセキュリティモデルは真の建築的改善である
WordPressのプラグインセキュリティは既存のモデル内では解決不可能だ。プラグインはコアと同じプロセスで実行され、同じデータベースアクセス、同じファイルシステムアクセス、そしてリクエストライフサイクルのどこにでも注入できる能力を持つ。侵害されたプラグインはサイト全体を侵害する。emdashはこれを反転させる：プラグインは必要な権限をあらかじめ宣言し（read-content、write-content、send-emailなど）、明示的な機能の境界内で実行される。「send-email」を要求するプラグインは急にデータベースへの書き込みを開始することはできない。「read-content」を要求するプラグインはユーザーのパスワードを流出させることはできない。
これはiOSのアプリ権限、ブラウザ拡張機能の権限、そして一般的に能力ベースセキュリティと同じ考え方だ。これは50年間正しい答えであり、WordPressは後方互換性の理由で22年間これを拒否してきた。emdashはこの立場から出発することで、WordPress形の世界が待っていた建築的リセットである。
ポストタイプ別の専用テーブル
WordPressはすべてのポスト、ページ、カスタムポストタイプ、リビジョンを型判別器付きの単一のwp_postsテーブルに詰め込む。カスタムフィールドはキー値行としてwp_postmetaに格納される。結果として、3つのタクソノミーと12のACFフィールドを持つカスタムポストタイプをクエリすると4〜5テーブルに複数のJOINでアクセスするため、遅いWordPressページビルドの主要な原因になる。emdashは各ポストタイプに専用テーブルと適切なカラムを与える。クエリパターンは当然高速であり、インデックス戦略は当然クリーンであり、50,000行のサイトはWordPressサイトがスキーマの選択を補うために使用する17個のキャッシングプラグインを必要としない。
MCP経由のAIファースト統合
2026年に「AI対応」をうたう多くのCMSは、WYSIWYGにOpenAI APIコールをボルトオンしたことを意味する。emdashはMCP（Model Context Protocol）サーバーとJSON CLIをそのまま搭載する。エージェントはHTMLをスクレイピングしたりブラウザセッションをシミュレートする代わりに、構造化契約を通じてコンテンツの読み取りと書き込みができる。これは2026年に出現しているAI駆動コンテンツワークフローの正しい抽象化であり、エージェントをファーストクラスのビルダーとして扱い、後付けするのではなく、真の差別化要因である。
TypeScriptエンドツーエンド + Astro
モダンスタック、モダンツーリング、PHPなし。スキーマ定義からAPIを通じてフロントエンドまで、型安全性を備えている。レンダリングレイヤーはAstroで、高速がデフォルトの静的・アイランドパターンをもたらす。2026年の開発者主導チームにとって、これが開始するべき正しいスタックである。WordPressは数年間エディタ体験の意味のある改善がない；emdashはゼロから始めることでそこに到達する。
何が間違っているか（少なくとも疑問の余地がある）
2026年のTinyMCEは正しいエディターの選択ではない
Maciekのレビューがこれを指摘して、私も同意する。GutenbergやSanityのPortable Textのようなブロックベースのエディターではなく、TinyMCEを選んだことは後退に感じる。ブロックベース編集は構造化コンテンツワークフロー、マルチチャネルパブリッシング、AIアシストコンテンツにとって本当に優れている。TinyMCEの論拠「ユーザーはそれに慣れている」は、WordPressがGutenbergの導入を5年遅延させ、その後も悪く実装した際の論拠と同じだ。emdashはブロックベースのエディターで始める機会があった。TinyMCEを選ぶことで、初期採用者はSanity、Storyblok、さらには最新のWordPressが編集面で提供できるもの以下を得ることになる。
WordPressユーザーの実際の課題を解決していない
WordPressユーザーはプラグイン権限のためにWordPressに留まるわけではない。彼らが留まるのは、（a）ホスティングが安価で豊富、（b）プラグインエコシステムが一般的な問題をすぐに解決、（c）WordPressの開発者を雇うことが簡単だから。emdashはまだホスティングを安くしていない（Cloudflare Workersは悪くないが規模では無料ではなく、Node.js自己ホストは月4ドルのWordPressホストよりも多くの運用作業である）。プラグインエコシステムはv0.1.0では空である。WordPressの開発者は数百万人；emdashの開発者は数十人である。これらのどれも素早く改善されることはない。
これは問題ない。emdashはEtsyショップブログメーカーの長い尾の層向けのWordPressになろうとしていない。WordPressから卒業した真摯なコンテンツ主導のチームにとって、モダンスタックの正しいアーキテクチャ基盤になろうとしている。しかしマーケティングのポジショニングがそれに合致する必要がある：emdashは一部のチームにとって正解だが、WordPress大多数にとって正解ではない。
プラグインエコシステムが空である（12～24ヶ月間はそのままになる）
グリーンフィールドCMSは常にブートストラップ問題に直面する：プラットフォームの価値はプラグイン可用性でスケール、プラグインはプラットフォームがユーザーを持つ一度にだけ構築され、ユーザーはプラグインが存在する一度にだけ採用する。emdashはこれを緩やかに解決するであろう。次の12～24ヶ月間、emdashのプロジェクトはSEOプラグイン、サイトマッププラグイン、多言語プラグイン、フォームハンドラー、メールニュースレター統合をファースト パーティの作業として書くことを意味する。予算を立てよ。
デフォルトとしてのCloudflare Workersベンダーロック
Cloudflare Workersが主なデプロイターゲットである。Node.jsはサポートされるが、ドキュメントはWorkers優先傾向である。既にCloudflareを使用しているチーム向けに、これは機能である。スタック独立性を望むチーム向けに、デフォルトによるアーキテクチャロックインのように読める。トレードオフはいずれにしても実質的である；emdashがCloudflareネイティブであることはその由来と一貫しているが、ポータブル抽象化ではなくCloudflareエコシステムへの投資を意味する。
emdashが適切な場所、適切ではない場所
適用する場合
Cloudflare Workers + Astro上で構築する新規プロジェクトで、初日からアーキテクチャを正しく設計したい場合。WordPressプラグインの攻撃対象面に疲れた、セキュリティに敏感なデプロイメント。MCPインテグレーションが重要なAIネイティブなコンテンツワークフロー。v0.x段階のCMSでも最先端にいることを優先するデベロッパー主導のチーム。
適用しない場合
v1.0まで少なくとも安定性が必要なミッションクリティカルな本番サイト。エディター体験が決定要因であるマーケティングチーム主導のプロジェクト（Sanity、Storyblok、Contentfulが勝つ）。プラグインエコシステムが本当の仕事をしているWordPressマイグレーション。月4ドルの共有PHPホスティングが正解であるコスト意識の高い長い尾のブログ。深いプール開発者を採用する必要があるチーム。emdashの採用プールは小さい。
2026年の推奨事項
最初はサイドプロジェクトでemdashを試す。本物を構築する。個人ブログ、内部ツール、ドキュメンテーションサイト。プラグインモデル、エディター体験、デプロイメントストーリーの感覚をつかむ。6～12週間後、紙の上で正しく見えるアーキテクチャ選択が本番で実際に正しく感じるかどうかわかる。そうなら、emdashは2027年の新規プロジェクトにとって真剣な選肢になる。エディターの苦痛またはエコシステムのギャップが取り扱いのできない問題なら、その経験はそれを素早く示す。
私の職業的バイアス：今日、船出準備ができたCMSの選択肢が必要なチームと仕事をしている。2026年のクライアント案件では、emdashはまだ早い。2027年の新規プロジェクトなら、適切な形のプロジェクトではデフォルトになる可能性がある。アーキテクチャは正しい、成熟度がまだ追いついていない。そのギャップは四半期ごとに閉じていく。
次のステップ
元の正直なレビューが欲しいなら、maciekpalmowski.devでのMaciek Palmowskiの記事が標準的な参考資料だ。emdashプロジェクトはemdashcms.devにあり、ソースはGitHubにある。あなたの特定のプロジェクトのCMS選択について話を詰めたいなら——emdash、Sanity、Storyblok、Payload、Decap、Tina、Hygraph、headless WordPressなど——30分間の通話が正しい出発点だ。このサイトの/developers/emdash/ページがemdash開発エンゲージメントが実際にはどのように見えるかを説明している。
よくある質問
emdash CMSとは何ですか？
emdashはCloudflareがオープンソース、MITライセンスのCMSとして2026年4月にv0.1.0プレビューとしてリリースしたものです。Astro-firstで、機能が限定されたサンドボックスプラグイン、ポストタイプごとのデータベーステーブル、MCPを通じてファーストクラスビルダーとして扱われるAIエージェントを備えています。WordPressの代替製品として位置付けられています。
emdash CMSは本番環境対応ですか？
2026年の時点ではまだです。v0.1.0プレビューとしてリリースされているため、設計上は初期段階です。アーキテクチャは本当に興味深く、注視する価値がありますが、現在ほとんどの本番サイトを運用するためのエコシステムと成熟度に欠けています。まだ移行対象ではなく、プレビューとして扱ってください。
emdash CMSアーキテクチャの興味深い点は何ですか？
3つあります。拡張機能が何をできるかを制限する機能限定サンドボックスプラグイン、単一の汎用テーブルではなくポストタイプごとのデータベーステーブル、MCPを通じたファーストクラスビルダーとしてのAIエージェントです。WordPressのクローンではなく、CMSデザインの新しいアプローチです。
WordPressからemdashに切り替えるべきですか？
まだです。WordPressは2026年の時点で、エコシステム、成熟度、エディタエクスペリエンスの面でほとんどのチームにとって依然として最適な選択肢です。emdashはアーキテクチャについて注視する価値がありますが、実際のサイトをv0.1.0プレビューに切り替えるのは時期尚早です。成熟するにつれて再度検討してください。