Day13 — ミドルウェアでリクエストを加工する：認証・ログ・バリデーションの入口を作る

はじめに

昨日（Day12）は
👉 レスポンス(JSON) の統一設計
について学びました。

今日からは、より “アプリケーションとしての土台” に踏み込みます。

今日のゴール

・ ミドルウェアとは何か？ が整理して理解できる

・ ミドルウェアがどこに挟まるか を図で理解できる

・Laravel でミドルウェアを作り、
　👉 ログ
　👉 認証
　👉 バリデーション
　の入口となる処理を追加できる

・アプリの「共通処理」を一箇所に集約できるようになる

ミドルウェアとは？

ズバリこれ。

「リクエストがコントローラに届く前に必ず通過する関所」

図にするとこうです：

ブラウザ
   ↓
[ ミドルウェア ] ← 今日作るのはココ
   ↓
コントローラ
   ↓
レスポンス(JSON)

ミドルウェアの役割は大きく3つ

① リクエストログ

「誰が・いつ・どんなリクエストを送ったか」を記録する。

② 認証処理

トークンやCookieを確認して「ログインしているか」を判断。

③ 共通のバリデーション

全 API 共通のチェックをかける。

ミドルウェアが無いとどうなる？

悪夢です。

// 全コントローラの全メソッドでログを書く…
Log::info($request->all());

if (!$request->bearerToken()) {
  return response()->json(...);
}

// バリデーションも毎回書く…

➡️ 重複だらけ
➡️ 保守不能
➡️ 漏れが発生

だからミドルウェアに集約することで
アプリ全体の “入口” を固めることができます。

実践：リクエストログミドルウェアを作る

まずはログを記録するミドルウェアを作成します。

php artisan make:middleware RequestLogMiddleware

生成されたファイルを編集：

app/Http/Middleware/RequestLogMiddleware.php

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;

class RequestLogMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        Log::info('Request received', [
            'ip' => $request->ip(),
            'url' => $request->fullUrl(),
            'method' => $request->method(),
            'body' => $request->all(),
        ]);

        return $next($request);
    }
}

ポイント：

・リクエストの内容を全部ログに残す

・コントローラへ進む前に実行される

・$next($request) を必ず返すこと

ミドルウェアをアプリに登録する

app/Http/Kernel.php に登録します。

protected $middleware = [
    \App\Http\Middleware\RequestLogMiddleware::class,
];

これで
すべてのリクエストでログが記録 されます。

認証ミドルウェアを作ってみる（Bearer Token）

次は認証用のミドルウェア。

php artisan make:middleware ApiAuthMiddleware

編集：

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class ApiAuthMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        $token = $request->bearerToken();

        if (!$token || $token !== 'SECRET_TOKEN_123') {
            return response()->json([
                'status' => 'error',
                'message' => '認証が必要です'
            ], 401);
        }

        return $next($request);
    }
}

※ 本番では DB でトークン管理しますが、今日は仕組み理解が目的です。

API ルートにだけ認証をかける

認証は 全ページにかけたくない ケースが多いので group に適用します。

routes/api.php

Route::middleware('api_auth')->group(function () {
    Route::get('/posts', [PostController::class, 'index']);
});

Kernel.php に登録：

protected $routeMiddleware = [
    'api_auth' => \App\Http\Middleware\ApiAuthMiddleware::class,
];

ミドルウェアの良さを実感する例

たとえば

・ログを残す

・認証をチェックする

・ペイロードの必須キーを確認する

これらをミドルウェアにまとめれば…

コントローラはこうなる

public function index()
{
    return response()->json([
        'status' => 'success',
        'data' => Post::all()
    ]);
}

コントローラは
👉 ビジネスロジックのみに集中できる。

ミドルウェアでよくある処理一覧

処理	ミドルウェアに書くべき？
APIログ記録	◎
認証チェック	◎
全API共通のバリデーション	◎
特定のAPIのバリデーション	✖（FormRequestへ）
メンテナンスモード処理	◎
CORS制御	◎

ミドルウェアは

「アプリ全体の統一した入口に置くべき処理」
だけを書くのがポイントです。

今日のまとめ

・ミドルウェアは「リクエストの関所」

・各APIの前に必ず通過する

・ログ・認証・共通バリデーションはミドルウェア向き

・Laravel では簡単に独自ミドルウェアを作れる

・入口に共通処理を置くとアプリが一気に綺麗になる

明日の Day14

Day13 では

👉 ミドルウェアでリクエストを加工する入口
を作りました。

次は

コントローラでビジネスロジックを扱うための設計手法
役割を分割して綺麗なコードを書く方法

に進みます。