目次
「Vue 2で作ったフロント、まだ動いているから放置している」。こういった判断が、フロントエンド開発の停滞を招く。Vue 2は2023年12月31日をもってEnd of Life（EOL）を迎えた。Nuxt 2は2024年6月30日にサポートが終了している。どちらも現時点でセキュリティパッチは提供されない（出典：Vue 2 EOL - Vue.js公式FAQ、Nuxt 2 End-of-Life - Nuxt Blog）。
移行先の選択肢は大きく3つある。Vue 3へのアップグレード、Nuxt 3への移行、そしてReact/Next.jsへのリプレース。本記事では、それぞれの手順と判断基準を、150万MAUのサービスが実際に踏んだNuxt→Next.js移行事例を参照しながら整理する。
Vue 2 EOLが意味すること
Vue 2のサポート終了は「古いバージョンを使い続けても動く」という意味ではない。問題は、脆弱性が発見されてもパッチが提供されないという点だ。
フロントエンドとはいえ、XSSやCSRFのリスクはある。依存するエコシステム（vue-router、Vuex、各種UIライブラリ）も順次Vue 2サポートを打ち切っており、Node.jsやビルドツールの更新に伴う互換性崩壊も時間の問題だ。
Vue 2.7系が最終リリースであり、Composition APIのバックポートが含まれている。2.7に留まること自体は技術的に可能だが、長期的な視点では移行を避ける理由にはならない。HeroDevsが有償の延長サポート（Vue 2 NES）を提供しているが、これは移行の猶予を買う手段であって、恒久的な解決策ではない（出典：Nuxt 2 LTS & Extended Support）。
Vue 3移行の具体的手順
ステップ1：Vue 2.7へのアップデート
Vue 3への直接移行より先に、Vue 2.7系に上げることを推奨する。2.7ではComposition APIが使えるようになるため、<script setup>構文でコンポーネントを書き直す練習を段階的に進められる。この段階でロジックのコンポーザブル化を始めておくと、Vue 3移行時の差分が小さくなる。
ステップ2：@vue/compat（移行ビルド）を活用する
Vue 3には互換モード（@vue/compat）が用意されている。Vue 2の挙動をエミュレートしつつ、フラグで互換性を切り替えながら段階的にコードを修正できる。一気に書き直すのではなく、コンポーネント単位で移行を進める方法として有効だ（出典：移行作業に取り掛かる人のためのVue3移行手順とTips - Zenn）。
ステップ3：Options APIからComposition APIへの変換
Options APIからComposition APIへの変換は機械的に行える部分が多い。対応関係を以下に整理する。
| Options API | Composition API |
|---|---|
data() | ref() / reactive() |
computed | computed() |
methods | setup()内の関数 |
mounted | onMounted() |
watch | watch() |
props | defineProps() |
emit | defineEmits() |
Composition APIの最大の利点はロジックの再利用性だ。Options APIでは機能ごとのロジックがdata、methods、computedに分散してしまうが、Composition APIではコンポーザブル関数として一箇所にまとめられる。TypeScriptとの親和性も高く、型推論が自然に効く（出典：Composition API FAQ - Vue.js公式）。
Makuakeのケースでは、600以上のコンポーネントを約1ヶ月でVue 3に移行している。移行ビルドで互換性を確保しながら段階的に進めたことが成功の要因だった（出典：いかにして600個以上のコンポーネントがあったVue2を約1ヶ月でVue3に置き換えたか｜Makuake Tech note）。
ステップ4：ツールチェーンの刷新
Vue 3移行に伴い、以下のツールも更新が必要になる。
- ビルドツール：Vue CLI → Vite
- 状態管理：Vuex → Pinia
- VSCode拡張：Vetur → Volar（Vue - Official）
- テスト：Vue Test Utils v1 → v2
Viteへの移行は単なるビルドツールの入れ替えではなく、開発体験の改善として実感できる。ホットリロードの速度が大幅に向上し、コールドスタートも速い。
Nuxt 3の主要変更点
Nuxt 2からNuxt 3への移行は、Vue 2→Vue 3の変更に加え、フレームワーク固有の破壊的変更が伴う。代表的な変更点を押さえておく必要がある（出典：Nuxt2 から Nuxt3 への変更点を整理する - Qiita）。
サーバーエンジン：Nitro
Nuxt 3のサーバーエンジンはNitroに刷新された。サーバーレス対応がデフォルトで含まれ、/server/api/以下にファイルを置くだけでAPIエンドポイントを定義できる。Nuxt 2時代のserverMiddlewareとは設計が大きく異なる。
自動インポートの拡張
components/、composables/、utils/ディレクトリ以下のファイルが自動インポートされる。Nuxt 2では手動でimportが必要だったコンポーザブルが、記述なしで使えるようになる。ただし、この「魔法」は解析ツールのサポート範囲外になるケースもあるため、大規模プロジェクトでは明示的インポートを好む判断もある。
asyncDataとfetchの廃止
Nuxt 2でデータ取得に使っていたasyncDataとfetchは廃止。代わりにuseFetchとuseAsyncDataコンポーザブルを使う。呼び出しインターフェースは似ているが、内部の動作とSSR/CSRの切り替え方法が異なる。
ディレクトリ構造の変更
store/（Vuex）は廃止。nuxt.config.jsの設定キーが多数変更されており、特にbuild関連の設定は大半が書き直しになる。
約60ページ規模のアプリケーションでNuxt 2→Nuxt 3を移行したケースでは、2ヶ月・4名体制が必要だったという報告がある（出典：Nuxt2からNuxt3のバージョンアップ - idealive tech blog）。移行ビルドが存在しないため、段階的な移行が難しい点がNuxt特有の課題だ。
150万MAUのNuxt→Next.js移行事例が示す判断軸
Ubieが公開した「150万MAUのNuxt.js製サービスを機能開発を止めずに1ヶ月&1人でNext.jsに置き換えた話」（出典：Zenn - ubie_dev）は、Vue/Nuxtの移行判断において重要な視点を提供している。
2018年に立ち上がったNuxt製のAI問診サービスは、コードベースが約6万行に成長。技術的な問題よりも組織的な課題がリプレースの引き金になった。Ubieの他プロダクトは全てReactで構築されており、Vue.jsのキャッチアップが必要になることで社内エンジニアの流動性が阻害されていた。「Vueを書ける人を採用するか、Vueを学んでもらうか」という問題が常に発生していた。
移行のアプローチとして特筆すべきは、CSS Modulesの採用だ。VueのSFCスタイルをCSS Modulesに変換することで、テンプレートとスタイルをほぼそのままNext.jsにポーティングできた。これにより、JSXへの書き換えとロジックの移植を並行して進める作業量を大幅に削減した。
機能開発を止めずに1ヶ月・1名で完了できた背景には、この技術的な判断と、既存のテストカバレッジが寄与している。
Vue 3継続 vs Nuxt 3移行 vs Next.js移行の判断基準
移行先の判断は技術要件だけでなく、チームの状況とプロダクトの将来像に依存する。以下の観点で整理する。
Vue 3継続（Nuxt 3移行）が合理的なケース
- フロントエンドチームがVue.jsに精通しており、採用もVueエンジニア前提
- Composition APIとcomposablesによるロジック再利用が十分に機能している
- Nuxt 3の自動インポート・Nitroサーバー・ハイブリッドレンダリングが要件にマッチする
- Vue特有のテンプレート構文やディレクティブ（
v-modelの双方向バインディングなど）を活かした設計が既に定着している
Nuxt 3はReact/Next.jsと比較してVueランタイムが軽量（Reactより約33%小さい）であり、Nitroのエッジコールドスタートが速いという特性がある（出典：Nuxt vs Next.js - DebugBear）。特にVercel以外のエッジ環境ではNuxt/Nitroの優位性が出やすい。
Next.jsへのリプレースを検討すべきケース
- 組織の主要技術スタックがReactであり、Vue専任エンジニアの確保が困難
- BFF（Backend for Frontend）やAPIルートをJavaScript統一で管理したい
- App RouterによるReact Server Componentsの活用がアーキテクチャ要件に合致する
- 採用・育成・他チームとの協業という観点でReactエコシステムへの統合が有利
判断の核心はパフォーマンスベンチマークではなく、長期的なチーム維持コストだ。「どちらが速いか」より「どちらのエンジニアを継続的に確保できるか」が実務上の決め手になる（出典：Nuxt vs Next.js 2025 - Strapi Blog）。
移行判断の前にやるべきこと
移行先を決める前に、現状のコードベースを正確に把握することが先決だ。特に以下の点は移行工数の見積もりを大きく左右する。
- コンポーネント数と循環依存の有無：Vuex storeとコンポーネント間の依存関係
- カスタムプラグインの数と複雑度：Vue.useで登録したグローバルプラグインの洗い出し
- サーバーサイドレンダリングの依存箇所：asyncDataやserverMiddlewareの使われ方
- テストカバレッジ：移行後の動作保証がどこまで自動化できるか
「動いているから触らない」という判断が通用したのはサポート期間中だ。Vue 2とNuxt 2のEOLは過ぎている。移行の入口として現状のフロントエンド構造を把握することが、具体的な計画策定の第一歩になる。
Vue/Nuxtのレガシーフロントエンド、どこから手をつけるべきか判断できていないだろうか。
SysDockは、AIマルチエージェントがソースコードからシステム構造を自動解析する。コンポーネント依存関係、ストア設計、SSRの使われ方をWord・PPT・React Flowフロー図の3点セットで可視化。1週間納品・ソースコード非送信・完全後払いだ。
WordPressを含むフロントエンドの老朽化診断については、WordPressサイトの老朽化診断｜リニューアル判断の5つのサインも参照してほしい。フレームワークが異なっても、「動いているから安全」という判断の危うさは共通している。
関連アプリ
| ツール | 概要 | URL |
|---|---|---|
| WhyTrace | なぜなぜ分析の構造化支援 | genbacompass.com/products/whytrace |
| AnzenAI | AI活用のリスクアセスメント支援 | genbacompass.com/products/anzenai |
参考文献
- 150万MAUのNuxt.js製サービスを機能開発を止めずに1ヶ月&1人でNext.jsに置き換えた話 - Zenn（ubie_dev）
- Nuxt 2 End-of-Life (EOL) - Nuxt Blog
- Vue.js公式FAQ - EOL情報
- Composition API FAQ - Vue.js公式
- 移行作業に取り掛かる人のためのVue3移行手順とTips - Zenn
- Nuxt2 から Nuxt3 への変更点を整理する - Qiita
- いかにして600個以上のコンポーネントがあったVue2を約1ヶ月でVue3に置き換えたか - Makuake Tech note
- Nuxt2からNuxt3のバージョンアップ - idealive tech blog
- Nuxt vs Next.js: A Practical Comparison - DebugBear
- Nuxt vs Next.js 2025: Framework Choice Guide - Strapi Blog