EmDashへの移行更新日
#EmDashの管理画面にログインできない時は何を確認しますか？
Studioから移管したあとにEmDashの管理画面が開かず、ログイン画面の前で立ち往生していませんか。最初に確かめたいのは、開いているアドレスです。EmDashの管理画面は、サイトのドメインのあとに /_emdash/admin を付けた場所にあります。開発中は localhost:4321 のような手元のアドレスで開きますが、本番では自分のドメインに付けて開きます。
アドレスが合っているのに入れない場合は、パスキーを疑いましょう。EmDashは標準でパスキー認証を採用しており、OAuthやマジックリンクによる予備のログイン手段も選べます。パスキーはサイトのドメインに結び付いているため、開発中に localhost で作ったパスキーは example.com のような本番ドメインでは通りません。新しいドメインで登録し直す必要があります。
ただ、パスキーは登録した端末でしか使えないわけではありません。対応するパスワード管理ツールで同期したり、近くのスマートフォンで承認してパソコンからログインしたりもできます。
予備手段のマジックリンクを使う場合は、サイト側でメール送信機能が正常に動いていることが前提になります。送られてくるリンクは1回限り有効で、発行から15分が経過すると失効するため、時間が経った際は再発行を試してください。また、本番でCloudflare Accessを認証方式にしている場合、パスキー、外部のログインサービス、ログインリンク、招待、自己登録はどれも使えません。
パスキーをすべてなくした時は、メール設定があれば別の管理者に復旧リンクを送ってもらい、ログインしてから登録し直します。手順はEmDashの認証ガイドに載っています。
#「emdash is not initialized」と表示された時はどうしますか？
Node.jsとSQLiteを組み合わせた移行環境では、この表示が出た際にプロセスのログを追跡したところ、kyselyの依存関係が見つからない例外が発生していた事例もありました。この文言は、リクエストを受けた時点でEmDashの実行環境が用意されていない時に、HTTP 500として返されるものです。画面のメッセージだけに引きずられず、journalctlやホスティング環境のログを直接開き、最初に出力された例外のスタックトレースを読み解くことが大切です。
Cloudflareで動かしている場合は、データベースのつなぎ方を見直します。EmDashの設定に書くD1の binding は、wrangler.jsonc に書いたD1バインディング名と同じでなければなりません。Workerはこの名前を手がかりにデータベースを参照するので、片方だけ書き換えていないか見比べます。
D1のテーブルを生成するコアマイグレーションは標準で自動実行されますが、D1データベースそのものはあらかじめ作成しておかなければなりません。設定名の一致とデータベースの存在を、デプロイ前に照合しておきましょう。
#EmDashのプラグインはどのように隔離されて動くのですか？
サイトに入れたプラグインが、記事や会員情報を勝手に読みにいかないかは気になるところですね。EmDashでは、サンドボックス型のプラグインが、それぞれ切り離された実行環境で動きます。CloudflareではWorker Loaderを使ったDynamic Worker、Node.jsでは workerd という子プロセスの中の隔離されたサービスが、その役目を担います。
この隔離環境にあるプラグインは、自分専用のストレージ領域こそ持てるものの、サイト本体が抱えるコンテンツや画像などのメディア、ユーザー情報、環境変数、サーバー内のファイルには最初から一切アクセスできません。外部のネットワークと通信する権限すら、初期状態では閉じられています。必要な機能があるときはマニフェストファイルで要求する権限を宣言し、サイト管理者が画面上で承認して初めてアクセスできるようになる仕組みです。権限は機能ごとに分かれていて、メディアへのアクセスを許しても、ユーザー情報や未公開の記事まで見えるようにはなりません。権限が増えるアップデートの際にも、その都度再承認を求められます。
Cloudflareで動かす場合、Dynamic Workersを使うにはWorkers Paidプランが必要です。サンドボックスを動かせる環境がないと、sandboxed に指定したプラグインは起動時に読み飛ばされます。これを plugins の指定へ移せば同じプロセスで動きますが、隔離もリソースの制限もなくなります。プラグインが動かないからといって、この切り替えで済ませるのは避けたいところです。
#EmDashのプラグインレジストリとは何ですか？有料プラグインはありますか？
plugins.emdashcms.com を開くと、EmDashで使えるプラグインが一覧で並んでいます。これがプラグインレジストリで、サンドボックス型プラグインの公式カタログです。サイトに入れる時は、ブラウザで一覧を見るだけでなく、自分の管理画面にある Registry から探してインストールします。
2026年9月28日のレジストリの公式発表では、掲載されているプラグインはすべて無料で、有料プラグインへの対応は今後の予定とされていました。発表の言い方は「今のところ無料」で、有料のプラグインが加わることも予定されているため、無料のものだけとは限りません。入れる前に、プラグインのページで料金の案内を確かめておきましょう。
インストール時には、公開者の署名記録とパッケージのハッシュ値、名前、バージョン、要求されている権限が照合される仕組みです。公開者がビルドの来歴の確認を求めている場合はそれも確かめ、どこかで合わなければインストールを止めます。レジストリはAT Protocolという分散型の通信方式の上に作られていて、署名済みのパッケージやリリースの記録は、公開者自身のアカウントに保存されます。
WordPressのプラグインを持ち込みたい場合は、保存データの扱い、画面表示、通信ルートなどの役割ごとに処理を分け、EmDashの仕様に沿って移植します。
#中小企業のコーポレートサイトにEmDashは向いていますか？
中小企業が会社案内や採用情報を掲載する基盤として、EmDashは本当に適しているのでしょうか。会社の規模よりも、サイトを作って保守できる人がいるかで決まります。EmDashはAstro向けのCMSで、開発者がAstroでサイトを組み、編集担当者が管理画面から記事や情報を更新する使い方を前提にしています。制作会社が作って、お客さまの担当者に更新を任せるサイトも、公式の利用例に入っていますね。
Studioから移る人がつまずきやすいのは、画面上でデザインを組む機能がない点です。Studioのようなノーコードツールでは、画面の見た目を直感的に並べ替えるビジュアルエディタが中心でした。一方のEmDashは記事やお知らせのテキストを管理するCMSであり、ページ全体の見た目やHTMLの組み立てはAstroのコード側で制御します。Studioのようにレイアウトをドラッグで直したい人には、操作の感覚がかなり違って感じられるでしょう。
サーバー環境に関しても、Cloudflareだけでなく一般的なNode.jsサーバーとSQLiteの組み合わせで動かせるため、特定のクラウドサービスに縛られることもありません。EmDashは、まだ出てから日が浅いCMSです。社内の担当者は記事を更新するだけで、サーバーや依存パッケージの面倒は制作会社か社内の開発者が見る、という分担ができるなら候補に入りますね。迷う場合は、ローカル環境で最初のサイトを作るチュートリアルか、既存のAstroプロジェクトに追加するガイドで試作し、更新担当者の操作感と保守の手間を確かめられます。
こんな聞き方も
- emdash admin
- emdash is not initialized
- EmDashの管理画面にログインできない時はどうすればいいですか？
- emdash admin login できない
- EmDashのプラグインはどのように隔離されて動くのですか？
- emdash プラグイン 隔離 サンドボックス
- EmDashのプラグインレジストリとは何ですか？
- EmDashに有料プラグインはありますか？
- EmDashのプラグインが求める権限（マニフェスト）はどう確認して承認しますか？
- EmDashのライセンスはMITですか？商用サイトで使えますか？
- EmDashへ移行する時、独自ドメインはどう切り替えますか？
- 中小企業のコーポレートサイトにEmDashは向いていますか？
- EmDashのプラグインやテーマはまだ少ないのですか？
- キャンペーンで急にアクセスが増えてもEmDashは大丈夫ですか？
あわせて知りたい（関連する疑問）
QEmDashのライセンスはMITですか、それともGPLですか？
EmDash本体はMITライセンスで、GPLではありません。EmDashのライセンス文には、ソフトウェアを使う、複製する、改変する、配布する、販売することへの許可が書かれています。条件を守れば、会社のサイトや制作案件のような商用の場面でも使えます。
利用にあたって守るべき条件は明快で、ソフトウェアの複製や重要な部分に対して、原作者の著作権表示と許諾表示をそのまま残しておくことだけです。EmDashを改変して配布するような場合は、ここを外さないようにしてください。
ちなみに、EmDashがMITライセンスを選んでいる背景には、開発時にWordPressのソースコードを流用せずゼロから書き上げられた経緯があります。
ところで、MITとGPLの違いを「商用で使えるか使えないか」と受け取る人もいますが、これは違います。WordPressのGPLv2以降でも、利用目的を問わず自由に実行する権利が保障されており、商用サイトでの利用自体はまったく問題ないのです。2つの違いは、改変したものを配る時の条件にあると考えたほうが近いでしょう。
QEmDashへ移行する時、独自ドメインはどう切り替えますか？
Studioで公開していたサイトのアドレスをそのまま引き継いでEmDashで運用するには、どのような手順で切り替えればよいのでしょうか。Cloudflare Workers上にEmDashを構築しているなら、同一のCloudflareアカウント内に管理対象のドメインを用意し、Workerのカスタムドメイン機能を使って結び付けます。ただし、すでにCNAMEレコードがあるホスト名や、自分のものではないゾーンには、カスタムドメインを作れません（Workersのカスタムドメイン）。
切り替えは、いきなり本番ドメインで始めないほうが安全です。EmDashの手順では、まず workers.dev のアドレスで正しく表示されるかを確かめ、そのあと本番ドメインを追加して再デプロイし、両方のアドレスで表示を確かめます。workers.dev で動いていれば、問題がドメイン側にあるのかアプリ側にあるのかを分けて考えられますね。
さらに、ドメイン名を変更せずにサーバーを引っ越す場合は、DNS情報のキャッシュがネットワークに残る時間を短くするため、移転作業の少なくとも1週間前にはTTLの数値を数時間程度まで下げておきます。
注意したいのが、ログインへの影響です。初期設定のあとで EMDASH_SITE_URL を別のドメインに変えると、ログインする場所もそのドメインに移り、前のアドレスで作ったパスキーはそこでは使えません。切り替え後は新しいアドレス上で認証情報を登録し直してください。
あわせて、Studio側で独自ドメインの接続を外す時は、公開パネルを開き、ドメインの左にある［×］をクリックします。
QEmDashでAI翻訳を使って多言語化するプラグインはありますか？
日本語の会社サイトに英語のページを足したい時に使えるのが、LinguaDashプラグインです。DeepL、OpenAI、Cloudflare AIのどれかを使って、記事の本文とSEO用の項目を翻訳できます。公式カタログに載っているプラグインで、EmDashの開発元が作ったものとは別です。
実務で助かるのは、機械翻訳を実行したテキストがそのままWeb上に公開されるのではなく、いったん下書き状態で生成される点です。専門用語の訳し分けや言い回しの不自然さを担当者が目視で確認し、手直しを入れてから公開状態に切り替える運用ができますね。
導入にはいくつか条件があります。
- EmDash 0.42以降であること
- プラグインのサンドボックスを動かせる環境があること
- 機械翻訳を使うなら EMDASH_ENCRYPTION_KEY を設定していること
- 翻訳したい項目ごとに Translatable を有効にしていること
なお、CloudflareのGitHub上にはPolyStellaという多言語化パッケージも存在しますが、こちらは開発途中の段階であり、新規の制作プロジェクトにはまだ採用しないよう呼びかけられています。今から多言語化を始めるなら、LinguaDashの条件を満たせるかを先に見るのが現実的でしょう。
QEmDashではURL構造を自由にカスタマイズできますか？
Studioや過去のWebサイトから移行するにあたり、これまでの検索評価を落とさないよう、記事や固定ページのURLの並び順を細かく調整したい場面はありませんか。公開ページのURLは、かなり自由に決められます。EmDashはAstroを土台にしたCMSで、ホームページや記事、アーカイブといったページの表示は、テーマ内のAstroのルートが受け持っています。
一方で、EmDashのコレクションに設定するURLパターンには決まりがあります。指定するプレースホルダーはそれぞれ独立したパスのスラッシュで区切らなければなりません。/{year}/{month}/{slug}.html は使えますが、/{year}{month}/{slug} や /{slug}-{id} のように2つをくっつけた形は受け付けられません（コレクションの説明）。
Studioで使っていたURLをそのまま残したい時は、ここが気になる所です。旧サイトのURLに年と月が続けて入っていたり、記事名とIDがハイフンでつながっていたりすると、コレクションのパターンでは同じ形を作れません。移行する前に旧URLの一覧を出し、EmDashのパターンで再現できるか、Astroのルートで作るかを決めてから作業に入ります。
QEmDashでサイトマップや構造化データを出力できますか？
どちらも出力できます。Astro公式の拡張機能である@astrojs/sitemapを使う手もありますが、あちらは静的に生成されたルートだけを拾うため、サーバー側で動的に描画するSSR環境では記事のURLをうまく拾えません。これに対して、EmDashは自前のサイトマップを持っていて、/sitemap.xml の目次と、コレクションごとのサイトマップを配信します。
対象になるのは、管理画面の Content Types でSEOを有効にしたコレクションです。ただし、設定をオンにすればすべての記事が載るわけではありません。コレクションのRoutable設定が無効になっているものは除外されますし、個別の記事についても、公開済みであること、削除されていないこと、slugが入力されていること、そして検索非表示のチェックが入っていないこと、という条件を満たす必要があります（EmDashのSEO設定）。サイトマップに出てこない記事があったら、まずこの4つを見直しましょう。
検索エンジン向けのJSON-LDも出せます。EmDashHead が、ページの情報に応じて BlogPosting か WebSite を作ります。記事ページには正規URL（canonical）、それ以外のページにはサイト名の設定が必要です。
出力したあとは、Googleのリッチリザルトテストで読み取られ方を確かめられます。Google独自の判定を抜きにして schema.org の書き方だけを見たい時は、Schema Markup Validator が使えます。どちらも書き方の確認で、検索結果に表示されることまで約束するものではありません。
QEmDash Software Ltdと関係がありますか？
海外の法人情報を調べているときに、英国に登記されている「EMDASH SOFTWARE LTD」という会社名を見かけて、CMSの運営母体なのかと疑問を抱いたことはありませんか。オープンソースCMSとしてのEmDashは、CDN大手のCloudflareによって主導され、Astroをベースにして作られたプロジェクトです。ソースコードはGitHub上の「emdash-cms/emdash」というリポジトリで公開されており、世界中の開発者コミュニティからの貢献を受けながら開発が進められています。
一方で、英国の会社登録簿であるCompanies Houseには、会社番号05736001のEMDASH SOFTWARE LTDという会社が登録されています。ただ、会社の登録があるというだけでは、このCMSとつながりがあるかはわかりません。この記事で使った資料の中には、両者の関係を示すものはありませんでした。関係があるとも、ないとも言い切れないので、名前だけを手がかりに問い合わせ先を選ばないほうが安全です。
もし利用中に技術的な疑問が生じたり、バグの報告や機能改善の要望を伝えたい場合は、公式サイト上で案内されているDiscordコミュニティや、GitHubのリポジトリにあるissueを活用します。管理画面に入れない、エラーが消えないといった相談も、まずはこの2つが窓口です。ただし、ログインの復旧を専門に受け付ける窓口ではないので、パスキーをなくした時の手順は認証ガイドを見ながら自分で進めることになります。
この内容をChatGPTで相談
