先日、WordPressからHugoへ移行したばかりでしたが、無料Webツールの表示にエラーが見つかり、思ったより修正量が多くなりそうです。そこで「どうせ直すなら別のフレームワークも試してみよう」と考え、Astroへの移行を決意しました。
当初Hugoを選んだのは、Node.jsがインストールされていないレンタルサーバーでもサクッと動く点が魅力だったからです。しかし実際に触ってみると、Go言語のテンプレート構文が自分にはどうしても馴染めず、特に自作のJSツールで表示不具合が出たときに修正が非常に手間取ってしまいました。
「このまま無理してHugoを続けても効率が悪い」と感じ、慣れているJavaScriptエコシステムでしっかり作り直した方が良いと判断。結果としてAstro + Cloudflare構成への移行を進めました。
Astroを選んで良かったのは、島アーキテクチャや部分ハイドレーションといった高度な機能のおかげで、サイト構築が驚くほどシンプルで楽になった点が大きいです。Tailwind CSS v4も簡単に導入でき、開発体験が格段に向上しました。
Reactでコンポーネントを管理できるうえ、必要最小限のJavaScriptだけをロードできるパフォーマンスの良さも実感しています。自作JSツールの不具合も、Astro上で整理し直したことで綺麗に解決できました。Goテンプレートはちょっと苦手だった自分にとって、今回の変更は良かったかなと思います。
移行作業では、複数サイトを同時に修正し、一部の内容はAIに任せていました。そのせいでちょっとした失敗も。あるサイトの修正時にビルドエラーが続き、AIの提案をそのまま何度も実行した結果、GitHub Actionsの無料枠を短期間で使い切ってしまったのです。提案内容が「毎回最初から全部やり直す」ようなものだったのに気づかず、機械的に繰り返してしまったのが原因でした。チェックしてなかった自分が悪いが、無料枠を一気に削られたのは流石にびっくししました。
自動化は便利ですが、リソースの消費ペースをしっかり把握しておかないと痛い目を見ますね。
この失敗をきっかけに運用を見直し、今はGitHub Actionsを完全に外しました。代わりにローカルでビルドしてからWranglerで直接Cloudflareへデプロイするスタイルに切り替えています。
Wranglerとは
Wranglerは、Cloudflare WorkersやPagesを操作するためのコマンドラインツール（CLI）。これを使うことで、ローカル環境で開発したコードを、ターミナルから直接Cloudflareのネットワークへ公開することができます。
# ビルドしてそのままデプロイ
npm run build && npx wrangler deployCloudflareが差分アップロードを行ってくれるので、とてもスムーズです。ビルドの待ち時間がなくなり、手元で変更を即座に反映・確認できるのが最高に快適。しばらくはこの運用を続けていくつもりです。
