WordPressはもうオワコン？AI時代のCMS「EmDash」徹底解説

WordPressを使い続けるべきか、Astro向けCMSのEmDashへ移るべきか。判断に迷うWeb担当者向けに、両者の違いを整理します。EmDashは、Astroで作るサイトの記事や画像を管理するCMSです。

この記事では、記事の更新方法、AIやAPI、MCPで記事を管理する方法、費用、移行時の注意点を、公式情報と株式会社ありがとうでの検証を分けて解説します。自社のサイトにEmDashが合うかを考える材料が分かります。

WordPressは「終わった」のか

結論から言うと、WordPressがすべてのサイトで不要になったわけではありません。WordPressには、20年以上使われてきた管理画面、豊富なテーマとプラグイン、PHPを動かせるホスティングの広さがあります。既存のサイトを運用している会社ほど、これらの資産をそのまま活かせる価値は大きいです。

一方で、WordPressの強みと弱点は表裏一体です。プラグインを足すほど便利になりますが、更新の互換性やセキュリティの確認も増えます。テーマを変えると、記事本文はそのままでも表示や導線の調整が必要になります。PHPの実行環境、データベース、サーバーの保守を誰かが持ち続ける必要もあります。

EmDashは、この前提を変える選択肢です。Astroで作ったサイトに管理画面を組み込み、コンテンツをデータベースで管理します。管理画面・REST API・CLI・MCPが同じ権限モデルで動くため、人間の編集とAIからの操作を同じ土台に置けます。2026年9月28日に1.0が公開され、2026年10月22日時点のnpm最新版は1.3.1です。MITライセンスで、Cloudflareが関わるオープンソースCMSとして公式サイトに説明されています。

ただし、EmDashはまだ新しいCMSです。WordPressの20年以上の運用知見と比べると、実運用の蓄積はこれからです。EmDashの公式ブログも、WordPressのプラグイン資産に追いつくには時間がかかると説明しています。WordPressを捨てるかどうかではなく、自分のサイトの制約にどちらが合うかで選ぶ必要があります。

EmDashは何を管理するCMSか

EmDashは、Astroに組み込むCMSです。管理画面は別サービスとして動くのではなく、Astroアプリの中に含まれます。コンテンツタイプを管理画面で定義すると、TypeScriptの型が生成され、Astroのページがデータベースから記事を読みます。

管理画面には、投稿、固定ページ、メディア、メニュー、ウィジェット、タクソノミー、コメント、リダイレクト、著者情報などがあります。下書き、履歴、公開予約、プレビューも管理できます。WordPressの管理画面に近い機能は多いですが、中身はPHPではなくTypeScriptとAstroです。

設置先は大きく2つです。Cloudflare WorkersではD1（Cloudflareのデータベース）にコンテンツ、R2（Cloudflareのオブジェクトストレージ）にメディアを置きます。Node.js（JavaScriptをサーバーで動かす実行環境）ではSQLite、libSQL、PostgreSQLと、ローカルファイルまたはS3互換ストレージを使えます。Cloudflare固有の機能を使わなければ、Node.js環境へ移せる余地があります。

プラグインは2種類あります。サンドボックス型は、宣言した権限と許可した通信先だけを使い、隔離された実行環境で動きます。ネイティブ型はホストアプリと同じ権限で動くため、自由度は高い一方、信頼できるコードだけを入れる必要があります。WordPressのPHPプラグインをそのまま読み込む仕組みではありません。

WordPressとEmDashは何が違うのか

大きな違いは、WordPressのテーマとプラグインの資産をそのまま使えるかどうかです。EmDashはPHPを実行せず、WordPressテーマやプラグインを読み込みません。WordPressからの記事移行はできますが、デザインと独自機能はAstro/EmDash向けに作り直すか、別のサービスへ置き換えることになります。

もう一つは、コードの配信方法です。WordPressはPHPファイルをサーバーに置いて動かすことが多く、テーマやプラグインの変更はファイルの更新として反映されます。EmDashはAstroアプリをbuildし、WorkerやNodeサーバーへdeployします。WordPressでも記事とテーマは別の操作ですが、テーマはサーバー上のファイルとして更新されます。EmDashではコードをbuildした成果物をdeployするため、記事の公開とコードの配信が、別々の経路としてはっきり分かれます。

Astroには、WordPressのテンプレート階層のような自動選択がありません。URLごとにルートを決め、コンポーネントを組み合わせます。テーマを移植するときは、どのURLをどのテンプレートで表示するかを、一つずつ決める必要があります。

どちらが優れているかではなく、既存資産と運用体制で決まります。WordPressのPHP資産を多く持つ会社が、すべてをAstroへ作り直す必要はありません。逆に、Astroで新しく作るサイトなら、最初からEmDashを選ぶ理由があります。

AI/API/MCPで記事運用はどう変わるか

EmDashの特徴は、管理画面・REST API・CLI・MCPが同じ権限モデルで動くことです。MCPは、AIクライアントがCMSの内容を読み書きするための共通規格です。EmDashでは /_emdash/api/mcp にMCPサーバーがあり、Bearerトークン（HTTPヘッダーで送る認証情報）で認証します。

認証は3つあります。対話型クライアント向けのOAuth 2.1 PKCE（ブラウザで承認する方式）、長期運用向けのパーソナルアクセストークン、コマンドライン向けのDevice Authorization Grant（コードをブラウザで承認する方式）です。ブラウザのセッションCookieではMCPは認証されません。

権限はscope（トークンに許す操作の範囲）とユーザーロールの両方で決まります。記事の取得には content:read、作成・更新・公開には content:write が必要です。自分の公開済み記事の編集にはAuthor以上、スキーマや設定の変更にはAdminが必要です。AIが使える操作は、そのユーザーが管理画面でできる操作を超えません。

AIに任せやすいのは、既存記事の検索、下書きの作成、構成の比較、複数記事の一括修正、公開予約です。人が残すべきなのは、事実確認、表現の最終判断、公開してよいかの判断です。AIが記事を書けることと、記事の正確さを保証できることは別です。ここに挙げた操作は公式仕様で可能なもので、自社環境でMCP経由の外部接続まで確認したという意味ではありません。

MCPは魔法ではありません。外部のAIクライアントから使うには、EmDashのBearer認証に加えて、前段のCloudflare Access（管理画面などへのアクセスを制限する仕組み）やリバースプロキシの認証を通す必要があります。管理画面をAccessで守っている場合、MCPのエンドポイントも同じ保護の内側に入ることがあります。クライアントによっては、追加の認証ヘッダーを付けられない場合もあります。接続設計は、記事を書く前に決めておく必要があります。

記事更新とコード配信は別物

ここが最も誤解しやすいところです。EmDashでは、記事の本文やタイトル、公開状態はデータベースに保存されます。Astroのページをサーバー描画（リクエストのたびにHTMLを作る方式）にしている場合、公開後の次のリクエストで新しい内容が読まれます。サーバー描画のページなら、記事を1本直すたびにサイト全体をbuildする必要はありません。

一方、テンプレート、CSS、ルート、設定、EmDash本体の更新はコードです。buildしてdeployする必要があります。deploy時に、EmDash本体のDB構造を更新するコアmigration（データベース移行）が走ることがあります。

注意点が3つあります。1つ目は、事前生成（prerender）のページです。Astroのページを静的ファイルとして生成している場合、データベースを更新しても次のリクエストでは変わりません。再buildが必要です。EmDashはサーバー描画のAstroアプリを前提にするため、既存の静的サイトから移す場合は出力方式の変更になります。

2つ目は、キャッシュです。Cloudflare Workers CacheやKV（キーと値を保存する仕組み）のオブジェクトキャッシュを使うと、公開直後でも古いページが返ることがあります。EmDashには公開時にキャッシュを無効化する仕組みがありますが、独自のキャッシュタグやCDN設定を足した場合は、無効化の範囲を確認します。

3つ目は、WordPressとの比較で誤解しやすい点です。WordPressも記事はデータベース、テーマやプラグインはファイルという分離があります。EmDashが特別に「記事だけDB」なのではありません。違うのは、EmDashのコードがbuild成果物として配信され、記事の更新とコードの配信がより明確に分かれる点です。「WordPressは毎回再buildしている」という意味ではありません。

費用は「ソフト無料」と「運用無料」を分ける

EmDash本体はMITライセンスで、ライセンス料はかかりません。ただし、動かす場所は無料ではありません。Cloudflare Workers、D1、R2、KVの無料枠に入れば小さく始められますが、超えた場合は課金されます。

Cloudflareの無料枠は、記事数が少ないサイトなら十分に見えます。ただし、Workers FreeのCPU時間は1リクエスト10msです。Cloudflare自身が、認証やサーバーサイドレンダリングを含む処理は10〜20msになることがあると説明しています。記事ページの表示、管理画面、Cron（定時実行）、画像処理がこの範囲に収まるかは、実際のアクセスで測る必要があります。超え続けるなら、月5ドルの有料プランや構成の見直しを検討します。

R2は転送料が無料で、画像の配信コストを抑えやすい選択です。一方、画像変換の回数、D1の行読み取り、KVの書き込みは、記事更新やアクセスの中で増えます。24記事程度の小規模サイトでも、画像の枚数、一覧ページのクエリ、管理画面の操作、Cronの頻度で結果が変わります。

ドメイン、メール配信、バックアップ、監視、人件費は、この表に入っていません。Node.jsのVPS、PostgreSQL、S3互換ストレージを使う場合は、別の料金体系になります。WordPressも、ホスティング、有料テーマ、有料プラグイン、保守の費用がかかります。EmDashだけが無料なわけではありません。

移行でつまずくところ

EmDashへ移すには、Astro 6以降とNode.js 22.16以降が必要です。Astro 7.4以降ならNode.js 22.22以降です。既存サイトがAstro 5以前なら、まずAstroのアップグレードが必要になります。サーバー描画（サーバー出力）とアダプター（Astroを動かす環境向けの接続部品）の設定も変わるため、静的サイトのままでは動きません。

WordPressからの記事移行はできます。WXRファイル（WordPressの標準エクスポート形式）、またはEmDash Exporterプラグインを使って、投稿、固定ページ、カスタム投稿タイプ、タクソノミー、著者、メディアなどを取り込めます。ただし、これはサイト全体の移行ではありません。

管理画面のWXR取り込みは、途中から再開するためのファイルを保存しません。失敗したときは、既存の記事をスキップする設定でやり直し、slug（URLの末尾に使う識別子）の変更や重複を確認します。コメント、メニュー、ロゴ、faviconまで取りたい場合は、EmDash Exporter 1.2.0以降が必要です。

運用面でも、WordPressとは責任の範囲が変わります。データベース、メディアストレージ、バックアップ、EmDashのアップデート、コアmigration、パスキー（指紋や顔認証でログインする仕組み）、MCPトークン、キャッシュ、Cronが、サイトの運用チームの責任になります。Cloudflareでは予約投稿にCron Triggerとscheduledハンドラー（定時実行の処理）が必要です。Node.jsではプロセスが止まると予約投稿も止まります。メールのマジックリンクや通知を使うなら、Cloudflare Email Sendingなどのメール配信設定も別途必要です。プレビュー環境は、本番と別のデータベースとストレージを使います。

公式ドキュメントでは、フィールドやコレクションの削除は元に戻せない操作として扱われています。フィールドを削除すると、その列の値も消えます。コレクションを削除すると、その記事も消えます。本番で試す前に、バックアップと検証環境で同じ操作を試す必要があります。seedファイルは初回のDB作成にだけ使われ、既存サイトのスキーマを後から変えるものではありません。

パスキーはホスト名に紐づきます。検証用のworkers.devで登録したパスキーは、本番ドメインでは使えません。本番ドメインでセットアップするか、EMDASH_SITE_URLを本番に設定してから初期設定を行います。後からドメインを変えると、旧ドメインのパスキーは使えなくなります。

EmDashはビジュアルなページビルダーではありません。記事の入力画面はありますが、デザインはAstroのコンポーネントで作ります。WordPressのように、テーマの管理画面から色やレイアウトを細かく変える使い方とは違います。EmDashは管理画面とフロントエンドを同じアプリとしてdeployするため、ヘッドレスCMSのように管理画面だけを独立して更新する形には向きません。

向くサイト・向かないサイト

EmDashが向くのは、Astroで作ったコーポレートサイトやブログで、編集者は管理画面を使い、開発者はコードを管理し、AIやAPIで記事更新を効率化したい場合です。記事の更新とコードの配信を分けたい、プラグインの権限を絞りたい、CloudflareやNode.jsの運用体制がある、といった条件も追い風になります。

WordPressが向くのは、既存のテーマやプラグインをそのまま使いたい場合です。WooCommerce、会員サイト、多言語、フォーム、SEOプラグインなど、既製の組み合わせで早く立ち上げたいなら、WordPressの資産は依然として大きいです。制作会社に運用を任せていて、PHPの保守を社内に持ちたくない場合も、WordPressの方が現実的です。

どちらでもない場合もあります。複数のフロントエンドに同じ記事を配信するなら、独立したヘッドレスCMSの方が向きます。記事をGitで管理したいだけなら、Astroのファイルベースのコンテンツで足ります。EmDashは、あくまでAstroサイトと管理画面を1つにまとめたい場合の選択肢です。

移行を決める前に、次の5つを確認します。

1. 現在のサイトはAstroか。Astroへ作り直す予定はあるか。
2. 編集者に管理画面が必要か。記事の更新頻度と人数はどのくらいか。
3. データベース、ストレージ、バックアップ、deployを運用できる人がいるか。
4. WordPressのテーマ、プラグイン、WooCommerceへの依存はどのくらいか。
5. AI/API/MCPで何を自動化したいか。認証と公開範囲を設計できるか。

移行は、サイト全体を一度に置き換えない方が安全です。1つの記事タイプ、1つのセクションから始め、URL、SEO、画像、フォーム、リダイレクトを確認します。WordPressは、新しいサイトが本番で安定するまで残します。戻せる状態を保ったまま、少しずつ移します。

自社で試して分かったこと

2026年10月21日から22日にかけて、自社の検証環境でEmDashを試しました。ローカルではEmDash 1.3.1、Astro 6.4.8、Node.js 22.22.3、SQLiteを使いました。実際の記事1本を、カバー画像、情報カード、Instagramの埋め込み3件を含む形で取り込みました。

REST APIで記事の説明文を更新し、公開しました。次のHTTPリクエストで新しい説明文が返り、再buildなしで反映されることを確認しました。テスト後は元の説明文に戻して再公開し、確認用に付けた説明文の変更が残っていないことも確認しました。画像、情報カード、埋め込みHTMLの保持も確認しています。

Cloudflare向けには、Astro 7.3.8、Workers、D1、R2、KVの構成で候補を作りました。24本の公開記事を取り込み、専用のWorkerで表示を確認しました。別サイト「湘南Life」（shonanlife.net）では、2026年10月22日に24本の記事を本番配信しています。湘南Lifeは株式会社ありがとうのサイトとは別のサイトです。

株式会社ありがとうのサイトも、2026年10月23日に独立したEmDash環境へ移行し、本番ドメインで配信を開始しました。既存の6本の記事と下書きを保持し、問い合わせフォームも動作確認しています。EmDash管理画面の保護を保ったまま、MCPの認証付き接続と記事の登録・公開も確認しました。これは湘南Lifeとは別のデータベースとメディア保存先を使う構成です。

MCPについては、株式会社ありがとうの本番環境へ認証付きで接続し、記事の読み取りと登録・公開を確認しました。Cloudflare Accessで管理画面を保護し、MCPはBearerトークンで認証しています。

費用についても、現在の構成が無料枠に収まるかは確定していません。Cloudflare Workers FreeのCPU上限、D1の行読み取り、R2の画像変換、KVの書き込みを、実際のアクセスで測る必要があります。無料枠で始められる可能性はありますが、運用全体が無料だとは言えません。

これは自社の検証環境と湘南Lifeで行った検証で、すべてのWordPressサイトに当てはまるベンチマークではありません。ただ、記事更新とコード配信が別経路であること、画像や埋め込みを保持できること、移行には未確認の運用課題が残ることは、実際の作業で見えました。

まとめ

WordPressが一律にオワコンになったわけではありません。既存のテーマ、プラグイン、PHPホスティング、運用会社との関係を活かすなら、WordPressは今も強い選択肢です。EmDashは、その代替というより、Astroで作るサイトに管理画面とAI/APIの入口を組み込む選択肢です。

判断の中心は、図にした4つの条件です。サイトの基盤がAstroか。編集者に管理画面が必要か。データベース、ストレージ、deployを運用できるか。WordPressのテーマやプラグインにどこまで依存しているか。これに、AI/APIで何を自動化したいかを加えて考えます。条件が決まれば、EmDashが向くか、WordPressを続けるか、別のCMSを見るかが整理できます。

記事更新とコード配信も分けて考えます。記事はデータベース、テンプレートやCSSはbuild/deploy。この境界を理解していれば、移行後に「記事を直したのに反映されない」「CSSを変えたのにdeployしていない」という混乱を減らせます。

費用は、ソフトの無料と運用の無料を分けます。無料枠で始められても、アクセス、画像変換、バックアップ、監視、人の時間はかかります。小さなサイトで試し、実際の数字を見てから広げる方が安全です。

CMSを替える目的は、流行に乗ることではありません。記事を出す速さと、サイトを安全に保つことを両立させることです。WordPressを残す判断も、EmDashへ移す判断も、その目的に合うかで決めます。