やあ！JavaScriptの世界へようこそ。
コードを書いていると、「あれ、思った通りの結果にならないな？」と首をかしげる瞬間、必ずありますよね。その原因のトップランナーが、今日お話しする「イコール（等価演算子）」の話です。
JavaScriptには、`==` と `===` という二つの「等しい？」を尋ねる記号があります。一見、どちらも同じように見えますが、実はこれ、「お人好しな仲裁人」と「超厳格な門番」くらいの決定的な違いがあるんです。
一緒に紐解いていきましょう。
—
1. ゆるふわな「==（等価演算子）」の世界
まずは `==` から見てみましょう。これはJavaScriptの歴史が生んだ「お人好し」です。
この子は、比較するときに「あ、型が違うね？じゃあ、僕が気を利かせて形を合わせてあげるよ！」と、勝手に裏で変換（暗黙の型変換）をしてくれます。
お買い物の例え話
スーパーのレジを想像してください。
あなたは「500円玉（数字の500）」を持っています。店員さんは「”500″と書かれた値札（文字列の500）」を持っています。
- `500 == “500”` と聞くと、JavaScriptは「まあ、見た目はどっちも500だし、同じでいいよね！」と `true（正解！）` を返します。
でも、これがトラブルの元なんです。
// JavaScriptの「お人好し」な挙動
console.log(5 == “5”); // true（数字と文字列だけど、よしなに合わせる！）
console.log(0 == false); // true（0とfalseは同じ扱いになる不思議）
console.log(“” == 0); // true（空っぽの文字列と0も同じ扱い！）
見ての通り、かなり大雑把ですよね。「空っぽの入力フォーム」が「0」と同じ判定になってしまうなんて、バリデーション（入力チェック）で事故が起きる予感がしませんか？
—
2. 厳格な「===（厳密等価演算子）」の世界
次に、私たちが実務で絶対の信頼を置いている `===` です。こちらは「超厳格な門番」です。
この子は決して妥協しません。「型も値も、完全に一致していないと認めない！」という姿勢を貫きます。たとえ見た目が同じ「500」でも、それが「数字」なのか「文字」なのかを厳しくチェックします。
さっきのレジの例えだと…
- `500 === “500”` と聞くと、門番は「左は数字の500、右は文字列の500だね。中身は似てるけど、型が違うから別物だ！」と `false（間違い！）` を返します。
これこそが、私たちが求めている「予測可能性」です。
// 厳格な門番のチェック
console.log(5 === “5”); // false（型が違うので認めない！）
console.log(0 === false); // false（型が違うので認めない！）
console.log(“” === 0); // false（型が違うので認めない！）
// もちろん、型まで同じならちゃんと認めてくれます
console.log(5 === 5); // true
—
3. なぜ実務では「===」を使うべきなのか？
現場のエンジニアが `===` を好む理由は、たった一つ。「バグを生みにくいから」です。
`==` を使っていると、意図しないところでプログラムが気を利かせてしまい、後から「なんでここで動いてるの？」「なんでここでエラーが出ないの？」という、いわゆる「ハマりどころ」を作ってしまいます。
特に、Webサイトのフォーム送信や計算処理などで `0` や `false`、あるいは空文字 `””` を扱うとき、`==` だと境界条件の判定で思わぬミスを誘発します。
「迷ったら `===` を使う」。これは、世界中のプロが守っている鉄則であり、あなた自身のコードをバグから守る一番の防具です。
—
最後に：つまずいても大丈夫です！
JavaScriptの型変換は、最初は本当に魔法のように見えて、混乱するものです。「なぜ `true` になるの？」と悩みながら、一つひとつ確認していくその過程こそが、一流のエンジニアへの近道です。
もしコードを書いていて「あれ、動かないな？」と思ったら、まずはその比較が `==` になっていないか確認してみてください。それだけで解決する問題が、現場では山ほどあります。
これからも、一つずつ着実に理解を深めていきましょうね。あなたのコードライフを、心から応援しています！
コメント