Astro + Cloudflare Workersでブログを公開する:実践ガイド
前回の記事では、Markdownブログ向けのSSGを比較し、Astroが2026年時点でバランスの取れた選択肢であることを整理しました。
この記事では、実際にAstroでブログを構築し、Cloudflare Workersで公開するまでの手順を解説します。
TL;DR
- Astroを使えば、Markdownで記事を書くだけのブログがすぐ作れる
- ファイル名に
_を付けるだけで下書き管理ができる - 設定ファイルを1つ追加するだけでCloudflareにデプロイ可能
- GitHubにpushすれば自動で本番公開される
この記事で扱う内容
- Astroプロジェクトの作成
- 記事の追加とフロントマター設定
- 下書き機能の実装
- Cloudflare Workersへのデプロイ
対象バージョン: Astro 5.x / Wrangler 3.x
ローカルでの動作確認から本番公開まで、一通りの流れを押さえます。
Astroプロジェクトの作成
初期化コマンド
npm create astro@latest
対話形式でいくつか質問されます。ブログ用途なら以下の選択が無難です。
- テンプレート: Blog
- TypeScript: お好みで(推奨は Yes)
- 依存関係のインストール: Yes
ディレクトリ構成
作成されるプロジェクトの主要な構成は以下の通りです。
src/
├── content/
│ └── blog/ # Markdown記事を配置
├── components/ # 再利用可能なコンポーネント
├── layouts/ # ページレイアウト
├── pages/ # ルーティング
└── content.config.ts # コンテンツスキーマ定義
記事は src/content/blog/ にMarkdownファイルを追加するだけで認識されます。詳細はAstroブログチュートリアルを参照してください。
記事の追加
フロントマターの基本形
各記事の先頭に、メタ情報を記述します。
---
title: '記事タイトル'
description: '記事の概要'
pubDate: 2026-01-13
tags: [astro, blog]
---
本文をここに書きます。
スキーマ定義(Content Layer API)
Astro 5.0では Content Layer API が導入され、glob loaderでコンテンツを読み込みます。src/content.config.ts でフロントマターの型を定義します。
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';
const blog = defineCollection({
loader: glob({ base: './src/content/blog', pattern: '**/*.{md,mdx}' }),
schema: ({ image }) =>
z.object({
title: z.string(),
description: z.string(),
pubDate: z.coerce.date(),
updatedDate: z.coerce.date().optional(),
heroImage: image().optional(),
}),
});
export const collections = { blog };
これで src/content/blog/ 内のMarkdownファイルが型安全に読み込まれます。
下書き機能の実装
Astro 5.0では、Content Layer APIの glob パターンを活用することで、シンプルに下書き機能を実現できます。
ファイル名で下書きを管理
下書きにしたい記事は、ファイル名の先頭に _ を付けます。
そして、content.config.ts の pattern を変更し、_ で始まるファイルを除外します。
// 変更前
loader: glob({ base: './src/content/blog', pattern: '**/*.{md,mdx}' }),
// 変更後: `_`で始まるファイルを除外
loader: glob({ base: './src/content/blog', pattern: '**/[!_]*.{md,mdx}' }),
[!_] は「_ で始まらないファイル」を意味するglobパターンです。これにより、loaderレベルで下書きが除外されます。
src/content/blog/
├── _my-draft.md # 下書き(ビルド対象外)
├── 20260113_1.md # 公開記事(ビルド対象)
└── 20260113_2.md # 公開記事(ビルド対象)
この方式のメリット
- 設定が一箇所で完結:
content.config.tsのパターンだけで制御 - フロントマターが不完全でもOK: loaderに読み込まれないのでビルドエラーにならない
- 一目で分かる: ファイル一覧を見るだけで下書きが識別できる
ページ側(index.astro、[...slug].astro)にフィルタリング処理を書く必要がありません。
// シンプルにgetCollectionを呼ぶだけ
const posts = (await getCollection('blog')).sort(
(a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf(),
);
公開時の操作
記事が完成したら、ファイル名から _ を削除するだけです。
# 下書き → 公開
mv _my-article.md 20260113_3.md
ローカルでの確認
下書き記事はビルド対象外のため、本番と同じ状態を確認できます。
npm run build
npm run preview
Cloudflare Workersへのデプロイ
なぜCloudflare Workersか
- 無料枠が実用的: 静的アセットは無制限、リクエストも10万/日
- Workers Builds: GitHubリポジトリと連携するだけで自動デプロイ
- 高速配信: 世界中のサーバーから最寄りの場所で配信
- 将来の拡張性: Cloudflareの機能で問い合わせフォームやデータベース連携も追加できる
個人ブログなら十分すぎる環境です。詳細はCloudflare Workers公式ドキュメントを参照してください。
Workers Assets とは
Cloudflare Workersには静的ファイルをホスティングする「Assets」機能があります。Astroでビルドした dist/ フォルダをそのまま配信できます。
設定ファイルの追加
プロジェクトルートに wrangler.jsonc を作成します。
{
"name": "your-site-name",
"compatibility_date": "2026-01-12",
"assets": {
"directory": "./dist"
}
}
| 項目 | 説明 |
|---|---|
name | Workers名(URLの一部になる) |
compatibility_date | Workers APIの互換性日付 |
assets.directory | 静的ファイルの出力先(Astroは dist) |
Workers Builds による自動デプロイ
Cloudflareには「Workers Builds」という自動ビルド・デプロイ機能があり、GitHub/GitLabと連携できます。
設定手順
- Cloudflareダッシュボードで「Workers & Pages」を開く
- 「Create」からGitHubリポジトリを連携
- ビルド設定:
- Build command:
npm run build - Deploy command:
npx wrangler deploy
- Build command:
ビルドの流れ
GitHub push
↓
Workers Builds(Cloudflare環境)
├─ npm clean-install(lockファイルを厳密に再現)
├─ npm run build(Astroビルド → dist/)
└─ npx wrangler deploy(Workers Assetsにアップロード)
↓
Cloudflare Workers(エッジ配信)
npm clean-install(npm ci)が使われるため、package-lock.json に記録されたバージョンが厳密に再現されます。
プレビュー環境
main以外のブランチにpushすると、ブランチごとにプレビューURLが自動生成されます。
https://<ブランチ名>.<プロジェクト名>.workers.dev
Cloudflare Accessを設定すれば、プレビュー環境に認証をかけることもできます。
まとめ
- Astroはブログテンプレートで即座に始められる
- Astro 5.0のContent Layer APIで下書き機能をシンプルに実装できる
_プレフィックス方式は設定が一箇所で済み、運用も直感的- Cloudflare Workers + Workers Buildsで自動デプロイ
- 将来的なAPI追加も同じ構成で対応可能
「Markdownで書いてGitで管理し、pushしたら公開」という流れが、最小限の設定で実現できます。