Q.Studioからの移管先として名前が挙がるEmDashとは何ですか？

オープンソースとして公開されているEmDashですが、実際の運用にはどれくらいの費用がかかるのか気になりますよね。本体は無料です。EmDashはMITライセンスのオープンソースCMSで、使うこと自体にライセンス料はかかりません。ただしサイトを公開するにはサーバーやデータベースが要るので、そちらの料金は別に見ておく必要があります。

たとえば公開先にCloudflare Workersを選ぶ場合、標準で利用できる無料プランの範囲内であればサーバー代はかかりません。上限を超えて使うなら有料プランに切り替えます。有料プランはアカウントごとの月額料金で、基本の枠を超えた分には追加料金がかかります。金額はWorkersの料金表で確かめられます。Node.js環境を使って自前のサーバーやクラウドサービスで動かす場合も、契約するサーバー代やデータベースの月額費用が実費として発生します。

試すだけならお金はかかりません。公式サイトのPlaygroundを開けばすぐに管理画面を触れますし、npm create emdashで手元のパソコンに新しいプロジェクトを作ることもできます。とはいえPlaygroundは試用のための場所で、実際のサイトを公開する環境とは別物です。

Studioの有料プランから移るなら、月々の費用だけを比べたくなりますね。ただ実際には、Astroでデザインを作り直す制作費と、データベースや画像の保存先を見る人の手間も加わります。

手軽なのは公式のテンプレートです。EmDashの公式GitHubや関連ドキュメントの中には、「Blog」「Marketing」「Portfolio」といったテンプレートが用意されています。これらはブログ形式のサイト、製品やサービスの案内ページ、制作実績などを紹介するポートフォリオを立ち上げる際の出発点として作られた構成です。現行の文書にはStarterやBlankもあるので、選べるのは3種類だけではありません。

たとえばブログ向けのテンプレートを使いたいときは、ターミナルで「npm create astro@latest -- --template @emdash-cms/template-blog」と入力してプロジェクトを展開します。公開先としてCloudflare Workersを想定している場合は、パッケージ名の末尾に「-cloudflare」が付いたテンプレートを選択して作業を進めます。

WordPressから来た人がつまずきやすいのが、テーマの扱いです。EmDashには、実行時に読み込むテーマパッケージもテンプレート階層もありません。管理画面でテーマを入れ替える方式ではなく、ひな型から作ったファイルをサイト側で直接書き換えていきます。

そのため、EmDashにおけるテーマ作りは、Astroプロジェクトそのものを自作する作業。ページ、全体のレイアウト、表示部品、スタイルシートを自分たちの手で組み合わせ、サイトの見た目を作り上げていきます。

Studioで作ったデザインを再現したいときは、テンプレートを土台にしてAstroのコードを書き直す作業になります。

サイトを運営するうえで欠かせない問い合わせ受付ですが、EmDash単体でフォームを作れるのか疑問に思うこともありますよね。作れます。公式のフォームプラグイン「@emdash-cms/plugin-forms」があり、フォームの作成、送信内容の受け取り、通知の送信に対応しています。問い合わせフォームのような基本的な用途なら、これで足りますね。

プラグインを組み込む際には、パッケージ同士のバージョンの噛み合わせに注意を払う必要があります。公式のフォームプラグインをはじめとする拡張パッケージにはそれぞれ独立したバージョン番号が付いており、動作に必要なEmDash本体の最低バージョンが指定されています。本体の更新状況とプラグインの要求条件を見比べながら導入を進める形。

また、公式以外のフォームプラグインもあります。第三者製の「@netdollar.dev/forms」は、サイトにフォームを出すために別のパッケージを追加し、ビルドとデプロイをやり直す必要があります。同じく第三者製のEmdashHQ contact formsは、管理画面でフォームを作り、ブロックとしてページに置く方式です。どちらも公式とは別の製品なので、手順を取り違えないようにしてください。

日本語を既定にして英語版を足す、といった多言語サイトも作れます。設定方法は多言語化のガイドにあります。

翻訳は、それぞれが独立した記事として扱われます。URL用の名前、公開状態、改訂履歴を言語ごとに持つので、日本語版は公開済みで英語版はまだ下書き、という進め方ができますね。

ただし、URLの付け方には決まりがあります。既定の言語に言語接頭辞を付けない構成にしてください。prefixDefaultLocaleをtrueにしたりprefix-alwaysにしたりすると、管理画面が404になります。日本語が既定なら、日本語ページには接頭辞を付けず、英語ページだけに/en/を付ける形です。

検索エンジン向けには、コレクションごとのサイトマップが翻訳記事どうしのhreflangを出力します。対象はURLを持ち、SEOが有効なコレクションの公開記事です。削除済み、slugなし、noindexの記事は外れます。0.20.0では翻訳版がない記事にhreflangが出ない不具合が報告され、このIssueはすでに閉じられています。

記事が増えてきたときに読者を助けるサイト内検索ですが、日本語の文章でも問題なく検索がヒットするのでしょうか。日本語での検索精度について、公式の保証はありません。EmDashの全文検索はSQLiteのFTS5を使っていて、機能としてPorter stemmingを掲げています。ところが、SQLiteのFTS5の説明のとおり、Porterによる語幹の処理は英語の単語向けです。英語で「running」と検索して「run」も見つかるような工夫が、日本語ではそのまま効くわけではないということです。

だからといって、日本語では検索できないと決めつける根拠もありません。ここは実際の記事で試して確かめるのがいちばん早いでしょう。

そこで、EmDashにはコマンドラインから直接検索のテストができるCLIツールが用意されており、対象のコレクションや言語、取得件数を指定して検索の挙動を確かめられます。たとえば npx emdash search "hello" --collection posts --limit 5 のように使います。公開前に、移行した日本語の記事で、タイトルの一部や本文によく出る言葉を入れてみてください。送り仮名やカタカナの書き方を変えた語で引っかかるかも見ておきたいところです。

Studioから記事を移したあと、サイト内検索を読者がよく使うサイトなら、ここで結果を見てから公開に進むほうが安全ですね。

新しいCMSなので、実際に使った人の声がいちばん気になりますね。ただし時期によって言われていることがかなり違います。

公開直後の2026年4月、Redditでは、プラグインを隔離して権限を絞る設計が注目され、プラグインAPIをほめる意見がありました。また、実際に管理画面を触った開発者からは、ページの切り替えが非常に軽快で扱いやすい点や、標準で柔軟なデータ項目を定義できる点を歓迎する声も上がっています。一方で、第三者製のプラグインもテーマもまだ一つもないことが、採用のリスクとして挙げられていました。

WordPressの共同創業者であるMullenweg氏は、自身のブログで、EmDashはCloudflareのサービスを売るために作られたという見方を示しました。ほかの会社へ移りにくくなるという批判です。それでも、技術の確かさや移行ツール、速さ、Astroとの連携は評価しています。

もっとも、EmDashはCloudflare以外のNode.js環境でも動き、プラグインの隔離もNode.js上のworkerdで使えます。1.0ではプラグインを探して入れられるレジストリも始まりました。

2026年8月には、WordPressから移した人がRedditに、画面と機能がまだ未熟だと書いています。移行用ドキュメントにも複数の問題があったそうで、移したのは収益を生まないサイトでした。Cloudflare自身も自社ブログを移行した際の振り返りの中で、編集操作に関する課題を率直に明かしていました。結局、登場して間もない成長過程のソフトウェアであることを念頭に置いて付き合っていくのがよさそうですね。