親シリーズ第6章で、AI と対話して静的な Web サイトを作った。ここでは、それを 自分の側から公開する。動的な WordPress をやめ、焼いた HTML を Cloudflare Pages に置く ── サーバは持たない。
なぜ WordPress をやめるのか
WordPress は、動的サーバ・データベース・プラグインの塊だ。更新・保守・セキュリティの負担が、ずっと続く。会社サイトの中身はめったに変わらないのだから、静的でよい。静的なら、サーバも DB も要らず、攻撃される面もほぼ無い。導入編で作った html/ を、そのまま公開する。
Cloudflare Pages に置く ── サーバを持たない
作った HTML は Cloudflare Pages に置く。サーバは要らない。ファイルをアップロードすれば、世界中の CDN から配信され、HTTPS も自動でつく。
配信と防御は Cloudflare に任せ、ソースとビルドは自分の手元に残す。公開する HTML に秘密は無いので、ここは安心して任せられる。
ビルド・確認・デプロイを分ける
公開は、手順を分けてやる。一つにまとめない。
# 1. ビルド ── html/ を作る
python tools/build.py
# 2. 確認 ── 作った html/ をそのまま開いて、目で見る
python -m http.server --directory html 8000
# 3. プレビューに上げる ── 本番の前に、実環境で確認
python tools/deploy_pages.py html --branch preview
# 4. 確認できたら、本番に上げる
python tools/deploy_pages.py html --branch main
自動で作り直す設定や、「ビルドして上げる」を一つにまとめたコマンドは使わない。確認した HTML と、本番に上がる HTML を、同じにするためだ
(詳しい運用は社内マニュアルに分ける)。アップロードに npm や Node は要らない ── Cloudflare の API を直接叩くスクリプト一つでよい。そのスクリプトは公開パッケージ cf-publish(aiseed-dev/cf-publish)
にしてある ── cf-publish html --project <名前> の一行で、変わったファイルだけが上がる。
ドメインをつなぐ
独自ドメインは、Cloudflare Pages の カスタムドメインに追加する。DNS を Cloudflare で持っていれば、今までサーバを指していた A レコードが、自動で Pages に切り替わる。証明書も自動でつく。
メール(MX・SPF)は触らない。Web の置き場を替えるだけだ。不安なら、旧サーバを止めず、プレビューで確認してから本番ドメインを向ける。
動く部分だけ、つなぐ
問い合わせフォームのような 動く部分だけ、裏につなぐ。送信先は、門番 (2-03)の内側に置いた自分の API(認証は門番、保存は2-02の DB、通知は 2-06のメール)。大半は静的、動くのは要る所だけ。
内部の道具は別 ── 窓は借り、金庫は自分に
公開サイトは Cloudflare Pages に 借りる。だが、自立編で立てた 内部の道具(門番・文書・コード・メール・会議)は別だ。秘密や生のデータが通るので、門番(自分のリバースプロキシ)の内側に残す。
- 公開サイト(静的・秘密なし)── Cloudflare Pages に借りる
- 内部の道具(認証・業務データ)── 自分の側、門番の内側に持つ
窓は借り、金庫は自分に。借りる所と、自分で持つ所を、分けて決める。
借りている窓は、いつでも替えられる。公開サイトの実体は 静的ファイルの束と、手元のソース であり、Cloudflare に預けているものは何も無い ── 明日、別のホストに同じファイルを置けば、それで引っ越しは終わる。窓は借りるが、出口はいつも開いている。
まとめ
- WordPress をやめる ── 動的サーバ・DB・プラグインの保守負担を捨てる
- Cloudflare Pages ── サーバ無しで公開、CDN・自動 HTTPS を借りる
- ビルド → 確認 → デプロイを分ける ── 確認した物を、そのまま本番へ
- ドメインは自動で切り替わる ── カスタムドメインで A レコードが Pages を指す、メールは触らない
- 窓は借り、金庫は自分に ── 内部の道具は門番の内側に残す
次章では、基幹システムのロジックを API(FastAPI) として出し、各アプリから使えるようにする。