既存Vue2アプリをVue3へ移行する判断基準

「Vue2で動いてはいるが、npm installのたびに脆弱性警告が増えている」「求人を出してもVue2経験者からの応募が減っている」——Vue2は2023年末にEOL(End of Life)を迎え、公式のセキュリティパッチ提供も終了しました。動いているものを止める理由がないまま、気づけば2年近く塩漬けにしている会社は少なくありません。

この記事では、既存Vue2アプリをVue3へ移行すべきかどうかの判断基準と、移行する場合の進め方・難所・外注時の確認点を、発注者向けに整理します。

Vue2を塩漬けにするコスト

「動いているから問題ない」という判断は半分正しく半分間違っています。Vue2自体が急に壊れることはありません。ただし放置コストは静かに積み上がります。

• セキュリティパッチが出ない: Vue2本体はEOL済みで、依存ライブラリ側のVue3対応が進むほどVue2向けの更新は止まっていきます。脆弱性が見つかっても直る見込みがありません
• 周辺ライブラリが順次Vue3専用になる: Vue Router・Vuex・Vuetify・Element UIなど主要ライブラリは軒並みVue3系にメジャーバージョンを上げており、新しいプラグインやUIコンポーネントの多くがVue3前提で作られています。Vue2版が更新されないため機能追加が止まった状態のライブラリに依存し続けることになります
• 採用市場でVue2経験は目減りしている: 新しく入るエンジニアはVue3(特にComposition API)を前提に学習していることが多く、Vue2固有の書き方(Options APIの制約・thisの挙動)を一から教えるコストがかかります
• Node.jsやビルドツールのバージョンに引きずられて他も上げられなくなる: Vue2を支えるVue CLI(webpack)は保守が縮小しており、Node.jsの新しいバージョンでビルドが通らない、といった別の問題を誘発し始めます

これらは「今日壊れる」話ではなく「1〜2年後に選択肢が狭まる」話です。だからこそ後回しにされがちですが、移行コストは待つほど増える方向にしか動きません(依存ライブラリの移行対応が進むほど参考実装は増えますが、自社のコード量も同時に増えるためです)。

移行の難所: Vue2→Vue3で何が壊れるか

Vue3はVue2との後方互換性を意図的に一部捨てています。主な難所は4つです。

1. 破壊的変更(Breaking Changes)

• グローバルAPIの変更: new Vue()がcreateApp()に変わり、Vue.componentやVue.useなどのグローバル設定方法も変わります。アプリのエントリーポイントは書き換えが必須です
• v-modelの挙動変更: Vue2のv-modelはvalue/input固定でしたが、Vue3ではmodelValue/update:modelValueに変わり、複数のv-modelを1コンポーネントに持たせられるようになった一方、既存の独自コンポーネントは軒並み書き換えが必要です
• フィルタ(filters)の廃止: {{ price | currency }}のようなフィルタ構文が丸ごと廃止されており、算出プロパティかメソッド呼び出しへの置き換えが必要です
• イベントAPIの変更: $on/$off/$onceによるイベントバスパターンが廃止されています。コンポーネント間通信をイベントバスに頼っている設計だと、Pinia(状態管理)やmittなどの代替手段への置き換えが必要になります

2. Options API → Composition API への移行圧力

Vue3でもOptions APIはサポートされており、書き方自体を変えなくても動く場合が多いです。ただし実務上は次の理由でComposition APIへの移行を同時に検討することになります。

• TypeScriptとの相性がComposition API側で大きく改善されている(Options APIのthis型推論は弱い)
• ロジックの再利用がmixin(名前衝突・出所不明瞭という問題を抱えていた)からcomposable(明示的なimport)に変わり、既存の複雑なmixin構成を持つアプリほど設計の見直しが必要になる
• 新規に入るエンジニアの多くがComposition APIを前提に学習しており、Options APIのままだとコードレビューや引き継ぎで摩擦が生じる

「文法だけVue3、設計はVue2のまま」でいったん移行を完了させ、Composition APIへの書き換えは機能追加のタイミングで併せて進める、という2段階に分けるのが現実的です。一度に両方をやろうとすると変更範囲が膨らみすぎてレビューもテストも成立しなくなります。

3. 依存ライブラリのVue3対応状況

移行工数を最も左右するのはアプリ自体のコード量ではなく、依存しているUIライブラリ・プラグインのVue3対応状況です。

• Vuetify 2系→3系、Element UI→Element Plus、Vue Router 3系→4系、Vuex→Pinia(またはVuex 4系)など、主要ライブラリはVue3版で破壊的変更を伴うメジャーバージョンアップになっているケースがほとんどです
• 社内製・特定ベンダー製の古いVue2専用コンポーネントに依存している場合、Vue3版が存在しないため代替ライブラリの選定か自作での置き換えが必要になり、ここが工数の大半を占めることが多いです
• 着手前にpackage.jsonの依存を洗い出し、各ライブラリのVue3対応状況(公式対応済み/開発中/対応予定なし)を一覧化するだけで、移行規模の見積もり精度が大きく上がります

4. 段階移行のしづらさ

jQuery→ReactやAngularJS→Angularのような異なるフレームワーク間の移行では、DOM上で新旧を共存させる段階移行が比較的組みやすいのに対し、Vue2→Vue3は同一フレームワークのメジャーバージョン違いであるため、1つのVueインスタンス・1つのビルド設定の中でバージョンを混在させることが基本的にできません。画面(ルート)単位でビルドを分離できる構成でない限り、「一部の画面だけ先にVue3化する」という進め方が技術的に難しいのが実情です。

移行方式の選択: 段階移行 / 一括移行 / 別フレームワークへ

一括移行が現実的なケース

• アプリ規模が小さい(コンポーネント数が数十程度)
• Vuetify・Element UIなど大型UIライブラリへの依存が薄い、またはすでにVue3対応版がある
• ビジネス側の機能追加を一時的に止められる期間(数週間〜1ヶ月程度)を確保できる

この条件が揃えば、Vue公式が提供する移行ビルド(@vue/compat)を使い、警告を1つずつ潰しながら一気に移行するのが最短ルートです。中途半端に期間を引き延ばすより、短期集中で片付けたほうがトータルコストは低くなります。

「画面単位の段階移行」が必要になるケース

• SPAが複数の独立したルート・複数のビルド成果物に分かれている(マイクロフロントエンド的な構成、あるいは元々サーバーサイドレンダリングのページに部分的にVueをマウントしている構成)
• ビジネス側の要望で機能追加を止められない

この場合、新規画面・大幅改修が入る画面から順にVue3で書き直し、それ以外はVue2のまま残す、という画面単位の切り替えが現実的な線です。ただし前述の通り1アプリ内での混在は難しいため、実質的には「新しいVue3アプリを別途立ち上げ、URLルーティングやリバースプロキシで段階的に向き先を切り替える」形になります。この進め方は移行期間中インフラ構成が一時的に複雑になる代償を伴うため、規模が小さいなら一括移行のほうが結果的に安く済むことが多いです。

別フレームワークへの乗り換えという選択肢

Vue2からの移行を検討するタイミングで、そもそもReact・Next.jsなど別のフレームワークへの乗り換えを検討する会社もあります。判断基準は次の通りです。

• Vue3への移行だけで済ませるべき: チームにVueの知見が蓄積されている、UIライブラリの移行対応が完了している、移行の主目的が「セキュリティ・保守性の回復」であって機能追加の予定が薄い場合
• 別フレームワークへの乗り換えも検討に値する: Vueの知見を持つエンジニアが社内・採用市場ともに減っている、SSRやSEOの要件が強くNext.jsのようなフレームワークの恩恵が大きい、今後大規模な機能追加を予定しており設計を作り直す機会と割り切れる場合

「どうせ書き換えるならVue3ではなくReactにしよう」という判断は理屈としては成立しますが、Vue3への移行より工数もリスクも大きくなる点は踏まえておく必要があります。移行しない(=Vue2を維持し続ける)という選択肢も、リプレースの予定が半年以内に確定しているなら合理的な場合があります。

移行しない、という判断もある

すべてのVue2アプリを今すぐ移行すべきというわけではありません。次のいずれかに該当する場合は、移行を急がず様子見でよいと考えています。

• 半年〜1年以内にプロダクト自体のリプレースやサービス終了が決まっている
• 外部公開されておらず社内限定利用で、攻撃対象としてのリスクが低い
• 依存ライブラリが枯れきっていて今後もアップデートの予定がなく、脆弱性が出ても影響範囲を把握・遮断できる体制がある

一方、これらに当てはまらないまま「後でやろう」で止まっている状態が最もリスクが高いパターンです。判断を先送りするだけでも、依存ライブラリの選定作業自体は今のうちに済ませておくことをお勧めします。

外注時に確認すべきこと

Vue2→Vue3移行を外部チームに依頼する際は、以下を確認してください。

• 依存ライブラリの洗い出しを最初にやるか: いきなりコードの書き換えに入るのではなく、package.jsonの全依存についてVue3対応状況を一覧化する工程があるか
• 一括移行か段階移行かの判断根拠を説明できるか: アプリ規模・ビルド構成・止められる期間を踏まえて、どちらが適切かを具体的に説明できるか
• Options API→Composition APIの移行を同じスコープに含めているか: 含める場合は工数が大きく変わるため、別フェーズとして切り出す提案になっているか
• 移行前のテスト整備を提案してくるか: Vue2アプリにE2Eテストがない場合、「今の挙動」を壊さず移行したことを確認する手段をどう用意するか

こうした判断は、フレームワークが異なるjQueryからの移行とも共通する部分がありますが、「同一フレームワーク内でのメジャーバージョン移行」特有の制約(混在のしづらさ)がある点が異なります。異なる技術スタック間の段階移行の考え方は古いjQuery画面をReactへ段階移行する進め方で扱っています。また、そもそも既存プロダクトのどこから手をつけるべきかを見極める観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。

torcheees では Vue を含むフロントエンド技術を中心に、既存プロダクトのモダナイゼーションを手がけています。詳しくはモダナイゼーションのサービスページをご覧ください。

まとめ

• Vue2はEOL済みでセキュリティパッチが出ず、依存ライブラリの対応終了・採用市場での目減りが静かに進むため、放置コストは待つほど大きくなる
• 移行方式はアプリ規模・依存ライブラリのVue3対応状況・機能追加を止められる期間で判断する。小規模なら一括移行、大規模かつ止められないなら画面単位の段階移行(実質的には別アプリを立てての切り替え)が現実的
• 外注時は「依存ライブラリの洗い出しを最初にやるか」「一括/段階の判断根拠」「Composition API移行を同じスコープに含めるか」「移行前のテスト整備」を確認することが失敗しない選択につながる

「Vue2のまま放置しているが、いつ・どう移行すべきか判断がつかない」という段階でも構いません。torcheees では既存プロダクト改善向けに、1〜4週間の「開発診断」で依存ライブラリの状況を含めた現状確認と移行方針をご提示するほか、継続的な改善支援も行っています。お問い合わせフォームからお気軽にご相談ください。