Contents
前提条件と環境構築
このセクションでは、Next.js アプリを Vercel にデプロイするまでに必ず揃えておくべきツール・バージョン を確認します。ローカルでの開発が滞りなく進むように、Node 系ランタイムやパッケージマネージャの推奨バージョンを事前にチェックしておくことが重要です。また、Vercel アカウントは無料プランでも本番環境へのデプロイが可能なので、まずはアカウント作成だけでも完了させておきましょう。
Node.js・npm / Yarn のバージョン確認
以下のコマンドでインストールされているバージョンを確認し、推奨範囲に収まっていない場合はアップデート してください。
- Node.js:
18.x以上(LTS 系が最も安定) - npm:
9.0以上(npm ciが高速ビルドの鍵) - Yarn:
4.x (Berry)を推奨。yarn set version berryでプロジェクト単位に切り替えられます。
|
1 2 3 4 |
node -v # → v18.17.0 npm -v # → 9.8.1 yarn -v # → 4.2.2 (未インストールなら `npm i -g yarn`) |
必要ツール一覧(表)
| ツール | 推奨バージョン | インストール方法例 |
|---|---|---|
| Node.js | 18.x 以上 | nvm install 18 && nvm use 18 |
| npm | 9.0 以上 | Node に同梱、最新版は npm i -g npm@latest |
| Yarn (Berry) | 4.x 系 | npm i -g yarn && yarn set version berry |
| Next.js | 13.4 以降 | npx create-next-app@latest |
| Vercel CLI | 32.0 以上 | npm i -g vercel または pnpm add -g vercel |
ポイント:Node とパッケージマネージャが推奨バージョンを満たしていれば、以降の手順はほぼそのまま実行できます。
Next.js プロジェクトの作成とローカルテスト
この章では create-next-app を使ってプロジェクト雛形を生成し、ローカルサーバで動作確認するまでの流れを解説します。テンプレートが正しく起動すれば、Vercel への本番デプロイはほぼ自動化できます。
プロジェクト雛形の作成
npx create-next-app@latest は最新の Next.js 設定と依存関係を自動で取得します。以下の手順でプロジェクトディレクトリを作成してください。
|
1 2 3 4 5 6 |
# 1. 雛形生成(my-vercel-app という名前は任意) npx create-next-app@latest my-vercel-app # 2. ディレクトリに移動 cd my-vercel-app |
ポイント:
--tsオプションを付ければ TypeScript プロジェクトが最初から生成できます。
パッケージインストールと推奨コマンド
作成直後は node_modules が自動でインストールされますが、CI 互換性の高い npm ci(または yarn install --immutable)を使うことでロックファイル通りに確実にインストールできます。
|
1 2 3 4 5 6 |
# npm 推奨 npm ci # Yarn (Berry) 推奨 yarn install --immutable |
開発サーバの起動と動作確認
以下コマンドでローカル開発サーバを立ち上げ、ブラウザから http://localhost:3000 にアクセスします。デフォルトページが表示されたら成功です。
|
1 2 |
npm run dev # または yarn dev |
ポイント:
next devは自動リロード機能が組み込まれているため、コード変更を即座にプレビューできます。
Vercel へのデプロイ手順
このセクションでは CLI と UI の両方のフロー を網羅し、Git 連携・環境変数管理・カスタムドメイン設定までを段階的に解説します。どちらの方法でも「Zero‑Config」でデプロイできる点が Vercel の大きな利点です。
Vercel CLI のインストールと認証
Vercel CLI はローカルから直接ビルド・プレビュー・本番デプロイを実行できます。以下のコマンドでグローバルにインストールし、ブラウザベースの認証を完了させます。
|
1 2 3 4 5 6 |
# npm / pnpm 推奨インストール例 npm i -g vercel # または pnpm add -g vercel # 認証(初回のみ) vercel login |
認証が成功すると vercel whoami で現在のユーザー名を確認できます。
Git リポジトリ連携とプレビューデプロイ
Vercel は Git Provider と自動連携 するだけで、push ごとにプレビュー環境(Preview Deployment)を作成します。以下は一般的な手順です。
- Vercel Dashboard の New Project をクリック
- GitHub / GitLab / Bitbucket のいずれかを選択し、対象リポジトリを検索・インポート
- ビルドコマンドと出力ディレクトリは自動判別(Next.js なら
npm run buildと.next)
これで git push するたびに https://<branch>--my-vercel-app.vercel.app のプレビューが生成されます。
本番デプロイ(UI と CLI)
UI からの本番デプロイ
Dashboard のプロジェクトページで Deploy ボタンをクリックし、Production を選択すれば即座に本番環境へ反映されます。設定は自動的に最適化されたまま使用されます。
CLI からの本番デプロイ
|
1 2 |
vercel --prod # プロンプトに従いプロジェクト名とディレクトリを確認 |
--prod フラグが付くとプレビューではなく Production デプロイとして扱われ、URL は https://my-vercel-app.vercel.app になります。
ポイント:CI/CD パイプラインで自動本番デプロイしたい場合は
vercel --prod --confirmをスクリプトに組み込むと対話なしで実行できます。
環境変数の管理(H4)
Vercel Dashboard の Settings → Environment Variables にキー/バリューを登録すると、ビルド時およびランタイムで自動的に注入されます。ローカル開発では同名の .env.local を用意すれば同期が取れます。
| 用途 | 設定場所 | プレフィックス例 |
|---|---|---|
| ビルド時のみ | Build & Development Settings → Override Build Env | NEXT_PUBLIC_ でクライアント側に露出 |
| ランタイム(サーバー) | Environment Variables | API_KEY(サーバー専用) |
環境変数は 暗号化保存 され、Git リポジトリに平文が残らないため安全です。
カスタムドメイン設定・SSL 自動取得(H4)
独自ドメインを使用したい場合は次の手順で設定します。
- Dashboard のプロジェクトページ → Domains タブ → Add Domain
example.comを入力し、表示される CNAME(または A レコード)を DNS プロバイダーに設定- 数分後にステータスが Verified になり、自動で無料の Let's Encrypt SSL 証明書 が発行されます
ポイント:Vercel のエッジネットワークは自動的に HTTP→HTTPS リダイレクトを適用するため、追加設定は不要です。
現行の最適化オプションと実装例
この章では Vercel が提供している ISR(Incremental Static Regeneration)・Edge Functions・Edge Middleware といった本番向けパフォーマンス最適化機能を、具体的なコード例と共に解説します。これらはすべて 2024 年時点で正式サポートされているため、将来的な変更リスクは低く、安定して利用できます。
ISR(Incremental Static Regeneration)の活用
ISR は静的ページを一定間隔で再生成できる仕組みです。revalidate に秒数を指定すると、バックグラウンドで最新データが取得され、ユーザーは常に新しいコンテンツを受け取ります。
|
1 2 3 4 5 6 7 8 9 10 11 |
// pages/posts.tsx export async function getStaticProps() { const res = await fetch('https://api.example.com/posts'); const posts = await res.json(); return { props: { posts }, revalidate: 60, // 1 分ごとに再生成 }; } |
Vercel のエッジ CDN が最新の HTML を即座に配信するため、ページロードが常に高速 になります。
Edge Functions による動的 API とキャッシュ制御
Edge Functions はリクエスト直前のエッジロケーションで実行され、レスポンスヘッダーを自由に操作できます。以下は 30 秒間キャッシュしつつ stale-while-revalidate を付与する例です。
|
1 2 3 4 5 6 7 8 9 10 |
// pages/api/hello.ts(Edge Function) import { NextResponse } from 'next/server'; export async function GET() { const data = { message: 'Hello from Edge' }; const res = NextResponse.json(data); res.headers.set('Cache-Control', 's-maxage=30, stale-while-revalidate=60'); return res; } |
この設定により、エッジで返されたレスポンスは CDN に保存され、次回以降のリクエストは ミリ秒単位 の応答が実現します。
Edge Middleware のベストプラクティス
Middleware はリクエスト段階で軽量な処理(ヘッダー操作やリダイレクト)を行うために最適です。重い計算や外部 API 呼び出しは Edge Functions に委譲するのが安全です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// middleware.ts import { NextResponse } from 'next/server'; export function middleware(request) { // 国コード取得 → 日本向けにパスを書き換え const country = request.geo?.country || 'US'; if (country === 'JP') { const url = new URL(request.url); url.pathname = '/ja' + url.pathname; return NextResponse.rewrite(url); } return NextResponse.next(); } |
ポイント:Middleware の実行時間は 50ms 未満 が目安。タイムアウトが頻発する場合はロジックを簡素化してください。
ビルドエラーのデバッグと運用チェックリスト
デプロイ後に遭遇しやすいビルドエラーとその対処法、さらに本番環境で安定稼働させるための 最終確認項目 をまとめます。ログ取得手順と自動化のヒントも掲載しているので、トラブル時に素早く原因切り分けが可能です。
主なビルドエラーと対処法(表)
| エラー例 | 発生しやすい原因 | 推奨解決策 |
|---|---|---|
Module not found: Can't resolve '@/components/...' |
tsconfig/jsconfig のパスエイリアスがビルド時に反映されていない | jsconfig.json に "paths" を正しく記述し、next.config.js の webpack 設定と同期させる |
Edge Function size exceeds limit (1 MB) |
大量の依存ライブラリをインポートしている | 使わないモジュールは devDependencies に移すか、コード分割 (dynamic import) を活用 |
ReferenceError: process is not defined |
Edge Runtime では Node のグローバル変数が利用できない | 環境変数は process.env → import.meta.env(Vite 系)または Dashboard の環境変数に置き換える |
Failed to compile. webpack compiled with errors. |
TypeScript の型エラーや構文ミス | ローカルで npm run build を実行し、エラーメッセージを確認・修正 |
デバッグ手順
- Vercel Dashboard → Deployments → Logs へアクセスし、ビルドログの最後に表示されるエラー箇所をコピー。
- 同様のコマンドをローカルで再現する:
npm run build(またはyarn build)。 - エラーメッセージが示すファイル・行番号を修正し、再度ビルドを実行。
- 必要に応じて Build Output API から JSON 形式のログを取得し、CI に自動通知させることも可能です。
|
1 2 3 4 |
# Build Output API の例(curl) curl -H "Authorization: Bearer $VERCEL_TOKEN" \ https://api.vercel.com/v1/integrations/builds/<BUILD_ID>/output |
運用チェックリスト(抜粋)
- 環境
- [ ] Node と npm / Yarn が推奨バージョンか確認 (
node -v,npm -v,yarn -v) -
[ ]
next.config.jsに Edge Middleware 設定が正しく記述されている -
デプロイ
- [ ] プレビュー URL と本番 URL 両方でページ表示確認(画像・リンクの破損チェック)
-
[ ] 環境変数が Dashboard と
.env.localの両方に正しく同期されている -
ドメイン
- [ ] カスタムドメインの CNAME/A レコードが Vercel に向いているか DNS チェックツールで検証
-
[ ] HTTPS が自動的に有効化され、Mixed Content エラーが出ていない
-
パフォーマンス
- [ ] ISR の
revalidate設定が意図した間隔になっているか確認 - [ ] Edge Functions のキャッシュヘッダー (
Cache-Control) が期待通りに機能している
このチェックリストを デプロイ直前に実行 すれば、ほとんどのトラブルは未然に防げます。問題が発生した場合は上記デバッグ手順に沿って原因を特定し、再ビルド・再デプロイを行いましょう。
まとめ
本稿では「Node/Yarn のバージョン確認 → Next.js プロジェクト作成 → Vercel へのデプロイ(CLI/ UI)→ 環境変数とカスタムドメイン設定 → ISR・Edge 機能での最適化 → ビルドエラー対処」の一連の流れを網羅しました。ポイントは Zero‑Config を活かしつつ、Yarn 4 / npm ci のような最新ツールと ISR/Edge Functions によるパフォーマンス向上策を併用することです。この記事を手順通りに実行すれば、無料プランでも数秒で世界中のユーザーへ安定した Next.js アプリを提供できるようになります。ぜひご自身のプロジェクトで試してみてください。