AIを使った開発手法 Vol.6：開発・テスト・ステージング・本番環境の使い分け

はじめに

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

本記事では、開発・テスト・ステージング・本番の4つの環境の使い分けと、環境間のプロモーション（昇格）フローを詳しく解説します。

4つの環境の全体像

┌─────────────────────────────────────────────────────────────────────────┐
│                         環境構成とフロー                                 │
└─────────────────────────────────────────────────────────────────────────┘

  PRマージ        定期 or 手動      QA承認後        リリース承認後
     │               │               │                │
     ▼               ▼               ▼                ▼
┌─────────┐    ┌─────────┐    ┌─────────────┐    ┌─────────────┐
│  開発   │───▶│ テスト  │───▶│ステージング │───▶│    本番     │
│  Dev    │    │  Test   │    │   Staging   │    │ Production  │
└─────────┘    └─────────┘    └─────────────┘    └─────────────┘
     │               │               │                │
     ▼               ▼               ▼                ▼
  開発者が       QAチームが      関係者全員が      エンドユーザー
  動作確認       テスト実施      最終確認          が利用

各環境の詳細

1. 開発環境（Development）

開発環境の役割

• 統合確認: 複数の機能が正しく連携するか確認
• 開発者テスト: 開発者による動作確認
• デバッグ: 問題発生時の調査
• デモ: 社内向けの簡易デモ

開発環境の特徴

# 開発環境の設定例
environment: development
features:
  - デバッグモード有効
  - 詳細ログ出力
  - テストデータ使用
  - 外部API はモック or サンドボックス
  - メール送信は内部転送

デプロイフロー

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

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: development
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: ./deploy.sh development

---

2. テスト環境（Testing / QA）

テスト環境の役割

• 機能テスト: 要件通りに動作するか検証
• 回帰テスト: 既存機能が壊れていないか確認
• 自動テスト: E2Eテストの実行環境
• バグ報告: 問題を発見して報告

テスト環境の特徴

# テスト環境の設定例
environment: testing
features:
  - 自動テスト実行可能
  - テストデータのリセット機能
  - パフォーマンス計測有効
  - 外部APIはサンドボックス
  - テスト用メールサーバー

デプロイフロー

# .github/workflows/deploy-test.yml
name: Deploy to Testing

on:
  # 毎日午前2時に自動デプロイ
  schedule:
    - cron: '0 17 * * *'  # JST 2:00
  # または手動トリガー
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: testing
    steps:
      - uses: actions/checkout@v4
        with:
          ref: main

      - name: Deploy to Testing
        run: ./deploy.sh testing

      - name: Run E2E Tests
        run: yarn test:e2e

      - name: Notify QA Team
        uses: slackapi/slack-github-action@v1
        with:
          channel-id: 'qa-team'
          slack-message: |
            🧪 テスト環境を更新しました
            URL: https://test.example.com
            テスト開始をお願いします

QAテストの流れ

1. テスト環境にデプロイされる
         │
         ▼
2. Slack通知「テスト環境が更新されました」
         │
         ▼
3. QAチームがテスト実施
   - テストケースの実行
   - 探索的テスト
   - バグの報告（Jira/GitHub Issues）
         │
         ▼
4. バグがあれば修正 → 再度開発環境から
   問題なければ → ステージングへ昇格

---

3. ステージング環境（Staging）

ステージング環境の役割

• 本番同等確認: 本番と同じ構成で動作確認
• パフォーマンステスト: 負荷テスト、速度測定
• 関係者レビュー: PM、デザイナー、ビジネス側の確認
• リリースリハーサル: デプロイ手順の確認

ステージング環境の特徴

# ステージング環境の設定例
environment: staging
features:
  - 本番と同じインフラ構成
  - 本番に近いデータ量
  - 外部APIは本番（またはサンドボックス）
  - パフォーマンス監視有効
  - 本番と同じセキュリティ設定

デプロイフロー

# .github/workflows/deploy-staging.yml
name: Deploy to Staging

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'デプロイするバージョン/コミット'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: staging
      # 承認者の設定（GitHub Environment Protection）
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.inputs.version }}

      - name: Deploy to Staging
        run: ./deploy.sh staging

      - name: Run Smoke Tests
        run: yarn test:smoke

      - name: Notify Stakeholders
        uses: slackapi/slack-github-action@v1
        with:
          channel-id: 'releases'
          slack-message: |
            📦 ステージング環境を更新しました
            URL: https://staging.example.com
            バージョン: ${{ github.event.inputs.version }}

            本番リリース前の最終確認をお願いします

ステージング確認チェックリスト

## ステージング確認チェックリスト

### 機能確認
- [ ] 主要機能が正常に動作する
- [ ] 新機能が要件通りに動作する
- [ ] 既存機能に影響がない

### パフォーマンス
- [ ] ページ読み込み速度が許容範囲内
- [ ] APIレスポンスが許容範囲内
- [ ] メモリ使用量が正常

### セキュリティ
- [ ] 認証・認可が正しく動作する
- [ ] 機密情報が露出していない

### その他
- [ ] モバイル表示が正常
- [ ] 多言語対応が正常（該当する場合）
- [ ] アクセシビリティに問題がない

---
✅ すべて確認完了 → 本番リリース承認へ

---

4. 本番環境（Production）

本番環境の役割

• サービス提供: 実際のユーザーが利用
• 可用性維持: 24/7 稼働
• 監視: エラー、パフォーマンスの監視
• インシデント対応: 問題発生時の対応

本番環境の特徴

# 本番環境の設定例
environment: production
features:
  - 高可用性構成（冗長化）
  - オートスケーリング
  - CDN配信
  - 本番API連携
  - 監視・アラート設定
  - バックアップ
  - WAF/セキュリティ対策

デプロイフロー

# .github/workflows/deploy-production.yml
name: Deploy to Production

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'リリースするバージョン'
        required: true
      release_note:
        description: 'リリースノート'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      # 本番は複数人の承認を必須に
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.inputs.version }}

      - name: Create Release Tag
        run: |
          git tag -a "v${{ github.run_number }}" -m "${{ github.event.inputs.release_note }}"
          git push origin "v${{ github.run_number }}"

      - name: Deploy to Production
        run: ./deploy.sh production

      - name: Health Check
        run: |
          sleep 30
          curl -f https://example.com/health || exit 1

      - name: Notify Release
        uses: slackapi/slack-github-action@v1
        with:
          channel-id: 'releases'
          slack-message: |
            🚀 本番リリース完了
            バージョン: v${{ github.run_number }}

            ${{ github.event.inputs.release_note }}

環境間のプロモーションフロー

全体フロー図

┌─────────────────────────────────────────────────────────────────────────┐
│                    環境プロモーション（昇格）フロー                       │
└─────────────────────────────────────────────────────────────────────────┘

Day 1
├── 9:00  チケット作成
├── 9:05  Claude Code → PR作成
├── 9:10  AIレビュー → プレビュー環境
├── 10:00 開発者確認 ✅
├── 10:15 PRマージ → 【開発環境】にデプロイ
│
Day 2
├── 2:00  定期ジョブ → 【テスト環境】にデプロイ
├── 10:00 QAチームがテスト開始
├── 17:00 QAテスト完了 ✅ バグなし
│
Day 3
├── 10:00 手動トリガー → 【ステージング】にデプロイ
├── 14:00 関係者が最終確認 ✅
├── 15:00 リリース承認
├── 15:30 → 【本番環境】にデプロイ 🚀
└── 15:35 リリース完了通知

各プロモーションの条件

GitHub Environments の設定

環境の作成

リポジトリの Settings → Environments で各環境を作成：

Environments:
├── development
│   └── (保護なし - 自動デプロイ)
├── testing
│   └── (保護なし - 自動デプロイ)
├── staging
│   └── Required reviewers: tech-lead
└── production
    ├── Required reviewers: tech-lead, pm
    └── Wait timer: 5 minutes

環境変数の設定

各環境ごとに異なる環境変数を設定：

development:
  DATABASE_URL: postgres://dev-db/app
  API_URL: https://dev-api.example.com
  LOG_LEVEL: debug

testing:
  DATABASE_URL: postgres://test-db/app
  API_URL: https://test-api.example.com
  LOG_LEVEL: info

staging:
  DATABASE_URL: postgres://staging-db/app
  API_URL: https://staging-api.example.com
  LOG_LEVEL: info

production:
  DATABASE_URL: postgres://prod-db/app
  API_URL: https://api.example.com
  LOG_LEVEL: warn

実践的な運用Tips

1. データの管理

2. 外部サービス連携

3. アクセス制御

# 環境ごとのアクセス制御
development:
  access: VPN or IP制限
  auth: 不要 or Basic認証

testing:
  access: VPN or IP制限
  auth: Basic認証

staging:
  access: VPN or IP制限
  auth: 本番と同じ認証

production:
  access: 公開
  auth: 本番認証

4. 監視とアラート

# 環境ごとの監視設定
development:
  monitoring: 基本監視
  alerting: Slackのみ

testing:
  monitoring: 基本監視
  alerting: Slackのみ

staging:
  monitoring: 本番同等
  alerting: Slack

production:
  monitoring: 完全監視
  alerting: Slack + PagerDuty + メール

ロールバック手順

各環境のロールバック

name: Rollback

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'ロールバック対象環境'
        required: true
        type: choice
        options:
          - development
          - testing
          - staging
          - production

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: ${{ github.event.inputs.environment }}
    steps:
      - name: Rollback
        run: |
          ./rollback.sh ${{ github.event.inputs.environment }}

      - name: Notify
        run: |
          curl -X POST $SLACK_WEBHOOK \
            -d '{"text": "⚠️ ${{ github.event.inputs.environment }} をロールバックしました"}'

まとめ

4つの環境を適切に使い分けることで、安全で効率的なリリースプロセスを実現できます。

シリーズまとめ

これで「AIを使った開発手法」シリーズは完結です。

チケット作成から本番リリースまでの自動化パイプライン構築を支援いたします。お気軽にお問い合わせください。