型システム（静的型付け vs 動的型付け）

型は何を守ってくれる？

「型」とは、値の種類と、その値に許される操作のセットです。number 同士は足し算・引き算ができ、string は連結や長さ取得ができる、という具合に。型システムは、

• 不正な操作を弾く（数値を関数として呼ぶ、存在しないプロパティを読む など）
• 意図を記録する（この引数は文字列を受け取る、という契約がコードに残る）
• 最適化やツール支援の土台になる（補完・リファクタリング・高速化）

ここで重要なのが「いつ検査するか」。これが静的／動的を分ける軸です。

静的型付け vs 動的型付け（いつ検査するか）

• 静的型付け: **実行する前（コンパイル時）**に型を検査する。型が合わなければそもそも動かせない。例: Java, TypeScript, Go, Rust, C#
• 動的型付け: 実行している最中に、値を触ったその瞬間に型を確かめる。間違っていればその行でエラー。例: Python, JavaScript, Ruby, PHP

同じ「文字列を数値で割る」バグでも、見つかるタイミングがまるで違います。

// TypeScript（静的）: 実行する前にエディタ／コンパイラが赤線
function half(n: number) {
  return n / 2;
}
half("10"); // ❌ コンパイルエラー: string は number に渡せない

# Python（動的）: 動かしてその行に到達して初めて落ちる
def half(n):
    return n / 2

half("10")  # ❌ 実行時に TypeError（その関数が呼ばれるまで気づけない）

強い型付け vs 弱い型付け（暗黙変換を許すか）

ここでよくある誤解。「静的＝強い、動的＝弱い」ではありません。“いつ検査するか”（静的/動的）と、“勝手に型を変換するか”（強い/弱い）は別の軸です。

• 強い型付け: 型が違えば勝手に変換しない。1 + "2" をエラーにするか、明示変換を要求する。
• 弱い型付け: 文脈に合わせて暗黙に変換する。1 + "2" が "12" になったりする。

Python は動的だが強い型付けで、1 + "2" は実行時にエラーになります。一方 JavaScript は動的かつ弱いため、暗黙変換が走ります。

# Python（動的・強い）: 暗黙変換しないのでエラー
1 + "2"   # ❌ TypeError: int と str は足せない

// JavaScript（動的・弱い）: 暗黙変換で“それっぽく”動いてしまう
1 + "2"    // "12"  （数値が文字列化されて連結）
"5" - 1    // 4     （今度は文字列が数値化されて引き算）
[] + {}    // "[object Object]"

型推論：書かなくても型は付く

「静的型付け＝型注釈を毎回書く」も誤解です。多くの静的言語は型推論を備え、初期値などから型を自動で割り出します。明示注釈を減らしつつ、静的検査の恩恵は受けられる、というおいしいとこ取り。

let count = 0;        // : number と書かなくても number と推論される
let name = "Tech";    // string と推論
count = "x";          // ❌ それでも型違反は弾かれる

つまり「静的か動的か」と「注釈を書くか書かないか」も、本当は別の話。推論が強力な Rust や TypeScript では、注釈は要所だけで済みます。

それぞれの利点・欠点

つまずきポイント

どう選ぶ？

• 静的が向く: 大規模・多人数・長期保守、安全性が要件（決済・基盤）、IDE 補完を最大化したい
• 動的が向く: プロトタイプ・スクリプト・データ分析、要件が流動的、とにかく速く回したい
• 迷ったら漸進的型付けから。最初はゆるく、重要部分から型で締めていく。

型システムは“優劣”ではなくトレードオフの設定です。早く検査して安全を取るか、後回しにして身軽さを取るか——プロジェクトの寿命と規模で答えは変わります。関連して、値そのものの分類は変数とデータ型、例外の扱いはエラーハンドリングも合わせてどうぞ。