2026年のLaravelアプリ開発、フロントをLivewire/Filamentで完結させるか、Next.js 16で分離するか。要件別の判断フレームと比較を実務目線で解説します。
「フロントどうする?」という問いに、もう迷わないために
Laravelプロジェクトを始めるたびに、こんな議論が起きていませんか?
「管理画面はFilamentでいいとして、フロントはReact使いたい派と、Livewireで完結させたい派で意見が割れてる」 「Next.jsで分離した方がモダンだと思うけど、工数が読めない」 「とりあえずLivewireにしたけど、これで本当に良かったのか不安」
2026年時点で、LaravelアプリのフロントエンドはLivewire 3・Filamentによるモノリス完結か、Next.js 16によるAPI分離かという構図が明確になっています。どちらも成熟しており、どちらかが「正解」というわけではありません。
この記事では、要件・チーム・運用コストを軸に、どちらを選ぶべきかの判断フレームを実務ベースで整理します。コード例・比較表・アンチパターンも含め、技術選定の場で即使える内容を目指しています。
2026年の選択肢が増えた背景
少し前まで、LaravelのフロントエンドといえばBladeテンプレートにjQueryを添えるか、Vue.js/ReactをLaravel Mixでバンドルする程度の選択肢しかありませんでした。それが今、大きく変わっています。
Livewire 3の成熟により、JavaScriptをほぼ書かずにリアクティブなUIが実装できるようになりました。モーダル・リアルタイムバリデーション・ページネーションといった動的な挙動を、PHP側のコンポーネントクラスだけで表現できます。Laravelチームのサポートも手厚く、エコシステムの第一級市民として統合されています。
Filamentはその上に乗る形で、CRUD・データテーブル・フォームビルダー・ダッシュボードウィジェットを宣言的に構築できます。管理画面やデータ管理系のUIを、最小限のコードで実装できるのが最大の強みです。
一方、Next.js はバージョン16系(2026年現在)に達し、App Router・React Server Componentsのアーキテクチャが安定しています。LaravelをバックエンドAPIとして使い、フロントを完全分離する構成が現実的な選択肢として定着しました。認証にはLaravel Sanctumが定番です。
この二軸の成熟が同時進行したことで、技術選定における「どちらが適切か」という問いが以前より重要になっています。
構成A:Livewire + Filamentで完結するモノリス
どんなプロジェクトに向いているか
- 管理画面・社内ツール・ダッシュボードが中心のアプリ
- 5〜15人規模のチームで、フロント専任エンジニアがいない
- Laravelエンジニアがフルスタックで開発・保守を担う体制
- SEO重視のサーバーサイドレンダリングが必要
- 開発スピードと初期コストの最小化を優先する案件
構成のイメージ
Laravelアプリが一枚岩(モノリス)として動作し、URLルーティング・ビジネスロジック・認証・UI描画まで同一プロセスで完結します。デプロイはサーバー1台、環境変数1セット、Gitリポジトリも1つです。
flowchart TD
Browser[ブラウザ] --> Laravel[Laravel App]
Laravel --> Livewire[Livewire コンポーネント]
Laravel --> Filament[Filament 管理画面]
Laravel --> Blade[Blade テンプレート]
Laravel --> DB[(Database)]Livewire 3 コンポーネントの例
たとえばユーザー一覧の検索機能を実装するケース。BladeとPHPだけで、タイピングに反応するリアルタイム検索が実現できます。
<?php
namespace App\Livewire;
use App\Models\User;
use Livewire\Component;
use Livewire\WithPagination;
class UserSearch extends Component
{
use WithPagination;
public string $search = '';
public function updatingSearch(): void
{
$this->resetPage();
}
public function render()
{
return view('livewire.user-search', [
'users' => User::query()
->when($this->search, fn ($q) =>
$q->where('name', 'like', "%{$this->search}%")
->orWhere('email', 'like', "%{$this->search}%")
)
->paginate(20),
]);
}
}
wire:model.live.debounce.300ms の一行で、入力300ms後に自動でサーバーへリクエストを投げ、ページを差し替えます。JavaScriptを一切書いていません。
Filamentで管理画面を構築する例
<?php
namespace App\Filament\Resources;
use App\Models\Post;
use Filament\Forms\Components\RichEditor;
use Filament\Forms\Components\Select;
use Filament\Forms\Components\TextInput;
use Filament\Forms\Components\Toggle;
use Filament\Resources\Resource;
use Filament\Tables\Columns\TextColumn;
use Filament\Tables\Columns\ToggleColumn;
class PostResource extends Resource
{
protected static ?string $model = Post::class;
protected static ?string $navigationIcon = 'heroicon-o-document-text';
protected static ?string $navigationLabel = '記事管理';
public static function form(Forms\Form $form): Forms\Form
{
return $form->schema([
TextInput::make('title')->label('タイトル')->required()->maxLength(255),
Select::make('category_id')->label('カテゴリ')->relationship('category', 'name'),
RichEditor::make('body')->label('本文')->columnSpanFull(),
Toggle::make('is_published')->label('公開する'),
]);
}
public static function table(Tables\Table $table): Tables\Table
{
return $table->columns([
TextColumn::make('title')->label('タイトル')->searchable()->sortable(),
TextColumn::make('category.name')->label('カテゴリ'),
ToggleColumn::make('is_published')->label('公開'),
TextColumn::make('updated_at')->label('更新日')->since(),
]);
}
}
このResourceクラス一つで、一覧・検索・ソート・作成・編集・削除が動く管理画面が完成します。FilamentはLaravel Policyとも自然に統合されるため、権限管理も宣言的に書けます。
構成B:Next.js 16でフロント分離
どんなプロジェクトに向いているか
- 高度なインタラクションが必要なSPA・Webアプリ(例:ダッシュボード with 複雑なデータビジュアライゼーション、リアルタイムコラボレーション)
- フロント専任チームが存在し、React/TypeScriptスキルセットで採用している
- 同じバックエンドAPIをiOSアプリ・Androidアプリ・Webで共用したい
- フロントエンドとバックエンドのデプロイサイクルを独立させたい
- 別ドメイン・CDNエッジでフロントをホストする要件がある(Vercelなど)
構成のイメージ
flowchart TD
Browser[ブラウザ] --> Next[Next.js 16\nApp Router + RSC]
Mobile[モバイルApp\niOS / Android] --> API
Next -->|API Request| API[Laravel API\nSanctum認証]
API --> DB[(Database)]
API --> Queue[Queue / Jobs]
Next -->|Deploy| Vercel[Vercel / Cloudflare Pages]
API -->|Deploy| VPS[VPS / ECS]Laravelはルーティング・Blade・Livewireを持たない純粋なAPIサーバーとして動作します。認証はSanctumのSPAモード(Cookieベース)かトークン認証を採用します。
// routes/api.php
Route::middleware('auth:sanctum')->group(function () {
Route::apiResource('posts', PostController::class);
Route::get('/user', fn (Request $r) => new UserResource($r->user()));
});
// app/Http/Controllers/PostController.php
public function index(Request $request): AnonymousResourceCollection
{
$posts = Post::query()
->with('author', 'category')
->when($request->search, fn ($q) =>
$q->where('title', 'like', "%{$request->search}%")
)
->latest()
->paginate(20);
return PostResource::collection($posts);
}
Laravel側はこのようにシンプルなAPIコントローラーに集中できます。Next.js側はfetchまたはAxiosでエンドポイントを叩き、React Server ComponentsでSSR/SSGを制御します。
構成A vs 構成B:比較表
| 評価軸 | A: Livewire + Filament | B: Next.js 16 分離 |
|---|---|---|
| 学習コスト | 低い(Laravelエンジニアが全て担える) | 高い(React/TypeScript + API設計の習熟が必要) |
| 初期開発速度 | 速い(管理画面はFilamentで大幅短縮) | 普通〜遅い(フロント・バック両方の設計が必要) |
| SEO対応 | ◎ サーバーレンダリングがデフォルト | ◎ Next.js RSC/SSGでSEO対応可能 |
| リッチなUI表現 | △ 複雑なアニメーション・SPAには限界あり | ◎ Reactエコシステムをフル活用 |
| チーム体制 | Laravelエンジニア中心のフルスタック構成 | フロント専任 + バックエンド専任に分担 |
| デプロイ構成 | シンプル(サーバー1台・リポジトリ1つ) | 複雑(フロント/バック別デプロイ・CORS・認証設定) |
| モバイルアプリとのAPI共用 | △ 追加でAPI化が必要 | ◎ 最初からAPIファーストで設計 |
| 採用のしやすさ | Laravelエンジニアで完結 | React人材の採用が追加で必要 |
| 運用・保守コスト | 低い(コードベースが一元管理) | 高い(インフラ・認証・CORS等の管理が増える) |
| 向いているプロジェクト規模 | 小〜中規模(〜数万ユーザー) | 中〜大規模、または複数クライアント対応 |
判断フレーム:要件でA/Bを決める
構成Aを選ぶべき要件
- 主要ユーザーが社内・限定ユーザー(管理システム・社内ツール・BtoBダッシュボード)
- Laravelエンジニアが1〜3名でフロントもバックも担当する体制
- 予算・納期が限られており、フロントとバックの並行開発が困難
- SEO重視のコンテンツサイト(ブログ・LP・コーポレートサイト的要素がある)
- 将来的にもモバイルアプリ展開の予定がない
- 保守フェーズが長く、関わるエンジニアが変わる可能性がある(コードを読みやすく保ちたい)
構成Bを選ぶべき要件
- フロント専任のReactエンジニアがすでにいる、またはこれから採用予定
- iOSアプリ・Androidアプリと同一APIを共用する設計にしたい
- Vercel等のエッジCDNでフロントをホストし、グローバルパフォーマンスを追求する
- フロントとバックのリリースサイクルを分離したい(フロントは週次デプロイ、バックは隔週など)
- 複雑なクライアントサイドインタラクション(DnD・リアルタイムコラボ・高度なグラフ操作)が要件にある
- チームがReact/TypeScriptのスキルを持ち、Bladeに戻ることに抵抗がある
アンチパターン:やりがちな失敗
技術選定の現場でよく見る失敗パターンを正直に書きます。
❌ 小規模案件にNext.js分離を導入して工数爆発
「モダンにしたい」という動機でNext.js+Laravel API構成を採用したものの、CORS設定・Sanctum認証のCookieドメイン設定・環境変数の二重管理・フロントとバックのAPI仕様同期という4つの追加コストが発生し、開発期間が当初見積もりの1.5倍になる——これは実際によくあるパターンです。
「10ページ程度の管理画面、エンジニア2名」という案件にAPI分離は過剰投資です。
❌ LivewireにJavaScriptを無理やり混ぜ込む
Livewireを選んでおきながら、「この部分だけReact使いたい」と言い始め、Alpine.js・インラインJavaScript・Vue単体コンポーネントを継ぎ足す構成になるケース。一見動いても、保守性が著しく落ちます。
Livewireで完結する選択をしたなら、Alpine.jsの範囲内で解決できるUIに設計を寄せるか、複雑なインタラクションが不可避なら早めに分離を検討してください。
❌ 「とりあえずFilament入れたけど、カスタマイズで詰まった」
Filamentは標準的なCRUD・テーブル・フォームには非常に強力ですが、デザインを大幅にカスタマイズしようとすると内部実装の理解が必要になります。「管理画面をFilamentでサクッと作る」という用途には正しい選択ですが、一般ユーザー向けの凝ったUIにFilamentを使おうとすると、素のBladeやLivewireで作り直した方が早いという状況になりがちです。
❌ Next.js分離なのにLaravel側に表示ロジックが漏れる
APIとして使うと決めたLaravelに、フォーマット済みのHTMLをJSON内に入れたり、ページネーションのUIロジックをサーバー側で決めたりするケース。APIはデータを返すことに集中し、表示ロジックは全てNext.js側に置く、という境界線を最初から明確にしないと、どちらの責務も曖昧になります。
迷ったときの実践的な問いかけ
技術選定の場で、次の4つを確認すると大半のケースで答えが出ます。
いる・採用予定あり → 構成Bを検討する価値あり
ない・未定 → 構成A(後から必要になればAPI追加は可能)
リアルタイム・ドラッグ操作・複雑なアニメーション → 構成B
React系が多い・または完全に分業 → 構成B
技術選択チェックリスト
まとめ
2026年のLaravelフロントエンド選択は、「どちらがモダンか」ではなく**「チームと要件にどちらが合うか」**という問いです。
- Livewire + Filamentのモノリス構成は、Laravelエンジニア中心のチームで、管理画面・業務システム・中小規模のWebアプリを速く・安く・保守しやすく作るための最善手になり得ます。
- Next.js 16によるフロント分離は、リッチなユーザー体験・フロント専任チーム・マルチクライアントAPI共用というコンテキストで力を発揮します。その代わり、運用の複雑さは増します。
「流行りだからNext.js」「楽そうだからLivewire」という理由での技術選択は、後のフェーズで必ず課題として戻ってきます。上記の判断フレームを使い、要件・チーム・保守コストを三点セットで評価してください。
この技術、御社の業務にも活かせます
業務システム開発
Laravelを使った業務システムの構築・改修を20年以上の経験でサポートします
※ 通常1営業日以内にご返信します
Fivenine Designへの無料相談
Laravelプロジェクトの技術選定や、既存システムのフロントエンドリアーキテクチャについて「うちのケースではどちらが適切か?」と迷っている方は、お気軽にご相談ください。Laravel・Next.jsでの開発実績をもとに、弊社が、要件を整理した上で中立な視点でアドバイスします。
**初回のご相談は無料です。**フォームからお気軽にどうぞ。