Next.js 16.3 の新機能 — Instant Navigations と TypeScript 7 対応、Lint の現在地

2026年8月3日、Next.js 16.3 が正式リリースされました。昨年11月の 16.0 以来もっとも大きな更新で、既存アプリがコード変更なしに得られる性能改善と、SPA 級の体感をサーバー主導のまま実現するInstant Navigations、そして先月リリースされた TypeScript 7 による型チェックの高速化が目玉です。本記事では、.NET バックエンドと Next.js フロントを組み合わせるチームの視点も交えつつ、16.3 の新機能を要点から整理します。あわせて、ユーザーからの質問が多い TypeScript 7 のサポート範囲と、まだ Lint が追いついていない点も具体的に解説します。

すぐ効く性能改善（メモリ・ビルド・SSR）

16.3 は、アプリのコードを1行も変えずに恩恵を受けられる改善を多数含みます。まず next dev のメモリ使用量が、Turbopack のディスクキャッシュとメモリ退避（eviction）が既定で有効になったことで最大 90% 削減されました。Vercel のダッシュボードでは、50 ルートをコンパイルした後のメモリが 21.5GB から 2GB へと約 9 割減ったと報告されています。長時間の開発セッションでも RAM を食い潰しにくくなった格好です。

ビルドも速くなりました。dev を高速化してきたファイルシステムキャッシュが next build でも既定で働くようになり、変更のない成果物をキャッシュから読み出します。Vercel の一部プロジェクトでは CI 上でビルドが最大 5.5 倍高速（30 秒→5.5 秒）になったとのことです。さらにサーバーサイドレンダリングでは、App Router のレンダリング層を Web Streams からネイティブの Node.js ストリームへ置き換え、変換オーバーヘッドを削減。負荷時に最大 22% 多くのリクエストをさばけるようになりました。

TypeScript 7 対応と、まだ追いつかない Lint

先月公開された TypeScript 7 は、型チェックが大幅に速いネイティブ移植版です。Next.js 16.3 では、next build の型チェックで TypeScript 7 を使えるようになりました。導入はプロジェクトのローカル依存を上げるだけです。

pnpm add -D typescript@^7

仕組みとして、next build は既定でプロジェクトローカルの tsc コマンド（CLI）を直接呼び出して型チェックします。これは experimental.useTypeScriptCli という実験的オプションで、既定値が true になっているためです。JavaScript 版のコンパイラ API を使う従来方式に戻したい場合は false に設定しますが、TypeScript 7 を入れた状態で false にすると next build は失敗します。

その理由が、今回もっとも注意すべきLint がまだ追いついていない点に直結します。公式ドキュメントは 「TypeScript 7 は現時点で JavaScript コンパイラ API を提供していない」と明記しています。Next.js が tsc CLI を呼ぶ方式へ切り替えたのも、この API が未提供だからです。裏を返すと、TypeScript の API に依存するツールは TypeScript 7 ではまだ動きません。代表例が typescript-eslint による型情報を使った Lint（type-aware rules）で、型プログラムを内部で構築するため TS7 のネイティブコンパイラでは動作しません。Next.js が同梱するカスタム TS プラグイン／型チェッカーも同じく JS API を使うため、TS7 環境では併用できません。

実務的な指針はこうなります。ビルド時の型チェックだけを速くしたいなら TypeScript 7＋tsc CLI で問題ない。一方で、型情報を使う ESLint ルールや Next.js のカスタム型チェッカーを使い続けたいなら、当面は TypeScript 6 系を併用するのが安全です。useTypeScriptCli 自体が実験的機能で挙動が変わりうる点も含め、本番導入は段階的に進めるのが無難でしょう。

Instant Navigations — SPA 級の体感をサーバー主導のまま

16.3 の主役が、オプトインで有効化する Instant Navigations です。Server Components は「少ない JavaScript で完全なページを描く」強みがある一方、リンク遷移が SPA より遅く感じられがちでした。16.3 は昨年導入した 'use cache' ディレクティブを土台に、この遷移・キャッシュ・プリフェッチの課題をまとめて改善します。次の2つのフラグで試せます。

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

遅い遷移を見逃さないよう、Next.js DevTools に Instant Insights が加わりました。ナビゲーション中にキャッシュされていないデータ取得が走ると検出し、その場で Stream（Suspense で包む）／Cache（'use cache'）／Block（ブロッキングを許可）という修正案を提示します。各インサイトには、AI エージェントに修正を適用させるためのプロンプトも付きます。

プリフェッチも柔軟になりました。Partial Prefetching は、任意のルートから再利用可能な「読み込みシェル」を抽出し、<Link prefetch={true}> ごとにどれだけの内容を先読みするかを細かく制御できます。ISR も進化し、ビルド時に一部だけをプリレンダリングした場合でも、未生成ページは初回訪問者にまず即時の読み込みシェルを返し、背景で本体を生成して以降の訪問者へキャッシュ配信します。「シェルを見せる」か「初回訪問者をブロックする」かの二択を、両取りできるようになった形です。

開発中はプリフェッチが無効なため、遷移時にユーザーが実際に見る読み込み状態を把握しづらい問題がありました。新しい Navigation Inspector は、ページ読み込みやクライアント遷移をシェルの段階で一時停止し、その瞬間の見え方を目視できます。

さらに、いま即時に表示されるページが将来遅くなる回帰を防ぐため、Playwright 用の instant() ヘルパーが追加されました。遷移中に「即時に見えるべき内容」をアサートでき、リファクタで即時 UI が壊れるとテストが失敗します。

import { expect, test } from '@playwright/test';
import { instant } from '@next/playwright';

test('product title is available immediately', async ({ page }) => {
  await page.goto('/products/shoes');
  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator('h1')).toContainText('Baseball Cap');
  });
});

開発体験を底上げする新機能

Instant Navigations 以外にも、日々の開発に効く改善が並びます。まずカスタムエラーバウンダリです。従来の React エラーバウンダリは notFound や redirect と干渉し、失敗した Server Component の再取得もできませんでした。16.3 の catchError は、これらと干渉しないエラーバウンダリを定義でき、retry() で子（Server Components を含む）を再取得できます。

'use client';
import { catchError, type ErrorInfo } from 'next/error';

function ErrorFallback(props: { title: string }, { error, retry }: ErrorInfo) {
  return (
    <div>
      <h2>{props.title}</h2>
      <p>{error.message}</p>
      <button onClick={() => retry()}>Try again</button>
    </div>
  );
}

export default catchError(ErrorFallback);

Turbopack には 組み込みの glob インポートが入りました。Vite 互換の import.meta.glob API で複数ファイルをまとめて読み込め、ローカルファイルを読む Server Components に HMR などの利点をもたらします。ほかにも、AI エージェント向けのバージョン別ドキュメント（next dev がプロジェクトの Next.js バージョンに一致した AGENTS.md を維持し、ローカルの node_modules 内ドキュメントを指す）、小さなプリフェッチの束ね込みによるリクエスト削減、デプロイをまたいで再利用できるイミュータブルな静的アセットなど、地味ながら効く改善が揃っています。

試せる実験的機能（Rust 版 React Compiler とオフライン耐性）

16.3 には、設定フラグで今日から試せる実験的機能も同梱されます。ひとつは Rust 版 React Compiler です。これまで React Compiler は Babel（Node.js）経由でしたが、実験的な Rust 移植版は Turbopack 内で直接動き、コード生成と再パースの手間を省きます。大型アプリ v0 でのテストでは、next dev から表示可能になるまでの時間がコールドで 34%、ウォームで 46% 短縮したとのことです（Babel から完全に離れた場合の値）。

const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

もうひとつがネットワーク耐性です。experimental.useOffline を有効にすると、通信が切れてもソフト遷移やデータ取得、Server Action を失敗させずに保留し、再接続時に自動でリトライします。useOffline フックでオフライン状態を検知し、ユーザーへ状況を提示することも可能です。Partial Prefetching がシェルをクライアントに保持しているため、プリフェッチ済みルートはオフラインでもシェルを描画し、再接続後にデータがストリーミングされます。

開発者の声（X より）

コミュニティの反応も熱を帯びています。まずは Next.js を生んだ Vercel CEO の Guillermo Rauch 氏。「速く、良く、強くなった」とし、メモリ改善に貢献した Fable への謝辞や、インクリメンタルな next build キャッシュ、そして「みんなが SPA を望んだ。ならば SPA を」という Instant Navigations への手応えを挙げています。

Next.js 16.3: faster, better, stronger. My highlights:

0️⃣ Faster dev & builds
Shoutout to Fable for improving memory use, and the team for landing the incremental 𝚗𝚎𝚡𝚝 𝚋𝚞𝚒𝚕𝚍 cache.

1️⃣ Instant navigations are 🔥
The people wanted SPAs, they shall get SPAs. By turning on… https://t.co/Qoo1A0mr79

— Guillermo Rauch (@rauchg) 2026年8月3日

もう一件は、日本の開発者・酒井氏の視点です。リリース記事では大きく扱われていないものの見逃せない機能として、動的セグメントのパラメータを扱う next/root-params に注目しており、公式の目玉以外にも実務で効く追加があることを教えてくれます。

Next.js 16.3がリリース。
追加された機能で、リリース記事になくあまり知られてないが、特に注目してるのが「next/root-params」… https://t.co/GOlqierxN9 pic.twitter.com/EDjIvJQlX6

— 酒井 / Hello (@hello__sakai) 2026年8月4日

よくある質問

16.3 へのアップグレードは何をすればよいですか？

npm install next@latest で最新版に上げるだけで、メモリ削減やビルド高速化、SSR 改善はコード変更なしに得られます。Instant Navigations や TypeScript 7、実験的機能は、それぞれのフラグや依存追加でオプトインする形です。

TypeScript 7 は本番ビルドで使って大丈夫ですか？

ビルド時の型チェック高速化が目的なら有力な選択肢ですが、useTypeScriptCli は実験的で挙動が変わりうる段階です。加えて TypeScript 7 は JavaScript コンパイラ API を未提供のため、typescript-eslint の型情報を使う Lint や Next.js のカスタム型チェッカーは併用できません。これらが必要なら当面は TypeScript 6 系を残すのが安全です。

.NET バックエンドと Next.js フロントの組み合わせでも恩恵はありますか？

あります。ビルド・SSR の高速化やプリフェッチ最適化はホスティング構成に依存しません。ASP.NET Core を API 層に据える BFF 構成でも、フロントの体感速度と開発効率がそのまま向上します。

参照元

• Next.js 16.3（Next.js Blog 公式リリース記事）
• TypeScript 設定 / Using TypeScript 7（Next.js Docs）
• useTypeScriptCli（Next.js Docs）
• Announcing TypeScript 7.0（Microsoft DevBlogs）
• @rauchg のポスト（X） / @hello__sakai のポスト（X）

Next.js の実務設計は Next.js App Router 実務ベストプラクティス、.NET と組み合わせる構成は ASP.NET Core × Next.js の BFF パターン と .NET / Next.js アプリを Azure へデプロイする実践ガイド にまとめています。