Vercel Elastic Build Machines βでCI短縮実装術

VercelでNext.jsを運用していて、テストは通るのにビルド待ちでPRが止まる。そんなモヤモヤを持つ人に向けて書いています。この記事を読むと、「どこを触れば待ち時間が減るのか」と「どこから課金が増えるのか」を同時に整理できます。設定画面で迷わず判断できるようになり、チームでの合意形成も速くなります。僕は福祉事業のIT全般を担当しつつAI×SaaS開発も続けているので、実務で使える形でまとめます。

Vercel Elastic Build Machines βの正体を最初にそろえる

まず混乱しやすいのが命名です。2026年2月26日更新のVercel公式ドキュメントでは、実際の主語は「Turbo Build Machines」「On-Demand Concurrent Builds」「Build Queue」です。つまり、Elastic Build Machines βという言い方は、実務上は複数機能のまとまりとして理解すると迷いません。イメージとしては「CPUを太くするレバー」と「待ち行列を飛ばすレバー」の2本を同時に触る感じです。

この2軸を分けて考えないと、速くなった理由も料金が増えた理由も見えにくくなります。チームで設定共有するなら、UI名とAPIキー名を先にそろえるだけでも引き継ぎはかなり楽になります。

結論として、まず「処理時間短縮」と「行列回避」を別KPIで管理するのが最短ルートです。 ここを分けるだけで改善の打ち手が明確になります。

Next.js 16.2.1のCIで詰まりやすいポイントと先回り

2026年3月20日にNext.js v16.2.1 が公開され、さらに3月24日の v16.2.1-canary.7 でTypeScript 6周辺の互換性修正が入りました。ここで重要なのは、アプリ本体の変更量よりもCI設定の古さで落ちるケースが増えやすいことです。つまり、コードが悪いというより「足回りのズレ」で失敗している状態ですね。

もう1つ大事なのが、失敗ログを「ビルド失敗」と一括で扱わないことです。設定警告由来の失敗と依存関係由来の失敗を分けるだけで、対処優先度がかなり見えやすくなります。

Vercelの公開実績（2026年2月3日）でも、Turbo導入時の短縮率はビルド時間帯で差があります。2分未満で最大30%、2〜10分で最大50%、10分超で最大70%です。長いビルドほど短縮余地が大きいので、まずは実行時間帯ごとにジョブを分けて測るのがおすすめです。つまり「全部を同じ最適化」で処理しない、これが実務ではかなり大事です。

DashboardでNext.js CI高速化を最短設定する手順

ここからは、まず画面で最短実装する手順です。先にDashboardで動かして、効いた設定だけAPI化する流れが失敗しにくいです。イメージとしては、検証環境で先に配線図を作ってから本番に配る感じですね。

1. Build設定を開く — プロジェクトのBuild関連設定を確認します。
2. ビルドマシンを選ぶ — Standard/Enhanced/Turboから、現状の平均ビルド時間に合わせて選択します。
3. On-Demand Concurrent Buildsを有効化 — 同時ビルド時の待機を減らします。
4. Queueモードを確認 — SKIP_NAMESPACE_QUEUE 相当の設定で行列回避を選びます。
5. PRとmainを分けて観測 — PreviewとProductionで所要時間を別に記録します。
6. 1週間で判断 — 待ち時間、実行時間、Build Minutesをセットで比較します。

2026年2月12日更新のBuild Queues情報では、同時ビルドの基準はHobbyが1、Proが12です。さらにOn-Demand有効時は「builds will never queue」と明記されています。つまり、待機時間を消すにはマシンスペックだけでなくキュー挙動の変更が必須ということです。速度だけ見てTurboに上げても、行列が残れば体感はそこまで変わりません。

運用に迷ったら、最初の1週間だけ「Turbo + On-Demand + Queue回避」を試し、翌週にEnhancedへ戻して差分を見比べると判断しやすいです。

APIで設定をコード化する実装例（elasticConcurrencyEnabled）

Dashboard運用が固まったら、次はAPIで設定をコード化します。自動化しておくと、プロジェクト追加時の設定漏れを防げます。複数案件を並行していると、手作業の差分は想像以上に事故につながります。

まずはcURL例です。PATCH /v9/projects/{id} で elasticConcurrencyEnabled とキュー設定を送ります。

curl -X PATCH "https://api.vercel.com/v9/projects/${PROJECT_ID}" \
  -H "Authorization: Bearer ${VERCEL_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "resourceConfig": {
      "elasticConcurrencyEnabled": true
    },
    "buildQueue": {
      "configuration": "SKIP_NAMESPACE_QUEUE"
    }
  }'

TypeScript SDKでまとめるなら、次の形が運用しやすいです。

import { Vercel } from "@vercel/sdk";

const vercel = new Vercel({ bearerToken: process.env.VERCEL_TOKEN });

await vercel.projects.updateProject({
  idOrName: process.env.VERCEL_PROJECT_ID!,
  requestBody: {
    resourceConfig: {
      elasticConcurrencyEnabled: true,
      buildQueue: {
        configuration: "SKIP_NAMESPACE_QUEUE"
      }
    }
  }
});

注意点は、すべてのリポジトリで同じキュー方針が正解とは限らないことです。順序性が必要なデプロイだけは WAIT_FOR_NAMESPACE_QUEUE を使う、という使い分けが安全です。

Vercel Build Compute料金を試算するテンプレート

ここが一番意思決定で重要なところです。2026年2月26日時点の公式単価で見ると、Standardは$0.014/分（On-Demand時のみ）、Enhancedは$0.030/分、Turboは$0.126/分です。旧資料だとTurboが$0.113/分の記載も残っているので、参照日を固定して社内共有するのが安全です。

monthly_cost = 1回あたりBuild Minutes × 月間ビルド回数 × 単価

• 例A — 同月400 build-minなら上の表の通りです。
• 例B — 100ビルド/月で、1回10分がTurboで40%短縮して6分になると、600分×$0.126=$75.60です。
• 損益分岐 — 同一ジョブ前提なら、TurboがEnhanced比で4.2倍速、Standard比で9倍速になって初めてコスト同額です。

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

他施策と組み合わせるときの優先順位（キャッシュ・Docker・リージョン）

Vercel設定だけでも改善はできますが、競合記事で出ている施策と組み合わせるとさらに安定します。僕のおすすめ順は「1. キュー最適化」「2. CIキャッシュ設計」「3. Dockerキャッシュ持ち運び」「4. リージョン見直し」です。

特にGitHub Actionsを使っているなら、.next/cache のキー設計を先に整えると、無駄なキャッシュ破棄を減らせます。次のように hashFiles の対象から node_modules を外しておくと、ヒット率が安定しやすいです。

- uses: actions/cache@v4
  with:
    path: .next/cache
    key: ${{ runner.os }}-next-${{ hashFiles('**/package-lock.json', '**/*.ts', '!**/node_modules/**/*') }}
    restore-keys: |
      ${{ runner.os }}-next-

Docker運用のチームなら、.next/cache を明示的に持ち運ぶだけで、25分から13分へ短縮した事例（約48%削減）もあります。つまり「マシン課金を上げる前に、再利用できる成果物を増やす」発想がかなり有効です。

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

この設定を後回しにすると、半年で失う時間

Vercelの設定は「今は動いているから後で」で先送りしやすいですが、放置すると小さな待ち時間が積み上がります。この情報を知らないままだと、レビュー待ちと再実行待ちで開発リズムが崩れる可能性があります。

• 判断遅延 — PRマージの意思決定が毎回遅れます。
• コスト錯覚 — 単価だけ見て、時間価値の損失を見落とします。
• 運用属人化 — Dashboardの手作業が増え、担当者依存になります。

怖がる必要はないですが、設定を1回言語化して共有するだけで避けられる損失が多いです。今日のうちに1つだけでも計測項目を追加してみてください。

この記事を書いている理由

僕自身、2026年3月28日にMac miniでGitHub Actionsセルフホストランナーを組み、deployment:false で誤デプロイを防ぎながら、Next.js 16.2 / TypeScript 6対応のCIコストを見直しました。その時に強く感じたのが、速度とコストは片方だけ最適化しても続かないということです。

ITの力を非ITに持ち込む「異世界転生」の実践として、橋渡し情報を増やしていきたいんです。

次のアクション

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。