第34回: ミドルウェア — リクエストの「通過ゲート」で横断処理を集約する
同じ処理を複数のコントローラに書くと、修正漏れやロジックの不一致が起きやすくなります。ミドルウェアを使えば、HTTPリクエストの前後に共通処理を1箇所で定義し、ルートに適用できます。
Year
年: 2026年
第33回: フォームリクエストクラス — バリデーションを「コントローラの外」に出す
$request->validate([…]) をコントローラに直書きし続けると、メソッドが肥大化して可読性もテスト性も下がります。フォームリクエストクラスに切り出すことで、バリデーションと認可のロジックを1ヶ所に集約できます。
第32回: Bladeテンプレート — Viewを「読みやすく・再利用しやすく」組み立てる
を素のPHPで書くと、HTMLとロジックが混在してレビューしにくくなります。BladeはLaravel標準のテンプレートエンジンで、繰り返し・条件分岐・レイアウト継承を明快な構文で書けます。
第31回: コントローラとアクション — 「受け取る・判断する・返す」を明確に分ける
バリデーション・DB操作・メール送信……すべてをコントローラに詰め込むと、テストも修正も困難になります。コントローラはリクエストを受け取り、適切なレスポンスを返す「司令塔」に徹するのが正しい設計です。
第30回: ルーティング設計 — URLと処理を「一覧できる地図」に整える
ルーティングの定義が散漫になると、バグ修正の際にどのファイルを触ればいいか迷いが生じます。Laravelのルーティングを正しく設計することで、アプリの全体構造を一目で把握できる「地図」が手に入ります。
第29回: Laravelのインストールと構成 — 最初の一歩を確実に踏み出す
フレームワークを使い始めるとき、最初の環境構築でつまずいてしまい、そこから先へ進めなくなる経験は多くの学習者が通る道です。Laravelは機能が豊富なぶん、「どの手順を・どの順番で・何を確認しながら」進めるかが曖昧なまま始めると、エラーの原因すら特定できない状態に陥りがちです。
第28回: APIバージョニング — 既存クライアントを壊さずに進化させる
レスポンスのフィールド名を変えたり、必須パラメータを追加したりすると、既存のモバイルアプリやフロントエンドが動作しなくなります。全クライアントが同時にアップデートできるとは限りません。
第27回: レート制限の実装 — 「1分60回まで」でAPIを守る
認証なしのAPIエンドポイントは、悪意のある大量リクエストや誤ったループ処理によって、サーバーリソースが枯渇する危険があります。結果として、全ユーザーへのサービス品質が低下します。
第26回: JWTによる認証 — ステートレスな「自己完結するトークン」の仕組み
複数サーバーで負荷分散するAPIや、モバイルアプリとWeb API間の認証では、サーバー側にセッションを持つと状態管理が複雑になります。「どのサーバーがセッションを持っているか」を共有するためにRedisやスティッキーセッションが必要になるからです。
第25回: 認証付きAPI（APIトークン） — 「誰がリクエストしているか」をSanctumで確認する
/api/users エンドポイントを作ったとき、認証がなければ世界中の誰でもアクセスできてしまいます。ユーザーデータや機密情報を扱うAPIには必ず「このリクエストは誰から来ているか」を確認する仕組みが必要です。