App Router の「なぜ」を掘り下げる──『実践Next.js』が解説する Server Components・キャッシュ・Server Actions

Next.js の App Router への移行は、ルーティング記法が変わるだけではない。コンポーネントをどこで実行するかという根本的な設計の考え方が変わる。この転換を理解しないまま移行すると、キャッシュの意図しない動作や、Server/Client Component の誤った配置で詰まることになる。

吉井健文著『実践Next.js App Routerで進化するWebアプリ開発』（技術評論社、2024年）は、公式ドキュメントでは補いきれない App Router の設計原理を、実際のアプリケーション開発を通じて解説する。

1. Server Components が変えるハイドレーションの考え方

従来の SSR では、サーバー側で生成した HTML をブラウザに送信した後、JavaScript を読み込んでインタラクティブな動作を付与する「ハイドレーション」が必要だった。この処理はデバイスの CPU を消費し、ページの操作可能になるまでの時間を遅らせる要因だった。

React Server Components（RSC）は、サーバー側のみで実行が完結するコンポーネントを分離することでこの問題に対処する。データの取得や HTML の生成をサーバーで行い、JavaScript バンドルをブラウザに一切送らない。動的な操作が必要な部分だけを 'use client' で Client Component として指定する。

この分離によって、必要な JavaScript の量を絞り込める。本書は、どのコンポーネントを Server Component にするかの判断基準と、Server/Client Component を組み合わせた設計パターンをコードで示す。

2. App Router の多層キャッシュと、意図した無効化

App Router の難所のひとつが、Request のメモ化・データキャッシュ・Full Route キャッシュ・Router キャッシュという 4 つのキャッシュレイヤーの挙動だ。Next.js v14 時点では多くのキャッシュがデフォルトで有効化されており、古いデータが残り続けたり、個人情報が意図せず共有されたりするリスクがあった（v15 でデフォルトの一部が変更された）。

本書はこれらのキャッシュがそれぞれどのタイミングで有効になり、何がトリガーで無効化されるかを整理する。タグを使ったオンデマンドの再検証（revalidateTag）など、きめ細かいキャッシュ制御の実装方法も扱う。

キャッシュを適切にコントロールするには、まずどのレイヤーで何がキャッシュされているかを理解することから始まる。本書はその構造を説明した上で、実装例を示す。

3. Server Actions と Progressive Enhancement の設計

Server Actions は、サーバーサイドの関数をフォームやクライアントコードから直接呼び出せる機能だ。REST API のエンドポイントを別途定義せずにデータの送受信ができる。

本書はこれを「API が不要になる便利な機能」としてではなく、JavaScript の読み込みが遅れている環境でも基本動作を保証する「Progressive Enhancement」の思想から位置づける。フォームが Server Action と連携していれば、JavaScript なしでも送信が機能する。

useOptimistic を使ったネットワーク待ちを感じさせない UI 更新や、バリデーションとエラーメッセージの実装方法も解説されている。Prisma によるデータ操作や NextAuth.js を使った認証の実装も含む、本番を想定した構成でコードが示される。

DevBookPath のマップで確認する

この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。

フロントエンドの地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。