Vue.jsとは?リアクティビティという中心概念から、Composition API・Vue 2のサポート終了・Nuxtまで技術選定に関わる人向けに解説【2026年版】

「提案書に『フロントエンドはVue.js 3で構築します』とあるのですが、これは何を意味するのでしょうか」——サイトや業務システムのリニューアルを検討している方から、こうした相談をよく受けます。3社のうち1社はVue、1社はReact、1社はいまのまま改修。金額は倍近く違うのに、その差が技術の違いなのかが分かりません。

結論から言うと、Vue.jsとは、標準のHTML・CSS・JavaScriptの上に立ち、画面(ユーザーインターフェース)を組み立てるためのJavaScriptフレームワークです。公式ドキュメントはこれを「宣言的でコンポーネントベースのプログラミングモデルを提供する」と説明しています。中心にあるのはリアクティビティという仕組みで、ひとことで言えばデータが変われば画面がひとりでに追いかけるということ。人が手でHTMLを書き換えていた作業を、Vueに渡すための道具だと理解すれば十分です。

そしてここが大事なところですが、Vueはバージョンとセットで見てください。Vue 2は2023年12月31日に公式のサポートを終えています(Vue.js公式ブログ、2023年12月15日公開)。終了したのは機能ではなく、公式からの修正です。いま動いているシステムがVue 2で作られているなら、脆弱性が見つかっても公式の修正は出ません。この一点だけで、リニューアルの優先順位は変わります。

本記事では、定義とリアクティビティ、単一ファイルコンポーネントと2つの書き方(Options APIとComposition API)、Vue 2とVue 3の違い、Vue Router・Pinia・Vite・Nuxtというエコシステムの範囲、ReactやAngularとの立ち位置の違いと出典のある採用シェア、選ぶべきケース・避けるべきケースと外部チームでの保守体制の順に解説します。SPA(シングルページアプリケーション)の仕組みやSEO、フロントエンドとバックエンドの役割分担、開発会社の選び方は扱わず、既存の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンで約100社の開発体制を支援してきました。当社はVue.jsでの開発実績があり、他社が作ったVueのコードを引き継いで保守することもあります。日本語の記事によく見る「大規模開発には向かない」「日本で人気」といった通説は、そのまま繰り返しません。vuejs.org の公式ドキュメントと公式ブログ、出典を示せる調査だけを根拠にし、確認できなかったことは「確認できなかった」と書きます(確認日はいずれも2026年9月16日)。

Vue.jsとは——画面を組み立てるJavaScriptフレームワーク。手でHTMLを書き換える作業をやめるための道具

Vue.jsとは、Webサイトやアプリの画面(ユーザーインターフェース)を組み立てるためのJavaScriptフレームワークです。読み方は「ビュー」。何かを新しく発明した道具ではなく、これまで人が手作業で書いていた処理のうち、決まりきった一部分を引き受けてくれる道具、と考えると輪郭がつかめます。ここではまず公式の定義を確認し、そのうえで中心にあるリアクティビティという仕組みを、業務の言葉に翻訳します。

公式の定義——「標準のHTML・CSS・JavaScriptの上に立つ、UIを構築するためのフレームワーク」

vuejs.org の公式ドキュメント「Introduction」は、Vueを次のように定義しています(確認日 2026-09-16)。ユーザーインターフェースを構築するためのJavaScriptフレームワークであり、標準的なHTML・CSS・JavaScriptの上に構築されていて、宣言的でコンポーネントベースのプログラミングモデルを提供する、というものです。

この定義文には、判断に効く情報が3つ入っています。

1つ目は「標準的なHTML・CSS・JavaScriptの上に構築されている」という点。Vueのテンプレートは、見た目がほぼHTMLです。独自の言語を新しく覚えるのではなく、HTMLに書き足していく形で使えます。あとで触れる「学習コストが低い」という評価は、感想ではなく、この設計方針から来ています。

2つ目は「宣言的」という点。「こういうデータのときは、こういう表示になる」と結果の形を書いておけば、そこへ至る手順はVueが引き受けます。手順を一つずつ書く(命令的な)書き方との違いが、次の項の話です。

3つ目は「コンポーネントベース」という点。画面を部品(コンポーネント)に分けて組み立てます。ヘッダー、検索ボックス、一覧表、といった単位で作り、それを組み合わせて1つの画面にする。同じ部品を別の画面でも使い回せます。

なお、VueはMITライセンスのオープンソースソフトウェアです。特定の企業が所有しているのではなく、独立したコミュニティ主導のプロジェクトとして運営され、資金はスポンサーシップでまかなわれている、と公式FAQに書かれています。ライセンス料は発生しません。

中心概念はリアクティビティ——データが変わると画面が自動で追いかける

Vueを一言で説明しろと言われたら、私は「データと画面を同期させ続ける仕組み」と答えます。公式ドキュメントはこれをリアクティビティと呼び、宣言的レンダリングと並ぶ2つのコア機能の一つとして挙げています。

たとえば、買い物かごの中身が3点から4点に増えたとします。従来のやり方では、次の手順を人が書いていました。

表の最終行が、この仕組みのいちばんの価値です。手作業で画面を書き換える方式では、データは正しいのに画面だけ古いという不具合が起きます。表示箇所が増えるほど、直し忘れの確率も上がります。Vueはこの種の不具合を構造的に潰します。

仕組みは公式ドキュメント「Reactivity Fundamentals」に説明があります。JavaScriptには、ふつうの変数が読み書きされたことを検知する標準の方法がありません。そこでVueは、値を ref() という関数で包み、.value というプロパティ越しに読み書きさせます。こうするとゲッターとセッターを通じて、追跡(track)——コンポーネントが最初に描画されるとき、使われた値をすべて記録する——と、トリガー(trigger)——値が変わったとき、それを使っていたコンポーネントを描き直す——の2段階が実現できる、という設計です。オブジェクトをまるごとリアクティブにする reactive() という関数もあり、こちらはJavaScriptのProxyを使ってプロパティへのアクセスと変更を横取りします。

もう1点、実務的に重要な性質があります。画面の更新は値を変えた瞬間に同期的に起きるのではなく、Vueが次の更新サイクルまでまとめて保留します。1回の処理で状態を10か所変えても、コンポーネントの描き直しは1回で済む、ということ。表示件数の多い一覧画面で効いてきます。

なお、Vueの説明で「仮想DOM」という語を見かけますが、これは画面の書き換えを効率よく行うための内部の実装です。発注側が判断に使う情報ではないので、「更新を速くするための内部の工夫」と押さえておけば足ります。また、Vue 2の時代によく語られた「双方向データバインディング」は、入力欄の値とデータを双方向に結びつける書き方(v-model)を指します。これは中心概念ではなく、リアクティビティの応用の一つです。

「使い方を選べる」フレームワーク——CDNで1行から、既存ページの一部にも載せられる

公式ドキュメントはVueを「プログレッシブフレームワーク」と呼びます。理由は、使い方を用途に応じて選べるからです。公式ページ「Ways of Using Vue」が挙げている使い方は6つあり、発注判断に効くのは最初の2つです。

1つ目がスタンドアロンスクリプト。 ビルドの仕組み(Node.jsやビルドツール)を一切用意せず、CDNから1本のスクリプトを読み込むだけで使えます。公式は、バックエンド側がすでにHTMLを出力している場合や、フロントエンドのロジックが複雑でない場合に最適だと書いており、jQueryのより宣言的な置き換えとして機能する、と説明しています。既存ページの一部だけをVueにする、という導入ができるわけです。

これは、当社に寄せられる相談の多くにとって現実的な選択肢です。「既存のサイトを全部作り直さないと新しい技術は使えない」と思い込んでいる方が少なくありませんが、Vueに関してはそうではありません。たとえば、いまあるページの中で「検索条件を変えるたびに一覧が絞り込まれる」部分だけをVueで書く、という使い方ができます。

2つ目がWebコンポーネントとしての埋め込み。 Vueで標準のWebコンポーネントを作り、他のフレームワークで作られた画面や、古いアプリケーション、静的なHTMLの中に埋め込めます。

残る4つは、単一ページアプリケーション(SPA)、サーバーサイドレンダリングを伴うフルスタック構成、静的サイト生成(SSG)、そしてWeb以外(Electronによるデスクトップ、Ionic Vueによるモバイル、TresJSによる3D表現など)です。このうちSPAの仕組みやレンダリング方式の選び分けは本記事では扱いません。別途「SPA開発」の記事に譲ります。ここでは「Vueは1行から全部まで、同じ道具のまま守備範囲を広げられる」という性格だけ押さえてください。

サイズも公式FAQに数字があります。最小構成でおよそ16kb(minify+brotli圧縮)、全機能を使っても約27kb、ビルドツールを使わない場合で約41kb。既存ページに載せるときに、読み込みが目立って重くなる規模ではありません。

道具の性格は、ここまででつかめたはずです。では、実際にどう書くのか。次は、Vueのコードが取る形を見ていきます。

Vue.jsの書き方——単一ファイルコンポーネントと、Options API / Composition API

Vueのコードを見たとき、押さえる形は2つだけです。1つはコードを入れる器である単一ファイルコンポーネント、もう1つはその中身の書き方です。そして中身の書き方には2つの流儀があり、この2つが混ざったまま人が入れ替わることが、引き継ぎで最も時間を食う原因になります。非エンジニアの方も、ここは読み飛ばさないでください。見積もりを読むときに効きます。

単一ファイルコンポーネント(.vue)——テンプレート・ロジック・スタイルを1つのファイルにまとめる

ビルドツールを使うVueのプロジェクトでは、*.vue という拡張子のファイルを使います。これを単一ファイルコンポーネント(Single-File Component、略してSFC)と呼びます。公式ドキュメントの説明は、コンポーネントのロジック(JavaScript)、テンプレート(HTML)、スタイル(CSS)を1つのファイルにカプセル化するもの、というものです。

中身は3つのブロックに分かれます。

実務で効くのは3行目の scoped です。CSSがそのコンポーネントの中にしか効かなくなるため、別の画面の見た目を壊す事故が起きにくくなります。既存サイトの改修で「1か所直したら別のページが崩れた」という経験がある方には、この一点だけでも価値が分かるはずです。

ファイルが機能単位で分かれる、という性質も見逃せません。コードレビューのとき、変更が 商品一覧.vue の中で完結しているのか、複数のファイルにまたがっているのかが一目で分かります。当社では他社が作ったコードを引き継ぐこともありますが、SFCで分かれているプロジェクトは、読み解きの初速がまるで違うのが実情です。

Options API と Composition API——2つの書き方と、公式が示す使い分け

Vueには、コンポーネントの中身を書く方法が2つあります。公式ドキュメントはこれを「2つのAPIスタイル」として並記しており、どちらかが非推奨というわけではありません。

Options APIは、data(データ)、methods(処理)、mounted(画面に出たときの処理)といった決まった名前のオプションを、1つのオブジェクトの中に並べて書く方式です。どこに何を書くかが最初から決まっているため、初めて見る人でも構造をたどりやすいという性質があります。Vue 2から続く書き方です。

Composition APIは、必要な機能(ref、onMounted など)をインポートして、処理の流れの順に書いていく方式です。単一ファイルコンポーネントの中では <script setup> という書き方と組み合わせて使うのが一般的です。関連する処理をひとまとまりに書けるため、1つのコンポーネントが複雑になったときに、機能ごとにコードをまとめておけるという利点があります。同じロジックを複数のコンポーネントで使い回すときにも、こちらが向きます。

公式ドキュメントが示している使い分けは明快です。

つまり、「既存サイトの一部をVueにする」ならOptions API、「これから業務システムを一式作る」ならComposition APIとSFCの組み合わせ、という整理になります。公式ドキュメントは両方の書き方を併記しており、読者はいつでも切り替えられるようになっています。

型の扱いについても触れておきます。VueはJavaScriptとTypeScriptの両方をサポートしており、どちらかを強制しません。TypeScriptで書く場合は、エディタ拡張(Vue - Official)が <script lang="ts"> の型チェックに対応し、コマンドラインでは vue-tsc で型チェックと型定義ファイルの生成ができます。人数が増えるプロジェクトでは、型があるほうが引き継ぎの事故が減ります。

発注側にとっての意味——書き方が混ざったコードは、引き継ぎのたびに読み替えが発生する

ここまでを、発注側の言葉に翻訳します。2つの書き方があるということは、プロジェクトの中で書き方が混ざりうるということです。そして実際、混ざります。Vue 2から移行したプロジェクトにOptions APIが残り、新しく足した画面はComposition APIで書かれている。担当者が替わるたびに、その人の得意な書き方で足される。こうして、1つのプロジェクトの中に2つの流儀が並びます。

技術的には両方動きます。問題は、読む人のコストです。引き継いだエンジニアは、ファイルを開くたびにどちらの流儀かを判定してから読むことになります。当社が他社のコードを引き継ぐとき、見積もりの読み解き工数がふくらむ原因の上位がこれです。

対策は難しくありません。プロジェクトの最初に「どちらで書くか」を決め、文書に残す。それだけです。決めていない規約は、人が入れ替わった日には決められません。開発会社に依頼するなら、提案の段階で「Options APIとComposition APIのどちらで書きますか。混在させない運用にできますか」と聞いてください。この質問に即答できる会社は、コードレビューの運用も持っています。当社の場合は、日本人PMの設計レビューとGitのプルリクエストによるコードレビューを標準の工程に入れており、書き方の逸脱はレビューの段階で止めます。プルリクエストの仕組みそのものは「GitHubとは」の記事にまとめてあります。

いま動いているあなたのプロジェクトで、その規約は誰が決めていますか。

Vue 2とVue 3——Vue 2は2023年12月31日にサポート終了。既存システムで確認すること

ここが、本記事でいちばん実害に近い章です。日本語の「Vue.jsとは」記事の多くは、この話を書いていません。書いていても日付がありません。バージョンは機能の新旧ではなく、公式からの修正が届くかどうかの話です。動いているシステムほど「動いているから」という理由で放置され、期限が過ぎたことに誰も気づきません。以下はすべて、vuejs.org の公式ブログと公式FAQで確認した日付です(確認日 2026-09-16)。

時系列で押さえる——Vue 3.0(2020年9月)、Vue 2.7(2022年7月)、Vue 2のEOL(2023年12月31日)

2026年9月16日時点で、npmレジストリが返す vue の最新版は 3.5.42 でした。つまり、いま新しく作るなら Vue 3 系の一択です。なお公式FAQは、Vue 3 の利点として、バンドルサイズがより小さいこと、パフォーマンスが向上していること、TypeScript対応が強化されていることを挙げています。

公式FAQの記述によれば、Vue 2.7 が最終のマイナーリリースで、そのあとの18か月間はセキュリティアップデートのみが提供され、2023年12月31日に End of Life を迎えました。

「サポート終了」が意味すること——機能が止まるのではなく、公式からの修正が出なくなる

ここを誤解している方が多いので、はっきり書きます。サポート終了の日に、動いているVue 2のシステムが止まるわけではありません。 昨日まで動いていたものは、今日も動きます。

終わったのは、次のことです。

1. 新しく見つかった脆弱性に対する公式の修正が出ない。 Vue 2本体に問題が見つかっても、公式から修正版はリリースされません
2. 新機能もバグ修正も追加されない。 挙動のおかしいところは、自分たちで回避策を書くしかありません
3. 周辺のライブラリが順次Vue 2対応をやめていく。 本体が終わっている以上、周辺も追随します。依存ライブラリの更新が詰まり、Node.jsやビルドツールを新しくできなくなります

この3つ目が、実務ではいちばん効きます。当社に寄せられる相談で多いのが、「数年前に作った管理画面がVue 2のままで、当時の開発会社とは契約が切れている。依存ライブラリの脆弱性警告が出たが、どう直せばよいか分からない」という状態です。本体が古いままだと、周辺だけを新しくすることもできません。

なお、公式の延長サポートはありませんが、公式ブログは HeroDevs 社と提携した「Never-Ending Support(NES)」に言及しています。End of Life 後も継続的な更新とセキュリティパッチが提供される有償の仕組みです。移行までの時間を買う選択肢として存在は知っておくとよいですが、あくまで時間を買うものであり、移行しなくてよいという意味ではありません。

既存システムで確認する4点と、取れる3つの選択肢

いま動いているシステムがVueで作られているなら、開発会社か社内のエンジニアに次の4点を聞いてください。技術的な知識がなくても質問できます。

1. Vueのバージョンは2系か3系か。 3系なら、細かい版(3.x)も聞く
2. Vue 2なら、HeroDevsの延長サポートを契約しているか。 していないなら、公式の修正は届いていない状態
3. 状態管理にVuexを使っているか、Piniaを使っているか。 Vuexならメンテナンスモードのものを使っている(次章で説明します)
4. ビルドは Vite か、Vue CLI(webpack)か。 Vue CLI もメンテナンスモードです

4点の答えが揃えば、取れる選択肢は3つに絞られます。

選択肢1: Vue 3へ移行する。 公式にマイグレーションガイドがあります。画面の作り直しではなく、書き方の置き換えが中心です。規模とコードの状態によって工数は大きく変わるため、まずコードを読ませたうえで見積もりを取ってください。「何画面あるか」だけでは金額は出ません。

選択肢2: 延長サポートを買って時間を確保する。 移行の予算や人手がすぐ用意できない場合の橋渡しです。同時に移行計画の期限を決めてください。期限のない橋渡しは、そのまま数年が過ぎます。

選択肢3: 作り直す。 機能追加の予定が多い、いまのコードを読める人が誰もいない、設計そのものが現在の業務に合っていない——このどれかに当てはまるなら、移行より作り直しのほうが安く済むことがあります。既存システムを止めずに置き換える進め方は「レガシーシステム 刷新 外注」の記事にまとめてあります。

放置した場合に起きることを、3つだけ挙げて締めます。脆弱性警告が出たまま止まり、対応できる人が見つからない。周辺ライブラリの更新が詰まり、新機能の追加そのものができなくなる。そして最後に、引き継げる技術者が市場からいなくなります。3つとも、期限の過ぎた日から少しずつ進みます。

Vueのエコシステム——Vue Router、Pinia、Vite、Nuxt。どこまでが公式か

提案書には、Vue以外の名前も並びます。Vue Router、Pinia、Vite、Nuxt。日本語の記事にはよく「Vueはプラグインやライブラリの数が少ない」と書かれていますが、その数を数えた調査は示されていません。発注判断に効くのは数ではなく、どこまでをコアチームが維持しているかです。公式が維持しているものは、本体のバージョンアップに追随する前提で作られています。追随の保証がある部品と、ない部品を見分けられれば十分です。

コアチームが維持しているもの——Vue Router、Pinia、Vite、create-vue、エディタ拡張

公式ドキュメントで確認できる範囲を整理します(確認日 2026-09-16)。

数えると、公式が面倒を見ている部品は10個前後です。「少ない」のではなく、必要なところは公式が押さえたうえで、残りは選べるようになっているという設計だと理解してください。

発注の場でこの表が効くのは2か所です。1つは Vuex か Pinia か。Vuexならメンテナンスモードの部品を使っていることになります。すぐ壊れるわけではありませんが、新しく作るのにVuexを選ぶ提案が来たら、理由を聞いてください。もう1つは Vue CLI か Vite か。Vue CLIもメンテナンスモードです。ここが新しいかどうかで、ビルドの待ち時間と、将来のアップグレードのしやすさが変わります。前章の「確認する4点」のうち2点が、この表に対応しています。

Nuxt——Vueの上に立つフルスタックフレームワーク

Nuxt は、Vueを土台にしたフレームワークです。公式サイト(nuxt.com)は自らを「The Full-Stack Vue Framework」と称し、「Build fast, production-ready web apps with Vue」と説明しています(確認日 2026-09-16)。Vueが画面の部品を組み立てる道具だとすると、Nuxtはその上に、アプリケーションとして必要な周辺の仕組みをひとまとめに載せたもの、という関係です。

公式ドキュメントが挙げている機能は、設定不要で始められること、レンダリング方式をページ単位で選べること、ファイルを置くだけで画面の住所が決まるファイルベースのルーティング、データ取得、エラー処理、画面遷移のアニメーション、画像やフォントの最適化、SEO関連の対応、200以上のモジュールによる拡張、そしてページ表示前に処理を挟むミドルウェアです。

発注側の言葉にすると、Nuxtを使うかどうかは「自前で組み立てるか、揃っているものを使うか」の選択です。Vueだけで作る場合、ルーティングも状態管理もビルド設定も自分たちで組み合わせます。Nuxtはそこが最初から組まれています。反面、Nuxtの流儀に沿うことになるため、独自の構成を取りたい場合は窮屈になります。

レンダリング方式(サーバー側で描くか、ブラウザ側で描くか、事前に静的なHTMLを作っておくか)の選び分けは、本記事では扱いません。 別途「SPA開発」の記事に譲ります。ここでは「Nuxtを使うと、その選択がページ単位でできるようになる」という位置づけだけ押さえてください。なお、記事や商品情報などの中身を別のシステムで管理してVueやNuxtで表示する構成もよく取られます。中身の管理側については「microCMSとは」の記事が参考になります。

サービスを複数の実行単位に分ける構造の話(マイクロサービス)は、Vueの選択とは別レイヤーです。こちらは「マイクロサービスとは」の記事にまとめてあります。

日本語の公式ドキュメント(ja.vuejs.org)が公式の翻訳体制で維持されている

学習を始めたい方に効く事実を1つ。Vueの公式ドキュメントには日本語版があります。 URLは ja.vuejs.org で、翻訳は vuejs-translations/docs-ja というリポジトリで管理されています。公式サイトの「Translations」ページに、正式に管理されている翻訳の一覧として掲載されています(確認日 2026-09-16)。

同じ体制で管理されている言語は、簡体字中国語、日本語、ウクライナ語、フランス語、ドイツ語、韓国語、ポルトガル語、ベンガル語、イタリア語、ペルシア語、ロシア語、チェコ語、繁体字中国語、ポーランド語の14言語(2026-09-16時点)。アラビア語とスペイン語は作業中とされています。

これは「日本で人気だから日本語版がある」という話ではありません。因果は確認できません。確認できるのは、日本語で公式の一次情報を読める状態が、公式の翻訳体制として維持されているという事実だけです。学習の入り口としても、発注後に自社で仕様を確認するときにも、ここが起点になります。翻訳は原文の改訂に追随中のものもあるため、迷ったら英語版と突き合わせてください。

ReactやAngularとの立ち位置の違いと、採用シェアの見方

「VueとReact、どちらがよいですか」は、当社が最もよく受ける質問の一つです。先に結論を書くと、この問いに一般解はありません。3つの道具は解こうとしている問題がほぼ同じで、違うのは設計思想と、公式がどこまで面倒を見るかの範囲です。ここでは立ち位置の違いを表で整理したうえで、シェアの数字を「出典つきで」提示します。出典を示せない数字は使いません。

3つの立ち位置の違い——比較表(何を標準で持つか、テンプレートの書き方、公式の範囲)

表の1行目と3行目が、実務上の分かれ目です。Vueは「公式が用意しているが、使うかどうかは選べる」という中間の立ち位置にいます。Reactは本体の守備範囲が狭く、周辺の組み合わせを自分たちで決めます。Angularは最初から全部入りで、決まったやり方に沿って作ります。

もう1つ、2行目のテンプレート構文の違いも効きます。Vueのテンプレートは見た目がほぼHTMLなので、HTMLとCSSを触ってきたWeb制作寄りの人が読める。ReactのJSXは、JavaScriptが読めないと画面の構造が追えません。社内に誰が残るかで、この差が効いてきます。

なお、公式FAQはパフォーマンスについて、js-framework-benchmark を根拠にReactやAngularを上回ると書いています。ただし、この種のベンチマークは実際のアプリケーションの体感とは別物です。性能を理由に選ぶ場面は、実務ではほとんどありません。

採用シェアは出典で見る——Stack Overflow Developer Survey 2025 の数字と、その読み方

ここから数字の話です。日本語の記事には「日本で人気」「シェアが高い」といった記述が頻出しますが、私が2026年9月16日に調べた範囲では、国別のフレームワーク採用率を示せる一次調査は見つけられませんでした。 したがって本記事では「日本で人気」とは書きません。

出典を示せるのは、Stack Overflow が毎年公開している開発者調査です。Stack Overflow Developer Survey 2025 の Technology セクション、「過去1年間に実務で多く使ったWebフレームワーク・技術」という設問の、全回答者ベースの数値は次のとおりでした(確認日 2026-09-16)。

この数字を使うときは、必ず次の3点をセットで伝えてください。

1. 回答者数は 23,678 人(この設問の回答率48.3%)。世界全体の開発者を代表する標本ではありません
2. 自己選択式(self-selected)の調査です。 Stack Overflow という特定のコミュニティを見ている人が自分の意思で回答しています。回答者の偏りは避けられません
3. 国別の内訳は公開されていません。 したがって「日本では」という主張には使えません

そのうえで読み取れることは、こうです。ReactとVueには2.5倍前後の開きがあり、VueはAngularとほぼ同じ水準にいる。 つまりVueは、最大勢力ではないが、主要な選択肢の一つとして継続的に使われている、という位置づけです。「廃れた技術」でもなければ「最も多い技術」でもありません。

採用組織についても、出典のある事実だけ書きます。Vue公式FAQは、150万人以上のユーザーと月間1,000万件のダウンロードがあるとしたうえで、採用組織として Wikimedia Foundation、NASA、Apple、Google、Microsoft、GitLab、Zoom などを挙げています。これらは公式が自ら公開している一覧であり、第三者の監査を受けた数字ではありません。 それでも、後述する「大規模開発には向かない」という通説を検証する材料にはなります。

発注側にとって、シェアの数字は順位表ではなく人の集めやすさの目安です。17.6%という数字は、「Vueを書ける人が市場にいないわけではないが、Reactほど豊富ではない」と翻訳するのが正確です。

学習コストが低いと言われる理由——「標準のHTML/CSS/JSの上に立つ」という設計から説明する

「Vueは学習コストが低い」もよく見る記述です。これは感想ではなく、設計から説明できます。公式の定義文にあるとおり、Vueは標準的なHTML・CSS・JavaScriptの上に構築されています。テンプレートはHTMLの形をしており、スタイルはCSSそのもの。新しい言語や記法を先に覚える必要がありません。

さらに、前章で見たとおり、ビルドツールなしでCDNから1行読み込むだけでも動きます。環境構築で挫折する率が下がる、という意味で入り口が低い。そして公式ドキュメントに日本語版があります。

ただし、入り口が低いことと、実務で通用する水準に達することは別です。 Composition API、状態管理、型、ビルド設定、テストまで含めれば、必要な知識量はReactと大差ありません。「最初の1週間が楽」であって、「半年後が楽」ではない、と理解してください。学習の順番としては、Vue 3・Composition API・Vite の組み合わせから始めるのが、いま新しく作るときの標準形です。教材を買う前に、バージョン表記を必ず確認してください。

Vue.jsを選ぶべきケース・避けるべきケースと、Vueで作ったものを外部チームで保守する体制

ここまでの内容を、判断の形にまとめます。そのうえで、この記事を読んでいる方の多くが最後に行き着く問い——「作ったあと、誰が触り続けるのか」——に答えます。フレームワークの選択で実際に痛むのは、技術の優劣ではありません。人が入れ替わったあとの読み替えコストです。当社はVue.jsでの開発実績があり、他社が作ったVueのコードを引き継いで保守することもあります。その立場から、正直な線引きを書きます。

選ぶべきケース4つ・避けるべきケース4つ——判断表

画面を作らずに済ませる選択肢もあります。管理画面や社内ツールなら、ノーコードツールで足りることがあります。判断の軸は「ノーコードとは」の記事にまとめてあります。また、画面側とサーバー側で見積もりがどう分かれるかは「フロントエンドとバックエンドの違い」の記事を参照してください。

「大規模に向かない」という通説を検証する——分かれ目は規模ではなく、書き方を統一できるかどうか

日本語の「Vue.jsとは」記事の多くが「大規模開発には向かない」と書いています。しかし、その根拠を示している記事を私は見つけられませんでした。 調査名も、規模の定義も、比較対象も書かれていません。

一方、前章で見たとおり、Vue公式FAQは採用組織として Wikimedia Foundation、NASA、Apple、Google、Microsoft、GitLab、Zoom を挙げています。公式の自己申告であるという留保はつきますが、少なくとも「規模が大きいから使えない」という説明とは整合しません。

では、なぜこの通説が生まれたのか。私の見立てはこうです。Vueは書き方の自由度が高く、公式の部品も「用意されているが強制はされない」という立ち位置にあります。Angularのように最初から決まったやり方に縛られる設計ではありません。その自由度は、人数が増えたときに規約がないと散らかるという形で表面化します。散らかったコードを見た人が「大規模に向かない」と言う。そういう順序ではないかと考えています。

だとすると、分かれ目は規模ではなく統制です。Options APIかComposition APIか、状態管理はPiniaか、ディレクトリ構成はどうするか、レビューは誰がどこで通すか。この4つを最初に決めて文書に残せるなら、人数が増えても崩れません。 決めていない規約は、人が入れ替わった日には決められない。これが私の持論です。

Vueで作ったものを外部チームで保守するときの体制——当社の位置づけと、引き継ぎで最初に見る4点

Vueで作ったものを他社のチームに引き継ぐ、あるいは外部チームで保守し続ける。この形は年々増えています。当社が他社製のVueプロジェクトを引き継ぐとき、機能の前に見るのは次の4点です。

1. Vueのバージョン(2系か3系か、3系なら何系か)
2. APIスタイルの混在(Options APIとComposition APIが混ざっていないか、混ざっているなら割合)
3. 状態管理(VuexかPiniaか、そもそも状態管理を使っているか)
4. ビルド環境(ViteかVue CLIか、ローカルで動く状態か)

この4点が揃っていないコードは、機能追加より先に読み解きの時間がかかるのが実情です。見積もりを取るときは、「何画面あるか」ではなくこの4点を伝えたうえで概算を出してもらってください。画面数だけの見積もりは、あとで必ずずれます。

当社はベトナム・ホーチミンを拠点に、日本人PMをフロントに置いたラボ型(準委任)の開発チームを提供しています。体制は2パターンで、日本人PM/ブリッジSE+エンジニアの構成(パターンA・推奨)と、エンジニアのみの構成(パターンB)。1名から、最短2週間で開始でき、増員は約1週間、縮小・交代は1か月単位です。グループで2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)を持ち、そこから直接アサインします。協力会社や紹介を経由しないため、仲介マージンは発生しません。

品質は仕組みで担保します。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点です。前述の「書き方の統一」は、このレビュー工程で守ります。規約から外れた書き方はマージ前に止まるため、人が入れ替わっても散らかりません。時差は2時間で、日本の午前が現地の早朝にかかりません。仕様の確認がその日のうちに返ります。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

費用の目安も公開しています。実務3年目安のエンジニアで 1,500USD(約22.5万円 / 1USD=150円換算目安)、5年で 2,000USD、10年クラスおよびブリッジSEで 3,000USD。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。当社調べで市場相場の約1/2にあたります。開発実績としては、介護記録SaaS「CareViewer」(日本語対応のブリッジSE1名+フルスタック2名。週次で優先順位を判断する体制で、コストは従来の半分以下)、Stripeを使った決済アプリ(二要素認証・ウォレット・PDF出力。新規開発から週次の保守へ移行)などがあります。

向かない案件も書いておきます。画面が数枚で今後の変更予定がない案件、仕様を一度も文書にしないまま口頭だけで進めたい案件、日本側に意思決定できる担当者を置けない案件。この3つは、ラボ型の良さが出ません。継続的に手を動かす前提の体制なので、作り切って終わる案件は請負のほうが合います。保守の範囲と費用の考え方は「システム改修 保守 外注」の記事に、委託先を替えるときの引き継ぎ手順は「開発会社 乗り換え 引き継ぎ」の記事にまとめてあります。開発会社の評価軸そのものは「システム開発会社 選び方」の記事をご覧ください。

これから開発を発注する方へ。提案書にVueと書かれていたら、聞くべきことは4つです。バージョンは3系か。Options APIとComposition APIのどちらで統一するか。状態管理はPiniaか。納品後、誰がこのコードを触り続けるのか。4つ目に即答できない相手とは、その先の話をしないほうが安全です。当社は、合わない案件にはその旨を率直にお伝えしています。

【FAQ】Vue.jsに関するよくある質問

Vue.jsについて、当社の相談窓口に実際に届く質問のうち、本文で扱いきれなかったものを5つ取り上げます。いずれも回答の根拠は vuejs.org の公式ドキュメント・公式ブログ、および Stack Overflow Developer Survey 2025 です(確認日 2026-09-16)。

Q1. ReactとVue.jsは、どちらを選ぶべきですか

一般解はありません。判断材料は2つです。1つは、社内や委託先に続けて触れる人を確保できるか。Stack Overflow Developer Survey 2025(全回答者ベース、n=23,678、自己選択式)では React 44.7% に対して Vue.js 17.6% で、書ける人の絶対数には開きがあります。もう1つは、社内に残るのがHTML・CSS寄りの人かどうか。Vueのテンプレートはほぼ HTML なので、Web制作寄りの人でも構造を追えます。性能で選ぶ場面は実務ではほとんどありません。

Q2. Vue 2で作ったシステムを、このまま運用し続けてよいですか

推奨できません。Vue 2 は 2023年12月31日に公式サポートを終了しており、新しく見つかった脆弱性に対する公式の修正は出ません。すぐ止まるわけではありませんが、周辺ライブラリの更新が順次詰まり、やがて機能追加そのものができなくなります。移行の予算がすぐ取れない場合は、HeroDevs の Never-Ending Support(有償の延長サポート)で時間を買う選択肢がありますが、移行の期限を同時に決めてください。期限のない橋渡しは、そのまま数年が過ぎます。

Q3. Options API は古い書き方で、覚える必要はありませんか

いいえ。公式ドキュメントは2つのAPIスタイルを併記しており、Options API を非推奨とはしていません。公式が示す使い分けは、ビルドツールを使わない場合や複雑度が低い場合は Options API、Vueでアプリケーション全体を構築する場合は Composition API と単一ファイルコンポーネントの組み合わせ、というものです。既存のコードを引き継ぐ立場なら、両方読めたほうが有利です。

Q4. Nuxt は必ず使ったほうがよいですか

必須ではありません。Nuxt は Vue の上に、ルーティング・データ取得・レンダリング方式の切り替え・SEO対応などをまとめて載せたフルスタックのフレームワークです。自前で組み合わせる手間が減る代わりに、Nuxt の流儀に沿うことになります。既存ページの一部をVueにするだけなら不要ですし、アプリケーションを一式作るなら検討に値します。使う・使わないは提案の段階で理由を聞いてください。

Q5. Vue.js を書ける技術者は採用・確保できますか

できます。ただしReactより母数が小さい前提で計画を立ててください。当社の場合、グループで2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしており、1名から、最短2週間で開始、増員は約1週間です。費用の目安は実務3年目安で1,500USD(約22.5万円 / 1USD=150円換算目安)、最小構成は日本人PMフロント+2〜3人月で月額約80万円から。社内採用と外部チームのどちらで持つかは、変更の頻度と、5年後も触り続ける必要があるかどうかによる判断。

まとめ: Vue.jsは画面を組み立てる道具——判断の軸はバージョンと書き方の統一、そして続けて触れる人

Vue.jsとは、標準のHTML・CSS・JavaScriptの上に立ち、画面を組み立てるためのJavaScriptフレームワークです。中心にあるのはリアクティビティで、データが変われば、それを表示しているすべての場所が自動で追いかけます。人が手でHTMLを書き換えていた作業を、まるごとVueに渡す。これが本質です。使い方は段階的に選べます。CDNから1行読み込んで既存ページの一部だけを動かすこともできれば、アプリケーションを一式作ることもできる。既存のサイトを全部作り直さないと新しい技術は使えない、という思い込みは捨ててください。

書き方で押さえるのは2つ。単一ファイルコンポーネント(.vue)という器と、その中身の流儀であるOptions APIとComposition APIです。公式が示す使い分けは、ビルドなし・低複雑度ならOptions API、アプリケーション全体を作るならComposition APIと単一ファイルコンポーネント。そしてバージョンは必ず確認してください。Vue 2は2023年12月31日に公式サポートを終えており、いまVue 2で動いているシステムには公式の修正が届きません。最新版は2026年9月16日時点で3.5.42です。エコシステムは数ではなく、どこまでが公式かで見ます。Vue Router、Pinia、Vite、create-vueが公式側。VuexとVue CLIはメンテナンスモードです。

採用シェアについては、出典のある数字だけを使ってください。Stack Overflow Developer Survey 2025(全回答者ベース、n=23,678、自己選択式、国別内訳なし)で Vue.js は17.6%、React は44.7%、Angular は18.2%。「日本で人気」という記述を裏づける一次調査は、本記事の調査時点では見つけられませんでした。「大規模に向かない」という通説も、根拠を示した記事は見当たりません。分かれ目は規模ではなく、書き方を統一する規約を最初に決めて文書に残せるかどうかです。古いバージョンからの移行はレガシーシステム刷新の外注に、委託先を替えるときの引き継ぎは開発会社の乗り換えと引き継ぎにまとめてあります。当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しています。日本人PMの設計レビューとGitのプルリクエストによるコードレビューで、書き方の逸脱はマージ前に止めます。1名・最短2週間から、最小構成は月額約80万円です。現在の体制と要件をお聞かせいただければ、Vueで進めるべきかどうかの判断も含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。