Next.jsとは?
Reactとの違い・インストール・
基本操作を初心者向けに解説
Reactだけで開発しているとぶつかる「SEO弱い・ルーティング設定が面倒・サーバー機能がない」という壁を全部解決してくれるのがNext.jsだ。Vercel社が開発し、Netflix・TikTok・Twitch等が採用。概要・Reactとの違い・レンダリング方式・App RouterとPages Routerの差・インストールから実際のコードまで完全解説する。
1. Next.jsとは——Vercel社製のReactフレームワーク
Next.js(ネクスト・ジェーエス)は、ReactをベースにしたオープンソースのWebフレームワークで、Vercel社(旧Zeit社)が開発・メンテナンスしている。Reactが「UIを構築するためのライブラリ」なのに対し、Next.jsは「Reactで本格的なWebアプリを作るために必要な機能を全部まとめたフレームワーク」だ。
一言で言えば、「Reactに足りないものを全部追加した完成パッケージ」がNext.jsだ。ファイルベースのルーティング・サーバーサイドレンダリング・APIルート・画像最適化・フォント最適化など、Webアプリに必要な機能が最初から組み込まれている。
- Next.jsを開発しているのはVercel社——Vercelはデプロイプラットフォームも提供しており、Next.jsとの相性が最も良い
- Server ComponentsとClient Componentsの違い——App Router時代に必須の概念。”use client”の意味
- APIルート(Route Handlers)——Next.jsだけでバックエンドAPIを作れる。Node.jsサーバーが不要になる
- フォント最適化(next/font)——GoogleフォントをCLSなしで読み込む機能
- メタデータAPI——SEO対応のmetadataオブジェクトでheadタグを管理する方法
- Next.jsのデメリット——学習コスト・Vercel依存・ビルド時間の問題
- 「React単体で十分」な場合と「Next.jsが必要」な場合の判断基準
- 採用企業(Netflix・TikTok・Twitch・GitHub Copilot等)と向いているプロジェクト
2. ReactとNext.jsの違い——根本から理解する
ReactとNext.jsの関係は「ライブラリ」と「フレームワーク」という根本的な違いがある。Reactは「道具」、Next.jsは「道具が全部揃ったツールボックス」だと考えると分かりやすい。
UIライブラリ(Meta/Facebook製)
- UIを構築するためのライブラリ
- ルーティングは自分で設定(React Router等)
- サーバー機能は別途用意が必要
- ビルドツールの設定が必要(Vite・Webpack等)
- 状態管理ライブラリも別途選択が必要
- 既存アプリへの部分的な導入に向いている
- React Native(モバイルアプリ)にも応用できる
Reactフレームワーク(Vercel製)
- Reactを含んだフルスタックフレームワーク
- ファイルを置くだけで自動ルーティング
- サーバー機能を内蔵(APIルート・SSR等)
- ゼロコンフィグで即開発開始
- 画像・フォント・SEOの最適化が標準搭載
- 新規プロジェクト・本格的なWebアプリに向いている
- フロントのみならずAPIサーバーも担える
| 比較項目 | React(単体) | Next.js |
|---|---|---|
| 位置づけ | UIを構築するライブラリ | Reactをベースにしたフレームワーク |
| 開発元 | Meta(旧Facebook) | Vercel社 |
| URLルーティング | React Router等を自分でインストール・設定 | ファイルを配置するだけで自動生成 |
| サーバー機能 | Node.js等を別途用意して接続 | APIルート(Route Handlers)を内蔵 |
| レンダリング方式 | 基本はCSRのみ(クライアントサイド) | CSR・SSR・SSG・ISRを使い分け可能 |
| 環境構築 | Vite・Webpackのビルドツール設定が必要 | create-next-appで即座に開始 |
| SEO | CSRのためSEOに不利(JavaScriptが実行されるまで空ページ) | SSR/SSGによりSEOに有利(完成したHTMLを送る) |
| 画像最適化 | 自前で対応(sharp等のライブラリが必要) | next/imageコンポーネントで自動最適化 |
| フォント | 別途Google Fonts読み込みコードが必要 | next/fontで最適化した読み込みが内蔵 |
3. 4つのレンダリング方式——CSR・SSR・SSG・ISRの使い分け
Next.jsが「高速で・SEOに強い」と言われる理由が、この4つのレンダリング方式にある。ページの特性に応じて最適な方式を選ぶことで、速度とSEOを両立できる。
Client Side Rendering
ブラウザ側でJSを実行してHTMLを生成。最初は「空のHTML」が届き、JSが実行されて初めて表示される。SEOに弱い
Server Side Rendering
リクエストのたびにサーバーで完成HTMLを生成してから送る。ユーザーごとに違うコンテンツに対応。SEOに強い
Static Site Generation
ビルド時にHTMLを事前生成して静的配信。最も高速。更新頻度の低いページに最適。SEOに最も強い
Incremental Static Regeneration
SSGをベースに一定時間後だけ再生成。更新頻度が中程度のページに向く。Next.js独自の機能
| 方式 | HTMLはいつ生成される | SEO | 表示速度 | 向いているページ例 |
|---|---|---|---|---|
| CSR | ブラウザ上でJS実行後 | 弱い | 初期表示は遅い | ログイン後のダッシュボード・管理画面 |
| SSR | リクエスト毎にサーバーで生成 | 強い | 中程度 | ユーザー別コンテンツ・リアルタイム在庫情報 |
| SSG | ビルド時に一度だけ生成 | 最も強い | 最速 | ブログ記事・ドキュメント・静的LP |
| ISR | ビルド時+一定間隔で再生成 | 強い | 速い | ECサイトの商品ページ・ニュース記事 |
「プリレンダリング」とCSRの違いを視覚的に理解する
Reactの通常の動作(CSR)では、サーバーから届くHTMLは「ほぼ空っぽ」だ。ブラウザが空っぽのHTMLを受け取り、JavaScriptを読み込み、実行して初めてコンテンツが表示される。検索エンジンのクローラーが訪れたとき、空のページしか見えないためSEOに不利になる。
一方のNext.jsは「プリレンダリング」——つまりサーバー側であらかじめ完成したHTMLを作ってから送る。ブラウザは受け取ったHTMLをそのまま表示するだけなので表示が速く、クローラーも内容を正しく読み取れるためSEOにも強い。
4. Next.jsの主な特徴・機能
ファイルベースルーティング
決まったフォルダにファイルを置くだけでURLが自動生成される。app/blog/page.tsx → /blog のURLでアクセス可能になる。URLごとにrouterの設定コードを書く必要がなく、直感的にページを追加できる。
画像最適化(next/image)
next/imageコンポーネントを使うだけで、表示サイズに合わせたリサイズ・WebP変換・遅延読み込み(Lazy Loading)・CLSの防止が自動で適用される。手動でsharpなどを設定する必要がない。
フォント最適化(next/font)
next/fontを使うとGoogleフォントを最適化してゼロCLSで読み込める。外部のGoogleサーバーへのリクエストが発生せず、フォントファイルがビルド時にバンドルされるためプライバシーとパフォーマンスが向上する。
APIルート(Route Handlers)
app/api/フォルダにroute.tsを置くだけで、Next.jsがAPIサーバーとしても機能する。別途Node.jsサーバーやExpress.jsを立てる必要がなく、フロントとバックエンドを同一プロジェクトで管理できる「フルスタック」開発が可能。
メタデータAPI(SEO対応)
page.tsxにmetadataオブジェクトをexportするだけで、titleタグ・descriptionタグ・OGPタグが自動的に設定される。コンポーネント内でheadタグを管理する必要がなく、ページごとのSEO設定が統一された方法で書ける。
Turbopack(高速ビルドツール)
Next.js 13以降はRustで書かれた高速ビルドツール「Turbopack」が同梱されている(2026年現在はstableとして利用可能)。従来のWebpackと比較して開発サーバーの起動・HMR(ホットリロード)が大幅に高速化される。
5. App RouterとPages Router——どちらを使うか
Next.js 13.4(2023年5月)からApp Routerがデフォルトになった。それ以前のPages Routerも引き続き使えるが、新しいプロジェクトではApp Routerを使うのが推奨されている。
| 比較項目 | App Router(推奨・現在のデフォルト) | Pages Router(旧方式・互換性維持) |
|---|---|---|
| ルートファイル | app/ディレクトリ内のpage.tsx | pages/ディレクトリ内のファイル名 |
| Server Components | 標準対応(デフォルトでサーバー側で動く) | 非対応 |
| データ取得 | fetch()をコンポーネント内で直接使える | getStaticProps・getServerSidePropsを使う |
| レイアウト | layout.tsxで階層的なレイアウトを定義 | _app.tsxと_document.tsxで管理 |
| Loading UI | loading.tsxを置くだけでローディング状態が自動適用 | 自前で実装が必要 |
| Error UI | error.tsxを置くだけでエラーUI が自動適用 | ErrorBoundaryを自前で実装 |
| 学習コスト | やや高い(新概念が多い) | やや低い(参考記事が多い) |
| 推奨度 | 新規プロジェクトに推奨 | 既存プロジェクトの移行・維持に使用 |
6. Server ComponentsとClient Components
App Routerで最も重要な新概念が「Server Components」と「Client Components」の区別だ。これを理解しないと”use client”のエラーで詰まりやすい。
| 種類 | 動く場所 | できること | できないこと | 書き方 |
|---|---|---|---|---|
| Server Component(デフォルト) | サーバー側のみで実行 | データベースへの直接アクセス・非公開APIの呼び出し・重い処理をサーバーで完結・バンドルサイズを減らす | useState・useEffect等のReact Hooks・ブラウザのイベント(onClick等)・ブラウザのAPI(localStorage等) | 通常のコンポーネントとして書く。特別な記述不要 |
| Client Component | ブラウザ側でも実行 | useState・useEffect・インタラクション・ブラウザのAPI | サーバー側の非公開リソースへの直接アクセス | ファイルの先頭に"use client"を追加する |
// “use client”の記述なし
async function ProductPage() {
// サーバー側でデータを直接取得できる
const data = await fetch(‘https://api.example.com/products’)
const products = await data.json()
return (
<div>
{products.map(p => <p key={p.id}>{p.name}</p>)}
</div>
)
}
// Client Component——ブラウザ側でも動く
“use client” // この1行でClient Componentになる
import { useState } from ‘react’
function Counter() {
const [count, setCount] = useState(0) // Hooksが使える
return <button onClick={() => setCount(c => c + 1)}>{count}</button>
}
7. Next.jsを使うべき場面・使わない場面
| 状況 | 推奨 | 理由 |
|---|---|---|
| 新規でWebサイト・Webアプリを作る | Next.js | ルーティング・SEO・最適化が最初から揃っている。ゼロから環境を組む手間がない |
| SEOが重要なサービス(ECサイト・ブログ・コーポレートサイト) | Next.js | SSR/SSGによりクローラーが完全なHTMLを読み取れる。CoreWebVitals対応も容易 |
| フロントとAPIを同じプロジェクトで管理したい | Next.js | APIルートでサーバーレス関数を書けば、別途Node.jsサーバーが不要 |
| すでにReactで動いている既存アプリに機能を追加 | React単体のまま | Reactで動いているものを無理にNext.jsに移行するとコストが大きい |
| Railsや Django等に部分的にUIを組み込む | React単体 | Next.jsはスタンドアローンなフレームワークのため既存サーバーと組み合わせにくい |
| モバイルアプリを作りたい | React Native | Next.jsはWeb専用。モバイルアプリにはReact Nativeを使う |
8. メリット・デメリット
- ゼロコンフィグで即座に開発を始められる
- SEOに必要なSSR/SSGが標準搭載
- ファイルを置くだけのルーティングが直感的
- 画像・フォント・スクリプトの最適化が自動
- APIルートでフルスタック開発が可能
- TypeScript・Tailwind CSSとの相性が抜群
- Vercelへのデプロイが非常に簡単
- 世界最大級のフロントエンド企業(Netflix等)の採用実績
- App RouterのServer Components概念の学習コストが高い
- Vercel社製のため、Vercelへの依存リスクがある
- 大規模プロジェクトではビルド時間が長くなりやすい
- 古い記事・チュートリアルが多くバージョン差異でつまずきやすい
- Pages RouterとApp Routerの並存で設計が複雑になる場合がある
- “use client”の付け忘れや不適切な使用でバグが起きやすい
9. インストール・プロジェクト作成
node -vでバージョンを確認し、v18未満の場合はnodejs.orgから最新版をインストールする。-
1create-next-appでプロジェクトを作成する
ターミナルで以下のコマンドを実行。プロジェクト名・TypeScript・ESLint・Tailwind CSS・App Routerなどを対話形式で選択できる。
npx create-next-app@latest
# 対話形式で各種設定を選択する(2026年現在のデフォルト推奨設定)
# What is your project named? → my-app(任意のプロジェクト名)
# Would you like to use TypeScript? → Yes(推奨)
# Would you like to use ESLint? → Yes(推奨)
# Would you like to use Tailwind CSS? → Yes(推奨)
# Would you like to use `src/` directory? → No(シンプルに始める場合)
# Would you like to use App Router? → Yes(推奨)
# Would you like to use Turbopack? → Yes(高速ビルド)
# Would you like to customize the import alias? → No
-
2開発サーバーを起動する
プロジェクトディレクトリに移動してdev サーバーを起動。ブラウザで localhost:3000 にアクセスして確認。
cd my-app
# 開発サーバーを起動
npm run dev
# ブラウザで http://localhost:3000 にアクセス
# ファイルを編集するとHMR(ホットリロード)でリアルタイム反映される
生成されるディレクトリ構造(App Router)
├── app/ # ← App Router の中心。ここにページを置く
│ ├── layout.tsx # ← 全ページ共通のレイアウト(header・footerなど)
│ ├── page.tsx # ← トップページ(/ にアクセスすると表示)
│ └── globals.css # ← グローバルCSS
├── public/ # ← 静的ファイル(画像・フォントなど)
├── next.config.ts # ← Next.jsの設定ファイル
├── package.json
└── tsconfig.json
10. 基本的なページ作成とルーティング
新しいページを追加する(App Router)
export default function AboutPage() {
return (
<main>
<h1>About</h1>
<p>このサイトについての説明です。</p>
</main>
)
}
// SEOのためにメタデータをexportする
export const metadata = {
title: ‘About — サイト名’,
description: ‘このサイトについての説明です’,
}
動的ルーティング([slug]パターン)
// /blog/hello-world や /blog/my-first-post 等でアクセス可能に
type Props = {
params: { slug: string }
}
export default function BlogPost({ params }: Props) {
return <h1>記事:{params.slug}</h1>
}
共通レイアウトの設定
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang=“ja”>
<body>
<header>共通ヘッダー</header>
<main>{children}</main> {/* 各ページのコンテンツ */}
<footer>共通フッター</footer>
</body>
</html>
)
}
APIルートの作成
// /api/hello にHTTPリクエストを送れるAPIエンドポイントになる
export async function GET(request: Request) {
return Response.json({ message: ‘Hello from Next.js API!’ })
}
export async function POST(request: Request) {
const body = await request.json()
// データベース処理等をここに書く
return Response.json({ received: body })
}
11. 環境変数の扱い方
APIキーやデータベースの接続情報など、外部に公開したくない情報は環境変数で管理する。Next.jsではプレフィックスによって「サーバー専用」か「ブラウザでも使える」かが変わる。
# サーバー側のみで使える環境変数(APIキー等の秘密情報)
DATABASE_URL=postgresql://user:pass@localhost/mydb
SECRET_API_KEY=sk-xxxxxxxxxxxxxxxx
# ブラウザでも使える環境変数(NEXT_PUBLIC_ プレフィックスが必要)
NEXT_PUBLIC_ANALYTICS_ID=UA-12345678-1
NEXT_PUBLIC_SITE_URL=https://mysite.com
const dbUrl = process.env.DATABASE_URL
// クライアントコンポーネント内で使う(NEXT_PUBLIC_ が必要)
const siteUrl = process.env.NEXT_PUBLIC_SITE_URL
12. デプロイ先の選択肢
| デプロイ先 | 特徴 | Next.jsとの相性 | 推奨シーン |
|---|---|---|---|
| Vercel(公式) | GitHubにプッシュするだけで自動デプロイ。Next.jsの全機能が最適な環境で動く。無料プランあり | 最高(Next.jsの開発元) | 個人プロジェクト・スタートアップ・プロトタイプ |
| AWS Amplify / EC2 | AWSのエコシステムと連携しやすい。大規模な企業システムとの統合に向く | 良い | 既存のAWS環境を使っている企業 |
| Netlify | Vercelに似た使い心地。一部のNext.js機能(ISR等)は独自アダプターが必要 | 良い(ほぼ全機能対応) | Vercelの代替として |
| 自前サーバー(VPS等) | Node.jsサーバーとして動かす。Vercelに依存しない。設定の柔軟性が高い | 動くが設定が必要 | 完全に自社インフラで管理したい場合 |
| Docker + Kubernetes | コンテナ化してスケールさせる。大規模・エンタープライズ向け | 動く(設定コスト高め) | エンタープライズ・マイクロサービス環境 |
