デジマールは2026年11月6日、本コーポレートサイトをWordPressから「静的サイト＋Cloudflare」の構成に切り替えました。作業はClaude Codeと一緒に進め、着手から切り替えまでは約2週間でした。
移したのは、シラバス・用語集・お知らせなどの記事約630本、サービスのページ57件を含む900ページ超と、WordPress時代から引き継いだリダイレクトルール900行超。
移行後、大きく変わったのは更新までのスピード感です。今はサイトの更新もClaude Codeに任せていて、これまで制作会社に依頼して1週間ほどかかっていた修正が、社内で30分もあれば公開まで終わります。
この記事では、なぜWordPressをやめたのか、どんな手順で進めたのか、どこでつまずいたのか、AIに何を任せ、移行後の更新がどう変わったのかをまとめています。自社サイトの運用にあたり、次のような課題やお悩みをお持ちの方の参考になれば幸いです。
- PHPの脆弱性のニュースを見て、WordPressのままで大丈夫か不安
- Cloudflareが気になっているが、何ができるのかよく分からない
- AIを使って、自社でサイトを更新していきたい
- サイト修正に時間がかかり、自社の成長に合わせてスピード感を持って運用できていない
なぜWordPressをやめる判断に至ったのか
PHPとプラグインの更新に追われ続ける
WordPressはPHPというプログラムの上で動いています。サイトを安全に保つには、WordPress本体・テーマ・プラグイン、そしてサーバーのPHPまで、すべてを最新に保ち続ける必要があります。
しかし、こうした更新を確実に続けるのは簡単ではありません。当社でも、脆弱性やセキュリティリスクがWordPressサイトを運用するうえでのネックになっていて、もっと安心・安全にサイトを運用できる方法はないかと模索していました。
移行に着手した2026年10月下旬には、PHP本体に重大な脆弱性（通称「PHP2Shell」）が公表され、IPA（情報処理推進機構）も注意喚起を出しました。条件によっては、外部の第三者にサーバー上で任意のプログラムを実行されるおそれがあるというものです。この種の問題は、WordPressの管理画面でプラグインを更新しても防げません。サーバーのPHPを最新に更新する必要があります。自社サイトでレンタルサーバーを使っている場合、PHPの更新はサーバー会社の対応を待つしかなく、更新されるまでの間、不安にかられた方も多いのではないでしょうか。
プラグインの脆弱性も毎週のように公表されています。とはいえ、自社でWordPressの更新まで手が回る会社は多くありません。多くの場合、更新や修正は制作会社・保守会社に任せることになり、次のような状態になりがちです。
- 更新のたびに、保守費や作業費がかかる
- 文言を1か所直したいだけでも、依頼・見積もり・確認のやりとりで公開まで1週間ほどかかる
- 急ぎの修正ほど、制作会社のリソースに合わせて待つしかない
サイトを安全に保つためにも、日々の小さな修正のためにも、時間とお金がかかり続ける。これがWordPressを使い続けるうえで大きなネックになります。
静的サイトなら「攻撃される場所」がそもそもない
静的サイトは、あらかじめ全ページをHTMLファイルとして作っておき、それをそのまま配信する仕組みです。アクセスのたびにサーバーでプログラムを動かすことも、データベースに問い合わせることもありません。
| WordPress | 静的サイト | |
|---|---|---|
| ページの表示 | アクセスのたびにPHPがページを組み立てる | 作っておいたHTMLを配るだけ |
| データベース | 必要 | 不要 |
| 管理画面（ログインページ） | 公開されている | ない |
| 守る対象 | 本体・テーマ・プラグイン・PHP・サーバー | 配信サービスの設定 |
PHPもデータベースも管理画面もないので、それらを狙った攻撃は成り立ちません。「更新し続けて守る」から「守る対象を減らす」への発想の転換です。
サイト運用コストを将来的に下げたい
もう一つの理由は、サイトの運用にかかる費用です。WordPressで構築されたサイトを運用すると、サーバーの費用に加えて、更新や修正の費用が毎年かかります。
静的サイトなら、配信はCloudflareの無料プランの範囲に収まり、修正も社内でClaude Codeに頼めば済みます。まだ、メール利用でレンタルサーバーの契約を続けているため、劇的にサイト運用コストが下がったわけではありませんが、更新の手間や外注の費用を含めると、運用コストは将来的に下がっていくと見込んでいます。
静的サイト（Astro）＋Cloudflareを選んだ理由
Astro：AIで更新しやすく、型で記事を作れる
サイトを作る仕組みには「Astro（アストロ）」を選びました。Astroは、静的サイトを作るためのWebフレームワークです。ページの「型」と「中身」を組み合わせて、完成したページを一度に作ってくれます。クリーンなHTMLが作られるため、Googleなどの検索エンジンやAIクローラーに評価されやすいと言われています。
Astroを選んだ理由は、次の2つです。
1. 設計思想がAIでの更新と相性が良い
Astroは、サイトを「部品」と「型」に分けて組み立てる、という考え方で作られています。ヘッダーやフッター、問い合わせ欄などは部品として1か所にまとめ、記事は種類ごとの型に原稿を流し込んでページにします。AIに更新を任せるうえで、この考え方がマッチしていました。
- 直す場所が1か所で済む：同じものがあちこちのページにコピーされていないので、Claude Codeは部品や型を1か所直すだけで済みます。変更が小さく済むため、他のページへの影響も小さくなります
- 間違いを公開前に止められる：記事の型には「タイトルと公開日は必ず書く」「画像は実在するファイルを指す」といった決まりを持たせられます。AIが書き漏らしや書き間違いをすると、サイトを組み立てる段階でエラーになり、公開されません
- AIが得意な書き方でできている：独自の仕組みが少なく、HTML・CSS・Markdownといった広く使われている書き方がほぼそのまま使われています。AIが学習している書き方に近いため、意図どおりのコードを書いてもらいやすくなります
2. 投稿ページを、型を使って誰でも作れる
WordPressをやめるときに一番悩んだのが、お知らせやコラムなどの投稿ページを、これからどう管理し、どう作っていくかでした。運用にコストがかからず、担当者が変わっても誰でも作れることが条件です。
Astroには、上で説明した「型」の考え方があります。記事は、タイトルや公開日などを書いた原稿のファイル（Markdown）を用意するだけで、あとは型に流し込まれてページになります。記事が増えてもサイトのソースが煩雑にならず、WordPressの投稿の仕組みを、そのまま静的なサイトに置き換えやすいと思いました。
実際に、WordPressの記事の本文（HTML）もそのまま入れられたため、約630本の記事は書き直さずに移行できています。今後は、WordPress時代の古い作りを見直し、よりAstroに合った形でコーディングし直していくことを考えています。
Cloudflare：配信・DNS・SSLを1か所で、無料で
Cloudflare（クラウドフレア）とは、Webサイトを速く・安全に届けるための仕組みを提供しているアメリカ発のグローバル・ネットワークプラットフォームです。サイトの配信、ドメインの住所録（DNS）の管理、不正なアクセスからの防御などをまとめて提供していて、世界中の多くのWebサイトで使われています。
完成したサイトの公開先には、このCloudflareを選びました。ここで「レンタルサーバーを借りなくていいの？」と思われた方もいるかもしれません。
WordPressにレンタルサーバーが必要なのは、アクセスのたびにPHPというプログラムを動かしてページを組み立て、データベースから記事を読み出す必要があるからです。
静的サイトは、ページがすべて出来上がった状態で用意されています。そのため、サイトを公開するために必要なのは、完成したファイルを預けておき、ブラウザでサイトに訪れたユーザーにファイルを届ける仕組みだけです。
Cloudflareは、世界中にデータの配送拠点を持っています。その仕組みの一つ「Cloudflare Workers」に完成したサイトのファイルを渡すと、サイトに訪れたユーザーのいちばん近くの拠点から届けてくれます。そのため、サイトのためにレンタルサーバーを借りる必要はありません。
ファイルを預けてサイトを公開できるサービスはほかにもありますが、当社がCloudflareを選んだのは、次の5つの理由からです。
- セキュリティが強固：大量のアクセスでサイトを止めようとする攻撃（DDoS攻撃）への防御が、無料プランでも標準で付いています。さらに、Cloudflareから配信されるのは完成したファイルだけで、PHPやデータベースは動いていません。冒頭で触れたPHPの脆弱性のような、サーバーのプログラムを狙った攻撃の入口そのものがありません
- サイトの応答速度が速い：世界中の拠点から配信しているため、サイトに訪れたユーザーのいちばん近くからページが届きます。当社のサイトでは、日本からのアクセスは東京の拠点から返り、応答が始まるまでの時間は、約0.05秒になりました
- DNS（ドメインの住所録）もまとめて管理：サイトの行き先・リダイレクト・SSL証明書（鍵マーク）を同じ画面で管理できます。SSL証明書の更新も自動です。
- GitHubとつながる：変更をGitHub（変更履歴を管理するサービス）に送ると、自動でビルド（HTMLの作成）と公開が行われます
- 無料プランで事足りる：当社の規模では、ビルドの時間（月3,000分）もリダイレクトルールの上限も無料プランの範囲に収まっています
なお、メールは以前と同じレンタルサーバー（Xserver）のまま残しています。サイトとメールを別々の場所に置けるのも、DNSをCloudflareで管理するメリットです。
このサイト構成を実現するために必要なもの
当社の構成（静的サイト＋Cloudflare＋Claude Code）で移行・運用するために用意したものです。
アカウント・契約
| 必要なもの | 何に使うか | 費用 |
|---|---|---|
| ドメイン（今のもの） | サイトの住所。ドメインの管理画面で「ネームサーバー」を変えられる権限が必要 | 今のまま |
| Cloudflare | サイトの配信、DNS（ドメインの住所録）、SSL証明書、リダイレクト | 無料プランで運用中 |
| GitHub | サイトのデータと変更の記録を置く場所 | 無料プランで運用中 |
| Claude Code | サイトの移行・修正・記事の追加 | Claudeの有料プラン |
| フォーム・計測などの外部ツール | 問い合わせフォーム（当社はHubSpot）、アクセス解析（Googleタグマネージャー・GA4）、Google Search Console など | 各ツールによる |
パソコンに入れるもの
作業する人のパソコン（MacでもWindowsでも可）に、次のツールを導入します。
- Claudeのデスクトップアプリ：チャットでClaude Codeに依頼する
- Git：変更を記録し、GitHubとやりとりする
- Node.js：サイトを組み立てる（ビルドする）
- GitHub CLI：Claude CodeがGitHubで確認・公開の手続きをする
入れ方が分からなくても、手順はClaude Codeに聞けば教えてくれます。当社では、別のパソコンで作業を始めるときの手順書もClaude Codeに作ってもらいました。
今のサイトの素材と情報
- WordPressの記事・固定ページの中身と画像
- テーマのCSS・画像・フォントなどのデザイン素材
- リダイレクトの設定（Redirectionなどのプラグイン）
- DNSの設定の一覧（ドメインやサーバーの管理画面から確認）
- フォーム・計測タグの埋め込みコード
WordPressからの移行の流れ
全体は次の6段階で進めました。
| 段階 | やること | 期間の目安 |
|---|---|---|
| ① 棚卸し | 今のサイトの全ページ・リダイレクト・フォーム・計測タグ・サブドメインを一覧にする | 最初の数日 |
| ② 移行 | デザイン・共通部品・記事・画像を新しい仕組みに移す | 約1週間 |
| ③ リダイレクト | URLを変える・なくすページのリダイレクトを書き、全行を確かめる | ②と並行 |
| ④ 確かめる | 全ページをPC・スマホで表示し、崩れ・リンク切れ・フォームを確認 | ②と並行 |
| ⑤ 切り替え | DNSを移し、digimarl.comを新サイトに向ける | 当日2〜3時間 |
| ⑥ 公開後 | 検索エンジンへの登録し直し、速度の測定、後片付け | 1週間ほど |
① 棚卸し：見えていないものまで洗い出す
最初に、今のサイトにあるものを全部書き出しました。ページの一覧だけでなく、次のような「普段は目に入らないもの」をどう扱うかを決めておくことが重要です。
- .htaccessのほか、WordPressのプラグイン（Redirection）に登録されていたリダイレクトをどうするか
- 移行後のお問い合わせフォーム（当社はHubSpot）と、計測タグ（Googleタグマネージャー）の管理方法
- 使用していない・機能していないページの見直し
- DNSに登録されていた、サブドメインの棚卸し
- WordPress固有の設定やページの作り直し
一覧はスプレッドシートにまとめ、「移す」「リダイレクトする」「やめる」を1行ずつ決めました。使っていないテスト環境の削除や、LPをリダイレクトにするかどうかは、代表に判断してもらいました。
② 移行：見た目は変えず、中身を移行する
デザインは変えず、今の見た目のまま移すことを優先しました。リニューアルと移行を同時にやると、問題が起きたときに原因を切り分けにくくなるためです。デザインの見直しは、移行がひと段落してから検討する想定です。
③ リダイレクト：URLは1本も変えない
検索順位を落とさないため、URLはWordPress時代と同じにしました。WordPressでリダイレクトされていたURLや、ページをなくすURLは、Cloudflareのリダイレクトルール（_redirects というファイル）に書き写しています。
④ 確かめる：人とAIの両方で
ブランチごとにCloudflareが「確認用URL」を自動で発行してくれるので、本番に出す前にPC・スマホで見て確認できます。全ページの表示の比較や、リダイレクトの全行チェックは、後で紹介するようにAIに任せました。
⑤ 切り替え：止めない・戻せるを最優先に
切り替えは、DNSの管理先をレンタルサーバーからCloudflareに切り替えたうえで、digimarl.comの行き先だけを新サイトに変える、という2段階で行いました。詳しくは次の「つまずいたポイント」で触れます。
⑥ 公開後：検索エンジンと速度の確認
切り替え後は、Google Search Console・Bing Webmaster Toolsへのサイトマップの登録し直し、404（ページが見つからない）が増えていないかの確認、表示速度の測定などを行っています。
実際につまずいたポイント
1. 「サイトが落ちる時間」をゼロにする2段階の切り替え
いきなり行き先を新サイトに変えると、DNSの切り替えと新サイトへの接続が同時に起き、問題が起きたときに原因がわかりません。そこで次の順に分けました。
- DNSの管理先をCloudflareに切り替える（この時点ではまだWordPressを表示）
- メール・サブドメインが動いていることを確かめる
- digimarl.comの行き先だけを新サイトに変える
これで、利用者から見てサイトが落ちる時間はほぼありませんでした。
2. リダイレクトルールの「見えない上限」
Cloudflareのリダイレクトルールは、「*」を使う動的なルールが100行まで、静的なルールが2,000行までです。ここで落とし穴がありました。Cloudflareは「*」の行が出てきた以降の行を、すべて動的として数えるのです。
途中に「*」の行があったため上限を超え、確認用URLの公開が失敗しました。しかも、手元でのビルドや事前のチェックでは見つかりません。今は「*」を使う行は必ずファイルのいちばん下に書く、というルールにしています。
3. 何か問題が発生した際に、「元に戻す手順」を先に作っておく
切り替えの前に、何かあったときに元に戻す手順（ロールバック）を書いておきました。
- WordPressは消さずに残す（DNSを戻すだけで、数分でWordPressに戻せるようにしておくため）
- 戻すかどうかの基準を決めておく（トップが表示されない、フォームが使えない、メールが届かない、原因が30分以内にわからない、など）
さらに、WordPress側のSSL証明書の期限もメモしておきました。切り替え後はWordPress側の証明書が自動更新されなくなるため、期限を過ぎてから戻すと「安全でないサイト」と表示されてしまいます。「いつまでなら簡単に戻せるか」を把握しておくと、落ち着いて判断できます。
AIベースでサイトを更新・運用する体制について
今回の移行は、AIのClaude Codeと一緒に進めました。私はクリエイティブディレクターですが、コードの多くはAIが書き、私は「何をするか決める」「結果を確かめる」役に回っています。
AIに任せたこと（一例）
- WordPressの記事約630本を、新しい仕組みの記事ファイルに変換する
- リダイレクトルール900行超を、1行ずつ「1回のリダイレクトで行き先に着くか」自動で確かめる
- DNSの56行を、レンタルサーバー側とCloudflare側で照らし合わせる
- デザインの修正前後で、全ページの全要素の見た目に差がないかを比べる
- 切り替えの手順書・元に戻す手順書・運用ガイドを書く
人がやると数日かかる確認作業を、漏れなく、何度でもやり直せるのがAIの強みです。
「AIが作業し、人が承認して公開する」ルール
一方で、AIに何でも任せるのは危険です。サイトは会社の顔ですし、DNSやメールの設定を間違えれば業務が止まります。そして、設定ファイルやパスワードなどの秘密の情報を、AIが意図せず読み込んだり漏洩したりするリスクもあります。そこで、AIが必ず守るルールを「CLAUDE.md（クロード・エムディー）」というファイルに書いて、サイトのデータと同じ場所に置きました。CLAUDE.mdは、Claude Codeが作業を始めるたびに自動で読み込む「作業ルールの説明書」です。Claude Codeは毎回これを読んだうえで作業します。当社のCLAUDE.mdには、たとえば次の手順を書いています。
- 作業ごとに作業用のブランチ（枝分かれ）を作る。本番に直接書き込まない
- 手元で直して、PC・スマホの表示を人に見せる
- GitHubに送る前に、変更内容を説明して人の「OK」をもらう
- 確認用URLで人がチェックする
- 人が承認してから本番に反映する（反映すると数分で公開される）
ほかにも「専門用語には説明を添える」「DNSやサーバーの設定は相談なしに変えない」「パスワードなどの秘密の情報は読まない・書かない」といった決まりを入れています。
決めたことをAIに覚えさせる
運用で一番効いているのが、「決めたこと・つまずいたことを、CLAUDE.mdに書き足していく」習慣です。たとえば「リダイレクトの『*』の行はいちばん下に書く」「写真は長い辺2,400px以下に縮小してから入れる（大きすぎる写真でビルドが失敗したことがある）」といった内容です。
一度つまずいたことは、次からAIが自分で避けてくれます。CLAUDE.mdはサイトのデータと一緒にGitHubで共有しているので、担当者が変わっても、別のPCで作業しても、同じルールの中でサイト運用が可能です。
制作会社に頼んで1週間かかる修正が、社内30分で完結
移行して1番良かったことは、修正が公開されるまでの速さです。
移行する前は、文言の修正やバナーの差し替えでも、制作会社に依頼して見積もり・作業・確認のやりとりを経るため、公開まで1週間ほどかかっていました。今は、担当者がAIに「このページのこの部分をこう直して」と日本語で伝えると、AIが直して手元で表示を見せてくれます。確認用URLで確かめて承認すれば、30分もあれば本番に反映されます。
| 移行前（WordPress・制作会社に依頼） | 移行後（AIに依頼・社内で承認） | |
|---|---|---|
| 依頼のしかた | メールで依頼し、見積もり・日程を調整 | Claude Codeにチャットで伝える |
| 確認 | 制作会社から確認用の画面が届くのを待つ | Claude Codeが作ってくれる確認用URLを見る |
| 公開まで | 1週間ほど（内容による） | 30分ほど |
| 費用 | 修正のたびに依頼費用、定額の保守運用費用 | 社内の作業時間のみ |
修正が早くなると、サイト改善の仕組みそのものが変わります。「広告の訴求に合わせて、今日中にページの文言を変える」「問い合わせの多い質問を、その日のうちによくある質問に足す」といったことに、自社の事業成長に合わせて、スピード感を持って対応できるようになりました。サイトを「年に一度リニューアルするもの」から「毎日少しずつ良くしていくもの」に変えられるのが、AI＋静的化でサイト運用する一番のメリットだと感じています。
WordPressの投稿画面がなくなって、記事の更新はどうしているのか
WordPressをやめるときに、多くの方が一番気になるのがここだと思います。WordPressにおける公開までの流れは、ブラウザで管理画面にログインし、「投稿画面」でお知らせやコラムを書いて、「公開」ボタンを押すだけでした。静的サイトにすると、この投稿画面はありません。
では、当社はお知らせ・コラム・用語集・採用情報などの記事を、移行後にどのように更新しているのか。実際の運用をご紹介します。
記事は「型」「テンプレートファイル」「原稿ファイル」で管理するようになった
WordPressでは、投稿画面に入力した内容がデータベースに保存されていました。移行後は、Astroの説明で触れた「型」と「中身」の組み合わせで記事を管理しています。
- 型：お知らせ・コラム・用語集など、記事の種類ごとに1つずつあるページのひな形。見出しの位置やデザイン、一覧への並び方を決めています
- テンプレートファイル：記事の種類ごとに1つずつ用意した、原稿ファイルの書き方の見本。どこに何を書くかの説明が付いています
- 原稿ファイル：記事ごとに1つ作るテキストファイル。テンプレートファイルをもとに、タイトル・公開日・カテゴリと本文を書きます
新しい記事を出すときに用意するのは、原稿ファイルだけです。原稿ファイルを種類ごとのフォルダに置くと、その種類の型に流し込まれて記事のページが出来上がります。
原稿ファイルの中身は、上の部分にタイトル・公開日・カテゴリなどの「記事の情報」、下の部分に本文、という作りです。たとえば、お知らせのファイルは次のようになります。
---
title: "新サービス提供開始のお知らせ"
date: 2026-11-20
categories: ["プレスリリース"]
---
本文をここに書きます。
## 見出し
- 箇条書き本文はMarkdown（マークダウン）という書き方で、「##」で見出し、「-」で箇条書き、のように記号で書きます。WordPressの投稿画面で見出しや太字のボタンを押していた操作を、記号で書くイメージです。
ただ、実際にはこの原稿ファイルを人が直接書くことはほとんどありません。書くのはClaude Codeです。
投稿画面で更新していたページと、移行後の運用
当社のサイトで、WordPressの投稿画面から更新していたのは次のページです。移行後は、どのページもテンプレートファイルをもとに原稿ファイルを作るだけで、Claude Codeに頼み、確認用URLで確かめて公開する、という同じ流れで更新しています。ページごとの違いは次のとおりです。
| ページ（カテゴリ） | 移行後の運用 |
|---|---|
| お知らせ | テンプレートファイルをもとに、Claude Codeがページを作成。一覧・トップページの新着に自動で並ぶ |
| シラバス（コラム） | テンプレートファイルをもとに、Claude Codeがページを作成。カテゴリ別の一覧・関連記事に自動で並ぶ。内容が古くなった記事は、冒頭に「〇年〇月の追記」を入れて更新日を変える |
| サービスページのコラム | テンプレートファイルをもとに、Claude Codeがページを作成。サービスごとのフォルダに置くと、そのサービスのページの「関連記事」に自動で並ぶ |
| 用語集 | テンプレートファイルをもとに、Claude Codeがページを作成。用語集の一覧に自動で並ぶ |
| 実績紹介・プロジェクトストーリー | テンプレートファイルをもとに、Claude Codeがページを作成。決まった項目を埋めると、ページのデザインに流し込まれる |
| 採用情報（求人） | テンプレートファイルをもとに、Claude Codeがページを作成。募集を終えるときは、その原稿ファイルを消すだけで一覧からも消える |
お知らせを1本公開するまでの流れ
たとえば、お知らせを1本追加するときは、次のように進みます。
- Claude Codeに原稿を渡す：WordやGoogleドキュメントの原稿、画像を渡して「この原稿をお知らせとして追加して。公開日は11月20日、カテゴリはプレスリリース」と日本語で伝えます
- Claude Codeが記事のファイルを作る：記事の種類ごとのテンプレートファイルをもとに、原稿ファイルを作ります。原稿に書かれていない情報（公開日やカテゴリなど）は、推測で埋めずに質問してくれます
- 手元で表示を確かめる：Claude Codeが自分のパソコンの中でサイトを表示して見せてくれます。「この見出しを短く」「画像をもう少し上に」と日本語で伝えれば、その場で直ります
- 確認用URLで見る：OKを出すと、Claude CodeがGitHubに差分（変更した内容）を送り、数分で確認用URLができます。スマホでも確認でき、社内の人にURLを送って見てもらうこともできます
- 承認して公開：問題なければ承認します。数分で本番のサイトに公開されます
また、お知らせの一覧ページ・トップページの新着・サイトマップ（検索エンジン向けの一覧）は、記事のファイルから自動で作られます。一覧に手動で足していく作業は必要ありません。WordPressを使っていた時と同じ要領で修正作業ができます。
共有・履歴・複数人での更新は、どうなったか
上の流れでは触れていない、WordPressの便利な機能が移行後どうなったかも補足しておきます。
| WordPressでの作業 | 移行後のやり方 |
|---|---|
| 下書き・プレビューを社内で共有する | 確認用URLを送れば、社内の誰でもパソコン・スマホで見られる |
| 過去の版に戻す | すべての変更がGitHubに残っていて、いつでも前の状態に戻せる |
| 複数人で同時に更新する | 人ごとに作業用のブランチを分けるので、同時に作業しても上書きし合わない |
| 誰がいつ何を変えたかの記録 | 変更のたびに、誰が・いつ・何を変えたかがGitHubに自動で記録される |
投稿画面がないことの、良い点と注意点
良い点は、記事の追加とページの改修が同じ流れになったことです。WordPressでは「お知らせは投稿画面で自分たちで」「コーディングしなければならない修正は制作会社に依頼」と分かれていましたが、今はどちらもClaude Codeに日本語で頼むだけです。
注意点もあります。最初に、GitHubのアカウントとClaude Codeを使える環境を用意する必要があります。また、毎日たくさんの記事を出す、何十人もの担当者がブラウザだけで書きたい、といった場合は、記事の管理だけ専用の管理画面（CMS）を残す構成のほうが合うこともあります。自社の運用体制と相談しながら、最適なやり方を検討する必要があります。
移行してみてどうなったか
| 移行前（WordPress） | 移行後（静的サイト＋Cloudflare） | |
|---|---|---|
| セキュリティチェック | 本体・プラグイン・PHPの更新を確認し、更新を続ける | PHP・データベース・管理画面などの攻撃対象がないため、脆弱性のたびに更新や確認に追われることがない。さらにCloudflareの、大量のアクセスでサイトを止める攻撃（DDoS攻撃）への防御が標準で付いている |
| 応答の速さ（応答開始） | 約0.06秒 | 約0.05秒（東京の拠点から配信） |
| 更新のしかた | 制作会社に依頼、または自社リソースで対応 | AIに依頼 → 確認用URLで確認 → 承認して公開 |
| 修正が公開されるまで | 1週間ほど（内容による） | 30分ほど |
| 変更の記録 | 誰がいつ何を変えたかを追いにくい | すべての変更がGitHubに残り、1クリックで戻せる |
サイトを維持するためにかかる費用も、次のように変わりました。
| 費用の項目 | 移行前（WordPress） | 移行後（静的サイト＋Cloudflare） |
|---|---|---|
| 保守運用費 | 制作会社・保守会社に、本体・プラグインの更新や不具合対応を依頼 | 不要（更新するソフトがない。日々の運用はClaude Codeで完結） |
| 修正の依頼費 | 修正のたびに制作会社へ依頼 | 不要（社内の作業時間のみ） |
| サーバー | レンタルサーバー（WordPressを動かすため） | サイトの配信はCloudflareの無料プラン。メールのためにレンタルサーバーの契約は続けている |
| ドメイン | 年1回の更新費 | 変わらず（年1回の更新費） |
| SSL証明書（鍵マーク） | レンタルサーバーの無料SSL | Cloudflareが自動で発行・更新（無料） |
| 有料プラグイン・テーマ | 機能を足すたびに購入・更新費 | 不要（WordPressのプラグインの仕組みがない） |
| 新しくかかる費用 | ― | Claude Codeの利用料 |
一番大きかったのは、修正のスピードです。1週間待つのが当たり前だった修正が30分で終わるので、気づいたその日に直せます。作業そのものも楽になりました。あわせて、「更新を止めると危ない」という不安もなくなりました。
移行はゴールではなく、運用を良くしていくためのスタートだと感じています。
静的サイトに移行するときの注意点
昨今のPHPやWordPressのセキュリティ問題を受けて、静的サイトへの移行を検討している企業も多いと思います。しかし、静的サイト化はどのような企業にもマッチするわけではありません。移行を決める前に、次の点を確かめておくとよいでしょう。
1. 動的な機能は、そのままでは作れない
静的サイトは、Cloudflareのような配信サービスから「あらかじめ作っておいたページを配るだけ」の仕組みです。見る人によってページの中身が変わる機能や、サーバーにデータを保存する機能は作れません。
- 会員登録・ログイン・マイページ
- ECサイトのカート・決済
- 予約システム
- サイト内検索
- 記事へのコメント欄
こうした機能が必要な場合は、外部のサービスを組み合わせるか、その部分だけ別のシステムで作る必要があります。ログインして使う機能がサイトの中心にあるなら、静的サイトへの移行は向いていません。
2. フォームは外部ツールになる
WordPressでよく使われる「Contact Form 7」のように、サーバーのPHPでメールを送るフォームは使えません。問い合わせフォームや資料請求は、HubSpot・Googleフォームなどの外部ツールを埋め込む形になります。
当社はもともとHubSpotのフォームを使っていたため、埋め込みのコードをそのまま移せました。
3. プラグインが対応していたことは、自前で代替機能を用意する必要がある
WordPressでは、プラグインを入れるだけで済んでいた機能があります。静的サイトでは、それぞれ自前で用意する必要があります（Claude Codeに作ってもらうのもよいと思います）。
- 検索エンジン向けの設定（ページごとのタイトル・説明文、サイトマップ、構造化データ）
- リダイレクトの設定
- RSS（記事の更新情報の配信。WordPressは自動で作っていた）
4. 公開までに数分かかる・無料プランの上限がある
静的サイトは、全ページをあらかじめ作っておいて配る仕組みのため、変更を公開するたびに全ページを作り直します（ビルド）。そのため、WordPressのように「公開」ボタンを押してすぐ反映されるのではなく、反映まで数分かかります。Cloudflareの無料プランでは、ビルドの時間が月3,000分まで・同時に1つまで、リダイレクトルールにも行数の上限があります。当社の規模では問題ありませんが、ページ数や更新の回数が多いサイトは、どのプランが適しているか事前に確かめておくとよいでしょう。
5. サーバーで動いていたものは移せない
同じレンタルサーバーで、ほかのWordPressやPHPのシステム（テスト環境、別のサイトなど）を動かしている場合、それらは静的サイトには移せません。当社もメールとサブドメインのために、レンタルサーバーの契約を続けています。
6. AIの作業は、必ず人が確かめる
Claude Codeは確認作業まで手伝ってくれますが、間違えることもあります。本番に反映する前に、必ず人が表示を確かめて承認するルールにしてください。
まとめ：WordPressからの移行を考えている方へ
WordPressから静的サイト＋Cloudflareに移り、更新をClaude Codeに任せたことで、サイトは「守り続けるもの」から「自社の成長に合わせてスピード感を持って改善できるもの」に変わりました。脱WordPress・静的サイトへの移行を考えている方に向けて、この記事のポイントをまとめます。
- セキュリティリスクと維持費を減らせる：PHP・データベース・管理画面などの攻撃対象がなくなり、CloudflareのDDoS攻撃への防御も標準で付きます。脆弱性への対応や保守の費用にも追われにくくなります。
- 自社サイトが静的運用に向いているかを先に確かめておく：ログイン・カート・予約などの動的な機能が中心のサイトには向きません。フォームはHubSpotなどの外部ツールになります
- 切り替えは「止めない・戻せる」を最優先に：2段階で切り替え、元に戻す手順と期限を先に決めておきます
- AIに任せるときは、ルールを決めて人が承認する：守ってほしい手順や決めたことはCLAUDE.mdに書き、本番への反映は必ず人が確かめてから行います
- 投稿画面がなくても、手触りよくスムーズに更新できる：原稿をClaude Codeにチャットで渡せば、原稿ファイル作りから一覧への反映まで進みます。ただし、自社の更新の量や体制に合うかは検討が必要です
- 修正〜公開にかかる時間を大幅に短縮できる：制作会社に頼んで1週間ほど待っていた修正が、社内30分で完結します。自社の事業成長に合わせてサイトを改善できるのが、一番のメリットです
デジマールでは、今回の経験をもとに、WordPressからの移行、コーポレートサイトの作り直し、公開後にClaude Codeで更新・運用していく体制づくりをご支援しています。「自社のサイトでも移行できるか知りたい」「AIでの運用が自社に合うか相談したい」という段階でも、お気軽にご相談ください。
WordPressからの移行・サイトの作り直しをご検討中ですか？
デジマールは、これまで多くのWebサイト・LPの制作・運用を支援してきました。その経験に、自社サイトの移行で得た知見を加えて、WordPressからの移行やサイトの作り直し、公開後の運用体制づくりまでサポートしています。お気軽にご相談ください。
著者情報
