LaravelでSPAっぽい画面を作りたい──
でも、Next.jsとかNuxt.jsほどガッツリじゃなくていい。
ルーティングはLaravelに任せたいし、APIも分けたくない。

そんなときに名前が出てくるのが Inertia（イナーシャ：慣性）.jsです。今日はその紹介になります。
ちなみにしばらく俺はInteria.jsだと勘違いしてました。interiaではありません。Inertiaです。

Inertia.jsとは？

Inertia.jsは、LaravelやRailsなどのサーバーサイドフレームワークと、Vue / React / Svelte といったモダンJSフレームワークを直接つなぐ「アダプタ」のような存在です。
APIを別に用意せず、サーバー側のルーティングをそのまま使いながらSPA的なUXを実現できます。
BladeやERBと同じように「サーバー側でページを返す」感覚を保ちながら、フロント側はコンポーネントベースで開発できるのが特徴です。

実際に使ってみたら、確かに「BladeとSPAの間」にスッと入ってくる感覚があった。
今回はその体験談を、良かったところ、微妙だったところ、そして「これ向いてる／これはやめた方がいい」案件まで、まとめていきます。

良かったところ

🌀 SPAっぽい雰囲気を手軽に味わえる

Bladeで画面遷移するときの全リロード感が消えて、
ページ間がフワッとつながる。完全SPAではないけど、体感はかなり近い。

📦 Vue / React / Svelte 対応

主要どころはカバーされてるので、チームの好みや既存資産に合わせやすい。
「今うちはVueだし、Reactの案件もある」という環境でも移行コストは低め。

🛠 fetchを書かずにデータ渡し

Laravelのコントローラで return Inertia::render(...) すると、
ビューと一緒にPropsがサクッと飛んでくる。
API設計を別に考えなくても、最初の画面まではすぐ形になる。

🧾 フォームエラーもLaravel標準のまま

$errors がそのまま使える。
いつもの @error('title') も違和感なく置き換えられるのはかなり気持ちいい。

微妙だったところ

⚠ ステータスコードが全部200で返る

404も403も200で返す仕様。
「HTTPはこうあるべき」派にはちょっとモヤる。
（仕様の理由はわかるけど、API思考だと気持ち悪さは残る）

🌀 型がむずい

TypeScriptで安全にPropsを扱おうとすると、型定義を結構ガチで書く必要がある。
特に大きめのPropsになると「これ普通にAPI設計して型定義するのと変わらないのでは？」感。

🔄 CSR前提

初期表示はCSRなので、SEOには弱い。
管理画面なら気にならないけど、公開サイトだと選択肢に入りづらい。

こういう案件ならハマる

• 社内ツール・管理画面
  SEO不要。ログイン後のサクサク感が正義なやつ。
• 中小規模の業務システム
  完全SPAはオーバーキルだけど、フォームやリスト画面が多い案件。
• 既存Laravelの一部モダン化
  全面リプレイスは無理でも、一部画面だけVue/React化したいとき。

こういう案件は避けたい

• SEOが命のサービス
  CSR前提なので、検索流入が必要なサイトはSSR系（Nuxt/Next）を検討したほうがいい。
• APIファーストな開発文化
  ステータスコード200固定やProps直渡しが、チームの設計思想とズレやすい。
• 大規模SPA
  状態管理やルーティングを全部フロントに寄せる場合、Inertiaは中途半端に感じる可能性大。

まとめ

Inertia.jsは、LaravelとモダンJSフレームワークを「ちょうどいい距離感」でつないでくれる。
Bladeだけじゃ物足りない。でもフルSPAまでは踏み込みたくない。
そんな案件にはすごく心地よくハマる。

逆に、SEOが必要だったり、API設計をガチでやりたいチームには向かない。
良くも悪くも「Laravel中心の開発を崩さないための選択肢」だと思う。