Next.jsを本番環境に乗せるとき、選択肢の多さで迷う。Vercel・AWS・Heroku・Render…。どれを選ぶかはそのまま運用コストと性能に直結するため、入門段階では判断がつきにくい。
実務でNext.jsのデプロイを複数パターン経験した中で整理した基準をまとめる。
Next.jsのレンダリング方式を先に把握する
デプロイ先選択の前に、自分のアプリがどのレンダリング方式を使うかを確認する必要がある。
| 方式 | 概要 | デプロイ制約 |
|---|---|---|
| SSG（静的生成） | ビルド時にHTMLを生成 | 静的ホスティングでOK |
| SSR（サーバーサイドレンダリング） | リクエスト時にサーバーで生成 | Nodeサーバーが必要 |
| ISR（インクリメンタル静的再生成） | 静的 + 一定時間で再生成 | Vercel or Nodeサーバー推奨 |
| App Router（RSC） | Server Components | Nodeサーバーが必要 |
SSGのみのサイトなら静的ホスティングで十分。SSR・ISR・RSCを使うならNodeサーバーが動く環境が必要だ。
選択肢ごとの比較
Vercel
Next.jsを作っているVercelのホスティングサービス。設定なしで最も簡単に動く。
git push → 自動デプロイ → プレビュー環境 → 本番メリット:
- GitHubと連携するだけでCI/CDが完成する
- SSG・SSR・ISR・App Routerすべてに対応
- エッジキャッシュ・CDNが最初から最適化されている
- プレビューデプロイが自動で作られる（PRごとにURLが生成される）
デメリット:
- 無料プランはチームや商用利用に制限がある
- トラフィックが増えるとコストが跳ね上がる
- ベンダーロックインが強い
こんなプロジェクトに向いている:
- スタートアップの初期フェーズ
- 個人プロジェクト・副業
- チームが小さく、インフラに手をかけたくない
AWS S3 + CloudFront（静的ホスティング）
SSGで書き出した静的ファイルをS3に置き、CloudFrontで配信する構成。
メリット:
- コストが安い（S3の容量 + CloudFrontの転送量のみ）
- CDNのキャッシュ設定を細かく制御できる
- AWSの他サービスと連携しやすい
デメリット:
- SSR・ISR・App Router（RSC）には対応できない
- GitHub Actions等でデプロイパイプラインを自分で作る必要がある
当ブログ（taka-techblog.com）はこの構成で動いている。AstroのSSGビルドをS3にアップし、CloudFrontで配信するシンプルな構成だ。
こんなプロジェクトに向いている:
- SSGのみのブログ・ドキュメントサイト・マーケティングLP
- AWSに統一したいチーム
- コストを最小化したい
AWS Amplify
AWSが提供するフルマネージドのホスティング + CI/CD。VercelのAWS版に近い位置づけ。
メリット:
- GitHubと連携してCI/CDが自動構築される
- SSR対応（LambdaでNext.jsサーバーを動かす）
- Cognito・AppSyncなどAWSサービスとの統合が楽
- プレビューデプロイも対応
デメリット:
- Vercelと比べてNext.jsの最新機能の対応が遅れることがある
- 設定の学習コストがVercelより高い
- App Routerとの相性が以前は不安定だったが改善されてきている
こんなプロジェクトに向いている:
- AWSに統一したい + SSRが必要
- 会社のAWS契約でコストを一元管理したい
Heroku
Dockerコンテナ or Buildpackでアプリを動かすPaaS。Next.jsサーバーをそのまま動かせる。
メリット:
- Nodeサーバーとして動かすのが直感的
- データベース（Postgres）等のアドオンが簡単に追加できる
デメリット:
- 無料プランが廃止されており、コスト面でVercel・Flyに劣る
- Heroku独自の制約（エフェメラルファイルシステム等）を把握する必要がある
2026年現在の位置づけ: 正直、新規プロジェクトでHerokuを選ぶ理由は薄くなっている。コスパ面でもDX面でもVercelかFly.ioが上回っている。レガシープロジェクトの維持には引き続き使われている。
選択フローチャート
SSGのみ？
├─ Yes → AWS S3 + CloudFront（コスト最安）
│ または Cloudflare Pages
└─ No（SSR/ISR/RSC使う）
├─ AWSに統一したい → AWS Amplify
├─ インフラ管理したくない → Vercel
└─ 自前でサーバー管理OK → EC2 + ALB または ECS実務での私の選択
| プロジェクト | 選択 | 理由 |
|---|---|---|
| 当ブログ（Astro SSG） | AWS S3 + CloudFront | SSGのみ、コスト最安 |
| 社内Webアプリ（SSR） | AWS EC2 + ALB | 既存AWSインフラに統一 |
| 個人の検証用Next.js | Vercel | 設定ゼロで動く |
スタートアップ初期なら迷わずVercel。AWS環境に統一されているチームならAmplifyかEC2。SSGのみなら S3 + CloudFront。この3択で大体カバーできる。
まとめ
デプロイ先の選択基準はシンプルだ。
- レンダリング方式を決める（SSGのみかSSR/RSC含むか）
- チームのAWS依存度を確認する
- コストと運用工数のトレードオフを評価する
Next.jsのデプロイの全体像はTypeScriptとReact/Next.js実践本の7章に概説されている。入門として一通り読んだ後、実際の選択は本記事の判断基準を参考にしてほしい。
