Q.GutenbergのブロックはEmDashに取り込む時どう変換されますか？Studioからの移行にも使えますか？

WordPressで書き溜めた記事を新しい環境へ移す際、ブロックの見た目や配置が意図通りに保たれるかは気になるところですね。EmDashにはWordPressからの移行を支援する仕組みとしてgutenberg-to-portable-textという変換器が備わっています。この仕組みにより、Gutenberg特有のHTMLコメントを含むブロックデータは、Portable Textと呼ばれるJSON形式のデータへと変換されます。つまり、元のブロックのマークアップがそのまま残るわけではありません。

特に注意したいのが、動的に画面を生成するブロックの扱いです。WordPressの動的ブロックは、保存時に属性を持つコメントだけを残す仕組みです（ブロックのマークアップ表現）。EmDashでは、そのコメントを含んだHTMLブロックとして取り込まれます。そのため、画面上には何も表示されない空のブロックが残る形になり、EmDash側でコンポーネントを新しく作り直すか、不要なブロックとして削除する判断が必要です。

ただし、すべての要素が何もしなくても完全に再現されるわけではありません。複雑なレイアウトブロックや外部コンテンツの埋め込み、ショートコード、ページビルダーで作成した装飾、プラグイン独自のカスタムブロックなどは、変換後に表示の崩れや欠落が起きやすい部分です。移行作業を終えた後は、EmDashのWordPress移行資料の手順に沿って、実際の表示状態を目視で確かめる作業が欠かせません。

なお、EmDashの管理画面では、WordPressから書き出したWXRファイル、または専用のEmDash Exporterプラグインを利用してデータの取り込みを進めます。Exporterを入れずにサイトのURLだけを入力した場合は、公開REST APIの検出と件数の確認までしかできず、REST経由で直接取り込むことはできません。

Studioで運用してきたWebサイトを別の基盤へ移そうと考えたとき、gutenberg-to-portable-textをそのまま活用できるでしょうか。Studioのサイトを、この変換部品にそのまま渡すことはできません。Studioには、デザイン、ページ情報、ソースコード、Studio CMSのデータを書き出す機能がないためです（Studioで書き出せないデータ）。例外はフォーム回答のCSV出力くらいで、記事データをファイルとして取り出す手段がありません。

変換部品そのものはGutenbergのマークアップを読むためのものです。同じ変換器でClassic HTMLも処理されるので、理屈の上ではHTMLさえ用意できれば通せる余地はあります。ただ、Studioのページを集めて流し込むための公式な手順はありません。

もし自分でページを集めるなら、手がかりは/sitemap.xmlで提供されるサイトマップです。Studioが自動生成するサイトマップファイルには、モーダル画面や検索避けのnoindexを設定したページが含まれない仕様になっています。サイトマップだけで全ページを拾えるとは限らないので、載らないページは別に書き出しておく必要がありますよ。

EmDashには、コンテンツとスキーマをプログラムから扱えるCLIがあります。Studioのページを取り出し、整えて、CLIで登録するという流れは組めそうに見えますね。ただし、その一連の作業がうまく動くかは検証されていません。

ちなみに、EmDashのWordPress移行ガイドには、切り替え前に旧サイトの公開URLを巡回して、変わった経路ごとにリダイレクトを用意する手順があります。WordPress向けの手順ですが、URLが変わる点はStudioから移る場合も同じです。

SWELLやCocoonをEmDashで動かすことはできません。EmDashはPHPを実行せず、WordPressのテーマもプラグインも動かさないためです。そのため、WordPressから記事データや画像を引き継げたとしても、SWELL独自の吹き出しやボックスデザイン、Cocoonのレイアウト設定などが自動的に再現されることはありません。サイトの見た目や使い勝手は、Astroと呼ばれるWebフレームワークを用いて新しく作り込む必要がありますね。

EmDashにおけるテーマは、Astroのひな形プロジェクトとして提供される仕組みです。ページ、レイアウト、部品、スタイルが一式そろっていて、導入した後は生成されたファイルを直接編集して見た目を変えます（EmDashのテーマ概要）。管理画面のカスタマイザーで色や配置を選ぶWordPressのテーマとは、触り方がかなり違います。

ブログ用途としては、カテゴリーやタグの分類、サイドバーの各種表示枠、検索機能、RSS配信などを備えた公式テンプレートが配布されており、Cloudflare環境向けにはパッケージも公開されています。Cloudflareで動かす場合は@emdash-cms/template-blog-cloudflareを使いましょう。記事一覧と個別記事が並ぶ一般的なブログなら、この公式テンプレートを土台にできます。

また、既存のWordPress資産を活かしたい開発者向けに、テーマやプラグインの移植作業を支援するAgent Skillsという仕組みも用意されています。とはいえ、あくまで移植の補助です。既存のテーマが手を加えずに動くわけではなく、すべてを自動で移せるわけでもありません。

同じ使い勝手のテーマがある前提では進めず、必要な装飾は自分で作るつもりで見積もるのが現実的です。

Gutenbergのカスタムブロックを作るには、どのような手順を踏むのでしょうか。WordPress側では、@wordpress/create-blockで雛形を生成するところから始めます。動的ブロックなら「npx @wordpress/create-block@latest copyright-date-block --variant=dynamic」のように実行し、できあがったblock.jsonやedit.jsを編集していく流れです（公式のブロック作成チュートリアル）。準備するのはコードエディタ、Node.js、ローカルのWordPress環境の3つです。

公開側の表示を制御する方法は、ブロックの種類によって分かれます。チュートリアルの動的ブロックではrender.phpが公開画面の出力を担い、静的なHTMLを保存したいときはsave.jsを追加します。編集画面はReact、表示はPHPという分担になることもありますね。

EmDashへ移るなら、作ったブロックは向こうでもう一度作り直します。EmDashでは、Portable Textに対応したカスタムブロックをプラグインという形で追加する仕組みを採用しています。公開サイトで表示するにはネイティブプラグインか、付随パッケージのAstroコンポーネントが必要です。しかも、Plugin CLIやレジストリのパッケージではブロック型を定義できません。サイト側には、ビルド時に読み込まれるAstroのcomponentsEntryも用意します。ブロック型を宣言しただけでは、公開画面に表示されません。

もうひとつ、Studioの「カスタムコード」と混同しないようにしてください。これは有料プランで、サイトや個別ページのheadとbodyに独自のコードを足す機能です。GutenbergやEmDashのようにエディタ内で自由に使えるブロックを新設するアプローチとは目的が異なります。

Mullenweg氏は、EmDashへの意見を書いたブログ記事を公開しています。この意見は、Cloudflareが2026年4月1日にEmDashをWordPressの「精神的後継」として発表したことを受けたものです。この呼び方は、WordPress側が後継として認めたという意味ではありません。

一つめの批判は、EmDashがCloudflareのサービスをもっと売るために作られたのではないか、という見方です。ほかのベンダーへ乗り換えにくくなる点も問題にしています。ただ、これはあくまで本人の評価です。

二つめはプラグインの安全性です。WordPressはプラグインがシステム全体を自由に変更できる柔軟性を強みとしてきたのに対し、EmDashは安全性を高めるためにプラグインを隔離環境で動かす方式を採用しています。Mullenweg氏はこの隔離方式をオープンウェブの自由さを損なうものと捉え、当時の仕様ではプラグインの安全性がCloudflareのインフラ上でしか機能しないと主張しました。現在は、Cloudflare以外のNode.jsサーバーでも動かせます。データベースもSQLiteだけでなくlibSQLやPostgreSQLへの接続に対応しており、隔離プラグインを動かすworkerdランナーも提供されています。動かせることと、どの環境でも同じ機能や運用になることは別なので、そこは分けて読んだほうがよいでしょう。

三つめは編集画面です。Mullenweg氏はEmDashの編集UIを批判して、Gutenbergを採用してはどうかと提案しました。最初はTinyMCEを使っていると書いていましたが、実際はPortable Textだったとして後から訂正しています。

もうひとつ紛らわしい点として、D1 SQLiteでは複雑なリレーショナル設計に向かないと指摘したのはJames F. Gibbons氏です。Mullenweg氏の発言ではありません。