Next.jsのリファクタリング外注で確認すべき論点
「Pages Routerのまま数年放置している」「App Routerへの移行を始めたが中途半端で止まっている」「ビルドに数分かかる」「画面によってSSRとCSRの使い分けがバラバラで誰も説明できない」——Next.jsでプロダクトを作って運用していると、こうした状態に行き着くことが少なくありません。Next.js自体の進化が速いフレームワークであるがゆえに、作った当時は最適だった構成が数年で技術的負債になりやすいのです。
この記事では、Next.jsプロダクトのリファクタリングを外注する際に確認すべき論点を、App Router移行・レンダリング戦略・パフォーマンス・バージョンアップというNext.js固有の切り口で整理します。
Pages Router のまま止まっているとどうなるか
Next.js 13で導入されたApp Routerは、もはや新規機能の中心です。Pages Routerに留まり続けると、以下が徐々に効いてきます。
- 新しいNext.jsの最適化機能（Server Components、Streaming、Partial Prerenderingなど）の恩恵を受けられない
- ライブラリ側がApp Router前提でドキュメントを書くようになり、Pages Router向けの情報が探しにくくなる
- 採用面でも「Pages Routerしか知らない」より「App Routerの経験がある」エンジニアの方が採用市場で見つけやすい
とはいえ、「動いているPages Routerを今すぐ全部App Routerに書き換える」のが正解とも限りません。移行コストと得られるメリットを天秤にかける必要があります。
App Router移行は「一気に」やらない
Next.jsのApp Router移行で最も危険なのが、全ページを一度に移行しようとすることです。理由は次の通りです。
- App RouterはPages Routerとデータ取得の作法（
getServerSideProps/getStaticPropsからfetch+ キャッシュ戦略へ）が根本的に異なり、ページごとに個別の判断が必要 - レイアウト構造（
_app.tsx/_document.tsxからlayout.tsxへ）の変更が全ページに波及するため、途中で止めると新旧の作法が混在してかえって読みにくくなる - Server ComponentsとClient Componentsの境界設計を誤ると、意図せずクライアントバンドルが肥大化する
Next.jsはPagesディレクトリとAppディレクトリを同一プロジェクト内で共存させられるため、移行は本来これを活かして段階的に進められます。
- 新規ページ・影響範囲の小さいページからAppディレクトリで作り始める
- 既存ページはトラフィックの少ない/変更頻度の低いものから順にApp Routerへ移す
- データ取得ロジックとUIロジックが密結合しているページは、先に分離してから移行する
- 移行完了までPages Routerを残すことを前提にスケジュールを引く（無理に期限を切らない）
「App Router移行」という名目で発注が来ても、私たちはまず移行しないと解決しない課題かどうかから確認します。パフォーマンスやSEOの問題が別の原因（後述のレンダリング戦略の混在など）にある場合、App Router移行より先にやるべきことがあるケースは珍しくありません。
レンダリング戦略の整理: SSR/SSG/CSRが混在してカオスな状態
Next.jsの強みは複数のレンダリング戦略を選べることですが、それが「なぜこのページがこの方式なのか誰も説明できない」状態を生みやすい原因にもなっています。
- 本来SSGで十分な静的コンテンツが、過去の都合でSSRになっていてサーバー負荷とレスポンスタイムを無駄に悪化させている
- クライアントで完結できるデータ取得が、SSRとCSRの二重取得（サーバーで取ってきたデータをクライアントで再度fetchし直す）になっている
- キャッシュ戦略（
revalidateの有無・秒数）がページごとにバラバラで、意図した鮮度で表示されているか誰も検証していない
外注時にまず依頼すべきは、全ページのレンダリング方式を棚卸しして一覧化することです。「このページは本当にSSRである必要があるか」を1ページずつ再検証するだけで、パフォーマンスとサーバーコストが改善するケースは多くあります。
パフォーマンス改善: 計測してから直す
「Next.jsのサイトが遅い」という相談で、いきなりコードを書き換え始めるパートナーには注意が必要です。Next.jsのパフォーマンス問題は原因が多岐にわたるため、計測せずに直すと的外れな対応になりがちです。
- ビルドが遅い: 依存パッケージの肥大化、不要なポリフィル、TypeScriptの型チェックがビルドをブロックしているなど原因は様々
- 表示が遅い（Core Web Vitals）:
next/imageを使わず素の<img>タグで巨大な画像を配信している、フォントの読み込みが最適化されていない（next/font未使用）、不要なClient Componentsが多くバンドルサイズを圧迫している、といった典型パターンがある - 画面遷移が遅い: プリフェッチが効いていない、ミドルウェアで重い処理を毎回実行している、といったケース
外注時に確認すべきは、Lighthouse・Core Web Vitals・バンドルサイズ分析（@next/bundle-analyzer など）で現状を数値化してから改善提案が来るかです。「なんとなく遅いから作り直す」ではなく、ボトルネックを特定してから最小の変更で直す進め方が費用対効果に優れます。
バージョンアップの論点
Next.jsはメジャーバージョンごとに変更が大きく、バージョンが古いまま放置されているプロダクトも多く見かけます。
- Next.js 12以前からのアップグレードでは、App Router導入だけでなく
next/imageやnext/fontの仕様変更、ミドルウェアの挙動変更なども同時に絡んでくる - Reactのバージョン（18→19系）とNext.jsのバージョンの組み合わせに互換性の制約があるため、Reactだけ・Next.jsだけを個別に上げることが難しい場面がある
- 依存しているUIライブラリがApp Router / Server Componentsに未対応の場合、バージョンアップより先にライブラリの置き換えが必要になることもある
バージョンアップは単独のタスクに見えて、実際にはApp Router移行・レンダリング戦略の見直しと分離できないことが多いです。外注先には、この3つを別々の作業として提案してくるか、依存関係を理解した上で統合したロードマップを示せるかを確認してください。
外注時に確認すべきこと: 既存の集客URLを壊さない
Next.jsのリファクタリングで事業上最もリスクが高いのは、検索エンジンに評価されている既存URLを壊してしまうことです。
- App Router移行やルーティング構造の変更で、既存ページのURLパスが意図せず変わっていないか
- URLを変更する場合、301リダイレクトが漏れなく設定されているか（
next.config.jsのredirectsで機械的に検証できる） - メタタグ・構造化データ（JSON-LD）がApp Router移行後も同じ内容で出力され続けているか
- サイトマップの生成ロジックが移行後も正しく動いているか
これらはリファクタリングの完了基準に含めるべき項目です。「コードはきれいになったが検索流入が落ちた」は、事業側にとってはリファクタリングの失敗と同義です。外注先が着手前にこの観点を持ち出してこない場合は、こちらから確認することを強くおすすめします。
なお、Reactコンポーネント設計・state管理といったフレームワーク非依存の論点はReactリファクタリングを外注すべき症状と進め方で扱っています。Next.js固有の論点と合わせて確認すると、リファクタリングの全体像を把握しやすくなります。また、そもそも既存プロダクトのどこから手を入れるべきかを見極める観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。
torcheees では React / Next.js を中心に、既存Next.jsプロダクトのApp Router移行・パフォーマンス改善を手がけています。詳しくはモダナイゼーションのサービスページをご覧ください。
まとめ
- Next.jsのリファクタリングは、App Router移行・レンダリング戦略・バージョンアップが密接に絡み合うため、一気にではなく段階的に進めるのが安全
- パフォーマンス改善は「計測してから直す」が原則。Core Web Vitalsやバンドルサイズを数値化しないまま着手する提案には注意する
- 既存の集客URLとSEO評価を壊さないことをリファクタリングの完了基準に含め、301リダイレクトやメタタグの継続を必ず確認する
「Next.jsのコードが古い、または移行が中途半端で止まっている」という状態でも構いません。torcheees では既存プロダクト改善向けに、1〜4週間の「開発診断」で現状のレンダリング構成とパフォーマンスを確認し優先順位をご提示するほか、継続的な改善支援も行っています。お問い合わせフォームからお気軽にご相談ください。