---
title: "Laravel Inertiaとは｜APIを作らずSPAを組む仕組みと3系の変更点"
url: "https://www.issoh.co.jp/tech/details/17149/"
published: 2026-08-30
updated: 2026-08-30
categories: ["Laravel"]
publisher: "株式会社一創"
---

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

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

## まとめ：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の書き方と本番ビルドの落とし穴](https://www.issoh.co.jp/tech/details/3251/)で扱っています。

### 部分リロードは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リソース・エラー応答の統一](https://www.issoh.co.jp/tech/details/17137/)、認証方式の選び分けは[Laravel Sanctumとは：SPAとモバイルのトークン認証とCookieセッションの使い分け](https://www.issoh.co.jp/tech/details/17139/)にまとめてあります。

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

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

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

## 実装で先に詰まる箇所を共有プロップスと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アプリ開発](https://www.issoh.co.jp/service/apps/business/)としてご相談を承っています。

### 分岐はそのアプリ以外がAPIを叩くかどうかの一点で決まってくる

4方式の比較表は項目が多く、機能単位で見比べると判断が止まります。実務で効いたのは1つの問いだけでした。このWebアプリ以外の何かが、同じサーバのデータを叩きに来るかどうかです。来ないならInertia、来るならAPI＋SPAという分け方で、これまでの案件はほぼ説明が付きました。

この問いに「来ない」と答えたうえで、さらにJSを書けるメンバーがいないならLivewireへ倒します。フレームワークそのものを選ぶ段階の判断材料は[Laravelの将来性を2026年のデータで判断する｜サポート期限・求人単価・AI対応](https://www.issoh.co.jp/tech/details/5469/)にまとめてあるので、そちらも併せて確認してください。

## よくある質問

### Inertiaを入れるとAPIは一切書かなくてよいのですか？

Webブラウザからの画面表示に限れば、REST APIを別に設計する必要はありません。コントローラが返すのはコンポーネント名とpropsで、それがそのままページオブジェクトとして届きます。ただしモバイルアプリや外部システムが同じデータを取りに来るなら、その経路のためのAPIは別に要ります。

### ReactとVueとSvelteのどれを選ぶとよいですか？

サーバ側のコードはどれを選んでも同じなので、チームが書ける言語と既存のUI資産で決めてください。版の縛りだけは事前確認が要ります。3.7.0のReactアダプタはreact 19系を要求し、SvelteアダプタはSvelte 5のみが対象です。

### 2系のまま運用を続けても問題はありませんか？

npmのlegacyタグで2.3.27が配布されており、当面は使い続けられます。ただし新機能はすべて3系側へ入るため、useHttpや楽観的更新の標準APIは使えません。いずれ上げる前提で計画に入れておくのが無難でしょう。

### 既存のBladeアプリへ後から導入できますか？

導入できます。ルート定義は変えずに、書き換えたい画面のコントローラだけをInertia側へ切り替える形で、画面単位の段階移行が可能です。ただしBladeを返す画面へInertia経由のリンクで遷移すると全面リロードになるため、移行途中はリンクの張り方を使い分けてください。

### 検索エンジンに正しく認識させるにはどうしますか？

既定ではクライアント側で描画するため、初期HTMLに本文が入りません。検索流入を取りに行く画面ではSSRを有効にしてください。本番ではSSRバンドルを実行するNodeプロセスが常駐するので、デプロイ手順と監視対象に加える前提で設計しましょう。

## 関連記事

- [LaravelとReactの連携ガイド｜環境構築・SPA・認証・デプロイと選び方](https://www.issoh.co.jp/tech/details/2906/)：React側の環境構築とデプロイの手順を扱っています。
- [Livewire（Laravel）とは？v4対応の使い方とコンポーネント作成・Blade連携の手順](https://www.issoh.co.jp/tech/details/4474/)：JSを書かずに動的UIを組む側の方式です。
- [Laravel APIの作り方｜install:apiとAPIリソース・エラー応答の統一](https://www.issoh.co.jp/tech/details/17137/)：APIを別に立てる場合の設計です。
- [Laravel Sanctumとは：SPAとモバイルのトークン認証とCookieセッションの使い分け](https://www.issoh.co.jp/tech/details/17139/)：認証方式の選び分けの材料です。
- [Laravel Viteの使い方｜@viteの書き方と本番ビルドの落とし穴](https://www.issoh.co.jp/tech/details/3251/)：アセットのビルド周りの前提です。
- [Laravelの将来性を2026年のデータで判断する｜サポート期限・求人単価・AI対応](https://www.issoh.co.jp/tech/details/5469/)：採用判断の前提になる材料です。

---

出典: [Laravel Inertiaとは｜APIを作らずSPAを組む仕組みと3系の変更点](<https://www.issoh.co.jp/tech/details/17149/>)（株式会社一創）