本記事は社内勉強会（約50分＋質疑）向けに用意した補足資料を、Web上で順に読める記事として書き直したものです。

前回記事

【JS/TS社内勉強会第１回】こわくないJavaScript・やさしいTypeScript（全３回）

それでもバグは減らない

第１回で「JavaScript は味方」と述べたうえで、現場では別種の困りごとが起き続ける事実に向き合います。専門用語が増えますが、すべてを暗記する必要はありません。全体の流れと「なぜそう言えるか」の骨格をつかんでもらえれば十分です。

現場で起きる困りごと

• 変更後に壊れる：一箇所を直したら別の場所が動かなくなった

• デプロイ後に壊れる：ローカルでは動いていたが本番で動かない

• 原因が追えない：「なんか干渉しているのでは」という曖昧な会話

これらは周辺技術の知識不足だけでは説明しきれず、熟練者にも起きる種類の問題です。

「JavaScript のバグが多い」は本当か──データで見る

本番 JavaScript の未処理エラー（CatchJS, 2020） 上位 100 万ドメインの分析では：

• 調査対象サイトの 12% に 1 件以上の未処理エラー

• 未処理エラーの 85% が ReferenceError・TypeError・SyntaxError

TypeError と ReferenceError は、ざっくり「型・存在チェックの失敗」に近く、静的型付けで防げるクラスに重なります。

クライアントサイド JavaScript のバグ構造（Ocariza et al., 2013） 12 リポジトリ・317 件のバグレポートの分析では：

• バグの 65% が DOM 操作起因（周辺との接続）

• 高影響度に限ると 80% が DOM 関連

これは第1章の主張──「難しさの多くは周辺」──を裏付けます。一方で残りの約 35% は言語特性（型変換・スコープ・非同期など）に起因し、その多くが型まわりです。Tang et al. (2026) で「型関連エラー率 約 33%」などと計上される数値の文脈ともつながります。

動的型付けと静的型付けのバグ率（Ray et al., 2014/2017） 大規模な GitHub 研究では：

• 動的型付けは静的型付けよりわずかにバグが多い傾向

• 暗黙の型変換を許容する言語は、許容しない言語よりバグが多い傾向

• ただし効果量は小さく、開発者個人差・プロジェクト規模・チームといった要因の方が影響が大きい

留保: Ray et al. は再現研究（Berger et al., 2019）で GitHub 上の言語分類の精度問題が指摘されています。数値は参考程度にしつつ、「静的型付けがわずかに有利という方向性」は複数研究で重なる、という読み方が妥当です。

「バグが減らない」の構造

本番エラーの多くが TypeError / ReferenceError / SyntaxError（型・存在の失敗）
    ↓
言語特性起因のバグも一定割合で残る
    ↓
規模が大きくなるほど「隠れた前提」が増える
    ↓
人間の認知能力では追いきれなくなる（次章）

技術力の不足だけの話ではなく、規模と変更の積み重ねが認知的管理コストを押し上げる、という見方ができます。

後半で扱う「三つの沼」（予告）

後半の軸は次の三つです。

1. 動的型付け（この連載で最も掘る部分）

2. 関数型的な性質（第一級関数・クロージャ・高階関数など）

3. 歴史的な継ぎ足し構造（var, == / ===, this など）

中心となる問いは次の一文です。

「JavaScript はなぜ奥が深いのか。その難しさはどこから来るのか？」

JavaScript の歴史と「三つの沼」

誕生──約 10 日間のプロトタイプ

1995 年 5 月、Netscape の Brendan Eich は、ブラウザ向けスクリプト言語のプロトタイプをわずか約 10 日間で作成しました。Navigator 2.0 のスケジュールに間に合わせる必要があった、という切迫した背景があります。

名前の変遷はおおむね次のとおりです。

設計への影響源は、ざっくり次の三つに整理できます。

Douglas Crockford はこれを 「C の皮をかぶった Lisp」 と表現しています。見た目は C 系なのに、中身に Scheme や Self が強く入っている──これが「見た目と挙動のギャップ」の一因です。

驚かれやすい挙動の例

[] + []      // → ""（空文字列） 
[] + {}      // → "[object Object]" 
{} + []      // → 0 
typeof null  // → "object"（歴史的経緯で「null」ではない） 
NaN === NaN  // → false

これらは後方互換性のため、仕様として「直せない」側面を持ちます。typeof null や暗黙変換の詳細は次の記事で扱います。ここでは「こういう挙動が仕様として残っている」という事実だけ押さえてください。ブラウザの DevTools で実際に試すと、印象に残りやすいでしょう。

ECMAScript の標準化と「継ぎ足し」

ES3（1999）から ES5（2009）まで約 10 年仕様の大きな更新がなく、その間に Web は爆発的に成長し、jQuery などがブラウザ差を吸収しました。標準が止まっている間に現場が独自進化した歴史も、エコシステムの複雑さの一因です。

三つの沼（再掲）

• 沼① 動的型付け … 実行時に型が決まり、暗黙変換がある。小規模では柔軟、大規模では「今何型？」の負荷が増える。

• 沼② 関数型的性質 … map / filter / reduce、クロージャなど。命令型に慣れた人には馴染みが薄い。

• 沼③ 歴史的継ぎ足し … var、== と ===、this のバインディング、typeof null === "object" など。

次回記事

【JS/TS社内勉強会第３回】やさしい TypeScript（全３回）