2026.08.30 Laravel

Laravel Inertiaとは｜APIを作らずSPAを組む仕組みと3系の変更点

Inertiaは、Laravelのルーティングとコントローラをそのまま残したまま、画面の描画だけをReactやVueのコンポーネントへ差し替えるための接続層です。REST APIを別に設計する必要も、フロント側にルータを持たせる必要もなく、コントローラが返すのはテンプレート名ではなくコンポーネント名とデータになります。この記事では2026年8月30日時点の公式ドキュメントと実際に配布されているパッケージを実測し、通信で何が飛んでいるのか、3系で何が変わったのか、React・Vue・Svelteのどれを選ぶと版の縛りが効いてくるのかを整理したうえで、受託開発で採用してよい条件を条件付きで示します。React環境をどう組むかという手順の話はLaravelとReactの連携ガイド｜環境構築・SPA・認証・デプロイと選び方にまとめてあるので、そちらを参照してください。

まとめ：Inertiaが省くもの、3系の変更点、選定の分岐

Inertiaはフレームワークではなく、サーバ側のルーティングとクライアント側のコンポーネントを橋渡しする層です。APIの設計もフロント側のルーティングも書かずに済みます。
通信はヘッダ1本で切り替わります。初回はHTMLが返り、以降はX-Inertia付きのXHRに対してcomponent・props・url・versionの4項目だけが返る形です。
3系は2026年3月26日に安定版が出ました。axiosを外して内製のXHRクライアントに置き換え、useHttpと楽観的更新を標準化した版です。
ESMのみの出力になり、Svelte 4は対象外になりました。2系のまま止めておく選択も残っており、npmのlegacyタグで2.3.27系が配布されています。
Blade・Inertia・API＋SPA・Livewireの4方式は、ルーティングと認証をどこに置くかで分かれます。Inertiaが省くのはこの2つの二重実装で、フロントの記述量は減りません。
採否の分岐は「そのWebアプリ以外の何かがサーバを叩くか」の一点で決まると判断しています。モバイルアプリや外部システムが同じデータを取りに来る予定があるなら、結局APIを別に立てることになるでしょう。

InertiaはAPI層を挟まずビュー層だけをJSへ置き換える

名前からはフロントエンドのフレームワークに見えますが、Inertiaが提供するのはルータでもUIライブラリでもありません。サーバ側とクライアント側のアダプタが対になり、決まった形のJSONをやり取りするだけの層です。

サーバはInertia::renderでコンポーネント名とpropsを返す

コントローラの書き方はBladeを返していたときとほとんど変わりません。view()をInertia::render()に置き換え、第1引数にJS側のコンポーネント名、第2引数に渡したいデータを並べるだけです。ルート定義もミドルウェアもバリデーションもLaravelの作法がそのまま通ります。

public function index(): Response
{
    return Inertia::render('Users/Index', [
        'users' => User::query()
            ->select('id', 'name', 'email')
            ->paginate(20),
        'filters' => Request::only(['search_word']),
    ]);
}

JS側ではページ用のディレクトリ配下にある同名ファイルが解決され、第2引数の配列がそのままpropsとして届きます。フロント側にルーティングテーブルを持たせないため、URLとコンポーネントの対応関係はLaravelのルート定義だけが唯一の情報源になる構造です。導入自体は次の3コマンドで終わります。

composer require inertiajs/inertia-laravel
php artisan inertia:middleware
npm install @inertiajs/react

初回はHTMLで返り、以降はX-Inertia付きのXHRに切り替わる

最初のアクセスだけは通常のHTMLレスポンスです。ドキュメント内にdata-page属性を持つscript要素が埋め込まれ、そこにJSONエンコードされたページオブジェクトが入っています。クライアント側のアダプタはこれを読んで初期描画し、以降のリンククリックを横取りしてXHRへ変換します。

2回目以降のリクエストには、クライアントが自動で判別用のヘッダを付けます。サーバ側のミドルウェアはこれを見て、ページオブジェクトだけをJSONで返す形へ切り替わります。飛ぶのは次の3種類です。

ヘッダ	入る値と役割
X-Inertia	trueで判別に使う
X-Inertia-Version	手元のアセット版を送る
X-Inertia-Partial-Data	返してほしいprops名

部分リロードのときは、対象コンポーネント名を送るX-Inertia-Partial-Componentも併せて付きます。返ってくるページオブジェクトの中身は4項目に固定されており、この形が崩れるとクライアント側は解釈できません。

項目	入る値
component	描画するコンポーネント名
props	画面へ渡す値とerrors
url	そのページのURL
version	アセット版の識別子

PUT・PATCH・DELETEのあとにリダイレクトを返すと、302は303 See Otherへ自動で変換されます。ブラウザがリダイレクト先へGETを投げ直す挙動になるため、非GETのリクエストが二重に走る事故は構造的に起きません。

アセットのバージョン不一致は409を返して全面リロードに落ちる

SPA型の構成でいちばん厄介なのが、デプロイ直後に古いJSを抱えたタブが残る状態です。Inertiaはページオブジェクトのversion項目でこれを検知します。クライアントの版とサーバ側の版が食い違うと、409 ConflictとX-Inertia-Locationヘッダが返り、通常のページ遷移としてリロードし直す流れです。

ユーザーには一度だけ画面が再読み込みされたように見えるだけで、古いバンドルのまま操作を続けてエラーになる事態は避けられる仕組みです。Laravelのアダプタは既定でビルド成果物のマニフェストからハッシュを取るため、追加の設定なしにこれが働きます。ビルド周りの記法や本番での落とし穴はLaravel Viteの使い方｜@viteの書き方と本番ビルドの落とし穴で扱っています。

部分リロードはonlyとexceptで返すプロップスを絞り込む

一覧画面の絞り込みのように、同じコンポーネントのまま一部のデータだけ取り直したい場面があります。onlyで欲しいprops名を指定すると、サーバ側は指定されたものだけを評価して返します。指定外のpropsのクロージャは実行されません。

router.reload({ only: ['users'] })

逆に「これ以外は全部欲しい」場合はexceptを使います。さらに2系から入った遅延プロップスを使うと、初回の描画では返さず、描画後に別リクエストで取りに行く形にできます。集計値のように出るまで時間のかかるデータを、画面の表示そのものから切り離せる機能です。

return Inertia::render('Dashboard', [
    'summary' => $this->summary(),
    'audits' => Inertia::defer(
        fn () => Audit::latest()->take(50)->get(),
        'slow'
    ),
]);

第2引数のグループ名が効きます。同じ名前を付けたものは1回のリクエストにまとまり、違う名前のものは並列に取りに行く動きです。重いクエリが2本あるなら、別グループに分けるだけで待ち時間が直列から並列へ変わります。

3系で入った主な変更は依存の削減と非同期の書き味の改善に集中する

2026年3月26日に3.0.0の安定版が出て、以降は3.7.0まで版が進みました。依存の整理と「遷移を伴わない通信」の扱いに手が入った版という性格が強く、2系から上げるときは破壊的変更のほうを先に見ておく必要があります。

Axiosを外した内製のXHRクライアントでバンドルが軽くなった

2系まではaxiosが必須の依存で、Inertiaを入れると自動的にバンドルへ乗っていました。3系はこれを自前のXHRクライアントに置き換えており、gzip後で約15KB分が削減されます。3.7.0のパッケージ定義でも、依存はcoreとes-toolkitとlaravel-precognitionの3つだけです。

影響が出るのは、axiosのインターセプタでCSRFトークンや共通ヘッダを差し込んでいた構成です。Inertia経由の通信はもうaxiosを通らないため、その仕掛けは効きません。移行時はインターセプタの処理を洗い出し、Inertiaのイベントフックか後述のuseHttp側へ移し替える作業が発生します。

useHttpは画面遷移を伴わないリクエストの状態管理を引き受ける

Inertiaの弱点として長く指摘されていたのが、ページ遷移を起こさないHTTPリクエストの扱いでした。オートコンプリートの候補取得やモーダル内の保存処理は、遷移させたくないのにuseFormの恩恵も受けたい位置にあります。3系のuseHttpはこの穴を埋めるフックです。

processing・errors・progress・isDirtyといったリアクティブな状態を返す点はuseFormと同じで、違うのは結果がページ遷移にならないところだけです。書き味を揃えたまま、遷移するものとしないものを使い分けられます。遷移を伴うフォーム送信は従来どおりの書き方です。

const { data, setData, post, processing, errors } = useForm({
    name: '',
    email: '',
})

function submit(e) {
    e.preventDefault()
    post('/users')
}

楽観的更新は先に画面を更新し非2xx応答で自動ロールバックする

チェックボックスの切り替えや並び替えのように、成功が前提の操作で往復を待たせたくない場面があります。3系はルータ・useForm・useHttpの3経路すべてに楽観的更新のAPIを持たせました。変更はページの状態へ即座に反映され、サーバが2xx以外を返した時点で自動的に巻き戻ります。

自前で実装すると、巻き戻しの取りこぼしとエラー表示の二重管理がそのまま不具合の温床になっていました。ここが標準化された意味は小さくありません。あわせてレイアウトプロップスのAPIが入り、ページからレイアウトへ値を渡す迂回策も不要になりました。

破壊的変更としては、ESMのみの出力へ切り替わった点と、Svelte 4のサポートが終了した点が実務に響きます。開発時のSSRがNodeの別プロセスなしで動くようになった一方、CJSを前提にした古いビルド構成では上げる前に整理が要るでしょう。

項目	2系	3系
HTTP実装	axiosを同梱	内製のXHR
出力形式	CJSとESM	ESMのみ
Svelte	4と5に対応	5のみ対応
遷移なし通信	自前で用意	useHttpが担当
楽観的更新	自前で用意	各APIに内蔵
開発時SSR	別プロセス	Viteが内包

アダプタはReact・Vue・Svelteの3種で版の縛りが異なる

Inertiaはどのフロントを選んでもプロトコルが同じなので、サーバ側のコードは共通です。違いが出るのはクライアント側のアダプタで、それぞれが前提にするフレームワークの版が決まっています。ここを見ずに選ぶと、既存プロジェクトの版と噛み合わずに詰まります。

現行は3.7.0系でReactはv19、SvelteはSvelte 5が前提になる

2026年8月時点で配布されている版を確認したところ、3つのJSアダプタはいずれも3.7.0が最新で、2026年8月18日の公開でした。サーバ側のinertia-laravelはv3.3.1で、PHP 8.2以上とLaravel 11.35以降を要求します。11・12・13のいずれからでも導入できる形です。

パッケージ	現行版	前提
@inertiajs/react	3.7.0	React 19
@inertiajs/vue3	3.7.0	Vue 3
@inertiajs/svelte	3.7.0	Svelte 5
inertiajs/inertia-laravel	v3.3.1	PHP 8.2以上

とくに効いてくるのがReactアダプタの前提です。3.7.0のpeerDependenciesはreactとreact-domがどちらも19系を要求するため、React 18のまま止まっているプロジェクトへそのまま入れられません。React側を先に上げるか、2系のアダプタを選ぶかの二択になります。npmのlegacyタグには2.3.27が残っています。

公式スターターキットの3種はいずれもInertia 3を既定にしている

Laravelのインストーラで作られる公式のスターターキットは4種類あり、そのうちReact・Vue・SvelteのいずれもInertiaを前提にしています。Reactキットの構成はInertia 3・React 19・Tailwind 4・shadcn/ui、VueキットはInertia 3とVue 3のComposition APIとshadcn-vue、SvelteキットはInertia 3・Svelte 5・shadcn-svelteという内訳です。認証はいずれもFortifyが担当します。

新規案件なら、ページの解決・レイアウト・認証画面・SSRのビルドコマンドまで揃ったキットから始めるほうが早いでしょう。

Blade・API＋SPA・Livewireとの違いを工程の負担で比べる

Inertiaを選ぶかどうかは、単体で決まる話ではありません。同じ画面を作る手段が4つあり、それぞれ何を書かずに済ませるかが違います。機能比較ではなく、工程の負担がどこに寄るかで並べたほうが判断しやすくなります。

4方式の差はルーティングと型と初期表示の持ち方にはっきり現れる

観点	Blade	Inertia	API＋SPA	Livewire
ルート定義	サーバ側	サーバ側	二重に持つ	サーバ側
画面の記述	Blade	React等	React等	Blade
認証	セッション	セッション	トークン等	セッション
初期表示	サーバ描画	JSが描画	JSが描画	サーバ描画
JSの記述量	ごく少ない	多い	多い	少ない
検索エンジン	そのまま	SSRが要る	SSRが要る	そのまま

API＋SPAとの差は認証とルーティングの二重実装が消える点にある

LaravelでAPIを立ててReactから叩く構成では、URLの設計をサーバ側とフロント側の両方に持つことになります。認証もトークンやCookieベースの仕組みを別に用意する必要があり、CORSやリフレッシュの扱いまで工数が積み上がるでしょう。Inertiaはこの2つを省く方式です。

裏返すと、その省略はInertia経由の通信でしか効きません。同じデータをモバイルや外部システムにも渡す予定があるなら、二重実装は消えないまま残ります。API側を作る場合の設計はLaravel APIの作り方｜install:apiとAPIリソース・エラー応答の統一、認証方式の選び分けはLaravel Sanctumとは：SPAとモバイルのトークン認証とCookieセッションの使い分けにまとめてあります。

LivewireとはJSを書くか書かないかで採用の分かれ目ができる

Livewireも同じくAPIを作らずに動的なUIを組む方式ですが、UIの記述がBladeとPHPのまま完結する点が決定的に違います。Inertiaは画面のコードをReactやVueで書くので、フロント側の設計力とビルド環境が要る代わりに、コンポーネントの資産やUIライブラリをそのまま持ち込めます。

PHPしか書かないメンバーで回すならLivewire、フロント担当が別にいて既存のUIライブラリを使い回したいならInertia、という分け方でおおむね説明が付きます。Livewire側の詳細はLivewire（Laravel）とは？v4対応の使い方とコンポーネント作成・Blade連携の手順を参照してください。

実装で先に詰まる箇所を共有プロップスとSSRの手当てから潰しておく

導入自体は数コマンドで終わりますが、実案件へ載せると同じ場所で詰まります。あとから直すと影響が全画面に及ぶ2点を先に挙げておきます。

共有プロップスはミドルウェアのshareでどの画面にも配られる

ログインユーザーやフラッシュメッセージのように、全画面で使う値をコントローラごとに書くのは現実的ではありません。専用のArtisanコマンドで生成されるミドルウェアのshareメソッドに置くと、すべてのページオブジェクトへ自動で乗ります。クロージャで渡した値は遅延評価されます。

public function share(Request $request): array
{
    return array_merge(parent::share($request), [
        'auth' => [
            'user' => fn () => $request->user()?->only('id', 'name'),
        ],
        'flash' => [
            'success' => fn () => $request->session()->get('success'),
        ],
    ]);
}

ここに何を載せるかは早めに決めてください。共有プロップスは全ページのレスポンスに毎回入るため、権限一覧やマスタデータのような大きい配列を置くと、遷移のたびに転送量が積み上がります。画面固有の値はその画面のコントローラで渡すのが原則になります。

SSRを入れるならビルド生成物と常駐プロセスの管理を分けて考える

Inertiaは既定でクライアント側描画なので、初期表示のHTMLには中身が入りません。検索エンジンやOGPの取得を前提にする画面では、SSRを入れる判断になります。公式のスターターキットはSSR対応のビルドコマンドを持っており、開発中は開発サーバと同居させて確認できます。

問題は本番です。SSRを有効にすると、通常のPHPプロセスとは別に、SSRバンドルを実行するNodeプロセスが常駐します。デプロイのたびにバンドルを作り直し、そのプロセスを再起動する手順が要るうえ、落ちたときの監視対象も1つ増えるわけです。SSRを入れるかどうかは、この運用コストを保守契約に載せられるかで決めてください。

受託開発でInertiaを採用してよい条件と見送りにする場面の整理

ここからは実案件に載せる判断です。技術的な優劣ではなく、案件の要件とチームの構成で答えが変わります。

バックエンド主体のチームが画面をリッチにする案件では噛み合う

もっとも噛み合うのは、Laravelを書けるメンバーが主体で、画面の操作性だけを引き上げたい社内システムや業務Webアプリです。ルーティングも認証もバリデーションもサーバ側の作法のまま残るため、フロント側で新しく覚えるのはコンポーネントの書き方とpropsの受け取り方に限られます。API設計と仕様書のやり取りが工程から消える効果も小さくありません。

モバイルや外部システムがAPIを叩く案件では見送り側に倒れる

逆に見送りが妥当なのは、Webブラウザ以外の経路から同じデータへアクセスする要件が最初から見えている案件です。ネイティブアプリ、取引先とのシステム連携、社内の別システムからの参照が1つでもあるなら、APIは結局必要になります。

その場合、Inertiaを併用するとサーバ側にInertia向けの経路とAPI向けの経路が二重に並びます。整合を取り続ける手間を考えると、最初からAPI＋SPAへ寄せてWeb画面もそのAPIを叩く構成のほうが素直でしょう。どちらの方式で組むべきかを含めて設計から相談したい場合は、業務用・Webアプリ開発としてご相談を承っています。