Cloudflare が EmDash 1.0 を公開、Agent に優しいオープンソース CMS

Web サイトを作ったことがあれば、WordPress のようなコンテンツ管理システム（CMS。編集者が記事を書き、画像をアップロードし、ページの内容を管理する管理画面）を使ったことがあるはずです。Cloudflare は EmDash という新しいオープンソースの CMS を作りました。Cloudflare はこれを WordPress の「精神的な後継」と呼んでいます。EmDash はエイプリルフールに発表されたため、冗談だと疑った人も少なくありませんでした。そして今、1.0 の安定版が公開されました。無料で、MIT ライセンスのオープンソースで、そのまま本番の Web サイトを動かせます。

以下は、一般の読者が知りたい順に説明します。何なのか、従来の CMS のどんな悩みを解決するのか、どこが目玉か、誰がどんな場面で使うのか、どう始めるのか、そして注意すべき点です。

EmDash とは何か

ひとことで言うと、無料でオープンソース、Agent に優しい Web サイトの管理システムです。次の3種類の人の仕事を分けています。

• 開発者は Astro（Web サイトを作るフロントエンドのフレームワーク）でサイトを作ります。
• 編集者は EmDash の管理画面で記事を書き、メディアを管理します。WordPress を使う感覚に近いものです。
• Agent（自分で作業を進められる AI）は、API、コマンドライン、または内蔵の MCP サーバーを通じて、コンテンツを直接読み書きできます。

1.0 は「安定した」だけではありません。同時にプラグインのレジストリ（プラグインのカタログ）と、オープンソースの AI サイトビルダー EmDash Build（alpha 版）も公開されました。

従来の CMS のどんな悩みを解決するのか

Cloudflare の説明から、4つの悩みを読み取れます。

1つ目は、メンテナンスの負担が重いことです。 Avulux の例が一番わかりやすいでしょう。WordPress のメンテナンス負担にうんざりして、自作のマイクロサイトを EmDash に移しました。イノベーション・システム担当ディレクターは、サイトは使いやすくチームが更新しやすくなければならないのに、WordPress はその逆になっていたと言います。今は、開発者が拡張でき、マーケターが直接内容を編集できる共通のプラットフォームがあるそうです。

2つ目は、プラグインの権限に境界がないことです。 WordPress のプラグインはアプリケーション全体と同じ PHP プロセスの中で動き、データベース、ファイルシステム、ネットワークに直接アクセスできます。問い合わせフォームのプラグインでも、技術的には未公開の記事を読み、ほかのプラグインを書き換え、データをどこにでも送れます。サイト運営者は、そうしないと信じるしかなく、将来の更新でも挙動が変わらないと信じるしかありません。

3つ目は、プラグインストアを1社が握っていることです。 従来のプラグインストアは、発行者のアカウント、パッケージの正式な記録、ユーザーが探すカタログの3つの役割をまとめて持つのが普通です。アカウントが停止され、掲載が取り下げられ、ルールが変わり、サービスが終了しても、発行者は同じ身元とリリース履歴をほかの場所へ持っていけません。

4つ目は、AI にサイトを作らせたあとの小さな変更にコストがかかることです。 いまのサイト作りは、チャット欄から始まることが多く、Agent に作りたいものを説明します。しかし完成したあと、小さなところを直したくなると、プロンプト欄に戻って結果に賭けるか、1行変えるためにクレジットを消費することになります。

この4点に対する EmDash の答えが、以降の各節です。

目玉1：Agent に優しい。API を呼べるだけではない

従来の CMS は人がマウスで操作するためのものです。EmDash は Agent にも3つの入口を開けています。API、コマンドライン、そして内蔵の MCP サーバーです。さらに EmDash Agent Skills（Agent 向けのスキルパック）も提供され、Agent が使い始めやすくなっています。Cloudflare の表現では、EmDash は「Agent の最良の友」です。先ほどの Avulux は、Agent Skills の助けで1日足らずで移行を終えました。

Web サイト構築やホスティングの会社なら、この道はさらに先へ進みます。こうした会社は Workers for Platforms（プラットフォームが顧客ごとのサイトを 1 つの Worker として動かせる Cloudflare のサービス）を使えば、サイトごとにサーバーを用意する必要がなく、顧客がサイトを作り管理する体験に集中できます。EmDash はコンテンツ層を提供します。プラットフォームは管理画面をそのまま使うことも、API とコマンドラインの上に独自の画面を作ることも、内蔵の MCP サーバーの前に Agent を置くこともできます。Cloudflare が挙げる例は、パン屋の店主が「営業時間を変えて」と普通の言葉で頼むと、プラットフォームの Agent が内容を読み、更新し、保存する、というものです。Cloudflare は、Agent 向けの新しい CMS 体験を一緒に作るホスティングパートナーも探しています。

目玉2：プラグインはサンドボックスへ。入れる前に権限を確認

プラグインは CMS のエコシステムの中核です。サイト開発者は同じ連携やワークフローを作り直さずに済み、専門家はノウハウを共有でき、ソフトウェアのビジネスにすることもできます。Cloudflare は、Agent によってこの再利用がさらに価値を持つと見ています。Agent は単発の連携を作ることもできますが、問題を理解し、コードを書き、テストし、あとで保守しなければなりません。プラグインはその作業を形にして残すので、別の Agent は実績のある解決策をそのまま入れて設定でき、ゼロからやり直す必要がありません。

EmDash のサンドボックス化されたプラグインは、別のモデルを使います。各プラグインは隔離された実行環境で動き、自分専用のストレージにはアクセスできますが、サイトのコンテンツ、メディア、ユーザー、シークレット、環境変数、ファイルシステム、ネットワークにはアクセスできません。追加の能力は、プラグインが宣言し、サイト管理者が承認したときにだけ与えられます。

図の右側の例を見てください。メディアの読み取り（media:read）だけを承認されたプラグインが記事の書き込み（posts:write）を要求すると、ゲートキーパーはその能力がないと判断して何も返しません。一方、記事の読み取り（posts:read）を承認されたプラグインは、記事を読む要求なら通されます。リソースは隔離されており、脆弱性の影響はその Worker がアクセスできる範囲に限られます。

つまり、サンドボックス化されたプラグインを入れる体験は、従来の CMS のプラグインというより、スマホアプリを入れるのに近いものです。実行する前に、EmDash はそのプラグインが何をしたいのかを示し、実行時には承認された範囲だけに制限します。下の図は、レジストリにある Cloudflare Email Sending プラグインのページです。「インストール前」の欄に3つの権限が並んでいます。宣言された外部ホスト（api.cloudflare.com）へのネットワークリクエスト、送信メールの監視と変更、そして現在の送信方法を置き換えるメール送信の経路の提供です。

これにより、プラグインは役に立つ仕事をしつつ、無関係な権限は手に入れられません。

大事なのは、これらの能力が互いに独立していることです。メディアの権限を与えても、ユーザーや未公開のコンテンツが見えるようにはなりません。1つのサービスへの接続を許しても、ネットワーク全体が開くわけではありません。これらの境界は実行環境が強制するもので、プラグイン作者の善意に任せていません。

この隔離は Cloudflare 上に限りません。Cloudflare 上では、EmDash は Worker Loader を通じて各プラグインを Dynamic Worker として動かします。Node.js 上では、EmDash が workerd（Cloudflare のオープンソースの Workers ランタイム）を別プロセスとして起動し、その中で各プラグインを隔離されたサービスとして動かします。どちらでも同じマニフェストと、能力で制限された API を使います。

目玉3：どの会社のものでもないプラグインカタログ

権限はプラグインが実行時にできることを縛りますが、もう1つ問題が残ります。プラグインはどこから来て、信頼できるのか、ということです。プラグインのカタログサイト plugins.emdashcms.com が 1.0 と一緒に公開されました。開発者はサンドボックス化されたプラグインを公開でき、サイト運営者は検索し、内容を確認し、インストールできます。

EmDash はプラグインとカタログを切り離します。発行者は自分でパッケージとリリース履歴を保管し、EmDash は探してインストールするための便利な場所を提供するだけです。ほかのサービスも同じ公開内容を索引化し、自前のカタログを作り、自分のポリシーを適用できるので、開発者はやり直す必要がありません。EmDash のカタログは、表示する名前、説明、リンク、画像にデフォルトのモデレーションを適用します。モデレーションで有害な内容をこのカタログ内で隠すことはできますが、リリースを書き換えたり、プラグインの所有権を奪ったり、元の公開記録を消したりはしません。

この仕組みは AT Protocol（atproto）の上に作られています。Bluesky を動かしている分散型ネットワークプロトコルです。プラグイン作者は Atmosphere アカウント（このエコシステムで共通の、持ち運べる身元）で公開します。パッケージと各リリースの記録は発行者が署名し、発行者自身のアカウントに保存されます。

「分散型」は、検証されていないコードを受け入れるという意味ではありません。atproto のリポジトリは署名付きの Merkle Search Tree を使い、包含証明が特定のリリース記録を発行者アカウントの署名付きコミットにつなぎます。そのため EmDash は、カタログのコピーを信じずに、記録を独立して検証できます。そのうえで、プラグインのチェックサム、パッケージ名、バージョン、要求する権限、必要な場合はビルドの由来を確認し、ダウンロードしたパッケージが署名された記録と一致することを確かめます。

EmDash は、発行者やサイト運営者が自分でインフラを運用しなくて済むよう、デフォルトのレジストリサービスをホストしています。Cloudflare はこれらのサービスをすべてオープンソースにもしました。レジストリを動かすアグリゲーター、Workers AI でパッケージの説明を審査するラベラーサービス、任意の Astro サイトにプラグイン一覧を埋め込むローダーです。現時点で対応しているのは無料のプラグインだけです。Cloudflare は将来、同じ分散型モデルで有料プラグインにも対応することを目指し、atproto Spaces の alpha も注視しています。誰でも安全な有料プラグインのマーケットプレイスを運営でき、発行者がソフトウェアで収益を得られるようにするのが目標です。Cloudflare の考えはこうです。プラグインを勝手に奪ったり取り下げたりできる中央の管理者はおらず、プラグインとレジストリの安全性は、何らかの権威や行動規範を信じることではなく、コードに組み込むべきだ、と。

目玉4：EmDash Build。Agent がひとこと指示でサイトを丸ごと作る

同時に公開され、オープンソースになった EmDash Build（alpha 版）は、ホスティング事業者、サイト作成ツール、プラットフォームが自分で動かし、自社のシステムに組み込める AI サイトビルダーです。デモは build.emdashcms.com で試せます。コードは github.com/emdash-cms/emdash-build でオープンソースになっています。

これは前述の4つ目の悩みへの答えです。EmDash Build が作るのは、サーバーレンダリングの Astro ページ、データベース、メディアストレージ、管理画面まで備えた、完全な EmDash サイトです。Agent は要件からコンテンツモデルを設計し、EmDash の MCP サーバーを通じて内容を入れ、それを表示するページを書きます。その後は、あなたや顧客がページ上で直接文字を直したり、投稿を予約したり、Agent に任せたりできます。そのたびにプロンプト欄に戻る必要はありません。

EmDash Build では、プロジェクトごとに専用の Cloudflare Sandbox コンテナがあり、Agents SDK で作られた Agent がその中で自分の作業を検証します。Artifacts がすべての変更を git のコミットとして記録します。サイトを公開すると、内容は本番の EmDash サイトに移り、ホストの Workers for Platforms の名前空間にデプロイされます。

1.0 は何が安心材料なのか

EmDash の最初のベータ版が出たあと、実際にサイトを公開した開発者はすでにいました。それでも Cloudflare には、同じ反応が聞こえ続けました。「面白そうだね。1.0 になったら教えて」。安定していて安全で、アップグレードでコンテンツが損なわれず、Cloudflare が保守を続けると確信したい、ということです。

過去5か月、Cloudflare は貢献者や本番ユーザーと一緒に、どのサイトにも欠かせない部分に取り組んできました。データの安全性、データベース移行、編集ワークフロー、多言語化、プラグインの安全性、性能、そして管理画面・API・MCP・メディアの信頼性です。もっとも象徴的なのは Cloudflare 自身のケースです。今年の夏、Cloudflare は自社の Cloudflare ブログを EmDash に移しました。Cloudflare が「Customer Zero」と呼ぶやり方で、自分が最初の顧客になるということです。ブログは、週に数百万ページビュー、正常なトラフィックで最大毎秒 5,000 リクエスト、散発的な DDoS 攻撃に耐えなければなりません。この移行から、3つのオプション機能が生まれ、いまはすべてのユーザーが使えます。KV オブジェクトキャッシュ、Hyperdrive データベースアダプター（Hyperdrive はデータベース接続を高速化する Cloudflare のサービス）、そして Workers Cache との互換性です。

CMS は組織の最も重要なコンテンツを保管し、何十人もの編集者が毎日使うことも多いため、Cloudflare はベンダーロックインさせないことを強調しています。EmDash は完全に無料で、寛容な MIT ライセンスのオープンソースです。執筆時点で 175 人を超える人がプロジェクトに貢献し、コミットは 1,800 回を超え、インターフェースは 25 言語に翻訳されています。Cloudflare は、Agent が人間の開発者を圧倒するのではなく助けるようにプロジェクトを意図的に作ったとも述べています。Noah Pham はインターンとして Cloudflare に入り、EmDash の2人目のメンテナーになりました。80 件を超える変更を加え、メディアライブラリ、コンテンツエディター、管理画面の重要な部分を担当しています。

エコシステムも育っています。Lexington Themes は EmDash 版付きの Astro テーマを 44 種類提供しています。Urumi は WooCommerce の知見を生かして EmDash 初の EC プラグインを公開しようとしています。Empress は複数ブランドを持つ組織向けのプラットフォームを立ち上げ、自然言語や従来型の管理画面でサイト群を管理できます。

誰が、どんな場面で使うのか

Cloudflare の説明に沿って、自分に当てはまるものを探せます。

• 本番の Web サイトを作るチーム：会社のマーケティングサイトやコンテンツサイト。Cloudflare は、いまは会社のマーケティングサイトを移す好機だとしており、自社のブログが先例です。前提として Astro で開発できる人が必要で、編集者は日常の作業を管理画面で行います。
• 制作会社：Cloudflare が用途として挙げるものの1つが「あなたの制作会社の vibe-coding プラットフォーム」（対話で AI にサイトを作らせるサービス）で、EmDash の上にサービスを構築できます。
• ホスティング事業者とサイト作成プラットフォーム：Workers for Platforms で顧客ごとに独立したサイトを持たせ、サンドボックス化されたプラグインで多数の顧客サイトに拡張を提供し、自前のプラグインマーケットプレイスを運営することもできます。レジストリ全体を開放するか、事前に承認したプラグインだけを選ぶこともできます。
• 個人の小さなプロジェクト：Cloudflare は、話していた個人プロジェクトを Agent に立ち上げてもらえると述べています。Avulux のマイクロサイト移行も1日足らずでした。
• プラグイン開発者：拡張を作って収益を得たい人は、EmDash の許可なしに公開できます。サイト運営者は実行する前に、そのプラグインに何が許されているかを確認できます。
• 多数のサイトを管理する組織：Empress のような、複数ブランドを持つ組織向けのプラットフォームで、自然言語や従来型の管理画面を使ってサイト群を管理する場合です。

使い始めるには

1. まず試す：try.emdashcms.com のプレイグラウンドを開くか、build.emdashcms.com で EmDash Build のデモを試します。
2. ローカルでサイトを作る：ターミナルで次のコマンドを実行します。

npm create emdash@latest

3. デプロイ：Cloudflare のダッシュボードから公式ブログテンプレートをワンクリックでデプロイすることもできます。
4. 既存サイトの移行：Cloudflare は EmDash Agent Skills を使って Agent に移行を手伝わせる方法に触れています。管理画面のメニューにもインポート（Import）の入口があります。
5. プラグインを開発する：公式ドキュメントに、プラグインを作ってプラグインレジストリに公開するまでのステップバイステップのガイドがあります。
6. ソースを読む、自分でホストする：EmDash 本体のプロジェクトは github.com/emdash-cms/emdash にあります。AI サイトビルダー EmDash Build のコードは github.com/emdash-cms/emdash-build にあり、ホスティング事業者やプラットフォームが自分で動かして自社のシステムに組み込めます。レジストリのアグリゲーター、ラベラーサービス、Astro ローダーもオープンソースで、コードは本体プロジェクトの中にあります。
7. コミュニティに参加する：Discord にはすでに 800 人以上が参加しています。貢献はコードを書くことに限りません。翻訳、ドキュメント、テスト、デザイン、課題の整理、質問への回答も貢献です。

どう捉えるか

EmDash は「もう1つの WordPress 代替」にとどまりません。前の各節を合わせて見ると、CMS に3つの問いへ同時に答えさせています。Agent がコンテンツを読み書きできるか（API、コマンドライン、MCP）。Agent や人が入れた拡張が権限を越えないか（既定では権限なし、宣言してから承認、実行環境が強制）。その拡張の出どころを独立して検証できるか（署名されたリリース記録。カタログは入口にすぎない）。Agent に拡張を入れさせる製品を作っているなら、この3点は自分の製品と見比べる価値があります。

ただし現状は見ておく必要があります。レジストリが対応するのは今のところ無料のプラグインだけで、有料マーケットプレイスは計画中です。EmDash Build は alpha 版です。サイト自体は Astro で開発する必要があるため、自分で始めるには開発のスキルが要ります。コードを書かない編集者は、環境が整ったあとで日常的に管理画面を使う形になります。