プラグインを隔離して動かす。それがEmDashの最大の売りでした。ところが公開されているプレイグラウンドを開くと、プラグインは0件です。しかもコードを追うと、その導線は意図的に閉じられていました。無料で触れる範囲に何があり、何がないのか。約1時間の環境を触ってみました。
Cloudflareが開発するオープンソースCMS「EmDash」は、ブラウザーだけで試せるプレイグラウンドを公開している。try.emdashcms.com を開くと、アカウント登録なしで管理画面が立ち上がる。筆者の環境では約10秒だった。画面は日本語で、バージョンはv0.35.0。4月の公開時点はv0.1.0である。
セッションの寿命は実装上1時間と定められている。管理画面からコンテンツタイプを定義でき、フィールドは16種類から選べる。一方、プラグインの導入とマーケットプレイスへのアクセスは、プレイグラウンドでは遮断されている。
WordPressからのインポートでは、サイトのURLを入力すると項目ごとの移行可否が表示される。
10秒で開くプレイグラウンド
試したのは2026年8月26日、Chromeからです。try.emdashcms.com を開くと「Creating your playground…」の表示が出て、データベースの用意とデモコンテンツの読み込みが進み、筆者の環境では約10秒で管理画面に着きました。メールアドレスもパスワードも求められず、パスキーの登録もありません。着地した時点で、匿名の管理者ユーザーとして始まります。
画面は日本語でした。リポジトリにはi18nのディレクトリと翻訳管理の設定が置かれ、日本語のカタログも用意されています。
左下に表示されたバージョンはv0.35.0でした。4月に公開されたときはv0.1.0です。約5か月で、v0.1.0からv0.35.0まで進んだことになります。
画面下部には黒い帯があり、「54m remaining」と残り時間が表示されていました。実装ではTTLが3600秒に設定され、残り時間はセッションの作成時刻から計算されます。期限は開いてから1時間で、確認した時点では54分残っていたことになります。
プラグインは0件だった
EmDashが掲げる最大の特徴は、プラグインを隔離して動かす仕組みです。WordPressのプラグインはデータベースにもファイルにも直接手が届きますが、EmDashのサンドボックス化されたプラグインは、事前に宣言した権限の範囲でしか動けません。なお、EmDashのプラグインにはサンドボックス型とネイティブ型の2種類があり、後者はサイトと同じプロセスで動きます。
その画面を開くと、こう表示されました。「プラグインが設定されていません」。一覧は0件で、右上にも「0件のプラグイン」とあります。案内文には「astro.config.mjsにプラグインを追加してEmDashの機能を拡張できます」と書かれていました。
EmDashには、管理画面のマーケットプレイスからプラグインを検索してワンクリックで導入する仕組みがあります。ただしプレイグラウンドでは、この経路が意図的に遮断されていました。実装を見ると、プラグインの導入とマーケットプレイスへのアクセスは遮断対象として並んでおり、コードには「セキュリティの境界」と注記されています。
サンドボックスの実行環境は差し替えられる設計です。Cloudflare Workers上ではDynamic Worker Loaderが使われ、公式のREADMEはこれが有料アカウント（月5ドルから）の機能だと案内しています。Node.js環境向けには、workerdを使うランナーも用意されています。公式ドキュメントには開発状況の記述に揺れがありますが、少なくとも隔離実行の手段がCloudflareの有料機能だけに限られるわけではありません。
遮断されているのはプラグインだけではありません。認証や初期設定、APIトークンといったセキュリティ上の要所、メディアのアップロードのような悪用されうる経路、スナップショットの書き出しのように使い捨ての環境では意味の薄い機能も、同じ扱いです。
メディアライブラリが0件だったのは、また別の仕組みによります。プレイグラウンドは初期データを読み込むとき、画像のダウンロードを行わない設定になっています。そのうえで、新しいメディアのアップロードも遮断されている。デモ記事にアイキャッチが表示されていながら、ライブラリが空だったのはそのためです。
一方で、コンテンツの作成と編集、スキーマの変更、分類、メニュー、ウィジェット、検索、設定は使えます。主要なCMS機能は広く開かれ、その外側の一部に線が引かれている、という設計です。
本文の欄がないCMS
では編集の側で何ができるのか。ここからが面白いところでした。
「コンテンツタイプ」の画面にはPagesとPostsの2つが並び、それぞれの「ソース」が「ダッシュボード」と記されています。組み込みではなく、管理画面から作られたものと同じ扱いです。右上には「新しいコンテンツタイプ」のボタンがあります。
RecipeとRecipesという名前で作ってみると、保存した直後にサイドバーへRecipesが加わりました。PagesやPostsと同じ並びに、区別なく置かれます。一覧画面には検索窓、ステータスや執筆者での絞り込み、日付範囲、並べ替え、ゴミ箱まで最初から備わっていました。型をひとつ定義しただけで、管理機能が丸ごと生えてくるのです。
編集画面に入ると、slug、status、created_at、updated_at、published_atといった項目が「システム」として並び、その下に「カスタムフィールド」の区画が分かれています。システム側には編集も削除のアイコンもありません。触れるものと触れないものが、構造として分けられています。
フィールドを追加すると、短文テキスト、長文テキスト、数値、整数、ブール値、日時、選択、マルチセレクト、リッチテキスト、画像、ファイル、参照、JSON、スラッグ、URL、リピーターが並びました。公式のリファレンスも16種類と明記しています。数値と整数を分けているところに、型安全を掲げるCMSらしさが出ています。
リピーターは実務でも使いどころがあります。材料を何行でも、といった可変長の構造を管理画面から作れます。サブフィールドには短文テキストから画像まで9種類の型を選べ、最小と最大の件数も指定できました。参照も16種類のうちの一つで、別のコンテンツを指し示す型です。ただし管理画面のコードを見ると、参照先のコンテンツタイプを選ぶ設定がまだ用意されていません。公式のリファレンスは参照先の指定を必須としているので、型として在ることと、管理画面だけで使えることのあいだには、いまのところ段差があります。
設定項目には「必須」「一意」「インデックス済み」が並び、最小値と最大値の指定もできました。一意制約とインデックスを管理画面から張れるのは、データベースの設計そのものです。
「調理時間」という数値フィールドを追加して、Recipesの新規作成画面を開きました。現れたのは、調理時間の入力欄がひとつだけ。本文を書く欄はありません。
これは省略ではなく、「投稿には本文がある」という前提が最初から置かれていないということです。本文が要るなら、リッチテキストのフィールドを自分で定義する。公式のリファレンスでも、管理画面のコードでも、本文はシステム側の項目に含まれていません。
表側も確認しました。「サイトを表示」を開くと、アイキャッチ画像付きの記事一覧、検索窓、タグ、RSS、ライトとダークの切り替えが備わったブログが立ち上がっていました。執筆者名の横に「+1」と付く記事があり、複数の書き手にも対応しています。ただし、管理画面で新しい型を作れば自動的に公開ページができるわけではありません。表示のしかたはAstro側のテーマが決めます。表側にも管理画面と同じ黒い帯が出ていて、残り時間を告げていました。
日本語で使うと見える段差
日本語で入力すると、いくつか段差が見えました。
コンテンツタイプの名前に「レシピ」と入れたところ、複数形の欄が「レシピs」となり、スラッグには「s」だけが入りました。管理画面のコードを見ると、単数形の末尾に「s」を足して複数形を作り、それを小文字化して英数字以外を置き換えたうえで、前後の記号を取り除いてスラッグにしています。日本語はこの処理で残らず、足された「s」だけが残ったわけです。
一方、フィールドの側で「調理時間」と入れたときは、スラッグの欄は空のままでした。自動生成では英小文字と数字以外が置き換えられるため、日本語だけのラベルでは何も残りません。手でcooking_timeと入力すれば問題なく保存でき、ラベルは日本語のまま残ります。
つまりこれは日本語が扱えないという話ではありません。今回触れた範囲で見つかった日本語固有の段差は、コンテンツタイプ名の複数形とスラッグの自動生成でした。日本語でラベルを付け、スラッグを自分で英字にすれば、この命名上の問題は回避できます。
翻訳の境界も一貫していました。画面のUI文字列は訳される一方、PagesやPostsといったサイト側の名前や、機能の識別子はそのまま残ります。翻訳の対象と、サイトのデータが、別の層として扱われているということです。実際、コンテンツタイプのラベルに「レシピ」と日本語を入れれば、そのまま保持されます。
WordPressからの移行はどこまで運べるか
「インポート」の画面には、WordPressから移す3つの入口が用意されていました。WordPress側にEmDash Exporterを入れて移行キーを発行する方法、サイトのURLを入力する方法、WXRファイルをアップロードする方法です。進行の表示は接続、確認、インポートを基本とし、解析でメディアが見つかると4番目の「Media」が加わります。いきなり流し込まず、まず中身を確かめさせる構成です。
筆者が運営する異業種交流ギルド「クロストーク」のサイトのURLを入力すると、WordPressサイトであることが検出され、投稿30、ページ13、メディア489という数字が返ってきました。
そのうえで表示されたのが、項目ごとの移行可否の表です。WXRファイルだけの場合、投稿とページ、メディア、カテゴリーとタグ、独自の分類、アイキャッチ画像、メニュー、下書きと非公開に丸が付きます。サイト設定は一部、Yoast/RankMathは生のメタデータ。ウィジェットとACFフィールドには×が付いていました。Exporterプラグインを入れれば、すべてに丸が付きます。
ACF（Advanced Custom Fields）は、WordPressの投稿に独自の入力欄を足すためのプラグインで、価格や開催日といった項目を管理画面から設計できます。
ここは公式ドキュメントと読み比べる必要があります。移行のドキュメントは、WXRファイルにカスタムフィールドが含まれ、インポートの際にACFのフィールドを解析して型を推定すると説明しています。繰り返しフィールドや柔軟コンテンツはJSONとして取り込まれるとも書かれています。管理画面の表と、ドキュメントの説明が食い違っている状態です。
どちらが実際の挙動なのかは、今回の範囲では確かめられませんでした。ACFで項目を組んだサイトを移すなら、小さく試してから判断するのが確実です。Recipesとcooking_timeを手で定義した作業は、その確認を先取りしたものでもあります。
1時間のあとに残るもの
残り時間が尽きれば、作ったRecipesもcooking_timeも消えます。画面の下には「Deploy your own」のボタンがありますが、その先はGitHubのリポジトリです。ここで作ったものを引き継ぐ仕組みではありません。書き出しの経路も遮断されているので、持ち帰れるのは手元の記録だけです。自分の環境で始めるなら、一から作り直すことになります。EmDash自体はNode.js環境でも動くので、行き先がCloudflareに限られるわけではありません。
それでも、この1時間で分かることは多いと感じました。プラグインの生態系はこれから育つところです。その代わりに見えるのは、型を自分で定義するという設計思想でした。
WordPressは投稿と固定ページを中心に発展し、23年かけてその周りに巨大な生態系を築きました。独自のコンテンツタイプもカスタムフィールドも、コードやプラグインを使えば作れます。EmDashが違うのは、その型の定義そのものを管理画面の中心機能に据え、本文さえ必須の項目にしていない点です。
どちらが優れているという話ではありません。AIエージェントが構造を読み取って操作する時代に、コンテンツの型を最初から明示しておくことにどれだけの価値があるか。10秒で開いて1時間で消える環境は、その問いを手元で確かめるために置かれています。
【関連記事】
CloudflareがEmDashを発表—AIネイティブ設計でWordPressの23年越しのセキュリティ問題に挑む
2026年4月5日の当媒体の記事。v0.1.0プレビュー時点のEmDashを報じたもので、本稿はその約5か月後の続報にあたる。
【編集部後記】
気になったのは、コンテンツタイプ名に「レシピ」と入れた瞬間でした。複数形の欄が「レシピs」になり、スラッグは「s」だけ。管理画面のコードを追うと、単数形の末尾にsを足し、英数字以外をアンダースコアに置き換えて、前後の記号を取り除く処理でした。
画面のラベルは日本語に訳されている一方、この名前とスラッグを組み立てる規則には、英語を前提とした部分が残っています。多言語対応というのは、文字を置き換えるところから先に、まだ道のりがあるのだと思います。
【用語解説】
EmDash（エムダッシュ）
Cloudflareが開発するオープンソースのCMS。Astroを基盤に、全体がTypeScriptで書かれている。WordPressの「精神的後継者（spiritual successor）」を標榜し、プラグインを隔離して動かす仕組みを特徴とする。
プレイグラウンド
インストールせずにブラウザーだけで製品を試せる環境。EmDashの場合、一時的なデータベースとデモコンテンツが自動で用意され、実装上は1時間で消える。
コンテンツタイプ
投稿や固定ページなど、コンテンツの種類を定義する枠組み。EmDashではコードではなくデータベースで定義され、管理画面から作成・変更できる。ひとつ作るごとに実際のSQLテーブルが用意される。
フィールド
コンテンツタイプに属する個々の入力項目。短文テキスト、数値、日時など型が決まっており、EmDashでは16種類が用意されている。
リピーター
同じ項目の組を必要な数だけ繰り返せるフィールド型。材料や手順のような、件数が決まっていないデータを扱うときに使う。
参照
別のコンテンツを指し示すフィールド型。ただしv0.35.0では、参照先を管理画面から選ぶ設定が用意されていない。
スラッグ
URLやAPIの経路に使う識別子。英小文字と数字が基本で、日本語や記号はそのまま使えない。
サンドボックス
プログラムを隔離された環境で動かし、外部への影響を制限する仕組み。EmDashのサンドボックス型プラグインは、事前に宣言した権限の範囲でのみ動作する。
Dynamic Worker Loader
Cloudflareの機能で、実行時にプログラムを動的に読み込んで隔離実行する。EmDashがCloudflare上でプラグインを隔離する際に使われ、有料アカウント（月5ドルから）の機能とされている。
ネイティブ型プラグイン
サンドボックスを介さず、サイトと同じプロセスで動くプラグイン。管理画面のReactページなど、ビルド時の統合が必要な機能に使われる。
ACF（Advanced Custom Fields）
WordPressの投稿に独自の入力欄を追加するプラグイン。価格や開催日といった項目を管理画面から設計できる。
WXR
WordPressの標準的なエクスポート形式。［ツール］→［エクスポート］で生成されるXMLファイル。
パスキー
パスワードの代わりに、生体認証や端末の鍵で本人確認する仕組み。EmDashは通常の環境でこれを既定の認証手段としている。
【参考リンク】
EmDash 公式サイト（外部）
EmDashの公式サイト。このサイト自体がEmDashで構築されている。プレイグラウンドとドキュメントへの入口を兼ねる。
EmDash Playground（外部）
インストール不要で管理画面を試せる公式の体験環境。一時的なデータベースとデモ記事が用意され、制限時間が過ぎると内容は消える。
EmDash ドキュメント（外部）
導入手順、コンテンツモデル、プラグイン開発、WordPressからの移行までを網羅した公式ドキュメント。2026年8月時点では日本語版への切り替えを確認できない。
EmDash GitHubリポジトリ（外部）
EmDashのソースコードの公開先。MITライセンス。テンプレートや一次プラグイン、ドキュメントを含むモノレポ構成になっている。
Cloudflare（外部）
EmDashの開発元。CDN、セキュリティ、エッジコンピューティングのサービスを世界規模で提供している米国の企業である。
Advanced Custom Fields（外部）
WordPressの投稿に独自の入力欄を追加するプラグインの公式サイト。価格や開催日といった項目を管理画面から設計できる。
Astro（外部）
EmDashが基盤とするWebフレームワークの公式サイト。コンテンツを主体とするサイトの構築を得意としているツールである。
【参考記事】
Introducing EmDash — the spiritual successor to WordPress that solves plugin security（外部）
2026年4月1日のCloudflare公式ブログ。EmDashの設計思想と、プラグインを隔離して動かす仕組みを説明している。
EmDash is live（外部）
2026年4月28日のEmDash公式ブログ。提供する編集機能の概要と、プレイグラウンドやローカル起動の手順を案内している。
Choosing a plugin format（外部）
サンドボックス型とネイティブ型の違いを説明した公式文書。実行環境が設定されていない場合にどう扱うべきかも明記されている。
Installing Plugins（外部）
管理画面のマーケットプレイスからプラグインを導入する手順を示す。権限の同意ダイアログと、セキュリティ監査の仕組みを説明する。
Migrate from WordPress（外部）
WordPressからの移行手順を示した公式文書。カスタムフィールドの扱い、ブロックの変換表、リダイレクトの生成まで扱う。
