JavaScriptを学び始めると、避けて通れないのが「これ、本当に数値なの？」というデータ型の判定ですよね。特にフォームの入力値チェックや、APIから返ってきたデータを扱うとき、私たちは頻繁に「数値かどうか」を確かめたくなります。
そんなときによく見かけるのが、`isNaN()` という関数。
「よし、これ使えばバッチリだな！」と思って使い始めたはいいものの、実はここ、JavaScriptの歴史的なバグと闇が少しだけ隠れている、初心者が一番最初に踏みがちな「罠」のポイントなんです。
今回は、伝統的な `isNaN()` と、モダンな `Number.isNaN()` の違いについて、お買い物のレジでのやり取りに例えながら、優しく紐解いていきたいと思います。大丈夫ですよ、一緒にスッキリ解決していきましょう！
—
1. 昔ながらの `isNaN()` は「おせっかいな店員さん」
まずは、昔からJavaScriptにある `isNaN()` （is Not a Number＝「数値じゃないの？」の略）のお話から。
この `isNaN()`、実はすごくおせっかいな性格をしています。あなたが渡したものが何であれ、「とりあえず、無理やり数値に変換してから判定する」という特技を持っているんです。
これをお買い物に例えてみましょう。
あなたはレジに「リンゴの形をしたおもちゃ（文字）」を置きました。
- 普通の感覚： 「いや、これおもちゃ（文字）だから、食べ物（数値）じゃないでしょ！」
- `isNaN()` 店員： 「ええっと、とりあえずこのおもちゃを分解して、重さを量って……よし、これなら数値として扱えるから、セーフ（数値だよ）！」
……ちょっと混乱しちゃいますよね。具体的にコードで見てみましょう。
// 数字の「123」はもちろん数値です
console.log(isNaN(123)); // 出力: false （＝数値じゃない？ いいえ、数値です）
// 数字の形をした文字列も、おせっかい変換されます
console.log(isNaN(“123”)); // 出力: false （＝数値に化けるので「数値だ」と判定される）
// 全く関係ない文字はどうなるでしょう？
console.log(isNaN(“こんにちは”)); // 出力: true （＝数値じゃない！）
最後の `”こんにちは”` は、どう頑張っても数値に変換できないので `true`（数値じゃないよ）になります。ここまではいいんです。問題は、「数字の形をした文字列（`”123″`）」を渡したときに、勝手に数値扱いしてしまうこと。
フォームに入力されたデータは、基本的にすべて「文字列（String型）」としてJavaScriptに届きます。そのため、`isNaN(“123”)` が `false`（＝数値だよ）と返ってくるのは一見便利に見えますが、もっと複雑なデータ（例えば `undefined` や、空の配列など）を渡したときに、おせっかいが裏目に出てしまうのです。
—
2. 現代のヒーロー `Number.isNaN()` は「厳格な警備員さん」
そんなおせっかいな `isNaN()` の挙動に、世の開発者たちが「ちょっと待て、危なすぎるだろ！」と気づいて、ES2015（ES6）というモダンな時代にやってきたのが `Number.isNaN()` です。
こちらの `Number.isNaN()` は、一切の妥協をしません。おせっかいな変換は一切せず、「今、目の前にあるそのデータは、正真正銘の『数値型』であり、かつ、それが `NaN` というエラー値であるか？」を厳格にチェックします。
お買い物に例えるなら、こんな感じです。
- `Number.isNaN()` 警備員： 「私は見た目をごまかしません。今あなたが差し出したのは『文字列』ですね？ 型が違うので、私の判定では『数値ではありません』とハッキリお伝えします」
百聞は一見に如かず、先ほどと同じようなデータを `Number.isNaN()` に渡してみましょう。
// 本物の数値の NaN（計算エラーなどの結果生まれる特殊な値）
console.log(Number.isNaN(NaN)); // 出力: true （＝正真正銘、数値のNaNです）
// 文字列の「123」を渡してみる
console.log(Number.isNaN(“123”)); // 出力: false （＝型が違うので、エラーとしては扱わない）
// 「こんにちは」という文字を渡してみる
console.log(Number.isNaN(“こんにちは”)); // 出力: false
// おおっ！ここがポイントです！
最後の `”こんにちは”` に注目してください。`isNaN()` だと `true` になっていたのに、`Number.isNaN()` では `false` になっています。
「えっ、『こんにちは』は数値じゃないんだから、`true` にならなきゃダメなんじゃないの？」って思いませんでしたか？
ここが一番つまずきやすいところです。
- `isNaN(“こんにちは”)` は、「これ、数値に変換できる？ できないよね？ だから『数値ではない（Not a Number）』で合ってるよ！」という意味で `true` を返しています。
- `Number.isNaN(“こんにちは”)` は、「そもそもお前、数値型ですらない（文字列だよね？）から、私が判定する土俵にすら立ってないよ！」という意味で `false` を返しているのです。
つまり、`Number.isNaN()` は、「入力されたデータがすでに『数値型』であること」が大前提なのです。
—
3. 実務ではどう使い分けるべき？
現場のWeb開発で私たちが本当にやりたいことは大体決まっています。
それは、「ユーザーがフォームに入力した値が、ちゃんとした数字になっているかチェックしたい」というケースです。
ここで、それぞれの特徴を整理しておきましょう。
1. `isNaN()` を使う場合
- 渡された値が「数値として解釈できるかどうか」をざっくり調べたいとき。
- ただし、予期せぬデータ（`undefined` や `null`、配列など）を渡すと、JavaScriptが勝手に気を利かせておかしな挙動をすることがあるので注意が必要です。
- （※現代のモダンな開発では、あまり積極的に使われなくなっています）
2. `Number.isNaN()` を使う場合
- 「計算結果が `NaN`（計算不能）になってしまっていないか」を厳密にチェックしたいとき。
- プログラムの中で、 `0 / 0` のような数学的エラーが起きていないか監視するのに最適です。
💡 実務で安心・安全に数値チェックをするためのテクニック
じゃあ、フォームの入力値（文字列）を安全にチェックしたいときはどう書けばいいの？と不安になりますよね。
現場のプロたちは、よくこんな風に工夫してコードを書きます。
// ユーザーがフォームに入力したと想定する値
const userInput = “12345”;
// 1. まず自分でしっかりと「数値」に変換する（Number() や
コメント