Vercel CI が Vercel プロジェクトの連携不要に — 何が変わり、どう試すか
2026年11月3日、Vercel は Vercel CI を Vercel プロジェクトなしで使えるようにしたと発表しました。これまでは CI を動かすためだけに空の Vercel プロジェクトを作り、GitHub リポジトリを接続する必要がありました。今後はリポジトリのクローンで vercel ci enable を実行するだけで有効になります。つまり Vercel にデプロイしていないリポジトリでも、Vercel CI を単体の CI サービスとして使えるようになりました。ただし対象はプライベートな GitHub リポジトリのみで、Vercel CI 自体がまだ Beta です。
何が変わったのか
変更点は「前提条件の削除」です。Vercel CI は 2026年10月28日に Beta 公開されましたが、その時点の要件には「リポジトリが最低1つの Vercel プロジェクトに接続されていること」が含まれていました。そのため、デプロイ先が AWS や Cloudflare、オンプレミスであっても、CI を使うだけのダミープロジェクトを用意する運用が必要でした。
今回の変更で必要なものは3つだけです。リポジトリにアクセスできる Vercel GitHub App がインストールされていること、GitHub アカウントが Vercel アカウントと接続されていること、そのリポジトリに write または admin 権限があることです。この状態でクローンしたディレクトリから vercel ci enable を実行すると、CLI が向いているチームに対して CI が有効になります。別のチームで有効にしたい場合は --scope <team> を渡します。以降は push のたびに、リポジトリ内の設定どおりにタスクが実行されます。
どういうチームに効くのか
恩恵が大きいのは、Turborepo を使っていて、かつデプロイ先が Vercel ではないチームです。これまでは「CI だけ Vercel を使う」構成に、実体のないプロジェクトという説明しづらい要素が混ざっていました。その整理が不要になります。
もう一つは、1つのリポジトリから複数チームにプロジェクトを接続しているケースです。Vercel CI には「リポジトリが複数の Vercel チームのプロジェクトに接続されていてはいけない」という制約があります。プロジェクト連携そのものを前提にしない経路ができたことで、この制約に引っかかる構成でも検討の余地が生まれます。ただし制約自体が消えたとは公表されていないため、既存の接続がある場合は実際に有効化して確認するのが確実です。
逆に、すでに Vercel にデプロイしていて普通にプロジェクトが存在するチームにとって、今回の変更による実務上の差はほとんどありません。導入判断を左右するのは引き続き、後述の制約とコストです。
現時点の制約
今回の緩和は無条件ではありません。changelog に明記されているのは、プライベートな GitHub リポジトリのみという点です。パブリックリポジトリと GitHub 以外の Git ホスティングはまだ対象外です。GitLab や Bitbucket を使っているなら、この変更は関係ありません。
Vercel CI 本体の制約も残ります。ベースイメージは Linux のみ、トリガーは GitHub への git push のみ、そして Turborepo 2.11.7 以降と Vercel CLI 64.3.1 以降が必要です。タスクの指定は turbo.json に "tags": ["ci"] を付ける方式で、ワークフローの YAML は書きません。Turborepo を導入していないリポジトリは、まず turbo パッケージと turbo.json の追加から始めることになります。単一パッケージのリポジトリでも動作します。
なお、公式ドキュメントの Vercel CI ページは 2026年10月28日更新時点で「リポジトリは最低1つの Vercel プロジェクトに接続されている必要がある」と記載したままです。changelog のほうが新しい情報です。検証時にドキュメントと挙動が食い違う場合は、Beta 中の更新ラグを疑ってください。
コストの見積もり方
Vercel CI は CPU 分で課金されます。Pro は 1 CPU 分あたり $0.0035、Enterprise はカスタムです。Vercel の料金ページでは Beta 中、月200 CPU 分が含まれると案内されています。
見積もりで見落としやすいのが、タスク実行前の bootstrapping です。リポジトリのクローンと依存関係インストールを行うこの工程はデフォルト4 CPU を使い、実行ごとに必ず発生します。各タスクはデフォルト2 CPU で、ci:cpus:<count> タグで最大32 CPU まで引き上げられます。計算は「CPU 数 × 実行時間」で、秒単位に切り上げられます。
したがって、小さなタスクを大量に並べるほど bootstrapping 以外の固定費は増えにくい一方、CPU 数を安易に上げると線形に効いてきます。最初は型チェックとテストなど効果の見えやすいタスクだけにタグを付け、実測してから CPU 数を調整するのが無駄がありません。
試すときの進め方
評価するなら、既存 CI を止めずに並走させるのが安全です。手順はおおむね次のとおりです。
- Turborepo と Vercel CLI を必要バージョンまで上げる
- リポジトリのクローンで
vercel ci enableを実行する turbo.jsonで lint やテストなど一部のタスクにだけciタグを付ける- GitHub Actions 側はそのまま残し、同じ push に対する所要時間と結果を比較する
- 結果が安定したら、GitHub の branch protection の必須チェックを Vercel CI 側に切り替える
Vercel は自社リポジトリで push から CI 完了までが2〜6倍短縮したとしていますが、これはベンダー自身の数値です。キャッシュのヒット率やタスクの粒度で結果は変わるため、自分たちのリポジトリでの実測を判断材料にしてください。実行結果はダッシュボードの CI タブのほか、Vercel CLI、Vercel MCP、REST API から確認できます。GitHub Actions からの移行については、公式のナレッジベースに秘密情報や環境変数の移し方を含む対応表があります。
まとめると、今回の変更で「Vercel にデプロイしていないチームが Vercel CI を試す」ハードルが下がりました。該当するのは Turborepo を使うプライベート GitHub リポジトリです。まずは1リポジトリで既存 CI と並走させ、CPU 分の実績値を取ってから判断するのが現実的です。モノレポの CI 設計やビルド時間の改善、フロントエンド開発の体制づくりで相談先をお探しでしたら、お問い合わせからお気軽にご連絡ください。
