先日のブログで「脱WordPress計画」を宣言しました。
計画の中身は、
- 現WordPressサイトを静的HTML化
- Cloudflare Pages に移管
- Astro でラップして保守性UP
- Pages CMS で管理画面を接続
という流れでした。
今回はその進捗報告です。
全部まとめて進めようとすると大仕事ですが、優先順位を考えると
「とにかく早くPHPから離脱したい」 というのが最初のゴール。
そこで、Astro と Pages CMS はいったん脇に置き、
まずは今動いている静的HTMLをそのままCloudflareに乗せ替えるところから 始めました。
対象は、弊社運営の植え替えサービス「Green Re:pot(グリーン・リポット)」
もともとXサーバー上のWordPressで運用していましたが、丸ごとCloudflare Pagesに移管しました。
そもそも移管する予定ではあったのですが、WAF設定でCloudflareを利用していたところ、今回の騒動を受けてXサーバーが側から管理画面のアクセスを拒否される事態となり、急いで対処する必要が出て来たのです。
作業時間は1日。現状リスクは大幅に回避できました。
まずはこれだけやりました(第一弾)
| 項目 | Before | After |
|---|---|---|
| ホスティング | Xserver | Cloudflare Pages |
| サイト構成 | WordPress(PHP + MySQL) | 静的HTML |
| フォーム送信 | Formspree(外部サービスを利用) | 自作Worker + Resend |
PHPも、DBも、サーバーメンテも、ここでいったんお別れです。
Astroでのラップや Pages CMS 接続は後日やりますが、
この時点ですでに、現状の脆弱性リスクは軽減されました。
構成図
ざっくり、こうなっています。
【訪問者】↓
【Cloudflare Pages】← 静的HTMLをCDN配信(爆速)↓
お問い合わせフォームからPOST
【Cloudflare Workers】← フォーム受付エンドポイント(自作)
├─ D1(送信履歴保存)
└─ Resend API ─→ 【info@ibe-design.co.jp】
WordPressのように「アクセスごとにPHPが動く」構成ではなく、
事前に生成した静的HTMLをCDN配信するだけです。
フォーム送信、どうする問題
静的HTMLに移行するとき、必ず引っかかるのが「お問い合わせフォーム」です。
WordPressなら Contact Form 7 で済みますが、静的サイトはサーバーサイドで処理ができません。
選択肢は大きく2つ。
- A. 既製の外部フォームサービスを使う(Formspree、Basin、Netlify Forms など)
- B. 自分でフォーム受付の仕組みを作る(Cloudflare Workers などで実装)
最初は「とりあえず早く動かしたい」と思って、A の Formspree で設定してみました。
HTMLのformタグに action URLを書けば完了、5分で終わる手軽さです。
Green Re:pot でも実際に動作確認し、「ちゃんとメール届くね」まで到達しました。
だけど、気になることが出てきた
Formspree は便利ですが、使い込むほどに気になる点がぽつぽつと浮かんできました。
- 無料枠の月間送信数は50通まで。問い合わせが増えると有料プランへ
- 送信データは Formspree 側に保管され、自分で履歴管理ができない
- 複数サイト運営だと、サイトごとに契約・設定が必要
- カスタムロジック(返信先の自動設定、サイト別の振り分け)が入れにくい
- 外部サービス依存が1つ増える
そして何より、
今後 ibe-design.co.jp 本体や他のプロジェクトでも同じようにフォームが必要になる
という事情がありました。
サイトごとに別契約するより、1つの基盤で全部のフォームを捌けたほうが運用がラク です。
ちょうど Cloudflare Workers を触る構成に移行するところだったので、
「どうせ Workers 動かすなら、ついでにフォーム送信の仕組みも作っちゃうか」
——という流れで、自作に踏み切ることにしました。
自作フォーム基盤「Contact Platform」を作りました
PJ上のネーミングは「Contact Platform」としました。
特徴は以下となります。
- Cloudflare Workers で動く軽量な受付エンドポイント
- Cloudflare D1(SQLiteデータベース)で送信履歴を全件保存
- Resend を経由してメール通知
- フォームIDごとに送信元・通知先・CORSを設定できる マルチサイト対応
- 送信元ドメインは `noreply@mail.ibe-design.jp`(SPF/DKIM/DMARC認証済み)
- Cloudflare Turnstile によるスパム対策を後付けで有効化可能
今回は Green Re:pot 用に設定を1件追加しましたが、
将来 ibe-design.co.jp 本体サイトも同じWorkerで捌けます。
1つのプラットフォームで、複数サイトのフォームを管理する 設計です。
結果、Formspree 時代の「月50通まで」の制約から解放され、
月間送信件数は実質無制限(Resend無料枠3,000通/月まで)になりました。
やってみて感じたこと
よかった点
- 想像以上に早く終わった(丸1日)
- 静的サイト特有の爆速な表示体験
- セキュリティに悩まなくていい開放感
- Cloudflare のツール群が、思っていた以上に成熟していた
工夫が必要だった点
- Resend のドメイン認証(SPF/DKIM)はCloudflareのAuto configureで一瞬で解決
- 送信元ドメインの設計(サブドメイン運用のベストプラクティス)
- Reply-To を自動設定する細かいロジック
細かいハマりポイントはありましたが、どれも1〜2時間で解決できる範囲でした。
WordPressで年に数回起きる脆弱性対応のストレスを思えば、比較になりません。
これからやること(第二弾以降)
今日は「脱WordPress計画」の 第一弾 まで。
Astro と Pages CMS は、翌日以降に第二弾・第三弾として進めていきます。
第二弾:Astroでラップ(翌日実施予定)
現状は素の静的HTMLなので、ヘッダー・フッター修正が各ページ横断の作業になります。
Astroでコンポーネント化することで、
- 共通パーツは1箇所修正で全ページに反映
- ブログ記事はMarkdownで管理(1記事5分で追加可能)
- 一覧ページ・サイドバー・関連記事を自動生成
という状態にします。
第三弾:Pages CMS 導入(別日)
Astro化が終わったら、Pages CMS という管理画面ツールをつなぎます。
WordPressの管理画面と同じ感覚で、ブラウザから記事編集ができるようになります。
Markdown も Git も意識せず、「公開」ボタンだけで本番反映。
第四弾:本体サイト(ibe-design.co.jp)の移管
そしてこの計画の 最終的なゴールは、弊社本体サイト([ibe-design.co.jp](https://ibe-design.co.jp/))の移管 です。
本体は Google Workspace でメール運用もしているので、いきなり大本に手を入れるのは怖い。
そこで、まずは影響範囲の小さい Green Re:pot(グリーン・リポット) で検証を兼ねて移管を進めることにしました。
対象は、弊社運営の植え替えサービス「Green Re:pot(グリーン・リポット)」。
もともとXサーバー上のWordPressで運用していましたが、丸ごとCloudflare Pagesに移管しました。
作業時間は1日。コンパクトなサイトなので、この時間で済んだ部分もあります。
第五弾:他プロジェクトを統一
社内で運営している複数のサイトを、順次このスタックに統一していきます。
Contact Platformでフォームは一元管理、Pages CMSで記事編集は共通UI、
運用コストが大幅に削減される見込みです。
まとめ:まず第一弾として、ここまで来ました
✅ 静的HTML + Cloudflare Pages で本番稼働開始
✅ Formspree依存を外し、自作フォーム基盤 Contact Platform を構築
✅ PHPゼロ、脆弱性リスク軽減
⏳ Astro組み込み(第二弾・翌日予定)
⏳ Pages CMS 接続(第三弾・近日)
⏳ 本体サイト移管(第四弾)
Astro / Pages CMS はまだ入っていませんが、
「とにかく早くPHPから離脱する」という第一の目的は、1日で達成できました。
「WordPressの脆弱性対応が気になるけど、どこから手をつければ…」
「静的サイトに興味はあるけど、フォーム送信ってどうしてるの?」
「とりあえず今動いているサイトを、見た目はそのまま脱WordPressしたい」
そんな方、ぜひご相談ください。
今回のGreen Re:potでの実装経験そのまま、他のサイトでも応用できます。
デザインに手を入れる必要がなければ、
今動いているWordPressサイトを、そのままCloudflareに移管。
といったコンパクトなプランもご提案可能です。