収録問題 80問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
Laravelで、GET /users/{user} を UserController@show に結び付けたい。最も自然な定義はどれですか？
答え： Route::get('/users/{user}', [UserController::class, 'show']);
Route::get はGETリクエストのルート定義に使います。配列形式でControllerクラスとメソッドを指定できます。
Laravelで、ルートパラメータ {user} から自動的に User モデルを受け取りたい。主に使われる仕組みはどれですか？
答え： ルートモデルバインディング
ルートモデルバインディングにより、ルートパラメータから対応するEloquentモデルをController引数へ注入できます。
LaravelのControllerで、リクエスト入力を直接 $_POST から読むより望ましい方法はどれですか？
答え： Requestオブジェクトを引数で受け取り、検証して使う
LaravelではRequestオブジェクトを使うと、入力取得、認可、バリデーションなどをフレームワークの流儀で扱えます。
入力検証が複雑で複数Controllerから再利用したい。Laravelで分離先として自然なのはどれですか？
答え： Form Request クラス
Form Requestは認可やバリデーションルールを専用クラスへ分離できます。Controllerを薄く保つのに役立ちます。
Laravelでユーザーと投稿の1対多関係を表すとき、Userモデル側に定義する代表的なリレーションはどれですか？
答え： hasMany(Post::class)
ユーザーが複数投稿を持つ側なので、Userモデルには hasMany を定義します。投稿側からユーザーを見る場合は belongsTo です。
一覧画面で投稿と投稿者を表示するとN+1クエリが発生している。Laravelでまず検討する対策はどれですか？
答え： with('user') でEager Loadingする
関連モデルを事前取得するEager Loadingにより、ループ中の追加クエリを減らせます。
LaravelでMass Assignmentを安全に扱うため、モデルに設定する代表的なプロパティはどれですか？
答え： $fillable
$fillable は一括代入を許可する属性を明示します。意図しないカラム更新を防ぐために重要です。
LaravelでDBスキーマ変更をチームで共有し、履歴として管理するために使うものはどれですか？
答え： Migration
Migrationはテーブル作成やカラム追加などのDBスキーマ変更をコードとして管理する仕組みです。
外部キー制約付きのテーブルを削除するマイグレーションで、順序に注意が必要な理由はどれですか？
答え： 参照されているテーブルを先に消すと制約違反になる場合があるため
外部キー制約がある場合、参照関係に応じて制約を外す、または子テーブルから削除するなどの順序設計が必要です。
Laravelで、email が必須かつメール形式であることを検証したい。代表的なルールはどれですか？
答え： 'email' => ['required', 'email']
required は必須、email はメール形式の検証に使います。複雑な入力ではForm Requestへ分離すると管理しやすくなります。
Laravelで入力検証に失敗したとき、通常のWebリクエストで期待される基本動作はどれですか？
答え： 前のページへリダイレクトし、エラー情報をセッションに保持する
Webリクエストでは、検証失敗時に前画面へ戻し、エラーメッセージや古い入力を表示する流れが一般的です。
Laravelで、特定ルートをログイン済みユーザーだけに制限したい。代表的に使うものはどれですか？
答え： auth middleware
auth ミドルウェアは、未認証ユーザーをログイン画面へ誘導するなど、認証が必要なルートを守るために使います。
LaravelでCSRF保護が主に必要になる場面はどれですか？
答え： 状態を変更するフォーム送信やPOST/PUT/DELETEリクエスト
CSRFは利用者の認証状態を悪用して意図しない状態変更を行わせる攻撃です。状態変更リクエストでトークン検証が重要です。
メール送信や画像処理など、HTTPレスポンスを遅くしたくない重い処理を後回しにしたい。Laravelで使う代表的な仕組みはどれですか？
答え： Queue Job
Queue Jobを使うと、重い処理をキューへ投入し、workerで非同期に処理できます。
Laravelのqueue workerを本番運用する際、デプロイ後に再起動が必要になりやすい理由はどれですか？
答え： workerは長時間動き続け、新しいコードを自動で読み直さない場合があるため
queue workerは常駐プロセスなので、デプロイ後に新しいコードや設定を反映するため再起動運用が必要になります。
Bladeでユーザー入力をHTMLに表示するとき、通常の {{ $name }} が安全寄りとされる理由はどれですか？
答え： HTMLエスケープされた出力になるため
Bladeの {{ }} は標準でエスケープされます。信頼できないHTMLをそのまま出す {!! !!} は慎重に扱います。
共通ヘッダーやフォーム部品を複数画面で再利用したい。Bladeで候補になるものはどれですか？
答え： Bladeコンポーネント
Bladeコンポーネントは表示部品を再利用し、テンプレートの重複を減らすために使えます。
Laravelで、ログインユーザーが特定の投稿を更新できるか判断するロジックを整理したい。適切な置き場所はどれですか？
答え： Policy
Policyはモデルに対する認可ロジックを整理するために使います。ControllerやBladeに散らばる条件を減らせます。
認証済みユーザーの情報をControllerで取得したい。Laravelで代表的な方法はどれですか？
答え： $request->user()
$request->user() は現在の認証済みユーザーを取得する代表的な方法です。認可処理ではPolicyやGateと組み合わせます。
Laravel本番で .env を変更したのに設定が反映されない。まず疑うべきものはどれですか？
答え： config cache
本番では config:cache を使うことがあります。設定キャッシュがある場合、.env 変更後にキャッシュ再生成が必要です。
Laravelで機密値をコードへ直書きせず、環境ごとに切り替えたい。基本方針として適切なのはどれですか？
答え： .envや外部Secret管理を使い、config経由で参照する
機密値はコード管理から分離し、環境変数やSecret管理から設定へ流すのが基本です。公開リポジトリやログへの漏えいを避けます。
Laravelで「このURLにアクセスされたら、この処理を実行する」という対応を定義する場所として基本的なのはどれですか？
答え： routes/web.php
routes/web.php はWeb画面向けのルート定義でよく使われます。URLとControllerやクロージャなどの処理を結び付けます。
LaravelでControllerの主な役割として適切なのはどれですか？
答え： リクエストを受け取り、必要な処理を呼び出してレスポンスを返す
Controllerはリクエスト処理の入口として、ModelやServiceを呼び出し、ViewやJSONなどのレスポンスを返す役割を持ちます。
Laravelで画面HTMLを組み立てるテンプレートエンジンとして基本的に使われるものはどれですか？
答え： Blade
BladeはLaravel標準のテンプレートエンジンです。レイアウト継承や条件分岐、ループなどを使ってHTMLを組み立てます。
LaravelのEloquent Modelが主に表すものはどれですか？
答え： データベースのテーブルやレコードをアプリ内で扱うためのクラス
Eloquent Modelは、テーブルやレコードをオブジェクトとして扱うためのクラスです。検索、保存、リレーション定義などに使います。
Laravelでテーブル作成やカラム追加など、DB構造の変更履歴をコードとして管理する仕組みはどれですか？
答え： Migration
MigrationはDBスキーマ変更をコードとして管理する仕組みです。チーム開発や環境差分の再現に役立ちます。
LaravelのログインAPIに対する総当たりを抑えるため、一定時間内の試行回数を制限したい。適切な仕組みはどれですか？
答え： RateLimiterまたはthrottleミドルウェア
Laravelのレート制限機能は、IPや利用者などをキーに試行回数を制御できます。認証失敗の応答を統一し、MFAや監視も組み合わせます。
メール内の退会リンクについて、URLパラメータの改ざんを検出し、有効期限も設定したい。適切なのはどれですか？
答え： 一時署名付きURLとsignedミドルウェア
Laravelの一時署名付きURLはURLへ署名と期限を付け、signedミドルウェアで改ざんや期限切れを検証できます。署名URLだけで本人確認要件をすべて満たすとは限りません。
Laravelで外部サービスの秘密情報をDBへ保存し、必要時に復号したい。パスワード保存とは別の用途として適切なのはどれですか？
答え： Laravelの暗号化機能やencryptedキャストを使い、APP_KEYを安全に管理する
復号が必要な秘密情報にはLaravelの暗号化機能を使えます。APP_KEYの漏えい対策とローテーション計画が重要です。利用者パスワードは復号せずHashで検証します。
Laravel本番環境で例外詳細、環境変数、スタックトレースの露出を避けるため、最低限確認すべき設定はどれですか？
答え： APP_DEBUG=false
本番ではAPP_DEBUG=falseにし、詳細は保護されたログや監視基盤で確認します。.envやログをWeb公開せず、デプロイ時に設定を検証することも重要です。
HTTPSで動くLaravelアプリで、セッションCookieをJavaScriptから読めないようにし、平文HTTPでは送信しないようにしたい。確認すべき設定の組み合わせはどれですか？
答え： http_onlyを有効にし、secureを有効にする
HttpOnlyはJavaScriptからのCookie参照を制限し、SecureはHTTPS通信時だけCookieを送信させます。CSRF対策にはSameSiteなども要件に合わせて検討します。
LaravelでHTTPエンドポイントの応答ステータスや表示内容を確認するテストとして適切なものはどれですか？
答え： Featureテストで get や post を実行し、assertStatus や assertSee を使う
Featureテストでは、LaravelアプリケーションにHTTPリクエストを送り、レスポンス、認証、DB状態などを実際の利用に近い形で検証できます。
LaravelのFeatureテストで、テスト後にDB状態を戻しやすくするためによく使うトレイトはどれですか？
答え： RefreshDatabase
RefreshDatabase はテスト実行時にマイグレーションやトランザクションを利用してDB状態を整え、テスト間のデータ汚染を防ぎやすくします。
本番デプロイ後に .env の値を変更したが、Laravelが古い設定を参照している。まず確認すべき操作はどれですか？
答え： 設定キャッシュをクリアまたは再生成する
Laravelで config:cache を使っている場合、設定はキャッシュから読まれます。.env 変更後は config:clear や再キャッシュが必要です。
Laravelで重い集計結果を一定時間だけ再利用し、期限切れ後に再計算したい。適切な機能はどれですか？
答え： Cache::remember
Cache::remember はキー、期限、クロージャを指定し、キャッシュがあれば再利用し、なければ計算して保存できます。高コストな集計の負荷軽減に役立ちます。
注文確定後にメール送信や在庫連携など複数の後続処理を疎結合に実行したい。Laravelで適切な設計はどれですか？
答え： イベントを発火し、Listenerで後続処理を分ける
LaravelのイベントとListenerを使うと、注文確定という事実と後続処理を分離できます。必要に応じてListenerをQueueへ載せることもできます。
Laravelで、投稿を更新できるのは投稿者本人だけにしたい。認可ロジックを整理する場所として適切なものはどれですか？
答え： Policy
Policyはモデルに対する操作権限を整理する仕組みです。ControllerやBladeから authorize や @can で利用できます。
Laravelで、複雑なバリデーションルールと認可をControllerから分離したい。適切な仕組みはどれですか？
答え： Form Request
Form Requestは、入力バリデーションとリクエスト単位の認可を専用クラスへ分離できます。Controllerを薄く保ち、テストもしやすくなります。
Laravelでアップロードファイルを直接 public/ 配下へ置かず、抽象化された保存先へ保存したい。適切な機能はどれですか？
答え： Storageファサードとfilesystem disk
LaravelのFilesystemはlocal、public、S3などのdiskを設定し、Storage 経由で保存先を抽象化できます。公開可否やURL生成も設計しやすくなります。
Laravel本番デプロイで、ユーザー影響を抑えつつキューワーカーへ新しいコードを反映したい。適切な操作はどれですか？
答え： php artisan queue:restart を実行し、ワーカーを順次再起動させる
Laravelのキューワーカーは常駐プロセスなので、デプロイ後も古いコードを保持することがあります。queue:restart は現在のジョブ完了後に安全に再起動させます。
注文登録と在庫減算を両方成功した場合だけ確定し、途中で例外が出たら双方を取り消したい。適切なLaravelの機能はどれですか？
答え： DB::transaction()内で両方の更新を行う
DB::transaction()はクロージャが正常終了すればcommitし、例外時はrollbackします。関連するDB更新を原子的に扱う基本手段です。
同じ在庫行を複数リクエストが同時更新し、在庫数を上書きし合う問題を抑えたい。トランザクション内で検討するものはどれですか？
答え： 対象行をlockForUpdate()で取得する
lockForUpdate()はトランザクション中に対象行へ排他ロックを要求し、競合更新を直列化しやすくします。トランザクションを短く保ち、デッドロック再試行も検討します。
Eloquentでレコードを物理削除せず、削除日時を記録して通常検索から除外し、必要なら復元したい。適切な機能はどれですか？
答え： SoftDeletesトレイトとdeleted_atカラム
SoftDeletesは削除時にdeleted_atを設定し、通常クエリから除外します。withTrashed()やonlyTrashed()で参照し、restore()で復元できます。
DBのis_adminが0/1で保存されているが、モデル利用側では常にbooleanとして扱いたい。適切なEloquent設定はどれですか？
答え： モデルのcastsでis_adminをbooleanへ指定する
Eloquentのattribute castingを使うと、取得・設定時の型変換をモデルへ集約できます。boolean、datetime、arrayなどを一貫した型で扱えます。
複数箇所で使う「公開中の記事だけ」というEloquent条件をモデルへ再利用可能にまとめたい。適切な仕組みはどれですか？
答え： ローカルクエリスコープ
ローカルスコープはモデル上に共通クエリ条件を定義し、Article::published()のように組み合わせて利用できます。
数百万件のレコードを、メモリへ一括で読み込まずに処理したい。処理中に更新が入っても読み飛ばしが起きにくくしたい。主キー順で処理する方法として適切なのはどれですか？
答え： chunkById()
chunkById()はIDを基準に小分けで取得します。大量処理のメモリ消費を抑え、offset方式で更新対象を処理するときの読み飛ばしを避けやすくします。
APIレスポンスでEloquentモデルの内部カラムを直接露出せず、項目名や関連データの表現を一元管理したい。適切な機能はどれですか？
答え： API Resource（JsonResource）
API ResourceはモデルやコレクションをJSON表現へ変換する責務を分離します。条件付き属性や、ロード済み関連だけの出力も整理できます。
更新頻度の高い大規模一覧APIで、深いページでもoffset増大を避けたい。安定した一意順序を用意できる場合の候補はどれですか？
答え： cursorPaginate()
cursor paginationは前回位置をカーソルで表し、offset走査を避けやすい方式です。一意で安定したorderByが必要で、任意ページ番号への直接移動などには向きません。
Controllerが支払処理のinterfaceへ依存し、本番とテストで実装を差し替えたい。interfaceと実装の対応を登録する場所として自然なのはどれですか？
答え： Service Providerでサービスコンテナへbindする
Service Providerでinterfaceを実装へbindすると、サービスコンテナが依存解決できます。環境やテストでbindingを差し替えやすくなります。
サービスコンテナから依存を自動解決させ、Controller内で直接newする処理を減らしたい。基本的な方法はどれですか？
答え： Controllerのコンストラクタやメソッドで依存型をtype-hintする
型宣言された依存をコンストラクタやControllerメソッドで受け取ると、コンテナが解決します。明示的な依存になり、mockやfakeへ差し替えやすくなります。
5分ごとの集計タスクが前回分の実行中に次回起動し、二重処理になるのを防ぎたい。Laravel Schedulerで適切な指定はどれですか？
答え： withoutOverlapping()
withoutOverlapping()はキャッシュロックを使って同じスケジュール処理の重複起動を抑えます。異常終了時のロック期限や複数サーバー構成も考慮します。
外部APIの一時障害でqueued jobが即時連続再試行し、相手をさらに圧迫している。ジョブ側で検討する設定はどれですか？
答え： 試行上限とbackoffを設定する
ジョブの試行回数とbackoffを設定すると、永続的な失敗を無限再試行せず、一時障害では間隔を空けられます。処理の冪等性も必要です。
最大試行回数を超えたqueued jobを調査し、原因修正後に再投入したい。基本的な運用はどれですか？
答え： failed jobを確認し、queue:retryで対象を再試行する
失敗ジョブの保存先と監視を構成し、例外・payload・試行履歴を確認します。原因を直して安全性を確認した後、対象IDをqueue:retryで再投入できます。
同じ業務通知をメールとDB保存へ送り、利用者設定によってチャネルを切り替えたい。Laravelで適切な仕組みはどれですか？
答え： Notificationクラスのvia()でチャネルを返す
Laravel Notificationsはvia()でmail、databaseなどの配信チャネルを選び、チャネルごとの表現を同じ通知クラスへ整理できます。必要ならqueue化できます。
Laravel HTTP Clientで外部APIを呼び出します。無期限に待たないようにし、一時的な通信失敗は一定間隔で再試行したい。候補となる組み合わせはどれですか？
答え： Http::timeout(...)->retry(...)->get(...)
timeoutで待機上限、retryで回数と間隔を制御できます。再試行対象、冪等性、総待機時間を要件に合わせて設計します。
非公開S3オブジェクトを、ログイン利用者へ10分間だけダウンロード許可したい。保存diskが対応している場合の候補はどれですか？
答え： Storage::disk(...)->temporaryUrl(...)
temporary URLは有効期限付き署名URLを生成し、ストレージ認証情報を渡さず限定アクセスを提供します。生成前にアプリ側の認可も確認します。
注文APIのFeatureテストで、実際のqueue workerを動かさず、正しいJobが投入されたことだけを検証したい。適切な方法はどれですか？
答え： Queue::fake()とQueue::assertPushed()を使う
Queue fakeは実配送を置き換え、指定Jobが期待した条件でdispatchされたかをassertできます。外部副作用を避けて振る舞いを検証できます。
複数サーバーから同じ請求処理が同時実行されるのを、共有キャッシュを使って短時間排他したい。検討するものはどれですか？
答え： Cache::lock()によるatomic lock
共有atomic lock対応ドライバーを使うCache::lock()は、複数プロセス・サーバー間の排他に利用できます。期限、所有権、例外時解放を設計します。
SanctumのPersonal Access Tokenへorders:read能力だけを付けた。API側の安全な認可方針はどれですか？
答え： token abilityを確認し、Policy等で対象注文への権限も確認する
token abilityはAPI操作範囲を限定しますが、対象リソースをその利用者が扱えるかという認可も別途必要です。最小権限のabilityとPolicy等を組み合わせます。
本番デプロイ中はメンテナンス画面を表示しつつ、動作確認担当だけ秘密URLでアクセスできるようにしたい。候補はどれですか？
答え： php artisan down --secret=...
down --secretはメンテナンスモードを有効化し、秘密パス経由でバイパスCookieを発行できます。秘密値の管理と、作業後のphp artisan upを運用手順へ含めます。
Laravel 12.xで注文をDBトランザクション内に保存し、別ワーカーの非同期ジョブへ注文IDを渡します。コミット前にジョブが動いて注文を見つけられない事故を防ぐ指定はどれですか？
答え： ジョブの投入にafterCommit()を指定する
afterCommit()はトランザクションの確定後まで投入を待ちます。ロールバック時には投入されません。固定秒数の遅延ではDB処理の長さを保証できず、投入先キューの変更でも確定順序は制御できません。
Laravel 12.xのRedisキューでretry_after=90秒、ワーカーの--timeout=120秒としています。90秒を超えたジョブが別ワーカーでも処理されました。この時間設定の修正として適切なのはどれですか？
答え： timeoutをretry_afterより十分短くする
再試行可能になる前に古い処理を終了させる必要があります。正常な所要時間を確保しつつ、timeoutをretry_afterより余裕を持って短く設定します。タイムアウトが動作する実行環境も必要で、障害時の再配信に備えた冪等性は別途確保します。
Laravel 12.xでOrder::where('status', 'new')->update(['status' => 'expired'])を実行しました。Observerのupdatedが各注文で呼ばれなかった理由はどれですか？
答え： 一括更新では各モデルを取得せず、個別イベントが発火しない
クエリによる一括更新は各モデルを取得してsaveする処理ではないため、個別のupdatedイベントは発火しません。Observerが必須ならモデル単位で保存するか、一括処理の副作用を明示的に実装します。大量データでは件数と実行コストも考慮します。
Laravel 12.xで/users/{user}/posts/{post}を暗黙のモデル結合で解決します。Userモデルにはposts()リレーションがあります。URLの{post}が{user}の投稿でない場合は、モデル結合の時点で拒否したい。ルートに追加する指定はどれですか？
答え： ルートにscopeBindings()を指定する
scopeBindings()により子モデルを親のリレーション内で検索します。親に属さない投稿なら結合できず404になります。ただし、URLのユーザー自身へのアクセス許可や投稿操作の権限まで保証するものではなく、Policyなどで別途認可します。
Laravel 12.xのHTTP Clientで通常のHttp::get($url)が500応答を返しました。これを例外処理へ渡したい場合、取得した$responseに呼ぶメソッドはどれですか？
答え： $response->throw()
通常のHTTP Client呼出しは4xxや5xxだけでは自動で例外を投げません。応答のthrow()で失敗ステータスを例外にできます。接続不能などの通信例外とは区別して扱い、失敗応答を成功データとして保存しないようにします。
Laravel 12.xのテストでHttp::fake()にURL別の応答を登録しています。登録漏れのURLへ実通信が出るのを防ぎ、未登録ならテストを失敗させる指定はどれですか？
答え： Http::preventStrayRequests()を呼ぶ
preventStrayRequests()を使うとfakeに一致しないLaravel HTTP Clientの通信は例外になります。URLのタイプミスや想定外の呼出しを検出できます。別のHTTPライブラリの通信まで遮断する機能ではありません。
Laravel 12.xで入力profileにはnameとemailだけを許可します。is_adminなど余分なキーがあれば検証エラーにする、profile自体のルールはどれですか？
答え： array:name,email
array:name,emailは配列のキーを許可リストに限定します。各キーの存在や値の妥当性は、profile.nameなどへのrequiredやemailルールで別に検証します。許可された項目の検証と、予期しない項目の拒否は異なる役割です。
Laravel 12.xとMySQLで商品のskuを照合キーにupsertしたのに、同じskuの行が増えます。skuに一意インデックスはありません。設計上まず必要な対応はどれですか？
答え： 重複を整理してskuに一意インデックスを作る
MySQLドライバーのupsertはDBの主キー・一意インデックスで衝突を判断し、第2引数の列指定だけでは一意性を作れません。既存重複を業務ルールに沿って解消したうえで制約を追加します。事前検索だけでは同時リクエストの競合を防げません。
Laravel 12.xのOctaneで、処理コンテキスト用のオブジェクトを使います。同じリクエストの中では1つを共有し、次のリクエストでは新しく作り直したい。長寿命のオブジェクトには保持しない前提です。コンテナへの登録方法はどれですか？
答え： scopedでコンテキストを登録する
scopedはリクエストやジョブのライフサイクル内で同じインスタンスを返し、次のライフサイクルで破棄されます。Octaneでsingletonにリクエスト固有の情報を保存すると、次の利用者に状態を持ち越すおそれがあります。staticなど別の長寿命参照に保持しないことも必要です。
Laravel 12.xで、同じ定期タスクを3台のサーバーが実行しています。各回の実行を1台だけに限定したい。3台とも、ロックに対応した同じキャッシュへ接続しています。スケジュール定義に追加する指定はどれですか？
答え： タスクにonOneServer()を追加する
onOneServer()は共有キャッシュのロックで、その実行回を担当するサーバーを決めます。全台で同じロックを参照できることが前提です。前回の処理が長引いて次回と重なる問題にはwithoutOverlappingも検討し、副作用の二重適用には冪等性を持たせます。
Laravel 12.xでメールのunique検証から更新対象ユーザーを除外します。Rule::unique(...)->ignore(...)へ渡す値として安全な方針はどれですか？
答え： サーバー側で確定した対象モデルを渡す
ignoreには利用者が自由に指定した値を直接渡しません。公式ドキュメントもSQLインジェクションの危険を警告しています。サーバーで対象を解決し、更新権限を確認したモデルなどを使います。一意性の最終保証にはDBの制約も必要です。
Laravel 12.xのUserでpasswordを$hiddenへ追加しました。これが防ぐものはどれですか？
答え： 通常の配列・JSON変換での属性露出
$hiddenはモデルを配列やJSONへ変換する際の出力制御です。DBのアクセス権、暗号化、ハッシュ化や$fillableによる代入制御とは別です。明示的に属性を読み取って独自応答へ入れる処理にも注意します。
Laravel 12.xでDB::transactionのデッドロック再試行を有効にしました。クロージャ内に外部決済APIの呼出しがある場合、注意点はどれですか？
答え： 再実行で決済が重複する可能性がある
再試行ではクロージャが再び実行される場合があります。DBのロールバックで外部APIの副作用は取り消せません。決済の冪等キーや、確定後の信頼できる通知方式などを設計し、重複と送信漏れの両方に対応します。
Laravel 12.xのStorage::putで書込み失敗を例外として扱いたい。対象diskの設定で検討する項目はどれですか？
答え： throwをtrueにする
diskのthrowをtrueにすると、書込み失敗は例外として通知されます。設定しない場合のfalse返却も含め、保存結果を確認せず成功応答を返してはいけません。公開範囲や保存先の変更は失敗処理の代わりではありません。
Laravel 12.xで署名URLの検証からpriceパラメータを除外し、そのpriceで請求額を決める案があります。問題はどれですか？
答え： 除外した金額が改ざんされても検知できない
署名検証から除外したクエリ値は、変更しても署名検証の対象になりません。請求額などの重要値を信頼せず、サーバーの価格や注文情報から決定します。署名、期限、本人確認・認可は役割が異なります。
Laravel 12.xで大量のモデルと関連データを小分けに取得したい。cursor()でリレーションをeager loadしようとした場合の見直しはどれですか？
答え： withを組み合わせたlazyなどを検討する
cursorは一度に少数のモデルを扱えますが、リレーションのeager loadingはできません。lazyなどでチャンク取得と関連取得を組み合わせ、件数とクエリ数を測ります。最後に全件を配列化するとメモリ削減を失います。
Laravel 12.xで、tenant_idの条件を付けた後に、statusの条件をwhereとorWhereで続けて追加しました。すると他テナントの行が結果に混じりました。修正方針はどれですか？
答え： OR条件をクロージャ内にまとめて括る
tenant_id AND (status=A OR status=B)のように、ORの範囲を括ります。括らない式は(tenant_id AND status=A) OR status=Bとなり、別テナントが条件を満たし得ます。クエリの検証に加えて認可や分離設計も確認します。
Laravel 12.xで、利用者が選んだソート列の名前をそのままorderByへ渡しています。値はバインドされるので、列名も検証なしで渡してよいでしょうか？
答え： 許可した列名へ対応付けてから渡す
SQLの列名は通常の値パラメータとしてバインドできません。画面の選択肢をサーバー側の許可リストへ対応付け、方向も制限します。値のプレースホルダーがあることを、任意のSQL構造を受け入れる理由にしてはいけません。
Laravel 12.xでconfig:cache後、サービスクラス内のenv()が.envの値を返さなくなりました。推奨される修正はどれですか？
答え： 設定へenvを集約し、configで読む
設定キャッシュ後は.envを読み込まないため、envはシステム環境変数などに限られます。envの参照を設定ファイルへ集約し、通常のコードはconfigから値を取ります。デプロイ時には正しい設定でキャッシュを生成します。
Laravel 12.xでwithCount('comments')の後にselect(['id', 'title'])を呼ぶと、件数属性が消えました。呼出し順の修正はどれですか？
答え： selectの後にwithCountを呼ぶ
明示的にselectを使う場合、withCountはその後に呼びます。後からselectで選択列を置き換えると、集計用に加えた列が消えるためです。件数取得のために関連レコードを変更したり全件読み込んだりする必要はありません。