「WordPressじゃないほうが楽」はマーケ担当にとっても楽なのか、中小企業はどうしたらいいのかを、Claudeと考えてみた

WordPressで長く運用してきたサイトを、Cloudflare×Claude Codeの構成に移して運用が楽になった、という話を見かけることが増えてきましたよね？

こんな投稿です。

全記事を無事に移行できてデザインも良くなり、サーバー代もWordPressのメンテも不要に。記事作成から公開までClaude Codeに任せられて、YouTubeのリンクを渡すだけで記事にしてくれるので、Claude Codeが使えるならWordPressじゃないほうが楽、という内容でした。

自分のサイトなら確かにそうだろうなと思う一方で、クライアントのサイトに同じことを勧められるかというと、引っかかる部分がいくつかあったんですよね。Cloudflareに依存しすぎないか、ちょっとした修正もAI経由だと時間がかかるのでは、管理画面がないと全体像がつかめないのでは、などです。

特に気になったのが、サイトを作る側ではなく、タグやフォーム、広告の計測を扱うマーケ担当にとっても本当に楽なのか、という点です。社内にAIに詳しい人がいない中小企業だと、移行したあと誰がどう運用するのかという問題も出てきます。

そこで気になる点をClaudeにぶつけて、推す側の言い分も含めて両面から整理し、中小企業はどうしたらいいのかまで考えてみました。やり取りの中で出てきた疑問と議論を、分類ごとにまとめています。

先に結論

• 分かれ目は技術の新しさではなく「誰が、どう更新するか」

• AIに詳しい人がいない中小企業は、今はWordPress＋保守契約が手堅い

• 懸念は技術だけでなく、マーケ・法務・組織にまたがる←これが一番大変そう

技術がわかる人が自分のサイトをAIで運用するなら、WordPressより合理的な選択になりつつあるのは確かです。一方で、更新するのが非エンジニアだったり担当者が替わる前提だったりするサイトでは、別の問題を解決しないとかえって運用が大変になる、という感じです。

そもそも推す人の言い分は？

懸念から入る前に、この方法を推す側の言い分もClaudeに聞いてみました。

• コストと保守：サーバー代がほぼかからず、本体やプラグインのアップデート、脆弱性対策から解放される。プラグイン同士の競合で表示が崩れる、といったトラブルもなくなる

• 表示速度：CDNから静的ファイルを配信するので速く、アクセスが急増しても落ちにくい

• 資産としての扱いやすさ：記事がMarkdownでGitに入るので、全履歴が残っていつでも戻せる。データベースに閉じ込められない分、むしろ持ち運びやすい

• AIとの相性：テキストファイルとGitという構成はAIが一番扱いやすい形で、1,000記事規模の一括修正や内部リンクの整理も指示ひとつでできる

面白かったのは、「管理画面がない」のではなく「AIとの会話が管理画面になる」という考え方です。WordPressは非エンジニアがサイトを更新するための仕組みだったので、AIが更新を担うならその前提自体が変わる、という見方ですね。

このあたりは納得感があって、技術がわかる人が自分のサイトを運用する分には確かに理にかなっているなと思いました。

特に、最近話題になったPHPの脆弱性の件を考えると納得感があります。

技術面の疑問

Cloudflareに依存しすぎない？

最初に気になったのがここです。Claudeの答えは、依存の度合いは「何を使っているか」で変わる、というものでした。

記事がMarkdownでGitHubにあって、汎用的な静的サイトジェネレーターでビルドしているだけなら、ほかのホスティングにも比較的簡単に移せます。依存が深くなるのは、Workersやデータベース、ストレージなどCloudflare固有の機能に処理を寄せ始めたときです。DNSもホスティングもまとめていると、障害やアカウント停止のときに全部止まるという単一障害点の問題は別にあります。

それよりも大きいのはClaude Codeへの依存ではないか、という指摘もありました。記事作成から公開まで任せられるということは、AIツールの価格や仕様が変わったら運用フローが止まるということでもあります。AIなしでも最低限の更新ができる手順を残しておけるかどうか、という話ですね。

ちょっとした修正や全体の把握は？

誤字ひとつ直すのにも、指示を書いて、AIが対象を探して、差分を確認して、デプロイを待つという流れになるので、WordPressの「編集して更新」より遅くなるのはその通りでした。AIが頼んでいない箇所まで直すこともあるので、差分を確認する習慣も必要になります。

全体像については、記事一覧や下書きの状態を出すページをビルド時に自動で作るか、Gitベースの軽量なCMSを上に載せるのが現実的な対策とのことでした。

動的な機能は？

静的サイトでは、WordPressがサーバー側でやっていた処理がそのままでは動きません。サイト内検索、人気記事ランキング、関連記事、予約投稿などは別の仕組みで作り直す必要がありそう。AIがやってくれそうですが。

会員ページや予約、ECになると静的サイトの範囲を超えるので、外部サービスに任せるのが現実的な感じです。

移行するとき、データはちゃんと出せる？

WordPressは標準のエクスポート機能で記事を出せますが、きれいに出るのは本文やタイトル、カテゴリくらいです。ページビルダーで組んだページ、カスタムフィールド、SEOプラグインのメタ情報などは崩れたり抜けたりしがちなんですよね。クライアントのサイトでもよく見る話です。

Claudeが挙げた取り出し方は次の通りです。

• 記事データやSEOメタは、エクスポート用のプラグインやREST APIで構造化して取り出す

• データベースを直接見るのは、エクスポートで出てこないものを探しに行く最終手段

• ページビルダーのページは、ソースを取り出しても再現できないことが多いので、公開されている表示後のHTMLから中身を回収する

• 最後にサイトマップのURL一覧と突き合わせて抜けを確認する

逆に言うと、標準のエディタで書いてプラグインも最小限のサイトなら、移行はかなりスムーズです。Markdownにはタイトルや日付、descriptionなどの項目を持たせられるので、シンプルなカスタムフィールド程度なら素直に引っ越せます。カスタマイズを重ねたサイトほど、作った時点では便利でも、そのぶん将来の移行コストが積み上がっていくという感じですね。

技術面に関しては面倒なのかそうではないのか、ぐらいでここだけを見ると移行してもよさそう。

マーケ面の疑問

ここからは、制作の視点だけだと見落としやすい部分です。

タグ周りは？

Google タグマネージャー(以下、GTM)やGA4、Clarity、チャット、広告タグのように、ブラウザ側でJSを読み込むだけのものは問題なく動きます。共通のテンプレートにGTMを一度入れれば全ページに効くので、むしろシンプルです。

GTMがあればタグの追加や変更はAIを通さずGTMの管理画面でできるので、「全部AI経由で面倒」という問題の逃げ道にもなります。これはなるほどと思いました。

注意点としては、WordPressのプラグインがやっていたdataLayerへの送信（フォーム送信や購入など）を自前で書き直す必要があること、Cookie同意バナーをプラグインに頼っていた場合は置き換えが必要なこと、画面遷移を速くする仕組みを使うとpage_viewが送られないケースがあること、などが挙がりました。

タグを入れること自体は簡単ですが、dataLayerやCookie同意まわりはAIにお任せしづらい部分で、専門の人と調整しながらやらないと事故る可能性がありそうです。

フォームとCRM連携は？

ここが一番の山です。Contact Form 7のようなフォームはサーバー側でメールを送っているので、静的サイトでは動きません。選択肢は大きく3つです。

• 外部のフォームサービスを使う（手軽だけど、埋め込み方によっては完了の計測やデザインの統一で苦労する）

• HubSpotなどCRM/MAツールのフォームを使う（CRM連携が前提ならこれが素直）

• Cloudflare Workersで自作する（自由度は高いけど、迷惑送信対策や自動返信、データの保管を全部自分で持つことになり、Cloudflare依存も深まる）

CRMとの連携も、WordPressでは連携プラグインが裏でやっていたこと（フォームの内容をCRMに送る、UTMを隠しフィールドで渡すなど）をつなぎ直す必要があります。

広告計測は？

フォームを差し替えるとサンクスページのURLが変わるので、GA4のキーイベントの見直しが必要になります。広告のコンバージョン設定もURLで定義していれば作り直しです。個人的にはやりたくない(笑)。

Claudeからは、コンバージョンの定義や計測方法が大きく変わると、自動入札が新しいデータに適応するまで、一時的に広告の成果が不安定になる可能性があるとのこと。これまで蓄積してきたデータが全部消えるわけではありませんが、できれば触りたくない部分です。フォームのメールアドレスを使う拡張コンバージョンを入れている場合は、フォームの差し替えで動かなくなることもあります。

広告費をかけているところほど、ここはかなり慎重にやらないとまずいと思います。いい感じに学習してくれていたのに…となるので。

SEOと計測データは？

URLが変わるなら301リダイレクトの網羅、titleやdescription、構造化データの引き継ぎ、Search Consoleでの移行後の確認が必要です。あわせて新旧URLの対応表を残しておくと、GA4での前年比較やページ単位の推移を後から追いやすくなります。

制作会社に任せる場合は、このあたりを聞いてみると実力がわかりやすい、という話にもなりました。デザインや表示速度の話しかしないと、移行後に流入が落ちて原因がわからない、というパターンになりやすいからです。

個人的には、CMSを変更するだけならURLはできるだけ変えたくはないです。サイトの仕組みを変えることと、URLやサイト構造を整理することは、分けて考えたほうが安全だと思います。

最初からURLを維持するようAIに指示しておけばいいかもしれませんが、不安でしかないです。

法務面の疑問

フォームやタグの話を詰めていくと、法務の話にもつながってきます。以下はざっくりした整理なので、実際の判断は法務や専門家に確認する前提で読んでください。

• 外部のフォームサービスを使うと、個人情報の取り扱いを外部に委託する形になるので、プライバシーポリシーの記載の見直しが必要になることも←そこそこ面倒

• そのサービスが海外事業者なら、追加の説明が必要になることがある

• 電気通信事業法の外部送信規律の対象になる事業者なら、タグを追加・変更したときに公表内容の更新が必要

企業によっては法務レビューに数週間かかるので、移行スケジュールの最初に組み込んでおかないと、サイトはできたのに公開できない、ということになりかねません。サイトの引っ越しのつもりが、マーケや法務、営業をまたぐ案件になるわけです。

組織面の疑問

AIに詳しい人がいれば大丈夫？

社内にAIに詳しい人がいても、その人頼みの構成にすると、辞めた瞬間に誰も触れないサイトが残ります。

ここでClaudeが出してきた視点が良くて、WordPress＋保守契約も実は保守業者という「人」に依存している、と。それでも安心なのは、WordPressを扱える業者が世の中にたくさんいて、合わなくなっても乗り換えられるからです。Cloudflare×Claude Codeの構成は、今のところ引き継げる人が少ないので、差は技術ではなく代わりがいるかどうかなんですよね。

どちらの構成でも、サーバー、ドメイン、各種アカウントは自社名義で持っておくことが大事です。このあたりに関しては今までと変わらずですね。

更新の体制はどうなる？

担当者が書いて上長が確認してから公開、という承認フローがある会社は、WordPressの権限設定でやっていたことを別の形で再現する必要があります。採用ページは人事、お知らせは総務、のように複数の部署が更新しているサイトは特に影響が大きいです。

GitHubやCloudflare、Claude Codeのアカウントを誰が持つのか、AIにデプロイ権限までどこまで任せるのか、といった線引きも必要になります。保守契約も、WordPressのアップデート対応がなくなる代わりに何を保守範囲にするのか、AIツールの利用料をどちらが持つのかなど、作り直しになります。

じゃあ中小企業はどうする？

ここまで整理して、AIに詳しい人がいない中小企業は、従来型で保守契約をしっかり結ぶのが今のベストかな、という結論になりました。

今は移行期なので、先端を行く必要がなければ少し待つ方が手堅いと思います。先行者がハマった穴を後から避けられるのは、待つ側のメリットです。

とはいえ、待つ間に何もしないのはもったいないので、次のあたりはやっておくと、いざ移行するときの負担がかなり変わります。

• できるだけ標準機能の範囲でサイトを作っておく

• サーバー、ドメイン、アカウントを自社名義で整理しておく

• 担当者がAIに触れる機会を、本番サイト以外のところで作っておく

切り替えどきの目安は、地元の制作会社や保守業者が普通にこの構成を提案し始めたとき、というのがClaudeの意見でした。引き継げる人が増えたサインなので、そこから乗っても十分間に合う、という考え方ですね。

おわりに

元の投稿の「WordPressじゃないほうが運用が楽」は、技術がわかる人が自分のサイトを運用する場合にはその通りだと思います。一方でクライアントのサイトとなると、タグやフォーム、広告計測、法務、更新体制まで含めた話になって、楽になるかどうかは別問題でした。

AIで楽になるのは、まずAIを扱える側なんですよね。クライアントに何を勧めるかは、楽になるかどうかより、担当者が替わっても回り続けるかどうかで考えるのがいいかなと思っています。

間違っている点、見落としている点などあると思いますので、皆さんのご意見やご感想もコメントなどでお待ちしております。