公開日 2026-03-23

Laravel 13のStarter Kitsで認証付きアプリを始める

Laravel 13 の Starter Kits を公式 docs ベースで整理し、空ディレクトリから Livewire Starter Kit を使って認証付きアプリを始める手順をまとめる。

目次

  1. 前提環境
  2. 1. ゴールと非対象
  3. 2. Laravel 13 では認証の入口をどう理解するか
  4. 3. Starter Kit の選択肢をざっくり整理する
  5. 4. 作業前提をそろえ、Laravel Installer を必要なら更新する
  6. 5. 空ディレクトリから Starter Kit 付きアプリを作る
  7. 6. register / login / logout と認証済み画面を確認する
  8. 7. Starter Kit が面倒を見る範囲と、ここから先に足すもの
  9. 8. 既存の Breeze 記事との役割差
  10. 9. まとめ

Laravel 13 で認証付きアプリを始めたいが、いまの公式 docs では Breeze 単体より Starter Kits が入口になっており、どこから読めばよいかで迷いやすい読者向けの記事です。

Starter Kits の位置づけを整理し、空ディレクトリから Livewire Starter Kit を使って register / login / logout と認証済み画面の確認まで進めます。既存プロジェクトへ認証だけを後付けしたい場合は、末尾の補助リンクから Laravelで認証を足す(Breeze 最小導入) を参照してください。

Starter Kit は、認証に必要な route / controller / view などをまとめて用意する Laravel の初期構成です。この記事では、その中でも Livewire Starter Kit を使って browser 向け認証の入口を確認します。

シリーズ内の既存 Laravel 記事は WSL 上の Docker を主線にしていますが、この記事ではあえて Laravel 13 の公式な入口に寄せ、laravel new と Starter Kit 選択をそのまま扱います。認証の始め方そのものをつかむのが主題で、Docker の compose 準備まで同時に入れると論点が増えるためです。

前提環境

  • Windows 11
  • WSL2(Ubuntu)
  • PHP 8.3 以上
  • Composer
  • Node.js 24.x LTS と npm(WSL 側)
  • Laravel Installer
  • SQLite

以降のコマンドは、特記がない限り WSL 側のターミナルで実行します。

1. ゴールと非対象

この記事で到達する状態:

  • Laravel 13 の認証入口を Starter Kits 基準で理解できる
  • React / Vue / Svelte / Livewire のざっくりした違いを把握できる
  • 空ディレクトリから Starter Kit 付きアプリを作成できる
  • register / login / logout と認証済み画面の表示を確認できる
  • Starter Kit が面倒を見る範囲と、自分で足す範囲を切り分けられる

今回は fresh app で認証を始める入口に絞ります。既存 CRUD への後付け、Policy による認可、Sanctum / Passport を使う API 認証、WorkOS variant の詳細設定は扱いません。

2. Laravel 13 では認証の入口をどう理解するか

Laravel 13 の auth docs では、quickstart の最初に Starter Kit のインストールが置かれています。starter kits docs でも、Starter Kit は認証に必要な routes / controllers / views をまとめて用意し、認証処理には Laravel Fortify を使うと説明されています。

Laravel 13 で browser 向けの認証付きアプリを fresh app から始めるなら、まずは laravel new で Starter Kit を選ぶのが公式の主線です。Breeze を後付けするやり方が消えたわけではありませんが、公式 docs の入口はそこではありません。

flowchart LR
    A[laravel new] --> B[Starter Kit を選ぶ]
    B --> C[Fortify ベースの認証一式]
    C --> D["register / login / logout"]
    D --> E[auth middleware で保護した画面]

release notes では、Laravel 13 の最小 PHP バージョンは 8.3 です。upgrade docs では、Laravel Installer を使って新規アプリを作る場合、composer global update laravel/installer で installer を最新にしておくよう案内しています。fresh app を作る今回の手順では、Laravel 13 用に更新済みの installer を使うところが最初の確認ポイントです。

upgrade docs にある PreventRequestForgery への変更も、fresh app を Starter Kit 付きで生成する限りは生成済みスキャフォールドが最新状態を持つため、この記事では「新規作成側では追従作業を意識しなくてよい」と理解しておけば十分です。既存アプリを 12 から 13 へ上げる話とは分けて考えます。

3. Starter Kit の選択肢をざっくり整理する

Laravel 13 の starter kits docs にある現行の主な選択肢:

選択肢向いているケース主な前提
Reactフロントを React で書きたいInertia 2、React 19、TypeScript、Tailwind、shadcn/ui
Vueフロントを Vue で書きたいInertia 2、Vue 3、TypeScript、Tailwind、shadcn-vue
Svelteフロントを Svelte で書きたいInertia 2、Svelte 5、TypeScript、Tailwind、shadcn-svelte
LivewirePHP / Blade 寄りの感覚で進めたいLivewire 4、Tailwind、Flux UI
WorkOS variantSSO、social login、passkey、Magic Auth を最初から入れたいWorkOS アカウント、環境変数設定

今回採用するのは Livewire Starter Kit です。理由は 3 つあります。

  • Laravel 13 の公式選択肢であり、fresh app の認証入口として素直に説明できる
  • React / Vue / Svelte の選定を同時に済ませなくても、ブラウザ向け認証付きアプリを最短で動かせる
  • WorkOS のような外部サービス前提を増やさず、記事単体で完結しやすい

なお、Livewire が常に最良という話ではありません。フロントを React や Vue で進める前提が固まっているなら、その Starter Kit を選ぶほうが整理しやすくなります。今回は「Laravel 13 では認証の入口をどう始めるか」を主題にしているため、余分な意思決定を増やしにくい Livewire を採ります。

Breeze を今回の主役にしない理由もここにあります。Breeze は既存プロジェクトへ最小差分で認証を足したい場面では便利ですが、Laravel 13 の公式 docs が fresh app の入口として前面に置いているのは Starter Kit の選択です。

4. 作業前提をそろえ、Laravel Installer を必要なら更新する

次の章で laravel new を実行できる状態かを確認します。この記事では Starter Kit の公式導線に寄せるため、まず PHPLaravel Installer が通るかを見ます。

最初に、Windows 側の PowerShell から WSL の Ubuntu へ入ります。

wsl

WSL に複数のディストリビューションがある場合は、wsl -l -v で名前を確認してから、起動したい Ubuntu を指定します。

wsl -l -v
wsl -d Ubuntu-24.04

以降の bash コマンドは、このあと開いた WSL 側のターミナルで実行します。表示が username@pc-name:~$ のように変わっていれば、WSL 側へ入れています。

php -v
laravel --version

次の状態なら十分です。

確認コマンド先に見たいポイント詰まったときの対応
php -vPHP 8.3 以上になっているPHP を 8.3 以上へ更新する
laravel --versionバージョンが表示されるlaravel コマンドが見つからないなら Laravel Installer を導入する

Laravel 13 は PHP 8.3 以上が前提です。php -vlaravel --version が通るなら、この章はひとまず通過して問題ありません。

laravel コマンドが見つからない場合は、WSL 側で Laravel Installer を入れます。composer が使えるなら、次を実行してください。

composer global require laravel/installer

実行後はいったん WSL のターミナルを開き直し、もう一度確認します。

laravel --version

composer も見つからない、あるいは PHP と Composer をまとめて入れ直したい場合は、Laravel 13 の installation docs にある Linux 用セットアップコマンドを使うほうが早いです。WSL の Ubuntu では次を実行します。

/bin/bash -c "$(curl -fsSL https://php.new/install/linux/8.4)"

このコマンドは PHP、Composer、Laravel Installer をまとめて導入します。実行後はターミナルを開き直し、次を確認してください。

php -v
composer --version
laravel --version

そのうえで、次の章では ComposerNode.js も使うため、未導入でないかだけ簡単に確認しておきます。ここで見るのは Windows 側ではなく WSL 側です。Windows に Node.js が入っていても、WSL 側で nodenpm が通らなければ今回の手順ではそのまま使えません。

composer --version
node -v
npm -v

ここは「バージョンを細かく読む」より、「コマンドが通るか」を見る段階です。composernodenpm が WSL 側で見つかれば、Starter Kit 付きアプリの作成と build を進められます。

もし node -vnpm -v が WSL 側で通らないなら、先に Node.js 公式サイト で WSL / Linux 向けの導入方法を確認し、WSL 側へ Node.js と npm を入れてから次の章へ進んでください。

Laravel Installer を composer global require laravel/installer で入れていて、次の章の laravel new で Starter Kit の選択肢が出てこない場合は、そこで更新を入れます。

composer global update laravel/installer

毎回先に更新するより、「Starter Kit の prompt が出ないときだけ疑う」と覚えるほうが初回は迷いません。今回の手順は laravel new を前提にしているため、installer が古いままだと Starter Kit の選択画面が揃わない場合があります。

Herd の bundled installer を使っている場合は、composer global update laravel/installer ではなく Herd 側を最新化してください。

5. 空ディレクトリから Starter Kit 付きアプリを作る

開始位置をそろえるため、空の作業ディレクトリを作ります。

mkdir -p ~/projects
cd ~/projects
laravel new laravel13-starter-kits-auth-demo
cd laravel13-starter-kits-auth-demo
code .

laravel new の質問は、今回の環境では次の順で表示されました。回答もこの並びにそろえます。

  1. Starter kit: Livewire
  2. Authentication provider: Laravel's built-in authentication
  3. Single-file Livewire components: Yes
  4. Testing framework: PHPUnit
  5. Laravel Boost: No
  6. Would you like to run npm install and npm run build?: Yes

質問順は次の画面のように進みます。

laravel new の質問順

最後の build 確認は別画面で表示されます。

npm build 確認プロンプト

Single-file Livewire components は、今回の画面のように既定の Yes のままで構いません。この記事で優先したいのは、Livewire の構成差の比較ではなく、まず auth 画面が生成されることの確認です。

Laravel Boost は AI 支援開発を強化する追加導入です。今回は No のままにして、認証の確認へ絞ります。認証導線の確認だけなら、ここで足さなくても困りません。

database はこの prompt では聞かれません。生成後は既定の SQLite 構成で始まるため、最短で認証導線を確認しやすくなっています。別の RDBMS を使いたい場合は、あとから .envDB_* を切り替えたうえで migration を通します。

そのあと、Application key set successfully. の表示に続いて Would you like to run npm install and npm run build? と聞かれます。4章で WSL 側の node -vnpm -v が通るところまで確認している前提なので、ここは Yes で進めます。Starter Kit の画面表示に必要な frontend asset をそのまま準備できるためです。

もし prompt に Starter Kit が出てこないなら、installer の更新漏れを先に疑ってください。Laravel 13 の official flow に合わせるなら、ここで Starter Kit を選べる状態が前提です。

生成が終わったら、migration と開発サーバー起動を確認します。この記事の主線は prompt で Yes を選ぶ流れなので、ここではその前提で進めます。

php artisan migrate
composer run dev

何らかの事情で prompt では No を選んだ場合だけ、composer run dev の前に npm installnpm run build を手動で実行してください。

installation docs では npm install && npm run build の後に composer run dev を案内しています。これで開発サーバー、キュー監視、Vite まわりのローカル開発タスクをまとめて起動できます。

php artisan migrate は、Installer 側ですでに走っていても問題ありません。追加 migration がなければ Nothing to migrate. になるだけなので、開始位置を確認するコマンドとして入れておくと手戻りが減ります。

http://localhost:8000 を開くと、Starter Kit の guest 向け welcome 画面が表示されます。

Starter Kit の welcome 画面

まだ開発サーバーを起動していない段階では、次のような Vite 側の案内画面が出ることがあります。その場合は composer run dev を実行してから開き直してください。

Vite の案内画面

6. register / login / logout と認証済み画面を確認する

開発サーバーが起動したら、ブラウザで http://localhost:8000 を開きます。Starter Kit 付きの fresh app では、guest 向けの welcome 画面から RegisterLog in へ進める状態になっています。

確認する順番:

  1. http://localhost:8000/register を開く
  2. 新規ユーザーを作成する
  3. 認証済み画面へ遷移することを確認する
  4. いったん logout する
  5. http://localhost:8000/login から同じユーザーで再ログインする

入力に迷う場合は、たとえば次の値で確認できます。

項目入力例
NameTaro Yamada
Email addresstaro@example.com
PasswordStarterKitDemo123!
Confirm PasswordStarterKitDemo123!

Register 画面の入力欄は、次のように並びます。

Register 画面

登録に成功すると、認証済みの dashboard へ遷移します。

認証済み画面

登録が終わったら、この Email addressPassword をそのまま /login でも使います。Confirm Password は登録画面だけにある確認欄なので、ログイン画面では出てきません。

logout 後の login 画面:

Login 画面

auth docs では、Starter Kit を入れた fresh app で /register や他の認証用 URL を開けば認証導線を確認できると説明されています。Starter Kit 側で login throttling も自動適用されるため、ログイン試行回数の基本的な防御まで含めて最初の形が用意されています。

route が生成されていることも確認しておきます。

php artisan route:list | grep -E 'login|register|logout|dashboard'

route:list の出力例は次のようになります。

認証関連 route の一覧

/login/register/logout、認証後に入る画面の route が並んでいれば、Starter Kit が auth routes を生成できています。starter kits docs でも php artisan route:list を確認手段として案内しています。

Laravel の auth docs では、認証済みユーザーの取得や route 保護は auth middleware を使う前提で説明されています。Starter Kit はその入口を一式そろえるところまで受け持ち、そこから先にアプリ固有の画面を足していく流れです。

7. Starter Kit が面倒を見る範囲と、ここから先に足すもの

Starter Kit が最初から用意してくれるものを整理すると、次のようになります。

Starter Kit が用意するものここから自分で足すもの
register / login / logout の導線業務画面の route / controller / view
Fortify ベースの認証処理Policy / Gate などの認可
認証用の画面レイアウトとフォームドメインモデル、CRUD、検索、一覧改善
パスワードリセットや email verification などの feature 切り替え基盤Social login、SSO、WorkOS 連携などの外部 auth
web 向けセッション認証の初期構成API 認証としての Sanctum / Passport

自分の画面を認証必須にしたいときは、auth docs にあるとおり auth middleware を付けて route を保護します。

Route::middleware('auth')->group(function () {
    Route::get('/books', function () {
        return view('books.index');
    })->name('books.index');
});

Starter Kit は「認証の入口」をそろえるものであって、アプリ固有の画面設計まで自動では決まりません。たとえば books 一覧を作るなら route、controller、view、migration は自分で追加します。所有者ごとに編集可否を分けたいなら、その先に Policyuser_id の設計が要ります。

Starter Kit 側の feature を減らしたい場合は、starter kits docs にある config/fortify.php の feature 設定を見直します。公開登録を止めたいなら registration を外す、password reset を使わないならその feature を外す、という整理です。

8. 既存の Breeze 記事との役割差

ここまでの内容は、Laravel 13 の公式 docs に沿って fresh app から認証付きアプリを始める手順です。役割としては「これから新しく始めるときの入口」に当たります。

一方で Laravelで認証を足す(Breeze 最小導入) は、すでにある CRUD プロジェクトへ認証だけを後付けする記事です。開始位置が違うので、使い分けは次のように考えると迷いにくくなります。

補助導線として、基礎から入りたい場合は Laravel入門(Route / Controller / View / Model 最小構成)Laravelで最小CRUDを作る(一覧 / 作成 / 編集 / 削除) も参照できます。ただし、この記事を進めるための必須前提ではありません。

9. まとめ

Laravel 13 で browser 向け認証付きアプリを fresh app から始めるなら、まず見るべき入口は Starter Kits です。Starter Kit は Fortify ベースの認証導線をまとめて用意し、register / login / logout と認証済み画面の最初の形までを短時間でそろえてくれます。

今回 Livewire を採ったのは、Starter Kit 全体の選択肢を整理したうえで、余分な前提を増やさずに Laravel 13 の現行 auth 導線を確認しやすいからです。認証必須の業務画面、認可、外部 auth provider の導入は、アプリの要件に合わせて順に追加してください。