記事を書くだけで自動公開：microCMSのWebhookでサイトを自動再ビルドする仕組み

結論：記事を書いて「公開」を押すだけでサイトが自動的に作り直されて反映される仕組みは、microCMSのWebhookとCloudflare Pagesのデプロイフックをつなぐだけで作れます。microCMS側の「記事が公開された」という出来事を、Cloudflare側の「サイトを作り直して」という命令へ橋渡しできるからです。

この記事は、株式会社curveが運営するAI情報メディア「AIテックベース」を静的サイトの構成で作った実体験シリーズの1本です。作業したのはエンジニアではなく社内のWeb担当者で、AIコーディング支援の「Claude Code」と一緒に進めました。仕組みと設定の手順に加えて、実際に運用して分かった注意点も紹介します。

1. そもそも静的サイトに「自動再ビルド」が必要な理由

結論：静的サイトは記事を書いただけでは表示が変わらないため、「再ビルド（作り直し）」という工程が必要です。

WordPressのような仕組みは、訪問者がページを開くたびにサーバーがその場でページを組み立てます。これに対して静的サイトは、「あらかじめ完成したページのファイル」を置いておくだけです。表示が速く、攻撃されやすい部分（管理画面・プラグイン・データベース）がない分だけ安全という利点がありますが、その代わり、内容を変えたら「ページを作り直す」必要があります。

AIテックベースでは、記事の中身はmicroCMS（日本製のヘッドレスCMS）に入っています。Astro（ウェブフレームワーク）がmicroCMSから記事を読み込んでページ一式を作り、それをCloudflare Pagesが配信します。記事を更新するたびに「Astroにもう一度ページを作らせる」必要があり、これを毎回手作業でやるのは現実的ではないので、自動化します。

2. 仕組みを一本の流れで理解する

結論：仕組みは「microCMSで公開 → Webhookが通知 → デプロイフックが起動 → 再ビルド → サイトに反映」という一本の流れです。

1. 公開する：Web担当者がmicroCMSで記事を書き、「公開」ボタンを押す
2. 通知が飛ぶ（Webhook）：microCMSが「記事が公開されました」という合図を、決められた宛先（URL）に自動で送る
3. 命令が届く（デプロイフック）：宛先はCloudflare Pagesの「デプロイフックURL」。合図が届くと、Cloudflareは「サイトを作り直して」という指示として受け取る
4. 再ビルドが走る：CloudflareがGitHub上のソースを使ってAstroを実行し、最新の記事の内容でページを作り直す
5. 反映される：AIテックベースの規模では、公開から1分ほどで新しい記事が表示される

用語を噛み砕くと、Webhookは「何かが起きたときに自動で送られる通知」、デプロイフックは「その通知を受け取って、再ビルドを始めるための専用の入口」です。この2つを線でつなぐ、というイメージが一番分かりやすいでしょう。

3. 設定手順の要点

結論：設定は「Cloudflare側でデプロイフックURLを作る → そのURLをmicroCMSのWebhookに登録する」の2ステップが中心です。難しいコードは書かず、管理画面の操作だけで完結します。

ステップ1：Cloudflare Pagesでデプロイフックを作る

• Cloudflare Pagesの対象プロジェクトの設定画面を開き、「デプロイフック（Deploy hooks）」を作成すると、専用のURLが1本発行される
• このURLは「送れば再ビルドが始まる」スイッチそのものなので、外部に漏らさない

ステップ2：microCMSのWebhookに登録する

• microCMSの対象のコンテンツ（記事など）のAPI設定からWebhookを追加する。送信先の候補には「Cloudflare Pages」が用意されている
• ステップ1でコピーしたデプロイフックURLを登録する
• どの操作で通知するかを選ぶ（「コンテンツの公開時・更新時」「コンテンツの公開終了時」「公開中コンテンツの削除時」など）。最低限「コンテンツの公開時・更新時」を有効にしておけば、公開も書き直しも自動で反映される。記事の取り下げも反映したいなら、「公開終了時」と「削除時」も有効にする

ステップ3：テストして確認する

• microCMSでテスト記事を公開し、Cloudflare側の「デプロイ履歴」に新しいビルドが始まっているかを確認する
• ビルドが「成功（Success）」になり、公開ページに記事が出れば完成

4. セキュリティ面で気をつけたいこと

結論：デプロイフックのURLは「知っていれば誰でも再ビルドを起動できる鍵」なので、パスワードと同じ感覚で扱います。

• チャットや資料に貼らない：共有が必要な場合は、パスワード管理ツールなど安全な手段を使う
• 公開されたコードに書き込まない：外部から見えない場所で管理する
• デプロイ履歴をたまに確認する：身に覚えのないビルドが増えていたら、デプロイフックを作り直して古いURLを削除する

もう一歩踏み込むなら、microCMSのWebhookの「カスタム通知」で「シークレット」を設定すると、送信する通知に署名が付き、受け取る側で「本当にmicroCMSから届いた通知か」を確かめられます。ただし、Cloudflareのデプロイフックはこの署名を確かめる仕組みを持たないため、署名を生かすには間に確認用の小さなプログラムを挟む必要があります。小規模なメディアなら、URLを厳重に管理するだけでも十分な場合が多いでしょう。

5. 運用して分かった注意点

実際に運用してみると、設定の時点では気づきにくい注意点がいくつかありました。

• ビルドの回数には上限がある：Cloudflare Pagesの無料プランでは、ビルドは月500回まで、同時に動かせるのは1つまでです。記事の公開や更新に加えて、サイトの改修でGitHubに変更を送るたびにもビルドが走ります。一度に多くの記事を直す日は、回数を意識しておくと安心です
• 画像は記事より先に公開する：AIテックベースでは、記事の中に図を入れる目印を書くと、ビルドのときにその図のファイルを探して埋め込みます。図のファイルがまだサイト側に届いていない状態で記事を公開すると、ビルドそのものが失敗します。そのため、図を先にGitHubに送り、公開ページで表示できることを確かめてから記事を公開する順番にしています
• ビルドが失敗しても、前の版が表示され続ける：失敗した場合は、直前に成功した版のサイトがそのまま表示されます。サイトが真っ白になることはありませんが、「公開したのに反映されない」ように見えるので、デプロイ履歴の確認が欠かせません
• 使っていない自動処理は止める：AIテックベースでは、過去に試した別の配置の仕組みが、公開には使われないまま動き続け、毎回失敗していました。動いていても意味のない処理は、混乱の元になるので止めておきます

6. 反映されないときに確認する順序

「公開したのに記事が反映されない」ときは、闇雲に設定をいじらず、流れの前から順番に確認すると原因を絞り込めます。

1. microCMSで本当に「公開」できているか：下書き保存のままになっていないか
2. Webhookの通知の設定に、その操作が含まれているか：「コンテンツの公開時・更新時」が有効か。その中の細かい選択肢（予約公開など）で、使った操作が外れていないか
3. Cloudflareのデプロイ履歴に新しいビルドがあるか：なければWebhookが届いていない可能性が高い
4. ビルドが失敗（Failed）になっていないか：失敗していれば、記録（ログ）に原因が書かれている。記事の中の画像や目印の不備が原因のことが多い

この順番で確かめれば、「通知が届いていないのか」「ビルド自体が失敗しているのか」を切り分けられ、調査の時間を大きく短縮できます。

7. この構成にして運用が楽になった理由

Web担当者が「記事を書いて公開を押す」以外に何もしなくてよくなりました。

以前は旧サーバーへ自動でアップロードしようとして、海外で動く自動化ツールからの接続が、サーバーの「国外IPアドレスフィルタ」に止められていました。Cloudflare Pagesに移したことで、旧サーバーへ海外から接続する必要そのものがなくなり、フィルタを有効に保ったまま自動公開を実現できました（くわしくはシリーズの別記事で紹介しています）。

この考え方は、microCMSとCloudflare Pagesの組み合わせに限りません。他のヘッドレスCMSや、VercelやNetlifyといった他の公開サービスでも、「公開を通知する仕組み（Webhook）」と「再ビルドの入口（デプロイフック）」という構図はほぼ共通しています。なお、Cloudflareは新規のプロジェクトにはPagesではなく「Workers」という仕組みを勧めています（Pagesも引き続き利用できます）。Workersでも、2026年4月から同様のデプロイフックが使えるようになりました。

8. まとめ

• 記事を書いて公開するだけで自動反映できるのは、microCMSのWebhookとCloudflare Pagesのデプロイフックをつないでいるから
• 仕組みは「公開 → 通知 → デプロイフック起動 → 再ビルド → 反映」の一本の流れ。設定は管理画面の操作だけ
• デプロイフックのURLはパスワードと同じ扱い。送信元を確かめたいならWebhookのシークレット（署名）も使える
• 無料プランのビルドは月500回まで。図などの画像は記事より先に公開する。失敗しても前の版が表示され続けるので、デプロイ履歴を確認する
• 反映されないときは、流れの前から順番に確認して原因を1か所に絞る