4.

Next.jsとは?App Routerとレンダリングの全体像

編集

この記事の要点

  • Next.js は React でアプリを作るためのフレームワーク。ルーティング・ビルド・サーバー実行・最適化といった「React 単体では自分で用意する部分」をまとめて引き受ける。
  • 現在の主軸は App Router。フォルダ構成がそのまま URL になり、コンポーネントは既定でサーバー側で実行される。
  • 「サーバーコンポーネント」と「クライアントコンポーネント」の境界を意識できるかどうかが、最初の分かれ道になる。
  • バージョン 16 ではバンドラが Turbopack に、キャッシュの考え方が Cache Components に置き換わっており、古い日本語記事の手順がそのままでは通らないことがある。
  • この記事を入口として、環境構築 → ルーティング → データ取得 → 更新 → デプロイの順に読み進められる連載を用意している。

Next.js は、React を使った Web アプリケーションを構築するためのフレームワークです。React 自体は「画面を組み立てるためのライブラリ」であり、URL の設計、サーバーでの HTML 生成、ビルド、画像やフォントの最適化といった部分は含まれていません。Next.js はそこを丸ごと引き受け、React だけでは自分で寄せ集める必要があった要素を一つの枠組みにまとめたものです。

本記事はシリーズの入口として、Next.js が何を解決しているのか、どのバージョンで何が変わったのか、そして学習をどの順で進めるとよいのかを整理します。個々の実装手順は各回にまとめてあります。

1React だけでは足りない部分を埋める

React 単体でアプリを作る場合、次のような判断を自分で行うことになります。

  • ルーティングライブラリを選び、URL とコンポーネントの対応を自分で定義する
  • ビルドツール(バンドラ)を設定し、開発サーバーと本番ビルドを整える
  • 検索エンジンや初回表示を考えるなら、サーバー側で HTML を生成する仕組みを別途用意する
  • 画像の最適化、フォントの読み込み、コード分割などをそれぞれ導入する

Next.js はこれらに既定の答えを持っています。ルーティングはフォルダ構成そのもの、ビルドは同梱のバンドラ、サーバーでの実行は最初から前提、画像とフォントは専用コンポーネントで最適化される、という具合です。「決めなくてよいことが増える」のがフレームワークを使う最大の利点で、その代わりにフレームワークの流儀を覚える必要があるのがコストになります。

React だけの構成 React(画面の組み立て) ルーターを選ぶ バンドラを設定する サーバー描画・最適化を足す Next.js を使う構成 React(画面の組み立て) Next.js が既定で提供 ファイルベースのルーティング バンドル・開発サーバー・本番ビルド サーバー描画 / 画像・フォント最適化
React は「画面を作る道具」、Next.js は「アプリを成り立たせる枠組み」。役割が違うので、どちらかがどちらかの上位互換というわけではない。

2App Router と Pages Router

Next.js には歴史的な経緯から 2 つのルーティング方式があります。学習を始めるときに最も混乱しやすいのがここで、検索で出てくる記事がどちらの方式で書かれているかによって、フォルダ名も API もまったく変わります。

観点App Router(現在の主軸)Pages Router(従来方式)
置き場所app/ ディレクトリpages/ ディレクトリ
ページの定義フォルダ内の page.tsxファイル名がそのまま URL
既定の実行場所サーバー(サーバーコンポーネント)クライアント(React コンポーネント)
データ取得コンポーネント内で直接 awaitgetServerSideProps などの専用関数
共通レイアウトlayout.tsx が階層ごとに入れ子になる_app.tsx で全体を包む

Pages Router は現在も動作しますが、新規に学ぶなら App Router を選ぶのが素直です。ネット上の記事に getServerSidePropspages/index.js が出てきたら、それは Pages Router 時代の情報だと判断できます。本シリーズはすべて App Router を前提としています。

3サーバーで動くか、ブラウザで動くか

App Router で最初に越えるべきハードルが、コンポーネントが既定ではサーバー側で実行されるという点です。ファイルの先頭に 'use client' と書いたものだけがブラウザにも配られ、そこではじめて useState やクリックイベント、window などのブラウザ API が使えます。

この境界は制約ではなく設計の道具です。データベースへの問い合わせや API キーを使う処理はサーバー側に置いたままにでき、ブラウザに送る JavaScript を減らせます。逆に、境界を意識せずに書くと「useState が使えない」「window is not defined が出る」といったエラーに繰り返しぶつかることになります。詳しくは サーバーコンポーネントとクライアントコンポーネント で扱います。

4バージョン 16 で変わったこと

Next.js は変化の速いフレームワークで、日本語の解説記事はバージョン 13〜14 のものが多く残っています。2026 年 8 月時点の安定版は 16.3 で、次のような違いがあります。

  • Turbopack が既定のバンドラになり、--turbopack を付ける必要がなくなった
  • キャッシュの考え方が Cache Componentsuse cache ディレクティブ)に整理され、fetch は既定でキャッシュされない
  • paramssearchParamscookies() などが 非同期でのみアクセスできるようになった
  • middleware という名前が proxy に変わった
  • Node.js は 20.9 以上が必須になった

古い記事どおりに書いたコードが動かない場合、原因の多くはこの世代差です。移行時の詰まりどころは バージョン16 への移行と注意点 にまとめています。

5向いている用途・慎重に考えたい用途

向いている
コンテンツを検索エンジンに拾わせたいサイト、管理画面と公開ページが同居するアプリ、フォーム送信やデータ更新を伴う業務系、画像が多くパフォーマンスが問われるサイト。
慎重に考えたい
完全にログイン後だけで完結し SEO が不要な画面、静的な HTML だけで足りるページ、Node.js を動かせないホスティング環境。後者は静的書き出しでも配信できるが、機能に制限がかかる。

6このシリーズの読み進め方

各記事は単体でも読めますが、前後の ◀ ▶ ボタンで順番に進める構成になっています。まったくの初学者であれば、次の順で読むと詰まりにくくなります。

段階読む記事身につくこと
導入開発環境の構築とプロジェクトの初期構成動く状態を作り、生成されたファイルの意味を理解する
骨格App Router のルーティングとファイル規約
レイアウトと特殊ファイルの使い分け
URL 設計と画面の入れ子構造
中核サーバーコンポーネントとクライアントコンポーネント
サーバー側でのデータ取得と並列化
どこで何を実行するかの判断
体感速度ストリーミングで体感速度を上げる
キャッシュの仕組みと use cache
再検証の使い分け
速く見せる仕組みと、鮮度の設計
書き込みフォーム送信とデータ更新の実装
エラーハンドリングとエラー境界
Route Handlers で API を作る
更新処理と失敗時の振る舞い
仕上げメタデータ API で SEO を整える
画像とフォントの最適化
本番ビルドとセルフホスト
公開品質に持っていく

すでに ReactVue.js の経験があるなら、1 と 2 を流し読みして 4 の「サーバーとクライアントの境界」から入っても構いません。逆に JavaScript 自体がまだ不慣れな場合は、先に React 側の基礎を押さえたほうが遠回りになりません。

編集
Post Share
子ページ
  1. 開発環境の構築とプロジェクトの初期構成
  2. App Router のルーティングとファイル規約
  3. レイアウトと特殊ファイルの使い分け
  4. サーバーコンポーネントとクライアントコンポーネント
  5. サーバー側でのデータ取得と並列化
  6. ストリーミングで体感速度を上げる
  7. キャッシュの仕組みと use cache
  8. 再検証の使い分け
  9. フォーム送信とデータ更新の実装
  10. エラーハンドリングとエラー境界
  11. Route Handlers で API を作る
  12. メタデータ API で SEO を整える
  13. 画像とフォントの最適化
  14. 本番ビルドとセルフホスト
  15. バージョン16 への移行と注意点
同階層のページ
  1. Vue.js
  2. React
  3. Express
  4. Next.js