【設計編】WordPressからAstroへ。技術ブログの技術選定メモ
ブログの方向性を技術寄りにシフトするにあたり、これまで利用していた環境を一新することにしました。
今回はその第一歩として、フロントエンドとインフラの設計方針、そして技術選定の過程をまとめます。
新しい環境のフロントエンドには「Astro」、公開基盤のインフラには「Cloudflare」を採用することにしました。本記事では、なぜこれらの技術を選んだのかを順を追って説明します。
まずは、今回フロントエンドの主役となるAstroがどのようなフレームワークなのかを簡単に整理しておきましょう。
Astroとは
Astroは、ブログやドキュメントなど、コンテンツを中心としたWebサイトを作るためのWebフレームワークです。ページの大部分をHTMLとして生成し、標準ではブラウザへ不要なJavaScriptを送りません。
操作が必要な部分だけをアイランドとして動かせるのも特徴です。必要になればReactやVueなどのコンポーネントを追加し、その部分だけをクライアント側で動かせます。
Markdownを標準で扱え、Content Collectionsで記事の構造やメタデータを検証できます。静的サイトとして出力できるため、今回考えている「Markdownで執筆し、GitHub経由でCloudflareへ公開する」という構成にも合わせやすいと考えました。
1. フロントエンド選定：WordPress vs Astro
これまで使っていたWordPressを継続するか、別の技術へ移行するか。いくつかの選択肢を比較した結果、今回は Astro を採用することにしました。
もちろん、WordPressの「プラグインと管理画面で何でも一元管理できる」という強みは圧倒的です。一方で、今回新たに実現したいブログの運用フローを考えると、Astroのほうが目的に合っていました。
最大の理由は「AIとの親和性」
今回一番やりたかったのが、**「AIに執筆から公開まで任せるワークフロー」**を作ることでした。
- WordPressの場合： GUIでの操作が中心となるため、AIからの自動投稿パイプラインを作るにはAPI経由での連携など、ひと工夫必要になります。
- Astroの場合： 記事をMarkdownファイルとして、サイト全体をGitで管理できます。
つまり、次のようなCI/CDパイプラインをシンプルに構築できることが大きな決め手でした。
AIがMarkdownを作成
↓
GitHubへpush
↓
自動で公開ReactやVueではだめなのか？
Astroはコンテンツ中心のサイトを得意としているため、ブログ用途であればReactやVueを単独で使うよりも最初から目的に合っており、導入も手軽でした。
一方でAstroには、問い合わせフォームなどの動的な機能を追加しようとすると、外部サービス（BaaSなど）に管理が分散しやすくなるという弱点もあります。しかし、今回は会員管理のような複雑な運営機能を求めていないため、このトレードオフは許容範囲だと判断しました。
2. インフラ選定：なぜCloudflareか
フロントエンドが決まったところで、次はそれをどこにデプロイするかです。Astroのデプロイ先としてはVercelなども有力な選択肢ですが、今回は Cloudflare（Cloudflare Pages）に寄せました。
理由はシンプルで、将来的に自宅ラボの公開に Cloudflare Tunnel を使いたいと考えているからです。
技術ブログをCloudflare上で動かしておけば、日々の運用を通じてPagesやWorkersなど、Cloudflare周辺のエコシステムに触れる機会が増えます。つまり、ブログを公開・運用すること自体を、Webやインフラ技術の学習題材にするという狙いがあります。
3. 構成まとめ
最終的なブログの公開パイプラインは、次のようなシンプルな形に落ち着きました。
Markdown → Astro → GitHub → Cloudflare Pages → 公開ブログを運用していく上でのマイルールとして、「何でも自作しない」「外部サービスを増やしすぎない」 ことを意識し、メンテナンスに疲れない構成を目指していきます。
今回は、技術ブログの構成を検討した過程と、Astro + GitHub + Cloudflareという組み合わせを選んだ理由についてまとめました。
次回の 「実装編」 では、実際のAstroプロジェクトの立ち上げからCloudflareへのデプロイまでを解説します。