はじめてのAI活用あいみー公開 2026.11.15

EmDashってなに？YouTubeで気になったので、WordPressの記事を入れて試してみた

YouTubeで、EmDashをおすすめする動画を続けて見かけるようになりました。

「WordPressの後継？」「セキュリティの心配が減るの？」

PHPやWordPressの脆弱性の話も気になっていたので、ブログを運営している私としては、ちょっと放っておけません。とはいえ、動画でよさそうに見えたからといって、いきなり本番ブログを引っ越すのは怖い。

そこで、まずChatGPTのチャットとCodexを使い、EmDashとは何か、WordPressと何が違うのか、どんなメリットがあるのかを調べました。そのうえで、Codexに作業手順を案内してもらいながら、自分のパソコンにEmDashを入れ、今あるブログの記事や画像を移してみました。

分からないところだけ質問したというより、調べるところから、準備、操作、エラーへの対処まで、AIと一緒に進めた検証です。この記事では、その流れと、試して分かったことをまとめます。

今回やったことを先に一覧で

ChatGPTとCodexで、EmDashの基本情報・WordPressとの違い・メリットを調べる
本番のWordPressを変えず、AIブログで移行を試す方針を決める
Codexの案内に沿って、Node.js・npm・VS Codeを準備する
EmDashをインストールし、パソコン内で起動する
認証でつまずいたらAIに相談し、管理画面へ進む
記事の作成・表示、編集画面や設定を確認する
WordPressのバックアップを用意し、記事・画像などの取り込みを試す
自分の更新方法や費用に合うか考え、最終的にCMSなしの静的サイトを選ぶ

結果からいうと、EmDashで記事や画像を表示するところまではできました。ただ、私が欲しかった「心配や管理の負担を減らせる運用」を考え直し、最終的には別の形を選びました。

EmDashは、記事を管理するためのCMS

EmDashは、AstroというWebサイト制作の仕組みを土台にした、オープンソースのCMSです。CMSは、記事や画像を保存したり、管理画面で編集・公開したりするための仕組み。WordPressもCMSの一つです。

Cloudflareは2026年4月1日にEmDashを発表しました。WordPressの考え方を引き継ぎながら、新しい技術で作り直したCMSという位置づけです。PHPで動くWordPressとは異なり、TypeScriptで作られています。AIから記事や設定を扱うための機能も用意されています。

つまり、「AIが記事を書いてくれるサービス」というより、人からもAIからもブログの設定や記事の更新ができる仕組みが魅力な製品と理解しました。

調べて私が魅力に感じたのは、主に次の3点です。

PHPを使わない構成にできること。 WordPressで使っていたPHPの実行環境から離れられます。ただし、EmDashやNode.jsなど、別のソフトの更新・管理は残ります。
プラグインの安全性を見直した設計であること。 対応するプラグインを隔離して動かす仕組みがあります。WordPressで気にしていたリスクを減らせる可能性に惹かれました。
AIから記事を扱うための仕組みがあること。 API、MCP、CLIを備え、認証と権限を設定すれば、CodexやClaude Codeなどの対応ツールから記事の作成・編集・公開を進められます。毎回管理画面へコピーする作業を減らせそうだと感じました。

ただし、「AIにつなげば、確認も設定もなしで全部完了」という意味ではありません。今回は管理画面や取り込みの検証が中心で、AIから記事作成・公開までの一連の運用を完成させたわけではありません。

参考：CloudflareによるEmDashの発表

参考：EmDash公式のAI連携ガイド

PHPの脆弱性があるから、WordPressはもう危険？

私がEmDashに惹かれた理由の一つが、セキュリティでした。ブログを書きたいだけなのに、PHPのバージョン、テーマやプラグインの更新、不正アクセスへの備え……気にすることがいろいろあります。

ただ、ここは「PHPだから危険」「別の言語なら安全」と一括りにはできません。

PHP自体の問題と、WordPress本体・テーマ・プラグインの問題は別です。PHPにはサポート期間があり、サポートが終わったバージョンにはセキュリティ修正が提供されなくなります。WordPress側にも、本体や周辺ソフトを更新して使うという管理が必要です。

私が見た動画の印象と、EmDashが生まれた背景も分けておきたいところ。公式の発表で大きく取り上げられていたのは、特定のPHPの脆弱性への緊急対策というより、WordPressのプラグインが持つ強い権限と、それに伴うリスクをどう見直すかという話でした。

EmDashでは、対応するプラグインを隔離された環境で動かし、必要な権限を明示する仕組みが用意されています。ただし、すべての拡張機能が無条件に隔離されるわけではなく、形式や設定によります。「EmDashにすれば絶対安全、更新も不要」という話ではありません。

参考：PHPのサポート期間、WordPress公式のセキュリティ対策、EmDashのプラグイン設定

最初は、AIブログで移行できるか試す計画だった

目的は、WordPressで運営していたAIブログを、EmDash＋Astroへ移せるか検証することでした。うまくいけば、別に運営している「ふみきりトリップ」にも同じ構成を使えないか、と考えていました。

記事のお引っ越しだけでなく、PHP・テーマ・プラグインの保守負担を減らし、ChatGPTやCodexと記事の企画・執筆・編集・登録・公開を効率化したい。デザインはAstroで自由に作り、AdSenseや楽天アフィリエイトなどの収益化も続けたい、という計画でした。

ただし、動いているWordPressには手を加えず、まずはパソコン内だけで試すことにしました。移せるものと作り直すものを確認してから、本番移行を判断する方針です。

WordPressのバックアップも用意

試したのはWindows 11のパソコンです。インターネットに公開する前に、自分のパソコンの中だけで動く「ローカル環境」を用意しました。

先に、ConoHa WINGからWebデータとデータベースのバックアップを取得。WordPressの管理画面にある「ツール」→「エクスポート」から、記事のXMLファイルも書き出しました。

記事のデータと画像のファイルは別です。画像は、バックアップ内のuploadsフォルダーから確認しました。phpMyAdminではデータベースの候補が二つ出てきて、名前を照らし合わせながら選ぶ場面もありました。

バックアップも、Codexに手順を案内してもらい、画面を確認しながら一つずつ進めました。データベースの候補が複数あるなど、案内と手元の状況を照らし合わせて迷ったときは、その都度質問しました。

なお、バックアップを取得することと、本番サイトへ復元することは別。今回は元のブログへ復元する操作はせず、手元に保存したデータで試しています。

EmDashの前に、Node.jsのインストールが必要だった

EmDashをパソコンで試すには、先にNode.jsというソフトを入れる必要がありました。Node.jsは、JavaScriptで書かれたプログラムをパソコン上で動かすための実行環境です。EmDashを用意するための道具であるnpmも一緒に使います。

WordPressの管理画面からプラグインを追加する感覚とは違い、まずパソコン側の準備が必要だったんですね。

コードやファイルを扱うためのVS Codeもインストールしました。当時の作業メモに残っていた環境はこちらです。これから試す人に、このバージョンを指定するものではありません。

項目	検証時の環境
OS	Windows 11
Node.js	v26.13.0
npm	11.20.0
EmDash	v1.4.0
Astro	v7.4.7
エディター	VS Code

以下は、Windowsでこれから試す人向けに、公式資料をもとに整理した手順です。当時の操作を一つずつ記録したものではなく、画面や必要なバージョンは更新で変わることがあります。

1. Node.jsとnpmを用意する

私の場合は、Node.jsもCodexに案内してもらったコマンドでインストールしました。公式サイトからインストーラーをダウンロードして、画面を順番にクリックしたわけではありません。パソコンの準備の段階から、AIに手順を示してもらって進めています。

インストール方法は環境によって異なります。これから試す場合は、EmDash公式の導入手順で必要なバージョンを確認し、自分のWindows環境に合う方法を選んでください。Node.js公式サイトからインストーラーを使う方法もあります。

インストール後にPowerShellを開き直し、次のコマンドでバージョンが表示されるか確認します。

node --version
npm.cmd --version

私の環境では、PowerShellの実行ポリシーによってnpm.ps1を実行できませんでした。そこで、実行ポリシーは変更せず、npm.cmdを使って進めました。以下のコマンドも、その書き方にしています。

2. 試作用のEmDashプロジェクトを作る

既存ブログとは別の作業用フォルダーで、次を実行します。

npm.cmd create emdash@latest

対話形式の質問では、プロジェクト名を例えばmy-emdash-siteにし、実行先はNode.js、テンプレートはStarter、パッケージ管理はnpm、必要なソフトのインストールはYesを選びます。これはパソコン内で試すための例なので、Cloudflareの契約や本番サイトの変更は必要ありません。

EmDashの対話式セットアップ。実行先にNode.js、テンプレートにStarterを選択済みで、パッケージ管理のnpmを選んでいる

再現画面：矢印キーで項目を選び、Enterで確定します。撮影用のプロジェクト名はemdash-dialog-screenshotです。この撮影ではnpmを選ぶ画面まで進め、作成を実行せずに中止しました。

3. ローカルサイトを起動する

作成されたフォルダーへ移動して、開発サーバーを起動します。

cd my-emdash-site
npm.cmd run dev -- --host 127.0.0.1

PowerShellは開いたままにして、表示されたURLをブラウザーで開きます。通常はhttp://127.0.0.1:4321/です。別のサイトが同じポートを使っている場合は、画面に表示されたURLを確認してください。終了するときはPowerShellでCtrl+Cを押します。

4. 管理画面で初期設定する

同じURLの末尾に/_emdash/admin/を付けて管理画面を開きます。通常ならhttp://127.0.0.1:4321/_emdash/admin/です。

案内に沿ってサイト名や管理者情報を設定し、パスキーを登録します。その後、サンプル記事の編集・公開と、ローカルサイトでの表示を確認します。ここでの「公開」は、起動中のパソコン内の試作用サイトへの反映です。

以下の画像は、記事用にEmDash v1.4.0を入れ直して撮影した再現画面です。当時のスクリーンショットではありません。

EmDashのサイト初期設定画面。サイトタイトル、キャッチフレーズ、サンプルコンテンツの選択欄

再現画面：サイト名などを入力し、今回はサンプルコンテンツから始めます。

作成される.envには秘密の設定が含まれるため、記事やGitHubに載せないようにします。

参考：EmDash公式のローカル導入手順

認証でつまずきつつ、テスト記事の表示まで確認

実際の初期セットアップではサンプルコンテンツを選び、管理画面を確認しました。ただ、すべてがすんなり進んだわけではなく、パスキーやメール認証の画面では問題も起きました。

ここでも、詰まったらAIに相談します。自分だけで解決方法を探し続けるのではなく、表示された画面やエラーを伝えて、次にどう進めるか聞きながら検証しました。

今回、記事用に初期設定をやり直したときにも、パスキーの作成でエラーが表示されました。

EmDashのパスキー作成画面に、セキュリティ上の問題とセキュアな接続の確認を求めるエラーが表示されている

再現時の画面：「セキュリティ上の問題が発生しました。セキュアな接続でアクセスしていることを確認してください。」と表示されました。この表示だけでは原因は断定できず、当時も同じ原因だったかは確認できません。

今回の再現では、開発用のDev bypassで管理画面へ

今回の再現でも、エラーが出たところでAIに相談しました。そこで案内されたのが、開発サーバーの起動時に表示される「Dev bypass」です。これを使ったところ、管理画面に入ることができ、検証を続けられました。

Dev bypassは、パスキーの設定・認証を省略して、開発用の管理者として入るための機能です。「管理画面に入れず先へ進めない」という困りごとは、この方法で解決できました。ただし、パスキーのエラー自体を直したわけではありません。

EmDashのダッシュボード。Page、Post、メディアをアップロードのボタンが並ぶ

再現画面：管理画面では記事・固定ページの作成や、画像のアップロードに進めます。まだ画像を取り込んでいないため、メディアファイルは0件です。

EmDashのStarterテンプレートでサンプル記事Welcomeを表示した画面

再現画面：サンプル記事「Welcome」もローカルで表示できました。これはWordPressから取り込んだ記事ではなく、Starterテンプレートに含まれる記事です。

この方法はパソコン内の開発・検証用です。本番運用時の認証設定の代わりにはしません。また、今回この方法で入れたことと、当時も同じ方法を使ったかどうかは分けて記録しています。

当時の作業メモに戻ると、基本的な記事作成と表示は確認できていました。管理画面のPostsから「EmDash動作確認」というテスト記事を作って公開し、ローカルサイトの/posts/emdash動作確認で表示できました。

自分のパソコンでEmDashが動き、管理画面で作った記事がサイトに出る。 まずはそこまでを一つの区切りにして、WordPressのデータ移行へ進みました。

編集画面や設定も触ってみた

今回の再現では、本文に文字を入れ、見出しや太字、リンクなどの操作も試しました。

EmDashの記事編集画面。見出しレベルや太字などの操作を試している

再現画面：見出しを選ぶメニュー。文字を入力して編集するところまでは試せました。

1度目の検証では、Postの自動保存もできていました。 ただ、今回スクリーンショットを撮るために再現した検証ではエラーになり、自動保存はうまくいきませんでした。今回のエラーの原因は特定できていません。最初は使えていた機能でも、再現時には同じ結果にならなかった、という状況です。

EmDashの設定画面。一般、SNSリンク、SEOの項目が並ぶ

再現画面：サイト情報やSNSリンク、SEOの設定項目も確認しました。設定画面を見た段階で、すべての設定や動作を検証したわけではありません。

WordPressの記事と画像を取り込んでみた

移行では、本文やタイトルだけでなく、投稿日・更新日、カテゴリー・タグ、アイキャッチや本文内の画像、パーマリンク、SEO情報、内部リンクも確認対象にしました。既存の記事URLはできるだけ維持したいと考えていたからです。

これらがすべて自動で移るとは限らないので、記事データを移す作業と、表示や機能を再構築する作業を分けて考えました。

今回の再現では、WordPress用のインポート画面も確認しました。サイトURLの入力欄や、XMLファイルをアップロードする欄があります。今回ここから再インポートはしていません。

EmDashのWordPressインポート画面。サイトURLとエクスポートXMLの入力欄

再現画面：WordPressからの取り込み用の画面。以下の取り込み件数は当時の記録です。

当時は、WordPressの記事や画像を取り込んでいきました。当時の作業記録では、取り込めたのは次のデータです。

記事：15件
固定ページ：2件
カテゴリー：6件
タグ：10件
画像：155件を取り込み、重複がまとまりメディア一覧では154件

「今まで書いた記事が、別の仕組みでも表示されるんだ！」というところまでは確認できました。

ただし、記事を移せたことと、ブログ全体の引っ越しが終わることは違いました。

WordPressで使っていたCocoonのデザインや装飾、広告の位置などが、データを取り込むだけでそのまま引き継がれるわけではありません。ただ、私の場合はCodexに「既存サイトと同じデザイン、見栄えのサイトを作って」と指示すると、Astro側で作ってくれました。

初回の指示で、見た目の7〜8割はできてしまった印象です。 アイコンや文字のサイズ、フォントなどの微修正は必要でしたが、一から自分でデザインを組み立てる作業ではありませんでした。画面を見て「ここをもう少し小さく」「この文字の雰囲気を変えたい」と伝えながら整えていく形です。

この7〜8割は、今回の私の体感です。機能や広告の動作まで検証が完了したという意味ではありませんが、既存サイトに近い見た目を作る作業も、Codexに日本語で頼みながら進められました。

動いた。でも「私にCMSは必要？」となった

EmDashを入れて、記事と画像を表示するところまではできました。実際に触ったことで、動画を見るだけでは分からなかった移行作業も見えてきました。

でも、ここで考えが少し変わりました。

ブログを更新するのは私一人。元になる情報をAIに渡して、記事を作ってもらい、自分で確認する。そんな使い方なら、管理画面を持つCMSそのものが必要なのかな、と。

EmDashを選んでも、EmDashの更新やデータの管理は残ります。私が減らしたかったのは、まさにその「記事を書く以外の管理」でした。

結局、私はEmDashでの本番運用は選ばず、CMSを使わない静的サイトへAIブログを移しました。

ただし、この方法が誰にでも合うとは思いません。「CodexやClaude Codeは触りたくない」「管理画面のボタンや入力欄で操作するGUIが好き」「スマホからの記事投稿が必須」という方には、今回の私のようなCMSなしの運用はおすすめしません。記事ファイルを編集して公開する手順を、今までより不便に感じる可能性があります。管理画面で更新できるCMSを残す方が、使い方に合っていると思います。

WordPressで困り続けていたわけではない

WordPressには自動更新の設定もあります。更新後にログインできなくなったり、見た目が崩れたりする話は聞いていましたが、私が運用した約3年間では、そうしたトラブルは経験しませんでした。

ConoHa WINGでは、利用者が管理画面からPHPのバージョンを選ぶことはできました。ただ、私が気になった2026年10月のPHP脆弱性への対応は、その選択操作で解決できるものではなく、ConoHa側で更新してもらう必要がありました。

私が確認した範囲では、ConoHa側で対応しても、管理画面から見えるPHPのバージョン表示に変化はありませんでした。そのため、「自分のブログが動いている環境は、いつ更新されたのか」までは把握できず、そこは不満に感じました。

対応してもらえること自体はありがたいのですが、利用者の立場で対応状況を確かめにくいと、気になってしまいます。トラブルが起きたからというより、こうした心配をする負担も減らしたいと思うようになりました。

参考：ConoHa WINGのPHP設定

WordPressの管理画面で更新する使い方が合っているなら、そのまま続ける選択もあります。私が約3年間使っていたサーバーはConoHa WINGでした。今回の移行理由は、自分に合う運用と費用を見直したかったからで、利用中に大きな更新トラブルを経験したからではありません。

広告・PR：以下はアフィリエイトリンクです。

心配する負担を減らせる環境と、コストが決め手に

私が欲しかったのは、脆弱性の話題を見かけるたびに「私のブログ、大丈夫かな？」といちいち心配しなくて済むよう、気にする対象を減らせる環境でした。

公開サイトでPHPやCMSの管理画面を動かさない静的サイトなら、少なくともその部分について気にする必要はなくなります。アカウント管理や制作に使うソフトの更新などは残りますが、自分のブログに必要なものだけに絞れるのが魅力でした。

コストも決め手の一つでした。 私の試算では、これまでサーバー代が年約13,000円。静的サイトをCloudflareの無料枠で公開する形なら、移行後はドメイン代の年約2,000円程度を中心に運用できる見込みでした。AIの有料プラン代は別に考える必要があり、元のサーバー契約が残る間はその費用もかかります。

ひとりで更新するブログで、記事作りはAIと進める。その使い方なら、CMSを手放して、心配・管理・費用の負担を減らす形が自分には合っていると考え、静的サイトへの移行を決めました。

EmDashを試したことは無駄ではなく、自分のブログに必要なものを整理するきっかけになりました。次の記事では、なぜその形を選んだのか、費用や手放した機能も含めて書きます。