結論から書くと、Laravel でエラーが出たら、storage/logs のログで日時とメッセージを確かめ、スタックトレース（エラーに至るまでの処理の呼び出しの履歴）から vendor/ ではなく app/ などにある最初の行を探します。そこが自分たちのコードの該当箇所です。本番の画面にエラーの詳細を出す設定（APP_DEBUG=true）にはしません（公式の説明も本番では常に false としています）。ログで足りなければ、検証環境で再現します。対象は Laravel 10 から、2026年11月時点で最新の Laravel 13 までです（10 と 11 はセキュリティ修正の期限が過ぎています）。
この記事では、PHP の切り替え後に動かなくなったときの切り分けと PHP 自体のエラーログの出し方、定期処理やキューが止まったときの確認、PHP の Warning や Deprecated を直す優先順位は扱いません。PHP の切り替え後の切り分けは「レンタルサーバーで PHP のバージョンを切り替えたら動かなくなったときの切り分け」で説明しています。
ログの場所と設定を確かめる
ログは、標準では storage/logs に書かれます。書き方は config/logging.php の「チャンネル」で決まり、公式のログの説明によると主なものは次のとおりです。
- single: 1つのファイル（
laravel.log）に書き続ける - daily: 日ごとのファイル（
laravel-2026-11-04.logなど）に分け、古いものを消す - stack: 複数のチャンネルに同じ記録を書く
使っているチャンネルは default の行で分かります。env('変数名', '値') の形なら、.env（環境ごとの設定を書くファイル）に変数が無いときだけ2つ目の値が使われます。stack なら、中の channels が実際の書き先です。各チャンネルの level は記録する最低のレベル（重い順に emergency から debug までの8段階）です。
ログ1件の読み方
ログの1件は次のような形です（Laravel 12 で、画面のテンプレートが無いときの例。プロジェクトの場所は /path/to/project）。
[2026-11-04 10:15:30] production.ERROR: View [orders.index] not found. {"exception":"[object] (InvalidArgumentException(code: 0): View [orders.index] not found. at /path/to/project/vendor/laravel/framework/src/Illuminate/View/FileViewFinder.php:138)
[stacktrace]
（中略）
#3 /path/to/project/app/Http/Controllers/OrderController.php(25): view()- 日時:
config/app.phpのtimezoneに従います。UTCなら日本時間より9時間前です。 - production.ERROR: 前半は標準では環境の名前、後半がレベルです。本番で
localと出ていたら、.envのAPP_ENVを確かめます。 - メッセージと例外のクラス名: 何が起きたかと、例外（処理を止めて知らせるエラー）の種類です。
- at の後ろ: 例外が起きたファイルと行番号です。
4 が vendor/（Laravel 本体やライブラリ）の中なら、[stacktrace] を、エラーに最も近い #0 から下へ見て、プロジェクトの場所の直後が vendor/ ではない最初の行（app/ や routes/ など）を探します。例では #3 で、OrderController.php の25行目で表示しようとした画面のファイル（resources/views/orders/index.blade.php）が無い、と読めます。
tail -f storage/logs/laravel.log # 追記されるそばから表示（Ctrl+C で止める）
grep -n -E '\.(ERROR|CRITICAL|ALERT|EMERGENCY):' storage/logs/laravel.log | tail -n 20コマンドはプロジェクトのディレクトリで実行し、daily なら laravel.log を当日のファイル名に置き換えます。SSH（コマンドでサーバーを操作する仕組み）が使えなければ、FTP などでファイルをダウンロードして末尾から見ます。
社外の人や AI にログを渡すときは、必要な行だけを取り出し、利用者の入力や SQL の値を伏せます。
よく出るエラーの意味と最初の対処
| メッセージ | 意味 | 最初の対処 |
|---|---|---|
No application encryption key has been specified. |
APP_KEY（暗号化の鍵）が無い |
下の補足を先に読む |
… could not be opened in append mode: … Permission denied |
ログに書き込めない | storage の所有者と権限 |
SQLSTATE[HY000] [2002] …、[1045] Access denied … |
MySQL の 2002 はデータベースのサーバーにつながらない、1045 はユーザー名かパスワード（または接続元）が認められない | 2002 は .env の DB_HOST・DB_PORT とデータベースが動いているか、1045 は DB_USERNAME・DB_PASSWORD |
Class "…" not found |
PHP がクラスのファイルを見つけられない | 名前空間（クラスの住所にあたる記述）とファイル名の大文字・小文字、vendor（Composer で入れたライブラリ）のアップロード漏れ |
Target class […] does not exist. |
Laravel が組み立てようとしたクラスが無い | routes/ に書いたコントローラー名の誤り、ファイル冒頭の use 文の漏れ |
| 画面に「419」「Page Expired」 | CSRF トークン（フォームの送信元を確かめる値）が合わない | フォームに @csrf があるか、セッションが切れていないか |
APP_KEY の補足。 本番で以前は動いていたなら php artisan key:generate は実行せず、.env が消えたり差し替わったりしていないかを確かめて元に戻します。鍵を変えるとログイン中の利用者は全員ログアウトされ、前の鍵で暗号化したデータは復号できなくなるためです（暗号化の説明）。鍵を作るのは、新しく環境を作るときだけです。
権限の補足。 storage と bootstrap/cache は、Web サーバーのプロセスの所有者が書き込めるようにします（デプロイの説明）。777（誰でも書き込める状態）にはせず、レンタルサーバーでは契約しているサーバーのマニュアルで確認します。
ログが大きくなったとき、残っていないとき
single は1つのファイルに書き続けて大きくなるため、長く運用するなら daily にします。保持する日数は config/logging.php の daily の中の値で、項目の名前は公式の説明では Laravel 10〜12 が days、13 が max_files です（13 の説明）。値が env('LOG_DAILY_DAYS', …) の形なら .env の LOG_DAILY_DAYS で変えます。すでに大きい laravel.log は、必要な分を保存してから中身を空にします。
画面はエラーなのに記録が無いときは、次を疑います。
- 404 や 419（表の CSRF のエラー）など、一部のエラーは標準では記録されない（プログラムが
abort()で返したエラーも含む。説明） storage/logsに書き込めない（表の権限のエラー）- 書き先が
syslogなどになっている、またはlevelがcriticalなどに上げてある - Laravel が動く前に止まっている（
vendorが無いなど）。PHP や Web サーバーのエラーログを見る
h-system でできること
h-system では、他社や前任者が作った PHP・Laravel のシステムについて、エラーの原因の調査から不具合の修正、その後の保守までを開発者本人がお引き受けしています。ログを見ても原因が分からない段階での「調査だけ」のご依頼も可能です。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。