今回、ある企業サイトをリニューアルすることになりました。
もともとはノーコードサービスで運用されていたサイトです。
更新はできるものの、デザインの自由度や保守性を考えると、少し物足りなさを感じていました。
そこで今回は、AIを活用した制作環境へ移行することにしました。
AIと一緒にデザインやコーディングを進められる環境にしておけば、今後の修正や更新もしやすくなると思ったからです。
そのとき候補に上がったのが、Cloudflare Pagesでした。
GitHubと連携するだけで公開でき、表示速度も速い。
AIとの開発環境とも相性が良く、「これなら企業サイトにも使えそうだ」と思いました。
思わぬ壁
実際に構築を始めると、一つだけ困ったことがありました。
Cloudflare PagesではPHPが動きません。
そのため、今まで使っていたお問い合わせフォームを、そのまま利用することができませんでした。
そこで導入したのがResendです。
API経由でメールを送れるため、Cloudflare Pagesとの相性も良く、お問い合わせフォームも問題なく動きました。
ここまでは順調でした。
運用まで考えると見え方が変わった
実際に使ってみると、別のことが気になりました。
Resendの無料プランは、送信先を1つしか設定できません。
自分のサイトで使う分には十分です。
でも、仕事として複数のクライアントサイトを管理することを考えると、アカウントを追加したり、それぞれの設定を管理したりする手間が増えていきます。
そこで、自分のサイトはConoHaのレンタルサーバーに戻し、Resendはクライアントサイト用に使うことにしました。
そうしてCloudflare PagesとResendを組み合わせて運用してみると、逆にレンタルサーバーの便利さにも気付きました。
レンタルサーバーなら、PHPもメールもお問い合わせフォームも、一つの環境でそのまま動きます。
今まで当たり前だと思っていましたが、それは最初から必要な機能が一通り用意されていたからでした。
Cloudflare Pagesを試したからこそ、レンタルサーバーがよく考えられたサービスなんだと実感しました。
正解は一つではありませんでした
だからといって、
「Cloudflare Pagesが良くなかった」
という話ではありません。
今回のクライアントサイトのように、AIを活用した制作環境を作るなら、Cloudflare Pagesはとても魅力的な選択肢です。
そして、PHPが使えない環境ではResendも非常に便利でした。
一方で、レンタルサーバーだけで完結できる環境なら、その仕組みをそのまま活かした方がシンプルなこともあります。
つまり、
どちらが優れているかではなく、
環境によって最適解は変わる。
それが今回、一番の学びでした。
まとめ
Cloudflare Pagesも。
Resendも。
ConoHaも。
どれも間違いではありません。
今回分かったのは、
技術には、それぞれ得意な役割があるということです。
そして、その違いは実際に使ってみないと分かりません。
少し遠回りにはなりましたが、
そのおかげで、それぞれの役割や仕組みを理解することができました。
だから、この遠回りは決して無駄ではありませんでした。
レンタルサーバーとCloudflare Pagesの違い
レンタルサーバーは、Webサイトの公開だけでなく、PHPやメールなどの機能も一つの環境でまとめて使えます。
一方、Cloudflare Pagesは静的サイトの公開が得意です。表示速度が速く、GitHubとの連携も便利ですが、お問い合わせフォームなどはResendのような外部サービスと組み合わせる必要があります。
どちらが優れているかではなく、サイトの目的や運用方法に合わせて選ぶことが大切です。
コメント