Cloudflareは2026年4月初旬にemdash CMS v0.1.0プレビューをリリースしました。売り文句：オープンソース、MITライセンス、Astro優先、機能が限定されたプラグイン、投稿タイプごとのデータベーステーブル、MCPを介したファーストクラスビルダーとしてのAIエージェント。Maciek Palmowskiはmaciekpalmowski.devで鋭い初期レビューを書き、アーキテクチャ上の約束とエディタ体験の妥協を捉えました。これは、コードベース、ドキュメント、そしてこのプロジェクトが実際に何を目指しているのかを掘り下げた後の私の正直な見方です。
短い版：アーキテクチャの選択は正しい。エディタの選択は疑問の余地がある。価格設定は比類のない（無料、MIT）。対象となるオーディエンスはマーケティングが示唆するより狭く、それで問題ない — いくつかのチームにとって正しいWordPress代替が、すべてのチームにとって正しい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年の新規プロジェクトなら、適切な形のプロジェクトではデフォルトになる可能性がある。アーキテクチャは正しい、成熟度がまだ追いついていない。そのギャップは四半期ごとに閉じていく。
次のステップ
元のレビューが読みたければ、Maciek Palmowskiの記事（maciekpalmowski.dev）が標準的な参考資料。emdashプロジェクトはemdashcms.devで、ソースはGitHubにある。emdash、Sanity、Storyblok、Payload、Decap、Tina、Hygraph、headless WordPress、その他 — 特定のプロジェクトのCMS選択について相談したければ、30分の通話が正しい出発点。このサイトの/developers/emdash/ページに、emdash開発エンゲージメントが実際にどのように機能するかが記載されている。