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

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

この記事は、株式会社curveが運営するAI情報メディア「AIテックベース」を静的サイト構成で構築した実体験シリーズの1本です。作業したのはエンジニアではなく社内のWeb担当者で、AIコーディング支援の「Claude Code」と一緒に進めました。

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

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

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

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

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

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

言葉で図にすると、次のように進みます。

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

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

設定手順の要点

結論:設定は「Cloudflare側でデプロイフックURLを作る → そのURLをmicroCMSのWebhookに登録する」の2ステップが中心です。

難しいコードは書きません。基本は管理画面の操作だけです。要点を順番に挙げます。

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

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

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

• microCMSの対象コンテンツ（記事など）のAPI設定からWebhookを追加する。
• 送信先に、ステップ1でコピーしたCloudflareのデプロイフックURLを貼り付ける。
• どのタイミングで通知するか（公開・更新・削除など）を選ぶ。最低限「公開時」を有効にすれば、記事公開で自動再ビルドが動く。

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

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

私たちはこの確認を必ず行うようにしています。なぜなら、設定直後に「公開したのに反映されない」というトラブルが起きたとき、microCMSのWebhook側で送れていないのか、Cloudflare側でビルドが失敗しているのか、原因を1か所に絞り込めるからです。

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

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

なぜなら、再ビルドも配信も自動だからです。サーバーにログインする作業も、ファイルを手動でアップロードする作業も発生しません。具体的には次のような変化がありました。

実体験の補足:なぜ最初からこの構成ではなかったのか

結論:もともとは旧サーバーへ自動アップロードしようとして失敗し続け、最終的にCloudflare Pagesへ切り替えたことで自動化が成立しました。

理由は、旧環境（さくらのレンタルサーバー スタンダード）でのFTP運用にありました。当時はFTPで接続していたため、海外で動く自動化ツール（GitHub Actions）からの接続が「国外IPアドレスフィルタ」で遮断されていたのです。このフィルタはサイト閲覧（HTTP）は止めず、FTPや管理画面など管理系の入口だけを守ります。Cloudflare Pagesへ移したことで旧サーバーへ海外からアクセスする必要そのものが無くなり、フィルタを有効に保ったまま（高セキュリティのまま）自動公開を実現できました。この経緯は、シリーズの別記事（国外IPフィルタ／静的サイトを選んだ理由／フォームの作り方）でも詳しく触れています。

非エンジニアとしての学びは1つです。「原因らしきものを片っ端から試す」のではなく、先に環境の仕様を確定し、エラーの意味を調べて原因を1つに特定してから直すこと。Webhookの設定でも、まず「どこまで届いているか」を確認する姿勢が、結局いちばんの近道でした。

まとめ

• 記事を書いて公開するだけで自動反映できるのは、microCMSのWebhookとCloudflareのデプロイフックをつないでいるから。
• 仕組みは「公開 → Webhook通知 → デプロイフック起動 → 再ビルド → 反映」の一本の流れ。
• 設定の要点は「Cloudflareでデプロイフックを作る → そのURLをmicroCMSのWebhookに登録する → テストで確認する」の3ステップ。
• 静的サイトは表示が速く攻撃される面が少ないが、更新には再ビルドが必要。だから自動化が効く。
• 旧サーバーへの自動アップロードは国外IPフィルタで失敗。Cloudflare Pagesへの切り替えで、セキュリティを保ったまま自動公開が成立した。