Next.jsとNuxtの違いは、土台がReactかVueかの一点から始まります。SSR・静的生成・増分再生成・APIルートはどちらにもそろっており、機能表を並べても差はほとんど出ません。差が出るのは、ブラウザに送るJavaScriptの量、レンダリング方針を書く場所、そしてサポート期限とセキュリティ更新への追従です。
この記事では、同じページをNext.js 16.4.3とNuxt 4.6.3で作って測った初回JS量とビルド時間を示し、コードの書き方の差、2026年10月時点のサポート状況、チーム条件ごとの選び方の順に整理します。
まとめ
迷ったら、チームが書ける方を選んでください。Reactを書けるならNext.js、Vueを書けるならNuxtです。書けない側を選ぶと、学習期間の遅れがフレームワークの機能差より大きく効きます。どちらも書ける、あるいはどちらも書けないなら、ライブラリと人材の母数が大きいNext.jsが無難です。npmの週間ダウンロード数は2026年10月19日〜25日の週で next が約4,721万、nuxt が約163万と、約29倍の差があります。
Nuxtを選ぶ根拠になるのは、初回に送るJSの少なさと、Vercel以外へ出すときの移植性です。同じ「見出しとカウンターボタン」だけのページで、初回に読み込むJSはNext.jsがgzip後で約174KB、Nuxtが約67KBでした。版はNext.jsが16系(Active LTS)、Nuxtが4系に限られます。Nuxt 3は2026年7月31日にEOLを迎え、10月に公開された脆弱性のうち4件は3系に修正版が出ていません。
Next.js・Nuxt・React・Vueの関係
ReactとVueは画面を描画するUIライブラリで、Next.jsとNuxtはその上にルーティング・サーバーレンダリング・ビルド・デプロイを載せたフレームワークです。縦に見ると「ReactとNext.jsの違い」、横に見ると「Next.jsとNuxtの違い」になります。
| レイヤー | React系 | Vue系 |
|---|---|---|
| UIライブラリ | React 19.3 | Vue 3.5 |
| フレームワーク | Next.js 16.4 | Nuxt 4.6 |
| サーバー部分 | Next.js組み込み | Nitro |
| 状態管理の定番 | Zustand・Redux等から選ぶ | Pinia |
ReactとNext.js、VueとNuxtの役割分担
素のReactでは、ルーティングにReact Router、ビルドにVite、サーバーレンダリングに自前のNode.jsサーバーを、それぞれ選んで組み合わせます。Next.jsはこれを最初から決めており、app/ にファイルを置けばルートになり、コンポーネントは既定でサーバー側で動きます。Next.jsはReactの置き換えではなく、Reactを本番で動かすための決まった型です。始め方はNext.jsとは?16系App Routerで最小アプリを動かす手順と採用判断で扱っています。
VueとNuxtも同じ関係です。Nuxtは app/pages/ の配置をルートに変え、components/ と composables/ のimport文を自動で補い、サーバー側をNitroが受け持ちます。コンポーネント本体は素のVueで書くので、Vueを先に覚える順序になります。Nuxt単体の仕組みはNuxtとは:Vue.jsとの違い・レンダリング方式・4系への移行手順と採用判断を実装視点で解説にまとめています。
「Next.js vs Vue」の比較を置き換える軸
「Next.js vs Vue」「Nuxt vs React」は、フレームワークとUIライブラリという層の違うものを並べた比較です。知りたいことがReact系とVue系のどちらで始めるかなら、比べる相手はNext.jsとNuxt、またはReactとVueです。書き味の差はReactとVue 3の違いを比較|どっちを選ぶべきか【React 19.3・Vue 3.5対応】で比べています。比較の中身が「Next.jsで作るか、VueだけのSPAで作るか」なら、それはフレームワークを使うかどうかの判断です。検索エンジンに載せないログイン後の管理画面なら、VueだけのSPAで足ります。
同じページを両方で作った実測:初回JS量・依存・ビルド時間
見出し1つとクリックで数が増えるボタン1つだけのページを、Next.js 16.4.3(React 19.3.1・Turbopack)とNuxt 4.6.3(Vue 3.5.44)で作り、本番ビルドしてローカルで配信しました。カウンターはNext.jsでは useState を使うClient Component、Nuxtでは ref を使うページで書きました。集計対象は、トップページのHTMLにある script の src と modulepreload が指すJSで(このページに動的importはありません)、各ファイルをgzip -9で圧縮したサイズを合計しています。環境はIntel Core i9-9880HのmacOS、Node.js 26.5.0、npm 11.17.0です(2026年10月27日)。
| 項目 | Next.js 16.4.3 | Nuxt 4.6.3 |
|---|---|---|
| 初回に読むJSファイル数 | 7 | 2 |
| JS合計(gzip -9) | 174,256バイト | 67,173バイト |
| JS合計(非圧縮) | 568,881バイト | 183,753バイト |
| HTML(非圧縮) | 4,854バイト | 1,302バイト |
| node_modules | 約357MB・23パッケージ | 約192MB・389パッケージ |
| ビルド(1回目) | 29.69秒 | 23.35秒 |
| ビルド(2回目) | 14.10秒 | 19.84秒 |
初回JSの差は約2.6倍です。Next.jsのJSにはReact本体に加え、App Routerのクライアント側ルーターとサーバーコンポーネントの結果を受け取る処理が含まれます。この部分はページを増やしても再利用されるので、2ページ目以降は増分だけが加わります。ここで測ったのは転送するファイルの量で、表示までの時間ではありません。どちらもHTMLをサーバー側で作るため、JSを読み終える前に内容は表示されます。差が効くのは、ボタンなどが操作できるようになるまでの時間と、モバイル回線での通信量です。表示速度で比べたい場合は、同じ条件でLCPやINPを測ってください。
条件の違いもあります。Next.jsのページはビルド時に静的HTMLとして出力され、Nuxtのページはリクエストごとにサーバーで描画されました。Next.jsの1回目のビルドには型検査(6.3秒)と tsconfig.json の自動生成が入り、Nuxtは nuxt build で型検査をしません。node_modulesはNext.jsのほうが大きい一方でパッケージ数は23しかありません。next 本体が依存を同梱しており(約206MB)、@next 配下のSWCネイティブバイナリ等が約86MB、devDependenciesに入れたTypeScriptが約24MBを占めます。ビルド時間は数秒の差で、選定を左右する大きさではありません。
レンダリングとキャッシュの設計差
SSRとSSGの考え方は共通です。差が出るのは、ページの一部だけを動的にする方法と、その方針をどこに書くかです。Next.jsはコンポーネントや関数の単位で書き、Nuxtはルートの単位で書きます。
Next.js 16:use cacheとcacheComponents
Next.js 16では cacheComponents が安定版の設定になりました。有効にすると、公式リファレンスのとおり 'use cache' を付けたルート・コンポーネント・関数がキャッシュの対象になり、残りの動的な部分はSuspense境界の内側でリクエスト時に描画されます。
// next.config.ts
import type { NextConfig } from 'next'
const nextConfig: NextConfig = {
cacheComponents: true,
}
export default nextConfig
既存のページで有効にすると、キャッシュされずSuspense境界にも入っていないデータ取得がある箇所でビルドが止まります。1ページの中で「ここは静的、ここはユーザーごと」と細かく分けたいなら、この粒度はNext.jsのほうが細かく書けます。revalidateTag と updateTag の使い分けはNext.jsのキャッシュ|16.4のuse cache・revalidateTagの使い分けとCDNで効かない原因で解説しています。
Nuxt:routeRulesとNitroのデプロイ先
Nuxtは nuxt.config.ts の routeRules に、パスごとの描画方針をまとめて書きます。サイト全体の方針が1か所で読めるのが利点です。
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/': { prerender: true },
'/blog/**': { isr: 3600 },
'/admin/**': { ssr: false },
},
})
注意点は isr の効き方がデプロイ先で変わることです。Nuxt公式のレンダリング解説は、isr の挙動は swr と同じで、CDNキャッシュに載せられるのは現状NetlifyかVercelだと書いています。Node.jsサーバーやCloudflareへ出す場合は、Next.jsのISRと同じ結果を期待せず、Nitroのキャッシュ設定を確認してください。Nitroのプリセットの仕組みはNitroとは?Nuxtを支えるサーバーエンジンの仕組みとv3移行の判断軸を解説で扱っています。Reactのサーバーコンポーネントに近い .server.vue は experimental.componentIslands を有効にして使う実験的機能で、既定では無効です。
ルーティング・データ取得・APIのコード比較
どちらもファイルの置き場所がURLになるファイルベースルーティングです。以下のコードは、上の実測と同じ環境で両方ビルドし、存在する記事(hello)で200、存在しない記事と toString・constructor で404が返ることを確認しています。
Next.jsとNuxtの動的ルートとデータ取得
Next.jsは app/blog/[slug]/page.tsx、Nuxt 4は app/pages/blog/[slug].vue が /blog/:slug になります。params はNext.js 15でPromiseに変わり、互換のために残っていた同期アクセスが16で廃止されたため、必ず await してから使います。PageProps はビルド時に生成されるグローバル型で、importは不要です。ページとAPIの両方から読む記事データは、プロジェクト直下の lib/posts.ts に置きます。Map を使うのは、通常のオブジェクトだと toString や constructor という記事名で継承プロパティを拾い、404にならないためです。
// lib/posts.ts
const posts = new Map([['hello', { title: 'Hello Next.js' }]])
export async function getPost(slug: string) {
return posts.get(slug) ?? null
}
// app/blog/[slug]/page.tsx(Next.js 16)
import { notFound } from 'next/navigation'
import { getPost } from '../../../lib/posts'
export default async function Page(props: PageProps<'/blog/[slug]'>) {
const { slug } = await props.params
const post = await getPost(slug)
if (!post) notFound()
return <article>{post.title}</article>
}
Nuxtは useRoute() でパラメータを取り、useFetch でデータを取ります。useFetch はSSR時にサーバーで実行され、結果がHTMLに埋め込まれてブラウザへ引き継がれます。取得先が自分の server/api/ なら、戻り値の型が data に自動で付きます。エラー時はAPIが返したステータスをそのまま引き継ぎ、404と500を取り違えないようにしています。
<!-- app/pages/blog/[slug].vue(Nuxt 4) -->
<script setup lang="ts">
const route = useRoute()
const { data: post, error } = await useFetch(`/api/posts/${route.params.slug}`)
if (error.value) {
throw createError({
statusCode: error.value.statusCode ?? 500,
statusMessage: error.value.statusMessage,
fatal: true,
})
}
</script>
<template>
<article>{{ post?.title }}</article>
</template>
考え方の差は、Next.jsがサーバーで動くのを既定にして、ブラウザで状態を持つ部品にだけ 'use client' を付けるのに対し、Nuxtのコンポーネントは常にVueのコンポーネントで、データ取得の関数がサーバーとブラウザの橋渡しをする点です。Next.jsでは、'use client' を付けた部品にデータベース接続などのサーバー専用コードを直接組み込むことはできません。そうした処理はServer FunctionsかRoute Handlersに置き、Client Componentからはそれを呼び出す形にします。
APIルート:Route Handlersとserver/api
フォームの送信先や外部向けAPIを同じリポジトリに置く書き方も違います。Next.jsは route.ts に HTTPメソッド名の関数を書き、Route Handlersとして扱います。
// app/api/posts/[slug]/route.ts(Next.js 16)
import { getPost } from '../../../../lib/posts'
export async function GET(_req: Request, ctx: RouteContext<'/api/posts/[slug]'>) {
const { slug } = await ctx.params
const post = await getPost(slug)
if (!post) return Response.json({ error: 'not found' }, { status: 404 })
return Response.json(post)
}
Nuxtは server/api/ にファイルを置き、ファイル名の .get でメソッドを絞ります。中身はNitroのイベントハンドラーで、defineEventHandler などはimportなしで使えます。
// server/api/posts/[slug].get.ts(Nuxt 4)
const posts = new Map([['hello', { title: 'Hello Nuxt' }]])
export default defineEventHandler((event) => {
const slug = getRouterParam(event, 'slug') ?? ''
const post = posts.get(slug)
if (!post) throw createError({ statusCode: 404, statusMessage: 'not found' })
return post
})
Next.jsのRoute HandlersはWeb標準の Request と Response をそのまま使うので、他の実行環境へ持ち出しやすい書き方です。Nuxtの server/ はプロジェクトのルートに置く規約で、Nuxt 4で app/ 配下へ移ったページ類とは場所が分かれます。Nuxt 3の資料を見ながら作業すると、このディレクトリの違いで迷います。
サポート期限とセキュリティ更新(2026年10月時点)
移行の時期と、パッチを当てる頻度はここで決まります。どちらも脆弱性の公開と修正が頻繁にあり、サポート中の系統に乗っていないと修正版を受け取れません。
| 項目 | Next.js | Nuxt |
|---|---|---|
| 最新版 | 16.4.3(10月23日) | 4.6.3(10月27日) |
| 公式一覧の掲載 | 16.x(Active LTS)・15.x(Maintenance LTS) | 4.x(stable) |
| 前の系統の期限 | 15.xは規則上2026年10月21日 | 3.xは2026年7月31日にEOL |
| 採用する版 | 16.x | 4.x |
| 7月1日以降の公開アドバイザリ | 22件(critical 5件) | 18件(critical 1件) |
Next.js:16系のActive LTSと15系の期限
Next.jsのサポートポリシーでは、最新のメジャーが次のメジャーが出るまでActive LTSになり、ひとつ前のメジャーはMaintenance LTSとして重大なバグ修正とセキュリティ修正だけを受けます。Maintenance LTSの期間は初回リリースから2年です。15.xは2024年10月21日公開なので、規則どおりなら2026年10月21日が期限に当たります。ただし10月27日時点のサポート一覧はまだ15.xをMaintenance LTSとして載せており、15系向けの修正版15.5.28も10月14日に出ています。新規も更新も16系にそろえるのが確実です。
Next.jsのセキュリティアドバイザリは、2026年7月1日〜10月27日に22件公開され、そのうち5件がcritical、6件がhighでした。画像最適化API(/_next/image)や use cache まわりの遠隔コード実行が並び、10月14日の16.4.1と15.5.28で修正されたものもあります。App Routerを使う構成では、数週間単位でパッチを当てる運用を前提にしてください。直近の対応手順はReact2Shell(CVE-2025-55182)とNext.js脆弱性の対応手順|10月14日修正の16.4.1・15.5.28まで【2026年10月】にあります。
Nuxt:3系のEOLと4系の期限
Nuxtのロードマップには、Nuxt 3は2026年7月31日にEOLを迎え、以後はバグ修正もセキュリティパッチも受けないと書かれています。3系の最後の版は8月5日の3.21.11です。Nuxt 4のEOLは「Nuxt 5公開の6か月後」で、Nuxt 5は2026年第4四半期の見込みとされています。
EOLの影響はすでに出ています。Nuxtのセキュリティアドバイザリは7月1日以降に18件公開され、10月16日と10月27日公開分のうち4件は、影響範囲に3系を含むのに3系向けの修正版がありません。Nuxt 3のまま運用しているなら、4系への移行は保守の予定ではなく脆弱性対応です。10月27日公開の4.6.3の修正には、開発サーバーでの情報漏えいなど本番環境に関係しないものも含まれます。件数の多さだけで危険度は比べられませんが、どちらも最新版に追従する手間がかかる点は同じです。移行の作業内容はNuxt 4とは?最新バージョンは4.6|確認方法・Nuxt 3との違い・導入手順【2026年10月】で扱っています。
エコシステム・採用・学習コストの差
人と情報の量はNext.jsが大きく上回ります。Stack Overflow Developer Survey 2026の全回答者(10,281人)では、使っているWebフレームワークとしてReactが41.5%、Next.jsが20.6%、Vue.jsが17.2%、Nuxt.jsが4.4%でした。利用者数が多いぶん、詰まったときに参照できる記事や回答、React経験者の採用候補も多くなります。採用したい外部SaaSのSDKやUI部品がReact専用の場合は、Vueから使えるJavaScript APIがあるか、必要な画面をVueで作り直せるかを選定前に確かめてください。Reactの描画機構に依存するUI部品は、Nuxtから使えないことがあります。
一方、Nuxtは決めてくれる量が多いフレームワークです。import文の自動補完とNitroのプリセットによるデプロイ先の切り替えが標準でそろい、状態管理も pinia と @pinia/nuxt を追加すればストアが自動importされる形に決まっているため、フロントエンド専任がいない体制でも構成で迷う箇所が少なくなります。Next.jsもスタンドアロン出力でセルフホストできますが、画像最適化やキャッシュをVercel以外で同じように動かすには、ホスティング側の設定が必要です。
「Vercelを避けたい」という理由は、何を避けたいのかで答えが変わります。Vercelの発表のとおり、NuxtのコアチームがいるNuxtLabsは2025年7月8日にVercelへ加わりました。発表ではNuxtとNitroはMITライセンスの独立したOSSで、公開ロードマップのまま他のホスティング先でも使えるとしています。ホスティング先としてのVercelを避けたいなら、Nitroのプリセットで出し先を選べることはNuxtを選ぶ理由になります。一方、開発元の企業から距離を置きたいという理由では、どちらも主要な開発チームがVercelにいるため差がつきません。
チーム条件別の選び方と、選ぶべきでない場面
判断は次の順に降ろします。
| 条件 | 選ぶ方 |
|---|---|
| 主力メンバーがReactを書ける | Next.js |
| 主力メンバーがVueを書ける・Vue資産がある | Nuxt |
| 使う予定のSDKやUI部品がReact専用 | Next.js |
| Vercel以外(Node.js・Cloudflare等)へ出すと決まっている | Nuxt |
| 初回に送るJSを少なくしたいLP・メディア(LCP・INPの実測で確認) | Nuxt(またはAstro) |
| どちらも書けない・決め手がない | Next.js |
選ぶべきでない場面もはっきりしています。検索エンジンに載せる必要がなく、サーバー側の処理もAPIサーバーが別にある社内の管理画面なら、ViteとReact、またはViteとVueのSPAで足ります。Next.js(output: 'export')やNuxt(nuxt generate)にも静的ファイルとして書き出す構成はありますが、サーバー機能を使わないならフレームワークの規約と更新に付き合う理由が薄くなります。Nuxt 3で新しいプロジェクトを始めるのも避けてください。EOL後に公開された脆弱性に修正版が出ていません。既存のReactアプリを「Nuxtのほうが書きやすい」という理由で作り直す計画も、全面的な書き直しに見合う効果はまず出ません。乗り換えは、描画方式かデプロイ先の要件を今の構成で満たせないと分かったときに限って検討します。業務システムやWebアプリでどちらを使うか決めきれない場合は、業務用・Webアプリ開発の支援で要件から選定できます。
よくある質問
Next.jsとNuxtはどちらが速いですか?
最初に送るJSの量はNuxtのほうが少なく、同じ最小ページでgzip後に約67KB対約174KBでした。ただし実際の表示速度は、静的化した範囲・画像・キャッシュ設計で大きく変わります。採用前に自社のページを両方で作り、Core Web Vitalsで測るのが確実です。
Next.jsとReactの違いは何ですか?
ReactはUIを描画するライブラリで、Next.jsはそのReactにルーティング・サーバーレンダリング・ビルド・APIルートを載せたフレームワークです。素のReactではルーターやビルドの道具を自分で選びますが、Next.jsは app/ ディレクトリの規約でそれらを決めています。Next.jsを使うときもコンポーネントはReactで書きます。
VueとNuxtの違いは何ですか?どちらから学ぶべきですか?
VueはUIライブラリで、Nuxtはそこにルーティング・SSR・自動import・サーバーAPIを足したフレームワークです。学ぶ順はVueが先です。Nuxtのページもコンポーネントも中身は素のVue(単一ファイルコンポーネントとComposition API)なので、Vueの書き方を知らないとNuxtの機能を使う前に手が止まります。
Nuxt 3のまま運用を続けても大丈夫ですか?
おすすめしません。Nuxt 3は2026年7月31日にEOLとなり、10月に公開されたアドバイザリのうち4件は3系に修正版がありません。アプリがすぐに止まるわけではありませんが、新しい脆弱性が見つかっても公式の修正は出ない前提になります。4系への移行を早めに計画してください。
NuxtからNext.jsへ乗り換えるべきですか?
Vueで書いた画面をすべてReactで書き直すことになるため、乗り換えだけを目的にするのは割に合いません。React専用のSDKが必須になった、Reactを書ける人しか採用できない、といった事情があるときに検討します。Nuxt 3が理由なら、乗り換えよりNuxt 4への移行のほうが作業は小さく済みます。