もう迷わない！Laravelプロジェクトの正しいディレクトリ構成と設計ベストプラクティス

Laravelのディレクトリ構成を俯瞰してみよう

まずは、Laravelプロジェクトを最初に開いたとき、多くのファイルやフォルダが並んでいて圧倒されますよね。 でも、全てを理解する必要はありません。実際によく使う場所は決まっています。

project/
├── app/
│   ├── Http/
│   │   ├── Controllers/
│   ├── Models/
├── bootstrap/
├── config/
├── database/
│   ├── migrations/
│   ├── seeders/
├── public/
├── resources/
│   ├── views/
│   ├── lang/
├── routes/
│   ├── web.php
├── storage/
├── tests/

この中で、開発でよく触るのは次の4つです👇

• routes/… URLと処理の入口
• app/Http/Controllers/… リクエストを受け取る場所
• app/Models/… データベースと結びついたクラス
• resources/views/… 画面表示（Bladeテンプレート）

まずは「アプリはこの4つが繋がって動いている」という理解からスタートしましょう。

初心者がやりがちな「プロジェクトが崩れる」原因

多くのLaravel初心者（そして過去の私も含めて…）は、開発の初期段階では順調に進みますが、機能が増え、ファイルが増えるにつれて、まるで雪だるま式に複雑化していくという問題にぶつかります。その典型的な症状は、次の3点に集約されます。

• Controllerに処理を書きすぎて肥大化してしまう（ファットコントローラー問題）

  リクエストの受け付け、バリデーション、複数のModel操作、さらには外部APIとの連携や複雑な計算ロジックまで、すべてをControllerのメソッド内に記述してしまいます。結果として、一つのファイルが数百行にも膨れ上がり、どこに何が書かれているのか、何をしているのか一目で把握できなくなります。

• Modelにビジネスロジックまで書いてしまう（なんでも屋化）

  LaravelのModel（Eloquent）はデータベースとの通信を担当するレイヤーですが、ここに「注文完了時の在庫調整」や「ユーザーのポイント計算」といった純粋な業務ロジックまで記述されてしまいます。これにより、データベースを使わない場所で同じロジックを再利用できず、テストも困難になります。

• View側にもロジックが入り始めてしまう

  Bladeテンプレートに「もし〇〇だったらこの表示」「この条件ならこの計算」といった表示以外の判断ロジック（例えば、複雑なデータ加工や条件分岐）を書き込み始めると、デザインの変更だけでもアプリケーションの深い部分に影響が及ぶようになり、保守性が著しく低下します。

これらの問題の根本的な原因は、極論すると「責務（役割）の分担」が曖昧なまま開発していることに尽きます。
Laravelはその哲学として、開発者に大きな自由を与えます。これはすぐに動くものが作れるという強力なメリットですが、裏を返せば「どう設計するか」というアーキテクチャの意思決定を開発者自身が行う必要があるということです。この設計段階で、各クラスや層に「このクラスはこれだけをやる」という明確な境界線（単一責任の原則）を引かないと、プロジェクトは必ず構造的な崩壊を迎えてしまいます。

迷わないためのフォルダ構成ルール：シンプルな Service 層の導入

複雑な設計パターン（例えば、RepositoryパターンやDomain層など）は、確かに理想的ですが、プロジェクトの初期段階や小～中規模のプロジェクトでは、導入コストの高さが障壁になりがちです。今回は、「初心者でも続けられる」ことを最優先にし、Repository 層は一旦使いません。その代わり、最もシンプルで効果的な分離を実現するService層を導入します。

導入するのは、「app/Services」ディレクトリだけです。

app/
  Http/
    Controllers/
  Models/
  Services/  ← これを app ディレクトリ直下に作成！

たったこれだけ追加するだけで、Controllerが「リクエストの窓口」という本来の役割に専念できるようになり、処理の見通しが劇的に改善します。

Controller → Service → Model の責務と処理の流れ

Service層を導入することで、各レイヤーの責任範囲は以下のように明確に定義されます。この責務の分離こそが、保守性を高める最大の秘訣です。

// 例：ユーザ情報を扱うケース（注文処理や在庫処理などの複雑なロジックは Service に集約される）

【Controller】: リクエストの受付と応答のみ
- リクエストデータ（フォームデータなど）を受け取る
- バリデーションを実行する (ただしシンプルなものに留める)
- Service を呼び出すだけ（純粋なビジネスロジックは一切書かない！）
- Service から受け取った結果をもとに View を返すか、リダイレクトする

【Service】: ビジネスロジックの実行層（このパターンでの主役）
- 複雑な計算、複数のModelを跨いだ操作など、業務上のルールをすべてここに記述する
- トランザクション処理や外部APIとの連携処理も担当する

【Model】: データベース操作のみ
- DBとのデータ操作（CRUD）だけを担当する
- リレーション（hasManyなど）の定義もここで行う

Controller の実装例：窓口役としての徹底

Controllerの役割は、「誰かに仕事を依頼し、その結果を返す」ことです。処理がどれほど複雑になろうと、Controllerはこのシンプルさを保ちます。Laravelの依存性注入（Dependency Injection, DI）を活用して、Serviceをコンストラクタやメソッドに注入しましょう。

<?php

namespace App\Http\Controllers;

use App\Services\UserService; 
use Illuminate\Http\Request; // リクエストの処理

class UserController extends Controller {
    // DIにより UserService が自動的に注入される
    public function index(UserService $service) {
        // Controllerは「誰に」「何をさせるか」だけを指示する
        $users = $service−>getAllUsers(); 

        // 取得した結果を View に渡して応答する
        return view('users.index', compact('users'));
    }

    // 例えば、複雑な更新処理も Service に丸投げ
    public function update(Request $request, UserService $service, int $userId) {
        // シンプルなバリデーションは Controller で行ってもOK
        $request−>validate(['name' => 'required|max:255']);

        // 処理の本体は Service 側で実行
        $service−>updateUser($userId, $request−>validated()); 

        return redirect()−>route('users.show', ['user' => $userId])
                         −>with('success', 'ユーザー情報を更新しました。');
    }
}

Service の実装例：ビジネスロジックの要塞

Service層は、アプリケーションの「頭脳」となる部分です。Controllerがシンプルになる分、ここでは「何をしたいか」という目的に沿ってコードが書かれることになります。Controller側の update メソッドに対応する UserService の例を見てみましょう。

<?php

namespace App\Services;

use App\Models\User;
use Illuminate\Support\Facades\DB; // トランザクションの使用

class UserService {
    /
     * すべてのユーザーをID降順で取得する
     */
    public function getAllUsers() {
        // シンプルなDBアクセスは Model に任せる
        return User::orderBy('id', 'desc')−>get();
    }

    /
     * ユーザー情報を更新し、関連するログ記録も行う（複雑なロジックの例）
     */
    public function updateUser(int $userId, array $data): User {
        // 複雑な処理をトランザクションで囲む
        return DB::transaction(function () use ($userId, $data) {
            $user = User::findOrFail($userId);

            // ユーザー情報（Model）の更新
            $user−>update($data);

            // ログの記録や他のシステムへの通知など、業務ロジックを実行
            // Log::create(['user_id' => $userId, 'action' => 'user_updated']); 

            return $user;
        });
    }
}

Model の実装例：純粋なデータの番人

Modelは、データベースのスキーマに忠実な「データの箱」としての役割に立ち戻ります。カスタムメソッドやスコープを定義することはあっても、上記 Service層で行うような複数の処理を統合するビジネスロジックは書きません。

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class User extends Model {
    /**
     * 複数代入可能な属性
     *
     * @var array
     */
    protected $fillable = [
        'name',
        'email',
        // ...
    ];

    // 例：User に関連する注文（Order）リレーションのみを定義
    public function orders() {
        return $this−>hasMany(Order::class);
    }
}

このように、Controller → Service → Model の流れを徹底するだけで、Controllerが超シンプルになり、アプリケーションが持つすべてのビジネスルールが app/Services ディレクトリに集約されます。
この設計を採用することで、あとから読み返しても「何をしているか」がすぐ分かるようになり、機能の追加や変更もServiceファイルの中だけで完結しやすくなります。

❓ ディレクトリ(クラス)設計に関するよくある質問（FAQ）と答え

• Q1. Serviceクラスは必ず作るべきですか？Controllerに直接書いてはいけませんか？

  A. 「必ず」ではありませんが、 Controllerの肥大化を防ぎ、コードの健全性を保つために、Service層の導入を強く推奨します。

  • 【なぜ推奨されるか】 複雑なビジネスロジックをControllerに直接書き始めると、数ヶ月後には一つのControllerメソッドが数百行に達し、修正やテストが困難になります。Serviceクラスは、この複雑な処理をControllerから切り離し、再利用可能な部品として管理するための場所です。
  • 【結論】 小さな処理や学習目的のコードであればController直書きでも問題ありませんが、「Controllerをスリムに保つ」ためのシンプルな設計方法として、Service層は早期に導入するのが最も有効な手段です。

• Q2. Repository層は使わなくていいの？Modelとどう違うのですか？

  A. 初心者のうちは使わなくてOKです。 まずは Controller → Service → Model のシンプルな三段構造に慣れることに集中しましょう。

  • 【Repository層の役割】 Repository層は「データ取得方法を抽象化する」ための仕組みです。たとえば「Userのリストを取得する」という処理に対し、データソースがDBであっても、外部APIであっても、Service層は同じように呼び出せるようにします。
  • 【導入の判断】 アプリケーションが成長し、「DBの種類を将来的に切り替える可能性がある」「テスト時にDB接続を完全に切り離したい」といった具体的なニーズが出てきてから導入しても遅くありません。規模が小さいうちに導入すると、コードの複雑さだけが増してしまうことがあります。

• Q3. Modelには何を書けばいいの？ビジネスロジックは一切禁止ですか？

  A. Modelは基本的に「そのエンティティ（データ）に関するDB操作と定義」だけを担当させます。

  • 【Modelの責務】
    • データベースとのやり取り: Eloquentのリレーション定義（hasMany, belongsToなど）や、データの取得・保存（save()）。
    • データの整形: データの型定義（$casts）や、アクセサ・ミューテータ（データの読み書き時の加工）。
  • 【ロジックの書き方】 複雑な計算、複数のModelをまたぐ処理、外部サービスとの連携など、ビジネス上の判断を伴うロジックはすべて Serviceクラスに移しましょう。Modelを「データそのもの」を表現するシンプルな存在として扱うことが、プロジェクトを長続きさせる秘訣です。

• Q4. プロジェクトが大きくなってきたら、今の設計で大丈夫でしょうか？

  A. 大丈夫です。 あなたが今、Service層を導入しているなら、その設計は拡張の準備ができています。

  • 【Service層の利点】 Service層がアプリケーションの中心的なロジックを担っているため、後から新しい層（例：Domain層、Repository層）を追加しても、ControllerやViewといった他の部分に大きな影響を与えることなく、スムーズに拡張できます。
  • 【次の段階】
    • 複雑な集計: Query ObjectやActionクラスを導入して、Service層からさらにロジックを分離。
    • 外部連携: API Client層を追加し、Serviceが外部サービスへの依存を持たないように抽象化。

  「必要になったときに追加する」というアプローチが、Laravelの柔軟性を最大限に活かす賢い方法です。

🙅‍♂️ 初心者がやりがちな「設計の失敗例」と、Service層による劇的な改善方法

Laravel開発において、コードが「汚く」「読みにくく」「メンテナンス不能」になる原因の9割は、責務の分担が曖昧であることにあります。ここでは、具体的な失敗コードと、Service層を導入することでどのように改善されるかを見ていきましょう。

❌ 失敗例1：Controllerに「全て」のロジックを書きすぎてしまう（Fat Controller）

Controllerの役割は、リクエストを受け取り、適切な処理を呼び出し、レスポンスを返すことだけです。データベースへの問い合わせや複雑なデータ加工は、Controllerの本来の責務ではありません。

<?php

// ❌ Bad Code (UserController.php)
public function index() {
    // 1. DBクエリを記述
    $users = User::where('age', '=<', 20)−>orderBy('id', 'desc')−>get(); 

    // 2. 複雑なデータ加工ロジックを記述
    $users = $users−>filter(fn($user) => $user−>is_active); 

    // 3. レスポンスを返す
    return view('users.index', compact('users'));
}

→ 改善：Serviceにロジックを移し、Controllerを薄く保つ

複雑なロジックを UserService に移譲することで、ControllerはただServiceを呼び出すだけのシンプルな役割に戻ります。このControllerは「薄い（Thin）」と表現され、テストも非常に容易になります。

<?php

// ✅ Good Code (UserController.php)
public function index(UserService $service) {
    // サービスを注入し、メソッドを呼び出すだけ
    $users = $service−>getActiveUsers(); 
    return view('users.index', compact('users'));
}

【メリット】 Controllerに書かれていたロジックを、別の場所で再利用したい場合（例：APIからも同じロジックを使いたい場合）に、Serviceメソッドを呼び出すだけで済み、コードの重複が完全に解消されます。

❌ 失敗例2：Modelにビジネスロジックを詰め込む（Modelのなんでも屋化）

Modelの本来の責務は、データベースの定義とデータ操作（CRUD）です。ビジネス上の判断や、複数のテーブルをまたぐようなロジックはModelに書くべきではありません。

<?php

// ❌ Bad Code (User.php Model)
class User extends Model {
    // Modelなのに、ビジネス上のフィルタリングロジックが書かれている
    public function getActiveUsers() { 
        // クエリビルダを使っているが、これは本来Serviceで呼び出すべき
        return self::where('is_active', true)−>get();
    }
}

→ 改善：Modelはデータ構造に専念させ、ロジックはServiceに移す

Modelはデータ構造とリレーションシップの定義に専念させ、ロジックを実行する責務はServiceに持たせます。これにより、ModelとDBアクセスを切り離したテストも容易になります。

<?php

// ✅ Good Code (UserService.php Service)
class UserService {
    // Service層が、どのModelを、どのように操作するかを決定する
    public function getActiveUsers() { 
        return User::where('is_active', true)−>get(); 
    }
}

【メリット】 Modelをシンプルに保つことで、DBのスキーマ変更があった際も、影響範囲がそのModel内に留まりやすくなります。

❌ 失敗例3：フォルダを作る時にルールがない（プロジェクトの散らかり）

開発が進みファイルが増えてきたとき、「この特定の計算処理はどこにある？」という状態が頻繁に発生し始めます。これは、責務ごとにファイルを配置するルールがないために起きる問題です。

→ 改善：最初にシンプルな三段構成の置き場所のルールを決める

Laravelのデフォルト構造に手を加えるのは怖くありません。app ディレクトリ直下に Services フォルダを追加し、責務を明確に分けるだけで、誰もが理解できるシンプルな構造が完成します。

app/
 ├ Http/
 │  └ Controllers/  ← 🚪 【入口】リクエストを受け付け、Serviceに仕事を依頼する
 ├ Models/         ← 💾 【データ】データベースとのやり取りだけを担当する
 └ Services/       ← 🧠 【ロジック】すべてのビジネス処理、複数のModelの連携を担う
    

この「Controller → Service → Model」というシンプルな三段構成は、アプリケーションが小さくても大きくても通用する、拡張性に優れた構成です😊。

設計は「ルール」であり、「センス」ではない

設計は「センス」や「才能」ではなく、「ルールを知っているかどうか」だけです。あなたがControllerの肥大化という課題を認識し、Service層の導入というシンプルなルールを採用した時点で、確実に一歩プロの開発者として前進しています。

この調子で、無理なく育てられ、数年後も誰が見ても美しいLaravelアプリケーションを書いていきましょう✨。

🎉 まとめと実践への道：迷わず育てられる Laravel アプリ設計への転換

ここまでお疲れさまでした！本記事を通じて、Laravelアプリケーションが成長する過程で「なぜ設計が崩れるのか」という原因を理解し、その崩壊を防ぐためのシンプルで効果的な設計哲学を学びました。

Laravelは非常に自由度が高く、それが魅力ですが、同時に「どこに何を書くか」という責務の境界線 が曖昧になりがちです。しかし、今回紹介した Controller → Service → Model の三段構造を意識するだけで、あなたの開発体験は驚くほどスムーズになり、コードの品質は向上します。

あなたが今日手に入れた、崩れない設計の原則

• 🚪 Controller の役割：入口と出口の番人

  Controller は「入口と出口だけ」に専念させ、リクエストの受付とレスポンスの返却以外の複雑な処理は一切書かない、薄い（Thin）状態を保ちます。

• 🧠 Service 層の役割：ロジックの中心地

  Service には、ビジネスロジック、複数の Model をまたぐ複雑な処理、外部連携など、アプリケーションの中核となるすべてのロジックを集めます。Controller と Model を仲介する役割を担います。

• 💾 Model の役割：データ構造の定義者

  Model は データベース（DB）とのやり取りとリレーション定義 だけに専念させ、Service 層から呼び出されるシンプルな存在として扱います。

• 📂 フォルダ構成：小さく、シンプルに。

  app/Services フォルダを追加するという小さな一歩が、後々コードを探し回る無駄な時間をなくし、大きなプロジェクトを管理可能にするための決定的な一歩となります。

🚀 今すぐ実践！次のアクションを起こしましょう

設計は「知識」ではなく「習慣」です。この知識を定着させ、あなたのアプリケーションをより良くするために、たった一つだけ今すぐ実行してほしいことがあります。

1. 1. 📁 app/Services フォルダを作成する

   あなたの現在のLaravelプロジェクトの app ディレクトリ直下に、Services という名前の新しいフォルダを作成してください。これで、ロジックの避難場所ができました。

2. 2. ✂️ 最も肥大化した Controller のロジックを Service に移動する

   アプリケーション内で最も長い Controller メソッドを見つけ、その中でビジネスロジック（DBクエリの羅列、複雑な条件分岐など）になっている部分を切り出し、新しい Service クラス（例: UserService）のメソッドとして貼り付けてみましょう。そして、Controllerからはその Service メソッドを呼び出すだけに修正します。

あなたのアプリは、あなたがこれから育てていく大切な作品です。無理なく、読みやすく、そして作っていて気持ちのよいコードを目指していきましょう。その小さな一歩が、数ヶ月後のあなた自身を助けることになります。

さあ、ターミナルで mkdir app/Services を実行しましょう！💻✨