ホーム › 失敗談・学び › Netlify無料枠が深夜に枯渇した話と緊急移管
失敗談・学び

Netlify無料枠が深夜に枯渇した話と緊急移管

公開: 2026-05-19 · 著者: GRAMSHIFT

無料枠で運用するクラウドサービスは「いつか必ず枯渇する」前提で備える

Netlify無料枠が深夜に枯渇した話と緊急移管

Netlify から移管して学んだことを、先に3点だけ置いておきます。

  1. Netlify 無料プランの月 300 build minutes は、毎日複数回デプロイする運用では 1 ヶ月持たない ことがある (Netlify 公式: 月 300 分上限、超過時はビルド停止)
  2. 緊急移管先として「契約済みクラウドリソース (ConoHa WING マルチドメイン無制限)」を使えば、追加コストゼロ + 3時間で完全移管が可能
  3. 無料枠依存リスクの本質は「データではなくビルドプロセスのロックイン」。GitHub 連携の便利さと引き換えに、別環境への移管時に手作業が発生する。最初から FTPS デプロイの選択肢を残しておく設計が重要

以下、その夜の経緯、移管手順、無料枠依存リスクへの考え方を、Netlify と Vercel と Cloudflare Pages の無料枠比較を含めて時系列で残します。

あなたがNetlify無料プランでサイトを運用しているなら、月300creditの上限が突然訪れる可能性を知っておく必要があります。私の運用していたあるメディアサイトがこの状況になり、深夜に配信停止寸前まで追い込まれて、3時間でConoHa WINGへ緊急SFTP移管しました。この記事ではその夜の経緯、移管手順、そして「無料枠依存」のリスクへの考え方を残します。同じトラブルに見舞われた個人開発者の参考になればと思います。

枯渇に気づいた瞬間 — 75%消費警告メール

2026年5月初旬、私はNetlifyから「Build minutes usage 75%」というメールを受け取りました。当時はあまり深く考えず、「まあ来月リセットされるだろう」と放置していました。しかし4日後、別のメール「Build minutes used 100%、Builds will fail until next cycle」が届き、初めて事態の深刻さに気づきました。

そのメディアサイトは記事自動生成バッチが毎日新規記事をデプロイするフローで運用していたため、デプロイが止まると毎日の記事更新が完全に停止します。次の billing cycle のリセットまで残り 18日、その間サイト更新ができない状況は集客戦略上致命的です。

3時間で完了した緊急SFTP移管

その夜のうちに、ConoHa WING への移管を決断しました。WING にはマルチドメイン無制限プランを既に契約していたため、サーバー追加コストはゼロです。手順は以下のように進めました。

第一に、WING の管理画面で該当ドメインを追加し、無料独自SSLを有効化。これに 10分。第二に、DNS の A レコードを WING の IP に変更。Netlify から WING への DNS 切替で、TTL の関係で伝播待ち最大1時間。第三に、ローカルのデプロイスクリプト deployer.mjs を deployToNetlify から deployToWing に書き換え。WING は FTPS (port 21 + TLS) しか開いていないため、basic-ftp パッケージを使う実装に変更。これに 90分。第四に、テストデプロイで Coming Soon ページを送信、ブラウザで確認。これに 15分。最後に、本番記事を再デプロイ。これに 30分。

合計で約 3時間、深夜 1時から朝 4時までの作業でした。翌朝、該当サイトは WING 上で正常配信されており、自動デプロイバッチも WING 経由で動き続けるように修正完了。Netlify の枯渇は実害ゼロで乗り切れました。

無料枠依存はリスク、契約済みリソースを優先活用

この事件から得た最大の教訓は「無料枠依存は隠れたリスク」ということです。Netlifyは魅力的なサービスですが、無料プランの月300credit という制限は、頻繁にデプロイする運用 (毎日複数回の自動デプロイ) では1ヶ月持たないことがあります。

個人開発で契約済みのクラウドリソースがあるなら、新サイトもそこに統合するほうが運用は単純になります。私の場合、ConoHa WING のマルチドメイン無制限プランで、ai-pick.tech、prompts.ai-pick.tech、lab.ai-pick.tech、saas-diary.com の4サイトを並走できています。月コストは WING のプラン代だけです。

FTPS への切替で意外と困った点

Netlify は GitHub 連携で自動デプロイできる構成ですが、WING は SSH (port 22) が開いていないため SFTPS が使えず、FTPS (port 21 + TLS) が唯一の選択肢です。basic-ftp パッケージで実装すると、初心者には少し詰まる点がありました。

  • secure: true で FTPS を有効化、secureOptions: { rejectUnauthorized: false } で証明書の厳密検証をスキップ
  • uploadFromDir() は再帰的にアップロードするが、ローカルとリモートのパス対応に注意
  • 同時接続数に制限があるため、並列アップロードでなく逐次アップロードが安全

これらを押さえれば、basic-ftp での FTPS デプロイは安定して動きます。私の実装では現在、3サイト並走で1日複数回のデプロイをエラーなくこなしています。

緊急時の判断軸 — 「即時復旧」を最優先する

クラウドサービスの突然停止に直面したとき、最初に考えるべきは「24時間以内に復旧できる代替手段は何か」です。今回の私の場合、Netflifyから WING への移管が最速ルートでした。新しい有料プランを契約する、別の無料サービスに登録する、自前サーバーを立てるなどの選択肢もありましたが、契約済み WING を使うのが最短で確実でした。

こうした緊急時に冷静に動ける準備として、日頃から「代替先の候補リスト」を頭の中に持っておくことが大事です。クラウドサービスは便利ですが、いざ止まったときに代替を持っているかどうかで、個人開発の事業継続性が決まります。

同様のインフラ運用ノウハウは技術ログカテゴリ、コスト構造判断はビジネスカテゴリに追記しています。

Netlify 無料枠の実態 — 「月300 build minutes」が意味すること

移管後に冷静に Netlify 公式ドキュメントを読み直して、無料プランの実態を整理しました。Netlify Free プランの主要上限は以下の通りです (Netlify Pricing 公式、2026 年時点)。

  • Build minutes: 300 分/月 (超過時はビルド停止、復旧は次の billing cycle まで)
  • Bandwidth: 100 GB/月 (大規模流入時に枯渇リスク)
  • Forms submissions: 100 件/月 (フォーム経由のリード獲得が多いサイトで枯渇)
  • Concurrent builds: 1 (複数サイト並走デプロイ時に待ちが発生)
  • Functions invocations: 125,000 件/月 (Serverless 多用サイトで枯渇)

「月 300 分」だけ見ると十分そうですが、実態は違います。1 回のビルドで 1-3 分消費する静的サイトの場合、1 日 5 回デプロイすると 1 日 5-15 分、1 ヶ月で 150-450 分です。記事自動生成バッチで毎日新規記事をデプロイする運用だと、月の半ばで 100% に到達することは現実的に起こります。

Vercel Hobby プランは Build minutes に明示的な月間上限がない代わりに「Fair Use Policy」で過剰使用時の制限があります。Cloudflare Pages Free プランは月 500 build minutes (Netlify の 1.6 倍) で、同時ビルド数も 1 と Netlify と同じです。無料枠で最大の build minutes を求めるなら Cloudflare Pages、Netlify Forms が必要なら Netlify、と用途別に選び分けるのが現実的です (各社公式 Pricing ページ、2026 年時点)。

緊急移管時の事前準備リスト (チェックリスト化)

3 時間の緊急移管で気づきましたが、移管をスムーズに進めるための「事前準備」はいくつかあります。今回はぶっつけ本番でなんとかしましたが、次に同じ事態が起きたときに 1 時間以内に終わらせるための準備リストとして、以下を整理しました。

  1. DNS 切替の事前準備: A レコード変更先 IP の控え、現在の TTL 値の確認 (TTL 3600 だと最大 1 時間の伝播待ち)、DNS プロバイダ管理画面のログイン情報
  2. 環境変数の引き継ぎ: Netlify Dashboard の Environment Variables を全部メモ、移管先で同じ変数を設定する手順
  3. Forms の代替策: Netlify Forms を使っているなら、移管先で Formspree / Cloudflare Forms / 自前 API に切替が必要、フォーム送信先 URL の更新箇所も控え
  4. 301 リダイレクト設定: Netlify _redirects ファイルや netlify.toml の redirect 設定を、移管先の .htaccess / nginx.conf に書き換え
  5. ビルド済み静的ファイルのローカルバックアップ: 緊急時に dist/ ディレクトリをそのまま FTPS でアップする選択肢を確保 (ビルドが動かない最悪ケース対応)
  6. FTPS / SFTP クライアントの準備: WinSCP / FileZilla / basic-ftp パッケージのインストールと接続テスト、緊急時に「ライブラリのインストールから始める」だと時間ロス
  7. 代替先のサーバー or プランの即時利用可能化: ConoHa WING / Xserver / さくらレンタル の「マルチドメイン無制限プラン」を 1 つ契約しておく、月 1,400-2,000 円の保険料

この 7 項目を 30 分以内にチェックできる状態にしておけば、緊急移管は 1-2 時間で完了可能です。3 時間かかった今回の経験から、事前準備の重要性を学びました。

無料枠依存リスクを最小化する設計原則

クラウドサービスの無料枠は便利ですが、長期運用するメディアサイトで完全依存するのは事業継続性の観点でリスクが大きい判断です。Netlify 枯渇事件から導出した設計原則は以下の 4 つです。

  1. 「いつでも別環境に移管できる」ビルド成果物の独立性を保つ: 静的サイトジェネレータの dist/ ディレクトリだけで完結する設計、特定プラットフォーム固有の機能 (Netlify Functions / Vercel Edge) への依存を最小化
  2. ビルドプロセスをローカル + サーバー共通化する: npm run build で生成された dist/ をどこからでも FTPS / SFTP / S3 / CDN にアップできる構造に。プラットフォームのビルドサーバーに依存しない設計
  3. 無料枠ではない契約済みリソースを優先利用: 既に月額固定で借りているサーバー (VPS / レンタル / マルチドメインプラン) があれば、新サイトもそこに統合。サイト追加の限界費用ゼロが理想
  4. 有料プラン移行コストを事前計算しておく: 「Pro プランで月 $19、500 GB bandwidth」のように、各サービスの値段感を頭に入れておく。緊急時に有料化で凌ぐ選択肢も考慮できる状態に

この 4 原則をすべてのメディアサイト立ち上げ時に意識すると、ベンダーロックインから自由な運用ができます。「動いているから OK」ではなく「いつでも動かせる場所を変えられるか」が個人開発の事業継続性の指標です。

他のホスティング選択肢との比較

移管時に他の代替先も検討しました。結論として WING にしましたが、他の選択肢も知っておくと将来の判断材料になります (各社公式 Pricing、2026 年時点)。

サービス無料枠有料最安プラン静的サイト適性FTPS/SFTP
Netlify300 build min$19/月 (Pro)★★★★★×
VercelFair use$20/月 (Pro)★★★★★×
Cloudflare Pages500 build min$5/月 (Workers Paid)★★★★★×
ConoHa WINGなし¥1,452/月 (ベーシック)★★★★★○ (FTPS)
Xserver スタンダード10日無料¥990/月★★★★○ (SFTP)
さくらレンタル スタンダード2週間無料¥425/月★★★★○ (SFTP)
GitHub Pages1 GB / 100 GB BW無料 (Public)★★★★×

個人開発の長期運用では「マルチドメイン無制限 + FTPS デプロイ可能」の組み合わせが最強です。サイト数を増やしても月額コストが固定で済むため、不労収入のためのサイト群量産戦略と完全に一致します。Netlify / Vercel / Cloudflare Pages の Jamstack 系は単一の派手なサイトには優秀ですが、4-10 サイトを並走運用する場合は WING / Xserver / さくら の方が経済合理性が高くなります。

緊急移管後に変えた運用フロー

今回の事件後、メディアサイト全体の運用フローを見直しました。具体的な変更点は以下の通りです。

  1. すべての新サイトを ConoHa WING マルチドメインに集約: ai-pick.tech / lab.ai-pick.tech / saas-diary.com / host.ai-pick.tech をすべて WING で運用。サブドメ追加コストゼロ
  2. FTPS デプロイを標準化: scripts/deploy-site-v2.mjs --site=... で全サイト共通の FTPS デプロイ。basic-ftp パッケージで実装、ECONNRESET エラー時の自動リトライ込み
  3. 毎日のバックアップに dist/ を含める: ビルド成果物自体もバックアップ対象に。緊急時に dist/ をそのままアップすれば即復旧可能
  4. 本人作業 + 自走バッチ両方からデプロイ可能な共通スクリプト: Claude Code からの手動デプロイと Windows Task Scheduler からの自走デプロイで同じスクリプトを共有、設計の二重化を回避

この体制になってから、Netlify のような「サービス側の事情で停止」のリスクから解放されました。月 1,452 円の WING ベーシックプラン代だけで 4-5 サイトを安定運用できています。年間 17,424 円、無料枠依存リスクを完全に排除できる保険料としては安いと判断しています。

緊急時の判断軸の整理 — 「即時復旧」を最優先する

クラウドサービスの突然停止に直面したときの判断軸は明確です。「24 時間以内に復旧できる代替手段の中で、最も確実なものを選ぶ」です。今回の私の場合、Netlify から WING への移管が最速ルートでした。新しい有料プランを契約する、別の無料サービスに登録する、自前サーバーを立てるなどの選択肢もありましたが、契約済み WING を使うのが最短で確実でした。

緊急時に冷静に動くための事前準備として、以下を日常的に整備しておくと安心です。

  • 代替先の候補リスト (最低 3 つ、月額・FTPS 可否・接続情報を控え)
  • DNS プロバイダの管理画面ログイン情報の即時アクセス手段
  • 環境変数の控え (パスワードマネージャ等)
  • ビルド成果物のローカルバックアップ (毎日の自動バックアップに含める)
  • FTPS / SFTP クライアントの接続テスト済み状態

クラウドサービスは便利ですが、いざ止まったときに代替を持っているかどうかで、個人開発の事業継続性が決まります。今回の事件で「クラウドサービスへの依存度を測る」という新しい運用指標を意識するようになりました。

筆者: GRAMSHIFT — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech 等 複数メディア運営。本記事は実体験ログ、移管時の数値や所要時間は実測値です。

あわせて読みたい記事

本記事と関連性の高いトピックを扱った記事です。

よくある質問

Netlify 無料プランは個人開発でどのくらい持ちますか?

月 300 build minutes が上限です。1 回のビルドが 1-3 分かかる静的サイトの場合、毎日 5 回デプロイすると月の半ばで枯渇する可能性があります。Netlify Forms (月 100 件) / Bandwidth (月 100 GB) も上限があり、流入急増時に複合枯渇のリスクがあります。自動デプロイバッチを毎日複数回回す運用なら、最初から Cloudflare Pages (月 500 build min) や有料プラン、または FTPS 対応のレンタルサーバー (ConoHa WING / Xserver / さくら) を検討するのが現実的です。

Netlify から ConoHa WING への移管はどれくらい時間がかかりますか?

私の場合は深夜の緊急対応で 3 時間でした。内訳は WING ドメイン追加 + SSL 10 分、DNS 切替 + 伝播待ち 60 分、デプロイスクリプト書き換え 90 分、テスト + 本番再デプロイ 30 分です。事前準備 (DNS 切替手順 / 環境変数控え / FTPS クライアントテスト) を済ませておけば、次回以降は 1-2 時間で完了できる見込みです。事前準備チェックリスト 7 項目を本記事内に整理しました。

WING の FTPS デプロイは Netlify と比べて運用しにくくありませんか?

初回設定は手間ですが、軌道に乗れば運用負荷は変わりません。basic-ftp パッケージで `npm install basic-ftp` 後、deploy-site-v2.mjs のような共通スクリプトを書けば、Claude Code 経由でも Windows Task Scheduler 経由でも同じコマンド一発でデプロイ可能です。ECONNRESET エラーが時々発生するため自動リトライ実装が必要で、ここが Jamstack 系 (Netlify / Vercel) と比べた運用上の差ですが、慣れれば許容範囲です。

無料枠依存リスクを最小化するには何を意識すれば良いですか?

4 つの設計原則があります。(1) ビルド成果物 (dist/) の独立性を保ち、特定プラットフォーム固有機能への依存を最小化、(2) ビルドプロセスをローカル + サーバー共通化、(3) 既存の契約済みリソース (VPS / マルチドメインプラン) を優先利用、(4) 各サービスの有料プラン移行コストを事前把握。この 4 原則を立ち上げ時から意識すると、ベンダーロックインから自由な運用が可能になります。