--- title: "Laravelの命名規則一覧｜テーブル・モデル・コントローラーとコーディング規約【Laravel 13対応】" url: "https://www.issoh.co.jp/tech/details/5468/" published: 2025-02-21 updated: 2026-10-15 categories: ["Laravel"] publisher: "株式会社一創" --- # Laravelの命名規則一覧｜テーブル・モデル・コントローラーとコーディング規約【Laravel 13対応】 Laravelは「名前を規約どおりに付ければ設定を書かなくて済む」設計です。モデル名からテーブル名を、リレーションのメソッド名から外部キーを、マイグレーションのファイル名から対象テーブルを推論します。テーブル名や外部キーなど推論に使われる名前を変える場合は、対応する設定を明示する必要があります。この記事では、Laravel 13.36.0（2026年10月15日にcreate-projectで作成）で各推論を実行して確かめた結果をもとに、対象別の命名規則・PHPの規約（PSR）との関係・規約を外れるときの上書き方法・命名を機械的に守る手段をまとめます。 ## まとめ：Laravelの命名規則の要点 - **ケースは3つ：**クラスは**StudlyCase**（`OrderItem`）、メソッドと変数は**camelCase**（`$orderTotal`）、テーブル・カラム・ルートパラメータは**snake\_case**（`order_items`）。定数と`.env`のキーは大文字のUPPER\_SNAKE\_CASE。 - **テーブルはモデル名から推論：**単数StudlyCaseのモデル`OrderItem`は複数snake\_caseの`order_items`へ。`Person`は`people`、`Index`は`indices`のように英語の不規則変化にも従う。 - **外部キーはリレーションのメソッド名から：**`belongsTo`はメソッド名＋`_id`（`author()`なら`author_id`）を探す。中間テーブルは2モデルの単数形をアルファベット順に連結（`role_user`）。 - **規約を外れるならLaravel 13は`#[Table]`属性：**テーブル名・主キー・型・連番・タイムスタンプを1行で宣言できる。12系では従来の`$table`などのプロパティを使う。 - **Pintは名前を直さない：**`pint --test`はクラス名`order_service`のような命名違反をPASSにする。命名の機械検査にはPHP\_CodeSnifferのPSR1標準を使う。 ## PHPの命名規則とLaravelの土台｜PSR-1・PSR-12 Laravelの命名は、PHPの標準規約PSR（PHP Standards Recommendations）の上にフレームワークの推論規約を重ねたものです。PHP全体の決まりとLaravelの都合を分けておくと、チームで揉める範囲が狭まります。 ### PSR-1の命名規定｜クラス・定数・メソッドとプロパティの扱い [PSR-1](https://www.php-fig.org/psr/psr-1/)が命名について「MUST」で定めているのは3点だけです。クラス名はStudlyCaps、クラス定数はすべて大文字のアンダースコア区切り、メソッド名はcamelCaseです。プロパティ名については、4.2節で「`$StudlyCaps`・`$camelCase`・`$under_score`のどれを使うかの推奨は意図的に避ける」と明記し、一定の範囲（ベンダー・パッケージ・クラス単位）で一貫させるべき（SHOULD）とだけ書いています。メソッド内のローカル変数名には触れていません。「PHPの変数はsnake\_caseが正しい」「camelCaseが正しい」という断定は、どちらもPSRには根拠がありません。 ### PSR-2の非推奨化｜PSR-12への移行とLaravelの書式設定 Laravelの命名を解説する記事には「PSR-2準拠」と書かれたものが今も多くありますが、[PSR-2](https://www.php-fig.org/psr/psr-2/)は2019年8月10日に非推奨となり、後継として[PSR-12](https://www.php-fig.org/psr/psr-12/)が推奨されています。紛らわしいのは、Laravel自身の[コントリビューションガイド](https://laravel.com/docs/13.x/contributions)が13.x版でも「Laravel follows the PSR-2 coding standard」と書いている点です。実際の整形は後述のLaravel Pintが担い、既定のプリセット`laravel`はLaravel本体のコードスタイルに合わせて整えます。新しく規約を決めるなら、書式の判定はチームで固定したPintの設定に合わせ、命名規則は別途明文化してください。 ### 変数名｜camelCaseへの統一方針 PSRが決めていない変数名は、フレームワーク本体に合わせるのが最も摩擦の少ない選択です。laravel/framework v13.36.0の`src`配下をPHPのトークナイザ（`token_get_all`）で走査し、コメント・引数の既定値・プロパティ宣言を除いた代入文の変数のうち複数語のものを数えると、camelCase（`$orderTotal = `の形）が1,478件、snake\_caseは失敗ジョブの日時を入れる`$failed_at`の1件だけでした。アプリ側の変数もcamelCaseで統一し、snake\_caseはデータベースのカラム名と、そのカラムを読むときの`$user->created_at`に限定すると、本体のコードと並べても違和感が出ません。言語をまたいだケースの考え方は[プログラミングの命名規則まとめ｜キャメルケース・スネークケースの違いとPythonのファイル名など6言語の書き方](/tech/details/2339/)で整理しています。 ## 対象別の命名規則一覧（早見表） Laravelで名前を付ける主な対象を一覧にしました。「推論される」の列が○の対象は、名前を外すとLaravelが自動で結び付けられなくなります。 | 対象 | ケース・形 | 例 | 推論される | | ------------ | -------------------------- | ------------------------------ | ----- | | モデル | StudlyCase・単数 | OrderItem | ○ | | テーブル | snake\_case・複数 | order\_items | ○ | | カラム | snake\_case | created\_at | ― | | 外部キー | メソッド名\_id | author\_id | ○ | | 中間テーブル | 単数\_単数（英字順） | role\_user | ○ | | コントローラー | StudlyCase＋Controller | OrderItemController | ― | | リソースのアクション | 7つの固定名 | index / store / destroy | ○ | | メソッド・変数 | camelCase | $orderTotal | ― | | リレーション | camelCase・単複 | user() / orderItems() | ○ | | ルート名 | URI.アクション | order-items.index | ○ | | ルートパラメータ | snake\_case・単数 | {order\_item} | ○ | | マイグレーション | 日時\_動作\_テーブル | …\_create\_order\_items\_table | ○ | | Seeder | モデル名＋Seeder | OrderItemSeeder | ― | | Factory | モデル名＋Factory | OrderItemFactory | ○ | | Policy | モデル名＋Policy | OrderItemPolicy | ○ | | FormRequest | 動作＋モデル名＋Request | StoreOrderItemRequest | ― | | Bladeコンポーネント | kebab-case | user-card.blade.php | ○ | | 定数 | UPPER\_SNAKE\_CASE | MAX\_LOGIN\_ATTEMPTS | ― | | 設定ファイル・.env | snake\_case ／ UPPER\_SNAKE | services.php ／ DB\_DATABASE | ― | ## テーブル・モデル・コントローラーの命名 ### テーブル名｜snake\_caseの複数形と不規則な複数形 Eloquentはモデルのクラス名を複数形にしてsnake\_caseへ変換し、テーブル名とみなします（[公式ドキュメント](https://laravel.com/docs/13.x/eloquent)の例は`AirTrafficController`→`air_traffic_controllers`）。複数形化には英語の辞書が使われるため、単純に「s」を付けるわけではありません。Laravel 13.36.0で推論結果を出力すると次のとおりでした。 | モデル名 | 推論されるテーブル名 | | ------------------------ | ------------------------ | | Person | people | | Category | categories | | Status | statuses | | Index | indices | | Criterion | criteria | | Mouse | mice | | UserData | user\_data | | News / Equipment / Media | news / equipment / media | 落とし穴になりやすいのは`Index`と`UserData`です。`Index`モデルに対して`indexes`テーブルを作ると、Eloquentは`indices`を探して失敗します。`Data`や`News`は不可算名詞として扱われ、複数形にもなりません。テーブルを先に作る場合は、モデルを作ってから`(new OrderItem)->getTable()`で推論結果を確かめるのが確実です。カラム名もsnake\_caseで、主キーは`id`が既定です。 ### モデル名｜StudlyCaseの単数形 モデルはテーブルと対になるStudlyCaseの単数形にします。`app/Models`に置き、名前空間`App\Models\OrderItem`とファイルパスをPSR-4で一致させます。1インスタンスが1行を表すので単数形です。 ### コントローラー名｜StudlyCase＋Controllerとリソースの7アクション コントローラーはStudlyCaseで末尾に`Controller`を付けます。`php artisan make:controller OrderItemController`なら`app/Http/Controllers/OrderItemController.php`が作られます。CRUDを担うリソースコントローラーでは、メソッド名が`index`・`create`・`store`・`show`・`edit`・`update`・`destroy`の7つに固定されています。`Route::resource`の1行がこの7つにルートを割り当てるため、`list`や`delete`のような独自名にはしません。 ### メソッド名｜camelCaseと動詞始まり メソッド名はPSR-1どおりcamelCaseで、`calculateTotal`・`markAsShipped`のように動詞から始めます。真偽値を返すものは`isPaid`・`hasStock`の形にします。Eloquentのアクセサもメソッド名はcamelCaseで、`firstName()`が`first_name`カラムに対応します（[ミューテタのドキュメント](https://laravel.com/docs/13.x/eloquent-mutators)）。Eloquentのモデル定義全体は[Laravel Eloquentとは｜モデル定義・リレーション・eager loadingの基礎とクエリビルダの使い分け](/tech/details/17127/)で解説しています。 ## リレーション・外部キー・中間テーブルの命名 リレーションは、名前がそのままSQLのカラム名になる箇所です。推論の元になる名前が関係の向きで違うため、取り違えると規約どおりに書いたつもりでも`Unknown column`が出ます。 ### belongsToの外部キー｜メソッド名と関連先主キー名からの推論 `belongsTo`は、相手のモデル名ではなく**リレーションのメソッド名**をsnake\_caseにし、アンダースコアと関連先モデルの主キー名を付けた列を外部キーとみなします。関連先の主キー名が既定の`id`なら、末尾は`_id`です。`Post`モデルで`author()`メソッドに`belongsTo(User::class)`と書くと、探しに行く列は`user_id`ではなく`author_id`です。したがって列名が`author_id`なら第2引数は不要で、第2引数が必要になるのは列名が推論とずれたとき（`checked_by`列を`reviewer()`で読むなど）だけです。 ``` namespace App\Models; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo; class Post extends Model { // author_id を自動で探す（第2引数は不要） public function author(): BelongsTo { return $this->belongsTo(User::class); } // 列名がメソッド名と違うときだけ明示する public function reviewer(): BelongsTo { return $this->belongsTo(User::class, 'checked_by'); } } ``` 一方、`hasMany`の外部キーは**親モデルのクラス名**から作られます。`User`の`posts()`なら`posts.user_id`、`Post`の`orderItems()`なら`order_items.post_id`です。子側から見る`belongsTo`と親側から見る`hasMany`で推論の元が違うので、メソッド名を`author()`にしたら、親側の`hasMany`には`'author_id'`を明示する必要があります。 ### 中間テーブル名｜単数形のアルファベット順による連結 多対多の中間テーブルは、2つのモデル名をsnake\_caseの単数形にし、アルファベット順に並べてアンダースコアでつなぎます。実測では`User`と`Role`が`role_user`、`Post`と`Tag`が`post_tag`、`OrderItem`と`Product`が`order_item_product`でした。並べ替えはsnake\_caseにした2つの名前を文字列として比べるため、迷ったら`$user->roles()->getTable()`で確かめてください。中間テーブルの列は`role_id`・`user_id`の単数形です。 ### リレーション名とJSONのキー リレーションのメソッド名は、1件を返すもの（`belongsTo`・`hasOne`）を単数の`user()`、複数を返すもの（`hasMany`・`belongsToMany`）を複数の`orderItems()`にします。注意したいのは、camelCaseで定義したリレーションが`toArray()`やJSONではsnake\_caseのキーになることです。`orderItems`を読み込んだモデルをJSONにすると、キーは`order_items`になります（[シリアライズのドキュメント](https://laravel.com/docs/13.x/eloquent-serialization)にも同じ記述があります）。フロントエンドで`orderItems`を参照してundefinedになる場合は、レスポンスのキーが`order_items`になっていないか確認してください。 ## ルーティング・マイグレーション・Bladeの命名 ### ルート名とURI｜order-items.index URIは小文字の複数形をハイフンでつなぐ形（`/order-items`）が慣例です。`Route::resource('order-items', OrderItemController::class)`と書くと、ルート名は`order-items.index`・`order-items.show`のようにURIの文字列がそのまま使われ、ルートパラメータは単数形のsnake\_caseで`{order_item}`になります。`users.order-items`のようにネストすると、ルート名は`users.order-items.index`です。ビューやリダイレクトでは`route('order-items.show', $item)`のように名前で参照します。 ### ルートモデル結合｜ルートパラメータ名と引数名の対応 暗黙のルートモデル結合は、型宣言した引数の変数名がルートパラメータ名と一致したときだけ働きます（[ルーティングのドキュメント](https://laravel.com/docs/13.x/routing)）。Laravelは変数名をsnake\_caseに変換しても照合するので、`{order_item}`に対して`OrderItem $orderItem`は結合されます。危ないのは名前がずれたときです。Laravel 13.36.0で検証すると、次の2本は動作が分かれました。 ``` // {order_item} と $orderItem は一致 → 該当行を取得、無ければ404 Route::get('/order-items/{order_item}', fn (OrderItem $orderItem) => $orderItem->id); // 名前が違う → 404にも例外にもならず、空の OrderItem が渡る Route::get('/x/{order_item}', fn (OrderItem $item) => var_export($item->exists, true)); ``` 2本目は存在するIDを渡しても`false`を返しました。エラーにならないため、更新処理で新しい行が作られて初めて気付くことがあります。`make:controller --resource --model=OrderItem`で生成すれば引数名は`$orderItem`で揃うので、手で書き換えるときだけ注意します。 ### マイグレーション｜ファイル名からテーブルを推論 マイグレーションは「日時\_動作\_テーブル」で名付け、日時はartisanが付けます。Laravelはファイル名から対象テーブルと新規作成かどうかを推測し、生成するコードに埋め込みます（[マイグレーションのドキュメント](https://laravel.com/docs/13.x/migrations)）。推測に使われる形は次の4つです（`TableGuesser`の正規表現）。 - `create_order_items_table`または`create_order_items` → `Schema::create('order_items')` - `add_status_to_order_items_table`のように`_to_`・`_from_`・`_in_`の後ろにテーブル名 → `Schema::table('order_items')` この形から外れた名前（`update_order_items`など）でも作成はできますが、`up()`と`down()`が空のひな形になります。`make:migration CreateFlightsTable`とStudlyCaseで渡しても`create_flights_table.php`に変換されました。マイグレーションの実行と巻き戻しは[Laravelマイグレーションの使い方｜php artisan migrateとrollback・freshの挙動を13.xで検証](/tech/details/7253/)で扱っています。 ### Blade・ビューファイル｜コンポーネントはkebab-case 通常のビューファイル名には公式の強制規約がなく、新規アプリのひな形にあるのも`welcome.blade.php`の1つだけです。複数語ならsnake\_caseかkebab-caseのどちらかにプロジェクトで統一します。一方、Bladeコンポーネントは規約で決まっています。`php artisan make:component UserCard`はクラス`app/View/Components/UserCard.php`とビュー`resources/views/components/user-card.blade.php`を作り、タグは``です。コンストラクタ引数はcamelCase、HTML属性ではkebab-caseで渡します（[Bladeのドキュメント](https://laravel.com/docs/13.x/blade)）。 ### 定数・設定ファイル・.envのキー クラス定数はPSR-1どおりUPPER\_SNAKE\_CASE（`const MAX_LOGIN_ATTEMPTS = 5;`）です。`config`配下のファイル名とキーはsnake\_case（`config/services.php`の`'slack' => ['notifications' => ['bot_user_oauth_token' => ...]]`）、`.env`のキーはUPPER\_SNAKE\_CASE（`DB_DATABASE`）にします。設定ファイル名の単複は同梱の`services.php`・`queue.php`でも混在しており、規約はありません。 ## Seeder・Factory・Policy・FormRequestの命名 Laravel 13.36.0で`php artisan make:model OrderItem -mfsc --policy`を実行すると、次の名前でファイルが作られました。 | 種類 | 生成されたファイル | 名前が外れたとき | | ---------- | -------------------------------------------- | ----------------- | | Seeder | database/seeders/OrderItemSeeder.php | 自分で呼ぶので動く | | Factory | database/factories/OrderItemFactory.php | factory()が見つけられない | | Policy | app/Policies/OrderItemPolicy.php | 自動検出されない | | Controller | app/Http/Controllers/OrderItemController.php | ルート定義で指定するので動く | 2020年前後の記事に多い`UsersTableSeeder`は古い慣習で、現在の[公式ドキュメント](https://laravel.com/docs/13.x/seeding)の例は`UserSeeder`です。Seederは`DatabaseSeeder`から明示的に呼ぶため推論には使われませんが、モデル名＋`Seeder`に揃えます。投入してよいデータの線引きは[Laravel Seederの使い方｜Factory連携と本番投入してよいデータの線引き](/tech/details/17160/)を参照してください。 FactoryとPolicyは名前で自動検出されます。`HasFactory`は`Database\Factories`名前空間の「モデル名＋Factory」を探し（[Factoryのドキュメント](https://laravel.com/docs/13.x/eloquent-factories)）、Policyはモデルのあるディレクトリ以上の`Policies`ディレクトリで「モデル名＋Policy」を探します（[認可のドキュメント](https://laravel.com/docs/13.x/authorization)）。名前を変えたい場合は、モデルに`#[UseFactory]`・`#[UsePolicy]`属性を付けて明示します。FormRequestは推論されませんが、`StoreOrderItemRequest`・`UpdateOrderItemRequest`のように「アクション＋モデル名＋Request」にすると、どのアクション用かが名前で分かります。実装は[Laravelのバリデーション｜validateとFormRequestの使い分け・カスタムルール・JSON応答](/tech/details/17118/)で扱っています。 ## Eloquentの規約を外れるときの上書き方法｜#\[Table\]属性 既存の業務システムのDBでは、テーブルが`m_members`、主キーが文字列の`member_id`のように規約と合わないことがあります。DBを改名するのではなく、モデル側で実際の名前を宣言します。Laravel 13では`#[Table]`属性で1行にまとめられます。 ``` use Illuminate\Database\Eloquent\Attributes\Table; use Illuminate\Database\Eloquent\Model; #[Table('m_members', key: 'member_id', keyType: 'string', incrementing: false, timestamps: false)] class Member extends Model { } ``` このモデルで`getTable()`・`getKeyName()`・`getKeyType()`・`getIncrementing()`・`usesTimestamps()`を出力すると、`m_members`・`member_id`・`string`・`false`・`false`が返りました。`#[Table]`は2026年2月13日にマージされた[PR #58578](https://github.com/laravel/framework/pull/58578)で入り、v13.0.0には存在しますが、確認対象の12系タグv12.70.0にはありません。13.xの公式ドキュメントはこの属性で説明しているため、12系のプロジェクトでドキュメントを写すとクラスが見つからないエラーになります。12系では従来どおりプロパティで書きます。 ``` class Member extends Model { protected $table = 'm_members'; protected $primaryKey = 'member_id'; public $incrementing = false; protected $keyType = 'string'; public $timestamps = false; } ``` プロパティの書き方は13でも動くので、12から13へ上げても書き直しは必須ではありません。**規約に乗れば宣言はゼロで、外れた分だけ宣言が増える**。合わない箇所だけをモデルで宣言し、それ以外は規約に任せます。上書きが多くても、命名差だけならモデル側の宣言で対応します。DBビューを採用する場合は、利用するDBで必要な更新操作が可能か、ビューの保守工数が増えないかを確認します。なおLaravel 12のバグ修正は2026年8月13日で終了し、セキュリティ修正は2027年2月24日までです（[リリースノート](https://laravel.com/docs/13.x/releases)）。版ごとの対応は[Laravelの最新バージョンは13｜対応PHPバージョン・サポート期限一覧とアップグレード判断](/tech/details/5637/)にまとめています。 ## 命名規則の自動検査と生成支援｜Pint・artisan・PHP\_CodeSniffer コーディング規約を守る道具は、書式を揃えるものと名前を検査するものが別です。混同すると、CIは通るのに命名がばらばらになります。 ### Laravel Pintの担当範囲｜書式の整形と命名検査の限界 Laravel Pintは新規のLaravelアプリに同梱されるコードフォーマッタで、2026年10月15日のcreate-projectではv1.32.1が入りました。プリセットは`laravel`（既定）・`per`・`psr12`・`symfony`・`empty`の5つです（[Pintのドキュメント](https://laravel.com/docs/13.x/pint)）。命名についての効果を確かめるため、クラス名`order_service`・定数`maxCount`・メソッド`Get_user_name`を含むファイルに`vendor/bin/pint`をかけました。Pintは波括弧の位置と空行を直しただけで、3つの名前はそのまま残りました。書式を整えた後の同じファイルに`pint --test`をかけると結果はPASSで、終了コードは0です。 つまり`pint --test`をCIに入れても、命名規則の違反は止まりません。プリセットの選び方とCIでの差分チェックは[Laravel Pintとは｜プリセット選定とCI差分チェック運用の判断基準](/tech/details/17143/)で解説しています。 ### 命名の検査はPHP\_CodeSnifferのPSR1標準 同じファイルをPHP\_CodeSniffer 4.0.4で`vendor/bin/phpcs --standard=PSR1`にかけると、3件のエラーで終了コード2になりました。 ``` 4 | ERROR | Class name "order_service" is not in PascalCase format 6 | ERROR | Class constants must be uppercase; expected MAXCOUNT but found maxCount 8 | ERROR | Method name "order_service::Get_user_name" is not in camel caps format ``` 検出されたのはPSR-1が「MUST」としているクラス名・定数・メソッド名の3種類だけで、変数`$User_Name`は報告されません。PSR-1が変数名を規定していないためです。変数名はレビュー基準で揃えます。Pintで書式、PHP\_CodeSnifferで命名を分担すれば、両方をCIで止められます。型や未定義参照の検査は[PHPStanとは？レベル0〜10の違いと導入・ベースライン運用【2.3対応】](/tech/details/12338/)の守備範囲です。 ### php artisan make系による関連ファイル名の統一 最初から規約どおりの名前にするには、ファイルを手で作らずartisanで生成します。`make:model OrderItem -mfsc --policy`なら、モデルに対応するマイグレーション・Factory・Seeder・コントローラー・Policyが前章の名前で一度に揃います。各コマンドの生成先とオプションは[php artisan makeコマンド一覧｜Laravel 13対応 生成先・オプション早見表](/tech/details/3759/)で確認できます。社内の業務システムをLaravelで作る際の命名ルールの策定から開発までは、[フルスクラッチ開発](/service/system/fullscratch/)でも支援しています。 ## よくある質問 ### Laravelのコーディング規約と命名規則は何が違いますか？ 命名規則は名前の付け方（クラスはStudlyCase、テーブルはsnake\_caseの複数形など）で、コーディング規約はインデントや波括弧の位置を含む書き方全般です。Laravelでは書式をPintが自動で整えますが、Pintは名前を変えないため、命名はartisanでの生成とPHP\_CodeSnifferなどの検査で守ります。 ### PHPの変数名はcamelCaseとsnake\_caseのどちらが正しいですか？ PSR-1はローカル変数名のケースを規定していません。プロパティ名についてはケースの推奨を意図的に避け、一定の範囲で一貫させることを推奨しています。Laravelでは本体のソースがcamelCaseで書かれているため、アプリの変数もcamelCaseに揃え、snake\_caseはデータベースのカラム名に使うのが一般的です。 ### モデル名とテーブル名がずれても動きますか？ 動きますが、モデルに実際のテーブル名を宣言する必要があります。Laravel 13なら`#[Table('m_members')]`属性、12以前なら`protected $table = 'm_members';`です。推論は英語の複数形に従うため、`Index`モデルは`indices`テーブルを探す点にも注意してください。 ### StudlyCaseとは何ですか？ 単語の先頭をすべて大文字にしてつなぐ書き方で、PascalCase（アッパーキャメルケース）とほぼ同じ意味です。PSR-1は「StudlyCaps」と呼び、Laravelでは`Str::studly('order_item')`が`OrderItem`を返します。クラス名に使います。 ### Laravelでコントローラーを作るときの命名は？ `php artisan make:controller OrderItemController`のように、StudlyCaseのモデル名に`Controller`を付けます。CRUD用なら`--resource --model=OrderItem`を付けると、7つの標準アクションと、ルートパラメータに一致する`$orderItem`引数が生成されます。 ## 関連記事 - [プログラミングの命名規則まとめ｜キャメルケース・スネークケースの違いとPythonのファイル名など6言語の書き方](/tech/details/2339/) - [php artisan makeコマンド一覧｜Laravel 13対応 生成先・オプション早見表](/tech/details/3759/) - [Laravel Eloquentとは｜モデル定義・リレーション・eager loadingの基礎とクエリビルダの使い分け](/tech/details/17127/) - [Laravel Pintとは｜プリセット選定とCI差分チェック運用の判断基準](/tech/details/17143/) - [Laravelマイグレーションの使い方｜php artisan migrateとrollback・freshの挙動を13.xで検証](/tech/details/7253/) --- 出典: [Laravelの命名規則一覧｜テーブル・モデル・コントローラーとコーディング規約【Laravel 13対応】]()（株式会社一創）