Next.js 14 と Vercel のデプロイ手順とベストプラクティス

2026年6月23日

Contents

1 前提条件と環境設定
- 1.1 Node.js と Git の推奨バージョン
- 1.2 Vercel アカウントの作成とセキュリティ設定
2 Next.js 14 プロジェクトの作成
- 2.1 create‑next‑app での初期化
- 2.2 App Router と Server Components の概要
3 Vercel ダッシュボードでのリポジトリ連携と設定
- 3.1 GitHub リポジトリのインポート手順
- 3.2 next.config.js の最新設定例と Edge Functions の有効化方法
4 ローカルデプロイとプレビュー環境（Vercel CLI）
- 4.1 Vercel CLI でのローカル開発サーバーと本番デプロイ
- 4.2 ビルド設定・キャッシュ戦略・環境変数の管理
5 カスタムドメインの追加と DNS 設定
- 5.1 カスタムドメインの登録手順
- 5.2 DNS レコード（CNAME / ALIAS）の設定ポイント
6 トラブルシューティングとチームコラボレーション
- 6.1 代表的エラーと対処法（ビルドタイムアウト・依存関係）
- 6.2 プレビュー URL の活用とレビュー/承認フロー
7 次のステップ

スポンサードリンク

前提条件と環境設定

このセクションでは、Next.js 14 と Vercel に必要な 開発環境 を確認します。Node.js・Git のバージョンや Vercel アカウントのセットアップが正しく行われていないと、ローカルビルドや CLI 操作でエラーになるため、最初にしっかり整えておきましょう。

Node.js と Git の推奨バージョン

ポイント
Next.js 14 は Node.js 18 LTS 以降 がサポート対象です（20 でも動作しますが必須ではありません）。Git は 2.30 以上を用意すると、サブモジュールや LFS の互換性で問題が起きにくくなります。

導入文
以下のコマンドで現在インストールされているバージョンを確認し、必要に応じてアップデートしてください（80〜200字程度）。

# バージョン確認
node -v   # 例: v18.19.0 以上が推奨
git --version   # 例: git version 2.41.0

# バージョン確認

node -v # 例: v18.19.0 以上が推奨

git --version # 例: git version 2.41.0

更新手順

Node.js：公式サイトの LTS バイナリ（https://nodejs.org/ja/）からインストール、または nvm・brew 等でバージョン切替。
Git：macOS は brew upgrade git、Linux は sudo apt-get install -y git で最新パッケージに更新。

まとめ
Node.js 18+ と Git 2.30+ が揃っていれば、以降の手順はスムーズに進行します。

Vercel アカウントの作成とセキュリティ設定

ポイント
Vercel の無料プランでアカウントを作り、メール認証に加えて 二要素認証（2FA） を必ず有効化してください。

導入文
2FA を設定すると、GitHub 連携時の権限付与が安全になるだけでなく、チーム内のアクセス管理も簡単になります。

https://vercel.com にアクセスし「Sign Up」ボタンをクリック
GitHub・GitLab・メールアドレスのいずれかで登録（GitHub 推奨）
ダッシュボード右上の Settings → Security から Two‑factor Authentication を有効化
Google Authenticator、Authy 等の認証アプリでコードを入力

まとめ
2FA が完了すれば、Vercel と Git リポジトリの安全な連携が確立し、次章以降のデプロイ作業に進めます。

Next.js 14 プロジェクトの作成

この章では、公式推奨の create-next-app@latest コマンドで App Router と Server Components が有効な ベースプロジェクトを生成します。最小構成から始めることで、後から必要な設定を段階的に追加しやすくなります。

create‑next‑app での初期化

ポイント
npx create-next-app@latest my-vercel-app --ts --app を実行すると、TypeScript と App Router が自動組み込みされた Next.js 14 プロジェクトが作成されます。

導入文
このコマンドは、Next.js 13 以降で追加された app/ ディレクトリ構造と Server Components のデフォルト有効化を同時に行います。

npx create-next-app@latest my-vercel-app --ts --app
cd my-vercel-app
npm run dev   # http://localhost:3000 でローカル開発サーバー起動

npx create-next-app@latest my-vercel-app --ts --app

cd my-vercel-app

npm run dev # http://localhost:3000 でローカル開発サーバー起動

生成された app/page.tsx は サーバーコンポーネント として扱われ、クライアント側に不要な JavaScript が送られません。

App Router と Server Components の概要

ポイント
App Router はファイルシステムベースのルーティングを app/ ディレクトリで提供し、Server Components によってページ単位でサーバー側レンダリングが可能です。

導入文
以下の例は、データ取得を完全にサーバー側で完結させる典型的な Server Component の書き方です（30〜80字）。

// app/dashboard/page.tsx (Server Component)
import { fetchUserStats } from '@/lib/api';

export default async function Dashboard() {
  const stats = await fetchUserStats(); // サーバー上で API 呼び出し
  return (
    &lt;section&gt;
      &lt;h1&gt;Dashboard&lt;/h1&gt;
      &lt;pre&gt;{JSON.stringify(stats, null, 2)}&lt;/pre&gt;
    &lt;/section&gt;
  );
}

// app/dashboard/page.tsx (Server Component)

import { fetchUserStats } from '@/lib/api';

export default async function Dashboard() {

const stats = await fetchUserStats(); // サーバー上で API 呼び出し

return (

<h1>Dashboard</h1>

<pre>{JSON.stringify(stats, null, 2)}</pre>

</section>

);

}

use client ディレクティブが無い限り、クライアント側に JavaScript がバンドルされない点がパフォーマンス向上の鍵です。

まとめ
App Router と Server Components を組み合わせることで、低遅延・高スケーラビリティな Next.js アプリを簡単に構築できます。

Vercel ダッシュボードでのリポジトリ連携と設定

この章では、GitHub リポジトリを Vercel にインポートし Edge Functions や環境変数を正しく設定する手順をご紹介します。2026年4月に刷新された UI では、プロジェクトごとの設定が一元化されており、操作ミスが減ります。

GitHub リポジトリのインポート手順

ポイント
Vercel の New Project から GitHub を選択し、対象リポジトリをインポートすれば自動ビルドが有効になります。

導入文
インポート時に Vercel が vercel.json と next.config.js を解析し、必要なビルド設定や Edge Runtime の情報を自動で検出します。

Vercel コンソール → Projects → New Project
「Import Git Repository」→ GitHub を選択し OAuth で連携
デプロイしたいリポジトリ（例: my-vercel-app）を検索・選択
ビルドコマンドはデフォルトのままで Deploy をクリック

これだけで、プッシュするたびに自動ビルド＆プレビュー URL が生成されます。

next.config.js の最新設定例と Edge Functions の有効化方法

ポイント
Edge Functions は ページや API ルートごとに runtime: 'edge' を指定 します。output: 'edge' は誤りで、代わりに output: 'standalone'（Vercel 最適化ビルド）を使用します。

導入文
以下の設定例は、現在の Next.js 14 と Vercel が推奨する構成です。実験的フラグは最新版に合わせて更新しています。

// next.config.js (2026 年版)
module.exports = {
  // Server Actions は stable になるまで experimental フラグで有効化
  experimental: {
    serverActions: true,          // 現在も実験的機能
  },
  output: 'standalone',           // Vercel の最適化ビルド形式

  // 任意の API Route を Edge Runtime にする例
  async rewrites() {
    return [
      {
        source: '/api/edge/:path*',
        destination: '/api/edge/:path*',
      },
    ];
  },
};

// next.config.js (2026 年版)

module.exports = {

// Server Actions は stable になるまで experimental フラグで有効化

experimental: {

serverActions: true, // 現在も実験的機能

output: 'standalone', // Vercel の最適化ビルド形式

// 任意の API Route を Edge Runtime にする例

async rewrites() {

return [

{

source: '/api/edge/:path*',

destination: '/api/edge/:path*',

];

};

Edge Function の個別指定（API Route）

// pages/api/edge/hello.ts
export const config = { runtime: 'edge' }; // ← Edge Runtime を明示

export default async function handler(req) {
  return new Response(JSON.stringify({ message: 'Hello from Edge!' }), {
    headers: { 'Content-Type': 'application/json' },
  });
}

// pages/api/edge/hello.ts

export const config = { runtime: 'edge' }; // ← Edge Runtime を明示

export default async function handler(req) {

return new Response(JSON.stringify({ message: 'Hello from Edge!' }), {

headers: { 'Content-Type': 'application/json' },

});

}

まとめ
next.config.js の output: 'standalone' と、エンドポイント単位で runtime: 'edge' を設定すれば、Vercel の最新 Edge 機能を安全に利用できます。

ローカルデプロイとプレビュー環境（Vercel CLI）

ローカルでも本番と同じビルドパイプラインを再現できると、デバッグが格段に楽になります。ここでは Vercel CLI の最新コマンドとキャッシュ・環境変数の扱い方を解説します。

Vercel CLI でのローカル開発サーバーと本番デプロイ

ポイント
vercel dev でローカルサーバーを起動し、本番デプロイは vercel deploy --prod を使用します。旧来の vercel --prod は非推奨です。

導入文
CLI が Vercel ビルダーと同一設定ファイル（vercel.json）を参照するため、ローカルとクラウドで結果が一致します。

# CLI のインストール
npm i -g vercel   # or brew install vercel

# ローカル開発サーバー起動（Edge Runtime もエミュレート）
vercel dev        # http://localhost:3000 がプレビュー URL と同等

# 本番環境へデプロイ
vercel deploy --prod

# CLI のインストール

npm i -g vercel # or brew install vercel

# ローカル開発サーバー起動（Edge Runtime もエミュレート）

vercel dev # http://localhost:3000 がプレビュー URL と同等

# 本番環境へデプロイ

vercel deploy --prod

--previews フラグを付けるとプレビュー用の一時デプロイが作成でき、PR ごとのテストに便利です。

ビルド設定・キャッシュ戦略・環境変数の管理

ポイント
Vercel のビルドキャッシュは vercel.json の build.cache オブジェクト で制御します。cache: true と書くだけでも自動的に依存パッケージや .next ディレクトリが再利用されます。

導入文
以下は、ビルドコマンド・環境変数・キャッシュ有効化を一括で設定した例です（30〜80字）。

// vercel.json (2026 年版)
{
  &quot;build&quot;: {
    &quot;command&quot;: &quot;npm run build&quot;,
    &quot;env&quot;: {
      &quot;NEXT_PUBLIC_API_URL&quot;: &quot;https://api.example.com&quot;
    },
    &quot;cache&quot;: true               // ビルドキャッシュを有効化
  }
}

// vercel.json (2026 年版)

{

"build": {

"command": "npm run build",

"env": {

"NEXT_PUBLIC_API_URL": "https://api.example.com"

"cache": true // ビルドキャッシュを有効化

}

CLI で環境変数を上書きしたいとき

vercel deploy --previews \
  --env NEXT_PUBLIC_API_URL=https://staging.api.example.com

vercel deploy --previews \

--env NEXT_PUBLIC_API_URL=https://staging.api.example.com

まとめ
vercel.json の build.cache を正しく設定すれば、依存インストールや TypeScript コンパイルがスキップされ、ビルド時間が約30%短縮できます。

カスタムドメインの追加と DNS 設定

独自ドメインで公開するとブランド価値が向上します。Vercel の最新 UI では Domains タブから簡単に登録でき、必要な DNS レコードも自動提案されます。

カスタムドメインの登録手順

ポイント
プロジェクト設定 → Domains にドメインを入力し「Add Domain」だけで完了します。SSL 証明書は Vercel が自動取得します。

導入文
以下の手順で、example.com を Vercel プロジェクトに紐付けます。

Project Settings → Domains → Add Domain
example.com（または www.example.com）を入力し「Continue」
表示された CNAME/ALIAS レコードをドメインレジストラへコピー
数分待つと Vercel が自動で SSL を発行し、HTTPS が有効化

DNS レコード（CNAME / ALIAS）の設定ポイント

ポイント
サブドメインは CNAME、ルートドメインは ALIAS/ANAME（または Cloudflare の CNAME フラットニング）を推奨します。Aレコードで固定 IP を指定すると、Vercel 側のエッジロケーション変更に追従できません。

ドメイン種別	推奨レコード	設定例
`www.example.com` (サブ)	CNAME	`www → cname.vercel-dns.com`
`example.com` (ルート)	ALIAS/ANAME*	`@ → alias.vercel-dns.com`

* プロバイダーが ALIAS をサポートしていない場合は、Cloudflare の CNAME フラットニング を利用すると同等の効果があります。

まとめ
正しいレコードタイプを設定すれば、Vercel が自動管理する CDN と SSL が即座に有効化されます。

トラブルシューティングとチームコラボレーション

デプロイ時に遭遇しやすいエラーとその対処法、さらにプレビュー URL を活用したレビュー・承認フローをまとめました。Vercel のリアルタイムログ機能と GitHub Pull Request 連携で、問題の早期発見と迅速なフィードバックが可能です。

代表的エラーと対処法（ビルドタイムアウト・依存関係）

ポイント
ビルドがタイムアウトする場合は vercel.json の build.maxDuration を延長し、依存関係の衝突はローカルでクリーンインストール後に再デプロイします。

導入文
以下は具体的な設定例と対処手順です（30〜80字）。

// vercel.json
{
  &quot;build&quot;: {
    &quot;maxDuration&quot;: 600   // デフォルト 300 秒から 10 分に延長
  }
}

// vercel.json

{

"build": {

"maxDuration": 600 // デフォルト 300 秒から 10 分に延長

}

依存エラーが出たら次を実行：

rm -rf node_modules .next
npm ci --prefer-offline      # クリーンインストール
vercel deploy --prod

rm -rf node_modules .next

npm ci --prefer-offline # クリーンインストール

vercel deploy --prod

まとめ
maxDuration の調整とローカルでのクリーンビルドが、ビルド失敗を防ぐ基本手順です。

プレビュー URL の活用とレビュー/承認フロー

ポイント
Pull Request が作成されるたびに Vercel が自動生成したプレビュー URL を GitHub コメントで通知します。ステークホルダーは実際の UI を確認しながら Approve / Request changes が行えます。

導入文
Vercel の「Preview Deployments」機能と環境変数上書きにより、本番データを汚染せず安全に検証できます。

git push origin feature/login → PR 作成
Vercel が自動でプレビュー URL（例: pr-12--my-vercel-app.vercel.app）をコメント
コメント内リンクから UI を確認し、QA が承認

まとめ
プレビュー URL と GitHub 連携によるレビュープロセスは、デプロイ前に実際の動作を検証できる最も効果的な手段です。

次のステップ

本記事で示した 「Next.js 14 + Vercel デプロイフロー」 を自分のリポジトリで試すだけで、ローカル開発・プレビュー・本番公開がシームレスに統合されたワークフローが完成します。チーム全体でこの手順を標準化し、継続的デリバリー（CD）を加速させましょう。