2026.08.29 Laravel

Laravel Filamentとは？管理画面を短工数で作る構成とNovaとの選択基準

業務システムの受注が決まったあと、工数の見積りで扱いに困るのが管理画面です。エンドユーザーが触る画面より地味なのに、一覧・検索・登録・編集・権限と作るものは多く、素のBladeで書けば画面数に比例して積み上がります。Laravel Filamentは、この部分をEloquentモデルの定義から組み上げるパッケージです。ここではFilamentが何を肩代わりするのかを構造から整理し、導入要件、有償のLaravel Novaとの費用差、そして業務システムで採用してよい条件と見送るべき場面までを扱います。数値は2026年8月29日に公式ドキュメントとリポジトリで確認したものです。

まとめ：Filamentが向く管理画面の条件とNovaを選ぶ場面の分かれ目

先に結論から並べます。

FilamentはLaravel向けのMITライセンスのUIフレームワークで、管理パネル一式を無償で構築できます。
画面はPanel・Resource・Schemaの3階層で組み上がり、Resourceはartisanコマンドから生成します。
基盤はLivewireとAlpine.jsとTailwind CSSで、フロントのビルド構成はこの3つに引きずられます。
5系の要件はPHP 8.2以上・Laravel 11.28以上・Livewire 4.1以上・Tailwind CSS 4.1以上です。
短工数で組める前提は、モデルとリレーションがテーブル設計の段階で整っていることです。
Novaは有償で、Single 99ドル・Unlimited 299ドル。拡張の書き方もVue側に寄ります。
公式のサポート窓口が調達要件に入る案件では、無償のFilamentが要件を満たさない場合があります。
エンドユーザー向けの画面まで広げると、UIの制約を外す作業のほうが高くつきます。

以下、それぞれの根拠を順に見ていきます。

FilamentがLaravelの管理画面に持ち込む機能の範囲と前提技術

Filamentは管理画面を作りやすくするヘルパ集ではありません。認証済みのパネルという器を用意し、その中にモデル単位の画面を差し込む枠組みです。まず何が同梱されているのかを押さえます。

Filamentが提供する7つのパッケージと担当する画面の役割

公式のインストール手順では、パネル一式をまとめて入れる方法と、個別パッケージを選んで入れる方法の2通りが示されています。個別に列挙されているのはtables・schemas・forms・infolists・actions・notifications・widgetsの7つです。tablesが一覧とページネーションと検索、formsが入力欄、infolistsが読み取り専用の詳細表示、actionsがボタンとモーダル、notificationsが操作後のトースト表示、widgetsがダッシュボードの集計パネルを担当します。schemasは、フォームと詳細表示に共通するレイアウト定義を切り出したものです。

パネルを使わず、既存の画面にテーブルだけ組み込むといった部分導入も成立します。管理画面をまるごと置き換える判断が付いていない段階なら、一覧表示だけをtablesで置き換えて感触を確かめる入り方が現実的です。

Livewire・Alpine.js・Tailwind CSSの3層が画面を動かす仕組み

Filamentの画面は、素のJavaScriptで書かれたSPAではありません。サーバー側のPHPクラスが状態を持ち、Livewireがその状態と画面を同期させ、モーダルの開閉のような即時の反応をAlpine.jsが受け持ちます。見た目はTailwind CSSのユーティリティクラスで組まれています。

この構造から実務上の帰結が2つ出ます。1つは、フォームの分岐やバリデーションをPHP側に書けること。もう1つは、画面の応答がサーバーとの往復に依存することです。Livewireそのものの書き方や、コンポーネントとBladeの関係についてはLivewire（Laravel）とは？v4対応の使い方とコンポーネント作成・Blade連携の手順で扱っています。Filamentの挙動で詰まったとき、原因がFilament側かLivewire側かの切り分けにも使えます。

素のBladeで管理画面を作る場合と比べて省ける実装作業の内訳

省けるのは見た目のCSSだけではありません。一覧のソートとページネーション、検索フォームとクエリへの反映、バリデーションエラーの表示位置、削除時の確認モーダル、操作後のフラッシュメッセージ、リレーション先を選ぶセレクトボックス。この6つは、どの管理画面でもほぼ同じ形で必要になり、そのたびに書き直されてきた部分です。

逆に省けないものもはっきりしています。どのモデルを管理対象にするか、どの列を一覧に出すか、誰に何を触らせるか。この3つは設計判断であり、コード生成では埋まりません。工数見積りでは、生成で消える部分と残る部分を分けて数えると精度が上がります。

PanelとResourceとSchemaで画面が組み上がる構造と生成の手順

Filamentの画面構成は3階層です。ここを取り違えると、あとから権限やテーマを変えるときに広範囲へ手が入ります。

Panelが担う認証・ナビゲーション・テーマの設定単位と分割

Panelは管理画面そのものの単位です。ログイン画面、左側のナビゲーション、配色、パスのプレフィックスがPanelごとに決まります。管理者用と取引先用のように、対象が違う画面を1つのアプリで持つ場合は、Panelを分けるのが基本形になります。

設定ファイルはphp artisan vendor:publish --tag=filament-configで公開でき、既定値の変更はここから行います。Panelを後から分割する改修は、ナビゲーション定義と認可の両方を触ることになるため、対象ユーザーの種類が2つ以上あると分かっている案件では最初から分けておくほうが安く済みます。

make:filament-resourceが生成するファイルと編集する箇所

モデル1つに対する管理画面はphp artisan make:filament-resourceにモデル名を渡して生成します。出来上がるのは、一覧・作成・編集にあたるページクラスと、それらをまとめるResourceクラスです。開発者が手を入れるのは主にResourceクラスの中の、フォーム定義とテーブル定義の2か所に集約されます。

Filament以外のmake系コマンドとあわせて把握しておくと、生成先のディレクトリを探す手間が減ります。artisanの生成コマンド全体についてはphp artisan makeコマンド一覧｜Laravel 13対応生成先・オプション早見表にまとめてあります。

フォームとテーブルをPHPのメソッドチェーンで定義する書き方

入力欄はTextInput::makeのようなコンポーネントのファクトリメソッドに列名を渡し、必須指定や文字数制限をメソッドチェーンでつないで宣言します。テーブル側も同じ形で、表示する列と並び替えの可否を並べます。BladeテンプレートではなくPHPのクラス内に定義が集まるため、IDEの補完と静的解析が機能する構成です。

この書き味には副作用もあります。定義が長くなるとResourceクラスが数百行に膨らみ、レビューしにくい状態です。フォームの共通部分をSchemaとして切り出し、複数のResourceから参照する形に整理しておくと、後の改修で差分が読めます。

Eloquentのリレーションが素直でないと自動生成が効かない理由

生成コマンドはモデルとマイグレーションの定義を読んで画面を組み立てます。裏を返すと、テーブル設計が命名規約から外れていると、生成された画面はそのままでは動きません。中間テーブルに複合キーを使っている、外部キーが規約どおりの名前でない、1つのカラムに複数の意味を持たせている。こうした設計は、Filamentの手前で解消しておく必要があります。

既存システムのリプレースでFilamentを検討するときは、この点が採否を分けます。旧システムのテーブルをそのまま引き継ぐ前提だと、生成の恩恵が受けられず、結局は手書きに近い工数がかかります。テーブル設計を作り直せる案件かどうかを先に確認してください。

導入要件と、既存のLaravelアプリへ後から組み込むときの順序

要件は年々上がっています。既存アプリへの後付けでは、Filament本体よりも周辺のバージョンが障害になります。

Filament 5系が要求するPHP・Laravel・Livewireのバージョン

2026年8月29日時点の公式ドキュメントは5.x系を掲げており、必要要件としてPHP 8.2以上・Laravel v11.28以上・Tailwind CSS v4.1以上が明記されています。リポジトリ側のパッケージ定義を見ると、Laravelは11.28系から13系までを受け付け、Livewireは4.1以上が要求されています。ライセンスはMITです。

稼働中のアプリが11系なら、まず11.28以上に上がっているかを確認します。11自体のサポート状況と変更点はLaravel 11の変更点とサポート期限｜EOL後も残る未修正の脆弱性と12・13への移行判断に整理しています。12へ上げる判断をする場合の動作要件はLaravel 12の対応PHPバージョンと動作要件｜サポート期限・11からのアップグレード・変更点を参照してください。

新規プロジェクトと既存アプリで異なるインストール手順と作業順序

新規ならphp artisan filament:install --scaffoldにnpmのインストールとビルドを続ける流れで、認証まわりを含めた土台がそろいます。既存アプリではcomposer requireでパッケージを入れたあと、パネル用の初期化を実行し、管理者ユーザーをphp artisan make:filament-userで作る順序になります。

注意したいのは、既存アプリ側にすでに認証の仕組みがある場合です。Filamentのパネルは独自のログイン経路を持つため、既存のユーザーテーブルとどう突き合わせるかを先に決めないと、ログイン導線が二重になります。管理者だけがパネルに入れる制御を初期段階で入れておくのが安全です。

Tailwind CSS 4系への移行が既存のCSS資産と衝突する場面

Tailwind CSS v4.1以上という要件は、既存アプリにとって軽い条件ではありません。3系で書かれた設定ファイルや、独自にビルドしているCSSがある場合、Filamentの導入がフロントのビルド構成の作り直しを連れてきます。

この衝突を避ける手段が、管理画面を別アプリとして切り出す構成です。エンドユーザー向けの画面と管理画面でリポジトリを分け、データベースだけ共有する形にすれば、フロントの構成を独立させられます。運用するサーバーが増える代わりに、片方のバージョン上げがもう片方を巻き込まなくなります。どちらを取るかは、既存アプリのフロント資産の量で決めてください。

スターターキットの再編とFilamentの位置づけの重なり方

Laravelの公式スターターキットは再編され、BreezeとJetstreamは新規案件向けの選択肢から外れました。この経緯と移行先についてはLaravel Breeze・Jetstreamはなぜ非推奨に？スターターキット（React/Vue/Livewire）への移行と代替案で詳しく扱っています。

両者の守備範囲は違います。スターターキットが用意するのは認証とプロフィール編集までで、業務データのCRUD画面は含まれません。Filamentが埋めるのはその先です。したがってスターターキットを入れたからFilamentは不要という関係にはならず、認証をどちらに持たせるかだけを決めれば併用できます。

有償のLaravel Novaとのライセンス費用と実装スタイルの違い

管理画面パッケージの比較では、Novaが対抗馬に挙がります。判断材料は費用だけではありません。

Novaの価格体系と、無償のFilamentで発生しない費用の内訳

2026年8月29日時点の公式サイトによると、Novaのライセンスは2種類です。単一プロジェクト向けのSingleが初回99ドルで更新が年79ドル、プロジェクト数無制限のUnlimitedが初回299ドルで更新が年249ドルとされています。Unlimitedにはメールサポートが含まれます。

比較項目	Filament	Laravel Nova
ライセンス	MIT・無償	商用・有償
初回費用	なし	99ドルから
年次更新	なし	79ドルから
拡張の基盤	Livewire	Vue.js
サポート窓口	コミュニティ	上位版にメール

金額の差は、受託開発では見た目ほど大きくありません。ライセンス費用が案件の総額に占める比率は小さく、実装工数の差のほうが効きます。費用だけで決める材料にはならないと考えてください。

拡張の書き方がVueかLivewireかで変わる要員のそろえ方

標準機能で足りない画面を作るとき、Novaはカスタムフィールドやカスタムツールをフロント側で組む設計で、Vue.jsの知識が要ります。FilamentはLivewireのコンポーネントとして書けるため、PHPの範囲で完結させやすくなります。

チーム編成に直結する違いです。サーバーサイドのエンジニアだけで管理画面まで作り切りたいなら、Filamentのほうが要員をそろえやすくなります。逆に、フロントにVue.jsの資産と担当者がすでにいるなら、Novaの拡張コストは低く見積もれます。手元の要員構成から逆算するのが実務的な選び方です。

公式サポートの有無が調達要件になる案件での製品選定に用いる判断基準

官公庁や大企業の案件では、採用したソフトウェアの問い合わせ窓口を求められることがあります。OSSであるFilamentには商用の窓口がなく、この要件を単体では満たせません。Novaは有償ライセンスの上位版にメールサポートが付きます。

ただし実務では、開発会社が保守契約の中で一次窓口を引き受ける形で要件を満たす例が多くあります。この場合に問われるのは、パッケージ側のサポートではなく開発会社の体制です。提案書を書く前に、発注者がどちらを求めているのかを確認しておくと手戻りが減ります。

業務システムの管理画面にFilamentを採用する条件と見送る場面

ここからは受託開発の現場で、採否をどう決めているかを条件の形で言い切ります。

短工数で組める条件となるモデルとリレーションの設計を見極める判断基準

Filamentで工数が縮むのは、Eloquentの規約に沿ったテーブル設計になっている案件だけです。新規開発でこちらがテーブルを設計できるなら、この条件はほぼ満たせます。採用してよい典型は、新規の業務システムで、管理対象が20から40モデル程度、画面の要件がCRUDと検索と一括操作に収まるケースです。

この範囲なら、画面ごとに手書きする場合と比べて管理画面の実装工数を減らせる条件です。浮いた工数は、業務ロジックの作り込みとテストに回せます。管理画面を含む業務アプリの受託開発については業務用・Webアプリ開発で、設計から運用までの進め方を紹介しています。

エンドユーザー向け画面に広げると割に合わなくなる採否の分岐点

Filamentの画面は、管理者が業務として使う前提で設計されています。エンドユーザー向けの画面に転用しようとすると、既定のレイアウトを外す作業が積み上がります。分岐点は明確です。デザインカンプが用意され、そのとおりに再現する要件があるなら、Filamentは選びません。

パネルの配色やロゴの差し替え程度なら標準機能の範囲です。しかし画面ごとに独自のレイアウトを組むなら、枠組みと戦うことになります。会員向けのマイページのような画面は、素直にBladeかフロントのフレームワークで作り、管理画面だけをFilamentに任せる分業が扱いやすい構成です。

権限設計とマルチテナントを後付けする場合に増える手戻りの範囲

見落とされやすいのが権限です。管理者は全件を触れるという単純な設計で作り始め、あとから支店の担当者は自支店のデータだけという要件が出てくると、一覧のクエリ、編集画面の可否、一括操作の対象範囲を横断で見直すことになります。

テナントごとにデータを分ける要件も同じです。Filament側にテナント分離の仕組みはありますが、途中から入れる場合は既存のResource全体に影響します。要件定義の段階で、権限の軸が役割だけなのか、役割と所属の組み合わせなのかを確定させ、後者なら最初からその前提でPanelとResourceを設計してください。

受託開発でFilamentを採用する際に見積り前へ倒す5つの確認項目

提案前に確認しておきたい項目は5つです。稼働環境のPHPが8.2以上か、Laravelが11.28以上か、既存フロントがTailwind CSS 4系へ上げられるか、テーブル設計を規約に沿って作れるか、権限の軸が2つ以上あるか。この5つのうち3つ以上で引っかかるなら、Filamentを前提にした見積りは危うくなります。

逆に5つとも問題がなければ、管理画面の工数を圧縮した提案が組めます。見送る判断も含めて、確認を見積りより前に済ませておくことが、着手後の作り直しを防ぎます。