AIを使った開発手法 Vol.5：プレビュー環境で確認後、開発環境へデプロイ

はじめに

Vol.1〜4では、チケット作成からコード生成、AIレビューまでの自動化を解説してきました。

Vol.5では、プレビュー環境から開発環境へのデプロイフローを構築します。AIが生成したコードをまずプレビュー環境で確認し、問題なければ開発環境にデプロイする仕組みです。

4つの環境構成

本シリーズでは、以下の4つの環境を前提としています：

┌─────────────────────────────────────────────────────────────────┐
│                        環境構成                                  │
├─────────────┬─────────────┬─────────────┬─────────────────────────┤
│   開発環境   │  テスト環境  │ステージング │      本番環境          │
│ Development │   Testing   │  Staging   │     Production         │
├─────────────┼─────────────┼─────────────┼─────────────────────────┤
│ 開発者が     │ QAチームが  │ 本番同等    │ エンドユーザーが       │
│ 動作確認     │ テスト実施  │ 環境で最終  │ 利用する環境           │
│             │             │ 確認        │                        │
└─────────────┴─────────────┴─────────────┴─────────────────────────┘

    ↑
┌─────────────┐
│ プレビュー   │  ← PRごとに自動生成される一時的な環境
│  環境       │
└─────────────┘

※ 各環境の詳しい使い方は Vol.6 で解説します。

本記事のスコープ

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  PR作成     │────▶│ プレビュー   │────▶│  開発環境   │
│             │自動 │  環境       │承認後│             │
└─────────────┘     └─────────────┘     └─────────────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ 👤 人間が   │
                    │   確認      │
                    └─────────────┘

本記事では、プレビュー環境での確認から開発環境へのデプロイまでを解説します。

推奨デプロイフロー

┌─────────────┐
│  PR作成     │
│(Claude Code)│
└──────┬──────┘
       │ 自動
       ▼
┌─────────────┐
│ AIレビュー  │
│(CodeRabbit) │
└──────┬──────┘
       │ 自動
       ▼
┌─────────────────────────────────────┐
│     プレビュー環境に自動デプロイ      │
│  https://pr-123.preview.example.com  │
└──────┬──────────────────────────────┘
       │
       ▼
┌─────────────┐
│ 👤 人間が   │  ← ここで確認！
│  動作確認   │
│  ・UI/UX    │
│  ・機能     │
│  ・表示崩れ │
└──────┬──────┘
       │ 承認してマージ
       ▼
┌─────────────┐
│ 開発環境へ  │  ← マージ後に自動デプロイ
│  デプロイ   │
│ dev.example.com │
└─────────────┘

ポイント：人間の確認を挟むことで、AIの生成物を安全に開発環境へ反映できます。

なぜプレビュー環境が重要か

AIコード生成の現実

AIが生成するコードは高品質ですが、以下のような問題が発生することがあります：

これらは実際に動かしてみないとわからないため、プレビュー環境での確認が不可欠です。

プレビュー環境のメリット

• 開発環境を汚さない - 問題のあるコードが開発環境に入らない
• PRごとに独立 - 他の作業に影響しない
• URLを共有 - チームメンバーに確認を依頼できる
• 問題があればマージしない - 安全なゲートキーピング

実装方法

Vercel を使う場合（推奨）

Vercelは設定なしでプレビュー環境が使えます。

1. Vercelとリポジトリを連携

1. Vercel にログイン
2. 「Add New Project」をクリック
3. GitHubリポジトリを選択
4. 環境を設定：
   • Production Branch: main → 開発環境用
   • Preview: PRごとに自動生成

2. 環境変数の設定

# Vercel Dashboard → Settings → Environment Variables

# 開発環境用（Production）
DATABASE_URL=postgres://dev-db.example.com/app
API_URL=https://dev-api.example.com

# プレビュー環境用（Preview）
DATABASE_URL=postgres://preview-db.example.com/app
API_URL=https://preview-api.example.com

3. PRにプレビューURLが自動コメントされる

🔍 Preview deployment ready!

Preview: https://my-app-git-feature-123-team.vercel.app

Built with commit abc1234

4. 確認してマージ → 開発環境にデプロイ

プレビュー環境で動作確認し、問題なければPRをマージ。 マージすると自動で開発環境（mainブランチ）にデプロイされます。

GitHub Actions で構築する場合

プレビュー環境へのデプロイ

# .github/workflows/preview.yml
name: Preview Deploy

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  preview:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'yarn'

      - name: Install & Build
        run: |
          yarn install --frozen-lockfile
          yarn build
        env:
          NEXT_PUBLIC_API_URL: https://preview-api.example.com

      - name: Deploy to Preview
        id: deploy
        run: |
          npm install -g vercel
          url=$(vercel deploy --token=${{ secrets.VERCEL_TOKEN }})
          echo "preview_url=$url" >> $GITHUB_OUTPUT

      - name: Comment Preview URL
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## 🔍 プレビュー環境

**URL:** ${{ steps.deploy.outputs.preview_url }}

### 確認項目
- [ ] 新機能が正しく動作する
- [ ] UIが崩れていない
- [ ] 既存機能に影響がない
- [ ] モバイル表示も確認

✅ 確認完了後、このPRをマージすると**開発環境**にデプロイされます。`
            })

開発環境へのデプロイ（マージ後）

# .github/workflows/deploy-dev.yml
name: Deploy to Development

on:
  push:
    branches: [main]

jobs:
  deploy-dev:
    runs-on: ubuntu-latest
    environment:
      name: development
      url: https://dev.example.com

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'yarn'

      - name: Install & Build
        run: |
          yarn install --frozen-lockfile
          yarn build
        env:
          NEXT_PUBLIC_API_URL: https://dev-api.example.com

      - name: Run Tests
        run: yarn test

      - name: Deploy to Development
        run: |
          vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_DEV_PROJECT_ID }}

      - name: Notify Slack
        uses: slackapi/slack-github-action@v1
        with:
          channel-id: 'dev-deployments'
          slack-message: |
            🚀 開発環境にデプロイしました

            *コミット:* ${{ github.event.head_commit.message }}
            *URL:* https://dev.example.com
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

確認フローの詳細

PRに確認チェックリストを追加

.github/pull_request_template.md:

## 変更内容
<!-- 何を変更したか簡潔に -->

## プレビュー確認
<!-- プレビューURLは自動でコメントされます -->

### 確認チェックリスト
- [ ] 新機能が要件通りに動作する
- [ ] UIデザインが崩れていない
- [ ] レスポンシブ対応（モバイル表示）を確認
- [ ] 既存機能への影響がない
- [ ] エラーが発生しない

### AIレビューの指摘事項
- [ ] CodeRabbitの指摘を確認・対応した

## 備考
<!-- レビュアーへの補足事項があれば -->

---
✅ 確認完了後、マージすると**開発環境**にデプロイされます

Slackでプレビュー通知

// n8n Function ノード
const prData = $input.first().json;

const message = {
  blocks: [
    {
      type: "header",
      text: {
        type: "plain_text",
        text: "👀 プレビュー確認お願いします"
      }
    },
    {
      type: "section",
      text: {
        type: "mrkdwn",
        text: `*PR:* <${prData.pr_url}|#${prData.pr_number} ${prData.title}>`
      }
    },
    {
      type: "section",
      text: {
        type: "mrkdwn",
        text: `*プレビュー:* <${prData.preview_url}|こちらをクリック>`
      }
    },
    {
      type: "context",
      elements: [
        {
          type: "mrkdwn",
          text: "✅ 確認OKならマージ → 開発環境にデプロイされます"
        }
      ]
    },
    {
      type: "actions",
      elements: [
        {
          type: "button",
          text: { type: "plain_text", text: "🔍 プレビューを開く" },
          url: prData.preview_url,
          style: "primary"
        },
        {
          type: "button",
          text: { type: "plain_text", text: "📝 PRを確認" },
          url: prData.pr_url
        }
      ]
    }
  ]
};

return { message };

実際のフロー例

9:00 AM - チケット作成

PM「ログイン画面にパスワードリセット機能を追加したい」 → Jiraでチケット作成

9:05 AM - 自動でコード生成

• n8n → GitHub Issue作成
• Claude Code → コード生成、PR作成

9:10 AM - AIレビュー

• CodeRabbit → 自動レビュー
• 指摘があれば Claude Code が自動修正

9:15 AM - プレビュー環境にデプロイ

• GitHub Actions → プレビュー環境に自動デプロイ
• PRにプレビューURLがコメントされる
• Slackに通知「確認お願いします」

10:00 AM - 人間が確認 👤

開発者がプレビュー環境で確認：

• ✅ パスワードリセット画面が表示される
• ✅ メール送信機能が動作する
• ✅ UIがデザイン通り
• ✅ モバイルでも正常に表示

10:15 AM - 承認してマージ

• 開発者がPRを承認
• 「Merge」ボタンをクリック

10:16 AM - 開発環境にデプロイ

• GitHub Actions → 開発環境に自動デプロイ
• Slackに通知「🚀 開発環境にデプロイしました」
• 開発環境URL: https://dev.example.com

所要時間：約1時間15分（うち人間の作業は確認とマージのみ）

トラブル対応

プレビューで問題が見つかった場合

1. PRにコメントで指摘
2. @claude この部分を修正してください でAIに修正依頼
3. 修正されると自動で新しいプレビューが作成される
4. 再度確認して問題なければマージ

開発環境で問題が発生した場合

# ロールバック用ワークフロー
name: Rollback Development

on:
  workflow_dispatch:

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: development
    steps:
      - name: Rollback
        run: |
          vercel rollback --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_DEV_PROJECT_ID }}

      - name: Notify
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text": "⚠️ 開発環境をロールバックしました"}'

ブランチ保護ルール

mainブランチへの直接プッシュを禁止し、必ずPR経由でマージするようにします：

1. Settings → Branches → Branch protection rules
2. 「main」ブランチを選択
3. 以下を有効化：
   • ✅ Require a pull request before merging
   • ✅ Require approvals (1以上)
   • ✅ Require status checks to pass
   • ✅ Require branches to be up to date

まとめ

本記事では、プレビュー環境から開発環境へのデプロイフローを解説しました。

次回 Vol.6 では、開発・テスト・ステージング・本番の4つの環境の使い方を詳しく解説します。

• 各環境の役割と責任
• 環境間のプロモーション（昇格）フロー
• テスト環境でのQA実施方法
• ステージングでの最終確認
• 本番リリースの承認フロー

この開発自動化パイプラインの導入支援を承っております。お気軽にお問い合わせください。