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

php artisan make は、Laravel がモデル・コントローラー・ミドルウェアなどの雛形を生成するコマンド群の総称です。日本語で読める一覧記事の多くは Laravel 5.x から 8.x の時代に書かれたもので、Laravel 11 で生成物の登録先が config/app.php から bootstrap 配下へ移った変更が反映されていません。古い手順のまま make:provider を実行し、生成したクラスを config/app.php に書き足そうとして該当の配列が見つからない、という詰まり方が典型です。この記事では Laravel 13.23.0（2026年7月27日リリース）のフレームワーク本体のソースで実在を確認したコマンドだけを、生成先ディレクトリと主要オプション付きで整理します。

まとめ

• Laravel 13 のコアが持つ make:系コマンドは31種類。実機で使えるものは php artisan list make で確認できます。
• Laravel 11 以降、make:provider は生成と同時に bootstrap/providers.php へ自動追記されます。config/app.php の providers 配列に手で書き足す手順は不要になりました。
• make:middleware が生成するファイルの置き場所は app/Http/Middleware のままですが、登録先は bootstrap/app.php の withMiddleware に変わりました。
• make:service は Laravel に存在しません。Laravel 11 で追加された汎用の make:class にディレクトリ付きの名前を渡すのが最短の代替手段です。
• make:enum・make:interface・make:trait の生成先は固定ではなく、app/Enums や app/Traits などの既存ディレクトリを検出して切り替わります。

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

make:系コマンドは php artisan make:<種類> <クラス名> という共通の形をとり、指定した名前でクラスファイルを生成します。生成物の置き場所を決めるのは、GeneratorCommand を継承した各コマンドの getDefaultNamespace が返す名前空間です。どこにファイルができるかを先に把握しておけば、生成後に探し回らずに済みます。

Laravel 13標準のmake:系コマンド一覧（生成先ディレクトリ付き）

下表は laravel/framework の 13.x ブランチに実在するコマンドクラスを数え上げたものです。内訳は Illuminate\Foundation が26本、Illuminate\Routing が2本（make:controller・make:middleware）、これに Illuminate\Database 配下の make:migration・make:seeder・make:factory を加えた31種類です。「導入」列が空欄のものは古くから存在するコマンドを表します。

生成先が矢印表記の4つは、既存ディレクトリを検出して名前空間を切り替える実装です。EnumMakeCommand なら app/Enums があればそこへ、無ければ app/Enumerations、どちらも無ければ app 直下という順で判定します。プロジェクトの慣習に合わせて先にディレクトリを作っておけば、生成先を毎回指定する必要はありません。

全コマンド共通の引数・オプションと名前空間の指定方法

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

上書き用の --force は全コマンド共通ではなく、各コマンドが個別に定義しています。GeneratorCommand 側は hasOption で存在を確かめてから参照する作りで、実際 make:middleware にはこのオプションがありません。短縮形の扱いも統一されておらず、make:model と make:controller の --force には短縮形がない一方、make:model の -f は --factory を指します。上書きのつもりで -f を付けるとファクトリが生成されるため、短縮形ではなく --force と書くのが安全です。

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

# 既存ファイルを上書き（短縮形ではなく --force と書く）
php artisan make:provider PaymentServiceProvider --force

# 使えるmake:系コマンドを実機で一覧表示（list は Symfony Console の仕様で名前空間を引数に取れる）
php artisan list make

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

Livewire や Filament などのパッケージも独自の make:系コマンドを追加するため、実機で何が使えるかは上の一覧より php artisan list make の出力が正確です。

使用頻度の高いmake:コマンドの実行例とオプション

31種類のうち、日常的に叩くのは一部に偏ります。ここでは組み合わせで挙動が変わり、オプションの理解が結果を左右する3つを取り上げます。

make:modelのオプション組み合わせによる関連クラスの同時生成

make:model は、モデル本体に加えて関連クラスをまとめて生成できます。13.x のシグネチャで定義されているオプションは -a（–all）、-c（–controller）、-f（–factory）、-m（–migration）、-s（–seed）、-r（–resource）、-R（–requests）、-p（–pivot）、--policy、--api、--morph-pivot、--force の12個です。

# モデル＋マイグレーション＋リソースコントローラー＋フォームリクエスト
php artisan make:model Invoice -mrR

# --all はマイグレーション・シーダー・ファクトリ・ポリシー・リソースコントローラーを生成
php artisan make:model Invoice --all

-a を付けると handle メソッドが factory・seed・migration・controller・policy・resource の各オプションを立てるため、モデル本体を含めて6ファイルが一度に増えます（controller と resource は同じ1ファイルを指し、resource はコントローラーの種類を決めるオプションです）。設計が固まっていない段階では -m だけで始め、必要になった時点で個別に足すほうが余計なファイルを抱えずに済みます。なお -p は中間テーブル用のモデルを生成するオプションで、多対多のリレーションに追加カラムを持たせるときに使います。

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

# 単一リソース向け（--creatable で作成系メソッドも追加）
php artisan make:controller ProfileController --singleton --creatable

ユーザーごとに1つしか存在しないプロフィールのようなリソースには --singleton（-s）が向きます。--model を併用すると各メソッドの引数にモデルの型宣言が入った状態で生成されるため、ルートモデルバインディングを使う前提なら指定しておくと後から書き足す手間が減るはずです。--requests（-R）を足せば store と update 用のフォームリクエストも同時に作られます。クラス名やテーブル名の付け方に迷ったら、Laravelの命名規則一覧｜テーブル・モデル・コントローラーからコーディング規約までに単数形・複数形の使い分けをまとめています。

make:requestによる入力検証のコントローラーからの分離

make:request が生成するフォームリクエストクラスには、authorize と rules の2つのメソッドが含まれます。authorize が false を返すとバリデーション以前に 403 が返るため、認可の判定をここに置けばコントローラーの分岐を減らせます。注意すべきは、13.x の request.stub でも authorize が false を返す状態で生成される点です。そのまま使うと全リクエストが 403 になるので、認可が不要なら true に、必要なら判定式に書き換えてから使ってください。バリデーションが動かないという相談の多くはここが原因です。

php artisan make:request StoreInvoiceRequest

コントローラーのメソッド引数の型宣言を Request からこのクラスに差し替えるだけで、検証済みの値を validated() で受け取れます。

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

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

make:providerの登録先（bootstrap/providers.phpへの自動追記）

Laravel 13 の ProviderMakeCommand は、クラス生成後に ServiceProvider::addProviderToBootstrapFile を呼び、bootstrap/providers.php に生成したクラスを追記します。つまり make:provider の実行だけで登録まで完了します。config/app.php の providers 配列に手で追記する必要はなく、そもそも Laravel 11 以降の既定のスケルトンにはこの配列がありません。

php artisan make:provider PaymentServiceProvider

<?php
// bootstrap/providers.php に PaymentServiceProvider の行が追記される
return [
    App\Providers\AppServiceProvider::class,
    App\Providers\PaymentServiceProvider::class,
];

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

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

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

php artisan make:middleware EnsureTokenIsValid

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

        // ルート側で 'subscribed' と書けるようにする
        $middleware->alias([
            'subscribed' => EnsureUserIsSubscribed::class,
        ]);
    })->create();

web グループや api グループへの追加は $middleware->web(append: [...]) のように専用メソッドを使います。実行順の制御が必要な場合だけ priority メソッドで並べ替えます。

Laravel 11・12で追加されたmake:class系コマンド

make:class・make:enum・make:interface・make:trait・make:job-middleware の5つは Laravel 11 で追加されました。10.x のソースツリーには対応するコマンドクラスが存在しないため、Laravel 10 以前の環境では動きません。make:config は 11.x にも無く、12.x から追加されたコマンドです。この記事の後半で扱う db:show・db:table・db:monitor は、さらに古い Laravel 9 の追加分にあたります。

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

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

「php artisan make:service」で検索する人は多いものの、Laravel のコアにこのコマンドはありません。13.x のソースに ServiceMakeCommand は存在しないため、実行すると Command “make:service” is not defined というエラーになります。サービスクラスは Laravel が定義する構成要素ではなく、アプリケーション側の設計上の概念です。フレームワークが置き場所を決めていない以上、雛形も用意されていません。

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

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

php artisan make:class Services/InvoiceService

# 生成物: app/Services/InvoiceService.php
# 名前空間: App\Services

単一の処理だけを持たせたい場合は --invokable を付けると __invoke メソッドだけのクラスになります。Laravel 10 以前の環境では make:class 自体が無いので、ディレクトリとファイルを手で作るか、後述の stub を用意することになります。

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

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

ただし Laravel 13 で新規に認証機能を作るなら、laravel/ui は選択肢としては古い部類に入ります。現在の標準はスターターキットで、選定の考え方はLaravel Breeze・Jetstreamはなぜ非推奨に？スターターキット（React/Vue/Livewire）への移行と代替案で整理しています。

stubのpublishによる独自make:コマンドの用意と判断基準

チーム全体で同じ雛形を使いたい場合は、stub を公開して編集します。php artisan stub:publish を実行すると、プロジェクト直下の stubs ディレクトリにフレームワークの雛形がコピーされ、以降の生成はそちらが優先されます。各 make:系コマンドは stub を探す際にアプリケーション側のパスを先に見るため、編集した内容がそのまま反映される仕組みです。

php artisan stub:publish

# 独自コマンド自体を作る場合
php artisan make:command MakeService --command=make:service

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

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

サービスクラスは「コントローラーが太ったら作るもの」と説明されがちですが、単に処理を別ファイルへ移すだけなら得られるものはありません。Eloquent の1メソッドで済む取得処理をサービス経由に変えても、テストの書きやすさは変わらず、追跡するファイルが1つ増えるだけです。

分離が効くのは、外部 API 呼び出しやトランザクションをまたぐ複数モデルの更新など、コントローラー以外（コンソールコマンド・キュージョブ・イベントリスナー）からも同じ処理を呼ぶ見込みがあるときです。呼び出し元が1箇所しかない状態でクラスを増やす判断は、後から統合する手戻りを生みます。

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

make:migration で作ったマイグレーションが意図どおりに反映されたかは、Laravel 9 で追加された db:系コマンドで確認できます。8.x 系のソースには ShowCommand・TableCommand・MonitorCommand が存在しないため、古い環境では使えません。マイグレーション自体の実行やロールバックの手順はLaravelにおけるマイグレーションの基本とその重要性で扱っています。

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

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

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

db:show のシグネチャにあるオプションは --database=、--json、--counts、--views、--types の5つです。行数とビューの表示は大きなデータベースでは時間がかかるため、必要なときだけフラグで有効にする設計です。マイグレーション後にカラムの型が想定と違うといった食い違いを調べる場面では、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 を使います。

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

よくある質問

php artisan make:service は使えますか。
Laravel のコアには存在しないコマンドです。Laravel 11 以降なら php artisan make:class Services/InvoiceService で app/Services 配下に生成できます。10 以前は手動作成か、stub と独自コマンドの用意が必要です。

make:model の -a では何が生成されますか。
マイグレーション・シーダー・ファクトリ・ポリシー・リソースコントローラーの5つで、モデル本体と合わせて6ファイルが増えます。使わないファイルが残らないか確認してください。

作成したミドルウェアはどこに登録しますか。
Laravel 11 以降は bootstrap/app.php の withMiddleware クロージャです。全リクエストに適用するなら append、ルートで名前指定して使うなら alias を使います。app/Http/Kernel.php は既定のスケルトンから廃止されています。

db:wipe と migrate:fresh はどう違いますか。
db:wipe はテーブルを削除するだけで、マイグレーションを実行しません（ビューと型は --drop-views --drop-types を付けたときのみ削除）。migrate:fresh は削除後にマイグレーションを再実行し、--seed を付ければシーディングまで続けて行われます。

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

関連記事

• Laravelにおけるマイグレーションの基本とその重要性
• php artisan tinkerの使い方｜Laravel Tinkerの基本コマンドとEloquent操作
• Laravelの命名規則一覧｜テーブル・モデル・コントローラーからコーディング規約まで
• Laravel Breeze・Jetstreamはなぜ非推奨に？スターターキット（React/Vue/Livewire）への移行と代替案
• Laravel 13で正式安定版になったAI SDKの全体像と導入判断の前提知識