まず「undefined」を一言でいうと
undefined は、
「“値がまだ決まっていない”ことを表すための特別な値」 です。
もう少し噛み砕くと、
「変数は“ある”んだけど、中に“ちゃんとした値”がまだ入っていない」
「この場所に“どんな値を置くか”が、まだ決まっていない」
ときに登場する“状態”を表す値が undefined だと思ってください。
ここが重要です。undefined は「エラーのメッセージ」ではなく、「JavaScript が自動的に入れてくる、特殊な値」。
“変数やプロパティが存在はしているが、中身が未決定” というサインです。
undefined が勝手に現れる典型パターン
変数を「宣言しただけ」で、値を入れていないとき
いちばん基本的なパターンです。
let x;
console.log(x); // 何が出る？
このとき、x は「宣言された」だけで、
まだ何も代入されていません。
JavaScript は、
「宣言されたけれど値がない変数」に自動的に undefined を入れます。
実際の出力はこうなります。
undefined
つまり、
let x;→ 変数 x を作る（宣言）- でもまだ値は決めていない → 中身は
undefined
という状態です。
関数が「何も return しない」とき
次の関数を見てください。
function hello() {
console.log("こんにちは");
}
const result = hello();
console.log(result); // ？
hello() は return を書いていません。
このとき、関数の呼び出し結果には、
自動的に undefined が入ります。
出力はこうなります。
こんにちは
undefined
つまり、
console.log("こんにちは");が実行されるhello()自体は何も返さない → 戻り値はundefined- その
undefinedがresultに入る
という流れです。
オブジェクトのプロパティが存在しないとき
オブジェクトの話も少しだけ。
const user = { name: "Taro" };
console.log(user.name); // "Taro"
console.log(user.age); // ？
user.age というプロパティは定義していません。
この場合も、JavaScript は
「そんなプロパティはない → undefined」
と解釈します。
実際の出力はこうなります。
undefined
ここが重要です。
「変数は宣言されているが値がない」「関数が何も返していない」「存在しないプロパティを読もうとした」
といった場面で、JavaScript は“とりあえず” undefined を返す。undefined は、そういう「まだ／そもそも、値がない」という状態の合図です。
undefined と「変数が存在しない」を混同しないこと
「宣言したけど undefined」と、「そもそも存在しない」は別物
次の 2 つは似ているようで、意味がまったく違います。
let x;
console.log(x); // undefined（宣言済み・未代入）
console.log(y); // ReferenceError: y is not defined（変数自体が存在しない）
x は「宣言したけど値を入れていない」ので undefined。y は「宣言すらしていない」ので、エラー になります。
ここがとても大事です。
undefined
→ 値として存在する（＝「中身がない」という意味の“値”）
→ 「変数はある」ことの証拠でもある- ReferenceError（～ is not defined）
→ そもそもその名前の変数はどこにもない
undefined が出ているときは「変数はある」。
エラーになっているときは「変数そのものがない」。
ここが重要です。
「undefined は“エラーの一歩手前”。
”宣言し忘れ” ではなく“代入し忘れ・プロパティ忘れ”を疑うサイン。
ReferenceError が出たら、“その変数自体の宣言を忘れている” と考える。
undefined と null の違いを感覚でつかむ
ざっくりしたイメージの対比
感覚的にこう覚えておくと分かりやすいです。
undefined
→ 「まだ何も決めてない／用意してない」
→ JavaScript 側が自動的に入れてくることが多いnull
→ 「何もないことを、あえて自分で決めた」
→ 開発者が“意図的に”代入することが多い
たとえば、「現在ログインしているユーザー」を表す変数を考えます。
let currentUser = null; // 最初は「誰もログインしてない」と自分で決めている
// ログインしたら…
currentUser = { name: "Taro" };
ここで let currentUser; とだけ書いてしまうと、undefined になり、
「単に初期化し忘れているのか？」
「まだログインチェックをしていないのか？」
が分かりにくくなります。
null を使うことで、
「今は意図的に“誰もいない”状態」 を表現できます。
どっちを使うべきかの指針
初心者向けにはこうまとめておきます。
- 何も代入していない変数
→ 自動でundefined（バグ臭・初期化忘れの匂い） - 「値がない」という状態を明示したい
→ 自分でnullを代入する
ここが重要です。undefined は「準備不足かもしれない」「何かミスっているかもしれない」匂いがする値。null は「ここは空でいい」と設計として決めた値。
“どちらを意図しているのか” を常に自分に問いかけて使い分けることが重要です。
undefined が原因で起こりやすいバグと、その見分け方
計算に使って NaN になる
undefined を数値計算に巻き込むと、NaN になります。
let price;
let total = price + 100;
console.log(total); // NaN
price は undefined なので、
undefined + 100 → NaN（数として成り立たない）
という流れです。
もしここで price が 0 だと思い込んでいたら、
バグに気づきにくいですよね。
文字列に結合して「undefined」が画面に出てしまう
let name;
console.log("こんにちは、" + name + "さん");
// "こんにちは、undefinedさん"
ユーザーに「undefinedさん」と表示されるのは、
かなり恥ずかしいバグです。
これは「name を代入し忘れている」のに、undefined のまま使ってしまったことが原因です。
対処の基本：使う前に「undefined かもしれない」と疑う
こういうバグを減らすためには、
「その変数は、この行に来るまでに必ず値が入っているか？」
を常に意識することです。
たとえば：
let price;
// ここで price に代入するつもりだったが、書き忘れた…
console.log(price + 100); // NaN
このコードを読むときは、
「price はどこで初期化されている？」
「もしここまでに代入されていなかったら undefined では？」
と自分に問いかける習慣をつけていくと、undefined によるバグをだんだん自分で見つけられるようになります。
ここが重要です。
「undefined のまま使っていないか？」は、
JavaScript のデバッグで最初に疑うべきポイントのひとつ。
“この変数には必ず値が入っている” と言い切れるか、自分に確認してから計算・表示に使う癖を持つこと。
undefined を自分から「わざわざ代入」すべきか？
結論：基本的には自分から undefined を代入しない
技術的には、こう書くこともできます。
let value = undefined;
ですが、実務的には あまりおすすめされません。
- 単に「未初期化」の状態なら、
let value;で十分 - 「意図的に何もない」なら、
nullを使ったほうが意図が伝わる
からです。
「undefined を自分で入れる」というコードは、
“本当にそれは null ではダメなのか？”
と疑われがちです。
例外的に使われることはあるが、初心者は null 優先でいい
ライブラリの実装や、型システムとの兼ね合いなど、
特殊な事情で「undefined をあえて返す」設計も存在します。
ですが、JavaScript 初心者としては、
- ライブラリの挙動として undefined を「受け取る」ことはあっても
- 自分から進んで undefined を「返す／代入する」のは避ける
くらいの感覚でいて大丈夫です。
ここが重要です。
「意図した“空”は null、意図していない“空”が undefined」
という線引きを自分の中に持っておくと、
わざわざ undefined を書きたくなる場面はほとんどなくなるはずです。
typeof undefined と Boolean での扱い
typeof undefined の結果
typeof で undefined を調べると、こうなります。
console.log(typeof undefined); // "undefined"
これは分かりやすいですね。null の "object" とは違って、undefined はちゃんと "undefined" と返ってきます。
if 文での挙動（falsy）
undefined は Boolean 文脈では falsy（false とみなされる）です。
let value;
if (value) {
console.log("truthy");
} else {
console.log("falsy"); // こちらが実行される
}
Boolean(undefined) とすると false になります。
console.log(Boolean(undefined)); // false
「値があるかどうか」をザックリ見るときに、if (value) と書くと、
undefinednull0""（空文字）NaNfalse
などを全部「値なし」の側にまとめてしまいます。
これが便利なことも、
逆に危険なこともあります。
ここが重要です。
「undefined は falsy」だけれど、
“0 や空文字と同列で扱って本当にいいのか？”
を常に考える必要がある。
“ながら if (value)” で雑に判定しすぎると、意図しない分類をしてしまうことがある。
初心者向け：undefined で本当に押さえてほしいこと
最後に、Undefined についての核心だけをコンパクトに整理します。
undefined は、「変数はあるが、まだ値が決まっていない」状態を表す特別な値。
次のようなときに自動的に undefined になる。
- 変数を宣言しただけで代入していない
- 関数が何も return していない
- 存在しないオブジェクトのプロパティを読んだ
undefined と「変数がそもそも存在しない（ReferenceError）」は別物。
前者は「箱はあるが中身がない」、後者は「箱そのものがない」。
undefined を計算や文字列結合に使うと、NaN や「undefined」という変な結果になりがちで、よくあるバグの原因になる。
「意図した空」は null を使う。undefined は“代入し忘れ・用意し忘れ”の匂いがするので、自分から進んで代入することは基本的にしない。
ここが重要です。
変数や戻り値を見るたびに、「これは本当に値が入っているか？ undefined のままじゃないか？」と自分に問いかける癖をつけること。
その感覚が身につくと、“なんか NaN になる”“なんか undefined が出る” というモヤモヤしたバグを、自分の目で追い詰められるようになります。
もしよければ、次のような小さな練習をしてみてください。
let a;
function f() {}
const obj = { x: 1 };
console.log(a); // ?
console.log(f()); // ?
console.log(obj.y); // ?
それぞれがなぜ undefined になるのかを、一つずつ言葉にして説明してみてください。
そうすると、「JavaScript がどんなときに undefined を返すのか」が、かなりくっきり見えてくるはずです。