デプロイは「git push したら本番に出た」で終わらせると、いつか必ず事故ります。Vercel の真価は、本番事故を「出す前」と「出した後」の両面で抑え込む安全弁を最初から備えている点にあります。この記事は、Rolling Releases や Instant Rollback などの公式仕様に忠実に、安全に出す・即座に戻すデプロイ運用を実コマンドでまとめます。
全体像は Vercel 本番運用ガイド を参照してください。本稿は「どう出して、どう戻すか」に集中します。
4つの安全弁
| 安全弁 | タイミング | 役割 |
|---|---|---|
| プレビューURL | 出す前 | ブランチ/PR ごとに本番同等の独立URL。レビュー・QA・ステークホルダー確認 |
| Production Promote | 出す瞬間 | 検証済みデプロイを本番へ昇格。再ビルドせず成果物をそのまま |
| Instant Rollback | 出した後（問題時） | 不変な過去デプロイへ即時復帰 |
| Rolling Releases | 出す過程 | 新デプロイを段階配信（カナリア）し、メトリクスで判断 |
これらが効くのは、Vercel のデプロイが不変（イミュータブル）なスナップショットだからです。各デプロイは固有URLを持ち、過去のものも生き続けます。だから「戻す」は再デプロイではなくルーティングの切り替えで、一瞬で済みます。
プレビューデプロイ：レビューを本番品質の環境で
Git 連携すると、プッシュのたびにプレビューデプロイが作られ、独立URLが発行されます。本番と同じビルド・同じ関数・同じエッジで動くので、「ローカルでは動いた」を潰せます。
# 手動でプレビューを作る（CLI）
vercel deploy
# → https://your-app-git-feature-xyz.vercel.app のような固有URL
プレビューは PR にコメントされ、レビュアーは実物を触って確認できます。E2E（Playwright 等）をプレビューURLに対して回すと、マージ前に回帰を捕まえられます（Playwright E2E 設計）。
プレビューも守る：プレビューURLは公開です。ステージング相当の機密がある場合は、Vercel の**デプロイ保護（パスワード/SSO）**や Firewall でアクセス制御します。
本番へ：Promote と Instant Rollback
Production Promote
検証済みのプレビューデプロイを、再ビルドせずに本番へ昇格します。「ビルドした成果物 ＝ 本番に出る成果物」が保証され、ビルド差異による事故が消えます。
vercel promote <deployment-url-or-id> # 本番へ昇格
Instant Rollback
本番で問題が出たら、過去の本番デプロイへ即時戻します。不変デプロイなので、ビルドも待ちません。
vercel rollback <deployment-url-or-id> # 指定デプロイへ即時復帰
# 引数なしなら直前の本番へ
ISR キャッシュも戻る：ロールバックしても、過去デプロイの ISR キャッシュは purge されていないので、生成済みコンテンツを失わずに戻れます（キャッシュ戦略）。
Rolling Releases：いきなり100%に出さない
「新デプロイを全ユーザーに一斉公開」は最もリスクが高い行為です。Rolling Releases は、まず一部（例：5%）にだけ新デプロイを流し、メトリクスを見ながら段階的に100%へ広げます（Pro は1プロジェクト、Enterprise はカスタム）。
ステージ設計
有効化したら、2つ以上のステージを設定します。各ステージはカナリアへ流す比率で、後のステージほど大きく、最終ステージは必ず100%。多くのプロジェクトは「1つの少数ステージ＋100%」の2段で足ります。
例）2段： 5% → 100%
例）3段： 5% → 25% → 100%
各 promote 操作（git push の自動昇格・ダッシュボードの Promote・vercel promote）が新しい Rolling Release を開始します。進行中の Rolling Release があるときは、解決（完了 or 中断）するまで次は始まりません。
カナリアを判断する
進行中は、デプロイ一覧でリリース候補が "Canary" バッジと流入比率で示され、Observability タブの Rolling Releases セクションで Vercel 計測のメトリクス（Speed Insights 等）をカナリア vs 現行で比較できます。良ければ次ステージへ「Advance」、最終ステージなら100%昇格して通常状態へ。ダメなら——
Abort（中断）/ Instant Rollback でベースデプロイへ戻す
必須：Skew Protection
Rolling Releases では、あるユーザーが新旧どちらのページを受け取るか分かれます。このとき、ページから出るバックエンドAPI呼び出しのバージョンがページとズレると壊れます。Skew Protection は「どのデプロイに当たったユーザーも、そのページと同じバージョンのバックエンドと通信する」ことを保証します。
公式も「Rolling Releases には Skew Protection を強く推奨」と明記しています。セットで有効化してください。これを忘れると、配信中だけ再現する厄介なバグ（古いクライアントが新APIを叩く等）に悩まされます。
本番トラフィックなしで検証する
Rolling Release 中、URLに特殊なクエリを付けると、自分のセッションだけ強制的にカナリア／現行へ振れます。
?vcrrForceCanary=true… 常にカナリア（0%設定のステージでもアクセス可）?vcrrForceStable=true… 常にベース（現行）
# カナリアだけを自分で確認（一般ユーザーには5%しか出していない状態で）
open "https://your-app.vercel.app/checkout?vcrrForceCanary=true"
注意：
vcrrForceCanary=trueは誰でも付けられます。0% カナリアは既定で配信されませんが、秘匿はされていません。本当に隠したい機能は Rolling Releases ではなく機能フラグ（Edge Config）や認可で守ります。
REST API / CLI で自動化
Rolling Releases は API で制御でき、CI/CD に組み込めます。
| 操作 | エンドポイント |
|---|---|
| 設定取得/更新 | GET/PATCH /v1/projects/{id}/rolling-release/config |
| 次ステージへ | POST /v1/projects/{id}/rolling-release/approve-stage |
| 100%完了 | POST /v1/projects/{id}/rolling-release/complete |
| ロールバック | POST /v1/projects/{id}/rollback/{deploymentId} |
API での中断の注意：進行中に config を無効化（PATCH/DELETE）しても、それだけでは現在の Rolling Release は止まりません（未来のリリースにのみ影響）。**
complete（カナリアを100%）かrollback（ベースへ）**を別途呼ぶ必要があります。
CI/CD：GitHub Actions で再ビルドなし昇格
Vercel の Git 連携だけでも CI/CD は回りますが、独自のテスト/ゲートを挟みたいときは GitHub Actions から --prebuilt で出すのが定石です。「一度ビルドした成果物をそのまま本番へ」昇格でき、ビルド差異とビルド時間を消せます。
# .github/workflows/deploy-production.yml
name: Deploy Production
on:
push:
branches: [main]
permissions:
contents: read
id-token: write # OIDC（鍵レス）に必要
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 24 }
- run: npm ci
# 品質ゲート（型・lint・テスト）— 通らなければ出さない
- run: npm run lint && npm run test && npx tsc --noEmit
- run: npm i -g vercel@latest
# ① 環境情報を取得 → ② ビルド → ③ 成果物をそのままデプロイ
- run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
- run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
- run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
鍵レス（OIDC）が2026年の標準：外部クラウド（AWS 等）の認証情報を CI に置かず、GitHub の OIDC トークンで一時クレデンシャルを得ます。Vercel の OIDC 連携を使うと、長命のアクセスキーをシークレットに保管せずに済みます（OIDC 鍵レス CI/CD の考え方）。
VERCEL_TOKEN自体もスコープを絞り、ローテーションします。
設定は vercel.ts（型安全・動的）
ビルド・ルーティング・ヘッダ・Cron・関数設定は vercel.ts で型安全に宣言できます。vercel.json と違いビルド時に実行されるので、環境変数で条件分岐したり API から設定を取得したりできます（どちらか一方のみ）。
// vercel.ts
import { routes, deploymentEnv, type VercelConfig } from "@vercel/config/v1";
const isProd = deploymentEnv.VERCEL_ENV === "production";
export const config: VercelConfig = {
framework: "nextjs",
buildCommand: "npm run build",
// 本番だけ別バックエンドへ rewrite するような動的設定が書ける
rewrites: [
routes.rewrite("/api/(.*)", isProd
? "https://api.example.com/$1"
: "https://staging-api.example.com/$1"),
],
headers: [
routes.cacheControl("/assets/(.*)", { public: true, maxAge: "1 year", immutable: true }),
],
crons: [{ path: "/api/cron/cleanup", schedule: "0 0 * * *" }],
};
@vercel/config を入れ、config を export するだけです。vercel.json から移行するなら、内容を config にコピーしてから動的化していきます。
本番チェックリスト（デプロイ）
- プレビューURLでレビュー・E2Eを回してからマージ
- CI に型・lint・テストの品質ゲートを置き、通らなければ出さない
-
--prebuiltで再ビルドなし昇格、ビルド差異を排除 - CI 認証は OIDC 鍵レス、
VERCEL_TOKENはスコープ最小＋ローテーション - 重要リリースは Rolling Releases で段階配信
- Rolling Releases には Skew Protection を必ず併用
- Instant Rollback の手順をチームで共有（誰でも即戻せる）
- 設定は
vercel.ts/vercel.jsonのどちらか一方に統一
まとめ
Vercel のデプロイ運用は、不変デプロイという土台の上に4つの安全弁を重ねる設計です。
- プレビューで出す前に捕まえる
- Promoteで成果物をそのまま昇格
- Instant Rollbackで出した後も一瞬で戻せる
- Rolling Releases ＋ Skew Protectionで段階的に・整合して広げる
- CI/CD は
--prebuilt＋ OIDC 鍵レスで安全・高速に
次は、出した本番の入口を守る Firewall・WAF・BotID ガイド へ。
本記事は Rolling Releases / Instant Rollback / Vercel CLI 公式ドキュメント（2026年6月時点）に基づきます。仕様は更新されるため、本番採用時は公式で最新値を確認してください。