Laravelでdump()とdd()を使う方法

Laravelでのデバッグでは、変数の中身や処理の流れを一時的に確認したい場面が頻繁にある。そのとき最も手軽に使われるのが dump() と dd()。どちらも値を可視化するための関数だが、役割は同じではない。dump() は「表示して処理を続ける」、dd() は「表示して処理を止める」という違いがあり、使い分けを誤るとデバッグ効率が落ちるだけでなく、開発中の画面停止や本番事故の原因にもなる。特にLaravelでは、Eloquentモデル、Collection、Request、Query Builder、APIレスポンスなど確認対象が多いため、どのタイミングで何を出すかを整理して使うと非常に強力になる。

dump()とdd()の基本的な違い

dump() は値を出力したあと、後続の処理をそのまま継続する。
dd() は「Dump and Die」の略で、値を出力した直後に処理を終了する。
この違いだけで使いどころが大きく変わる。

dump($user);
dump($request->all());

dd($user);
dd($request->all());

たとえば、複数の地点で変数の変化を見たいなら dump() が向いている。
逆に「この時点の値だけ見て、以降は進ませたくない」なら dd() が向いている。

まず覚えるべき使い分け

開発中の判断基準はかなり単純。
・処理を止めてよいなら dd()
・処理を止めたくないなら dump()
これを基準にすれば迷いにくい。

たとえば、フォーム送信直後の入力内容を見たいだけなら dd($request->all()) で十分。
一方で、ループの中や複数箇所で値の変化を追いたいなら dump() の方が適している。

Requestの中身を確認する場面

Laravelで最もよく使うのは、フォーム送信やAPIリクエストの中身確認。
「値が届いていない」「name属性がズレている」「JSON構造が違う」といった問題の切り分けに役立つ。

public function store(Request $request)
{
    dd($request->all());
}

これで送信された全データを確認できる。
特定キーだけ見たいなら次のように絞る。

public function store(Request $request)
{
    dd($request->input('email'));
}

エラーが発生しやすい条件としては、
・フロント側で name 属性が想定と違う
・JSON送信なのに form-data だと思っている
・ネスト配列の構造を勘違いしている
といった入力仕様のズレが多い。

Eloquentモデルを確認する場面

Eloquentモデルは、そのまま dump() や dd() に渡して確認できる。
ただし、モデルをそのまま出すと属性以外にも内部情報が多く表示されるため、必要に応じて配列化すると見やすい。

$user = User::find(1);

dd($user);

見づらい場合は次の形が有効。

$user = User::find(1);

dd($user?->toArray());

これで属性中心に確認できる。
発生しやすい問題としては、find() が null を返しているのに、そのままメソッドを呼んで別エラーになるケースがある。
そのため、?-> を使うか、先に dd($user) で null かどうかを見ると切り分けしやすい。

Collectionや配列の中身を見る場面

一覧データや検索結果を見たいときも dd() は有効。
Collectionは件数が多いと出力が長くなるため、必要な部分だけ切り出すと見やすい。

$users = User::where('status', 'active')->get();

dd($users);

件数や先頭だけ見るなら次のようにする。

$users = User::where('status', 'active')->get();

dump($users->count());
dd($users->take(3)->toArray());

発生しやすい問題は、
・件数が多すぎて画面が見づらくなる
・Collectionの中身が多重にネストされて読みにくい
・必要以上に大量データを出してしまい、ブラウザが重くなる
といったケース。

ループの中で使うときの注意点

ループの中で dd() を使うと、その1回目で必ず処理が止まる。
そのため、ループ全体の流れを見たい場合は dump() を使う方が適している。

foreach ($users as $user) {
    dump($user->email);
}

逆に、特定の1件目だけ見たいなら dd() でもよい。

foreach ($users as $user) {
    dd($user->email);
}

発生しやすい問題は、
・「ループが最後まで回っていない」と勘違いする
・1件しか表示されない理由が dd() による停止だと気づかない
というもの。
ループ内はまず dump() を選ぶ方が事故が少ない。

Query BuilderやSQL結果を確認する場面

クエリの結果がおかしいときは、実行結果だけでなく、クエリ内容そのものを確認したくなることがある。
まず結果確認なら次のようになる。

$posts = DB::table('posts')->where('status', 'public')->get();

dd($posts);

SQL自体を見たい場合は、Builderの状態を確認する方法もある。

$query = DB::table('posts')->where('status', 'public');

dd($query->toSql(), $query->getBindings());

これでSQL文とバインド値が確認できる。
発生しやすい問題は、
・where条件の値が想定外
・SQLは正しいが bindings が違う
・get() した結果だけ見ていて、そもそもクエリ条件が間違っている
といったケース。

Bladeテンプレート内で使う場面

Bladeの描画中でも dump() や dd() は使える。
ビューに渡された変数がおかしいときの確認に便利。

@php
dd($posts);
@endphp

ただし、Bladeで dd() を使うとレンダリング途中で画面全体が止まるため、ページ構造ごと確認したいときには不向き。
軽く確認したいときは dump() の方が扱いやすい。

@php
dump($posts);
@endphp

発生しやすい問題としては、
・Blade内で dd() を置いたままコミットしてしまう
・レイアウトの途中で停止し、原因箇所が分かりにくくなる
というものがある。

API開発で使うときの注意点

APIレスポンスを返す処理の中で dd() を使うと、JSONではなくHTMLベースのダンプ出力で処理が止まる。
そのため、フロントやPostmanから見ると「JSONが返るはずなのに崩れている」ように見える。

public function show($id)
{
    $user = User::find($id);

    dd($user);
}

これはデバッグとしては正しいが、APIの挙動確認中はレスポンス形式が崩れることを理解して使う必要がある。
JSONとして確認したい場合は、一時的に return response()->json(...) を使う方が見やすいこともある。

本番環境で使ってはいけない理由

dd() は処理を強制終了するため、本番で残っていると業務停止の原因になる。
dump() も画面に内部情報を出力するため、本番では情報漏えいにつながる可能性がある。
特に次のような情報は危険。
・ユーザー情報
・トークン
・SQL構造
・認証状態
・セッション内容

そのため、dump() と dd() は基本的に開発環境限定で使い、最終的には必ず削除する必要がある。

dump()やdd()を使った後に起こりやすいミス

開発では便利だが、置きっぱなしによる事故が非常に多い。
典型例は次の通り。
・dd() を消し忘れて画面が止まる
・AjaxやAPIでレスポンス形式が崩れる
・Bladeの途中で止まり、原因不明の空画面になる
・本番に誤って残してしまう
・大量データを dump() してブラウザが固まる

特に dd() は「原因調査のために一時的に入れたはずが、そのまま残る」ことが多いため注意が必要。

使いすぎを防ぐための考え方

dump() と dd() は非常に便利だが、毎回それだけに頼ると調査の幅が狭くなる。
使い分けの目安としては、
・一瞬で値を見たい → dump() / dd()
・継続的に追いたい → logger()
・SQLを詳しく見たい → QueryログやTelescope
・HTTP全体の流れを見たい → Telescopeやブラウザ開発者ツール
という形で分けると整理しやすい。

つまり、dump() と dd() は「最速で一点を見るための道具」であり、「恒久的な観測手段」ではないと考えると使いやすい。

まとめ

Laravelでの dump() と dd() は、開発中のデバッグで最も手軽に使える確認手段。
dump() は処理を続けながら値を見たいとき、dd() はそこで処理を止めて確認したいときに使う。
特にRequest、Eloquent、Collection、Query Builder、Bladeなど、確認対象に応じて使い方を変えるとデバッグ効率が上がる。
一方で、ループ内やAPI、本番環境では副作用も大きいため、
・止めるべきかどうか
・どこまで出すか
・使い終わった後に消すか
を意識して使うことが重要になる。