JavaScriptのイコール3つ（===）とは？==との違いと推奨される使い分けを解説

JavaScriptのプログラミングを学んでいると、値を比較する際に「==」と「===」の2種類が存在することに気づくでしょう。

他のプログラミング言語ではイコール2つが一般的であることも多いため、なぜJavaScriptには3つのイコールが必要なのか、どちらを使うべきなのか迷ってしまう方も少なくありません。

プログラミングにおける比較は、プログラムのロジックを制御する極めて重要な要素です。

もし適切な演算子を選べていないと、意図しない型変換によってバグが発生し、その原因特定に多大な時間を費やすことにもなりかねません。

本記事では、JavaScriptにおける「イコール3つ（厳密等価演算子）」の重要性と、イコール2つとの決定的な違い、そして現代のエンジニアが守るべき推奨される使い分けについて詳しく解説します。

JavaScriptにおける「イコール3つ（===）」の正体

JavaScriptにおいて「===」は、一般的に厳密等価演算子（Strict Equality Operator）と呼ばれます。

この演算子の最大の特徴は、比較する2つの値の「データ型」と「値」の両方が一致しているかどうかをチェックする点にあります。

厳密等価演算子の仕組み

厳密等価演算子は、比較のプロセスにおいて型変換を一切行いません。

左辺と右辺を比較した際、まず「型が同じであるか」を確認し、型が異なる時点で即座に false を返します。

型が同じである場合にのみ、その中身である値を比較します。

以下のコードで、厳密等価演算子の基本的な動作を確認してみましょう。

// 数値どうしの比較
console.log(10 === 10); 

// 数値と文字列の比較
console.log(10 === "10"); 

// 真偽値の比較
console.log(true === 1);

true
false
false

この結果からわかる通り、数値の 10 と文字列の "10" は、人間から見れば同じ数値に見えますが、JavaScriptの厳密等価演算子においては「型が異なるため別物」として扱われます。

これが、後述するイコール2つとの決定的な差異です。

「イコール2つ（==）」との根本的な違い

一方で、イコール2つの「==」は等価演算子（Equality Operator）または「抽象等価演算子」と呼ばれます。

この演算子は、比較する2つの値の型が異なる場合、JavaScriptのエンジンが気を利かせて（あるいは余計なお世話として）自動的に型を変換してから比較を行います。

これを「暗黙の型変換（Type Coercion）」と呼びます。

暗黙の型変換の例

等価演算子を使用した場合、どのような結果になるかを見てみましょう。

// 数値と文字列の比較（自動的に型が変換される）
console.log(10 == "10");

// 数値と真偽値の比較
console.log(1 == true);

// null と undefined の比較
console.log(null == undefined);

true
true
true

驚くべきことに、これらはすべて true になります。

JavaScriptは「数値と文字列を比べようとしているなら、文字列を数値に変換してあげよう」といった判断を内部で行います。

一見すると便利な機能に思えますが、この挙動こそが予期せぬバグの温床となるのです。

型変換（Type Coercion）が引き起こす罠

なぜ、イコール2つ（==）の使用が危険視されるのでしょうか。

それは、JavaScriptの型変換ルールが複雑であり、開発者の直感に反する挙動をすることがあるからです。

混乱を招く比較例

特に有名な、直感に反する比較結果をいくつか紹介します。

// 空文字、数値の0、偽値の比較
console.log("" == 0);
console.log(0 == false);
console.log("" == false);

// 特殊なケース：配列と数値
console.log([] == 0);

true
true
true
true

これらはすべて true と評価されます。

空の文字列 "" や数値の 0 は、等価演算子の文脈では false 相当として扱われてしまいます。

しかし、実際のアプリケーション開発において、「空文字」と「数字の0」を同一視して良いケースは稀です。

例えば、ユーザーの入力フォームで「0点」と入力されたのか、「未入力（空文字）」なのかを区別したい場面を想像してください。

== を使ってしまうと、0と空文字を区別できず、プログラムが誤作動を起こす可能性があります。

なぜ「===」が強く推奨されるのか？

現代のJavaScript開発（ECMAScript 2015以降から現在に至るまで）においては、原則として「===」を使用することが業界のスタンダードとなっています。

その理由は主に3つあります。

1. 予測可能性の向上

=== を使う最大のメリットは、コードの挙動が予測しやすくなることです。

型が違うものは不一致（false）になるという単純なルールのおかげで、ソースコードを読んでいる時に「ここでは型変換が起きているのではないか？」と疑う必要がなくなります。

これにより、コードの可読性とメンテナンス性が劇的に向上します。

2. デバッグ効率の改善

バグが発生した際、== による暗黙の型変換が原因だと、その特定が非常に困難です。

変数の型が何であるかを常に意識しなければならないため、開発者の脳に余計な負荷がかかります。

最初から === を徹底していれば、型の不一致に起因するバグを未然に防ぐことができ、開発スピードの向上に繋がります。

3. パフォーマンス上の利点

理論上、厳密等価演算子のほうがわずかに高速です。

等価演算子（==）は、型が異なる場合に内部で型変換のアルゴリズムを走らせる必要がありますが、厳密等価演算子（===）はそのステップをスキップできるからです。

現代のJavaScriptエンジン（V8など）は非常に高度に最適化されているため、この差を体感することはまずありませんが、「型を意識したコード」はエンジンにとっても最適化しやすいコードであることは間違いありません。

「==」を使うべき唯一と言える例外ケース

基本的には === を使うべきですが、ごく稀に == を使うことが許容（あるいは推奨）されるケースがあります。

それは、null と undefined を同時に判定したい場合です。

JavaScriptでは、値が存在しないことを示す状態として null と undefined が存在します。

これらをまとめてチェックしたい場合、以下のように記述できます。

let value = null;

// value が null または undefined の場合に true となる
if (value == null) {
    console.log("値が null または undefined です");
}

この書き方をすると、以下のコードと同じ意味になります。

if (value === null || value === undefined) {
    // 処理
}

等価演算子を使うことで、コードを簡潔に書くことができます。

ただし、この手法を採用する場合は、チーム内で「null判定に限り == を許可する」といった合意が必要です。

もし迷うのであれば、常に === を使い、明示的に両方の値をチェックするほうが安全です。

基本的な比較ルールのまとめ表

ここで、改めて各演算子の比較結果を表にまとめてみましょう。

ここで注目すべきは、最後の NaN （Not-a-Number）です。

JavaScriptの仕様上、NaNは自分自身を含め、どの値とも等しくないと定義されています。

NaNの判定を行いたい場合は、演算子ではなく Number.isNaN() メソッドを使用する必要があります。

参照型（オブジェクト・配列）における注意点

これまでは数値や文字列といった「プリミティブ型」の比較を見てきましたが、オブジェクトや配列などの「参照型」を比較する際には、さらなる注意が必要です。

=== を使ったとしても、オブジェクトや配列の内容が同じであっても false になるケースがあります。

const arrayA = [1, 2, 3];
const arrayB = [1, 2, 3];
const arrayC = arrayA;

console.log(arrayA === arrayB); 
console.log(arrayA === arrayC);

false
true

なぜ arrayA === arrayB が false になるのでしょうか。

それは、JavaScriptにおける参照型の比較が「メモリ上のどこに保存されているか（参照先）」を比較しているからです。

arrayA と arrayB は、中身は同じですがメモリ上では別々の場所に保存されているため、別物と判断されます。

一方で、arrayC は arrayA の参照をそのままコピーしているため、同じ場所を指しており、結果は true となります。

このように、厳密等価演算子であっても「構造的な一致（中身が同じか）」までは判定できないことを覚えておきましょう。

Object.is() という選択肢

JavaScriptには === よりもさらに厳密な比較を行う Object.is() というメソッドも存在します。

2026年現在のモダンな開発において、極めて特殊なケースで使用されます。

=== と Object.is() の主な違いは以下の2点です。

1. NaNの比較: Object.is(NaN, NaN) は true になります。
2. +0 と -0 の比較: Object.is(+0, -0) は false になります（=== では true ）。

console.log(NaN === NaN);            // false
console.log(Object.is(NaN, NaN));    // true

console.log(+0 === -0);             // true
console.log(Object.is(+0, -0));     // false

通常のビジネスロジックで Object.is() を使う機会は少ないですが、数値の厳密な精度が求められる計算処理や、特定の数学的アルゴリズムを実装する際には、この違いが重要になることがあります。

実践的なコーディング規約とツールの活用

個人の注意に頼るだけでは、ついつい == を書いてしまうミスを防ぎきれません。

そこで、プロの開発現場では静的解析ツール（Linter）を活用して、機械的にチェックを行います。

最も普及しているツールである「ESLint」では、eqeqeq というルールが用意されています。

これを有効にすると、コード内で == や != が使われている箇所をエラーとして指摘してくれます。

ESLintの設定例（.eslintrc.json）

{
  "rules": {
    "eqeqeq": ["error", "always"]
  }
}

このように設定しておくことで、開発者は常に === を使うことを強制され、チーム全体でコードの品質を均一に保つことができます。

また、TypeScriptを導入している環境であれば、異なる型どうしの比較（例えば string と number の比較）をコンパイルエラーとして検出できるため、イコール3つの原則をより強固に守ることができます。

時代とともに変わる「当たり前」

JavaScriptは歴史の長い言語であり、初期の設計思想には「初心者でもエラーが出にくいように、型を自動で合わせる」という配慮（等価演算子）が含まれていました。

しかし、Webアプリケーションが大規模かつ複雑になるにつれ、その「配慮」が逆にバグを生む最大の原因となってしまいました。

2026年現在、フロントエンド開発でもバックエンド開発（Node.jsなど）でも、「== は避けるべき過去の遺物」という認識が一般的です。

新しくJavaScriptを学ぶ方は、たとえチュートリアルで == を見かけたとしても、自ら書くコードでは常に === を選択する習慣を身につけてください。

まとめ

JavaScriptにおけるイコール3つ（===）とイコール2つ（==）の違いについて解説してきました。

厳密等価演算子（===）は、「型」と「値」の両方を厳格にチェックするため、暗黙の型変換による予期せぬ挙動を防ぐことができます。

対して、等価演算子（==）は、便利な反面、意図しない型変換によって 0 == false が真になるなど、デバッグを困難にするリスクを抱えています。

最後に、JavaScriptの比較における黄金律を再確認しましょう。

• 原則として、すべての比較には「===」を使用する。
• 「==」を使用するのは、null と undefined を一括判定したい場合のみに限定する。
• ESLintなどのツールを使って、機械的に「===」を強制する。
• オブジェクトや配列の比較は、内容ではなく「参照先」を見ていることに注意する。

これらを徹底するだけで、あなたの書くJavaScriptコードの堅牢性は格段に向上します。

基本を疎かにせず、常に型を意識した明確なコーディングを心がけましょう。