Vercel 料金を抑えるBasicビルドマシンの見極め方

Vercel 料金を見直すとき、判断材料は安い分単価だけではありません。2026年9月3日、VercelはProとEnterprise向けに、2 vCPUs、8 GBのメモリ、ビルド時間（分）あたり$0.007の新しいBasicオプションを追加しました。ただし、実行時間、端数の切り上げ、失敗、キュー待ちを反映した完了ビルドあたりのコストでElasticを下回る場合に限って、請求額を減らせます。

Vercelで変わったこと

ビルドマシンとは、Vercelが依存関係のインストール、アプリのコンパイル、デプロイの準備に使う一時的なコンピューターです。有料プロジェクトには、より小さな固定構成が加わりました。BasicビルドマシンはHobbyだけでなく、ProとEnterpriseでも利用できます。

Basicは2 vCPUs、8 GBのメモリ、32 GBのディスクを備えます。Elasticはプロジェクトのワークロードに応じて、4〜30 vCPUsと8〜60 GBのメモリを割り当てられます。新しい有料プロジェクトの既定値は、引き続きElasticです。

選択肢が増えたのであって、有料プランの新しい既定値になったわけではありません。新しい有料プロジェクトは引き続きElasticで始まり、Ownerはチームまたはプロジェクトの設定からBasicを選べます。Hobbyプロジェクトでは、従来から含まれていた2 vCPUのマシンがそのまま使われ、名称だけがBasicになりました。

この記事では、ビルドマシンの選択だけに焦点を絞ります。プラン料金、利用クレジット、シート、トラフィック、Functions、ストレージ、アドオンは、引き続きVercel料金の完全ガイドで確認できます。

Vercel 料金は完了ビルドあたりで比べる

BasicとElasticのCPU単価は、どちらもCPU時間（分）あたり$0.0035から始まります。Basicは常に2 vCPUsを使う一方、Elasticは4〜30 vCPUsを割り当てるため、実際の請求額に差が生まれます。

Vercelは各ビルドの所要時間を分単位で切り上げます。実務では、次の式で計算できます。

• Basic： 切り上げ後のビルド時間（分）× $0.007。
• Elastic： 切り上げ後のビルド時間（分）× 割り当てvCPU数 × $0.0035。

最小の4 vCPU構成でも、Elasticは請求対象のビルド時間（分）あたり$0.014からです。Basicの分単価はその半分なので、Basicの請求時間がちょうど2倍なら同額、2倍未満ならBasicのほうが安くなります。

Elasticに4 vCPUsを超える構成が割り当てられると、この基準も変わります。また、Vercelが月次合計ではなくビルドごとに所要時間を切り上げるため、分の境界をまたぐたびに結果が変わります。請求額を判断するには、料金表だけで推測せず、実際の所要時間と割り当てられたマシンを確認する必要があります。

この例では$7を確かに節約できますが、それに価値があるとは限りません。プレビューのたびに開発者、レビュアー、コーディングエージェントの作業が止まるなら、フィードバックの遅れが請求額の削減分を上回る可能性があります。ビルドをバックグラウンドで実行でき、キューも詰まらないのであれば、Basicのほうが単位コストに優れます。

失敗したビルドも分子に含めてください。見るべき運用指標は、ビルド料金の総額を成功したデプロイ数で割った値です。分単価が安くても、再試行が増えるマシンでは、本当に購入している成果に対するコストが高くなりかねません。

キュー待ちもワークフロー上のコストになる

Vercelが公開している請求式に入るのは、ビルド時間とCPU数です。キュー待ちは別の課金項目ではありませんが、その遅延はチームの作業に響きます。

オンデマンド同時実行を無効にしている場合、Proには同時デプロイスロットが3個あります。稼働中のスロットを超えたビルドは待機します。オンデマンド同時実行では、Vercelは最大500件の同時デプロイを掲げ、使用したビルド時間に対して課金します。

Basicでビルドが遅くなれば、その分だけスロットを長く占有します。小さなサイトを日に数回デプロイする創業者なら、問題にならないかもしれません。一方、コーディングエージェントが複数のプレビューを作る場合、制作会社が多数の顧客プロジェクトをデプロイする場合、チームが複数のブランチへ同時にプッシュする場合は、すぐに影響が表れます。

次の両方を記録してください。

• ビルド時間： 分単位で切り上げた後のマシン料金を決めます。
• キュー待ち＋ビルド時間： フィードバックが返るまでの時間を決めます。

判断に必要なのは、この2点です。前者を最適化しても、後者でワークフローを損なわないようにしてください。

Basicを試す価値があるのは誰か

小規模アプリを運営する個人創業者

SaaSを一人で運営する創業者なら、軽量なマーケティングサイトやダッシュボードをプロジェクト単位でBasicに切り替え、同じ代表的なビルドをElasticと比較できます。Vercelプランのほかの部分を変えずに、継続的なビルド料金を抑えられるのが利点です。

切り替えを維持する価値があるのは、ビルドの信頼性を保てて、実行時間が延びたとしてもリリースを遅らせない場合だけです。デプロイ頻度が低いプロジェクトでは、金額差が小さすぎて個別調整に見合わないこともあります。

性質の異なる顧客案件を抱える制作会社

制作会社が全顧客に同じマシン判断を適用するべきではありません。小規模なランディングページやコンテンツ案件は、プロジェクトごとにBasicへ固定していきます。大規模なストアフロント、モノレポ、依存関係の重いアプリは、実測でBasicが有利だと分かるまでElasticに残します。

利点は、プロジェクトごとの利益率が明確になることです。リソース消費の少ない顧客案件まで、制作会社で最も重いアプリと同じビルドマシンを使う必要はなくなります。

コーディングエージェントを運用するエンジニアリング責任者

エージェント主導の開発では、コスト計算に効くビルド回数が変わります。自動コミットが増えればプレビュービルドも増えるため、ビルドごとの小さな差が何度も積み重なります。

エンジニアリング責任者が測るべきなのは、静かな時間帯のデプロイではなく、通常規模のバーストです。Basicで完了ビルドあたりのコストが下がっても、実行時間の長期化によって利用可能な3スロットが埋まり、キューが発生するなら、安いマシンはコストを請求書から待ち時間へ移しただけです。

Enterpriseのプラットフォーム責任者

BasicはEnterpriseでも利用できますが、契約条件によってはセルフサービスで変更できません。契約でEnhancedマシンが有効になっているEnterprise顧客は、そのマシンが既定で使われます。マシン設定を変更するには、アカウントマネージャーへの連絡が必要です。

プロジェクト単位でBasicへ切り替えて検証する方法

まずはプロジェクト単位で変更します。無関係なアプリを実験に巻き込まずに済み、同じ設定画面から簡単に元へ戻せます。

1. 1

   Elasticの基準値を記録する

   Vercel ObservabilityでBuild Diagnosticsを開き、代表的なデプロイを選びます。ビルド時間、割り当てマシン、請求対象の使用量、キュー待ち、デプロイが完了したかどうかを記録してください。Basicでの実行と比較できるよう、キャッシュ条件とコードのリビジョンをそろえます。

2. 2

   プロジェクトでBasicを選ぶ

   Vercelでプロジェクトを開き、Settings、Build and Deployment、Build Machineの順に進みます。Basicを選んで保存してください。Vercelのドキュメントではチーム単位でも同じ選択ができますが、最初の検証はプロジェクト設定のほうが安全です。ビルドマシン設定へアクセスするには、Ownerロールが必要です。

3. 3

   ドキュメント記載のCLI手順を使う

   Vercel CLI 59.6.0以降では、次のコマンドでプロジェクトの設定を変更できます。

   vc project update --build-machine basic

   よくあるのは、古いCLIを実行し、マシンを選べないと早合点するケースです。コマンドが失敗してもプランの制限だと判断せず、まずバージョンを確認してください。

4. 4

   同じワークロードを実行する

   キャッシュ条件をそろえ、同じ代表的なリビジョンをビルドします。所要時間、マシン、請求対象の使用量、キュー待ち、完了の可否という同じ項目を記録してください。エージェント主導の作業では、キューの挙動も確認できるよう、通常規模のバーストを含めます。

5. 5

   成果を基準に選ぶ

   月間ビルド料金の総額を計算し、成功したデプロイ数で割ります。この単位コストが下がり、全体の所要時間もチームの目標内に収まるならBasicを維持します。速度、メモリ、信頼性の悪化で節約分が消えるなら、Build Machine設定からElasticへ戻してください。

見落としてはいけない制約

BasicはElasticを効率化したものではなく、単純に小さなマシンです。メモリ上限は8 GBに固定されています。Elasticはワークロードに応じて、最大60 GBのメモリと30 vCPUsまで拡張できます。

分単位の切り上げによって、わずかな節約が消えることもあります。分単位の境目を数秒超えただけで、請求対象が丸ごと次の分まで増えます。ストップウォッチの値を都合よく丸めるのではなく、Vercelに表示される請求対象の使用量を比較してください。

Elasticはプロジェクトの変化にも適応し続けますが、Basicの構成は固定です。今の小規模アプリに合うマシンでも、依存関係、ルート、生成アセットが増えれば不適切になる可能性があります。

今すぐ試すべきか、待つべきか

• 今週試す： ProまたはEnterpriseのプロジェクトで、低リソースの安定したビルドを実行しており、継続的なビルド単価の差が効くほど件数が多い場合です。
• 待つ： プロジェクトがCPU依存、メモリ負荷大、45分の上限に近い、またはプレビューのキューにすでに影響されている場合です。まず、比較可能なElasticの基準値を確立してください。
• 料金変更を気にしなくてよい： Hobbyを利用している場合です。付属の2 vCPUマシンはBasicへ改称されましたが、マシンとプラン上の扱いは変わりません。
• 先に契約を確認する： EnterpriseでEnhancedマシンが有効な場合です。変更はアカウントマネージャーの管轄かもしれません。

月曜日にやること

月曜日に、代表的な小規模プロジェクトを選びます。同じビルドをElasticとBasicで実行し、所要時間、請求対象の使用量、割り当てCPU数、キュー待ち、完了の可否を記録してください。完了ビルドあたりのコストを下げつつ、チームが求める所要時間も守れるほうを採用します。

予算やワークフローを左右するプラットフォーム変更を、平易な言葉で解説するニュースレターにご登録ください。