AIエージェントに指示するだけで、アプリが一晩で動くようになりました。でも、その「動いたコード」をそのまま公開するのは危険です。CI/CDを組めば、その不安を自動テストと自動デプロイで解消できます。本記事では、Vercelを例に設定手順とベストプラクティスを解説します。
この記事の対象読者：Claude CodeやCursorでアプリを作っている個人開発者・少人数チームの方です。まだ自動テスト・自動デプロイの仕組みを持っていない方を想定しています。
CI/CDの正体と役割分担
CI/CDとは、コードの変更を自動でテストし、問題がなければ自動で公開まで進める開発の仕組みです。GitHub Actionsの公式ドキュメントは、CI/CDを「ビルド・テスト・デプロイのパイプラインを自動化するプラットフォーム」と説明しています。私の理解では、この中でCIに当たるのが「コードのビルドとテスト」です。CDに当たるのが「マージされたプル要求を運用環境にデプロイすること」です。
vibe coding（AIエージェントに自然文で指示してコードを生成させる開発スタイル）では、この2つの工程が抜け落ちやすくなります。私の見立てでは、そのまま「動いたから公開する」に飛びやすい傾向があります。自分の手元で1回動いたことと、想定外の入力や決済失敗時にも正しく動くことは別の話です。CI/CDを組むと、コードをpushするたびにこの確認が自動で走るようになります。
| 項目 | 手動デプロイ | CI/CD |
|---|---|---|
| 動作確認 | 公開のたびに手作業で確認 | pushのたびに自動テストが実行 |
| 公開作業 | ファイルを都度アップロード | 本番ブランチへのマージで自動反映 |
| 問題発覚のタイミング | 公開後、ユーザーの報告で気づく | テスト失敗の時点でデプロイが止まる |
Vercelが自動化する範囲
VercelはGitリポジトリと連携するだけで、CI/CDの土台を標準搭載しています。本番ブランチ以外へのpushは、自動的にPreview（プレビュー）デプロイになります。GitHub・GitLab・BitbucketでのPR（プルリクエスト）作成も同様です。本番ブランチへのpushやマージは、自動的にProduction（本番）デプロイになります。
本番ブランチは、①mainブランチ②masterブランチ③Bitbucketの設定④Gitリポジトリのデフォルトブランチ、の優先順で自動判定されます。この順序はVercel公式ドキュメントに基づいています。新規プロジェクトの最初のデプロイは、使ったブランチに関係なく常にProductionデプロイになるという仕様も明記されています。
PreviewデプロイのURLには2種類あります。「ブランチ固有URL」はブランチの最新変更に常に対応し、「コミット固有URL」はそのコミット時点に固定されます。PRごとに専用URLが発行されるため、レビュー担当者はコードだけでなく実際の画面でも動作を確認できます。
事前に準備するもの
Vercel単体でCI/CDを組むだけなら、特別なツールはほとんど要りません。
| 必要なもの | 費用 | 備考 |
|---|---|---|
| GitHubリポジトリ | 無料 | AIエージェントが生成したコードをpush済みであること |
| Vercelアカウント | Hobbyは無料 | 個人開発ならHobbyプランで一通り試せます |
| Vercel CLI（任意） | 無料 | pnpm i -g vercel でインストールします |
| Vercelアクセストークン | 無料 | GitHub Actionsを併用する場合のみ必要です |
Vercel単体でCI/CDを組む手順
Vercel単体であれば、3ステップで自動デプロイが動き始めます。
STEP1: リポジトリをインポートする
Vercelダッシュボードの「New Project」からGitHubリポジトリを選び「Import」します。フレームワークは自動検出されるため、多くの場合は設定を変えずに「Deploy」を押すだけで済みます。
STEP2: Previewデプロイの挙動を確認する
本番ブランチ以外にpushするか、PRを作成すると、そのブランチ専用のPreview URLが自動で発行されます。AIエージェントに機能追加を指示したら、mainにマージする前にこのPreview URLで挙動を確認するのが基本の流れになります。
STEP3: 本番ブランチへの反映を確認する
本番ブランチへマージすると、成功したデプロイに本番ドメインが即座に切り替わります。Project SettingsのEnvironments内には、Branch Trackingという設定項目があります。ここで、どのブランチを本番ブランチとして扱うかを明示的に指定できます。
Vercel CLIから手を動かしたい場合は、コマンドの使い分けで挙動が変わります。vercelだけで実行するとPreviewデプロイになります。vercel --prodを付けると本番デプロイになります。ローカルでダッシュボードの挙動をそのまま再現したいときはvercel devが使えます。
GitHub Actionsを足して安全性を上げる構成
「テストが通った場合だけデプロイする」設計にしたい場合は、GitHub Actionsを組み合わせます。Vercel単体の自動デプロイは速いですが、テストやLint（コードの記述ミスや品質上の問題を自動検出するチェック）を挟まずにそのままビルドへ進むためです。
Vercel CLIの公式ドキュメントは、CI/CD環境向けの認証方法を明記しています。ローカルの対話式vercel loginとは異なります。CI環境では、Vercelのトークンページで発行したアクセストークンをVERCEL_TOKENという環境変数として渡します。--tokenという引数ではなく環境変数が推奨されるのは、引数だとログやプロセス一覧に露出しうるためです。
手順は次の4つです。
- Vercelダッシュボードでアクセストークンを発行します
- GitHubリポジトリのSettings > Secrets and variables > Actionsを開きます。そのトークンを
VERCEL_TOKENという名前のSecretとして登録します - ワークフローYAMLで、テストジョブに成功した場合だけデプロイジョブが実行されるよう依存関係を設定します
- デプロイジョブの中で、Secretsから読み込んだトークンを使ってVercelへデプロイします
name: deploy
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm i -g vercel
- run: vercel --prod
env:
VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
このワークフローでは、テストが失敗した時点でデプロイジョブが実行されません。テストで検知できる不具合であれば、動作確認前のコードが本番に反映されるのを防げます。
「決まった条件で自動的に処理が走る」という設計思想は、他の記事とも根っこが同じです。外出先でもClaude Codeを動かす方法を徹底比較で扱ったスケジュール実行・トリガー実行も、この考え方に基づいています。
最低限おさえるべきベストプラクティス
設定項目が多く見えても、最初に押さえるべきはこの4点に絞られます。
| 項目 | やること | 理由 |
|---|---|---|
| 環境変数を環境ごとに分ける | Production／Preview／Developmentで別の値を設定します | 本番用のAPIキーが誰でも開けるPreview環境に漏れるのを防ぎます |
| Deployment Protectionを設定する | Vercel Authentication（Preview URLへのアクセス時にログインを要求する認証機能）で保護範囲を確認します | Hobbyプランの既定はPreview URLのみ保護です。本番ドメインまで保護したい場合はPro以上のプランが必要になります（料金・プラン内容は変更される可能性があるため、契約前に公式サイトで確認してください） |
| 切り戻し手段を確認しておく | vercel rollbackや、過去デプロイのpromote（特定の過去デプロイを本番に昇格させる操作）を試しておきます |
本番反映後に不具合が見つかっても即座に戻せます |
| トークンはSecretsで管理する | コードに直書きせず、GitHub Secretsや環境変数として渡します | リポジトリへのアクセス権を持つ全員にトークンが見える状態を避けます |
【要注意】つまずきやすいポイントと対処
設定自体は難しくありませんが、次の3つは実際に見落としがちです。
| 症状 | 原因 | 対処 |
|---|---|---|
| プレビューURLを外部の人にも見られてしまう | Deployment Protectionが未設定、または保護範囲が本番ドメイン以外に限定されています | Vercel Authentication（Preview URLへのアクセス時にログインを要求する認証機能）を有効化します。本番ドメインまで保護したい場合はPro以上のプランを検討します |
| 環境変数を追加したのに反映されない | 環境変数は新規デプロイにしか適用されない仕様になっています | 変数を追加・変更したあとに再デプロイします |
| mainにpushしたのにPreviewとして扱われる | 本番ブランチの自動判定と、プロジェクト側のBranch Tracking設定が食い違っています | Project Settings > Environments > ProductionでBranch Trackingの設定を確認します |
CI/CDを組んだ後に、次にやるべきこと
私が生成AI組み込みアプリの開発支援をする中でも、最初のリリースをAIエージェントに任せる案件が増えています。CI/CDを整えてから公開する案件は、公開後の手直しが少ない、というのが私の実感です。自動テストと自動デプロイがあれば、機能追加のたびにPreview URLでその場で挙動を確認でき、問題があればすぐにコードを書き直させられます。
私の判断軸では、個人開発の規模ならVercel単体のCI/CDで十分です。決済処理や会員情報など、失敗の影響が大きい機能を扱うようになったら、GitHub Actionsでテストを自動化する段階に進むべきだと考えています。AIコーディングツール徹底比較で紹介したような、複数のAIエージェントを併用する開発体制もあります。そこでも、公開前にテストが自動で走る仕組みさえあれば、書き手がどのツールでもチェックの質を落とさずに保ちやすくなります。
自社だけでCI/CDの設計まで手が回らない場合は、外部の伴走支援も選択肢になります。
まとめ
CI/CDは、AIエージェントが書いたコードを「動いた」から「公開して問題ない」状態に引き上げる自動化の仕組みです。Vercelを使えば、Gitと連携するだけでPreviewデプロイとProductionデプロイの土台が手に入ります。GitHub Actionsを足せば、テストが通った場合だけデプロイする構成にできます。まずは環境変数の分離とDeployment Protectionの2点だけでも設定し、公開前に一呼吸置ける仕組みを作ってください。
参考リンク
- Vercel 公式ドキュメント「Git連携によるデプロイ」
- Vercel 公式ドキュメント「Environments（Preview環境）」
- Vercel 公式ドキュメント「Environment Variables」
- Vercel 公式ドキュメント「Vercel CLI」
- Vercel 公式ドキュメント「Deployment Protection」
- GitHub 公式ドキュメント「GitHub Actionsを理解する」
監修者
池田 智彦 ｜ 株式会社Spovisor 代表取締役
NTTドコモ・KDDIで通信業界に21年従事し、グローバル／国内市場で10以上の新規事業の立ち上げと、1,000万ユーザー規模サービスの開発・運用を主導。事業戦略から海外展開、エンジニアリングまで横断する経験を活かし、2023年6月に株式会社Spovisorを設立。現在はAI・アプリ開発、生成AIコンサル、AI駆動開発支援、AI顧問など、企業のDXを実装まで伴走する支援に取り組む。
生成AI／AIエージェントを「成果」に変える、Spovisorの伴走支援
株式会社Spovisorは、生成AI・AIエージェントを「使ってみた」で終わらせず、業務やプロダクトに組み込んで成果を出すところまで伴走する実装パートナーです。
| 支援領域 | 内容 |
|---|---|
| 生成AI組み込みアプリ開発 | Claude／ChatGPT／AIエージェントを組み込んだ業務アプリや自社プロダクトの設計から実装まで支援 |
| 生成AI導入コンサル／AI顧問 | 経営課題や業務プロセスから導入ポイントを設計し、本番運用まで伴走 |
| AI駆動開発支援 | Claude Code／Codexを使った開発生産性向上を現場へ定着 |