Vercel CI がベータ公開 — Turborepo の設定1行でCIを動かす仕組みと、導入を判断する基準
Vercel は2026年10月28日、CI 製品「Vercel CI」のベータ提供を開始しました。turbo.json のタスクに "tags": ["ci"] に相当する1行を足すだけで、ビルド以外の lint やテストも Vercel 上で実行できます。ワークフロー YAML は書きません。結論から言うと、すでに Turborepo を使っていて GitHub 上でモノレポを運用しているチームにとっては、検証コストの低い選択肢です。一方でベータ段階の制約が明確にあり、現時点で GitHub Actions を全面的に置き換える判断はまだ早い、というのがこの記事の見立てです。
何ができるようになったのか
Vercel CI は Turborepo のタスクグラフ（タスク同士の依存関係の定義）をそのまま CI の定義として使います。turbo.json 内のタスクに ci タグを付けると、そのタスクが push のたびに実行されます。CI 設定ファイルを別に持たないため、turbo.json と CI 定義がずれる問題が構造的に起きません。
Vercel は自社リポジトリで、git push から「CI passed」までの待ち時間が従来比で2〜6倍短くなったと公表しています。また自社リポジトリとプライベートベータを合わせて約800万タスクを実行済みとしています。同社はこの改善の動機として、コーディングエージェントがプルリクエストを大量に開くようになり、CI の待ち時間がボトルネックになっている点を挙げています。
実行の仕組み
push のたびに、次の順序で処理されます。
- Turborepo が ci タグの付いたタスクを特定する
- Vercel Remote Cache を参照し、キャッシュ済みのタスクを除外する
- 残った未キャッシュのタスクを実行対象にする
- 各タスクを依存順に、それぞれ独立したコンピュートインスタンスで実行する
- 結果を GitHub 側に返し、ひとつでも失敗すれば CI 全体を失敗として扱う
ポイントは「変更の影響を受けたタスクしか動かない」ことと、「タスクごとに必要な分だけのコンピュートを割り当てる」ことの2点です。Remote Cache は設定なしで有効になり、依存関係のインストールは1回の実行につき1度だけ、しかもコード更新をまたいでキャッシュされます。実行基盤には Vercel のビルドインフラである Hive が使われています。
実行状況はダッシュボードの CI タブのほか、Vercel CLI、Vercel MCP、REST API から確認できます。CLI では実行一覧の取得、タスク一覧の確認、ログ取得、失敗タスクの標準エラー出力への絞り込み、過去の実行ログの横断検索ができます。フレーキーなテストを追う作業は、人間よりもエージェントに任せる前提の設計になっています。
導入手順と前提条件
前提は Turborepo 2.11.7 以降と Vercel CLI 64.3.1 以降です。手動セットアップの場合は、GitHub リポジトリをチーム内の Vercel プロジェクトに接続したうえで、ローカルのクローンから vercel ci enable を実行し、対象タスクに ci タグを付けます。Turborepo をまだ使っていない場合は turbo.json と turbo パッケージを追加する必要がありますが、単一パッケージのリポジトリでも動作します。
Vercel はエージェント向けのセットアップ Skill も用意しており、リポジトリを開いたエージェントに所定のプロンプトを渡すと、初期タスクの選定から設定、プルリクエストの作成までを行わせられます。既存の CI を止めずに並走させ、結果を突き合わせてから切り替えるのが現実的な進め方です。Vercel CI は GitHub のチェックとして結果を返すため、既存のブランチ保護ルールでマージをブロックできます。
料金はCPU分単位。GitHub Actions との比較
課金はビルドと同じ CPU 分（1 CPU が1分動いた量）単位で、ドキュメント上は Pro が1 CPU 分あたり 0.0035 ドル、Enterprise はカスタムと記載されています。CPU 数 × 実行時間で計算し、時間は秒単位で切り上げ（最小1秒）です。既定値はブートストラップが4 CPU、各タスクが2 CPU で、いずれも設定で変更できます。
単価だけを見ると、2 CPU のタスクは1分あたり 0.007 ドル相当で、GitHub がドキュメントで公開している Linux 2コアランナーの 0.006 ドル/分（arm64 は 0.005 ドル）よりやや高くなります。ただし比較すべきは単価ではなく総量です。GitHub Actions はジョブ単位で分を切り上げるのに対し、Vercel CI は秒単位で、さらに影響のないタスクとキャッシュ済みタスクは実行自体をスキップします。短いジョブが多い構成や、変更範囲が狭いモノレポほど差が出ます。逆に、毎回ほぼ全タスクが走る小規模な単一パッケージ構成では、スキップが効かないため価格面の優位は薄くなります。
加えて、GitHub Actions には私有リポジトリ向けの無料枠（Free プランで月2,000分など）があり、公開リポジトリとセルフホストランナーは分単位課金の対象外です。小規模リポジトリでは依然として Actions のほうが安く収まる可能性があります。移行の判断材料は、現状の CI で「変更と無関係に毎回走っている分数」がどれだけあるかです。まずそこを計測してください。
ベータ段階の制約
ドキュメントに明記されている制限は次のとおりです。
- ベースイメージは現時点で Linux のみ
- 対応するソースコードホスティングは GitHub のみ
- トリガーは GitHub への git push のみ（スケジュール実行や手動実行は対象外）
- リポジトリは最低1つの Vercel プロジェクトに接続されている必要がある
- 複数の Vercel チームのプロジェクトに接続されたリポジトリは不可
さらに Vercel 自身のリリースフェーズの定義として、ベータ製品は Enterprise プランの SLA の対象外であり、本番環境での全面的な利用は推奨されないとされています。機能と設定も変更される可能性があります。GA に向けては、より詳細なオブザーバビリティ、push 前に分散実行を行う CLI コマンド、より細かいテスト選択の追加が予定されています。
この制約の組み合わせから、現実的な適用範囲は絞られます。macOS や Windows でのビルドが必要なプロジェクト、GitHub 以外を使っているチーム、cron による定期実行や手動ディスパッチに依存しているワークフローは、少なくとも当面は Actions 側を残す必要があります。
どう動くべきか
すでに Vercel と Turborepo を使い、GitHub 上のモノレポで lint とユニットテストの待ち時間が開発の律速になっているなら、その2タスクだけに ci タグを付けて既存 CI と並走させる価値があります。評価軸は「push から成功までの時間」と「スキップされたタスクの割合」の2つで十分です。デプロイをブロックする E2E やリリース用ジョブは、GA と SLA の扱いが固まるまで既存の仕組みに残しておくのが安全です。
