Laravelの命名規則一覧｜テーブル・モデル・コントローラーからコーディング規約まで

Laravelは「規約に従って名前を付けると設定が要らない（設定より規約）」という思想で作られています。テーブル名やモデル名を決められた形にしておくだけで、Eloquentが自動でテーブルを結び付け、リソースルートが標準のアクション名を生成します。逆に命名を外すと、その分だけ手で設定を書き足すことになります。この記事では、テーブル・モデル・コントローラーからマイグレーション・ルート・定数まで対象別の命名規則を一覧で整理し、Eloquentの規約を外れるときの上書き方法、そしてLaravel Pintやartisanで命名を自動的に守る手段までをまとめます。

まとめ：Laravelの命名規則の要点

• 3つのケース：クラスはStudlyCase（UserController）、メソッド・変数はcamelCase（getUserName）、テーブル・カラムはsnake_case（order_items）が基本。土台はPHPのPSR-1／PSR-4／PSR-12。
• テーブルとモデルは対で決まる：モデルは単数StudlyCase（OrderItem）、テーブルは複数snake_case（order_items）。この対応が守られていればEloquentが自動で結び付ける。
• 規約を外すときは明示的に上書き：レガシーDBで名前が合わないときだけ、$tableや$primaryKeyで1行ずつ宣言する。独自ルールでフレームワークと戦わない。
• 命名はartisanで生成すると間違えない：php artisan make:modelなどが正しいケースでファイルを作る。手打ちで作らない。
• コーディング規約（スタイル）はPintで自動整形：ただしPintが整えるのはインデントやimport順などの書式で、変数名がcamelCaseかといった識別子の命名そのものは変えない。命名はレビューとRectorで担保する。

以下、命名の土台から対象別の一覧、規約の自動化までを順に見ていきます。

Laravel命名規則の土台｜PSR規約と3つのケース

Laravelの命名規則は独自ルールではなく、PHPの標準規約PSR（PHP Standards Recommendations）に乗っています。クラスの構造はPSR-1（基本コーディング規約）とPSR-4（オートロード）、コードの書式はPSR-12（拡張コーディングスタイル）が定めており、フレームワーク本体もこれに従っています。だからチームで名前を揃える議論をゼロから始める必要はなく、「PSRに従う」で大半が決まります。

実務で覚えるのは、どこで3つのケースを使い分けるかです。StudlyCase（先頭大文字のパスカルケース）はクラス名に使い、モデル・コントローラー・ミドルウェア・ジョブなどのファイル名兼クラス名がこれにあたります。camelCase（先頭小文字）はメソッド名と変数名、Eloquentのリレーションメソッドに使います。snake_case（小文字＋アンダースコア）はデータベースのテーブル名・カラム名、Bladeのファイル名、設定キーに使います。加えて、定数と.envのキーはUPPER_SNAKE_CASE（大文字＋アンダースコア）です。PHPの言語をまたいだ命名ケースの考え方はプログラミングの命名規則まとめ（キャメルケース・スネークケースの違い）でも整理しています。

対象別の命名規則一覧（早見表）

Laravelで名前を付ける主な対象と、そのケース・具体例を一覧にまとめます。迷ったらまずこの表で当たりを付け、個別の注意点は次章以降で確認してください。

テーブル・モデル・コントローラーの命名

テーブル名｜snake_caseの複数形

テーブル名はsnake_caseの複数形にします。ユーザーならusers、注文明細ならorder_itemsのように、単語をアンダースコアで区切って最後を複数形にするのが基本です。この形にしておくと、後述のモデルがテーブル名を自動で推論できます。カラム名も同じくsnake_caseで、主キーは慣例でid、外部キーは参照先モデルの単数名＋_id（user_id）です。多対多の中間テーブルは、関連する2モデルの単数名をアルファベット順にアンダースコアでつないだ形（role_user）を既定とします。

モデル名｜StudlyCaseの単数形

モデル名はテーブルと対になる形で、StudlyCaseの単数形にします。usersテーブルならUser、order_itemsならOrderItemです。Eloquentはモデル名を「単数→複数・snake_case化」してテーブル名を推論するため、この対応を守っていれば$tableの指定は不要になります。新規のLaravelアプリではモデルはapp/Models配下に置かれ、名前空間はApp\Models\Userのようにディレクトリ構造とPSR-4で一致させます。

コントローラー名｜StudlyCase＋Controllerサフィックス

コントローラーはStudlyCaseで、末尾に必ずControllerを付けます（UserController・OrderController）。サフィックスは規約であり、これを付けることでルート定義やコード検索でコントローラーだと一目で分かります。CRUD操作を担うリソースコントローラーでは、メソッド名も規約で決まっており、index・create・store・show・edit・update・destroyの7つが標準アクションです。この名前でメソッドを用意すると、リソースルート1行がそれぞれに対応するURLとHTTPメソッドを自動で割り当てます。

メソッド名・変数名｜camelCaseと動詞始まり

メソッド名と変数名はcamelCaseです。メソッドはgetUser・updateStatusのように動詞で始めると、何をするかが名前だけで伝わります。変数も$userName・$orderTotalのように意味の分かる名前にし、$aや$tmpのような省略は避けます。注意したいのは、同じ「変数名」でも文脈でケースが変わる点です。PHP側の変数はcamelCaseですが、その値がデータベースのカラムやBladeに渡るデータのキーになる場合は、対応するsnake_case（$user->created_at）で扱います。名前の付け方はPHPに限らず言語共通の考え方が土台にあります。

ルーティング・マイグレーション・Blade・定数の命名

ルーティング｜リソースルートと名前付きルート

ルートには名前付きルートを付け、users.index・users.showのように「リソース名.アクション」をドットでつなぎます。名前を付けておくと、テンプレートやリダイレクトでURL文字列を直書きせずroute('users.show', $user)で参照でき、パスを変更しても呼び出し側を直さずに済みます。リソースルートを使えばこの命名は自動生成されます。URI名は開発者が指定でき（Laravelが自動変換するわけではない）、小文字複数形にハイフンをつなぐ形（/order-items）が慣例です。Web用ルートとAPI用ルートは接頭辞（api/）とファイルで分けて管理します。

マイグレーション｜日時＋動詞＋テーブル名

マイグレーションファイルは2024_01_01_000000_create_users_table.phpのように「日時_動作_対象テーブル」で命名します。先頭のタイムスタンプはLaravelがコマンドでファイルを作る際に自動で付与し、実行順序を保証します。動作部分は用途で語を変えるのが規約で、テーブル新規作成はcreate_〇〇_table、カラム追加はadd_〇〇_to_〇〇_table、変更はchange_〜のように、ファイル名だけで何のための変更かが分かるようにします。マイグレーションの書き方そのものはLaravelのマイグレーションの基本で、列にEnumを使う場合はLaravelでのEnum実装方法で詳しく扱っています。

Blade・ビューファイル｜snake_caseとコンポーネントのkebab-case

Bladeのビューファイルは.blade.php拡張子で、ファイル名はsnake_case（user_profile.blade.php）が一般的です。公式に強制される規約はなく、kebab-caseやドット記法を使うプロジェクトもありますが、いずれか1つに統一し機能ごとにディレクトリで整理します。一方、Bladeコンポーネントのタグはkebab-caseで、<x-user-card/>のようにハイフン区切りで書きます。同じビュー周りでもファイル名とコンポーネントタグでケースが異なる点は間違えやすいので、表の該当行で確認してください。

リレーションメソッド・定数・設定｜単複とUPPER_SNAKE_CASE

Eloquentのリレーションメソッドは、返す関係の数で単複を変えます。1対1や多対1（hasOne・belongsTo）は単数（user()）、1対多や多対多（hasMany・belongsToMany）は複数（posts()）にすると、呼び出し側の$post->user／$user->postsが自然な英語として読めます。定数はUPPER_SNAKE_CASE（const MAX_LOGIN_ATTEMPTS = 5;）、設定ファイルはconfig配下のsnake_case（config/services.php）でキーもsnake_case、.envのキーはUPPER_SNAKE_CASE（DB_DATABASE）です。秘密情報は.envに置き、設定ファイルからはconfig()経由で参照してコードに直書きしません。

Eloquentの規約を外れるときの上書き方法

規約通りに名付けるのが最善ですが、既存の業務システムやレガシーDBが相手だと、テーブルがm_members、主キーがmember_idのように規約と合わないことがあります。ここで無理にDBを改名するのではなく、モデル側でプロパティを宣言してEloquentに実際の名前を教えるのが正攻法です。

class Member extends Model
{
    protected $table = 'm_members';
    protected $primaryKey = 'member_id';
    public $incrementing = false;
    protected $keyType = 'string';
    public $timestamps = false;
}

$tableで推論と違うテーブル名を、$primaryKeyでid以外の主キーを指定します。主キーが自動連番でない文字列なら$incrementing = falseと$keyTypeを合わせます。created_at・updated_atを持たないテーブルでは$timestamps = falseにします。外部キーがリレーションの規約（参照先_id）と違う場合も、リレーション定義の第2引数で明示します。

public function author()
{
    return $this->belongsTo(User::class, 'author_id');
}

ここで大事なのは立場です。規約に乗れば書く設定は減り、外れれば外れた分だけ宣言が増える。だから「合わないから独自ルールで全部書き換える」のではなく、合わない箇所だけをモデルで1行ずつ上書きし、それ以外は規約に任せるのが保守しやすいコードになります。上書きが増えてきたら、それはDB側の命名を見直すサインでもあります。

命名規則を自動で守る｜Pint・artisan・静的解析

「laravel コーディング規約」を守るとき、手作業のレビューだけに頼ると抜けが出ます。Laravelには命名とコードスタイルを機械的に揃える仕組みが用意されており、役割ごとに使い分けます。ここは混同されがちなので、何が何を担保するのかを切り分けます。

Laravel Pint｜標準搭載のコードスタイル整形

Laravel Pintは、新規のLaravelアプリすべてに標準で同梱されるコードフォーマッタです。vendor/bin/pintを実行するだけで、インデント・空白・import順・波括弧の位置などをプロジェクト全体で自動的に揃えます。設定なしの既定プリセットはlaravelで、これはPSR-12をベースにLaravel固有のルールを足したものです。ほかにpsr12（Laravel拡張なしの素のPSR-12）・per・symfony・emptyのプリセットをpint.jsonで選べます。CIではvendor/bin/pint --testを使うと、整形せずに違反の有無だけを検査でき、規約から外れたコードのマージを止められます。

ただし注意が必要です。Pintが整えるのは「コードスタイル（書式）」であり、変数名をsnake_caseからcamelCaseに直すような識別子の命名そのものは変えません。命名規則の一覧を守らせる目的でPintを入れても、名前の付け方自体は自動修正されない点を理解しておくと、期待とのズレを避けられます。

php artisan make系｜生成時に正しい名前を強制する

命名を最も確実に守る方法は、ファイルを手で作らずartisanコマンドで生成することです。php artisan make:model OrderItemはStudlyCaseでapp/Modelsに、make:controller OrderControllerはコントローラーを、make:migration create_orders_tableは日時付きのマイグレーションを、それぞれ規約に沿った名前とパスで作ります。php artisan make:model Photo -mcrのようにオプションを付ければ、モデル・マイグレーション・リソースコントローラーを一括生成でき、命名を手打ちで間違える余地がなくなります。

静的解析とRector｜命名の検査と一括変換

命名の逸脱をレビュー前に検出したいなら静的解析ツールを併用します。PHPStan（LaravelではLarastan）やPsalmは型や未定義参照を検査し、クラス・メソッドの参照ミスを拾います。両者の違いと選び方はPsalmとPHPStanの違いの比較で整理しています。既存コードの命名を一括で直したいときはRector（rector laravelで検索される自動リファクタツール）が有効で、ルールに沿ってクラス名やメソッド呼び出しを機械的に変換できます。より高速なPHPツールチェーンを求めるならMago静的解析ツールも選択肢になります。Laravel本体のバージョンによる差分はLaravel 12の新機能もあわせて確認してください。

よくある質問

Laravelのコーディング規約と命名規則は何が違いますか？

命名規則は「名前の付け方」（テーブルはsnake_case、クラスはStudlyCaseなど）を、コーディング規約はそれを含む「コードの書き方全般」（インデント・書式・PSR-12準拠）を指します。Laravelでは命名規則はPSRとフレームワーク規約、書式はLaravel Pintで担保する、という役割分担になっています。

モデル名とテーブル名がずれても動きますか？

動きますが、モデルにprotected $tableを書いて実際のテーブル名を明示する必要があります。規約どおり（モデルUser→テーブルusers）なら指定は不要です。ずれる場合だけ1行で上書きするのが基本です。

変数名はcamelCaseとsnake_caseのどちらが正しいですか？

PHPコード内の変数はcamelCase（$userName）です。snake_caseはデータベースのカラム名や設定キーで使います。同じ値でも、PHP変数として扱うときはcamelCase、DBカラムやBladeに渡すキーとして扱うときはsnake_caseと、文脈で使い分けます。

命名やコード品質を自動でチェックするツールはありますか？

コードスタイルはLaravel Pint（vendor/bin/pint --test）で検査でき、CIで違反を止められます。ただしPintは書式の整形が中心で、識別子の命名自体は変えません。命名や参照の逸脱はPHPStan・Psalmで検出し、既存コードの一括変換はRectorで行います。

php artisan makeで作れば命名は自動で正しくなりますか？

はい。make:modelやmake:controllerなどのartisanコマンドは、StudlyCaseのクラス名や日時付きのマイグレーションファイル名を規約どおりに生成します。ファイルを手作業で作るより命名ミスが起きにくいため、新規作成はartisan経由が確実です。

関連記事

• プログラミングの命名規則まとめ｜キャメルケース・スネークケースの違いと主要6言語の書き方
• Laravelにおけるマイグレーションの基本とその重要性
• LaravelでのEnum実装方法とその利点
• PsalmとPHPStanの違いを比較｜PHP静的解析ツールの選び方・使い方
• PEP8とは？Pythonコーディング規約の基本ルールとチェックツール