お疲れ様です！IT業界で働くアライグマです！
結論から言うと、Next.jsは万能ではありません。
2023年から2025年にかけて、Next.jsはReactエコシステムにおける事実上の標準フレームワークとして君臨してきました。しかし、2025年後半から「Next.jsを採用するのをやめた」という声が増えています。サーバーコンポーネントの複雑さ、App Routerへの移行コスト、Vercel以外への環境へのデプロイの難しさなど、運用してみて初めて見えてきた課題が表面化しているためです。
本記事では、Next.jsからViteベースのフレームワークへ移行を検討する際の判断基準と、実際に移行を決断したプロジェクトの事例を紹介します。
Next.jsが「重い」と感じるようになった背景
Next.jsが選ばれてきた理由は明確でした。ファイルベースルーティング、SSR/SSGのサポート、API Routes、Image最適化など、フルスタックWebアプリケーションに必要な機能がオールインワンで揃っていたからです。
しかし、App RouterとReact Server Components（RSC）の導入以降、状況が変わりました。
App Routerの学習コストと移行の複雑さ
Pages RouterからApp Routerへの移行は、単なるディレクトリ構造の変更ではありません。コンポーネントの設計思想そのものを見直す必要があります。
- サーバーコンポーネントとクライアントコンポーネントの境界設計：「use client」ディレクティブの配置戦略
- データフェッチパターンの変更：getServerSideProps/getStaticPropsからfetch with cacheへ
- Layoutsとloading.jsの新しい概念：キャッシュ戦略の複雑化
既存のPages Routerのプロジェクトを維持しながら新規開発はApp Routerで、という混在運用は現実的には困難です。
Vercel最適化とセルフホストの壁
Next.jsはVercelが開発しているため、Vercelへのデプロイが最も簡単で、機能も最大限に発揮されます。しかし、AWS、GCP、オンプレミスへのセルフホストでは、ISR（Incremental Static Regeneration）やEdge Functionsなどの一部機能に制限が生じます。
インフラコストを抑えたい、既存のKubernetesクラスタで運用したいといった要件がある場合、Next.jsの恩恵を十分に受けられないケースがあります。
フロントエンド技術のスキルアップ戦略については、jotaiで学ぶReact Suspense時代の状態管理も参考になります。
IT女子 アラ美
ITアライグマViteベースフレームワークが選ばれる理由
Next.jsからの移行先として注目されているのが、Viteをベースにしたフレームワーク群です。代表的なものとしてReact Router（旧Remix）、TanStack Start、Astroなどがあります。
Viteの圧倒的な開発体験
ViteはES Modulesをネイティブで活用することで、開発サーバーの起動とHMR（Hot Module Replacement）が非常に高速です。
- コールドスタートの高速化：プロジェクト規模に関わらず瞬時に起動
- HMRの即時反映：ファイル保存から画面反映まで数十ミリ秒
- シンプルな設定：vite.config.tsで必要なプラグインを追加するだけ
React Router v7（旧Remix）の進化
2025年にリリースされたReact Router v7は、Remixと統合され、フルスタックWebアプリケーションフレームワークとして大幅に強化されました。
- loader/actionによる直感的なデータフェッチ：サーバーとクライアントの境界が明確
- Progressively Enhanced Forms：JavaScriptなしでも動作するフォーム
- ViteベースのビルドシステムとRSC対応：最新のReact機能を活用可能
技術トレンドの変化への対応については、Remix 3の新コンポーネントライブラリ入門も参考になります。
IT女子 アラ美ITアライグマケーススタディ：社内ツールをNext.jsからReact Router v7に移行した事例
ここでは、実際にNext.js 14（App Router）からReact Router v7への移行を行ったプロジェクトの事例を紹介します。
状況（Before）
- 社内向け管理ツール。ユーザー数約200名、月間PV約10万
- Next.js 14（App Router）で構築。Vercel上で運用
- 開発チーム3名（フロントエンド2名、バックエンド1名）
- 課題：Vercelの月額コストが増加（月10万円超）、セルフホストへの移行を検討
- 課題：App Routerのキャッシュ挙動が予測しにくく、デバッグに時間を取られる
- 課題：新メンバーのオンボーディングに3週間以上かかる（RSCの理解に時間）
行動（Action）
- フレームワーク選定：React Router v7、TanStack Start、Astroを比較検討
- 選定基準：①既存のReact資産の活用、②セルフホストの容易さ、③学習コスト
- React Router v7を採用：loader/actionのパターンがシンプル、Viteベースで高速、RSC非依存
- 移行戦略：Route単位で段階的に移行。共通コンポーネントは共有パッケージ化
- Docker化してAWS ECS Fargate上にデプロイ。月額コストを約3万円に削減
- 移行期間：約2ヶ月（主要機能の移行1.5ヶ月、テスト・調整0.5ヶ月）
結果（After）
- 開発サーバー起動時間：8秒 → 0.5秒以下（16倍高速化）
- HMR反映時間：2〜3秒 → 50ms以下
- 新メンバーのオンボーディング期間：3週間 → 1週間
- インフラコスト：月10万円 → 月3万円（70%削減）
- ビルド成果物サイズ：約30%削減
キャリアの技術選択については、エンジニアがスキルアップできる転職先を見極めるための評価軸と面接での質問術も参考になります。
IT女子 アラ美ITアライグマNext.jsに留まるべきケースと移行すべきケース
すべてのプロジェクトがNext.jsから移行すべきというわけではありません。判断基準を整理します。
Next.jsに留まるべきケース
- Vercelでの運用に問題がない：コスト・機能の両面で満足している
- SSG/ISRを多用するメディアサイト：Next.jsのImage最適化・ISRが効果的
- 既にApp Routerに完全移行済み：再度の移行コストが高い
- チーム全体がRSCに習熟している：開発効率が落ちていない
移行を検討すべきケース
- セルフホストが必須要件：AWS/GCP/オンプレミスでの運用が必要
- Pages RouterからApp Routerへの移行が停滞：移行コストが高すぎる
- 開発サーバーの起動・HMRが遅い：大規模プロジェクトでのDX低下
- 新メンバーのオンボーディングに時間がかかる：RSCの学習コストが高い
シンプルな構成への回帰は、Rails 8でSQLiteを本番運用するといった記事が示すように、バックエンド領域でもトレンドになっています。フロントエンドでも同様の動きが起きています。
さらなる年収アップやキャリアアップを目指すなら、ハイクラス向けの求人に特化した以下のサービスがおすすめです。
| 比較項目 | TechGo | レバテックダイレクト | ビズリーチ |
|---|---|---|---|
| 年収レンジ | 800万〜1,500万円ハイクラス特化 | 600万〜1,000万円IT専門スカウト | 700万〜2,000万円全業界・管理職含む |
| 技術スタック | モダン環境中心 | Web系に強い | 企業によりバラバラ |
| リモート率 | フルリモート前提多数 | 条件検索可能 | 原則出社も多い |
| おすすめ度 | 技術で稼ぐならここ | A受身で探すなら | Bマネジメント層向け |
| 公式サイト | 無料登録する | - | - |
IT女子 アラ美ITアライグマまとめ
Next.jsは優れたフレームワークですが、すべてのプロジェクトに最適というわけではありません。
- App RouterとRSCの複雑さ：学習コストと移行コストが高い
- Vercel最適化：セルフホストでは機能制限がある
- Viteベースの代替：React Router v7、TanStack Startが有力な選択肢
- 移行判断の基準：DXの低下、セルフホスト要件、オンボーディングコスト
技術選択はプロジェクトの要件と制約によって異なります。「Next.jsだから正解」「Viteだから正解」ではなく、自分たちのチームとプロダクトに合った選択をすることが重要です。
IT女子 アラ美ITアライグマ
