JavaScript | 基礎構文:変数・定数 – 再代入の可否とは

JavaScript
スポンサーリンク

「再代入の可否」を一言でいうと

「再代入の可否(さいだいにゅうの かひ)」は、
「一度値を入れた変数に、あとから“別の値を入れ直していいかどうか」
というルールのことです。

もう少しくだいて言うと、

  • 一度入れた値を「上書きしてもいい変数」か
  • 一度入れた値を「二度と変えちゃいけない変数」か

この違いを表す言葉が、「再代入の可否」です。

JavaScript だと特に、

  • let:再代入「できる」
  • const:再代入「できない」

この対比が、再代入の可否そのものになっています。


「代入」と「再代入」をちゃんと分けてイメージする

代入とは:「最初に値を入れること」

まずは「代入(たいにゅう)」から。

変数を作って、最初の値を入れることを「代入」と言います。

let score = 50;    // これが「代入」
JavaScript

ここでは、

  • score という名前の箱を作る(変数宣言)
  • その箱に 50 を入れる(代入)

という 2 ステップが同時に起きています。

宣言と代入を分けると、こう書けます。

let score;      // 宣言(まだ中身はない)
score = 50;     // 代入(最初の値を入れる)
JavaScript

再代入とは:「あとから別の値を入れ直すこと」

一度値を入れたあとに、
もう一度 = を使って別の値を入れ直すことを「再代入」と言います。

let score = 50;  // 代入(最初の値)
score = 80;      // 再代入(上書き)
JavaScript

score という同じ箱に、
5080 と中身を入れ替えています。

「再」が付く=「2 回目以降の代入」だと思ってください。

ここが重要です。
「代入」は最初の一回、「再代入」は 2 回目以降の上書き。
JavaScript の変数宣言は、「再代入を許すかどうか」をキーワード(let / const)で決めている。


let は「再代入できる」変数

具体例:カウンターのような「変わる値」

let で宣言した変数は、あとから何度でも値を上書きできます。

let count = 0;          // 代入
console.log(count);     // 0

count = count + 1;      // 再代入(0 → 1)
console.log(count);     // 1

count = 10;             // 再代入(1 → 10)
console.log(count);     // 10
JavaScript

count という同じ名前の箱に、
時間とともに違う値が入っています。

ゲームのスコア
現在ページ番号
何回クリックされたか

みたいに、「時間とともに変化するもの」を扱うときは、
「再代入できる」let が自然です。

宣言だけして、あとから代入 → さらに再代入

let name;          // 宣言だけ(まだ undefined)
name = "太郎";     // 代入(最初の値)
name = "花子";     // 再代入(上書き)
JavaScript

このように、let 変数は、

  • 一度目の =:代入
  • 二度目以降の =:再代入

という形で、中身を何度でも変えられます。


const は「再代入できない」変数

一度値を入れたら、二度目の = は禁止

const で宣言した変数は、
一度入れた値をあとから別の値に変えることはできません。

const pi = 3.14;   // 代入(最初で最後)
console.log(pi);   // 3.14

pi = 3.1415;       // ← ここでエラー(再代入不可)
JavaScript

「再代入の可否」で言うと、

  • let:再代入「可」(できる)
  • const:再代入「不可」(できない)

となります。

「この値を途中で変えたくない」「変えたらバグ」というような値は、
const にしておくと安全です。

宣言と同時に代入が必須

const は、宣言だけして値を入れない、ということはできません。

const taxRate;   // エラー:初期値が必要
taxRate = 0.1;
JavaScript

必ずこう書きます。

const taxRate = 0.1;  // OK
JavaScript

const で変数を作る=その場で値を決めて、以後変えない」
という約束です。

ここが重要です。
const には「代入」はできるが、「再代入」はできない。
“最初の一回だけ OK、その後は一切ダメ” というルールになっている。


「オブジェクトや配列は const でも中身が変えられる」ややこしい話

ここが、初心者が一番混乱しやすいポイントなので、丁寧にいきます。

const なのに変更できてしまう例

const user = { name: "Taro", age: 20 };

user.age = 21;          // これは通る
console.log(user.age);  // 21

// でもこれはダメ
user = { name: "Hanako", age: 30 }; // エラー(再代入)
JavaScript

「え、const なのに age を変えられてるじゃん」と感じますよね。

ここで区別したいのは、

  • 変数 user に入っている「オブジェクトの場所(参照)」
  • そのオブジェクトの中身(プロパティ)

const が禁止しているのは、
「変数が指している“場所”を別の場所に変えること(=再代入)」 です。

オブジェクトの内部(user.age)を変えることそのものは、
const のルールでは止めていません。

配列も同じです。

const numbers = [1, 2, 3];

numbers.push(4);       // 中身を変える → OK
console.log(numbers);  // [1, 2, 3, 4]

numbers = [10, 20];    // 別の配列を代入 → エラー(再代入)
JavaScript

再代入の対象は「変数そのもの」

整理すると、

  • user = {...} をもう一度やる
    → 変数 user に「別のオブジェクト」を代入しようとしている → 再代入 → const では禁止
  • user.age = 21 をやる
    → 変数 user は同じオブジェクトを指したまま、そのオブジェクトの中身だけ変えている
    → 変数への再代入ではないので、const のルール外

という違いです。

ここが重要です。
再代入の可否は「変数に対して別の値(参照)を入れ直せるかどうか」の話。
オブジェクトや配列の「中身を書き換えられるかどうか」は、別の次元の話だと切り分けて考えると混乱が減ります。


なぜ「再代入できるかどうか」をわざわざ区別するのか

「変わらないはずのもの」が変わるとバグになるから

例えば、税率(消費税)を考えてみます。

const TAX_RATE = 0.1;
JavaScript

この値は、プログラムの途中で勝手に変わると困りますよね。

もし let で書いていた場合:

let TAX_RATE = 0.1;

// どこか遠くのファイルでうっかり…
TAX_RATE = 0.2; // 本当はやってはいけない変更
JavaScript

気づかないうちに誰かが上書きしてしまうと、
全体の計算結果が狂います。

const にしておけば:

const TAX_RATE = 0.1;

TAX_RATE = 0.2; // ここでエラーになってくれる
JavaScript

「ここは変えちゃいけない場所だよ」とコンピュータが教えてくれる ので、
早い段階でミスに気づけます。

「変わるデータ」と「変わらないデータ」を見分けやすくする

コードを読むとき、
すべての変数について「これは途中で変わるのか?」を毎回考えるのはつらいです。

  • const:途中で変わらない
  • let:あとで変わる可能性がある

という区別がついていれば、

「この値はずっと同じ」「この値は変化するかも」

を、キーワードを見るだけでパッと判断できる ようになります。

ここが重要です。
**再代入の可否を明示することで、

  • バグを防ぐ(変えちゃいけない値を変えようとするとエラー)
  • コードを読むときの負担を減らす(変わる/変わらないが一目で分かる)
    という二つの効果が得られる。
    だから、letconst に「再代入できる/できない」という差がついている。**

実務的な指針:「まず const、必要なら let」にする理由

「全部 let」で書いても動くけど…

次のようなコードを想像してみます。

let price = 1200;
let taxRate = 0.1;
let total = price + price * taxRate;
console.log(total);
JavaScript

これでも動きます。
ですが、「どれが変わる可能性がある値なのか」が分かりません。

本当は、

  • price:あとで変えるかもしれない(商品を選ぶたびに変わる)
  • taxRate:基本的に固定(途中で勝手に変わるとバグ)

といった違いがあるかもしれません。

再代入が必要なものだけ let にする

同じ処理を、再代入の可否を意識して書くと、こうなります。

let price = 1200;         // 商品が変われば変化する
const TAX_RATE = 0.1;     // 途中で変わらない前提

const total = price + price * TAX_RATE;
console.log(total);
JavaScript

こうしておくと、

  • TAX_RATE は「絶対に途中で変えたくない値」
  • total も「計算した結果として固定でよい値」

だと読み取れます。

さらに、もし誰かが TAX_RATE = 0.2; のように書いたら、
その場でエラー になってくれるので、
「再代入してはいけないところに再代入しようとしている」ことにすぐ気づけます。

ここが重要です。
実務的には、「まず const を使う。どうしても値を変えたいところだけ let にする」という方針にすると、
「再代入してよいもの/いけないもの」が自然と分かりやすいコードになります。


まとめ:再代入の可否とは何か(初心者目線で言い直す)

最後に、シンプルにまとめます。

「再代入の可否」とは、
「その変数に、あとからもう一度 = で別の値を入れ直していいかどうか」 のこと。

JavaScript では、

  • let:再代入「できる」変数(何度でも上書きOK)
  • const:再代入「できない」変数(一度決めたら変えちゃダメ)

という違いになっている。

再代入できるかどうかを区別するのは、

  • 「変えちゃいけない値」を誤って変えるバグを防ぐため
  • 「変わるもの」と「変わらないもの」をコード上で見分けやすくするため

オブジェクトや配列を const にした場合も、
変数そのものへの再代入はできないが、
「中身のプロパティ/要素の書き換え」は別問題なので、そこは切り離して考える。

ここが重要です。
「この値は途中で変える必要があるか?」を自分に問いかけて、

  • 変えるなら let
  • 変えないなら const
    と判断する習慣をつけると、「再代入の可否」が自然と設計に組み込まれ、コードの質が一段上がります。

もしよければ、

  • カウンター(クリック数など)
  • 変わらない税率や定数
  • 計算結果の一時変数

を自分でいくつか考えてみて、「これは let」「これは const」と分類してみてください。
その練習をするだけで、「どんな値が再代入すべきで、どんな値は再代入すべきでないか」の感覚がかなり明確になってきます。

タイトルとURLをコピーしました