このブログを作った技術構成 — Astro × GitHub × Cloudflare Pages

個人ブログを Astro と Cloudflare Pages で立ち上げ、GitHub に push すれば公開される構成にした記録。

このブログをどう作ったかをまとめておきます。Markdown で記事を作成し、GitHubを更新したら勝手に公開される。利用するサービスを無料で長く続けられる構成を選びました。

なぜこの構成にしたか

最初はNoteやQiitaなどで技術ブログを作成すれば十分。という想定をしていたが、記事として配置するには物足りない要素が多いという印象がぬぐえない為メモの置き場を用意しようと思った点。

WordPressが候補になっていたが、サーバー運用に費用をかける事への出費が気になる事。

丁度 CloudFlare Pages でホスティングする事で相当な事が無い限り無料で運用できる事が分かったのでそこを中心に検討した。

Astro については今回初見でAIにオススメされてそのまま採用する形を取った、他の構成との差に関しては基本的には把握できていない。

結果的に以下の流れで作成。

静的サイトジェネレータ（Astro）でビルドし、できあがった HTML / CSS / JS を配信するだけにする
ソースを GitHub に置き、記事もリポジトリに .md として追加する
Cloudflare Pages にリポジトリを繋ぎ、push のたびに自動ビルド・自動公開させる

これで自分はMarkdownを書いて配置するだけ。各サービスは基本無料。となって要件を満たせるという形。

Astro の基本

Astroは最近流行っているらしい技術で、自分はNext.jsを触れる機会が少しあるが本質的にはjs関連のフロントの違いは分かっていない。

とりあえず早い点(静的ファイルにjsが含まれない)が強みのようで、ブログのような要件なら確かに候補として強いのかも？と言った印象。

ディレクトリ構成はおおまかにこんな形になりました。

src/
├── pages/             # ファイルベースルーティング
│   ├── index.astro
│   └── posts/[...slug].astro
├── layouts/           # 共通レイアウト
│   └── BaseLayout.astro
├── content/
│   └── blog/*.md      # 記事の本体（Markdown）
└── content.config.ts  # 記事のスキーマ（zod）

GitHub での記事運用

GitHubの使い方はシンプルで、リポジトリを 1 つ作って、それをそのままブログのソースにしています。

新しい記事を書くときの流れは次のとおりです。

src/content/blog/<slug>.md を新規作成する
frontmatter を書く（タイトル、カテゴリ、公開日など）
本文を Markdown で書く
GitHubに配置

個人運用ならブランチを切る必要は特になさそうで、mainで直接操作しています。

一時公開などを考えたらブランチ切ってCloudFlareのステージングでチェックする方針を取っても良さそう、frontmatterでdraftのフラグで一覧から除外できるようにはなっているが未検証。

Cloudflare Pages で公開

CloudFlarePagesは静的サイトであれば基本無料でホスティングでき、GitHubと連携するとリポジトリの更新に連動して自動でビルド・デプロイしてくれます。

設定は次の手順でした。

Cloudflare ダッシュボードから Workers & Pages → Create → Pages → Connect to Git を選ぶ
GitHub の Cloudflare Pages App をインストール
連携したいリポジトリを選択
ビルド設定を入力

私が入力したビルド設定はこれだけです。

項目	値
Framework preset	Astro
Build command	`npm run build`
Build output directory	`dist`
Production branch	`main`

初回ビルドが終わると <project>.pages.dev という URL が割り当てられ、すぐに公開されます。

CI/CD として動くこと

連携が終わったあとは、GitHubの更新がそのままデプロイ操作になります。

GitHubの更新 → 本番デプロイ。<project>.pages.dev（またはカスタムドメイン）が更新される
その他のブランチへの更新h → プレビュー用 URL が発行される（例: <branch>.<project>.pages.dev）
Pull Request を開く → その PR に対するプレビュー URL が自動でコメントされる

プレビュー URL には Cloudflare 側で自動的に X-Robots-Tag: noindex が付くので、書きかけの記事や試行錯誤中のレイアウトが検索結果に紛れ込む心配がありません。

ビルドログは Cloudflare のダッシュボードに残り、失敗したときも何が落ちたか追えます。たとえば npm run build の出力で Cannot find package のようなエラーがあれば NODE_VERSION の問題、TypeScript の型エラーなら frontmatter の不足、というように原因を辿りやすくなっています。

ここまでくると、

記事を書く → 配置する → ビルドが走る → 数十秒で公開される

というループが完成し、サーバーの事は気にせずGitHubでファイルを置けばいいだけの運用が完成しました。