契約プランは$20/月。しかし実際の請求は$132.62——超過分は約$112でした。
この検証では、その原因を特定し、対策を実施しました。主因はサーバーレス構成の常時起動コストではなく、ビルド回数の多さでした。
この検証の概要
検証時期 | 2026年6月2日〜（対応継続中） |
|---|---|
対象 | Vercel（Proプラン $20/月） |
問題 | 実請求 $132.62（On-Demand超過 約$112） |
主因 | Build CPU Minutes が全体の約90% |
対応 | Ignored Build Step で production 以外のビルドを停止 |
状況 | 止血対応は完了、運用フロー整備が残課題 |
結論：ビルド回数が9割を占めていた
請求の内訳を確認したところ、構造がはっきりしました。
項目 | 金額 | 割合 |
|---|---|---|
Build CPU Minutes | $145.43 | 約90% |
Fast Origin Transfer | $2.53 | 少額 |
Fluid Active CPU | $1.80 | 少額 |
「サーバーレスだから実行コストが高いのでは」という想定は外れました。実行時のCPU課金（Fluid Active CPU）は$1.80で、超過分としては軽微です。
膨らんでいたのはビルドでした。
なぜビルドが積み上がるのか
デフォルトの挙動が原因です。
GitHub連携では、デフォルトで全ブランチへのpush・PR作成時に自動でデプロイ（ビルド）が実行されます。
つまり、こうなります。
- featureブランチにpushするたびにビルド
- PRを作るたびにビルド
- mainへの細かいマージが多いほど、そのたびに本番ビルドが走る
この検証では、featureブランチ運用が確立されておらず、mainへの細かいPR・マージが多い状態でした。開発の進め方が、そのまま課金に反映されていたことになります。
対処①：production以外のビルドを止める
最も効果の大きい対応です。
Ignored Build Stepを「Only build production」に設定しました。
if [[ "$VERCEL_ENV" == "production" ]]; then exit 1; else exit 0; fiこれにより、featureブランチや未割り当てブランチへのpush/PRではビルドが走らなくなります。
ここで押さえるべき仕様の違いがあります。
キャンセルされたビルドはデプロイメントクォータにカウントされますが、スキップ（ビルド未実行）はCPU消費が発生しません。
組み込みのオプションによるスキップと、bashコマンドでキャンセルする方式は仕組みが違います。コスト削減が目的なら、スキップさせる必要があります。
対処②：ビルドマシンの種別を確認する
もう1つの大きなコスト要因です。
マシン種別 | 単価 |
|---|---|
Turbo（固定） | $0.126/分 |
Elastic（自動スケール） | $0.0035/CPU分から |
多くのプロジェクトでコストが半減以上します。
新規チームではElastic Build Machinesがデフォルトですが、以前から使っているプロジェクトはTurbo固定のままになっている可能性があります。確認する価値のある設定です。
止血だけでなく上限を設ける
この検証で最も重要な指摘かもしれません。
Spend Managementを設定しない限り、On-Demand超過は上限なく課金され続けます。
対策として、50%/75%/100%での通知と、上限到達時にproductionを自動停止する設定が可能です。新規Proチームは$200がデフォルト予算になっています。
ただし注意点があります。
チェックは数分ごとのため、上限到達後も数分は課金が継続しうる。絶対上限より低い値を設定するのが安全です。
「上限を設定したから絶対に超えない」ではありません。余裕を持った値にしておく必要があります。
その他のコスト削減策
vercel.jsonでブランチ単位制御 —git.deploymentEnabledでパターン指定のデプロイ無効化- Turborepo Remote Cache — モノレポなら追加費用ゼロでビルド時間を最大85%削減（全プラン無料）
- On-Demand Concurrent Buildsを「1ブランチ1ビルド」に制限 — 並行ビルドの無駄を抑制
- Active CPU課金の理解 — I/O待ち中は課金されないため、Cache-ControlやISRの設定でActive CPU消費を削減できる
Remote Cacheは全プラン無料です。モノレポ構成なら、設定するだけで効果が出ます。
他プラットフォームとのコスト比較
プラットフォーム | ビルド | 帯域 | 備考 |
|---|---|---|---|
Vercel | $0.0035/CPU分〜（Elastic） | $0.15/GB（超過） | Next.js最適化が最強、コストは高め |
Cloudflare Pages | 月500ビルド（無料）、実質無制限に近い | Egress無料 | コスト最安、帯域課金なし |
Netlify | 100分/月（無料） | 100GB/月（無料） | 2025年に無料枠を300分→100分へ削減 |
Render | 月500ビルド分（無料） | 100GB/月（無料） | フルスタック対応、Next.js最適化は弱い |
判断の軸は明確です。
Next.js以外（Astro等）なら、Cloudflare Pagesへの移行でビルド・帯域コストをほぼゼロに近づけられます。
逆にNext.jsを使うなら、統合・DX・Preview体験の価値とコストを天秤にかけることになります。
トレードオフ
ビルドを止めることには代償があります。
featureブランチ単位のPreview URLが発行されなくなります。動作確認はdevelop/mainマージ後に行う運用へ変わります。
この検証では、現状Preview確認が運用に組み込まれていないため実害なしと判断しました。
使っていない機能のためにコストを払っていた——という構造です。設定を見直す前に、実際に使っているかを確認する価値があります。
対応ロードマップ
優先度 | 内容 | 状態 |
|---|---|---|
高 | Ignored Build Stepを「Only build production」に設定 | 完了 |
高 | mainへの直接プッシュ防止 | 完了 |
中 | Spend Limitをハードリミットに変更 | 今後 |
低 | featureブランチ運用へ移行（作業者 → feature/* → develop → main） | ゆくゆく |
止血（ビルド停止）を先に、体質改善（運用フロー）を後にという順番です。課金は待ってくれないため、この順序が現実的です。
よくある質問
なぜ請求が膨らんだのですか？
ビルド回数の多さが主因です。Build CPU Minutesが全体の約90%を占めていました。実行時のCPU課金は$1.80と軽微でした。
すぐにできる対策は？
Ignored Build Stepを「Only build production」に設定してください。featureブランチやPRでのビルドが走らなくなります。あわせて、ビルドマシンがTurbo固定になっていないか確認すると効果が大きくなります。
上限を設定すれば安心ですか？
チェックが数分ごとのため、上限到達後も数分は課金が継続しうる点に注意してください。絶対上限より低い値を設定するのが安全です。
他プラットフォームへの移行は有効ですか？
Next.js以外を使っているなら有効です。Cloudflare Pagesならビルド・帯域コストをほぼゼロに近づけられます。Next.jsを使う場合は、統合とDXの価値との比較になります。
まとめ
- 超過の主因は常時起動コストではなくビルド回数。Build CPU Minutesが約90%
- デフォルトでは全ブランチへのpush・PRでビルドが走る
- Ignored Build Stepで production 以外をスキップする。キャンセルとスキップは仕組みが違う
- Turbo固定とElasticでは単価が大きく違う（$0.126/分 vs $0.0035/CPU分〜）
- 上限設定がなければ超過は無制限に続く。ただし到達後も数分は課金されうる
- モノレポならRemote Cacheが無料でビルド時間を最大85%削減
- 使っていない機能（Preview URL）のためにコストを払っていないかを確認する
クラウドサービスのコストは、機能の使い方ではなく開発の進め方に反映されます。請求内訳を分解すると、どの習慣が効いているかが見えてきます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制とインフラ運用を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。