php artisan makeコマンド一覧｜Laravel 13対応 全37種の生成先・オプション早見表

php artisan make は、Laravel がモデル・コントローラー・ミドルウェアなどの雛形ファイルを生成するコマンド群です。日本語で読める一覧記事の多くは Laravel 5 から 8 の時代に書かれており、Laravel 11 で生成物の登録先が config/app.php から bootstrap 配下へ移った変更も、Laravel 13 で make:command の雛形が属性形式に変わった変更も反映されていません。この記事では、2026年10月20日に公開された Laravel 13.38.0 の新規プロジェクトで全コマンドを実行し、生成先・オプション・エラーメッセージを実測した結果をまとめます。

まとめ

• Laravel 13.38.0 の新規プロジェクトで php artisan list make を実行すると、make:系は37種類です。モデル・ビュー・設定ファイルなどを生成する31種と、フレームワーク機能用のテーブルマイグレーションを生成する6種に分けて紹介します。
• make:model –all が生成するのはモデル込みで8ファイルです。マイグレーション・ファクトリ・シーダー・ポリシー・コントローラーに加え、Store用とUpdate用のフォームリクエストが2本作られます。
• Laravel 13 の make:command は、$signature プロパティではなく #[Signature] 属性でコマンド名を定義する雛形を出力します。従来のプロパティ形式も引き続き動きます。
• make:provider は生成と同時に bootstrap/providers.php へ追記され、make:middleware の登録先は bootstrap/app.php です。config/app.php は存在しますが、サービスプロバイダ登録用の providers 配列はありません。app/Http/Kernel.php は既定の雛形にありません。
• make:service は存在しません。実行すると Command "make:service" is not defined. で終了コード1になります。make:class Services/InvoiceService が最短の代替です。

php artisan makeコマンドの全体像と生成先一覧

make:系コマンドは php artisan make:<種類> <名前> という共通の形をとり、成功すると INFO Model [app/Models/Invoice.php] created successfully. のように生成したファイルのパスを1行ずつ表示します。どこにファイルができるかを先に知っておけば、生成後に探し回らずに済みます。

モデル・ビュー・設定などを生成する31種の生成先とオプション

下表は 13.38.0 の新規プロジェクトで各コマンドを実行し、生成されたパスと php artisan help に出るオプションを書き写したものです。--force と、テスト同時生成用の --test --pest --phpunit は多くのコマンドに共通するため表から省きました。「導入」列が空欄のものは Laravel 10 以前からあるコマンドです。

make:enum・make:interface・make:trait・make:scope の4つは、既存のディレクトリを検出して生成先を切り替えます。実測では、新規プロジェクトで php artisan make:enum Status --string を実行すると app/Status.php に、mkdir app/Enums の後に make:enum Priority --int を実行すると app/Enums/Priority.php にできました。判定順は enum が Enums→Enumerations→app 直下、interface が Contracts→Interfaces→app 直下、trait が Concerns→Traits→app 直下、scope は app/Models が存在すれば Models/Scopes、存在しなければ Scopes です。プロジェクトの慣習に合わせて最初にディレクトリを作っておけば、以降は名前だけで揃います。

テーブル用マイグレーションを生成する6種と雛形への同梱状況

残り6種は、セッションやキューなどフレームワークの機能が使うテーブルのマイグレーションを生成します。Laravel 10 までは session:table のような名前でしたが、Laravel 11 で make: の名前空間へ移りました。11.x の SessionTableCommand は旧名を aliases に残しているため、古い手順のまま打っても動きます。

Laravel 11 以降の新規プロジェクトには、0001_01_01_000000 から 000002 までの3本のマイグレーションが最初から入っており、sessions・cache・jobs・job_batches・failed_jobs はそこで作られます。セッションやキューをデータベースで使う準備として make:session-table や make:queue-table を打つ手順は、Laravel 11 以降の新規プロジェクトでは不要です。既存ファイルを検出してエラー終了するだけなので害はありませんが、手順書から外して構いません。Laravel 10 以前から移行したプロジェクトで、これらのテーブルが未作成の場合にだけ使います。

クラス生成コマンドの名前空間指定と短縮オプションの違い

名前にスラッシュを含めると、その階層がそのまま名前空間とディレクトリになります。App\Http\Controllers\Admin のようなサブ名前空間を作りたいときも、ディレクトリを先に掘る必要はありません。

上書き用の --force は全コマンドにあるわけではありません。make:middleware・make:seeder・make:factory・make:migration には存在せず、php artisan make:middleware EnsureTokenIsValid --force は The "--force" option does not exist. で失敗しました。短縮形も揃っておらず、make:request や make:command では -f が --force ですが、make:model の -f は --factory です。php artisan make:model Receipt -f を実行すると、上書きではなく ReceiptFactory.php が追加で生成されました。make:controller の --force には短縮形がありません。上書きしたいときは短縮形を使わず --force と書くのが安全です。

# サブディレクトリ付きで生成すると App\Http\Controllers\Admin\UserController になる
php artisan make:controller Admin/UserController

# そのプロジェクトで使えるmake:系を一覧表示（パッケージが追加したものも出る）
php artisan list make

# 個別コマンドの引数とオプションを確認
php artisan help make:model

Livewire や Filament などのパッケージも独自の make:系コマンドを追加するため、実機で何が使えるかは上の表より php artisan list make の出力が正確です。その artisan が指しているフレームワーク本体の版を確かめる方法はLaravelのバージョン確認方法｜最新バージョンは13・artisanとcomposerの違いとサポート期限で扱っています。Filament が追加する make:filament-resource が何を生成するかはLaravel Filamentとは？管理画面を短工数で作る構成とNovaとの選択基準にまとめました。

よく使うmake:コマンドの実行例とオプション

37種のうち日常的に叩くのは一部に偏ります。ここでは組み合わせで生成物が変わり、オプションの理解が結果を左右する3つを取り上げます。生成済みのキャッシュを消す側のコマンドはLaravelのキャッシュクリア｜cache:clearとoptimize:clearの違いと本番デプロイの手順で整理しています。

make:modelの–allで生成される8ファイル

make:model はモデル本体に加えて関連クラスをまとめて生成できます。-m（マイグレーション）・-f（ファクトリ）・-s（シーダー）・-c（コントローラー）・-r（リソースコントローラー）・-R（フォームリクエスト）・--policy を個別に組み合わせるか、-a（--all）で一括指定します。

$ php artisan make:model Invoice --all

 INFO Model [app/Models/Invoice.php] created successfully.
 INFO Factory [database/factories/InvoiceFactory.php] created successfully.
 INFO Migration [database/migrations/2026_10_26_044852_create_invoices_table.php] created successfully.
 INFO Seeder [database/seeders/InvoiceSeeder.php] created successfully.
 INFO Request [app/Http/Requests/StoreInvoiceRequest.php] created successfully.
 INFO Request [app/Http/Requests/UpdateInvoiceRequest.php] created successfully.
 INFO Controller [app/Http/Controllers/InvoiceController.php] created successfully.
 INFO Policy [app/Policies/InvoicePolicy.php] created successfully.

出力のとおり、–all はモデル込みで8ファイルを作ります。ModelMakeCommand はコントローラー生成時に '--requests' => $this->option('requests') || $this->option('all') を渡しており、–all を付けるとフォームリクエストも立ちます。この分岐は Laravel 9.0.0 のソースの時点で入っているため、「–all は5ファイル（モデル込み6）」と書いた古い記事は9以降の実態と合いません。help の説明文も Generate a migration, seeder, factory, policy, resource controller, and form request classes for the model です。

# モデル＋マイグレーション＋リソースコントローラー＋フォームリクエスト（ファクトリ・シーダー・ポリシーは作らない）
php artisan make:model Invoice -mrR

設計が固まっていない段階では -m だけで始め、必要になった時点で個別に足すほうが、使わないシーダーやポリシーを抱えずに済みます。-p は多対多の中間テーブルに追加カラムを持たせるときのモデル（Pivot 継承）を生成するオプションです。モデル名・テーブル名の単数形と複数形の付け方はLaravelの命名規則一覧｜テーブル・モデル・コントローラーとコーディング規約【Laravel 13対応】にまとめています。

make:controllerのリソース・API・シングルアクションの作り分け

make:controller は空のクラスを作るのが既定動作です。CRUD の7メソッド（index・create・store・show・edit・update・destroy）を持つ雛形が欲しい場合は --resource、画面を返さない API 用に create と edit を除いた5メソッドが欲しい場合は --api を付けます。1つの処理しか持たないコントローラーには --invokable（-i）で __invoke メソッドだけのクラスを作ります。

# CRUD 7メソッドのリソースコントローラー（引数にモデルの型宣言が入る）
php artisan make:controller InvoiceController --resource --model=Invoice

# API向け（create・editを除く5メソッド）
php artisan make:controller Api/InvoiceController --api --model=Invoice

# ユーザーごとに1つしかないリソース（--creatable で作成系メソッドも追加）
php artisan make:controller ProfileController --singleton --creatable

--model を併用すると各メソッドの引数にモデルの型宣言が入るため、ルートモデルバインディングを使う前提なら指定しておくと書き足す手間が減ります。--parent=（-p）は /invoices/{invoice}/items のような入れ子リソース用です。API のレスポンス整形まで含めた組み立て方はLaravel APIの作り方｜install:apiとAPIリソース・エラー応答の統一で扱っています。

make:requestの生成直後はauthorizeがfalse

make:request が生成するフォームリクエストには authorize と rules の2つのメソッドが入ります。authorize が false を返すとバリデーション以前に 403 が返ります。13.38.0 で生成したファイルを確認すると、authorize の中身は return false; のままでした。

$ php artisan make:request StoreInvoiceRequest
$ grep -n -A3 "function authorize" app/Http/Requests/StoreInvoiceRequest.php
13:    public function authorize(): bool
14-    {
15-        return false;
16-    }

生成直後のフォームリクエストを適用した処理では、authorize が false を返すため 403 になります。認可が不要なら true に、必要ならポリシーや $this->user() を使った判定式に書き換えてから使ってください。403 が返って rules の検証まで進まないときに最初に見るのも、この authorize の戻り値です。コントローラーの validate との使い分けやカスタムルールはLaravelのバリデーション｜validateとFormRequestの使い分け・カスタムルール・JSON応答にまとめています。

make:commandで独自のArtisanコマンドを作る手順

定期バッチやデータ移行スクリプトを Artisan コマンドとして作るときに使うのが make:command です。雛形の形は Laravel 13 で変わったため、12 以前の記事のコードと見た目が一致しません。

Laravel 13で#[Signature]属性に変わった雛形

13.38.0 で php artisan make:command SyncInvoices を実行すると、app/Console/Commands/SyncInvoices.php に次のクラスができます。

<?php

namespace App\Console\Commands;

use Illuminate\Console\Attributes\Description;
use Illuminate\Console\Attributes\Signature;
use Illuminate\Console\Command;

#[Signature('app:sync-invoices')]
#[Description('Command description')]
class SyncInvoices extends Command
{
    /**
     * Execute the console command.
     */
    public function handle()
    {
        //
    }
}

コマンド名は --command= を省くと app: にクラス名のケバブケースを付けた名前になります。12.x までの console.stub は protected $signature と protected $description のプロパティで定義する形でした。stub が属性形式に変わったのは 2026年2月13日のコミット（laravel/framework #58578）で、v13.0.0 から含まれます。13.x の Artisan Console ドキュメントも Command Structure の例を Signature・Description 属性で示しています。

移行で書き直す必要はありません。13.38.0 上で protected $signature = 'legacy:run'; のプロパティ形式のクラスを置いて実行したところ、問題なく動きました。同じドキュメントでも引数・オプションの節はプロパティ形式の例のままなので、どちらで書いても構いません。チーム内ではどちらかに揃えておくと読みやすくなります。

引数・オプションの定義と終了コードの返し方

引数は {名前}、値なしのオプションは {--名前}、値ありは {--名前=} で書き、コロンの後ろに説明を付けられます。以下は生成済みファイルの namespace と use 宣言を残し、属性とクラス定義を差し替える例です。同期処理自体は省略しています。handle が整数を返すとそれが終了コードになるため、cron や CI から呼ぶコマンドは失敗時に self::FAILURE を返すようにしておきます。

#[Signature('invoices:sync {month : 対象月 (YYYY-MM)} {--dry-run : 書き込まずに件数だけ表示}')]
#[Description('指定月の請求書を外部会計へ同期する')]
class SyncInvoices extends Command
{
    public function handle(): int
    {
        $month = $this->argument('month');
        if (! preg_match('/\A\d{4}-(0[1-9]|1[0-2])\z/', $month)) {
            $this->error("月の形式が不正です: {$month}");
            return self::FAILURE;
        }
        $this->info(($this->option('dry-run') ? '[dry-run] ' : '')."{$month} の同期を開始します");
        return self::SUCCESS;
    }
}

$ php artisan invoices:sync 2026-10 --dry-run; echo rc=$?
[dry-run] 2026-10 の同期を開始します
rc=0
$ php artisan invoices:sync 2026/10; echo rc=$?
月の形式が不正です: 2026/10
rc=1

handle に業務処理とコンソール入出力をまとめると、コントローラーやキュージョブから業務処理だけを再利用しにくくなります。外部 API 呼び出しや複数モデルの更新は別のクラスに置き、handle の引数で型宣言して受け取る形にしておくと、コマンドは入出力の整形だけを持つ薄い入口になります。重い処理をバックグラウンドへ回すなら、コマンドから dispatch するジョブを make:job で作ります。ジョブの雛形と worker の運用はLaravel Queueの使い方｜ジョブ定義・worker常駐・失敗ジョブ運用を13.38で実測で扱っています。

app/Console/Commandsは登録不要・別ディレクトリはwithCommands

app/Console/Commands に置いたコマンドは自動で登録されます。上の invoices:sync も、ファイルを保存しただけで php artisan list invoices に invoices:sync 指定月の請求書を外部会計へ同期する と表示されました。Laravel 10 以前の app/Console/Kernel.php に登録する手順は、11 以降の雛形には当てはまりません。

ドメインごとにディレクトリを分けている場合は、bootstrap/app.php の withCommands にディレクトリかクラス名を渡すと、そこも読み込まれます。

// bootstrap/app.php の該当箇所のみ抜粋
->withCommands([
    __DIR__.'/../app/Domain/Orders/Commands',
])

Laravel 11以降で変わった生成物の登録先

Laravel 11 でアプリケーションの雛形が大幅に整理され、生成したクラスをどこに登録するかが変わりました。検索で見つかる日本語記事の多くは変更前の手順のため、コマンド自体は成功するのに登録先が見つからない、という食い違いが起きます。

make:providerはbootstrap/providers.phpへ自動追記

make:provider を実行すると、クラスの生成と同時に bootstrap/providers.php へそのクラスが追記されます。実測でも php artisan make:provider PaymentServiceProvider の後、ファイルは次の状態になっていました。make:provider の実行だけで登録まで完了し、config/app.php の providers 配列に手で書き足す必要はありません。そもそも Laravel 11 以降の既定の雛形にこの配列はありません。

<?php

return [
    App\Providers\AppServiceProvider::class,
    App\Providers\PaymentServiceProvider::class,
];

Laravel 10 以前から移行したプロジェクトでは、bootstrap/providers.php が無く config/app.php の providers 配列が残っている場合があります。その環境では自動追記が効かないため、生成後にこのファイルの有無を確認し、無ければ従来どおり config/app.php 側へ登録してください。

make:middleware生成後のbootstrap/app.phpでの登録

ミドルウェアのファイルは従来どおり app/Http/Middleware に生成されますが、app/Http/Kernel.php は Laravel 11 で既定の雛形から無くなり、登録は bootstrap/app.php の withMiddleware で行います。全リクエストに適用するなら append、ルートで名前を指定して使うなら alias です。

// bootstrap/app.php の該当箇所のみ抜粋
// ファイル冒頭に use Illuminate\Foundation\Configuration\Middleware; が必要
return Application::configure(basePath: dirname(__DIR__))
    ->withMiddleware(function (Middleware $middleware): void {
        // 全リクエストに適用
        $middleware->append(\App\Http\Middleware\EnsureTokenIsValid::class);

        // ルート側で 'subscribed' と書けるようにする（EnsureUserIsSubscribed も make:middleware で作成しておく）
        $middleware->alias([
            'subscribed' => \App\Http\Middleware\EnsureUserIsSubscribed::class,
        ]);
    })->create();

web グループや api グループへの追加は $middleware->web(append: [...]) のように専用メソッドを使います。グローバルとルート単位の使い分けや実行順の決め方はLaravelのミドルウェアとは｜適用範囲の使い分けと実行順序の決め方で解説しています。

版ごとに追加・変更されたmake:コマンドの境界

手元の Laravel が古いと、記事のコマンドが is not defined で失敗します。GitHub のブランチ・タグ別のソースツリーで確認した境界は次のとおりです。

• Laravel 11：make:class・make:enum・make:interface・make:trait・make:job-middleware が追加。session:table などのテーブル系が make:session-table などへ改名（旧名はエイリアスで残る）。
• Laravel 12.26.4（2025年8月29日）：make:config が追加。12.26.0 のソースには ConfigMakeCommand がありません。
• Laravel 13.0.0（2026年3月17日）：make:command の雛形が #[Signature] 属性形式に変更。

プロジェクトのバージョンは php artisan --version で確認できます（今回の検証環境は Laravel Framework 13.38.0）。版をまたいで手順を書く社内ドキュメントでは、この境界を明記しておくと「コマンドが見つからない」という問い合わせを減らせます。

make:serviceが存在しない理由とサービスクラスの作り方

「php artisan make:service」で検索する人は多いものの、Laravel のコアにこのコマンドはありません。13.38.0 で実行すると ERROR Command "make:service" is not defined. Did you mean one of these? に続いて make:系37種の候補が並び、終了コード1で止まります。サービスクラスは Laravel が定義する構成要素ではなく、アプリケーション側の設計上の概念です。フレームワークが置き場所を決めていないので、雛形も用意されていません。

make:classによるapp/Services配下への生成

Laravel 11 以降であれば、汎用の make:class にディレクトリ付きの名前を渡すのが最短です。app 直下を起点にディレクトリと名前空間が作られます。

$ php artisan make:class Services/InvoiceService

 INFO Class [app/Services/InvoiceService.php] created successfully.

名前空間は App\Services になります。単一の処理だけを持たせたい場合は --invokable を付けると __invoke メソッドだけのクラスになります。Laravel 10 以前には make:class 自体が無いので、ファイルを手で作るか、次の stub と独自コマンドを用意します。

コアから消えたmake:authとLaravel 13での代替

同じ「コマンドが見つからない」系では make:auth も定番です。ログイン画面と登録画面の雛形を作る make:auth は Laravel 5 系のコアにありましたが、Laravel 6 で本体から削除され laravel/ui パッケージへ移されました。laravel/ui を composer require すれば php artisan ui bootstrap --auth の形で同等の足場を生成できます。

ただし Laravel 13 で新規に認証機能を作るなら、laravel/ui は古い選択肢です。現在の標準はスターターキットで、選び方はLaravel Breezeはなぜ非推奨に？Laravel 13で使う手順と後継スターターキット4種・移行判断で整理しています。

stub:publishによる生成雛形のチーム内統一

生成直後のファイルに毎回同じ修正を入れているなら、stub を書き換えるほうが早く済みます。php artisan stub:publish を実行すると、プロジェクト直下の stubs ディレクトリに雛形がコピーされます（13.38.0 では54ファイル）。以降の make:系はこちらを優先して読みます。試しに stubs/request.stub の return false; を return true; に書き換えて make:request を実行すると、生成されたクラスの authorize は true になっていました。

php artisan stub:publish

# 独自の make:service を作る場合は、コマンド自体を make:command で用意する
php artisan make:command MakeService --command=make:service

独自の make:service を実装するかは慎重に判断してください。生成されるのが空のクラス1つなら make:class で足り、専用コマンドを保守するコストに見合いません。コンストラクタの依存注入・インターフェース・テストクラスまでを毎回セットで作る運用が定着している場合に限り、独自コマンド化の価値があります。週に数回しかクラスを追加しない規模なら、make:class とエディタのスニペットで十分です。

サービスクラスを作るべきでない場面

サービスクラスは「コントローラーが太ったら作るもの」と説明されがちですが、処理を別ファイルへ移すだけなら得るものはありません。Eloquent の1メソッドをそのまま転送するだけで、依存の差し替えや業務上の責務も持たないサービスなら、処理を追うためのファイルが増えます。

分離が効くのは、外部 API 呼び出しやトランザクションをまたぐ複数モデルの更新など、コントローラー以外（Artisan コマンド・キュージョブ・イベントリスナー）からも同じ処理を呼ぶ見込みがあるときです。呼び出し元が1箇所で、独立した責務やテスト上の分離目的もない場合は、サービスクラスを増やす必要はありません。サービス層をどこまで切るかを含めた設計から相談したい場合は、PHP・Laravel でのフルスクラッチ開発の支援も行っています。

生成物の確認とリセットに使うdb:系コマンド

make:migration で作ったマイグレーションが意図どおりに反映されたかは、Laravel 9 で追加された db:系コマンドで確認できます。マイグレーション自体の実行やロールバックの挙動はLaravelマイグレーションの使い方｜php artisan migrateとrollback・freshの挙動を13.xで検証で扱っています。

db:showとdb:tableによるスキーマ確認

# 接続中のDB名・テーブル一覧（行数の表示には --counts が必要）
php artisan db:show --counts

# 特定テーブルのカラム・型・インデックス・外部キー
php artisan db:table invoices

db:show のオプションは --database=・--json・--counts・--views・--types の5つです。help には –counts と –views に「大きなデータベースでは遅くなる」という注記があり、既定では行数とビューを数えません。検証用プロジェクトで invoices と notifications のマイグレーションも追加・実行した後に db:show を実行すると、SQLite 3.54.0・database/database.sqlite・テーブル11本が表示されました。カラムの型が想定と違うといった食い違いを調べる場面では、SQL クライアントを開くより db:table のほうが速く済みます。データそのものを対話的に触りたい場合はphp artisan tinkerの使い方｜Laravel Tinkerの基本コマンドとEloquent操作で扱っている tinker が向きます。

db:monitorによる接続数の監視

# 接続数が100以上ならイベントを発行
php artisan db:monitor --databases=mysql --max=100

db:monitor は現在の接続数を表示し、--max で指定した閾値以上になると DatabaseBusy イベントを発行します。スケジューラで定期実行し、イベントを購読して通知を飛ばす使い方が前提です。1回叩いて数字を眺めるだけでは監視になりません。

db:wipeとmigrate:freshの使い分けと本番での禁止

# 全テーブルを削除（ビュー・型は既定では残る／マイグレーションは実行しない）
php artisan db:wipe

# ビューと型（型は Postgres のみ）も含めて削除
php artisan db:wipe --drop-views --drop-types

# 全削除してからマイグレーションを再実行
php artisan migrate:fresh --seed

db:wipe が既定で削除するのはテーブルだけです。ビューは --drop-views、型は --drop-types（Postgres 専用）を付けたときだけ削除されます。削除と再構築をまとめて行いたい場合は migrate:fresh を使います。初期データの投入側はLaravel Seederの使い方｜Factory連携と本番投入してよいデータの線引きで扱っています。

どちらも本番環境では確認プロンプトが出ますが、--force を付けるとプロンプトを飛ばして実行されます。CI やデプロイスクリプトに db:wipe –force を書き込むのは避けてください。環境変数の指す接続先が想定と違っていた場合、確認なしで本番データが消えます。事故を構造的に防ぐなら、AppServiceProvider の boot で \Illuminate\Support\Facades\DB::prohibitDestructiveCommands($this->app->isProduction()); を呼んでおきます。

$ APP_ENV=production php artisan db:wipe --force; echo rc=$?

 WARN This command is prohibited from running in this environment.

rc=1

実測では --force を付けても上のとおり拒否され、migrate:fresh –force も同じ WARN で終了コード1になりました。APP_ENV=local では同じ db:wipe –force が Dropped all tables successfully. で通ります。本番のガードは環境名の判定に依存するため、本番サーバーの APP_ENV が production になっていることもあわせて確認してください。

よくある質問

php artisan make:serviceは使えますか？

Laravel のコアには存在せず、実行するとCommand "make:service" is not defined. で失敗します。Laravel 11 以降なら php artisan make:class Services/InvoiceService で app/Services 配下に生成できます。

make:modelの-aでは何が生成されますか？

モデル・マイグレーション・ファクトリ・シーダー・ポリシー・リソースコントローラー・Store用とUpdate用のフォームリクエストの8ファイルです（13.38.0 で実測）。使わないファイルが残る場合は -mrR のように個別に指定します。

make:commandで作ったコマンドはどこに登録しますか？

app/Console/Commands に置いたものは自動で登録されるため、作業は不要です。別のディレクトリに置く場合だけ、bootstrap/app.php の withCommands にディレクトリかクラス名を渡します。

db:wipeとmigrate:freshはどう違いますか？

db:wipe はテーブルを削除するだけでマイグレーションを実行しません。migrate:fresh は削除後にマイグレーションを再実行し、--seed を付ければシーディングまで続けます。

そのプロジェクトで使えるmake:コマンドを確認する方法はありますか？

php artisan list make で一覧を表示できます。導入済みパッケージが追加したコマンドも含まれるため、記事の一覧より確実です。個別のオプションは php artisan help make:model のように help で確認します。

関連記事

• Laravelマイグレーションの使い方｜php artisan migrateとrollback・freshの挙動を13.xで検証
• php artisan tinkerの使い方｜Laravel Tinkerの基本コマンドとEloquent操作
• Laravelのバリデーション｜validateとFormRequestの使い分け・カスタムルール・JSON応答
• Laravelのミドルウェアとは｜適用範囲の使い分けと実行順序の決め方
• Laravelのバージョン確認方法｜最新バージョンは13・artisanとcomposerの違いとサポート期限