Laravel使いが2026年のVue.jsを調べ直した — Vapor Mode、Inertia v3、そしてReactとの距離感
はじめに
普段はLaravel + Reactで書いているのですが、案件でVueを選ぶ機会があり「そういえば今のVueってどうなってるんだっけ？」となったので、2026年7月時点の状況を調べ直しました。
結論から言うと、Vueは「3.6 RC = Vapor Mode完成待ち」という節目にいます。既存のReactスタックを慌てて捨てる理由はないけれど、Vueを選ぶ理由は2026年になってかなり増えた、という温度感です。
対象読者は以下を想定しています。
- Laravel + Inertiaで開発している人
- Vue 3を触っているが、3.6/Vapor Modeの話をちゃんと追えていない人
- ReactとVueのどちらを選ぶか迷っている人
TL;DR
| トピック | 2026年7月時点の状況 |
|---|---|
| Vue安定版 | 3.5.40 |
| Vue 3.6 | RCフェーズ（stableはまだ） |
| Vapor Mode | 3.6 RCで機能完成。Suspenseのみ対象外 |
| リアクティビティ | alien-signalsベースに全面リファクタ |
| ビルド | Vite 8がRolldown（Rust製）をデフォルト採用 |
| 状態管理 | Pinia 3で確定。Pinia Coladaが安定版に |
| Nuxt | 4.5系。Nuxt 5に向けた地ならし中、Nuxt 3は年内EOL |
| Laravel連携 | Inertia v3がstableリリース済み（Axios依存が消えた） |
1. バージョンの現在地：3.6はまだstableではない
まずここを間違えている記事が多いので注意喚起から。
ネット上には「Vue 3.6は2026年初頭にstableリリースされた」と書いている記事がそこそこありますが、2026年7月時点で安定版は3.5.40、3.6は3.6.0-rc.2というRC段階です。alpha → beta → RCと1年以上かけて慎重に進めてきたラインなので、記事の日付とバージョン番号は必ず突き合わせてください。
3.6の内容は大きく2本柱です。
- Vapor Mode — 仮想DOMを使わない新しいコンパイル戦略
-
alien-signalsベースのリアクティビティ刷新 —
@vue/reactivityの大規模リファクタによる性能改善
「Vapor Modeの想定機能セットが完成したのでRCに入る」というのが公式のアナウンス文脈なので、Vapor Modeの完成度が3.6リリースのゲートになっている構図です。
2. Vapor Mode：Vueがコンパイラ側に舵を切った
何をするものか
従来のVueは、テンプレートをrender関数にコンパイルし、実行時に仮想DOMツリーを作って差分を取り、実DOMにパッチを当てていました。静的ホイスティングやパッチフラグといった最適化を積み重ねてきましたが、diff処理自体はユーザーのブラウザのCPUとメモリを使って毎回走るという構造は変わりませんでした。
Vapor Modeはここを根本から変えます。仮想DOMを作らず、コンパイラがVueのリアクティビティシステムに直結した細粒度のDOM操作コードを直接生成する。リアクティブな値が変わったら、それに紐づくDOMノードだけが更新され、ツリーのdiffも再レンダリングごとの調整も発生しません。
SolidJSやSvelteが先行していたアプローチを、Vueの既存のリアクティビティモデルとコンポーネントの書き方のまま持ち込んだ、というのがポイントです。
書き方
オプトインなので、SFC単位で切り替えます。
<!-- 従来モード -->
<script setup>
import { ref } from 'vue'
const count = ref(0)
const increment = () => count.value++
</script>
<template>
<button @click="increment">count is {{ count }}</button>
</template>
<!-- Vapor モード：script setup に vapor 属性を足すだけ -->
<script setup vapor>
import { ref } from 'vue'
const count = ref(0)
const increment = () => count.value++
</script>
<template>
<button @click="increment">count is {{ count }}</button>
</template>
ロジックは1行も変わりません。 これが「Composition APIへの投資は無駄にならない」と言われている理由です。今Composition API + <script setup>で書いておけば、後からファイル単位で属性を足すだけで移行できます。
アプリ全体をVaporでマウントする場合のエントリポイントAPI（createVaporAppなど）や、VaporコンポーネントとVDOMコンポーネントを混在させる際のinterop設定は、RC段階でまだ変わる可能性があります。実装時は公式ドキュメントの最新版を確認してください。
制約：ここが実務では一番大事
Vapor Modeには明確な制約があります。
-
Options APIは非対応。サポートされるのはtemplateのみのSFCと、
<script setup>を使うSFCだけ - Suspenseは対象外。これは仮想DOMとの協調に依存しているアーキテクチャ上の意図的な判断で、単なる未実装ではない
Vue 2からの移行が途中でOptions APIが大量に残っているコードベースは、Vaporの前にComposition API移行という前段が必要になります。逆に言えば、その移行作業は将来のVapor化への投資として二重に効きます。
推奨される使い方
公式が挙げているのは以下の2ケースです。
- 既存アプリの一部 — 性能がシビアな画面だけVapor Modeで実装する
- 小さい新規アプリを丸ごとVapor Modeで作る
**「全面移行」ではなく「重い画面1枚から」**が定石です。オプトインでインクリメンタルに導入できる設計なので、stableが来る前に「自分のコードベースのどこで効きそうか」を当たりだけつけておくのが賢い動き方だと思います。
3. エコシステム：Rust化が完了しつつある
Vite 8 + Rolldown
2026年3月リリースのVite 8で、Rust製バンドラのRolldownが本番ビルドのデフォルトになりました。大規模コードベースで5〜10倍のビルド高速化が報告されています。Rolldown自体も1.0が出てスタンドアロンで使えるようになりました。
Viteは今やVueだけでなくReactを含むフロントエンド全体の基盤なので、Vueを使っていなくても恩恵を受けられる部分です。
Pinia 3
状態管理はPinia一択で確定しました。v3でVue 2サポートを打ち切り、エコシステムがVue 3前提に単純化されています。APIはdefineStoreのままで、state/getters/actionsの書き味も変わっていません。
加えて、Pinia Colada（同じ作者によるデータフェッチ + キャッシュのライブラリ）が初の安定版に到達しました。ReactでいうTanStack Queryのポジションです。サーバー状態とクライアント状態を分けたい場合の選択肢になります。
Nuxt
Nuxt 4.5系が現行で、Vite 8とRspack 2に対応、実験的なSSRストリーミングも入っています。Nuxt 5に向けた地ならし段階で、前提となるNitro v3もbetaに入りました。
注意点として、Nuxt 3は2026年中にEOLを迎えます。Nuxt 3で動いているプロジェクトがあるなら、移行計画は今年中に立てておいたほうがいいです。
4. Laravel視点：Inertia v3がstableになった
ここが個人的には一番実用的な変化でした。Inertia.js v3が2026年3月にstableリリースされています。
主な変更点
Axiosが必須依存から外れた
独自のXHRクライアントに置き換わり、コード変更なしでgzip後約15KB削減されます。qsとlodash-esも除去され、後者はes-toolkitに置換されました。Axiosのインターセプターに依存しているコードがあっても、組み込みクライアントがインターセプターをネイティブサポートしているので移行は比較的スムーズです。どうしても必要ならAxiosはオプショナルなpeer dependencyとして残せます。
useHttpフック
ナビゲーションを伴わない普通のHTTPリクエスト（検索エンドポイントを叩く、外部APIを呼ぶなど）を出すための公式APIが用意されました。今までここだけAxiosを直接使う、みたいな微妙な状態だったので素直に嬉しい。
Optimistic Updates（自動ロールバック付き）
これまで手で実装していたパターンが一級市民になりました。
SSRがVite devモードで動く
npm run dev中に、別のNode.jsサーバープロセスを立ち上げずにSSRが動きます。Viteプラグインが自動で面倒を見てくれる形です。本番のワークフローは従来通りvite build && vite build --ssrのあとphp artisan inertia:start-ssr。
Layout Props
永続レイアウトとページ間の双方向通信に公式の答えが出ました。今までイベントバスやprovide/injectで無理やりやっていたところです。
<script setup>
import { useLayoutProps } from '@inertiajs/vue3'
const { title, showSidebar } = useLayoutProps({
title: 'My App',
showSidebar: true,
})
</script>
ページ側からsetLayoutProps()で更新できます。
前提条件
Laravel 11以上が必要です（現行stableのLaravel 13もサポート対象）。v2から上げる場合は破壊的変更がそこそこあるので、公式のアップグレードガイドを必ず読んでください。特にレイアウトをアロー関数コンポーネントで.layoutに直接代入する書き方は非サポートになっています。パッケージがすべてESM onlyになった点も要確認です。
余談：スターターキットの分断問題
Laravelの公式スターターキットはLivewire / Vue / Reactの3系統ありますが、同じ機能を3スタックで実現する前提のため、学習リソースやチュートリアルが分断されやすいという指摘があります。「Laravel Inertia ○○のやり方」で検索したときに、自分と違うスタックの記事ばかり引っかかるやつです。
チュートリアルを書く側も「3つ全部書くか、1つに絞るか」の判断を迫られるので、この構造問題は当分続きそうです。
5. で、React使いは移行すべきなのか
私の結論は「しなくていいが、Vue案件を避ける理由はもうない」です。状況別に整理します。
| 状況 | 判断 |
|---|---|
| 新規Laravel案件・チームがReact慣れ | Reactスターターキットのままで問題なし。移行コストに見合うリターンがない |
| Vue案件を受ける／既存Vueの保守 | 3.5系で普通に組む。ただしComposition API + <script setup>を徹底する（Vapor移行の布石） |
| 個人開発で既にReact | 移行不要。Vaporの性能が刺さるのはリアクティブ更新が激しいUIに限られる |
| Vapor Modeを試したい | 3.6 stableを待って、重い画面1枚だけ切り替えて計測が定石 |
| Nuxt 3で運用中 | 年内EOLなので移行計画を今立てる。ここだけ緊急度が高い |
代替案も一応
LaravelでSPAっぽいUXが欲しいだけなら、Vue/ReactどちらでもなくLivewire + Alpine.jsも引き続き有力です。フロントエンド側の学習コストとビルドパイプラインの複雑さを増やしたくないチームには、こちらのほうが合理的なケースが普通にあります。
「SPAにする必然性があるか」を先に問うのは、2026年でも変わらず有効な問いだと思います。
まとめ
- Vue 3.6はまだRC。stableと書いている記事に騙されない
- Vapor Modeは仮想DOMを捨てる方向転換だが、オプトインかつ書き方は変わらない。Options APIとSuspenseは対象外
- Composition APIへの移行はVapor化への投資として二重に効く
- ビルド周りはRust化（Vite 8 + Rolldown）が完了しつつある
- Laravel使いにとっての実利はInertia v3。Axios依存が消え、SSRのDXが改善された
- Nuxt 3のEOLだけは期限が切られているので要対応
Vapor Modeのベンチマークや実際の移行手順は、3.6 stableが出たら実プロジェクトで試して別記事にしようと思います。