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

動的型付けと認知の限界

型の「二軸」：いつ検査するか／どこまで暗黙変換するか

軸①：静的 vs 動的（いつ型を検査するか）

軸②：暗黙変換の多さ（強い／弱い）

「強い型付け／弱い型付け」は文脈で意味が揺れる用語です。実務的には 暗黙の型変換をどれだけ行うか と捉えるほうが明確だと思います。

四象限のイメージ（概念図）

JavaScript は動的かつ暗黙変換が多い側に位置しやすいです。Python は動的でも "5" + 3 は TypeError になり、黙って変換しない。JavaScript は黙って変換し、バグが静かに入りやすい、という対比が重要です。

TypeScript の位置づけ TypeScript は主に「いつ検査するか」を静的側へ寄せる存在です。暗黙変換そのものを実行時に消すわけではなく、コンパイル時に型チェックを足すのです。

const x: any = "5";
console.log(x - 3);  // コンパイルは通りうる → 実行時は 2

実行時の挙動は依然として JavaScript です。

動的型付けでは見えないもの

let x = "こんにちは";
x = 42;
x = true;

柔軟ですが、読んだだけでは変数の型が確定しないことも意味します。

暗黙の型変換（coercion）

"5" + 3    // → "53"（文字列結合が優先）
"5" - 3    // → 2（減算は数値へ）

+ は文字列結合と数値加算の両方を担い、一方が文字列なら結合が優先されます。- は数値演算と判断され、両辺を数値にしようとします。

typeof null === "object" 初期実装の値表現（型タグと NULL ポインタの関係）に由来する歴史的バグであり、既存コードへの依存のため修正できない、という説明が定説です。

[] + [] などの例は、Gary Bernhardt のライトニングトーク「WAT」（2012）でも取り上げられ、広く知られるようになりました。

小規模では破綻しにくい理由

• 全体が頭に入る

• 実行してすぐ確認できる

• 変更の影響範囲が限定的

規模が大きくなると──　認知負荷

1956 年、George Miller は短期記憶のチャンクが 7±2 程度であると報告しました。2001 年、Nelson Cowan は厳密な条件下では約 4 チャンクとする再検討を示しました。いずれにせよ、そんなに多くの情報を人間は保持できないといわれています。

しかしプログラミングでは例えば次のような情報を同時に保持しがちです。

• この変数は今何型か

• 引数に何を渡せるか

• 戻り値は null になりうるか

• 変更はどこに波及するか

動的型付けではこれらがコード上に明示されにくく、暗黙知が増え、やがてワーキングメモリの上限を超えやすくなります。

小規模     → 暗黙知が少なく管理しやすい
中規模     → 記憶に頼ると漏れが出始める
大規模     → 個人の認知では追いきれない／チーム共有も難しい

バグと認知をつなぐ

• 本番エラーの多くが型・存在まわり

• 言語差より規模とプロセスの影響も大きい

• それでも人間側の管理能力には上限がある

「もっと注意する」だけでは、構造的限界には届かない場合があります。求められるのは注意量の増大ではなく、認知に頼りすぎない仕組みです。

TypeScript の登場と効果

TypeScript とは

JavaScript に静的型付けを後付けした言語です。2012 年 10 月、Microsoft がオープンソースで公開。リードアーキテクトは Anders Hejlsberg（Turbo Pascal、Delphi、C# の文脈で知られる人物）。

動機は、要するに「Web の基盤になった JavaScript が、大規模な複数人開発にはそのままではスケールしにくい」という認識です。JavaScript を捨てるのではなく、型・ツーリング・リファクタリング可能性を足す、という賭けでした。

Before / After の最小例

JavaScript

function greet(user) {
  return "こんにちは、" + user.name + "さん！";
}
greet({ age: 25 });  // → "こんにちは、undefinedさん！"（エラーにならない）
greet(null);         // → 実行時エラー

TypeScript

interface User {
  name: string;
  age: number;
}
​
function greet(user: User): string {
  return "こんにちは、" + user.name + "さん！";
}
// greet({ age: 25 });  // コンパイルエラー：name がない
// greet(null);         // コンパイルエラー：null は User ではない

実行前に（エディタやコンパイルで）不整合を指摘できるのが違いです。

研究による裏付け

Gao et al. (2017), ICSE 公開 JS プロジェクトから修正済みバグ 400 件を集め、型注釈を足したうえで TypeScript が検出できたかを調べました。

• TypeScript 2.0 で公開バグの 約 15% を検出

• --strictNullChecks で検出可能なバグが 大幅に増加（1.8 → 2.0 の比較として 58% 増など）

対象は「テストやレビューを通過してしまったバグ」であり、開発中に潰したバグを含めれば実効はもっと大きい、という推定も示されています。さらに、IDE 補完やリファクタリング支援といった間接効果は数値に含まれていません。

Tang et al. (2026), MSR 先行研究と比較し、型関連エラー率が約 33% から 12.4% に低下した、と報告されています。

TypeScript の四つの武器

1. 暗黙知の明文化 … interface などで「何がありうるか」をコード上に残す

2. 実行前の検出 … 暗黙変換に依存した脆弱なパターンを早めに炙り出す

3. IDE 補完・リファクタリング … 型が構造的な手がかりになる

4. 型推論 … すべてに注釈を書かなくてよい

Stack Overflow Developer Survey 2025 では、TypeScript の Admired 率（使っている人のうち「今後も使いたい」）が 72.4% と高水準です。

普及の指標（参考）

2017 年頃 12% だった採用率が、2025 年にはプロ開発者で約 48.8% まで伸びた、という整理もあります。

限界（過大評価を防ぐ）

• 型消去（type erasure） … コンパイル後の JS には型情報は残らない。実行時の保証ではない^type-erasure。

• 外部から入るデータ … API レスポンスやユーザー入力は、ランタイムでは別途バリデーション（Zod, io-ts など）が必要。

• 型システムの学習コスト … 高度な機能はあるが、日常は基本的な注釈で十分な恩恵を得られることが多い。

すぐ試す：TypeScript Playground

インストール不要で、TypeScript Playground にブラウザでアクセスすれば、左に TS、右にコンパイル結果が表示され、型エラーもその場で確認できます。

まとめ──タイトルに戻る

前半の結論

「JavaScript が難しい」体験の正体の多くは、周辺技術（DOM・HTTP・フレームワークなど）との接続が難しいという体験である。言語本体は味方であり、周辺を扱うための道具である。

後半の結論

バグが減らない要因の一面は、人間の認知能力に構造的な限界があることである。TypeScript は暗黙知を明文化し、実行前に不整合を検出する「仕組み」を足す。

タイトルへの回帰

• 「こわくない」 … 難しさの正体がわかれば、恐怖は小さくなる。

• 「やさしい」 … 「もっと注意しろ」ではなく、仕組みで支えてくれる。

TypeScript は「熟練者だけのもの」ではなく、暗黙知がまだ少ない初学者こそ、型という案内板の恩恵が大きい、という見方もできます。エラーメッセージに教えてもらいながら学ぶほうが、仕様を推測しながら書くより効率が良い場面は多いです。

今日から試せる一歩

1. TypeScript Playground で "5" + 3 と "5" - 3 を試す

2. 型注釈を付けて、意図的にエラーを出してみる

3. 「次は TypeScript で書いてみようかな」と思ってみる

「書けるようになる」こと自体がこの記事のゴールではありません。「触ってみようかな」と思ってもらえたら、元になった勉強会の意図には沿えています。