きっかけ: 案件で Vercel にデプロイすることになった
対応した案件で、Next.js のサイトを Vercel にデプロイする構成を組みました。
そもそも CI/CD とは
- CI = Continuous Integration（継続的インテグレーション）: コードを push したら、ビルドやテストが自動で走る仕組み
- CD = Continuous Delivery / Deployment（継続的デリバリー / デプロイ）: それが通ったら、そのまま自動でデプロイされる仕組み
要するに「人が手でビルドしてサーバーにアップロードする」をやめて、git への push を起点に自動で流れるようにするという話です。従来は GitHub Actions などでこの流れを自前で組むことが多かったのですが、Vercel はこれを設定なしで持っています。
なお CD には2つの意味があり、区別されることがあります。
| 意味 | 本番反映 | |
|---|---|---|
| Continuous Delivery | いつでも本番に出せる状態まで自動化する | 最後のリリースは人が承認・実行 |
| Continuous Deployment | 承認を挟まず本番まで自動で出す | 完全自動 |
Vercel の場合、Production Branch にマージすればそのまま本番に出るので、後者の Continuous Deployment に当たります。マージというアクションが実質的な承認ゲートになっている形です。
GitHub リポジトリのインポート手順
セットアップでやることは、ほとんどありません。
Vercel で Add New → Project → GitHub のリポジトリを選んで Import。これだけです。Next.js であればフレームワークもビルドコマンドもパッケージマネージャも自動で検出されるので、基本は何も触らずにデプロイまで通ります。設定ファイルを書く必要もありません。
一度繋いでしまえば、あとは push するたびに自動でビルド・デプロイが走ります。CI/CD のためにワークフローを書く、という工程がまるごと無くなります。
Vercel のブランチ運用と環境構築
Vercel のデプロイは2種類あります。
- Production Deployment: Production Branch に指定した1本だけ。独自ドメインに出る
- Preview Deployment: それ以外の全ブランチ。ブランチごとに URL が自動生成される
ポイントは、Preview URL は PR を作らなくてもブランチに push した時点で生成されることです。「PR のプレビュー機能」というより、ブランチを切った数だけ環境が増えると捉えたほうが実態に近いです。
なので、環境設計＝ブランチ運用の設計になります。今回はこう切りました。
| GitHub ブランチ | 用途 | アクセス先 |
|---|---|---|
prd |
本番・一般公開 | 独自ドメイン |
stg |
QA・受け入れ確認 | 自動生成されたブランチ URL |
dev |
開発・動作確認 | 自動生成されたブランチ URL |
feature/* |
PR レビュー | 自動生成されたブランチ URL |
feature/* → dev → stg → prd と上げていき、prd にマージされたものだけが本番に出ます。
従来だと「ステージング環境をどう用意するか」「そのためのサーバーをどう調達するか」から考える必要がありましたが、ブランチを作るだけで環境が増えるので、この部分の悩みがなくなります。
PR 作成時のプレビュー URL 機能
実際に使ってみて一番便利だったのがここです。
PR を作成すると、Vercel が PR にコメントを付けてくれて、そこにプレビュー URL が載ります。デプロイのステータス（ビルド中 / 成功 / 失敗）も一緒に表示され、その PR に push するたびに最新のデプロイに更新されます。
レビューする側は、PR 画面のリンクをクリックするだけで実際に動いている画面を確認できます。
- ローカルにブランチを checkout して
npm run devする必要がない - 「どの URL で確認すればいいですか」と聞かなくていい
- コードの diff と動作確認が、同じ PR 画面から辿れる
デザイナーやディレクターなど、ローカル環境を持っていない人にも「この PR のリンクを見てください」で確認を依頼できるのが特に助かりました。
また、ビルドが失敗した場合も PR 上でステータスが赤くなるので、マージ前に気づけます。ここが CI として効いている部分です。
プレビュー URL のアクセス制限方法
便利な反面、注意が要るのはここです。デプロイすると発行される URL は、デフォルトでは誰でもアクセスできます。stg や dev の URL も、そのままだと外から見られる状態になります。
今回は Preview と本番で別々の手段を取りました。
Preview URL（stg / dev / feature/*） は Settings → Deployment Protection を有効化。これで Vercel にログインしたチームメンバーだけが見られる状態になります。設定はトグルひとつです。
ただし、Deployment Protection が無料で守ってくれるのは Preview までで、本番ドメインは対象外です。ここは別で塞ぐ必要がありました。
本番 は Firewall → Rules で IP 制限をかけました。許可する IP を段階的に足していく形で運用しています。
- 公開前: 社内 VPN の固定 IP だけを許可。社内からしか見られないので、そのまま公開前の保護になる
- 公開後: 今回のサイトは既存サーバーからのリバースプロキシ経由で公開する構成なので、リバースプロキシ元のサーバー IP を追加。一般ユーザーはそのサーバー経由でアクセスすることになる
公開後も社内 VPN の IP はそのまま残しています。こうしておくと、一般公開はリバースプロキシ経由の1本に絞りつつ、社内からは Vercel のドメインに直接アクセスして確認できるという状態になります。Vercel 側の URL を外部から直接叩かれることもありません。
なおこのあたりはプランと自分のロールによって使える手段が変わります。IP 制限の方法もいくつかあり、選べるものが変わってくるので、構成を決める前に公式ドキュメント等を確認しておくのがおすすめです。
まとめ
GitHub リポジトリをインポートするだけで CI/CD が組み上がり、ブランチを切れば環境が増え、PR を作ればレビュー用の URL が自動で出てくる。この一連の流れが設定なしで簡単にできるのが、GitHub → Vercel 構成の一番の強みだと感じました。
一方で、自分で決める必要があるのは次の2つでした。
- ブランチ運用 — ブランチがそのまま環境になるので、ブランチ設計＝環境設計になる
- 公開範囲 — デフォルトは全公開。どの URL を誰に見せるかは自分で塞ぐ必要がある
簡単30秒