サーバー・インフラ公開日
連載「Cloudflare Pages で公開する」第3回

microCMS で記事を公開したら Cloudflare Pages を自動で再ビルドする｜Webhook とデプロイフックの設定

この回でやること

microCMS で記事を公開・更新・削除したら、Cloudflare Pages が自動でサイトを再ビルドするようにします。連載「Cloudflare Pages で公開する」の第3回（最終回）です。

前提として、Astro は静的出力（アダプターなし）で、Cloudflare Pages へのデプロイまでは済んでいるものとします。

静的サイトは「ビルドした時点」の記事しか持っていない

このサイトは、記事のページをビルドのときにまとめて生成しています。記事詳細ページでは、getStaticPaths の中で microCMS から全記事を取得し、記事ごとにページを作ります。

src/pages/blog/[id].astro
export const getStaticPaths = (async () => {
	const blogs = await getAllBlogs();
	const seriesById = new Map(groupBySeries(blogs).map((entry) => [entry.series.id, entry]));
	return blogs.map((blog) => ({
		params: { id: blog.id },
		props: { blog, seriesEntry: blog.series ? seriesById.get(blog.series.id) : undefined },
	}));
}) satisfies GetStaticPaths;

microCMS にアクセスするのはビルドのときだけです。そのため、microCMS で記事を公開・更新・削除しても、次にビルドするまでサイトは変わりません。

設定する前に起きたこと

実際、Webhook を設定する前に、動作確認用に公開していたテストデータを microCMS で削除したところ、本番サイトには残ったままでした。

このテストデータが本番から消えたのは、別の変更（GA4 のタグ）を push して、Cloudflare Pages が再ビルドしたときです。コードを push しない限り、microCMS の変更はサイトに反映されません。

仕組み：Webhook でデプロイフックを呼ぶ

次の流れで、microCMS の変更をきっかけに再ビルドします。

  1. microCMS でコンテンツを公開・更新・削除する
  2. microCMS の Webhook が、Cloudflare Pages のデプロイフックの URL に POST する
  3. Cloudflare Pages が main ブランチをビルドする（このとき microCMS から最新の記事を取得する）
  4. 新しいビルド結果が公開される

デプロイフックは、コミット以外のきっかけでデプロイを始めるための URL です。Cloudflare のドキュメントでも、ヘッドレスCMS のコンテンツが変わったときの自動デプロイが、使い道の例に挙がっています。

With Deploy Hooks, you can trigger deployments using event sources beyond commits in your source repository. Each event source may obtain its own unique URL, which will receive HTTP POST requests in order to initiate new deployments.

出典：Deploy Hooks | Cloudflare Pages docs

手順1：Cloudflare Pages でデプロイフックを作る

Pages プロジェクトの 設定 > ビルド > デプロイフック で、ブランチ main のフックを作り、表示された URL をコピーします。

デプロイフックの URL は秘密にする

デプロイフックの URL は、知っていれば誰でもビルドを始められます。追加の認証はありません。Cloudflare のドキュメントでも、アプリケーションの秘密情報と同じように扱うよう書かれています。

Deploy Hooks are uniquely linked to your project and do not require additional authentication to be used. While this does allow for complete flexibility, it is important that you protect these URLs in the same way you would safeguard any proprietary information or application secret.

出典：Deploy Hooks | Cloudflare Pages docs

リポジトリや記事のスクリーンショットに URL が写り込まないように注意します。漏れた疑いがあるときは、そのフックを削除して作り直します。

手順2：microCMS の Webhook に登録する

microCMS の API設定 > Webhook で「カスタム通知」を追加し、手順1でコピーした URL を登録します。

通知のタイミング

microCMS の Webhook では、どのタイミングで通知するかを選べます。ドキュメントでは、大きく次の4つに分かれています。

タイミング

内容（ドキュメントの説明を要約）

コンテンツの公開時・更新時

公開したとき、公開中のコンテンツを更新したとき、並び替えたときなど

コンテンツの公開終了時

公開中のコンテンツを公開終了にしたとき、下書きに戻したときなど

コンテンツの下書き保存時

下書きを作成・更新したときなど

公開中コンテンツの削除時

公開中のコンテンツを削除したとき

参考：Webhookの設定 | microCMS ドキュメント

サイトの見た目が変わるのは、公開・更新、公開終了、公開中コンテンツの削除のときです。前の節のテストデータのように、公開中のコンテンツを削除したときにも再ビルドが必要なので、削除時の通知も忘れずに入れておきます。

下書きの保存は、ふつうはサイトに出ないので、再ビルドは要りません。ただし、ビルドに使う APIキーで「下書き全取得」の権限を有効にしていると、下書きも API から返ってきます。ビルド用の APIキーでは、この権限を無効にしておきます。

手順3：blogs 以外の API にも設定する

Webhook は API ごとに設定します。blogs だけに設定すると、記事以外を変えたときに再ビルドされません。このサイトでは、4つの API すべてに同じ Webhook を設定しました。

API

サイトのどこに出るか

blogs

記事一覧・記事詳細・トップページの新着記事

categories

記事に表示するカテゴリ名

series

記事に表示する連載名・連載の目次ページ

tools

ツール一覧・トップページのツール欄

たとえばカテゴリ名を変えると、そのカテゴリの記事すべての表示が変わります。しかし、変わったのは categories のコンテンツなので、blogs の Webhook は動きません。

ツール一覧は、microCMS の管理画面での並び順をそのまま使っています。

src/lib/microcms.ts
/** 全ツール。orders を指定しないので、microCMS 管理画面での並び順になる */
export function getTools(): Promise<Tool[]> {
	return client.getAllContents<Tool>({
		endpoint: 'tools',
		queries: { fields: TOOL_FIELDS },
	});
}

microCMS のドキュメントによると、公開済みのコンテンツを一覧画面で並び替えたときも Webhook が通知されます。tools に Webhook を設定し、公開時・更新時の通知を有効にしておけば、並び替えるだけでサイトの並び順も変わります。

動いたかを確かめる

設定したあと、microCMS で連載（series のコンテンツ）を公開して確かめました。

  • 14:18:34　microCMS で連載を公開
  • 14:19:03　GitHub の最新コミットに、Cloudflare Pages の「Deployed successfully」のチェックが付く

公開から29秒後に、push なしで再ビルドが走り、デプロイまで成功しています。

GitHub のチェックで確かめる方法

デプロイフックで走ったビルドも、GitHub の main の最新コミットに Cloudflare Pages のチェックとして記録されていました。GitHub の API で、そのコミットのチェックを一覧にすると分かります。

$ gh api "repos/<owner>/<repo>/commits/<SHA>/check-runs?filter=all" \
    --jq '.check_runs[] | [.name, .status, .started_at, .output.title] | @tsv'
Cloudflare Pages	completed	2026-10-23T05:19:03Z	Deployed successfully
Cloudflare Pages	completed	2026-10-23T05:16:36Z	Deployed successfully
Cloudflare Pages	in_progress	2026-10-23T05:16:04Z	Building

時刻は UTC です。日本時間に直すと、下の2行（14:16）がこのコミットを push したときのビルド、いちばん上の行（14:19）が microCMS の Webhook で走った再ビルドです。同じコミットに、push のあとでもう一度チェックが付いていれば、push 以外のきっかけでビルドされたことが分かります。

filter=all を付けているのは、付けないと最新のチェックしか返ってこないからです。GitHub のドキュメントでも、filter の既定値は latest（最新のチェックだけ）になっています。

参考：REST API endpoints for check runs | GitHub Docs

Cloudflare 側では、デプロイの一覧の「Source」の列で、デプロイフックで走ったデプロイかどうかを見分けられると、ドキュメントに書かれています。

まだ確認していないこと

今回確認できたのは、series の公開での再ビルドだけです。blogs の Webhook は、最初の記事を公開するときに確かめます。

注意点

  • デプロイフックの URL は、誰でもビルドを始められる秘密の URL。リポジトリやスクリーンショットに載せない
  • Webhook は API ごとの設定。表示に使っている API すべてに設定する
  • 公開中のコンテンツの削除・公開終了でも再ビルドが要る。通知のタイミングに含める
  • ビルド用の APIキーで「下書き全取得」を有効にしていると、下書きが本番に出てしまう

まとめ

  • 静的サイトはビルドしたときの記事しか持っていないので、microCMS の変更のたびに再ビルドが要る
  • Cloudflare Pages のデプロイフック（main 用）を作り、microCMS の Webhook（カスタム通知）に登録する
  • blogs だけでなく、カテゴリ・連載・ツールなど、表示に使う API すべてに設定する
  • 動いたかどうかは、GitHub の check-runs を filter=all で見ると確かめられる

連載「Cloudflare Pages で公開する」はこれで終わりです。広告やアクセス解析など、公開後の準備は連載「技術ブログの収益化準備」で、サイト全体の流れは総集編で紹介しています。