【環境構築】Next.js × Cloudflare Workers の本番環境を一から構築する

はじめに

開発環境(dev)で動いている Next.js アプリケーションを本番環境にデプロイするには、単にコードを push するだけでは済みません。データベース、ストレージ、認証、決済など、各サービスのリソースを本番用に新規作成し、適切に分離する必要があります。

この記事では、Cloudflare Workers 上で動く Next.js アプリの本番環境を一から構築した際の手順と設計判断をまとめます。

この記事でわかること

• dev/prod 環境のリソース分離設計の考え方

• Cloudflare API トークンの種類と使い分け

• Terraform で本番 R2 バケットを作成する手順

• Prisma Postgres の環境別 DB 構成

• GitHub Secrets を使った環境別シークレット管理

• 本番デプロイまでの正しい作業順序

対象読者

• Cloudflare Workers + Next.js でアプリを運用している方

• dev 環境はあるが prod 環境をこれから作る方

• インフラを Terraform で管理したい方

前提条件

• Next.js (App Router) + Cloudflare Workers (OpenNext) の構成

• Terraform CLI がインストール済み

• GitHub Actions で CI/CD が構築済み

• dev 環境が稼働中

技術スタック

1. 環境分離の設計方針

リソース分離の原則

本番環境では全リソースを完全分離する方針を取りました。

API キーも分離する理由

• レート制限を環境ごとに独立させる

• 本番の障害が dev 環境に波及しない

• セキュリティ侵害時の影響範囲を限定

2. Cloudflare API トークンの設計

Cloudflare では用途別に3種類のトークンを使い分けます。

トークン構成

R2 トークンの種類に注意

R2 の API トークン管理画面には2種類あります。

• アカウント API トークン — 組織に紐づく。組織を離れても有効。本番推奨

• ユーザー API トークン — 個人に紐づく。組織を離れると無効化

3. Terraform で R2 バケットを作成

ディレクトリ構成

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── prod/
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
└── modules/
    ├── r2/          # R2バケット + CORS設定
    └── worker/      # Worker Cronトリガー

prod/main.tf の構成

module "r2" {
  source = "../../modules/r2"

  account_id  = var.cloudflare_account_id
  bucket_name = "app-prod"
  allowed_origins = [
    "https://example.com",  # 本番ドメインのみ
  ]
}

module "worker" {
  source = "../../modules/worker"

  account_id  = var.cloudflare_account_id
  worker_name = "app"
  cron_schedules = ["0 15 * * *"]  # JST 0:00
}

R2 だけ先行作成

Worker Cron トリガーは既存の Worker が必要なため、初回は R2 だけ先に作成します。

cd terraform/environments/prod
terraform init
terraform plan -target=module.r2
terraform apply -target=module.r2

4. Prisma Postgres の環境別構成

同一プロジェクト内で DB を分離

Prisma Console では、1つのプロジェクト内に複数のデータベースを作成できます。新しいプロジェクトを作る必要はありません。

プロジェクト: my-app
├── Development  ← dev環境用（既存）
└── Production   ← prod環境用（新規作成）

作成手順

1. Prisma Console でプロジェクトを開く

2. 左サイドバーの DATABASES の + ボタンをクリック

3. 名前: Production、リージョン: Asia Pacific (Tokyo)

4. 2つの接続 URL を取得

5. GitHub Secrets の環境別管理

GitHub Environments の活用

GitHub Actions の environment 機能を使い、環境別にシークレットを分離します。

# deploy.yml
jobs:
  deploy:
    environment: ${{ github.ref == 'refs/heads/main' && 'prod' || 'dev' }}

これにより:

• main ブランチ → prod 環境のシークレットを使用

• develop ブランチ → dev 環境のシークレットを使用

CLI で一括登録

# 環境別にシークレットを登録
gh secret set DATABASE_URL --env prod --body "[DATABASE_URL]"
gh secret set AUTH_SECRET --env prod --body "$(openssl rand -base64 32)"
gh secret set CRON_SECRET --env prod --body "$(openssl rand -hex 32)"
# ... 他のシークレットも同様

必要なシークレット一覧

6. Stripe 本番モードの注意点

Stripe Live モードの有効化にはビジネスオンボーディングが必要です。

必要な情報

• 事業形態・個人情報

• ビジネスのウェブサイト（表示可能で公開されていること）

• 銀行口座情報

• 2段階認証設定

7. 正しい作業順序

各サービス間の依存関係を考慮すると、以下の順序が最適です。

Phase 1: リソース作成

1. Cloudflare API トークン作成 (Terraform用 + wrangler用 + R2用)
2. Terraform apply → R2 バケット作成
3. Prisma Console → 本番 DB 作成
4. Google Cloud Console → OAuth クライアント作成
5. 各サービス → API キー作成 (OpenAI, Gemini, Aivis, Resend)

Phase 2: デプロイ準備

6. AUTH_SECRET, CRON_SECRET を生成
7. GitHub Secrets に全シークレットを登録 (Stripe除く)
8. Worker 名の環境別切り替え対応

Phase 3: デプロイ & 後続設定

9.  main ブランチに push → prod デプロイ
10. Cloudflare → カスタムドメイン設定
11. Stripe → ビジネスオンボーディング完了
12. Stripe → Product/Price/Webhook 設定
13. GitHub Secrets に Stripe シークレット追加
14. 再デプロイ
15. Terraform apply → Worker Cron トリガー追加

Tips

8. デプロイ時のトラブルシューティング

初回の本番デプロイでは、開発環境では発生しなかった問題がいくつか発生しました。

pgvector 拡張の未インストール

prisma db push で ERROR: type "vector" does not exist エラーが発生。新規 DB に pgvector 拡張がインストールされていないため。

psql '[DIRECT_URL]' -c 'CREATE EXTENSION IF NOT EXISTS vector;'

prisma db push の --accept-data-loss

新規 DB へのスキーマ push 時に「データ消失の可能性」警告で停止。初回のみローカルから手動実行し、CI のコマンドはそのまま維持。

DIRECT_URL='[接続文字列]' bunx prisma db push --accept-data-loss

Stripe 環境変数未設定によるビルドエラー

Stripe の初期化コードが環境変数を必須としているため、未設定だとビルドが失敗。ダミー値を設定してビルドを通し、本番 Stripe 設定完了後に差し替える。

9. カスタムドメインの設定

Cloudflare Workers のカスタムドメインは API で設定可能。ダッシュボードに行く必要はありません。

curl -X PUT \
  "https://api.cloudflare.com/client/v4/accounts/[ACCOUNT_ID]/workers/domains" \
  -H "Authorization: Bearer [API_TOKEN]" \
  -H "Content-Type: application/json" \
  -d '{"hostname":"example.com","service":"worker-name","environment":"production"}'

• SSL 証明書は自動発行される

• DNS が Cloudflare で管理されていれば即時反映

まとめ

• リソースは完全分離が原則。Cloudflare アカウントだけ共通、それ以外は全て環境別

• API トークンは用途別に作成。Terraform 用、CI/CD 用、アプリ用で分ける

• Terraform の部分適用 (-target) で依存関係のないリソースから作成できる

• GitHub Environments で環境別シークレット管理。ブランチ名で自動切替

• Stripe はデプロイ後に設定。ウェブサイトの公開が前提条件

• 作業順序が重要。依存関係を把握して効率的に進める

• 初回デプロイは手動ステップが必要。pgvector 拡張のインストール、prisma db push --accept-data-loss

• Stripe は段階的に有効化。ダミー値でビルドを通し、オンボーディング後に差し替え

• カスタムドメインは API 設定可能。Cloudflare Dashboard 不要