Next.js 16: 何が変わったのか
Next.js 16は2025年後半のメジャーリリースで、App Routerの安定化とパフォーマンス改善が中心だ。Pages Routerは公式に「レガシー」扱いとなり、新機能の追加は停止された。KGAのクライアントプロジェクト3つでNext.js 14/15からの移行を実施した経験をもとに、実践的な移行ガイドをまとめる。
破壊的変更のインパクト
最も影響が大きかったのはキャッシュのデフォルト動作の変更だ。Next.js 15で導入されたfetch()のデフォルトno-store（キャッシュなし）がそのまま維持されているが、16ではさらにRoute Handlersのレスポンスキャッシュもデフォルトでdynamicになった。これまでexport const dynamic = 'force-static'を設定していなかったRoute Handlerが、すべて動的レンダリングに切り替わる。
KGAのプロジェクトでは、この変更によりビルド時間が40%短縮された一方、初期アクセスのレスポンスタイムが200-400ms増加した。ISR（Incremental Static Regeneration）の明示的な設定で対処する必要があった。
React Server Components: 実践で見えた設計パターン
RSCの最大のメリットはバンドルサイズの削減だ。KGAのダッシュボードプロジェクトでは、Server Componentへの移行でクライアントJavaScriptが62%削減された。しかし「何をServer Componentにすべきか」の判断基準が曖昧で、チーム内で混乱が生じた。
KGAが確立したルールは明確だ。データフェッチングを行うコンポーネントはServer Component。ユーザーインタラクション（onClick、onChange等）を持つコンポーネントはClient Component。状態管理（useState、useReducer）を使うコンポーネントはClient Component。それ以外はデフォルトでServer Component。
実装上の罠として、Server ComponentからClient Componentにシリアライズ不可能なprops（関数、Date、Map等）を渡すとランタイムエラーになる。TypeScriptの型チェックでは検出できないため、テストで補完する必要がある。
ストリーミングSSRの活用
Next.js 16ではloading.tsxとSuspenseによるストリーミングSSRが安定した。重いデータフェッチを伴うページで、シェルを即座に表示しつつデータ部分を段階的にストリーミングする。
KGAのアナリティクスダッシュボードでは、メインのKPIカード（軽量API、50ms）を即座に表示し、詳細チャート（重いクエリ、2-3秒）をSuspenseでラップしてストリーミングした。TTFB（Time To First Byte）が3.2秒から0.3秒に改善し、ユーザーの離脱率が15%低下した。
ただしストリーミングの順序制御は注意が必要だ。複数のSuspense境界がある場合、ネットワーク状況により表示順序が前後することがある。ユーザー体験を考慮し、重要度の高い情報から確定的に表示されるようレイアウトを設計すべきだ。
キャッシュ戦略の最適化
Next.js 16のキャッシュは4層構造だ。Request Memoization（同一レンダリング内のfetch重複排除）、Data Cache（fetch結果のサーバーサイドキャッシュ）、Full Route Cache（レンダリング結果のキャッシュ）、Router Cache（クライアントサイドのプリフェッチキャッシュ）。
KGAの推奨設定は、ユーザー固有データはno-store、共有データはrevalidate: 3600、マスターデータはrevalidate: 86400。revalidateTagを使ったオンデマンド再検証は、CMSのWebhookと連携して更新があったコンテンツだけを無効化する。
最も苦労したのはRouter Cacheだ。Next.js 15でデフォルト動的ページのRouter Cache TTLが0秒に変更されたが、プリフェッチされたページは30秒キャッシュされる。ユーザーがリアルタイムデータを期待するページでstale dataが表示される問題に遭遇し、router.refresh()を明示的に呼ぶ対処を入れた。
Parallel RoutesとIntercepting Routes
Next.js 16ではParallel Routes（@folder規約）の安定性が向上した。KGAのSaaSプロダクトでは、ダッシュボードの左ペインにナビゲーション、右ペインにコンテンツという2カラムレイアウトをParallel Routesで実装した。各ペインが独立してローディング状態を持てるため、一方の操作が他方をブロックしない。
Intercepting Routes（(.)folder規約）はモーダル表示に活用した。商品一覧から商品詳細をモーダルで表示し、直接URLアクセスではフルページ表示する。ソーシャルメディアのような閲覧体験を実現できるが、状態管理が複雑になるため、シンプルなモーダル表示以外での使用は慎重に検討すべきだ。
Server Actionsの運用
Server Actionsはフォーム送信やデータ更新のパターンを大幅に簡略化する。APIルートを別途作成する必要がなく、'use server'ディレクティブを付けた関数を直接呼び出せる。
KGAではServer Actionsの使用ルールとして、フォーム送信はServer Actions、RESTful APIの公開はRoute Handlers、外部クライアント（モバイルアプリ等）向けはRoute Handlersという使い分けを徹底している。
セキュリティ面では、Server Actionsは暗黙的にPOSTエンドポイントを生成するため、CSRF対策が組み込みで提供される。ただし入力バリデーションは開発者の責任だ。zodとの組み合わせでスキーマバリデーションを必ず実装すること。
移行チェックリスト
KGAの移行経験から作成したチェックリストを共有する。1. next.config.jsの設定確認（非推奨オプションの削除）。2. middleware.tsの動作確認（マッチャーの構文変更チェック）。3. fetch()のキャッシュ設定を明示的に指定。4. Client/Server Componentの境界を再設計。5. getServerSideProps/getStaticPropsからRSCパターンへの移行。6. API RoutesからRoute Handlersへの移行。7. ストリーミングSSRの導入検討。8. Lighthouseでの性能計測（移行前後の比較）。KGAの3プロジェクトでは、移行に平均2-3週間を要した。最大のボトルネックはClient/Server Component境界の再設計で、全工数の約40%を占めた。