SUAVE AI Works

PHPの緊急脆弱性をきっかけに、WordPressからEmDashへ。非エンジニアがAIと一緒にサイトを引っ越した話

公開日：

複数のWebページが青い橋を渡り、整理された新しいサイトへ移っていくイメージ

何をしたか

2026年10月25日、会社サイト（leaplab72.com）を、WordPress から EmDash という新しい仕組みに引っ越しました。調査から本番の切り替えまで、おおよそ2日間（10月24〜25日）。エンジニアではない私が、AI（Claude と Codex）と一緒に進めました。

この記事では、なぜ引っ越したのか、どう進めたのか、AIに何を任せて何を任せなかったのかを、専門用語を減らして書きます。同じことを考えている個人事業主や中小企業の社長の、判断材料になれば幸いです。

なぜ引っ越したのか

一番の決め手は、2026年10月に PHP で見つかった深刻な脆弱性です。そこに、プラグインへの不安と、「AI でサイトを管理したい」という考えが重なりました。

サイト移行までの経緯：2026年7月 WordPress本体の緊急脆弱性（wp2shell）、2026年10月21日 PHPの緊急脆弱性の修正版公開（php2shell）、2026年10月25日 EmDashへ切り替え

きっかけ：PHP に「緊急」レベルの脆弱性

  • 2026年10月21日（日本時間の夜23時）、PHP の開発チームが、深刻な脆弱性2件（CVE-2026-109618、CVE-2026-109619。通称「php2shell」）を直した修正版を公開しました。
  • 深刻度は10点満点で9.2。最も深刻な「緊急」の区分です。
  • 中身は、ログインもしていない第三者が、外からサーバー上でプログラムを動かせてしまうおそれ。サイトの乗っ取りにつながり得る種類です。
  • 修正版は PHP 8.5.12、8.4.27、8.3.36、8.2.35。サポートが終わった古い版（8.1以前）は、正式な修正版が出ません。
  • 公開の前に情報が漏れ、Cloudflare は修正版の公開前から攻撃の動きを観測したと伝えています。
  • 日本でも ITmedia NEWS や ＠IT などが取り上げ、大きな話題になりました。

出典：PHP Foundation の発表、gihyo.jp

WordPress は、なぜ関係あるのか

WordPress は PHP で動いています。今回の弱点は WordPress ではなく、その土台の PHP にあります。そのため、WordPress を最新にしても防げません。レンタルサーバーなら事業者が、自分で管理するサーバーなら自分が、PHP を更新する必要があります（Codeable の解説）。

しかも WordPress 本体でも、2026年7月に「wp2shell」と呼ばれる緊急の脆弱性（CVE-2026-63030 ほか）が直されたばかりでした。こちらも、ログインなしでサイトを乗っ取られるおそれがあるものでした（ScanNetSecurity）。

わずか3か月ほどの間に、WordPress の本体と、その土台の PHP の両方で「緊急」が続きました。ここで、このまま WordPress で会社のサイトを運営し続けてよいのか、と考えて、一気に切り替えることにしました。

もう一つの理由：プラグインと、AI の時代

WordPress の脆弱性の大半は、プラグイン（後付けの機能）で見つかっています。セキュリティ企業 Patchstack の年次報告では、2025年に見つかった WordPress の脆弱性は1万1,300件を超え、その96〜97%がプラグインでした（紹介記事）。

これからは、AI を使ってプログラムの弱点を探すことが当たり前になります。実際、PHP の開発元も、AI でコードを点検する体制を強めると発表しています。弱点を見つける速さが上がれば、数が多く、作り手もばらばらなプラグインは、これまで以上に狙われやすくなる、と私は考えています。

もう一つは、AI でサイトを管理したかったことです。WordPress でも AI に触らせることはできますが、私の使い方では、AI との相性が多少低いと感じていました。

EmDash には、AI をつなぐ入口が最初から備わっています。しかも、AI に許す操作を「記事と画像の読み書き」だけに絞れます。「AI に任せたい。でも、任せすぎたくない」という私の考えに、ちょうど合っていました。

引っ越し先はどういうものか

サイトの記事やページを書いて、公開・管理する道具を CMS（コンテンツ管理システム）と呼びます。WordPress は、その代表格です。

今回選んだ EmDash も CMS です。WordPress と同じように、管理画面から記事を書けます。違うのは中身です。

  • PHP ではなく、Cloudflare という大手のインフラ企業の仕組みの上で動きます。
  • 記事のデータは Cloudflare のデータベースに、画像は Cloudflare の保管場所に、分けて置いています。
  • AI をつなぐ「入口」が最初からあります（MCP という、AI がサイトの記事を読み書きするための決まりです）。しかも、AI に許可する操作を、「記事を読む・書く」「画像を読む・書く」の4つだけに絞れます。サイトの設定や、メニューの変更は、AI には任せられないようにしてあります。

セキュリティの面では、次の2点が決め手になりました。

  • PHP を使っていない。 そのため、今回の PHP の脆弱性の影響は受けません。
  • プラグインを、一つずつ隔離して動かす。 プラグインごとに切り離した場所で動かし、許可した操作しかできない仕組みです。WordPress のプラグインは、サイトのファイルやデータベースにほぼ何でも触れるので、そこが大きな違いです（InfoQ の紹介記事）。

とはいえ、どんな仕組みにも弱点が見つかる可能性はあります。EmDash は2026年4月に発表されたばかりの新しい仕組みで、「Cloudflare のサービスに依存しすぎる」という批判もあります。切り替えたから安心、ではなく、更新を続けることは変わりません。

WordPress の記事や画像を読み込む機能は、最初から用意されていました。とはいえ、読み込めば終わり、というわけにはいきませんでした。次の章で、流れを説明します。

全体の流れ

いきなり本番を切り替えることはしませんでした。「仮のサイトで試して、問題がないと確かめてから切り替える」という順です。

サイト移行の6つの手順：材料を確かめる、仮のサイトに取り込む、見た目を再現する、プラグインを置き換える、本番を切り替える、確かめる
  1. 材料を確かめる。 WordPress から、記事・画像・デザインのファイル・データベースを、すべて書き出します。中身を数えて、何を引っ越して何を捨てるかを決めます。
  2. 仮のサイトに取り込む。 公開中のページ（7件）と画像（20枚）を、本番とは別のアドレスに置いて、見出しの数や画像の数が同じかを確かめます。
  3. 見た目を再現する。 今までのデザインを、新しい仕組みの上で同じ見た目にします。
  4. プラグインを置き換える。 WordPress で後付けしていた機能（問い合わせフォーム、検索対策の設定、転送の設定など）を、新しいサイトで作り直します。
  5. 本番を切り替える。 ドメイン（leaplab72.com）の向き先を、Cloudflare に変えます。この切り替えは、約 9 分で反映されました。メールの転送も、同じときに設定し直しました。
  6. 確かめる。 フォームの通知メールが届くかを、本番で試しました。

もしものときに切り替え前の状態へ戻せるよう、戻し方もメモに残しています。

つまずいたことと、決めたこと

順調に見えて、実際には迷ったところがいくつかありました。

旧ブログ記事17件は、「削除済み」にした

これまでのブログ記事は、引っ越し先には持っていきませんでした。その代わり、旧アドレスを開いた人や検索エンジンに「このページはもうありません」と正しく伝える設定（「410」という結果）にしています。復活させないと決めたことも、あとで迷わないようにメモに残しています。

問い合わせフォームは作り直した

WordPress で使っていたフォーム用のプラグインは、新しい仕組みではそのまま使えません。項目と文言は同じにして、作り直しました。送信内容は必ずデータベースに保存され、あわせてメールでも届きます。迷惑メール対策には、Cloudflare の対策機能を使っています。

記事ページで「日本語のカテゴリ」が404になった

これは、引っ越しのあとに記事ページを整えていたときに見つかりました。カテゴリ名「記事」のアドレス用の名前が、引っ越しのときに「%e8%a8%98...」という文字列の形で保存されていて、ページ側の比べ方と食い違っていました。設定を直すのではなく、比べる前に形をそろえるようにコードを直して、解決しました。

AIに任せたこと、任せなかったこと

線引きは、「下書きまではAI、公開と削除は人」です。引っ越しのあとでも、この線引きはそのまま続けています。

AIと人の役割：AIがやるのは材料の整理、コードの修正、下書き、表示確認。人がやるのは公開、削除、ドメインとメールの設定、パスワードの管理

この線引きは、AI に渡す「引き継ぎメモ」に書いて、どの AI にも同じ内容を渡しています。理由は、戻しにくい操作（公開、削除、ドメインやメールの設定）ほど、人が最後に確認すべきだと考えるからです。

また、AI を複数使うときは、「同じ資料・同じルール」を渡して、役割を分けました。文章は Claude、画像とコードは Codex です。同じページを、二つの AI に同時に頼まないというルールも、メモに入れています。

やってみて分かったこと

やってみて分かったのは、「AI が速い」よりも、「確かめる仕組みが大事」だということです。

  1. 仮のサイトで先に試すと、本番は一瞬で終わる。 仮のサイトで中身と見た目を確かめておいたので、本番の切り替えは向き先を変えるだけ。反映まで約 9 分でした。
  2. AI も間違える。だから画面で確かめる。 例えば AI は一度、「記事のページはまだない」と報告しました。調べ直すと、実は簡素なひな形がすでに公開されていました。AI 自身が訂正してくれましたが、報告をそのまま信じず、最後は自分の目で確かめるようにしています。
  3. 線引きを書いておくと、AI を複数使っても迷わない。 「公開と削除は人」と書いたメモを渡しておくと、どの AI もそこで止まって、確認を求めてきます。
  4. 元のデータの控えは、2か所以上に。 引っ越しの後、整理していくと、WordPress の元データの控えが1か所にしかないと気づきました。旧サーバーを解約する前に、別の場所にもコピーを取る予定です。

同じことを考える人への確認リスト

引っ越しを始める前に、次のことを確かめておくと、迷いが減ります。

  • [ ] 今のサイトの、記事・画像・デザインのファイル・データベースを、すべて書き出して保管した
  • [ ] 引っ越さない記事のアドレスを、「削除済み」「転送」のどちらにするか決めた
  • [ ] 問い合わせフォームなど、後付けの機能を一覧にして、代わりを用意した
  • [ ] メールの転送先を決めて、切り替えてから実際に届くか試す予定を立てた
  • [ ] 仮のサイトで、見出しの数・画像の数が同じか確認した
  • [ ] 切り替えてから戻す方法を、メモに残した
  • [ ] AI に任せる範囲と、任せない範囲（公開・削除・設定など）を、書いてから渡した
  • [ ] 元データの控えを、別の場所（外付けドライブなど）にも取った

まとめ

PHP の緊急脆弱性は、WordPress を使う多くのサイトに関わる話でした。まずは、ご自身のサイトの PHP が修正版になっているか、契約しているサーバー会社に確認してみてください。

そのうえで、今後も WordPress を使い続けるのか、別の仕組みに移るのか。答えは、サイトの使い方によって違います。私の場合は、「AI で管理したい」という目的があったので、引っ越しを選びました。

SUAVE AI Works では、このような自社での実践をもとに、AI 活用のご相談をお受けしています。気になることがあれば、お問い合わせからお気軽にどうぞ。