この記事が答える悩み
「WordPressで会社サイトを作ったが、LPを1本増やすたびにテーマ、プラグイン、表示速度、セキュリティ確認が重い」「制作会社や担当者が変わるたびに、どこを触ればよいかわからない」「AIで記事やLPを増やしたいのに、CMSの都合で更新が止まる」。この記事は、その悩みに対して、WordPressを全否定せず、自社サイトとLPの役割が変わった会社はどこから卒業すべきかを整理します。
3行で読む結論
- WordPressを卒業するとは、CMSを捨てることではなく、公開サイト、編集画面、LP実験を分けて設計し直すことです。
- 2026年5月16日（JST）時点の一次情報を見ると、WordPressはPHP、MySQL/MariaDB、HTTPS、更新運用を前提にする一方、CloudflareはPages、Workers、D1、R2を組み合わせてサーバーレスに近いWeb基盤を作れます。
- 自社サイトとLPが「会社案内」ではなく「毎週改善する営業資産」になっているなら、Cloudflare + EmDashのほうが、速く直せて、壊れにくく、AIエージェントにも運用を渡しやすいです。
このNEWSで持ち帰ること
今回の持ち帰りは、「サイトをCMS中心に考えるのをやめる」という判断軸です。従来の自社サイトは、CMSの中にページ、画像、テーマ、問い合わせ、SEO設定、LP、ブログ、権限管理を詰め込む作り方がよくありました。初期構築は速いのですが、事業が動き出すと、1つの変更が別の変更を巻き込みます。LPを修正したいだけなのに、テーマのCSS、プラグインの相性、キャッシュ、PHPバージョン、バックアップ、権限まで気にすることになります。
Cloudflare + EmDashで考えると、役割は分かれます。Cloudflareは公開面を配信し、必要な動的処理をWorkersで持つ。EmDashは編集画面とコンテンツAPIを担当する。フロントエンドはAstroやNext.jsのようなコードで管理し、LPやサービスページはGitで差分管理する。この分離が、AIエージェントを使った制作・更新と相性がよいのです。
つまり「WordPressから乗り換えるべきか」という問いは、ツール名の比較ではありません。「自社のWeb運用は、毎週変わる営業資産になっているか」という問いです。毎週変わるなら、サイトを丸ごと1つのCMSに閉じ込めるより、公開面、編集面、実験面を分けたほうが判断も改善も速くなります。
WordPressは悪者ではない。卒業すべきなのは「全部入りCMS依存」
まず前提として、WordPressは今でも強い選択肢です。WordPress.orgは、WordPressがWebの43%以上を支えていると説明しており、セキュリティチームもコア、プラグイン、テーマを含む広いエコシステムを扱っています。ブログ、会員制コンテンツ、店舗サイト、既存プラグインを活用した予約・EC・多言語運用では、WordPressの管理画面とエコシステムが合う場面は多くあります。
ただし、自社サイトとLPの運用では、強みがそのまま重さになることがあります。WordPress.orgの要件ページでは、2026年5月時点でPHP 8.3以上、MariaDB 10.6以上またはMySQL 8.0以上、HTTPSを推奨しています。これは、WordPressが単なる静的ページではなく、サーバー上のPHPアプリケーションとデータベースを前提にするということです。
さらに、WordPress公式ドキュメントは、サイトを安全に保つにはプラグインとテーマを常に最新にすべきだと案内しています。プラグイン管理の文書でも、プラグインは新機能、コード品質、セキュリティのために更新されるため、最新に保つことがセキュリティとパフォーマンスの改善につながると説明されています。これはWordPressが危険という意味ではありません。むしろ、WordPressを安全に使うには、更新運用そのものが業務になるという意味です。
自社サイトの目的が「月に1回お知らせを出す」なら、その運用でも十分です。しかし、LPを毎週増やす、訴求をA/Bで試す、記事を検索・生成AI回答に引用される形へ直す、AIエージェントに下書きや実装修正を任せる、となると話が変わります。重いのはWordPressそのものではなく、公開面と編集面と実験面を1つの場所へ寄せすぎた設計です。
読者が取るべき行動は、WordPressの良し悪しを議論する前に、いまのサイト変更が「記事更新」「LP実験」「サービス訴求」「問い合わせ改善」のどれで詰まっているかを分けることです。
Cloudflare + EmDashで何が変わるのか
Cloudflare Pagesの公式ドキュメントは、PagesをCloudflareのグローバルネットワークへすぐデプロイできるフルスタックアプリケーション基盤として説明しています。Pages Functionsを使えば、専用サーバーを運用せずにサーバーサイドコードを追加できます。関連プロダクトとしてWorkers、R2、D1も並び、Workersはインフラを設定・保守せずにアプリケーションを作るサーバーレス実行環境、D1はWorkerやAPIから扱えるCloudflareネイティブのサーバーレスデータベースとして説明されています。
Cloudflareのストレージ選択ガイドでは、R2はS3互換のBlobストレージで、大量の非構造化データを保存でき、一般的なクラウドストレージに伴うエグレス料金なしで使えると説明されています。同じガイドでは、D1はSQLiteベースのサーバーレスデータベースで、Workersから扱うだけでなくHTTP APIによる外部アクセスにも対応すると整理されています。さらにWorkersの料金ドキュメントでは、D1からアクセスされるデータにはデータ転送や帯域の課金がないと明記されています。
この一次情報から見えるのは、Cloudflareが「Webサイトを置く場所」だけではなくなっていることです。静的なLP、問い合わせ前の診断フォーム、CMS API、画像配信、プレビュー、軽い検索、スケジュール実行まで、1つのエッジ基盤で組み合わせやすくなっています。
EmDashは、その上に置く編集レイヤーです。AITOWAのこのリポジトリでは、NEWS、ブログ、開発実績、制作実績をEmDash REST APIから取得する設計になっています。news コレクションの本文はリッチなMarkdown相当のデータとして管理でき、画像はEmDash Mediaへアップロードされ、公開フロントはAPIから取得した内容を表示します。つまり、編集者は管理画面で記事を扱い、制作者はフロントエンドをコードで磨き、公開面はCloudflareやNext.jsの配信設計に寄せられます。
読者が取るべき行動は、CMSを「サイトを作る場所」ではなく「編集データを入れる場所」と捉え直すことです。表示、編集、配信を分けるだけで、更新の詰まりはかなりほどけます。
自社サイトとLPでは、5つの差が効く
1. 表示速度より先に、変更速度が上がる
LPで本当に効くのは、最初の表示速度だけではありません。訴求が外れたときに、その日のうちに直せる変更速度です。WordPressでLPを運用していると、固定ページ、テーマビルダー、カスタムCSS、フォームプラグイン、キャッシュプラグインが絡み、軽い文言修正でも確認箇所が増えがちです。
Cloudflare + EmDashでは、LPの構成やコンポーネントはコードで管理し、更新頻度の高い文章やNEWSはEmDashで管理できます。CTA、セクション順、構造化データ、OGP、FAQ、内部リンクはコードレビューしながら直し、記事や実績の追加はCMSで行う。この分担にすると、マーケターと制作者が同じ画面を奪い合わなくなります。
読者が取るべき行動は、いまのLP修正依頼を10件並べ、どれが「CMSで変えるべきデータ」で、どれが「コードで直すべきUI」かを分けることです。
2. セキュリティ確認の範囲を小さくできる
WordPress運用では、コア、テーマ、プラグイン、PHP、データベース、管理画面、アップロードファイル、ログイン保護が同じ運用面に乗ります。もちろん自動更新、WAF、バックアップ、権限設計で堅くできます。ただ、LPを増やしたいだけの会社にとって、この面倒を見る範囲は広くなりやすいです。
Cloudflare + EmDashでは、公開サイトは静的配信または必要最小限のWorkers処理に寄せられます。管理画面はEmDash側に分け、フロントの公開コードはGitで差分管理する。問い合わせフォームやプレビューのような動的部分だけに権限と検証を集中できます。攻撃面をゼロにはできませんが、普段触る場所と公開される場所を分離できます。
読者が取るべき行動は、「公開ページを見るユーザー」と「編集画面へ入る担当者」が同じアプリケーションに触っているかを確認することです。分けられるなら、分けたほうが運用判断は楽になります。
3. AIエージェントが触れる範囲を決めやすい
AIエージェントでLPや記事を改善する場合、いちばん怖いのは「どこまで触ったかわからない」ことです。WordPressの管理画面内で文章、テーマ、プラグイン設定、フォーム、SEO設定をまとめて変更すると、AIに任せる範囲を切りにくくなります。
コード管理されたLPなら、AIエージェントには「このセクションの見出しと説明だけ」「FAQの構造化データだけ」「NEWS記事のMarkdownだけ」という小さな作業を渡せます。EmDashの下書きに登録し、管理画面で人間が確認し、公開は別ステップにすることもできます。これは、AIを使う会社にとって大きな安全弁です。
読者が取るべき行動は、AIに触らせてよいファイル、触らせない設定、必ず人間が見る項目を1枚に書くことです。
4. LPとNEWSを同じ営業導線に置ける
自社サイトのLPは、単独で勝つものではありません。NEWS、ブログ、実績、FAQ、導入事例、比較記事、用語解説がつながって、初めて検索と生成AI回答に拾われる営業資産になります。LPだけをきれいにしても、周辺の記事が薄ければ、検討中の読者に届きません。
EmDashでNEWSや実績を管理し、CloudflareやNext.js側で表示を統一すると、LPの中に関連記事、実績、CTAを自然に組み込めます。たとえば「AIでLP制作を自動化する講座」のLPと、NEWSの深掘り記事、Codex運用の記事、AI導入支援ページを内部リンクで接続できます。サイト全体が、単発のページ集ではなく、読者の疑問に順番に答える経路になります。
読者が取るべき行動は、LPの最後に置くリンクを「お問い合わせ」だけにしないことです。迷っている読者には、実績、関連記事、導入支援ページへの道を置く必要があります。
5. 将来の作り替えが怖くなくなる
WordPressでテーマやページビルダーに強く依存すると、数年後のリニューアルで「どこからどこまでがコンテンツで、どこからが見た目か」が混ざります。移行時に本文、画像、URL、フォーム、CSS、プラグイン設定を取り出す作業が発生し、リニューアルのたびに負債が増えます。
Cloudflare + EmDashでは、コンテンツはAPIで取り出せるデータ、見た目はコード、画像はメディアライブラリ、配信はCloudflareというように境界を置けます。境界があると、次のリニューアルでフロントだけ差し替えたり、LPだけ別プロジェクトに切り出したりしやすくなります。
読者が取るべき行動は、いまの記事・実績・LPコピーが、テーマに埋まっているのか、CMSのフィールドとして取り出せるのかを確認することです。
逆に、WordPressを残したほうがよいケース
卒業という言葉を使っていますが、すべての会社がCloudflare + EmDashへ移るべきではありません。WordPressを残したほうがよいケースもあります。
1つ目は、編集者が多く、既存のWordPress管理画面に深く慣れている場合です。記事承認、権限、ブロックエディタ、メディア運用、既存ワークフローが安定しているなら、急いで変える必要はありません。
2つ目は、会員機能、EC、予約、学習管理、多言語などを既存プラグインで運用していて、売上や業務がそこに乗っている場合です。この場合は、表側のLPだけCloudflareに切り出し、WordPressは業務システムとして残すほうが安全です。
3つ目は、担当者がコードレビューやGit運用をまったく受け入れられない場合です。Cloudflare + EmDashは、公開面をコードで管理するほど強くなります。コードを持ち込む意思がないなら、ノーコード寄りのWordPress運用を磨くほうが成果が出ます。
読者が取るべき行動は、「全部移行」か「全部残す」ではなく、LP、NEWS、実績、問い合わせ、会員機能を分け、どこだけ切り出すかを決めることです。
移行は6ステップで考える
Step 1: URLと目的を棚卸しする
まず、現在のサイトから上位20ページを抜き出します。トップ、サービス、料金、事例、ブログ、問い合わせ、LP、採用、会社概要などを並べ、それぞれの目的を1行で書きます。「問い合わせを増やす」「検索流入を受ける」「商談前の不安を消す」「既存顧客へ説明する」のように分けます。
ここで重要なのは、すべてのページを同じ強度で移行しないことです。営業に効くページ、検索で拾われるページ、ほとんど読まれていないページを分ければ、最初に作るべきCloudflare + EmDash構成が見えます。
Step 2: CMSに入れるものとコードにするものを分ける
次に、ページ要素を分けます。記事タイトル、要約、本文、タグ、対象読者、実績カード、画像、公開ステータスはEmDashに入れる候補です。ヒーロー、CTA、フォーム、FAQの見せ方、導線、構造化データ、LPセクションの動きはコードにする候補です。
この分け方を間違えると、せっかく移行しても再び重くなります。CMSに何でも入れすぎると、画面は便利でも品質管理が難しくなります。コードに寄せすぎると、毎回エンジニアが必要になります。更新頻度と品質要求で分けるのが実務的です。
Step 3: EmDashのコレクションを先に決める
AITOWAの構成では、news、blog、development_works、ningen_works のように用途ごとにコレクションを分けています。自社サイトでも、NEWS、実績、サービス、FAQ、LP用素材を同じ箱に入れず、役割ごとに分けるべきです。
たとえばNEWSには、タイトル、カテゴリ、読者分類、要約、本文、タグ、関連技術、相談リンクを持たせる。実績には、成果、役割、使用技術、公開可否、画像を持たせる。LPには、固定ページとしてコード管理する部分と、CMSから差し込む実績・FAQを分ける。この設計が後の運用を決めます。
Step 4: 1本のLPと3本の記事で試す
最初から全サイトを移行しないでください。まずは最重要LPを1本、周辺記事を3本だけ作ります。たとえば「AI導入支援」のLP、関連記事として「Codexを日常業務に入れる設計」「LP制作をAIで回す手順」「WordPressからCloudflareへ移る判断基準」を用意します。
この4本で、問い合わせ導線、内部リンク、検索での見え方、管理画面での編集、プレビュー、画像アップロード、AI下書き登録までを確認します。4本で詰まる設計は、40本に増やすと必ず詰まります。
Step 5: 301リダイレクトと計測を先に置く
移行時に怖いのは、見た目が変わることより、URLと計測が崩れることです。旧URLから新URLへの301リダイレクト、canonical、OGP、サイトマップ、robots.txt、フォーム送信、広告タグ、Search Console、GA4の確認を先にチェックリスト化します。
Cloudflare側でリダイレクトやエッジ処理を管理できると、URL移行はかなり扱いやすくなります。ただし、誰がいつ確認するかを決めないと、移行後に「流入が落ちた気がする」という曖昧な話になります。公開前に、旧URL、移行先URL、確認方法を表にしてください。
Step 6: 公開後30日で直す前提にする
移行は公開日がゴールではありません。公開後30日で、検索クエリ、クリック率、問い合わせ率、熟読されている記事、離脱しているLPセクションを見て直すところまでが移行です。
Cloudflare + EmDashの良さは、この改善が速いことです。本文はEmDashで直せる。LPの構造はコードで直せる。画像はMediaで差し替えられる。AIエージェントに改善案を出させ、下書きへ登録し、人間がレビューする導線も作れます。移行後の改善が回るなら、移行費用は単なるリニューアル費ではなく、営業資産を育てる投資になります。
コピペするプロンプト本体
WordPressからCloudflare + EmDashへ移るべきかを判断する前に、次のプロンプトで現状を棚卸ししてください。
textあなたは自社サイトとLPの移行設計に強いWebアーキテクトです。 以下の情報をもとに、現在のWordPressサイトをCloudflare + EmDash構成へ移すべきか、残すべきか、部分移行すべきかを診断してください。 【前提情報】 - 会社の事業内容: {事業内容} - 現在のWordPressの用途: {例: コーポレートサイト / ブログ / LP / EC / 予約 / 会員機能} - 月間で更新するページ数: {更新数} - LPの追加頻度: {頻度} - 使っている主なプラグイン: {プラグイン名} - 現在困っていること: {表示速度 / セキュリティ更新 / 制作会社依存 / LP改善速度 / SEO / AI活用} - 絶対に止められない機能: {問い合わせ / 決済 / 予約 / 会員ログイン / その他} - 社内にGitやコードレビューを扱える人がいるか: {いる / いない / 外部パートナーのみ} 【出力してほしいこと】 Step 1: サイトを「公開面」「編集面」「LP実験面」「業務機能面」に分けて、現状の問題を表にしてください。 Step 2: WordPressに残すべき領域、Cloudflareへ切り出すべき領域、EmDashで管理すべきコンテンツを分けてください。 Step 3: 最初に移行するべき1本のLPと、周辺に必要な3本の記事案を提案してください。 Step 4: 移行時に失ってはいけないURL、計測、フォーム、画像、構造化データのチェックリストを作ってください。 Step 5: 30日後に見るべき改善指標を、検索流入、問い合わせ、編集速度、保守負荷の4観点で定義してください。 【制約】 - WordPressを無条件に否定しないでください。 - Cloudflare + EmDashへ全面移行すべきでないケースも必ず書いてください。 - 抽象論ではなく、明日確認できるURL、項目、担当者、判断基準に落としてください。 - APIキー、管理画面パスワード、顧客情報などの秘密情報は入力しない前提で設計してください。
- 使用シーン: リニューアル前、LP改善が詰まっているとき、WordPress保守費用と制作スピードのバランスを見直すときに使います。
- 期待される出力: WordPressに残す領域、Cloudflareへ切り出す領域、EmDashで管理するコンテンツ、初回移行スコープ、30日後の改善指標。
- AITOWAの実績: AITOWAでは、LP、NEWS、実績、AI導入支援ページを分けて扱い、更新頻度の高い情報はEmDash、表示品質や導線はコードで管理する設計を重視しています。
- 注意点: 移行診断に秘密情報は不要です。管理画面URL、トークン、顧客名、売上データをそのまま貼らず、抽象化した情報で判断してください。
AITOWA視点
AITOWA視点で見ると、WordPress卒業の本質は「AI時代のWeb運用に合わせて、作業の置き場所を変えること」です。AIエージェントが強くなるほど、サイト運用は人間だけの手作業ではなくなります。記事の下書き、LPの見出し案、FAQの追加、内部リンクの提案、構造化データの点検、フォーム改善案の洗い出しは、AIに任せやすい作業です。
しかし、AIに任せやすい作業ほど、境界が必要です。AIが本文を直す場所、コードを直す場所、公開前に止まる場所、管理画面で人間が確認する場所を分けておかないと、改善が速くなるほど事故も速くなります。
このプロジェクトのAITOWAサイトでは、NEWSやブログをEmDash REST APIから取得し、公開フロントではNext.js側が表示を組み立てています。NEWSの本文はEmDashで扱い、画像はEmDash Mediaを通し、公開スクリプトはローカルファイルを最終成果物とは扱わず、実際のEmDash APIへ下書き登録して読み戻すところまで確認します。これは、単にCMSを入れ替えているのではなく、「AIが作る下書き」と「人間が確認する管理画面」と「読者が見る公開面」を分けるための設計です。
自社サイトとLPでも同じです。AIでLPを作るなら、AIに全部を任せるのではなく、作業を小さく分ける必要があります。見出しを作る、FAQを増やす、実績カードを追加する、NEWSを下書き登録する、CTAを検証する。それぞれの作業に、どのデータを触ってよいかを決めます。Cloudflare + EmDashは、その境界を作りやすい構成です。
読者が取るべき行動は、「AIでサイト運用を楽にしたい」と言う前に、AIが触る場所と人間が止める場所を分けることです。ここを決めると、ツール選定はかなり簡単になります。
30日で始めるなら、この順番が現実的
1週目: 診断と切り出し範囲の決定
最初の1週間は、移行作業ではなく診断に使います。WordPressのページ一覧、プラグイン一覧、テーマ依存、フォーム、画像、流入上位ページ、問い合わせにつながったページを確認します。ここで「全部を新しくする」と決めると危険です。最初は、営業上もっとも効くLPを1本だけ選びます。
この週の成果物は、移行対象URL、残す機能、切り出すLP、EmDashで管理するコンテンツ種別、リダイレクト表です。コードはまだ少なくて構いません。判断が曖昧なまま作り始めるほうが、後で高くつきます。
2週目: Cloudflare + EmDashの最小構成を作る
2週目は、Cloudflare側の公開基盤とEmDashのコレクションを作ります。NEWS、実績、FAQ、LP用の補助データをどのフィールドで持つかを決め、フロント側では1本のLPとNEWS詳細ページを表示できる状態にします。
この時点で重要なのは、管理画面の便利さより、データの形です。タイトル、要約、本文、対象読者、タグ、画像、相談リンクが取り出しやすいか。公開前のdraftを確認できるか。画像URLが本番で404にならないか。ここを先に確認します。
3週目: LPと記事を実際に登録する
3週目は、最重要LPを公開できる品質まで磨き、周辺記事を3本登録します。記事は「よくある質問に答える」「比較検討の不安を消す」「導入後の行動を示す」の3種類に分けると、LPだけでは届かない読者を拾えます。
ここでAIエージェントの出番です。記事下書き、内部リンク案、FAQ案、見出し案、CTAの言い換え案を作らせます。ただし、公開は自動にしません。EmDashのdraftに登録し、人間が管理画面で確認する流れにします。
4週目: 公開、計測、改善
4週目に公開します。公開後は、旧URLのリダイレクト、フォーム送信、OGP、サイトマップ、Search Console、GA4、表示速度、スマートフォン表示を確認します。公開当日はデザインを褒める日ではなく、壊れていないかを確認する日です。
その後30日で、検索クエリ、クリック率、問い合わせ率、読了されている記事、離脱しているセクションを見ます。Cloudflare + EmDashへ移行する価値は、ここから出ます。公開後に直しやすいからこそ、初回公開を完成品ではなく改善開始点にできます。
よくある質問
WordPressから完全移行しないと意味がありませんか？
完全移行でなくても意味があります。むしろ最初は部分移行がおすすめです。既存のWordPressをブログや会員機能として残し、LPと自社サイトの主要導線だけCloudflare + EmDashへ切り出す構成も現実的です。移行で失敗する会社ほど、最初から全部を動かそうとします。
EmDashを使うと、編集者はコードを書かないといけませんか？
いいえ。EmDashは編集画面とコンテンツAPIの役割を持ちます。編集者はタイトル、要約、本文、タグ、画像、公開状態を管理し、制作者や開発者が表示側をコードで整えます。すべてを編集画面で完結させるより、編集しやすい部分と品質を守る部分を分ける設計です。
Cloudflareにすると、デザイナーやマーケターが触りにくくなりませんか？
設計次第です。CTA文言、FAQ、実績、記事、画像のような頻繁に変わる情報をEmDashに入れれば、マーケターはCMSで触れます。一方で、LPのレイアウト、アニメーション、フォーム、構造化データはコードで守れます。触れる場所を減らすのではなく、触ってよい場所を明確にするのが目的です。
小さな会社でもCloudflare + EmDashは重すぎませんか？
最初から複雑に作ると重くなります。小さな会社なら、トップ、サービスLP、NEWS、実績、問い合わせだけで始めるのがよいです。重要なのは、最初の構成を小さくしつつ、後で増やせる境界を置くことです。WordPressの全部入りに慣れていると不安に見えますが、運用範囲を絞ればむしろ軽くなります。
関連記事
自社サイトとLPを営業資産に変えるなら
WordPressを卒業するかどうかは、技術の好みではなく、事業の更新速度で決めるべきです。サイトが名刺代わりなら、いまのWordPressを整えるだけでも十分かもしれません。しかし、LP、NEWS、実績、FAQ、導入記事を毎週改善し、AIエージェントと一緒に育てたいなら、公開面、編集面、実験面を分ける設計が必要です。
AITOWAでは、自社サイト、LP、NEWS運用、AIエージェント活用をまとめて設計し、Cloudflare + EmDashのような軽いWeb基盤へ落とし込む支援を行っています。WordPressを残すべきか、部分移行すべきか、最初のLPだけ切り出すべきかを整理したい方は、自社サイト/LP制作を相談する からご相談ください。
参考にした一次情報
- WordPress.org: Requirements
- WordPress.org: Security
- WordPress.org Documentation: Plugin and themes auto-updates
- Cloudflare Docs: Cloudflare Pages
- Cloudflare Docs: Choosing a data or storage product
- Cloudflare Docs: Workers Pricing
本記事はAIエージェントが下書きを生成し、aitowa編集部の方針・知見に基づき構成しています。