Cloudflare EmDash は注目する価値があります
Cloudflare によって、再び CMS を巡る議論が興味深いものになりました。その新しいプロジェクトである EmDash は、WordPress の精神的後継者として位置づけられています。オープンソースであり、TypeScript を第一に考え、Astro をベースに構築され、サーバーレスホスティング向けに設計されており、AI エージェント、MCP、スキル駆動型のサイト管理について非常に明確な方針を持っています。
この組み合わせこそが、私たちが最終的に Optagonen.se をこの方向へ移行させるべきかを真剣に考えている理由です。明日というわけではなく、また hype（流行）に乗った移行でもありません。しかし EmDash はまさに、私立ち止まって問いかけるような CMS アーキテクチャです。「もし 2026 年に Optagonen.se をゼロから構築するとしたら、私たちは依然として従来の WordPress スタックを選ぶだろうか？」と。
現在の私の答えは「おそらく違うだろう」です。
WordPress の移行に関する私の経験では、コストがかかるのは最初のローンチが問題なのではなく、長年にわたるプラグインの更新、リダイレクトの修正、編集者のための回避策、SEO メタデータの修正、ホスティング環境の変更などによって蓄積されるメンテナンス負債です。Cloudflare EmDash が興味深いのは、アーキテクチャレベルでそのメンテナンス対象を減らそうとしている点にあります。
だからといって、Cloudflare EmDash がデフォルトで Optagonen.se において本番運用-ready だというわけではありません。しかし、次回の再構築前に制御されたプロトタイプを試す価値は確かにあります。
Cloudflare が発表したこと
Cloudflare は EmDash を、Astro をベースに構築されたフルスタック・サーバーレス JavaScript CMS と表現しています。プレビュー版は v0.1.0 で、MIT ライセンスのオープンソースであり、EmDash GitHub リポジトリ から入手可能です。初期ベータ期間中は、Cloudflare へのデプロイか、Node.js サーバーでの実行が可能です。
中核となるアイデアはシンプルです。コンテンツ編集、拡張性、テーマ、管理ワークフロー、移行パスなど、人々が WordPress について気に入っていた要素は残しつつも、プラットフォームを PHP や共有ホスティングの前提、そしてあらゆる箇所に干渉可能なプラグインに代わり、モダンなインフラストラクチャ周りで再構築することです。
Cloudflare は以下の特定のアーキテクチャ選択に焦点を当てています。
これは小さな変更ではありません。公開インフラのための異なるモデルなのです。
引っかけとなるのはセキュリティの議論です
Cloudflare の最も強力な主張はプラグインセキュリティにあります。WordPress では、プラグインはサイトの他の部分と同じ実行情報内で実行されます。プラグインはデータベースの状態を変更したり、ファイルを読み取ったり、実行の多くの部分にフックしたりでき、脆弱性があれば完全な侵害経路となり得ます。
Cloudflare は Patchstack の WordPress セキュリティデータを引用し、このモデルは構造的にセキュリティを確保することが困難であると主張しています。Patchstack の State of WordPress Security in 2026 によれば、2025 年には WordPress エコシステム全体で 11,334 件の新たな脆弱性が発見され、2024 年から 42% 増加しました。また、新たな脆弱性の 91% がプラグイン、9% がテーマで見つかり、WordPress コアで報告されたのはわずか 6 件だったと報告しています。
これは Optagonen.se のようなビジネスサイトにとって重要です。小規模な WordPress サイトの多くが失敗するのは、WordPress コアが悪いからではありません。スタックがプラグイン、テーマ、管理アカウント、PHP バージョン、キャッシュレイヤー、バックアップ、セキュリティプラグイン、ホスティングの前提条件といった連鎖になってしまうために失敗するのです。
EmDash はそれをアーキテクチャレベルで解決しようとしています。プラグインは事前に機能を宣言します。コンテンツの読み取りアクセスとメール送信アクセスのみを要求するならば、得られるのもそれだけです。Cloudflare はこのモデルをスコープ権限に例えています。インストール前にプラグインに何をする権限があるかが分かるのです。
それはまさに、長年にわたって維持管理を容易にすべきサイトのために私が求めるモデルです。
これが Optagonen.se にとって重要な理由
Optagonen.se は、新規性よりも、信頼性、速度、編集のしやすさ、SEO、フォーム、長期的な保守性が重要なサイトです。問題は EmDash がクールかどうかではありません。サイトを既に必要としている機能を損なうことなく、運用上の摩擦を減らせるかどうかが問題です。
Optagonen.se のために、私は以下の 5 つの実践的な問い围绕して Cloudflare EmDash を評価します。
1. 現在のコンテンツモデルに適合できるか？
最初のテストはコンテンツ移行です。Cloudflare によれば、EmDash は WXR エクスポートを通じた WordPress インポートと、添付メディアを EmDash メディアライブラリに取り込むことのできるエクスポート用プラグインをサポートしています。GitHub の README には、投稿、ページ、メディア、分類、WordPress REST API コンテンツ、WordPress.com コンテンツのインポートについても言及があります。
心強い話に聞こえますが、盲目的に信じるべきではありません。ページ、SEO メタデータ、スラッグ、リダイレクト、画像、代替テキスト、フォーム、内部リンク、カスタム投稿タイプなど、実際の Optagonen.se のコンテンツでテストする必要があります。移行が成功するのは、公開 URL とランキングシグナルが維持された場合に限られます。
2. プラグインスタックをクリーンに置き換えられるか？
これが最大の問題です。WordPress が勝っているのは、その巨大なプラグインエコシステムがあるからです。EmDash は新しいものです。Optagonen.se が特定のプラグインの動作に依存している場合、EmDash 側での公式な代替機能、小規模なカスタムプラグイン、あるいはそれらプラグインの必要性自体をなくすよりシンプルなアーキテクチャのいずれかが必要になります。
利点としては、Optagonen.se の移行がシンプル化する機会になり得る点です。WordPress プラグインの使用法の多くは蓄積された履歴に過ぎません。フォーム、リダイレクト、SEO メタデータ、スキーマ、画像最適化、アナリティクス、キャッシュルール、セキュリティなどは、プラットフォーム、エッジレイヤー、コードベースへ移管できることが多いのです。
問題は、それがサイトをシンプルにするのか、それとも複雑さを新しい場所へ移動させているだけなのかということです。
3. AI ネイティブな管理は実際に役立つのか？
ここで EmDash が私にとって興味深いものになります。Cloudflare によれば、すべての EmDash インスタンスは Agent Skills、CLI、組み込みの MCP サーバーを公開できます。つまり、AI コーディングエージェントが CMS で何ができるかを理解し、コンテンツの管理、メディアのアップロード、投稿の検索、スキーマの作成、文書化されたワークフローを通じた作業が可能になるということです。
それは私がすでに好んで構築している方法と一致します。私は以前、ウェブサイトをエージェント対応にする方法→ や、MCP を使った CMS の構築とエージェントフロー→、そして Codex エージェントにとって GPT-5.5 のスキルが重要な理由→ について書いてきました。
EmDash が興味深いのは、そのアイデアを CMS に直接適用している点です。Optagonen.se にとって、これはコンテンツ更新の高速化、構造化された編集の安全性向上、より良い移行サポート、手動の管理操作の削減を意味する可能性があります。ただし、それはエージェントインターフェースが信頼でき、権限管理され、レビュー可能である場合に限り機能します。
4. Cloudflare への依存は許容範囲か？
これがトレードオフです。EmDash は Node.js 上でも動作し、GitHub の README にはデータベース、ストレージ、セッション、プラグインにポータブルな抽象化を使用していると記載されています。しかし、最良のバージョンは明らかに Cloudflare 上に存在します。D1、R2、KV、Workers、Dynamic Worker Loaders、Cloudflare のエッジランタイムなどです。
Matt Mullenweg 氏による EmDash への回答 は、明らかな反論を提示しています。WordPress はほぼどこでも動作する一方、EmDash は Cloudflare のエコシステム内で最も良く機能するという点です。また、彼はエンジニアリングと移行ツールを称賛しつつも、EmDash が WordPress と精神的に結びついているという考えを否定しています。
その批判はもっともです。Optagonen.se にとって、EmDash への移行は、より強い Cloudflare 重力を受け入れることも意味します。サイトがすでに Cloudflare のネットワーク、セキュリティ、キャッシュ、DNS、Workers、デプロイモデルから恩恵を受けているなら、それは問題ないかもしれません。しかし、ポータビリティが最優先事項であるならば、話は別です。
だからこそ、EmDash は自動的な移行ではなく、評価対象として扱うべきなのです。
5. ベータ版は十分に成熟しているか？
バージョン番号を無視して本番移行を行うべきではありません。EmDash は依然としてベータプレビュー版です。GitHub リポジトリは活発で、数千のスターを持ち、すでに多くのリリースがありますが、それが退屈なインフラになったわけではありません。
Optagonen.se にとって、「退屈」であることは良いことです。メリットが明確で、かつ移行を元に戻せるのでない限り、サイトを CMS のテストグラウンドにしてはなりません。
正しい道筋はスパイク（試作）です。
それが評価を行うための唯一の責任ある方法です。
それでも私が惹かれる理由
Cloudflare EmDash が魅力的な理由は、WordPress が死んでいるからではありません。WordPress はエコシステムが巨大で、編集者が使い方に慣れ、ホストがサポートし、脱出経路が無数にあるため、多くのサイトにとって依然として最も安全なデフォルトです。
EmDash が魅力的な理由は、それが私のワークフローが進んでいる方向と一致しているからです。
Optagonen.se のような代理店やスタジオのサイトにとって、それは重要になり得ます。よりクリーンな CMS は公開を高速化します。より権限が制限されたプラグインモデルは攻撃対象領域を減らします。組み込みの MCP は、AI 支援によるコンテンツ作成とメンテナンスのワークフローをより自然なものにします。
WordPress 側にもまだ理がある
「新しい CMS は良く、WordPress は悪い」と枠組みするのは怠慢です。WordPress は、非開発者にとっても機能し、ほぼどこでも動作し、新しい CMS が一夜で模倣できないエコシステムを持っているからこそ、その地位を築いてきました。
そこには実質的な哲学的な違いもあります。WordPress がプラグインに莫大な力を与えるのは、その力がエコシステムを可能にしたからです。EmDash がプラグインを制限するのは、Cloudflare がセキュリティとのトレードオフがもはや許容できないと考えているからです。
どちらの立場も理にかなっています。最大のエコシステムの柔軟性を求めるなら、WordPress を凌ぐのは困難です。より強力な境界線とエージェントネイティブなワークフローを求めるなら、EmDash の方が私が目指す未来にはるかに近いのです。
Optagonen.se にとっての答えは、今後数年間で私たちが何を最も重視するかに依存します。エコシステムの成熟さか、アーキテクチャの明確さか。
現在の私の見解
Cloudflare EmDash が新しいからといって、Optagonen.se を移行させるべきではありません。方向性が正しいからこそ、Cloudflare EmDash を調査すべきなのです。
次の正しいステップは再設計ではなく、プロトタイプです。現在のサイトを受け取り、インポートし、編集・公開フローを判断するのに十分なテーマを再構築し、重要な部分、つまり速度、SEO の維持、メンテナンスコスト、編集者体験、プラグインの置き換え、ロールバックオプションを測定します。
プロトタイプによって、EmDash が URL を維持し、SEO をクリーンに保ち、プラグインを単純化し、より良いエージェントワークフローを提供できることが証明されれば、Optagonen.se の移行は真剣な選択肢となります。
もしそれができないのであれば、WordPress を維持しつつ、良いアイデア、つまりより厳格なプラグインの規律、よりクリーンなコンテンツ構造、より良い Cloudflare 統合、そして意味のある場面での MCP 駆動型の管理ワークフローを盗用すればよいのです。
いずれにせよ、Cloudflare EmDash は、AI エージェント、エッジインフラ、スコープ権限、構造化コンテンツがデフォルトであるとき、CMS はどのようにあるべきかという正しい問いを私たちに突きつけてくれる点で有用です。
Optagonen.se にとって、次の大きな再構築の前にその問いに答える価値はあるはずです。