console.logだらけのデバッグは、もう卒業した方がいい

console.logをあちこちに仕込んでは消し忘れ、また仕込む——というデバッグのやり方、そろそろ見直してもいい頃かもしれません。ブラウザの開発者ツールに標準で入っているブレークポイント機能を使うと、console.logを書くより速く、かつ多くの情報を得られる場面が意外とあります。

console.logデバッグの限界

消し忘れの心理的な話や、オブジェクトが[object Object]になってしまう対処法は別の記事で扱ったので、ここでは手法そのものの技術的な比較に絞ります。console.logによるデバッグには、いくつかの構造的な弱点があります。

1. 「今どの値を見たいか」を毎回コードに書く必要がある

function calculateTotal(items) {
  console.log('items:', items); // ①
  const subtotal = items.reduce((sum, item) => sum + item.price, 0);
  console.log('subtotal:', subtotal); // ②
  const tax = subtotal * 0.1;
  console.log('tax:', tax); // ③
  return subtotal + tax;
}

「次はtaxの計算後の値も見たい」と思うたびに、コードを編集してconsole.logを追加し、保存して、また実行する——というサイクルを繰り返すことになります。

2. 消し忘れると本番コードに残る

デバッグ用に仕込んだconsole.logをコミット前に消し忘れる、という経験に身に覚えのある方も多いのではないでしょうか。本番環境のブラウザのコンソールに、内部の変数名やデータ構造がそのまま露出してしまいます。

3. 非同期処理では出力順が直感と合わないことがある

console.log('1: 開始');
setTimeout(() => console.log('3: タイマー完了'), 0);
console.log('2: 終了（同期処理はここで終わる）');

実行すると、出力は1 → 2 → 3の順になります。setTimeoutの中身は「後回し」にされるため、コード上の見た目の順番と実際の実行順が一致しません。console.logをいくつも並べていると、この順序のズレに気づきにくく、原因調査がかえって遠回りになることがあります。

代替案: debugger文とブレークポイント

JavaScriptにはdebuggerという予約語があります。この行にコードの実行が到達すると、ブラウザの開発者ツール（DevTools）が開いていれば、そこで実行が一時停止します。

function calculateTotal(items) {
  const subtotal = items.reduce((sum, item) => sum + item.price, 0);
  debugger; // ← ここで実行が止まる
  const tax = subtotal * 0.1;
  return subtotal + tax;
}

一時停止すると、DevTools上でそのスコープにあるすべての変数（items、subtotalなど）の中身を、コードを1行も書き足さずに確認できます。ブラウザのDevTools（Sourcesパネル）からもコードにブレークポイントを直接クリックで設置できるので、慣れるとdebugger文すら書かずに済みます。

ブレークポイントがconsole.logより優れている点

• 一時停止した時点の全変数がまとめて見える（console.logは指定した変数しか見えない）
• ステップ実行（Step Over / Step Into / Step Out）で、1行ずつ処理の流れを目で追える
• コールスタックが見えるので、「この関数はどこから呼ばれたのか」が一目で分かる
• 条件付きブレークポイントが使える。「items.length > 10のときだけ止める」のように、if文を書き足すことなく条件を設定できる
• コードに書き込む形ではない（DevTools側でクリックして設置する）ため、消し忘れて本番に残る心配がない

それでもconsole.logが向いている場面

ブレークポイントが万能というわけではありません。以下のような場面ではconsole.logの方が素直です。

• ループの中で値が何回・どう変化していくかを、時系列でまとめて見たいとき（一時停止を繰り返すより、ログを流し読みする方が速い）
• 本番環境で、エラー発生時の状況をログとして記録として残したいとき（この場合はconsole.errorや専用のロギングサービスが適切です）

「毎回止めて1つずつ確認したい」ならブレークポイント、「大量の実行結果をまとめて眺めたい」ならconsole.log、と使い分けるのが実用的です。

まとめ

• console.logの逐次追加は、都度のコード編集・消し忘れ・非同期処理での順序の分かりにくさという弱点がある
• ブレークポイント（debugger文またはDevTools上でのクリック設置）を使うと、一時停止した時点の全変数・コールスタックをまとめて確認でき、条件付き停止もできる
• 時系列で値の推移を追いたい場面では、引き続きconsole.logが有効。両者は競合するものではなく使い分けるもの

---

未経験者向けの講座を運営しています

未経験から Next.js + Supabase + Claude Code で Webアプリを公開するまで を、全24セッションで体系化した教材です。Claude Code を学習パートナーにする CLAUDE.md と学習モード（learner / developer）の設計までセットで含みます。

• ▶ ライブデモ（インストール不要・無料で今すぐ見られます）→ https://trial-web-ayies128s-projects.vercel.app/?ref=qiita
• 教材完全版＋月5,500円のメンタリング（全24セッション＋チャット質問し放題）→ https://menta.work/plan/20251?ref=qiita
• 無料体験版（git clone して自分の手元で動かす・最初の数セッション分・⭐ Star もよろしくお願いします）→ https://github.com/ayies128/next-ai-camp-trial
• YouTube『AIエンジニア情報局』（AI×開発ニュースを1本5分でキャッチアップできる別運営チャンネル・無料）→ https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/?ref=qiita

※ Qiita読者の方には易しすぎる内容なので、初心者の知り合いへの紹介や社内研修の参考としてどうぞ。