なぜTypeScriptなのか？保守性の高いコードベースの維持

近年のWebアプリは規模が爆発的に増大しており、人間が全ての変数の中身を記憶しておくことは不可能です。

function add(a, b) {
  return a + b;
}
// 意図せぬ文字列結合が起きる
add(1, "2"); // "12" 😱

function add(a: number, b: number) {
  return a + b;
}
// コンパイル時にエラー検知
add(1, "2"); // ❌ Error

TypeScriptは、この「実行しないと分からない」を「コードを書いている最中に分かる（コンパイルエラー）」に変えるツールであり、未来の自分やチームメンバーへの説明書をコードに埋め込む行為です。

TSの恩恵を最も感じるのは以下の3つの瞬間です。

• 境界（Boundary）：
  APIからのレスポンスやフォーム入力など、「外部から入ってくるデータ」に型をつけることで、そこから先の実装で「データがあるはずなのに無い（undefined）」というミスを完全に防げます。
• 変更（Refactoring）：
  「Userオブジェクトの name を fullName に変えたい」と思った時、JSでは全ファイルをGrepして目視確認が必要ですが、TSならエディタの機能で一括置換でき、修正漏れがあれば赤線で教えてくれます。
• レビュー（Review）：
  「この関数は何を受け取るの？」という簡単な質問をPull Requestでする必要がなくなり、「ビジネスロジックが正しいか」という本質的な議論に集中できます。

既存のJSプロジェクトを一気にTS化するのは危険です。以下の3ステップで進めます。

1. Level 1: 共存設定 (Allow JS)
   tsconfig.json で allowJs: true に設定し、既存のJSファイルをそのまま動くようにしつつ、新しく書くファイルだけ .ts で書きます。
2. Level 2: 境界の型定義
   APIのレスポンスや、共通コンポーネントのPropsなど、影響範囲の大きい部分から型をつけます。内部ロジックはまだ any でも構いません。
3. Level 3: 厳格化 (Strict Mode)
   noImplicitAny: true を有効にし、全ての変数に型がついている状態を目指します。ここまで来て初めて「堅牢なコードベース」と呼べます。

堅牢なコードベースを作るための推奨設定です。strict: true を基本とし、さらに以下を有効化します。

• noImplicitAny: true
  暗黙のanyを禁止し、型の明示を強制する（これを入れないとTSの意味が半減します）。
• strictNullChecks: true
  null/undefinedの可能性を厳密にチェックする（"ぬるぽ"を撲滅する）。
• noUncheckedIndexedAccess: true
  配列アクセス時にundefinedの可能性を考慮させる（arr[0] が必ず存在するとは限らない）。
• exactOptionalPropertyTypes: true
? 付きプロパティに明示的な undefined 代入を禁止する。

「型パズル（複雑すぎる型定義）」に陥らないためのポイントです。

TSを導入しても、ルールを守らなければ無法地帯になります。

• ESLint / Prettier：
  「使っていない変数はエラーにする」「インデントを揃える」など、機械的な指摘は人間にさせず、自動化します。
• CIでの型チェック (tsc --noEmit)：
  ローカルでエラーが出ていてもコミットできてしまうため、GitHub ActionsなどのCI上で必ず型チェックを走らせ、エラーがあるPRはマージできないようにします。

よくある失敗パターンです。

• 「とりあえずany」問題：
  型エラーを消すために any を多用すると、TSのメリットがゼロになります。
  → 回避策：どうしても型が分からない時は unknown を使い、「型ガード（if typeof ...）」を書かないと使えないように制限する。
• 過剰なジェネリクス：
  再利用性を高めようとして Function<T, U, V> のように複雑にしすぎ、誰も読めないコードになる。
  → 回避策：YAGNI（必要になるまでやらない）原則を守り、まずは具体的な型で書く。

TypeScript導入/運用の健全性チェックリストです。