Day22 前半のゴール
ここまでで、かなりいろいろ書けるようになってきたはずです。
でも、こう感じる瞬間が増えてきていない？
「動かない。どこが悪いのか分からない。」
「エラーが出てるけど、何を言われているのか分からない。」
Day22 は、ここを突破する回です。
テーマは デバッグ（バグを見つけて直すこと）。
前半では特に、
console.log を使って「中身を見る」感覚
ブラウザの開発者ツールを開いてエラーを確認する習慣
ここをしっかり身につけます。
デバッグとは何か
「勘で直さない」ための技術
バグが出たとき、やりがちなのが「なんとなく怪しいところをいじる」ことです。
これは、たまたま当たれば直るけれど、外れたら泥沼になります。
デバッグの本質は、
今、プログラムが「どう動いているか」を観察する
観察した事実から「どこがおかしいか」を絞り込む
という、かなり冷静で地味な作業です。
そのための一番の武器が console.log と エラー表示 です。
console.log の基本
「今、この値は何になっている？」を可視化する
JavaScript には、実行中の値をコンソールに出力するための関数があります。
それが console.log です。
const x = 10;
console.log(x);
これを実行すると、ブラウザの「コンソール」に 10 と表示されます。
この「コンソール」は、開発者ツールの一部です。
開発者ツールの開き方（ざっくり）
ブラウザによって少し違いますが、だいたい次のどれかです。
F12 キーを押す
右クリック → 検証
メニューから「その他のツール」→「デベロッパーツール」
開いたら「Console」タブを探してください。
そこに console.log の出力やエラーメッセージが表示されます。
例題：思った値になっていないときの console.log
うまく足し算できないコード
次のコードを見てください。
<input id="aInput" type="text">
<input id="bInput" type="text">
<button id="calcButton">計算</button>
<p id="result"></p>
<script>
const aInput = document.getElementById("aInput");
const bInput = document.getElementById("bInput");
const calcButton = document.getElementById("calcButton");
const result = document.getElementById("result");
calcButton.addEventListener("click", () => {
const a = aInput.value;
const b = bInput.value;
const sum = a + b;
result.textContent = `結果：${sum}`;
});
</script>
見た目は正しそうですが、
a に 2、b に 3 を入れると「結果：23」と表示されます。
「2 + 3 なのに、なんで 23？」という状態です。
console.log で「中身」を見る
ここで、いきなり修正しようとしないで、
まず「今、a と b は何になっているのか」を確認します。
calcButton.addEventListener("click", () => {
const a = aInput.value;
const b = bInput.value;
console.log("a の値:", a, "型:", typeof a);
console.log("b の値:", b, "型:", typeof b);
const sum = a + b;
console.log("sum の値:", sum, "型:", typeof sum);
result.textContent = `結果：${sum}`;
});
コンソールを見ると、例えばこう出ます。
a の値: 2 型: string
b の値: 3 型: string
sum の値: 23 型: string
ここで分かるのは、
a も b も「文字列」になっている
文字列同士の + は「足し算」ではなく「くっつける」
という事実です。
だから、修正すべきは「Number に変換してから足す」ことだと分かります。
const a = Number(aInput.value);
const b = Number(bInput.value);
このように、console.log は「何が起きているか」を見せてくれるライトです。
暗闇の中で手探りするのではなく、ライトをつけてから動くイメージです。
console.log を入れる場所のコツ
「怪しいところの直前」に置く
console.log は、どこにでも書けますが、
効果的なのは「怪しい処理の直前」です。
例えば、
if 文の条件が思った通りに動いていない
配列の中身がおかしい気がする
関数に渡している引数が正しいか不安
こういうときは、その直前に console.log を入れます。
console.log("チェック前の値:", value);
if (value > 10) {
// ...
}
console.log("配列の中身:", items);
items.forEach(/* ... */);
console.log("関数に渡す引数:", name, age);
doSomething(name, age);
「ここが怪しい」と思ったら、
まず console.log で「事実」を見る。
これがデバッグの基本の動きです。
エラー確認の基本
エラーは「敵」ではなく「ヒント」
JavaScript でエラーが起きると、
画面に何も出ないことも多いですが、
コンソールにはちゃんとメッセージが出ています。
例えば、こんなエラーがあります。
const button = document.getElementById("myButton");
button.addEventListener("click", () => {
console.log("clicked");
});
HTML に id=”myButton” の要素が存在しないと、
コンソールにこう出ます。
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
最初は「英語だし怖い」と感じるかもしれませんが、
よく見ると重要な情報が詰まっています。
Uncaught TypeError
null のプロパティ addEventListener を読もうとした
つまり、
button が null になっている
null に対して addEventListener を呼ぼうとしている
ということです。
エラーの「どこで起きたか」を見る
エラーメッセージには、たいてい「行番号」も出ています。
script.js:10
のような表示があれば、
script.js の 10 行目付近でエラーが起きている、という意味です。
そこを開いて、
「この変数、本当に中身が入っている？」
「この関数、本当に定義されている？」
といった視点で console.log を仕込んでいきます。
例題：null エラーをデバッグする
動かないコード
<button id="runButton">実行</button>
<script>
const button = document.getElementByID("runButton");
button.addEventListener("click", () => {
console.log("実行しました");
});
</script>
このコードは、ボタンを押しても何も起きません。
コンソールを見ると、こんなエラーが出ているはずです。
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
console.log で確認する
まずは button の中身を見てみます。
const button = document.getElementByID("runButton");
console.log("button の中身:", button);
コンソールには button の中身: null と出るでしょう。
ここで「そもそも取得に失敗している」と分かります。
よく見ると、メソッド名が getElementByID になっています。
正しくは getElementById（d が小文字）です。
このように、
エラーを見る
怪しい変数を console.log で確認する
スペルミスなどの「事実」に気づく
という流れで、冷静にバグを潰していきます。
console.log とエラー確認をセットで使う
「まずコンソールを見る」を習慣にする
何かがおかしいと感じたら、
いきなりコードをいじる前に、必ずこうします。
コンソールタブを開く
エラーメッセージが出ていないか見る
必要なら console.log を仕込んで値を確認する
これを習慣にすると、「勘で直す」時間が激減します。
逆に、コンソールを見ないまま直そうとすると、
ほぼ確実に遠回りします。
Day22 前半のまとめ
前半で押さえたのは、デバッグの一番大事な基礎です。
console.log で「今の値」「今の状態」を見る
怪しいところの直前に console.log を置く
エラーメッセージは「ヒント」として読む
null や undefined のエラーは「そもそも取得できていない」サイン
何かおかしいときは、まずコンソールを開く習慣をつける
後半では、
もう少し複雑な例（if 文の分岐、配列操作、関数分割後のコードなど）を題材に、
「どうやってバグを絞り込んでいくか」を一緒に追いかけていきます。