Netlifyで公開していたWebアプリを更新したのに、本番サイトへ反映されない。
読者
YuLab
私の場合、原因はコードやGitHubではなく、Netlifyの無料枠のクレジット上限でした。
2026年8月19日〜23日の5日間で270 creditsを消費していました。
NetlifyのFreeプランは現在、月300 credits。Production deployは1回15 creditsなので、単純計算すると270 creditsは約18回分のProduction deployに相当します。
私はAIやCodexを使いながらWeb制作をしているため、
「少し直す → 公開する → 実際に見る → また直す」
という作業をかなり短い間隔で繰り返していました。
この記事では、なぜNetlifyの無料枠を短期間で使い切ったのか、どうすればクレジット消費を抑えられるのか、そして無料環境と有料環境をどう考えればいいのかを、実体験をもとにまとめます。
結論：細かな修正を毎回Production deployしていたのが大きな原因
今回の原因をシンプルに言うと、
細かな変更のたびに本番環境へデプロイしていたこと
でした。
AIを使うとコードの修正そのものはかなり速くなります。
たとえば、
- 文字位置を少し調整する
- 表示を数px動かす
- アニメーションを変える
- 文言を直す
- GA4などの設定を確認する
といった小さな変更も短時間でできます。
すると、
修正
→ GitHubへ反映
→ 本番デプロイ
→ 実際の画面を確認
→ また修正
というサイクルも速くなります。
制作速度が上がった一方で、公開環境側の利用上限も同じ速度で消費していたわけです。
Netlifyのクレジットとは？
現在のNetlifyでは、Freeプランに月300 creditsの上限があります。
Production deployは1回15 creditsです。
一方で、Deploy Previewやbranch deployは0 creditsで利用できます。
つまり、同じ「デプロイ」でも、本番公開と確認用デプロイではクレジット消費が違います。
私の場合は、この違いを十分理解しないまま、GitHubのmainへ細かな変更を何度も反映していました。
「無料だから、普通に使っている限り大丈夫だろう」
くらいの感覚でした。
しかし、AIを使った開発では「普通の更新頻度」そのものが変わります。
実際に5日間で270 creditsを使った
確認すると、2026年8月19日〜23日の5日間でProduction deployによる消費が270 creditsまで増えていました。
Production deployが1回15 creditsなので、
270 ÷ 15 = 18
となり、約18回分です。
5日間で約18回なので、1日平均では3〜4回程度。
AIを使って、
「ちょっと直して確認する」
を繰り返していると、個人的にはそこまで多い感覚ではありませんでした。
ここが一番の気づきでした。
従来の自分の制作速度なら、そもそも1か月の中でここまで何度も修正・公開できなかったと思います。
AIによってコードを書く時間が短くなった結果、これまで遭遇しなかったインフラ側の制限に早くぶつかったとも言えます。
なぜ本番環境で何度も確認したくなるのか
もちろん、
「細かな変更をまとめてから公開すればいい」
という考え方もあります。
実際、それはクレジット節約には有効です。
ただ、Web制作を始めたばかりの自分にとっては、コードだけを見て完成形を正確に想像するのは難しいです。
実際に画面を見ることで、
「少し位置がおかしい」
「思っていた動きと違う」
「ここの切り替えが不自然」
という新しい疑問が出てきます。
私の場合は、
試す → 変化を見る → 疑問が出る → 考える → また試す
という流れそのものが制作になっています。
特にAIを使った制作では、最初の0→1はかなり速く作れます。
一方で、その後の1→100に近づける微調整は、実物を見ながら何度も直すことが多いです。
そのため、更新回数を単純に減らせばいいとも思っていません。
Netlify無料枠を節約するための対策
今回の経験から、Netlifyを無料で使い続けるなら、本番公開と確認作業を分けることが重要だと考えるようになりました。
まず使いやすいのがDeploy Previewやbranch deployです。
現在これらは0 creditsなので、確認段階ではPreviewを使い、公開して問題ない状態になってからProduction deployする方がクレジットを節約できます。
また、細かな修正をすべて1回ずつ本番へ送るのではなく、
「この3点を確認してから本番へ反映する」
のように、ある程度まとめる方法もあります。
ただし、すべての変更を大きくまとめる必要はありません。
自分のように実物を見ながら考えるタイプの場合、確認回数を減らしすぎると、逆に制作しづらくなることもあります。
重要なのは、
何をPreviewで確認し、何をProductionで確認するのかを分けること
だと思います。
AI開発では「コード以外の制限」も確認した方がいい
今回の失敗で、AIを使った開発ではコード生成速度だけ見ていてはいけないと感じました。
外部サービスを利用する場合は、
- 何をすると利用量が増えるのか
- API利用料は発生するのか
- デプロイ回数に制限はあるのか
- 月間上限はあるのか
- 上限到達後にどうなるのか
といった部分も先に確認した方が安全です。
AIによって作業速度が上がるほど、外部サービスの消費速度も上がる可能性があります。
「無料枠があるから大丈夫」ではなく、
自分の開発速度で使った場合にどうなるか
まで見る必要があります。
無料運用が向いているケース
だからといって、Netlifyの無料枠が使いにくいという話ではありません。
1つのサイトを公開して、更新頻度がそれほど高くないのであれば、無料枠でも十分なケースは多いと思います。
Deploy Previewも活用できます。
むしろ無料枠があることで、
「本当に本番公開する必要がある変更か」
を考えるきっかけになる面もあります。
細かな修正を何でもすぐ本番へ反映するより、ある程度整理してから公開する習慣が身につく可能性もあります。
有料環境を検討してもいいケース
一方で、私の場合は状況が少し変わってきました。
穴埋めノートだけでなく、複数のWebアプリやポートフォリオを作り、今後はWordPressでブログも運用する予定があります。
さらにAIを使って、
作る
→ 試す
→ 修正する
→ また試す
という回数も増えています。
その状態で毎回、
「あと何回デプロイできるだろう」
と考えること自体が管理コストになっていました。
そこで現在は、穴埋めノートを含む制作物をConoHa WING側へ移行しています。
穴埋めノートについては、現在NetlifyではなくConoHa WING上で公開しています。
「無料か有料か」は料金だけで決めなくなった
もともと私は、できるだけ無料サービスを使いたいと考えていました。
今でも、その考え自体は変わっていません。
ただ、今回の経験から、
無料 = コスト0
ではないと思うようになりました。
無料サービスを組み合わせることで、
- 利用制限を確認する時間
- サービスごとの仕様を覚える時間
- 上限を管理する時間
- 問題が起きた時に原因を調べる時間
- 別サービスへ移行する時間
が増える場合があります。
お金はかからなくても、時間は使っています。
そのため現在は、
追加料金 < 削減できる時間・管理負担・試行錯誤のしやすさ
になっているかで判断するようになりました。
ただし、有料にすれば正解というわけでもありません。
有料サービスは、使わなくても固定費が発生します。
私自身も、ConoHa WINGを契約したことが本当に正解だったかは、まだ最終判断していません。
今後、
記事を作る
→ アクセスが増える
→ 最終的に収益につながる
ところまで見て、費用対効果を判断するつもりです。
【PR】WordPress用サーバーの比較候補
私は現在ConoHa WINGを使っていますが、これからWordPressを始める場合は、XServer系も比較候補に入ります。料金だけでなく、サポートや運用のしやすさも含めて、自分に合う方を選ぶのがおすすめです。
まとめ
今回、Netlifyの無料枠を5日間で大きく消費したことで、AI開発では「コードを書く速度」だけではなく、その速度を受け止められる公開・検証環境も重要だと分かりました。
Netlifyの無料枠を使う場合は、Deploy Previewやbranch deployを活用し、Production deployと確認作業を分けることでクレジットを節約できます。
一方で、複数の制作物を運用し、AIを使って高頻度に試行錯誤する場合は、料金だけでなく管理時間や確認のしやすさまで含めて環境を選ぶ方がいいと思います。
この記事で触れた「穴埋めノート」は、現在実際に公開しています。
AIと一緒に作りながら改善を続けている学習用Webアプリです。興味があれば、実際の穴埋めノートを触ってみてください。
AIを使った学習問題の設計については、AIで穴埋め問題を作るときの3つのチェックポイントでも具体的に紹介しています。
コメント