VS Codeには「JavaScript Debug Terminal」という機能が組み込まれています。通常のターミナルと見た目はほぼ同じですが、ここで起動したNode.jsプロセスには自動的にデバッガがアタッチされます。launch.jsonを書く必要がなく、ターミナルでコマンドを打つだけでデバッグが始まるのが最大の利点です。
Next.jsやNuxt、Express、素のNode.jsスクリプトなど、ターミナルから起動するものなら何でもそのままデバッグ対象になります。
Debug Terminalの開き方
VS Codeのターミナルパネル右上にある「＋」ボタンの横にドロップダウンがあります。そこから「JavaScript Debug Terminal」を選択するだけです。コマンドパレット（Ctrl+Shift+P / Cmd+Shift+P）からJavaScript Debug Terminalと入力しても開けます。
開いたターミナルは通常のターミナルと見分けがつきにくいですが、ターミナルタブの名前に「JavaScript Debug Terminal」と表示されています。ここでpnpm run devやnpm run dev、node index.jsなどを実行すれば、それだけでデバッグモードに入ります。
ブレークポイントの設定
エディタ上で行番号の左側をクリックすると、赤い丸が表示されます。これがブレークポイントです。プログラムの実行がその行に到達すると、処理が一時停止します。
ここで重要なのが、ブレークポイントは実行可能なコードがある行にしか設定できないという点です。
空行やコメント行、波括弧だけの行などに置くと「バインドされていないブレークポイント」となり、止まりません。変数の代入、関数の呼び出し、returnなど、実際にJavaScriptエンジンが処理する行に置いてください。
ブレークポイントで止まったらできること
処理が一時停止すると、VS Codeの左側に「変数」「ウォッチ」「コールスタック」といったパネルが表示されます。
変数パネルでは、そのスコープに存在するすべての変数の中身を確認できます。オブジェクトや配列であれば展開して中身を掘り下げられます。APIから返ってきたレスポンスの中身や、データベースクエリの結果をここで確認すると、console.logを仕込んで画面を行き来する手間がなくなります。
ウォッチには任意の式を登録しておけます。たとえばuser.emailやitems.lengthなどを登録しておけば、ブレークポイントで止まるたびに自動で評価されます。
コールスタックでは、今の関数がどこから呼ばれたかを遡れます。バグの原因がどの呼び出し元にあるかを調べるときに便利です。
さらに、「デバッグコンソール」タブではブレークポイントで止まっている状態のまま、任意のJavaScript式を実行できます。変数の値を書き換えて動作を試すといったことも可能です。
ステップ実行
ブレークポイントで止まった後、画面上部に表示されるツールバーで処理の進め方を制御できます。
続行（F5）は次のブレークポイントまで処理を進めます。ステップオーバー（F10）は現在の行を実行して次の行に進みます。関数呼び出しがあってもその中には入りません。ステップイン（F11）は関数の中に入って1行ずつ追いかけます。ステップアウト（Shift+F11）は今いる関数を抜けて呼び出し元に戻ります。
基本的にはF10で1行ずつ進めつつ、気になる関数があればF11で中に入り、深く入りすぎたらShift+F11で戻る、という流れです。
条件付きブレークポイント
ループの中や頻繁に呼ばれる関数にブレークポイントを置くと、何度も止まって作業になりません。そういう場合は条件付きブレークポイントが便利です。
行番号の左側を右クリックして「条件付きブレークポイントの追加」を選ぶと、式を入力できます。たとえばuser.id === 42と書けば、その条件を満たすときだけ止まります。
ハマりやすいポイント
通常のターミナルで起動してしまう：普通のターミナルで起動したプロセスにはデバッガがアタッチされません。必ず「JavaScript Debug Terminal」として開いたターミナルを使ってください。
空行にブレークポイントを置いている：前述の通り、実行可能なコードがない行ではブレークポイントはバインドされません。赤い丸がグレーの中抜きになっていたら、行を移動させてください。
HMRでセッションがずれる：ファイルを保存するとHot Module Replacementが走りますが、これによってソースマップが再生成され、ブレークポイントがずれることがあります。ブレークポイントが効かなくなったと感じたら、一度プロセスを止めて再起動するのが確実です。
Turbopackとの相性：Next.js 15以降はデフォルトでTurbopackが有効ですが、ソースマップの生成が不安定なことがあり、ブレークポイントが機能しない場合があります。next devから--turbopackを外すと安定することがあります。
console.logとの使い分け
console.logは手軽ですが、どの変数を見るか事前に決めてコードに書く必要があります。デバッガを使えば、止まったその場で好きな変数をいくらでも覗けます。「何が問題かわからない」段階ではデバッガ、「この値が怪しい」と当たりがついているならconsole.log、と使い分けると効率的です。
特にサーバーサイドの処理ではリクエストごとにコンテキストが変わるため、ブレークポイントで止めてその場のデータを確認できるのは大きな武器になります。
