Vercel ビルド高速化：Turboを1回だけ使う方法と料金

2026年9月17日、Vercelは、Vercel ビルド高速化の選択肢であるTurboを、プロジェクト全体で使い続ける設定から、1回のデプロイだけに追加費用をかけて使える選択肢へと変えました。急ぎのビルドだけに費用をかけ、次のデプロイからはプロジェクトの通常のマシン設定へ戻せます。

Vercel ビルド高速化のためにプロジェクト設定を変える必要はない

ビルドマシンとは、依存関係のインストール、アプリのコンパイル、デプロイの準備を行う間、Vercelがコードに割り当てる一時的なコンピューターです。固定サイズの選択肢ではTurboが最大で、30 vCPUs、60 GBのメモリ、64 GBのディスクを備えます。

これまでは、固定ビルドマシンを選ぶにはチームまたはプロジェクトの設定変更が必要でした。短い締め切りへの対応には不便です。通常のプレビュービルドを含めてTurboの料金を払い続けるか、急ぎのときだけ設定を変え、後で元に戻すことを忘れないようにする必要がありました。

新しいオーバーライドでは、Turboの指定が1回のデプロイだけに適用されます。プロジェクト設定は書き換えられません。通常はBasic、Standard、Elasticのいずれかを使うプロジェクトなら、再度オーバーライドを指定しない限り、次のデプロイでは通常の選択に戻ります。

ここが実務上の要点です。追加のビルド費用をすべてのコミットではなく、緊急度に応じて使えます。

Turbo、Enhanced、Elasticを利用できるのはProとEnterpriseです。Hobbyプロジェクトは常にBasicを使うため、Hobby向けの高速化スイッチではありません。また、すべてのデプロイですでにTurboを使っているプロジェクトにも効果はありません。

1回のデプロイだけTurboを使う3つの方法

どの方法を使うかは、デプロイを何から開始するかで決まります。どの経路でも、同じく1回のデプロイだけを対象にオーバーライドします。

1. 1

   GitHubのコミットマーカーを使う

   VercelのGitHub連携からデプロイする場合は、コミットメッセージの本文に大文字と小文字を区別した正確なマーカーを入れます。

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   このマーカーは、そのコミットから作られるデプロイだけに適用されます。現時点では、VercelのGitLab連携やBitbucket連携では機能しません。

2. 2

   Vercel CLIを使う

   リンク済みのプロジェクトで次を実行します。

   vc deploy --turbo

   この方法にはVercel CLI 59.20.0以降が必要です。フラグが認識されない場合、まず古いCLIを使っていないか確認してください。

3. 3

   デプロイAPIのフィールドを設定する

   社内のリリースサービスからPOST /v13/deploymentsを通じてデプロイを作成する場合は、そのリクエストでbuildMachineをturboに設定します。このフィールドは任意で、適用範囲はそのデプロイだけです。プロジェクト設定は書き換えません。

プロジェクトのビルドマシンを更新する権限が必要です。また、見落としやすい失敗パターンがあります。Turboが利用できない場合やアカウントに権限がない場合、Vercelはデプロイを失敗させず、プロジェクトの通常のマシン設定を使います。

1回なら小さく、習慣にすると高くなるVercel ビルド料金

Vercelの現在のビルド利用料金は、CPU 1分あたり$0.0035です。請求対象となるビルド時間1分あたりの開始価格に換算すると、Basicは$0.007、課金対象の場合のStandardは$0.014、Enhancedは$0.028、Turboは$0.105です。

請求時間は各ビルドについて1分単位で切り上げられ、その後にマシンのCPU数を掛けて計算されます。そのため、Turboのビルドが3分40秒かかった場合、4分として請求され、料金は$0.42です。

プロジェクト単位でBasicとElasticのどちらを選ぶかについては、VercelのビルドコストをBasicマシンで削減する方法を参照してください。今回の新しい判断はより限定的で、1回の締め切りにTurboの追加料金を払う価値があるかどうかです。

ベンチマークではなく、ワークロードの計算例

あるチームが1週間に通常のデプロイを20回、緊急のデプロイを1回行うとします。チーム自身の計測では、同じワークロードがBasicで7分20秒、Turboで3分40秒かかりました。この所要時間は計算例のために設定したものです。すべてのビルド時間がTurboで半分になるわけではありません。

緊急デプロイ1回のオーバーライドにより、そのデプロイをBasicで実行する場合と比べて$0.364が上乗せされます。この例では、その追加料金によって重要なリリースで実測3分40秒を短縮できます。

通常の20回をBasicのままにすると、21回すべてをTurboで実行するより週間合計が$7.28安くなります。これが新たに得られる予算管理の要点です。実際には、キャッシュの状態、CPU使用率、メモリ負荷、端数の切り上げによって結果が変わるため、自分のプロジェクトの所要時間で判断する必要があります。

この運用が役立つのは誰か

本番修正をリリースする個人開発者

GitHubに接続したSaaSを運営する個人開発者なら、1つのホットフィックス用コミットにマーカーを付けられます。目的はプロジェクトを恒久的に高速化することではありません。障害、顧客との約束、ローンチ予定に関わるリリースの待ち時間だけを短くし、次のプッシュから通常の費用に戻すことです。

締め切りを抱える制作会社のリリース担当者

制作会社なら、レビューを待つ関係者がいるクライアント向けリリースでvc deploy --turboを使えます。通常のプレビューではプロジェクトの普段の設定を維持できるため、クライアントの修正が重なるたびにビルド費用が気づかないうちに増えるのを防げます。

承認フローを持つプラットフォームエンジニア

プラットフォームチームなら、デプロイサービス内で承認済みの緊急リリース経路にだけbuildMachine: "turbo"を追加できます。追加のコンピュートを常設のプロジェクト既定値にせず、ログ記録、レビュー、原価計算が可能な明示的なリリース判断にできます。

誇張せずに押さえたい制約

30 vCPUsだからといって、Basicの2 vCPUsよりビルドが15倍速くなるわけではありません。すべてのコアを使い切れないビルドもあります。Vercelによると、Turboマシンの能力を十分に使わないプロジェクトは多く、通常の処理でElasticがより小さなマシンを選べるのもそのためです。

Turboが変えるのはマシンであり、キューのポリシーではありません。遅延の大半がビルド枠の待ち時間なら、大きなマシンでは問題を解決できない可能性があります。CPUへの追加料金を払う前に、キューで待った時間と実際のビルド時間を比較してください。

キャッシュの状態によっても比較は崩れます。キャッシュが温まった通常ビルドとコールドキャッシュのTurboビルドを比べても、マシンによる差は分かりません。近いリビジョンと同等のキャッシュ条件を使い、実時間だけでなく請求対象の分数も比較してください。

管理された試行を1回行う

1. 1

   通常のデプロイを記録する

   Build Diagnosticsを開き、プロジェクトで通常使うマシン、ビルド時間、キュー時間、請求対象の分数、結果を記録します。確認したい緊急ワークロードに近いデプロイを選んでください。

2. 2

   1回のデプロイだけオーバーライドする

   比較できるデプロイ1回に、GitHubのマーカー、CLIフラグ、APIフィールドのいずれかを使います。チームやプロジェクトのビルドマシン設定は変更しません。

3. 3

   実測した時間短縮に値段を付ける

   1分単位で切り上げたTurboのビルド時間に$0.105を掛けます。その料金を通常デプロイの請求対象利用量と比較し、追加費用を実際に短縮できた時間で割ってください。

4. 4

   次のデプロイを確認する

   マーカー、フラグ、APIフィールドを付けずに、通常のデプロイをもう1回実行します。プロジェクトで普段使うマシン設定に戻っていることを確認してください。これにより、誤ってプロジェクト設定を変更していないかを検出でき、オーバーライドが一時的だったことも証明できます。

今どう動くべきか

• 今週実行する：ProまたはEnterpriseのプロジェクトで、ときどき締め切り優先のリリースがあり、普段のマシン設定は維持したい場合。
• まず計測する：プロジェクトがElasticを使っている場合。すでに十分なCPUとメモリが割り当てられている可能性があり、Turboを強制すると所要時間がほとんど変わらないまま料金だけが増えることがあります。
• プロジェクト設定を使う：ほとんどのデプロイでTurboが必要な場合。コミットごとに例外を繰り返す運用は、フラグに見せかけたポリシーです。
• 対応しない：Hobbyを使っている場合、すでにTurboが既定の場合、または遅延の主因がキューの場合。

月曜日に試すこと

月曜日に代表的なデプロイを1つ選びます。通常ビルドを記録し、Turboのオーバーライドを1回実行し、実際に短縮できた時間に対する追加料金を計算してください。その後、通常のデプロイを実行し、プロジェクトが普段の設定へ戻ったことを確認します。

予算やワークフローに影響するプラットフォーム変更を分かりやすく知りたい方は、ニュースレターに登録してください。