Vercel CIがベータで公開、変更に関わるタスクだけを動かす

変更が1行だけのpushでも、CIはlintからテストまでを全部流し直すしかないのか。Webアプリの公開基盤Vercelは、変更が影響するタスクだけを動かすCIでこれに応えた。2026年10月28日にベータ版を公開した「Vercel CI」である。

どのタスクを動かすかは、Turborepoのturbo.jsonでタスクに「ci」のタグを付けて決める。CI専用のワークフローのファイルは不要。Vercelにアプリを置き、GitHub Actionsでテストを回しているチームにとって、気になるのは両者の分担だろう。

設定はturbo.jsonのタグ1つ

Vercel CIは、Turborepoがもともと持つタスクの依存関係をそのまま使う。Turborepoは、複数のパッケージをまとめたリポジトリ（モノレポ）で、ビルドやテストを依存の順に動かすツールだ。turbo.jsonには、タスクごとに何に依存するかを書いておく。

pushのたびに、変更に関係するタスクだけが動く。入力が変わっていないタスクは、Vercel Remote Cacheに残った結果で済ませる。Remote Cacheは最初から有効だ。残ったタスクはそれぞれ別のマシンで、依存先が終わりしだい動き出す。マシンはVercelの計算基盤「Hive」の上で動き、Vercelは各タスクに「必要な分だけ」の計算資源を割り当てると書いている。

意外なのは、モノレポでなくても使える点だ。turbo.jsonとturboのパッケージを足せば、パッケージが1つだけのリポジトリでも動くと、Vercelは案内している。

始めるにはTurborepo 2.11.7以降とVercel CLI 64.3.1以降が要る。リポジトリをVercelのプロジェクトにつないだうえで、vercel ci enableで有効にする。複数のチームのプロジェクトにつながったリポジトリでは使えない。

Vercelは背景として、コーディングエージェントが開くプルリクエストの増加を挙げる。多くのCIは1行の変更でもワークフロー全体を動かすため、pushが増えるほど待ち時間がかさむという。Vercelによると、自社のリポジトリでpushから「CI passed」までにかかる時間は、以前の半分から6分の1に縮んだ。自社と非公開のベータで動かしたタスクは、すでに800万件近い。

GitHub Actionsとの違いは手順の置き場所

掲載しているGitHub Actionsと並べると、まずCIの手順を書く場所が違う。

比べる点	Vercel CI（ベータ）	GitHub Actions
手順を書く場所	turbo.jsonのタスクに付けるタグ	ワークフローのファイル
動き出すきっかけ	GitHubへのgit pushだけ	GitHubのあらゆるイベント
動くOS	Linux（Amazon Linux 2023かUbuntu 24.04）	Linux、macOS、Windows
実行するマシン	タスクごとに1台。標準は2CPUと4GBのメモリで、最大32CPU	GitHubが用意するランナーか、自社で用意するセルフホストランナー

表を見る限り、GitHub Actionsで回しているCIを今すぐすべて移せるわけではない。macOSやWindowsでのビルドや、push以外のイベントをきっかけにした処理は、GitHub Actionsに残すことになる。

一方で、両者は同じリポジトリで並べて使える。Vercel CIの結果はGitHubのプルリクエストにチェックとして返り、ほかのチェックと同じ欄に並ぶ。ブランチ保護ルールでマージを止める設定も、GitHub Actionsの失敗と同じように効く。

まずはlintや単体テストのように、変更の範囲で結果が決まるタスクから移すと無理がないだろう。

Vercelは、turbo.jsonとCIの設定が食い違う心配がなくなる点も利点に挙げている。Turborepoでタスクの依存関係を整えてあるリポジトリほど、書き足す量は少ないはずだ。

ソースコードをGitLabやBitbucketで管理している会社は、今のところ対象外になる。Vercel CIはGitHubにしか対応しておらず、GitLabとBitbucketはそれぞれ、ソース管理と一体のCI/CDを持っている。4つのサービスの掲載内容は、一つの表に並べたページでも見られる。

課金されるのは動いたタスクだけ

料金体系は、CPUを使った時間に応じた従量課金だ。CPUの数に動いた時間を掛けた「CPU分」で数え、Vercelのビルドと同じ単位を使う。対象になる段階は、リポジトリを取り込んで依存関係を入れる準備と、実際に動いたタスク。キャッシュから戻したタスクや、変更と関係がなく飛ばしたタスクは数えない。

つまり、変更の範囲が狭いpushほど、費用も小さく済む。

ドキュメントの料金表に載っているプランはProとEnterpriseで、Enterpriseは個別に決める。発表は全プランでベータを使えるとしているけれど、無料のHobbyは料金表に載っていない。もっとも、Hobbyは個人の非商用に限ったプランなので、会社で使うならPro以上が前提になる。金額はCIのドキュメントにある。

プレビューへのE2Eテストも任せられる

実務で効きそうな使い方に、プレビューのデプロイを使ったE2Eテストがある。タスクはコミットごとのデプロイが終わるのを待ってから、そこへリクエストを送れる。Deployment Protectionで保護したデプロイにも、Vercel CIがOIDCのトークンを付けてアクセスする。

失敗の調べ方も手軽だ。ダッシュボードのCIのタブかVercel CLIで、落ちたタスクのログにすぐたどり着ける。vercel ci grepを使えば直近の実行のログをまとめて検索でき、同じテストが何度も落ちていないかを追える。

ただ、ベータのため、機能や設定は変わる可能性があるとVercelは断っている。正式版までには、より細かいテストの選び出しや、push前に分散実行するCLIのコマンドを加える予定だ。

1行の変更のたびに全部を流し直す運用は、GitHubで開発し、Vercelにアプリを置くチームにとって、もう前提ではなくなった。

GitHub Actionsと並べて1〜2週間動かせば、自社のリポジトリで待ち時間がどれだけ縮むかが見えてくる。