第1章: TypeScriptとは何か — 設計哲学と「実用主義」の勝利

TypeScriptを一言で言うと

TypeScriptとは、JavaScriptに静的型付けを追加したスーパーセット言語です。 Microsoftが2012年に公開し、2025年にはGitHub上で最も使用される言語の第1位に到達しました。 月間コントリビューター数は260万人を超え、プロフェッショナル開発者の約半数が日常的に使用しています。

しかし、TypeScriptを単なる「JavaScriptに型を足したもの」と捉えるのは表面的です。 TypeScriptの本質は、その設計哲学にあります。 なぜ型を「正しく」するよりも「便利に」する方を選んだのか。なぜランタイムに一切の痕跡を残さないのか。 この章では、TypeScriptの設計思想を深掘りし、なぜこの言語が他の競合を押しのけて世界標準となったのかを理解します。

設計目標 — 11の約束

TypeScriptの方向性は、公式Wikiに明記された11の設計目標（Design Goals）で規定されています。 これらは単なる理想論ではなく、機能追加のたびに立ち返る「憲法」のような存在です。

中でも注目すべきは目標3「ランタイムオーバーヘッドを課さない」と目標9「完全に消去可能な型システム」です。 TypeScriptの型はコンパイル時にのみ存在し、出力されるJavaScriptには一切含まれません。 この「Type Erasure（型の消去）」は、TypeScriptの最も重要な設計判断の一つです。

Non-Goals — あえて「やらない」こと

設計目標と同じくらい重要なのが、TypeScriptが意図的にやらないと決めた7つのこと（Non-Goals）です。 これらを理解することで、TypeScriptの「不完全さ」が実は意図的な設計判断であることが見えてきます。

最も重要なNon-Goalは「健全な（sound）型システムを適用しない」です。 型システムの「健全性（soundness）」とは、「型チェッカーが安全だと判断したコードは実行時にも必ず安全である」という保証です。 ElmやPureScriptはこの保証を提供しますが、TypeScriptは意図的にこれを放棄しています。

構造的型付け — 形が同じなら同じ型

TypeScriptは構造的型付け（Structural Typing）を採用しています。 型の互換性は名前ではなく、構造（メンバーの形状）で判定されます。 これは「ダックタイピング」として知られるJavaScriptのパターンと自然に調和する設計です。

// 構造的型付けの例
interface Point {
  x: number;
  y: number;
}

// 明示的にPointを実装していないが、構造が一致するのでOK
const point = { x: 10, y: 20, z: 30 };

function printPoint(p: Point) {
  console.log(`(${p.x}, ${p.y})`);
}

printPoint(point); // OK! 余分なプロパティ(z)があっても構造が合致

Java や C# ではimplements Pointのような明示的な宣言が必要です（名義的型付け）。 TypeScriptでは、必要なプロパティを持っていれば型として互換があると判定されます。

// ブランド型パターン — 意味の異なるnumberを区別する
type UserId = number & { readonly __brand: unique symbol };
type ProductId = number & { readonly __brand: unique symbol };

function getUser(id: UserId) { /* ... */ }

const userId = 42 as UserId;
const productId = 42 as ProductId;

getUser(userId);     // OK
getUser(productId);  // コンパイルエラー！型が異なる

漸進的型付け — anyから始めてstrictへ

TypeScriptのany型は、型付きコードと型なしコードを共存させるための橋です。 これにより、600万行のコードベース（Airbnb）でも、一度にすべてを型付けする必要がありません。

graph LR
  A[JavaScript\nany だらけ] -->|allowJs: true| B[TypeScript 導入\n.js と .ts の共存]
  B -->|段階的に .ts へ| C[strict: false\n暗黙の any 許容]
  C -->|noImplicitAny| D[strict: true\n厳格な型チェック]
  D -->|noUncheckedIndexedAccess| E[最大厳格\n全オプション有効]

  style A fill:#ef4444,stroke:#dc2626,color:#fff
  style B fill:#f97316,stroke:#ea580c,color:#fff
  style C fill:#eab308,stroke:#ca8a04,color:#fff
  style D fill:#22c55e,stroke:#16a34a,color:#fff
  style E fill:#3b82f6,stroke:#2563eb,color:#fff

この「漸進的型付け（Gradual Typing）」は、TypeScriptが大規模な既存コードベースに採用される最大の理由です。 Stripeは370万行を1つのPRで移行し、Bloombergは5,000万行のコードベースで400以上のプロジェクトが自発的にTypeScriptを採用しました。 完璧を求めず、段階的に安全性を高められる設計が、これらの大規模移行を可能にしています。

Type Erasure — 型はコンパイル時に消える

TypeScriptの型はコンパイル時にのみ存在し、出力されるJavaScriptには一切含まれません。 これが「Type Erasure（型の消去）」です。

// TypeScriptのソースコード
interface User {
  name: string;
  age: number;
}

function greet(user: User): string {
  return `Hello, ${user.name}!`;
}

// ↓ コンパイル後のJavaScript（型は完全に消去）
function greet(user) {
  return `Hello, ${user.name}!`;
}

JavaScriptスーパーセットという設計判断

「すべてのJavaScriptコードは有効なTypeScriptコードでもある」— この設計判断こそ、TypeScriptが競合に勝利した最大の理由です。

ReScriptやElmのような「JavaScriptとは別の言語」は、型システムの純粋さでTypeScriptを上回ります。 しかし、既存のJavaScriptコードベースからゼロコストで移行を始められるのはTypeScriptだけです。 .jsファイルの拡張子を.tsに変えるだけで、TypeScriptの恩恵を受け始められます。

graph TB
  subgraph TypeScript[TypeScript の世界]
    TS[型注釈\nインターフェース\nジェネリクス\n型ガード]
    subgraph JavaScript[JavaScript の世界]
      JS[変数・関数\nクラス\nPromise\nモジュール]
    end
  end

  style TypeScript fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style JavaScript fill:#eab308,stroke:#ca8a04,color:#000
  style TS fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style JS fill:#eab308,stroke:#ca8a04,color:#000

TypeScriptを採用すべき場面 / すべきでない場面