EmDashは0.x.xの頃から使っているので、自分で言うのも何だがアーリーアダプターだと思う。
移行自体はVibe Codingで進めていたため、技術的なことは特に書くことがない。移行に関するプラクティスは公式ドキュメントを頼りにするのが一番良いと思うので、技術的なノウハウを求めている読者にとっては、期待に沿えない内容かもしれない。申し訳ない。
今回は個人ブログの変遷や思い出、リプレイスのモチベーション、使ってみた感想などを書いていきたい。
この個人ブログの変遷
一瞬だけ「Notionを外部公開するSaaS」を使った瞬間もあったが、本当に数ヶ月間だけだったので、基本的には2016年あたりから約10年間WordPressを使ってきた。
AS-IS (2016年〜2026年5月)
- CMS: WordPress
- ホスティング: シンレンタルサーバー（2023年ごろから）
TO-BE (2026年6月〜)
- CMS: EmDash
- デプロイ: Cloudflare Workers
- データベース: D1
- バケット: R2
CMSの思い出
僕が初めてドメインを取得してウェブメディアを作ったのが2010年で、その頃から「独自ドメインでウェブメディアを立ち上げるならばWordPress」といった状況だった。
当時はWordPressのバージョンが2.x.xから3.0.0になったくらいの頃だ。こうして文字にしてみると、僕も立派なインターネット老人だなと思う。（Movable Typeの存在も知ってはいたが、個人向けではない印象が当時からあった）
この頃からすでに「仕事でメディアを制作する際には当然WordPressを使う」という潮流があったように感じる。そのためyusukesatoh.comも慣習通りWordPressで作った。
Headless CMSの波に乗れなかった
「WordPressは表示速度が遅い」「セキュリティに問題が多い」という言説は昔から常に存在していて、それらが「WordPressをやめよう」という論拠になっている点は今と同じ。
2018年ごろ、その代替案として提示されていたソリューションは「Headless CMSへの移行」だった。StrapiやContentfulが注目されていた頃だ。懐かしい。
僕のGitHubリポジトリを確認したところ、2018年ごろにStrapiを使った個人ブログへの移行を試みた形跡があった。
当時、移行を完遂できなかった理由は「フロントエンドを作れないこと」と「データベースを設計・運用する能力がなかったこと」の2つだ。まさにヘッドレスな構成によって「切り離された部分」が僕にとってボトルネックだった。
また、当時の僕自身のマインドとして、フロントエンドとバックエンドがナチュラルに密結合しているWordPressで育ってきたこともあって「Headless CMSにどんなメリットがあるのか」や「フロントエンドとバックエンドを分ける」といった点が、いまいちピンときていなかったのだと思う。
こうして、パフォーマンスやセキュリティに問題があることは認識しつつも、WordPressを使い続けることが当時の僕にとっての現実解だった。 当時バズっていたHeadless CMSの波に乗れず、悔しい思いをしたのを覚えている。
WordPress時代のセキュリティ施策について
WordPressのセキュリティ施策として挙げられるのは、「本体のバージョンを常に最新にしておくこと」「プラグインを無闇に入れないこと」あたりが一般的だと思う。
僕の場合はそれに加えて、ログイン周りの対策として「WP Cerber Security」というプラグインを入れていた（気休めかもしれないが……）。
このプラグインを使うと、管理画面へのログインURLを既定の /wp-admin から任意のパスに変更でき、不正なログインを試みていると思われるIPを一定時間ロックダウンする、といった対策がとれた。
また、後述するリプレイスのモチベーションにもつながるのだが、検知した不正アクセスやロックダウンの状況をダッシュボードで視覚的に確認できる点も分かりやすくて便利だった。
リプレイスのモチベーション
端的にまとめると、以下の3つが重なったことでWordPressをやめられた。
- AIの進歩によって「フロントエンドを作れない」「データベースの設計・運用ができない」という壁を克服できた
- WordPressからのリプレイス先として、具体的かつ現実的な選択肢になり得る「EmDash」が登場した
- 1日あたりの不正ログイン試行数が急増した
GPT-3が登場した2023年ごろ、自分自身でコードを書ける状態を目指してNext.jsを勉強していた。
結果的に、AIのコーディング能力と周辺環境の進化スピードが自分の学習速度を上回ってくれたため、自分でコードを書く機会はほぼなくなった。ただ、副産物として「そのコードが何を意図しているのか」「認証認可とは？」といった基礎的な知識は、PM業務において必要な水準以上を身につけられたと思う。
これによって、かつてHeadless CMSの波に乗れなかった理由である2つのボトルネックが解消された。
同時に、このあたりから（現代の目線で見たときの）WordPressの設計の異質さが気になるようにもなった。
例えば「『記事の下にSNSボタンを設置する君』みたいなプラグインですら、その気になればデータベースを直接操作できちゃうってこと……？！」みたいな話。
そんな中で、WordPressの精神的後継を掲げる「EmDash」の登場は渡りに船だった。
どの部分が何を担当しているのかが分かりやすく、CMSの管理画面も十分実用的な仕上がりだったため、運用のイメージができた。4月の発表当初から「そのうちEmDashにリプレイスしよう」と思っていた記憶がある。
その「そのうち」が6月に前倒しされた背景が、3つ目の「不正アクセスの急増」だ。
WP Cerber Securityのレポートを見ていると、2026年に入ったあたりから攻撃の数が急激に増え始め、5月時点では脆弱性スキャンや不正なログイン試行が1日に3桁を超えることが常態化していた。
このまま攻撃に晒され続けていたら、遠からず自分の手には負えない状況になる、と直感した。結果的にはこれがEmDashへ移行する決め手となった。
リプレイス作業について
移行に着手したのは2026年6月ごろ。作業自体はClaude Opus 4.5と対話しながら進めていた。
「新しい概念をAIで扱うときのあるある」だが、EmDashという概念自体をLLMが十分に学習していないため、無計画に「WordPressからEmDashにリプレイスして！」と投げるだけでは期待した結果にはならない。
ただ、Cloudflareのプロダクトは公式ドキュメントが非常に充実しているので、ドキュメントのコンテキストをLLMに渡すと作業はスムーズに進んだ。
横道にそれるが、Next.jsに use client を書く文化が生まれ始めたころの話。当時はLLMがその情報を学習していない + ドキュメントも正しく理解してくれない状況で延々とエラーが解決できなかった。
それがトラウマとなり、勉強していたにもかかわらず僕はNext.jsがちょっと嫌いだったりする。自己中な理由で申し訳ない。
結果として、移行作業自体は1日もかからずに完了した。
EmDashの使い心地とこれから
受託でウェブメディアの開発を依頼されることもあるのだが、現在はこちらからWordPressを提案することはない。
昨今の各社の情報漏洩の事例を見ていると、運用保守を含めて安全性を担保する自信がないため、WordPressの利用が条件になっている案件はお断りしている。
僕がリプレイスした6月時点でのEmDashはバージョン0.x系だったが、2026年9月に無事1.0.0に到達した。個人的には、これで受託案件でもEmDashを提案しやすくなったと感じているし、早速EmDashで構築したメディアを1件リリース予定だ。
使い心地という点では、2026年10月時点で75点くらい。
主な課題はCMSのローカライズ周りで、多言語対応の置換対象から漏れている箇所がちらほらある、といった類のものだ。
ただ、個人ブログの運用という点では十分な完成度だし、ビジネスでの本番利用についても、運用担当者の理解さえ得られれば（といってもWordPressにかなり近いUIなので受け入れられやすいはず）、十分に実用に耐えうると思っている。
昨今はAIの普及で開発コストが下がったこともあり“オレオレCMS”を作る事例も見聞きする。
もちろんEmDashを使っていれば絶対に安全というわけではないが、Cloudflareが開発を主導している間はセキュリティ的な恩恵を受けられるし、何より車輪の再発明を避けられる。
もしウェブメディアの新規開発やリプレイスを検討しているなら、EmDashを有力な選択肢として検討してみてほしい。