Laravelで小さな管理画面を作る——ディレクターが知っておく構造

Laravelで小さな管理画面を頼むとき、ディレクターが決めておくべきことは 「どんなテーブルがあるか」「どのURLで何ができるか」「誰が何をしてよいか」 の3つです。コードが書けなくても、この3つが言葉になっていれば、見積もりも画面設計もぶれにくくなります。私はお知らせ管理や問い合わせ一覧のような小さな管理画面を、この順番で整理しています。

なお、2026年10月時点の公式のリリースノートでは、Laravel 13は2026年3月17日リリースで、PHP 8.3以上が必要とされています。既存案件で古いバージョンが動いていることも多いので、最初にバージョンとサポート期限を確認するようにしています。

フォルダ構成は「どこに何が書かれるか」の地図

公式のディレクトリ構成のページを、私はディレクター向けにこう読み替えています。

場所	中身	ディレクターが気にすること
routes/web.php	URLと処理の対応表	画面一覧と一致しているか
app/Models	テーブルごとのモデル	データ項目の抜け漏れ
app/Http/Controllers	画面ごとの処理	1画面で何をさせるか
resources/views	画面のテンプレート	デザインの差し込み先
database/migrations	テーブル定義の変更履歴	項目追加の影響範囲

全部を読む必要はありません。私が打ち合わせで実際に開くのは、routes/web.php と database/migrations の2か所くらいです。

テーブルは「マイグレーション」で履歴として残る

公式のマイグレーションの説明では、マイグレーションはデータベースのバージョン管理のようなもの、とされています。テーブルの作成や「項目を1つ足す」といった変更が、1ファイルずつ時系列で残る仕組みです。

ディレクションの目線では、これは 「項目追加は1回ごとに作業と確認が発生する」 という意味になります。お知らせに「公開日」を足す、あとから「カテゴリ」を足す、と小出しにすると、そのたびにマイグレーション、モデル、フォーム、一覧表示を直すことになります。だから私は、要件定義の段階で項目を表にしておき、「あとから足しそうな項目」も一度は候補として出すようにしています。

URLは「リソース」の7つの操作で考える

Laravelには、一覧・作成・保存・詳細・編集・更新・削除の7つの操作を、1行のルート定義でまとめて用意するリソースコントローラーがあります。たとえば Route::resource('photos', ...) と書くと、/photos（一覧）や /photos/{photo}/edit（編集）といったURLが決まった名前で並びます。

管理画面の画面一覧は、この7つに当てはめると整理しやすくなります。

• お知らせ：7つ全部が必要
• 問い合わせ：一覧と詳細だけ（作成・編集は管理側では不要）
• 設定：1件しかないので、一覧のない形にする

「どの画面が要らないか」を先に決めると、見積もりから不要な画面が外れます。公式ドキュメントでも、only や except で必要な操作だけに絞る方法が紹介されています。

権限は「ログインできる」と「操作してよい」を分ける

小さな管理画面でつまずきやすいのが権限です。Laravelの認可のドキュメントでは、ログインしているユーザーでも、特定のデータを更新・削除してよいとは限らない、という前提で、ゲート（クロージャで書く単純な判定）とポリシー（モデルごとに判定をまとめるクラス）の2つが用意されています。

私が要件で書くのは、次のような表です。

役割	お知らせ	問い合わせ	設定
管理者	全操作	閲覧・削除	編集
編集者	作成・編集	閲覧のみ	なし

この表があれば、エンジニアはポリシーに落とし込めますし、テストのときも確認すべき組み合わせがはっきりします。逆に「管理者だけ使う想定です」で済ませると、あとで「アルバイトにも入力だけさせたい」と言われたときに手戻りが大きくなります。

明日から試せる一手

次に管理画面の相談を受けたら、打ち合わせのメモを3枚に分けてみてください。1枚目に「テーブルと項目」、2枚目に「データごとに7つの操作のうちどれが要るか」、3枚目に「役割×操作の表」。Laravelで作るかどうかが決まる前でも、この3枚はそのまま要件定義書の芯になります。