WordPressからEmDashへの移行を試した結果、実用に耐えず見送ることにしました | UNIX Cafe

WordPressで運営しているブログの移行先として、EmDashを試していました。

自分のMacに環境を用意し、実際の記事を取り込み、見た目や商品リンクを調整。その後、Cloudflare上に公開するところまで進めました。

結論から書くと、今回のテストは失敗です。WordPressで運用しているブログを日常的に運営するには実用に耐えないと判断し、採用を見送ることにしました。

記事がまったく表示できなかったわけではありません。手動で作業を進め、記事と写真を表示し、商品リンクやGoogleマップも載せられるところまでは到達しました。

それでも、データの転送や書き出しが止まり、カテゴリーの変更にも調査が必要になる状態では、この先の更新を安心して任せられませんでした。

この記事は、2026年10月30日に検証を終了した時点の記録です。途中で作成した「移行を試している段階」の原稿から、その後どうなったのかをまとめます。

小さなブログで、実際の移行を試した

今回使ったのは、お出かけ記事を掲載している個人ブログです。

将来的には約400ページあるこのサイトでの採用も考えていましたが、まずは約20ページ規模のサイトで、実際に運営できるかを確かめることにしました。

記事には、本文と写真だけでなく、Googleマップ、商品リンク、広告、カテゴリーなどがあります。普段のブログで使っているものが、そのまま運用できるかが今回の確認対象でした。

検証ではEmDash 1.3.1を使い、公開先にはCloudflare Workersを選びました。記事や設定を保存するデータベースにはD1、画像の保存先にはR2を使う構成です。

プログラムの調整やエラーの確認は、Codexと相談しながら進めました。変更したコードはGitに記録し、作業の経過は引き継ぎ書にも残しています。

ローカルでは、ブログらしい形まで作れた

最初は、できることが増えていく手応えがありました。

2026年10月22日からのGit履歴には、記事のレイアウト、目次、重複する画像の表示などを調整した記録が残っています。10月27日には、記事一覧や見出しの色、ブログパーツ、商品リンク、広告コードの扱いにも手を入れました。

トップページと記事一覧のデザインをそろえ、写真と見出しを整えると、見慣れたブログに近づいていきます。記事データを取り込んだ直後の状態から、自分のサイトとして使える見た目に調整できた点はよかったと思います。

ただ、WordPressで使っていた機能は、一つずつ確認する必要がありました。

商品リンクは作り直しが必要だった

WordPressでは、Pochippを使って商品リンクを表示していました。その表示をEmDash側でも使えるように、商品情報を取り出し、HTMLの商品カードにする処理を作りました。

その後、管理画面から商品情報を編集できるように、専用の管理項目も追加しました。これらは今回独自に用意したもので、EmDashの標準機能としてそのまま使えたわけではありません。

ところが、公開側では、同じ商品カードでも表示されるページと表示されないページがあり、商品カードの仕組みでは安定して表示できませんでした。

そこで、表示できない部分を補うため、記事内にHTMLコードを直接記述できる「HTMLブロック」を使いました。商品カードの管理・表示機能とは別の方法で商品リンクを直接掲載し、2商品の表示を確認しました。

今回作成した商品カードでは、商品画像や説明、「Amazonで見る」というボタンを表示するところまではできました。ただし、この商品カードにPochippの機能をすべて移したわけではなく、価格の自動更新やクリック集計まで再現したものでもありません。

広告は、名前が移っていてもコードが空だった

広告データでは、「記事下」「記事内」「追尾サイドバー」という名前が取り込まれていても、表示に必要なコードが入っていないことが分かりました。

WordPressから書き出したXMLを調べると、広告コードは本文とは別の項目に保存されていました。そこからコードを復元し、管理画面で扱えるようにしました。

ここで確認できたのは、コードの復元と保存です。広告の移行と実際の配信が、すべて正常に完了したといえる状態にはなりませんでした。

データの件数や名前だけを見て、移行できたと判断できないことを実感しました。

Googleマップも、表示方法の調整が必要だった

おでかけの記事には、地図が欠かせません。

ところが、取り込んだGoogleマップが空白になる問題がありました。ローカルで確認すると、通常のHTMLブロックでは、埋め込み先を制限する処理によってGoogleマップの接続先が取り除かれていました。

専用のiframeブロックとして扱うように変更し、ローカルでは表示を確認できました。公開側でも手動で更新し、最終的にGoogleマップを表示できています。

対処方法は見つかりましたが、本文が取り込めたら地図もそのまま表示される、という移行にはなりませんでした。

公開環境への転送に、3日を費やした

大きくつまずいたのは、ローカルで作ったサイトを公開環境へ移す工程です。

転送が途中で止まり、やり直しや状態の確認を続けることになりました。データのアップロードに3日を費やしました。

記録には、管理画面を開く処理でのCPU上限超過や、1回の処理でAPIを呼び出す回数が多すぎるというエラーが残っています。転送処理の調整も試しましたが、安定して完了したことを確認できませんでした。

さらに困ったのは、未完了の取り込みが、通常の記事保存にも影響したことです。

新規記事を保存しようとすると、「サイトのインポートが進行中、または未完了のため書き込みできない」という意味のエラーが表示されました。

取り込みをキャンセルした後も、すぐに編集できる状態には戻りませんでした。中止済みの取り込みを放棄する操作が必要だと案内され、状態を確かめながら対応することになりました。

この時点では、記事を書き進めるために、取り込み処理がどの状態で止まっているのかを調べていました。

そこで全体の自動転送に頼るのをやめ、手動で記事を移す方針に切り替えました。

手動で記事を載せても、運用への不安が残った

手動作業を進めた結果、記事の投稿は一通り終わりました。

公開画面では記事一覧や写真、本文、見出し、目次を確認できました。商品リンクも置き換え、地図も更新しました。サイトのロゴは管理画面の設定から変更できています。

ここまでできたので、そのまま使い始められればよかったのですが、公開側のデータをローカルへ戻そうとしたときにも問題が出ました。

サイトのエクスポートが「メディアファイルの確認中」のまま進まず、やがてエラーになりました。再試行しても完了を確認できず、書き出したパッケージを保存するところには到達しませんでした。

公開側で手動更新した内容を、ローカルへ取り込む作業は未完了のままです。ローカルにはWordPressのXMLを再インポートしましたが、それは公開側の最新状態を取り戻したことにはなりません。

記事や画像を載せることに加えて、更新したデータを取り出し、必要なときに戻せることも、運営するうえでは確かめたい部分です。今回、その一連の流れを確認できませんでした。

最後はカテゴリーの変更で止まった

最後に確認したのは、「ハイキング」というカテゴリーのスラッグです。スラッグは、URLなどに使う名前の部分です。

管理画面でスラッグをhikingに変更して保存すると、次のエラーが表示されました。

Term ‘ハイキング’ not found in taxonomy ‘category’

カテゴリー一覧には存在するのに、保存すると「見つからない」といわれます。画面を読み込み直しても同じでした。

以前ローカルで修正した記憶があったため、Git履歴とバックアップを調べました。ローカルのDBバックアップでは、確かに「ハイキング」のスラッグはhikingになっていました。

しかし、公開側のD1を直接確認すると、別の状態でした。

カテゴリー名	公開側に保存されていたスラッグ	今回確認できた記事
ハイキング	%e3%83%8f…というURL用に変換された文字列	公開記事5件
hiking	hiking	該当する日本語記事なし

公開側には、別々のカテゴリーが2件存在していました。

エラーでは変換前の「ハイキング」を検索している一方、データベースには変換後の文字列が保存されています。さらに、変更したいhikingは別カテゴリーに使われていました。

文字列がどの処理で変換されるのかまでは特定していません。ただ、管理画面の保存操作だけでは変更できず、保存データを調べる必要がある状態でした。

そこで、既存のhikingを一時的な別名にし、記事5件が紐づく「ハイキング」のスラッグを変更する手順を用意しました。カテゴリーのIDと記事の関連付けは維持する方法です。

ところが、最初の変更で、今度はD1無料枠の1日あたりの書き込み上限を超えたというエラーが出ました。

続けて実行した変更も、重複を防ぐ条件により対象なしとなり、スラッグは変更できませんでした。上限がリセットされるまで待つか、有料プランに変更するよう案内されました。

カテゴリーの名前をURL向けに整えたい。それだけの作業で、データベースを調べ、SQLを実行し、最後は翌日まで待つことになりました。

ここで、今回の検証を終えることにしました。

無料枠の問題と、CMSの問題は分けて考える

今回の問題を、すべてEmDashだけの不具合としてまとめることはできません。

最後の書き込み制限は、Cloudflare D1の無料枠に関するものです。商品リンクや広告には、WordPress側のプラグインやデータの保存方法に合わせた移植作業がありました。自分で追加した処理もあります。

また、AIの作業環境から公開サイトやCloudflareへ接続できず、私が管理画面で確認して結果を渡す場面もありました。接続できなかった原因は特定できていませんが、確認作業にも手間がかかりました。

転送やエクスポートが止まった直接の原因も、すべて解明したわけではありません。有料プランに変えれば一連の問題が解決するかどうかも、今回の検証では確認できていません。

そのうえで、今回選んだ構成を自分のブログ運営に使えるか、という判断はできます。

私の場合は、使い続けるために必要な調査と修正の負担が大きすぎました。

今回は「実用に耐えない」と判断した

新しいCMSを使う以上、最初の環境構築やデザイン調整に手間がかかることは想定していました。WordPressで使っていた機能を作り直す必要があることも分かっていました。

それでも、記事を移す、保存する、データを書き出す、カテゴリーを変更する。こうした普段の運営につながる作業で、何度も原因調査が必要になる状態は、私の用途には合いませんでした。

AIを使えばコードを書き換える作業は進められます。ただし、修正案ができたことと、公開環境で安定して使えることは別です。試すたびに画面を確認し、結果を伝え、次の手順を判断する時間も必要です。

今回の小さなブログでこれだけの対応が必要になった以上、約400ページのサイトを移す判断はできません。

EmDashで記事を表示できたこと、管理項目を追加できたこと、地図や商品カードを整えられたことは、今回できたこととして残ります。しかし、日常の更新やデータの取り出しまで含めて任せられる状態には到達しませんでした。

以上のことから、今回の移行テストは失敗として終了し、今回のEmDashの採用は見送ることにしました。