デバッグとは？

プログラムの不具合を見つけ、正しく動作するように修正する作業のことです。

Laravel には、この作業を効率化してくれる便利な機能がいくつも用意されています。今回は、実際の開発でよく使っているデバッグ方法を紹介します。

blade を使っているときのデバッグ方法（API 以外）

基本的には dd()という関数を使えば十分です。

dd は何をする関数か

処理をその場で止めて、変数の中身を確認できる関数です。

dd で処理を止めることでエラー箇所を特定しやすくなる

dd は処理を止めて変数の中身を出力するので、「エラーが起きている場所」をピンポイントで絞り込めます。

やみくもに関数内を修正するのではなく、具体的にどの行が原因なのかが分かるだけで、デバッグの効率はかなり変わってきます。

エラーの原因となっているコードの後に dd()を置いてもエラーが表示される場合は、「もっと前の処理に原因がある」と判断できます。

コントローラーで dd を使う

$users = User::all();
dd($users);

// 結果
// Illuminate\Database\Eloquent\Collection {#1039 ▼
//   #items: array:6 [▶]
// }

dump()との違い

dd()は処理を止めますが、止めたくない場合は dump()を使うと、処理を継続したまま変数の中身だけを出力できます。

$users = User::all();
dump($users);
// 処理は止まらずに続く

複数の変数を一度に確認したいときは、dd($a, $b, $c)のようにまとめて渡すこともできます。

views(blade)で dd を使う

blade ファイルの中でも同じように使えます。

{{-- blade ファイル --}}
{{ dd($users) }}

blade の場合、処理が止まるまでのコードは実行されているため、画面の表示が途中までしか読み込まれていない状態になります。

API のときのデバッグ方法

エラーの内容を確認する方法

初期設定のままであれば、以下のファイルにエラーの内容が記録されています。

storage/logs/laravel.log

最新のログは一番下に追記されていきます。

変数のデバッグ方法 ①：レスポンスとして返す

一番手軽なのは、確認したい変数をそのままレスポンスとして返してしまう方法です。

return 以降の処理は実行されないので、dd()と同じようにバグの発生箇所を絞り込めます。

$users = User::all();
return response()->json(compact('users'), 200);
// これ以降の処理は実行されない
$posts = Post::matigatterukoudo();

このコードなら、現時点での $users の中身をそのまま確認できます。

変数のデバッグ方法 ②：ログに出力する

処理を止めずに変数の中身を確認したい場合は、ログに出力する方法が便利です。

\Log::info($users);

こう書くと、ログファイルに変数の中身が出力されます。

storage/logs/laravel.log を確認すると、出力された内容を見ることができます。

覚えておくと便利な他の方法

• php artisan tinker：コマンドラインから対話的に Eloquent やロジックを試せるので、ちょっとした検証に便利です。
• Laravel Telescope：リクエストやクエリ、例外などをまとめて可視化してくれるデバッグ用パッケージです。開発環境に導入しておくと、ログを目視で追う手間がかなり減ります。

まとめ

以上、自分がよく使っている Laravel のデバッグ方法を紹介しました。

API の開発時は、Postman などの API クライアントを併用するとレスポンスの確認がしやすくなるのでおすすめです。