microCMSの記事が反映されない原因｜Webhookと再ビルドを実測

microCMSで記事を公開したのに、新しいURLが404になる。本文を更新したのに、公開ページには古い内容が残っている。このような現象は、Next.jsのSSG（静的サイト生成）を使う構成では、再ビルドが完了するまで発生します。

当サイトでは、microCMSでの公開・更新をきっかけにWebhookを送り、Cloudflare Pagesでサイトを再ビルドしています。実際に記事を公開したところ、公開直後と30秒後は404で、75秒後の確認時点では表示されました。公開済み記事の更新は、45秒後も旧内容が表示され、90秒後の確認時点で新しい内容へ切り替わりました。

先に結論をまとめると、確認する順番は次のとおりです。

1. microCMSでコンテンツが公開状態になっているか
2. Cloudflare Pagesで新しいデプロイが始まっているか
3. デプロイが成功しているか
4. Next.jsのビルド対象に記事のパスが含まれているか
5. pages.devと独自ドメインで表示結果が異ならないか

この記事では、当サイトでの実測結果と実装をもとに、microCMSの記事が反映されない原因を切り分ける方法と、Webhookの設定手順を解説します。対象は、microCMSの更新後にホスティング環境で再ビルドするSSG構成です。

microCMSで公開してもSSGサイトはその場で更新されない

microCMSはコンテンツを管理し、APIでデータを提供するヘッドレスCMSです。Next.jsでSSGを採用している場合、公開サイトのHTMLはビルド時に生成されます。

そのため、microCMSで公開ボタンを押した時点では、microCMSの公開データが更新された段階です。公開サイトへ反映するには、その後にフロントエンドのビルドとデプロイが必要です。

当サイトでは次の順番で処理されます。

microCMSで記事を公開・更新
        ↓
microCMSからWebhookを送信
        ↓
Cloudflare PagesのDeploy Hookがデプロイを開始
        ↓
Next.jsがmicroCMSから最新データを取得して静的HTMLを生成
        ↓
新しいデプロイが公開環境へ反映

microCMS公式ドキュメントのレンダリング方式の説明でも、SSGはコンテンツやテンプレートの更新時にビルドを実行し、生成した静的ファイルをデプロイする方式とされています。

つまり、SSG構成では「microCMSでの公開」と「Webサイトへの反映」は同時ではありません。公開直後の未反映だけで、Webhookの設定不備や障害と判断する必要はありません。

公開・更新後の反映時間を実測した結果

2026年8月29日、当サイトで新規記事の公開と、公開済み記事の更新を行い、公開URLへ再アクセスして表示を確認しました。

これは連続計測ではなく、表に記載した時点で表示を確認した結果です。新規記事は30秒後から75秒後までの間、2回の更新は45秒後から90秒後までの間に反映されています。

今回の環境では、公開から75秒後、更新から90秒後の確認で反映済みでした。反映時間はサイトのページ数、依存パッケージ、ビルドキャッシュ、ホスティング環境によって変わります。秒数だけで正常・異常を決めず、Cloudflare Pagesのデプロイ状況を確認するのが確実です。

今回検証した記事と、microCMS MCPを使った公開までの流れは「microCMS公式MCPをCodexで使う方法」で紹介しています。

新規記事は404、更新記事は旧内容になる理由

同じ再ビルド待ちでも、新規公開と既存記事の更新では見え方が異なります。

新規記事が404になる理由

当サイトの記事ページは、Next.jsのPages RouterでgetStaticPathsとgetStaticPropsを使って生成しています。実装の要点は次のとおりです。

export async function getStaticPaths() {
  const allSlugs = await getAllSlugs()

  return {
    fallback: false,
    paths: allSlugs.map(({ slug }) => `/column/${slug}`),
  }
}

getStaticPathsはビルド時にmicroCMSから記事のslugを取得し、生成するURLを決めます。Next.js公式ドキュメントでは、fallback: falseの場合、getStaticPathsが返していないパスは404になると説明されています。

新規記事のURLは、次のビルドとデプロイが完了するまで公開環境の静的ファイルとして存在しません。そのため、microCMSでは公開済みでも、新しいデプロイが完了するまでは404になります。

参考：getStaticPaths｜Next.js公式ドキュメント

更新記事に旧内容が表示される理由

既存記事のURLは前回のビルドですでに生成されています。microCMS側の本文を更新しても、公開環境には前回生成した静的HTMLが残っています。

当サイトの記事ページではrevalidateを設定していないため、アクセスをきっかけに記事が再生成されることはありません。Webhookから新しいビルドとデプロイが完了した時点で、公開ページが更新後の内容へ切り替わります。

SSGの表示速度を維持しながら記事を更新するには、Webhookが正しくデプロイを開始できる状態が必要です。当サイトがmicroCMS、Next.js、Cloudflare Pagesを採用した経緯は「microCMSとWordPressを実装経験から比較」で解説しています。

microCMSの記事が反映されないときの確認手順

反映されない原因は、公開状態、Webhook、ビルド、静的パス、独自ドメインの順に確認すると切り分けやすくなります。

1. microCMSで公開状態を確認する

最初に、対象コンテンツが「公開中」になっているか確認します。

下書き保存だけでは、通常のGET APIから公開データとして取得できません。「公開中かつ下書き中」の場合は、公開中の内容と編集中の下書きが別に存在します。下書き側だけを更新した状態では、公開サイトに表示される本文は変わりません。

公開日時を予約している場合は、現在時刻とタイムゾーンも確認します。ここで公開状態に問題があれば、WebhookやCloudflare Pagesを調べる前にmicroCMS側の状態を修正します。

2. Cloudflare Pagesでデプロイが始まっているか確認する

microCMSで公開・更新した時刻以降に、Cloudflare Pagesで新しいデプロイが作成されているか確認します。

Cloudflare Pagesでは、対象プロジェクトの「Deployments」から履歴を確認できます。Deploy Hook経由で開始したデプロイは、デプロイログのSource列で判別できます。

• 新しいデプロイが進行中：完了後に公開URLを確認する
• 新しいデプロイがない：Webhookの有効状態、通知タイミング、Deploy Hook URLを確認する
• デプロイが失敗：ビルドログを確認する

Cloudflare PagesのDeploy Hooks公式ドキュメントでは、Deploy HookのURLへPOSTリクエストを送ると新しいデプロイが開始されること、Source列でDeploy Hookからの実行を確認できることが案内されています。

3. デプロイが失敗している場合はビルドログを確認する

Cloudflare Pagesでデプロイが始まっていても、ビルドに失敗すれば公開サイトは更新されません。

「Deployments」から対象デプロイの詳細を開き、Build logを確認します。microCMSとNext.jsの構成では、次の項目から確認します。

• microCMSのサービスドメインとAPIキーを環境変数から取得できているか
• APIキーにGET権限があるか
• ビルド中のContent APIリクエストがエラーになっていないか
• 必須フィールドを前提にした処理でundefinedやnullが発生していないか
• Node.jsや依存パッケージのバージョンが変わっていないか
• Build commandと出力先が正しいか

Cloudflare公式の「Debugging Pages」でも、「Deployments → View details → Build log」の順でビルドエラーを確認する手順が案内されています。

エラーを直しただけでは公開環境は更新されません。修正後に再デプロイし、成功したデプロイが公開環境へ反映されたことまで確認します。

4. ビルド対象に記事のパスが含まれているか確認する

デプロイは成功しているのに新規記事だけ404になる場合は、getStaticPathsへ記事のslugが渡っているか確認します。

よくある原因は次のとおりです。

• Content APIのlimitを超え、対象記事が取得結果に含まれていない
• filtersの条件で対象記事を除外している
• slugを変更したが、リンク先は変更前のURLのままになっている
• microCMSのslugとNext.jsへ渡すパラメータが一致していない
• ビルド時に参照しているmicroCMSのサービスや環境が異なる

fallback: falseでは、ビルド時の一覧に含まれないURLは404になります。APIの取得件数が増えるサイトでは、offsetを使って全記事のslugを取得する処理も必要です。

5. pages.devと独自ドメインの表示を比較する

Cloudflare Pagesのデプロイが成功し、pages.devのURLでは新しい内容が見えるのに、独自ドメインだけ古い場合は、独自ドメイン側のキャッシュ設定を確認します。

Cloudflare公式ドキュメントでは、Pagesの独自ドメインで古いコンテンツが表示される場合、Page RuleにCache Everythingが設定されていないか確認するよう案内しています。Pages自身が静的ファイルのキャッシュを処理するため、重複するキャッシュルールが原因になります。

ブラウザのキャッシュだけを疑う前に、pages.devと独自ドメインを同じタイミングで比較すると、デプロイ側と独自ドメイン側を分けて確認できます。

Cloudflare PagesとmicroCMSのWebhook設定

SSGサイトを自動更新するには、Cloudflare PagesでDeploy Hookを発行し、そのURLをmicroCMSへ登録します。

Cloudflare PagesでDeploy Hookを作成する

Cloudflareの管理画面で対象のPagesプロジェクトを開き、「Settings」からビルド設定へ進み、Deploy Hookを追加します。

設定する項目は次の2つです。

• Deploy Hookの名前
• ビルドするブランチ

作成後に表示されるURLは、認証なしでデプロイを開始できるURLです。APIキーやパスワードと同じように扱い、記事、Gitリポジトリ、画面共有へ掲載しません。漏えいした場合は古いDeploy Hookを削除し、新しく作り直します。

microCMSへCloudflare PagesのWebhookを登録する

microCMSで対象APIを開き、「API設定」から「Webhook」へ進みます。「Cloudflare Pages」を選択し、Cloudflareで発行したDeploy Hooks URLを登録します。

公開サイトの更新に必要な通知タイミングは、運用に合わせて次のように設定します。

本番サイトのビルドを目的とする場合、下書き保存のたびにデプロイする設定は不要です。プレビュー環境を別に用意している場合は、本番用とプレビュー用の通知先を分けます。

設定項目と通知条件の詳細は「コンテンツのWebhookを設定｜microCMS公式ドキュメント」で確認できます。

Webhookが発火しなかった場合の注意点

microCMSの公式ドキュメントでは、Webhookがネットワークエラーや4xx・5xxエラーで失敗しても、リトライ処理は行われないと明記されています。

そのため、一度の通知失敗を待ち続けてもデプロイは始まりません。Cloudflare Pagesに該当時刻のデプロイがなければ、次の順番で対応します。

1. microCMSのWebhookが有効になっているか確認する
2. 操作内容に対応する通知タイミングが選ばれているか確認する
3. 登録したDeploy Hook URLが現在も有効か確認する
4. 原因を修正し、対象コンテンツの更新で再通知するか、Deploy Hookへ手動でPOSTする
5. Cloudflare Pagesでデプロイ開始と成功を確認する

Deploy Hookを手動実行するときも、URLをターミナル履歴、ログ、共有資料へ残さない運用が必要です。

状態別の原因早見表

この表の上から順に確認すれば、「再ビルドを待てばよい状態」と「設定や実装の修正が必要な状態」を分けられます。

よくある質問

microCMSの記事公開後、何秒待てば反映されますか？

当サイトでは、新規記事は75秒後、公開済み記事の更新は90秒後の確認時点で反映されました。ただし、固定の待ち時間はありません。Cloudflare Pagesのデプロイが成功した時点を基準に判断します。

microCMSでは公開中なのに記事URLが404になるのはなぜですか？

Next.jsでfallback: falseを使ったSSG構成では、前回のビルドに含まれない新規URLは404になります。Webhookによる再ビルドが成功し、getStaticPathsへ新しいslugが含まれると表示されます。

記事を更新しても古い本文が表示されるのはキャッシュが原因ですか？

SSGでは、前回のビルドで生成した静的HTMLが表示されるため、まず再ビルドの完了を確認します。デプロイ成功後も独自ドメインだけ古い場合は、Cloudflareのキャッシュルールを確認します。

microCMSのWebhookは失敗時に自動で再送されますか？

自動では再送されません。microCMS公式ドキュメントでは、ネットワークエラーや4xx・5xxエラーで失敗したWebhookにリトライ処理は行われないと説明されています。原因を修正したうえで、再通知またはDeploy Hookの手動実行が必要です。

更新をすぐ反映したい場合はSSGをやめるべきですか？

更新頻度と必要な即時性で判断します。数分以内の反映で運用できるコーポレートサイトやブログなら、WebhookとSSGを組み合わせられます。秒単位の更新が必要なら、SSR、ISR、クライアント側でのデータ取得などを含めて設計を見直します。

まとめ

microCMSで記事を公開・更新しても、SSGサイトは再ビルドとデプロイが終わるまで更新されません。当サイトで確認した新規記事の404と更新後の旧表示は、Cloudflare Pagesの新しいデプロイが反映されると解消しました。

反映されないときは、ブラウザを何度も再読み込みするのではなく、次の順番で確認します。

1. microCMSの公開状態
2. Webhookによるデプロイの開始
3. Cloudflare Pagesのビルド結果
4. Next.jsの静的パス生成
5. 独自ドメインのキャッシュ設定

この順番なら、通常の再ビルド待ちと設定・実装の問題を短時間で切り分けられます。