やあ。今日も元気にコードを書いてるかい？
リポジトリのレビューをしていて、たまにこういうコードに遭遇して冷や汗をかくことがあるんだよね。
const total = ‘5’ + 3; // “53” になるはずが… あれ？
const result = ‘5’ – 3; // こっちは 2 になる
「なんでプラスだと文字列がくっつくのに、マイナスだと引き算になるんだよ！」って、昔の俺も頭を抱えたもんだ。JavaScriptが「動的型付け言語」として裏で勝手に気を利かせてくれる（Type Coercion / 暗黙の型変換）のはありがたい反面、仕様をハッキリ理解していないと、プロダクション環境でとんでもないバグを爆誕させる温床になる。
今回は、中級からもう一段階上のシニアへステップアップしようとしている君に向けて、算術演算における暗黙の型変換の闇と光、そして実務で絶対にハマらないための知見を徹底的に解説していこう。
—
1. 結論：加算（`+`）と減算（`-`）の決定的な違い
JavaScriptのエンジン（V8など）が式を評価する時、演算子によって「どちらの型に合わせるか」のプライオリティが全く異なる。ここを勘違いしていると痛い目をみる。
- 加算（`+`）演算子: 文字列優先（String Concatenation）。オペランドのどちらかに文字列（String）が含まれている場合、JavaScriptは「お、これは文字列の結合だな？」と判断し、もう片方も強制的に文字列に変換してしまう。
- 減算（`-`）・乗算（“）・除算（`/`）演算子: 数値優先（Numeric Conversion）。これらは算術演算（数学の計算）専用の演算子だから、文字列だろうがなんだろうが、容赦なく数値（Number）へと変換を試みる。
百聞は一見にしかず。まずはブラウザのコンソールで叩けるような、基本の挙動を確認してみよう。
// — 1. 加算 (+) の世界（文字列優先の罠） —
console.log(5 + 3); // 8 (数値同士は普通に足し算)
console.log(‘5’ + 3); // “53” (数値の 3 が文字列 “3” に化けて連結される)
console.log(5 + ‘3’); // “53” (こっちも当然文字列連結)
console.log(true + 1); // 2 (true は数値に変換されると 1 だから 1 + 1 = 2)
console.log(null + 1); // 1 (null は数値に変換されると 0)
console.log(undefined + 1); // NaN (undefined は数値化すると NaN になり、NaN との計算はすべて NaN)
// — 2. 減算 (-) の世界（数値優先の正義） —
console.log(5 – 3); // 2 (普通に引き算)
console.log(‘5’ – 3); // 2 (文字列 “5” が数値 5 に変換されて引き算される！)
console.log(‘5’ – ‘3’); // 2 (両方とも数値に変換される)
console.log(‘apple’ – 3); // NaN (数値化できない文字列を引こうとするとこうなる)
どうだろう？ `+` だけがあまりにも自由奔放というか、空気を読んで「文字列結合」を優先してしまうせいで、バグの温床になりやすいんだ。
—
2. ブラウザの裏側で何が起きているのか？（ECMAScript仕様の深掘り）
「なんでそんな仕様になってるんだよ」と文句を言いたくなるかもしれないが、これには歴史的な背景がある。JavaScriptはもともと「Webページにちょっとした動きをつけるための簡単なスクリプト言語」として生まれた。その名残で、ユーザーがフォームに入力した値（基本はすべて文字列）を画面に表示したり連結したりするユースケースが多すぎたため、`+` は文字列結合の役割を兼務させられたんだ。
ECMAScriptの仕様書（ToPrimitive抽象操作など）を紐解くと、JavaScriptエンジンは演算子に遭遇したとき、以下のステップで暗黙の型変換を行っている。
1. プリミティブ値への変換: オブジェクト（配列やプレーンオブジェクトなど）がオペランドに含まれている場合、まず `valueOf()` や `toString()` を呼び出してプリミティブ値（文字列や数値）に変換する。
2. 型の評価:
- `+` 演算子の場合：どちらか一方が `String` なら、もう一方を強制的に `String` に変換して連結。
- `-`, “, `/` 演算子の場合：両方のオペランドを `Number` に変換（`ToNumber` 抽象操作）してから演算を実行。
特に厄介なのが、配列やオブジェクトが絡んできたときだ。
// 配列と数値の足し算
console.log([1] + 2); // “12”
「なんでやねん！」って思うよね。裏側ではこう処理されている。
1. `[1]` はオブジェクト（配列）なので、`ToPrimitive` が走る。
2. 配列の `toString()` が呼ばれ、`[1]` は文字列 `”1″` に変換される。
3. 文字列 `”1″` と数値 `2` の `+` 演算になるため、結果として `”12″`（文字列結合）になる。
シニアとしてチームメンバーに伝えたいのは、「暗黙の型変換のルールを暗記するな、暗黙の型変換をコード上で発生させるな」ということだ。
—
3. 現場で使える！バグを防ぐベストプラクティス
実務の現場では、APIレスポンスの数値が `”150″` のような文字列で返ってきたり、URLのクエリパラメータがすべて文字列として取得できたりと、型が揺らぐシチュエーションがゴロゴロ転がっている。
ここで、安全かつ明示的に型をコントロールするための実践的なテクニックをいくつか紹介しよう。
① 入力値は「最初に」明示的にパースする（Type Casting）
フォームの入力値やAPIからの生データを受け取ったら、計算やロジックに持ち込む前に、あらかじめ明示的に型を変換（キャスト）しておくのが鉄則だ。
// ❌ 危険な書き方（暗黙の型変換に頼る）
function calculateTotal(price, quantity) {
return price quantity; // priceが文字列でも動くっちゃ動くが…
}
// ⭕️ 推奨される書き方（入り口で型を担保する）
function calculateTotal(price, quantity) {
// Number() や 単位演算子 (+) を使って明示的に数値化する
const numericPrice = Number(price);
const numericQuantity = Number(quantity);
// 万が一パースに失敗した場合（NaN）のガード節も入れると完璧
if (Number.isNaN(numericPrice) || Number.isNaN(numericQuantity)) {
throw new Error(‘無効な値が入力されています’);
}
return numericPrice numericQuantity;
}
② テンプレートリテラルを積極的に使う
文字列の中に変数を埋め込むときは、古臭い `+` による文字列連結を封印し、ES6のテンプレートリテラル（Template Literals）を使おう。これだけで `+` 演算子のオーバーロード（文字列結合と算術加算の兼務）による混乱を完全に回避できる。
const count = 5;
// ❌ 事故りやすい書き方
const message1 = ‘現在のアイテム数は ‘ + count + ‘ 個です’;
// ⭕️ 安全でモダンな書き方（可読性も段違い）
const message2 = `現在のアイテム数は ${count} 個です`;
③ 厳密等価演算子（`===`）を常識にする
今回は算術演算がテーマだけど、条件分岐での暗黙の型変換（`==` と `===` の違い）も同じ文脈で語られることが多い。実務では `==`（緩い等価）は原則禁止、常に `===`（厳密等価）を使うのがモダンフロントエンドのスタンダードだ。型が違うなら違うと判定させるのが、バグを早期発見する近道になる。
—
まとめ
JavaScriptの暗黙の型変換、特に算術演算における `+` と `-` の挙動の違いは、言語の歴史が生んだいわば「仕様のバグのような仕様」だ。
- 加算（`+`）は文字列が好き（文字列優先）
- 減算（`-`）などは数字が好き（数値優先）
この原則さえ頭に入っていれば、コンソールで奇怪な結果に直面したときも「あぁ、裏で今こういう型変換が走ったな」と秒で原因を特定できるようになるはずだ。
魔法のような暗黙の挙動に頼るのではなく、「型は自分でコントロールする」という意識を持つこと。それが、君の書くコードをワンランク上の、信頼性の高いものにしてくれる。さあ、今日もクリーンなコードを書いていこうぜ！
コメント