ひとことで言うと
Deploymentsタブを開く → 新しいビルドが来ているか確認
↓ビルドが来ていない
Settings → Git repository → Manage → GitHubを再認証
→ git commit --allow-empty -m "force deploy" && git push
まずDeploymentsタブで「ビルドが来ていないのか」「来ているが失敗しているのか」を切り分ける。何も来ていなければOAuth切断が9割。
やりたかったこと
記事を更新してgit pushしたのに、Cloudflare Pagesのサイトに変更が全然反映されなかった。いつもは1〜2分で更新されるのに、30分待っても何も変わらない。Deploymentsタブを開いたら新しいデプロイが一切来ておらず、最後のデプロイが昨日のままになっていた。
最初は「自分の回線の問題かも」と思ってスマホのモバイル回線でもサイトを確認した。同じ古い内容が表示されていた。「Cloudflare側がキャッシュを返しているのでは」とも考えたが、サイト自体は問題なく表示されているのでサーバー障害ではないと判断した。ここが最初の判断ミスで、「サイトが表示される=デプロイが動いている」という思い込みがあった。実際にはキャッシュされた古いバージョンが表示され続けていただけで、デプロイ自体は完全に止まっていた。
プロジェクトのトップを確認したら薄いオレンジのバナーがあった。
This project is disconnected from your Git account.
This may cause deployments to fail.
「May cause」という曖昧な書き方だったので深刻に受け止めていなかったが、これが原因だった。
自動デプロイが止まる原因は「ビルドが来ない」「ビルドは来るが失敗する」「デプロイは成功するがサイトに反映されない」の3パターンに分かれる。最初にDeploymentsタブを開いて「ビルドが来ているかどうか」だけ確認する一手間が、診断時間を大幅に短縮する。
環境
- Cloudflare Pages(2026年5月時点)
- GitHub(private/publicどちらでも発生)
- Astro 5.2.3
- Node.js 20.11.0
試したこと・うまくいかなかったこと
コードを疑ってローカルでビルド確認 → コードの問題ではなかった
「変なコードを入れたか?」と思って git diff で確認したが問題なし。ローカルで npm run build したら正常に通った。コードの問題ではないとわかったが、ではなぜデプロイが来ないのかわからなかった。
次にDeploymentsタブを全部見直したが「Failed」のビルドがあるわけではなく、新しいビルド自体が全く来ていなかった。「ビルドが失敗している」と「ビルドが来ていない」は全く別の問題で、診断の入口が変わってくる。ここで「ビルドが来ていない」のだから接続の問題だとすぐ気づくべきだったが、ビルド設定を疑ってSettings画面を調べ始めてしまった。
git push --force まで試した → 何も起きなかった
「もう一度pushすれば直るかも」と git push を再実行し、最終的に git push --force まで試したが、Cloudflareは全く反応しなかった。GitHubとCloudflareの接続が切れているのだから、どんな形でpushしても届かない。pushが成功しても「GitHubにコミットが届いた」というだけで、「Cloudflareがそのpushをトリガーにビルドした」とは別のことだった。
GitHubのWebhook deliveryログを確認したら、最新エントリのHTTPステータスが 401 Unauthorized になっていた。
POST https://api.cloudflare.com/client/v4/pages/webhooks/deploy/...
Response: 401
{"result":null,"success":false,"errors":[{"code":10000,"message":"Authentication error"}],"messages":[]}
これでOAuthトークンの失効が原因だと確定した。
ブランチ名の不一致でビルドが来なかったケース(別の機会)
別の日に master ブランチで作業してpushしていたのに、CloudflareのProduction branchが main に設定されていてデプロイが走らないことがあった。git branch でカレントブランチを確認したら確かに master だった。
git branch
# * master
# main
git checkout main して git merge master してから git push origin main でビルドが来た。
ビルド成功なのにサイトが更新されないケース
ビルドは来るし「Success」になるのにサイトが更新されない現象もあった。CloudflareのCDNキャッシュが古いものを返し続けていたのが原因で、「Purge Cache」を手動で実行したら解決した。Cloudflareダッシュボードの「Caching」→「Configuration」→「Purge Everything」でキャッシュを削除できる。
ブラウザのスーパーリロード(Ctrl+Shift+R)ではCloudflare CDNのキャッシュは削除できない。「自分のブラウザだけキャッシュされているのかも」と思って別ブラウザでも確認した。別ブラウザでも同じ古いコンテンツが出ていたのでCDN側の問題だと確定した。
Environment variablesの設定変更がビルドに反映されなかった
NODE_VERSION を設定したのにビルドが古いNode.jsで動いているように見えた。原因はEnvironment variablesの「Production」と「Preview」を別々に設定する必要があることを知らなかったことだった。変数設定の画面では「Production」タブと「Preview」タブが分かれていて、片方だけ設定しても両方には反映されない。「Production and Preview」のタブを選んで同時に設定するか、両方のタブでそれぞれ追加する必要があった。Previewのビルドだけで確認していたので本番ビルドに反映されず、切り分けに30分かかった。
解決策
原因は3パターン。Deploymentsタブの状態を最初に確認して絞り込む。
Deploymentsタブを開く
│
├─ 新しいビルドが0件(最後のデプロイが昨日以前)
│ ├─ プロジェクトトップにオレンジのバナーあり → 原因1(OAuth切断)
│ └─ バナーなし → GitHubのWebhookを確認 → 401が返っている → 原因1
│ → Deliveryが1件もない → 原因2
│
└─ 新しいビルドエントリあり
├─ Failed → ビルドログを確認 → 原因3
└─ Success → サイトが変わっていない → CDNキャッシュ → Purge Cache
原因1:CloudflareとGitHubの接続が切れている
Deploymentsタブにビルドが全く来ていない場合はほぼこれ。
Cloudflareダッシュボードで「Settings」タブ(上部のタブ)→「Git repository」セクションの「Manage」→GitHubのOAuth認証画面で「Authorize Cloudflare Pages」を選択する。
再認証後は空コミットをpushしてデプロイをトリガーする。再認証しただけでは過去のコミットが遡ってデプロイされない。
git commit --allow-empty -m "force deploy"
git push
再認証後にGitHubのWebhooks画面の「Ping」ボタンを押すと疎通確認ができる。Pingのレスポンスが200なら成功、401なら再認証が不完全。
詳細はCloudflare PagesがGitHubと切断された時の対処法にまとめた。
原因2:監視ブランチの設定が合っていない
git branch # 現在のブランチを確認
別ブランチで作業している場合はmainにマージしてpushする。
git checkout main
git merge 作業ブランチ名
git push origin main
リモートのデフォルトブランチ名の確認:
git remote show origin
# HEAD branch: の行に表示されるブランチ名を確認
CloudflareのSettings → Buildsで「Production branch」がこのブランチ名と一致しているか確認する。
原因3:ビルドエラーが出ている
Deploymentsタブ→該当ビルド→「View build logs」でエラー内容を確認する。よくあるエラーと対処:
Error: Cannot find module '@astrojs/sitemap'
→ package.json の dependencies に含まれているか確認。devDependencies に入れると本番ビルドでインストールされない。
Error: Build failed with exit code 1
→ Settings → Environment variablesで NODE_VERSION=20 を追加する。
Build exceeded the time limit of 20 minutes
→ 画像の最適化処理や大量ページのビルドで発生。npm run build のローカル実行時間を計測して原因箇所を特定する。
ビルドログが大量ある場合は「Download logs」でテキストとして保存してから Error: で検索するのが最速。
CDNキャッシュの問題
ビルドが「Success」でもサイトが更新されないように見える場合は、CDNキャッシュが残っていることがある。
Cloudflareダッシュボードでドメインを選択→「Caching」→「Configuration」→「Purge Cache」→「Purge Everything」でCDNキャッシュを全削除できる。
頻繁にPurgeするとCDNの効果が薄れるので、本当に「Success」なのにサイトが更新されない場合だけ使う。特定ページだけ怪しい場合は「Custom Purge」でURLを指定して部分削除できる。
問題が再発しないようにする
Cloudflare PagesのNotifications機能でビルド失敗のメール通知を設定する。「Workers & Pages」→プロジェクト→「Settings」→「Notifications」で設定できる。
pushした後は毎回Deploymentsタブを確認する習慣をつける。「2分でビルドが来るはず」という感覚が身につくと、来ない場合にすぐ気づける。
ハマったポイント
- サイトが問題なく表示されていたので「回線の問題かも」と最初に疑ったが、Cloudflareのキャッシュが古いバージョンを返し続けていただけだった。「サイトが表示される=デプロイが動いている」という思い込みを捨てて、まずDeploymentsタブを確認するのが正しかった
- 「ビルドが来ていない」のか「来ているが失敗している」のかで原因が全然違う。Deploymentsタブを最初に開いて状態を確認するのが一番早い診断だった。「Failedが来ていれば原因3、何も来ていなければ原因1か2」という切り分けだけ覚えておけばいい
- 再認証後に「GitHubにもうpush済みだから大丈夫」と思い込んでいたが、Cloudflareは認証復旧後に過去のコミットを遡ってビルドしてくれない。認証回復後に空コミットpushが別途必要だと気づくまで20分以上待ち続けた
masterブランチで作業してpushしていたのに、CloudflareのProduction branchがmainに設定されていてデプロイが走らなかった。ブランチ名の不一致は気づきにくい。接続時に設定したブランチ名をgit remote show originで定期的に確認する習慣が防止になる- デプロイ「Success」なのにサイトが更新されない場合はCDNキャッシュが原因のことがある。ブラウザのハードリロードで変わらなければCloudflareのPurge Cacheで解決した。「ビルドはできているのに反映されない」という現象はキャッシュを真っ先に疑う
- Environment variablesはProductionとPreviewを別々に設定する必要がある。Previewだけに設定してPreviewビルドで動作確認したが、本番にも同じ変数が必要なのに設定されておらず本番だけ壊れていた。最初から「Production and Preview」を選ぶか両タブに追加する
よくある質問
Q: git pushしてもDeploymentsタブに何も来ません。バナーも出ていません。 バナーが出ていない場合はGitHubのWebhookを確認する。GitHubの該当リポジトリ → Settings → Webhooks → 「Recent Deliveries」タブを開く。HTTPステータスが401なら再認証が必要。DeliveriesにそもそもエントリがないならCloudflareのProduction branchの設定が実際のブランチ名と一致しているか確認する。
Q: ビルドは「Success」なのにサイトが古いままです。 Cloudflare CDNのキャッシュが原因。Cloudflareダッシュボード → ドメインを選択 → Caching → Configuration → Purge Cache → Purge Everythingでキャッシュを全削除してからブラウザをシークレットモードで確認する。ブラウザのスーパーリロード(Ctrl+Shift+R)では直らない。
Q: force pushしたらデプロイが走らなくなりました。
force pushはGitHubのWebhookをトリガーするが、CloudflareがそのコミットのSHAを「処理済み」として記録しているケースがある。空コミットをpushして強制的に新しいSHAを作ると確実にデプロイがトリガーされる:git commit --allow-empty -m "trigger deploy" && git push
Q: プライベートリポジトリでも自動デプロイは動きますか? 動く。OAuth認証でCloudflare Pagesがプライベートリポジトリにもアクセスできるようになっている。OAuth接続が切れた場合はプライベート・パブリックどちらでも同じように再認証が必要。
Q: デプロイが頻繁に失敗する場合の調査方法は?
Cloudflareのビルド失敗通知をメールで受け取れるよう「Notifications」を設定する。失敗時はDeploymentsタブの該当ビルドから「Download logs」でテキストを保存してERRORキーワードで検索する。失敗パターンが devDependencies か NODE_VERSION の問題であれば1回で解決できることが多かった。
そもそもAstroをCloudflare Pagesに繋いでいない場合はAstroをCloudflare Pagesにデプロイする手順を参考に初期設定を確認してほしい。
関連記事
- Cloudflare PagesがGitHubと切断された時の対処法
- Cloudflare Pagesのビルドログの見方とエラーの対処法
- AstroをCloudflare Pagesにデプロイする手順
- XserverドメインをCloudflare Pagesのカスタムドメインに設定する全手順
ドメイン取得はこちら
Cloudflareと組み合わせるドメインの取得に。
より詳しく学びたい方へ
この記事の内容をさらに深掘りした実践ガイドをZennで公開しています。