まず、全体像
なぜNext.jsを使うのかを、自分の言葉で。
SEE THE BIG PICTURE
いきなり全部を覚えなくて大丈夫。まずは「何が、どこにつながるか」を見てみよう。
REACT + NEXT.JS
ReactはUIを組み立てるライブラリ。Next.jsはReactを使い、ルーティングやサーバー処理まで含むアプリの構成を用意するフレームワークです。
JavaScript → React → Next.js の順で、少しずつ積み重ねていくと理解しやすくなります。
YOUR LEARNING PATH
所要時間は本文の理解と小さな演習の目安です。環境構築、復習、最終制作にかかる時間は別です。
なぜNext.jsを使うのかを、自分の言葉で。
WebとReactの基本を、必要な分だけ。
URL、レイアウト、画面の移動をつなぐ。
どこで、いつ動くかを整理する。
入力、更新、API、失敗への備え。
見た目、権限、テスト、公開を仕上げる。
一つ作り切り、必要な発展領域へ。
基本演習はApp Router・JavaScript/JSX・Cache Components無効で進めます。11の有効化例は独立した発展実験です。01〜04は先に読んで、コードの実行は05の環境構築後に戻って試せます。
短い学習用の例です。各例は段階ごとの独立した例であり、全コードを一つのプロジェクトへ順に上書きして完成する形式ではありません。必要なファイル・依存関係・前提条件は注記に記載しています。
開発環境の準備を確認する →CHOOSE WITH UNDERSTANDING
| 観点 | React | Next.js |
|---|---|---|
| 主な役割 | UIの部品と状態の表現 | Reactを使うアプリの構成と実行 |
| ルーティング | 別の仕組みを選んで組み合わせる | ファイル規約によるRouterを用意 |
| データと表示 | 構成やフレームワークにより組み合わせる | Server Componentsや取得・更新のパターンを統合 |
| 画像・メタデータ | 必要な手段を選んで導入する | 専用の部品やAPIがある |
| 自由度と学習 | 構成を選ぶ自由が大きく、選定も必要 | 共通の仕組みが揃う分、規約と境界を学ぶ |
比較するのは「Reactだけの構成」と「Reactを含むNext.jsの構成」です。周辺の道具や配信環境による違いも分けて考えましょう。
ルート、レイアウト、取得、更新を同じプロジェクトで扱いやすい。
事前生成、リクエスト時の処理、ブラウザーの操作を組み合わせられる。
ナビゲーション、画像、フォント、metadataの仕組みが用意される。
KNOW THE TRADE-OFFS
Next.jsで作れることと、導入する価値が大きいことは別です。以下は公式の機能・制約をもとにした選定の目安です。
たとえば:既存の会社サイトに料金計算ウィジェットを置く。
選び方:Reactの部分導入をまず比較する。
サイト全体のURLやビルド構成まで変更する必要があるか、導入範囲を確認する。Next.jsを導入しても、使う機能が少なければ規約の学習負担の方が大きい場合がある。
公式資料をもとにした選定の目安関連レッスンを読む →たとえば:ログイン後だけ使う図形エディターや、既存APIにつなぐ社内ツール。
選び方:React中心のSPA構成と、Next.jsで得られるルーティング・分割読み込み等の価値を比較する。
Next.jsでもSPAを作れる。サーバー描画やServer Actionsが不要なら、それらの恩恵は小さくなるため、構成の単純さやチームの経験で判断する。
公式資料をもとにした選定の目安関連レッスンを読む →たとえば:サーバーを動かさず、生成したHTML・CSS・JSを配信する。
選び方:static exportで必要な機能が成立するか確認する。
リクエスト時のCookie処理やServer Actionsなど、サーバー実行に依存する機能はそのまま使えない。必要ならサーバー対応の公開方式か外部APIを選ぶ。
公式の機能・制約と、それに基づく選定の目安関連レッスンを読む →たとえば:共同編集、動画変換、大量の定期集計。
選び方:接続や処理の寿命に合う基盤を選び、必要なら専門サービスやワーカーに分ける。
Next.jsだけでDB・キュー・常時接続の基盤が揃うわけではない。サーバーレスの公開先では処理時間やWebSocketに制約がある場合があり、配置先ごとの確認が必要。
公式の機能・制約と、それに基づく選定の目安関連レッスンを読む →たとえば:在庫、本人だけのプロフィール、更新直後の表示。
選び方:キャッシュの範囲・期間・更新条件を明示し、権限をデータに近い場所で検証する。
機能が豊富な分、共有キャッシュと個人データを混ぜるなどの設計ミスを避ける理解が必要。SSRだけで安全性や検索順位が保証されることはない。
公式の機能・制約と、それに基づく選定の目安関連レッスンを読む →理解する軸が増える:ServerとClient、実行時点、キャッシュの鮮度を別々に考える。
バージョンを見分ける:Routerや設定で動作が違う。古い記事のコードをそのまま混ぜない。
運用も設計する:DB、認証、監視、費用、公開先の機能はアプリごとに選ぶ。
YOUR FIRST SMALL PROJECT
知識をつなぐための小さな制作課題です。最初は固定データで完成させ、永続保存や認証は次の段階に分けましょう。
制作の目安:3〜6時間(目安)
WHEN YOU ARE READY
こんなとき:動的ルートの一部をビルド時に用意したいとき
URLの候補、初回アクセス、キャッシュ設定の組み合わせを考える。
関連レッスン →こんなとき:ダッシュボードの複数領域や、URL付きモーダルが必要になったとき
通常のルートとレイアウトを理解した上で、直接アクセスとアプリ内移動の違いを確認する。
関連レッスン →こんなとき:リクエストの入口でパスやヘッダーに応じて処理を分けたいとき
Next.js 16の名称変更も確認する。Proxyでの早期判定だけを最終認可にしない。
関連レッスン →こんなとき:部品の入力やデータの形を、変更時にも確かめたいとき
props、API応答、nullの可能性から型を追加する。実行時の入力検証の代わりにはしない。
関連レッスン →こんなとき:日本語以外の言語や地域にも届けたいとき
ロケール、URL、翻訳辞書、日付や数値の表現を一緒に設計する。
関連レッスン →こんなとき:実際の利用環境で画面が重いと分かったとき
大きいClient側の依存、画像、待ち時間を測る。必要な箇所の遅延読み込みを検討する。
関連レッスン →こんなとき:永続保存や複数利用者、長時間処理が必要になったとき
データの所有者、接続、権限、マイグレーション、実行環境の制約をまとめて考える。
関連レッスン →こんなとき:自分以外の人が継続的に使い始めるとき
ログ、エラー監視、CI、更新手順、ロールバックを用意し、移行ガイドとテストをセットにする。
関連レッスン →