Vercel 移行ガイド：自前ホスト（AWS/EC2/Netlify）から無停止で乗り換える実践手順

「Next.js を EC2 や ECS、あるいは Netlify で動かしているが、運用の手間とデプロイの遅さに疲れた。Vercel に移したい。でも止めたくない」——この相談は本当に多いです。移行はやり方さえ間違えなければ無停止で、しかもロールバックも一瞬です。逆に、ステートフルな依存を見落とすと本番で詰まります。

この記事は、自前ホスト（AWS/EC2/ECS/Amplify）や Netlify から Vercel へ無停止で移行する実践手順を、Vercel 公式ドキュメントに忠実にまとめます。移行先の本番運用の全体像は Vercel 本番運用ガイド を参照してください。

移行の大原則：DNS カットオーバーを最後にする

移行で最も多い事故は「いきなり本番ドメインを Vercel に向けて、動かない」。これを避ける鉄則は——

①Vercelにデプロイ（プレビューURLで動く状態を作る）
   ↓
②プレビューで本番同等の検証（並走）
   ↓
③本番ブランチへPromote（まだ独自ドメインは旧基盤）
   ↓
④DNSを切り替える（最後の一手）
   ↓
⑤問題があればDNSを戻すだけ＝即ロールバック

DNS を最後の一手にすることで、切り替え前にいくらでも検証でき、問題時は DNS を戻すだけで旧基盤に復帰できます。

ステップ0：移行可否を見極める（最重要）

コードを動かす前に、「サーバー前提の依存」を棚卸しします。ここを飛ばすと本番で詰まります。Vercel はステートレスなサーバーレス基盤なので、以下は置き換えが必要です。

判断：標準的な Next.js（App Router、ステートレス、外部 DB）なら移行は容易。逆に「ファイルをローカルに書く」「常駐プロセスに依存」が深いほど、移行は再設計を伴います。ここを正直に評価するのが成否を分けます。

ステップ1：プロジェクトを Vercel に接続

Git 連携が最短です。リポジトリをインポートすると、プッシュごとにプレビューが作られます。

npm i -g vercel@latest
vercel login
vercel link            # 既存プロジェクトに紐付け（or 新規作成）
vercel                 # プレビューデプロイを作成 → 固有URLで動作確認

フレームワークは自動検出されますが、ビルドコマンド・出力ディレクトリ・ルートディレクトリ（モノレポなら特に）を設定で確認します。モノレポは Turborepo のルート設定に注意。

ステップ2：環境変数とシークレットを移送

旧基盤の環境変数を、Vercel の**3環境（production / preview / development）**へ整理して移します。

# 本番のシークレットを production だけに登録
vercel env add DATABASE_URL production
vercel env add STRIPE_SECRET_KEY production

# プレビューには本番と別の値（ステージングDB等）を
vercel env add DATABASE_URL preview

# ローカル開発用をローカルへ同期
vercel env pull .env.local

移送時の必須チェック（環境変数ガイド）：

• NEXT_PUBLIC_ 接頭辞に機密を載せない（ブラウザに露出）。API キーは無印で。
• 環境変数の変更は新しいデプロイにのみ適用される（既存デプロイは変わらない）。
• 外部クラウド（AWS S3/SES 等）へは、長命のアクセスキーを置かず OIDC 鍵レスへ切り替える好機。
• 合計サイズはデプロイあたり 64KBまで。

ステップ3：ステートフル依存を置き換える

ローカルファイル → Vercel Blob

EC2 のディスクに保存していたアップロードファイルや生成 PDF は、Blob へ。ユーザーアップロードは client upload（サーバーを経由せず、転送課金と 4.5MB 制限を回避）。

// 旧：fs.writeFileSync(path, buffer)
// 新：Vercel Blob（private で保存し、関数経由で配信）
import { put } from "@vercel/blob";
const blob = await put(`uploads/${id}.pdf`, buffer, {
  access: "private",
  addRandomSuffix: true,
});

DB 接続 → pooled 接続で枯渇を防ぐ

サーバーレスの並行性下では「1接続＝1プロセス」の Postgres が枯渇します。pooled 接続（Neon の pooled エンドポイント等）へ。

// Neon の pooled 接続（サーバーレスでは必須級）
import { neon } from "@neondatabase/serverless";
const sql = neon(process.env.DATABASE_URL!); // pooled エンドポイント

接続枯渇の理屈は PgBouncer・接続プーリング を参照。VPC 内の専用 DB は、公開＋認証エンドポイント化するか、Enterprise の Secure Compute を検討します。

cron / 常駐ワーカー → Cron Jobs / Workflows

// 旧：crontab や常駐デーモン → vercel.json の crons
{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [{ "path": "/api/cron/nightly", "schedule": "0 0 * * *" }]
}

Cron は CRON_SECRET で必ず保護し、長時間処理は Workflows/キューへ（Functions ガイド）。

ステップ4：プレビューで並走検証

DNS を切る前に、プレビュー（または Vercel の *.vercel.app 本番URL）で本番同等の検証を行います。

• **E2E（Playwright）**をプレビューURLに対して実行（E2E 設計）。
• 主要導線（ログイン・決済・アップロード・検索）を手動確認。
• x-vercel-cache でキャッシュが意図通り HIT/PRERENDER か確認（キャッシュ）。
• 必要なら旧基盤と Vercel を一定期間並走させ、トラフィックの一部だけ Vercel に流して比較（DNS の加重や、フロントのフラグで段階移行）。

ステップ5：DNS カットオーバーとロールバック

いよいよ本番ドメインを切り替えます。

事前：DNSレコードのTTLを短く（例 300秒）しておく（切替・巻き戻しを速く）
  ↓
Vercelにカスタムドメインを追加し、指示どおりA/CNAMEレコードを設定
  ↓
本番デプロイをPromote（Rolling Releases併用なら段階配信）
  ↓
DNSを切り替え → 伝播を監視（dig / 監視ツール）
  ↓
問題があれば：DNSを旧基盤に戻す（即ロールバック）
            or Vercel側はInstant Rollbackで前デプロイへ

• TTL を事前に短縮しておくと、切替も巻き戻しも速い。
• Vercel 側の不具合は Instant Rollback で即前デプロイへ。基盤ごと戻すなら DNS を戻す。
• Rolling Releases ＋ Skew Protection を使えば、本番でも段階的に Vercel デプロイを広げられる（デプロイ）。

ステップ6：移行後の最適化

移行は「動いた」がゴールではありません。

• キャッシュ設計：旧基盤で SSR だったページを ISR/CDN キャッシュへ。x-vercel-cache で HIT を実測（キャッシュ）。
• コスト：Active CPU 課金前提で、重い CPU 処理を分離、メモリ/maxDuration を用途に合わせる（コスト）。
• セキュリティ：WAF/BotID で入口を守り、OIDC 鍵レスへ移行（Firewall）。
• 可観測性：Observability で関数・エラー率・CWV を監視（可観測性）。

移行チェックリスト

• サーバー前提の依存（ファイル/常駐/長時間/VPC内DB）を棚卸し・置き換え設計
• 環境変数を3環境に整理、NEXT_PUBLIC_ に機密なし、変更は新デプロイのみ反映を理解
• DB は pooled 接続、ローカルファイルは Blob、cron は Cron Jobs
• プレビューで E2E・主要導線・x-vercel-cache を検証
• DNS の TTL を事前短縮、カスタムドメイン設定
• カットオーバー後の監視と、DNS/Instant Rollback の戻し手順を用意
• 移行後にキャッシュ・コスト・セキュリティ・可観測性を最適化

まとめ

Vercel への移行は、**「DNS を最後に切る」「ステートフル依存を先に置き換える」**の2点を守れば、無停止で安全に進められます。

1. 可否を正直に見極める（サーバー前提の依存が鍵）
2. プレビューで並走検証してから DNS を切る
3. ファイル→Blob、DB→pooled、cron→Cron Jobs、長時間→Workflows
4. TTL 短縮 → Promote → DNS 切替 → 監視 → 戻せる構成
5. 移行後にキャッシュ・コスト・セキュリティ・可観測性を仕上げる

移行可否の見極めから、ステートフル依存の再設計、無停止カットオーバー、移行後のコスト最適化まで、案件として伴走します。

本記事は Vercel 公式ドキュメント（環境変数・Blob・Cron・ドメイン、2026年6月時点）に基づきます。仕様は更新されるため、本番採用時は公式で最新値を確認してください。