FlowingDev

TypeScriptとは？ JavaScriptにシートベルトとエアバッグが付いた理由を解説

TypeScriptは、静的型付けでエラーを早期に発見し、コードをより堅牢で分かりやすくする、いわばJavaScriptのスーパーパワー。その理由を学びましょう。

ツールを試す: TypeScript Playground

一言でいうと

TypeScriptは、JavaScriptの上に「型システム」を追加したプログラミング言語です。この型システムは、データ版の文法チェッカーみたいなもので、コードが実行される前に、山ほどあるバグのクラスを捕まえてくれます。

TypeScriptが解決する問題

Webの黎明期を想像してみてください。JavaScriptは、Webページをもう少しインタラクティブにするために、大急ぎで（有名な話ですが、たった10日間で）生まれました。ボタンのアニメーションやフォームのバリデーションといった、小さなスクリプト向けに設計されたのです。動的で、柔軟で、そして寛容でした。この寛容さが最大の長所であり、Webが成熟するにつれて、最大の弱点にもなりました。

素のJavaScriptでは、変数はなりたいものになんでもなれました。最初は数値だったのに、文字列に再代入され、次にはオブジェクトになり、最終的には undefined になる、なんてこともあります。

let myThing = 123;         // myThingは数値
myThing = "Hello world"; // 今度は文字列
myThing = { id: 456 };   // そして今度はオブジェクト

20行のスクリプトなら、これで問題ありません。でも、GoogleマップやFigmaのような巨大なサービスを動かす20万行のアプリケーションでは、これはカオスの元凶です。開発者は間違った型のデータを関数に渡してしまい、実行時、つまり実際のユーザーの目の前で、あの悪名高い undefined is not a function エラーを引き起こしていました。コードのリファクタリングは悪夢でした。ある関数を変更すると、手遅れになるまで気づかないうちに、アプリケーションの他の10箇所を壊してしまう可能性があったのです。

Microsoftは、自社の巨大なJavaScriptプロジェクトでまさにこの問題に直面し、カオスに秩序をもたらすことを決意しました。2012年、彼らはTypeScriptをリリース。その目的はJavaScriptを置き換えることではなく、強化することでした。誰もがすでに知っている言語の上に安全性と予測可能性のレイヤーを追加し、現代のWebが要求する大規模で複雑なアプリケーションに適したものにすることだったのです。

舞台裏の仕組み

TypeScriptの魔法は、コードがブラウザに届く前に起こります。ブラウザが実行するのはTypeScriptではなく、古き良きJavaScriptです。TypeScriptの仕事は、開発中に超インテリジェントで積極的なリンターとして機能することなのです。

### TypeScriptはJavaScriptのスーパーセット

これは理解すべき最も重要なコンセプトです。「スーパーセット」とは、有効なJavaScriptコードはすべて有効なTypeScriptコードでもある、という意味です。.js ファイルを .ts にリネームしても、そのまま動きます。TypeScriptは、単にJavaScriptの上に新しい構文を追加するだけなのです。

主な追加機能は型注釈（type annotation）です。これにより、TypeScriptにどんな種類のデータを期待しているかを伝えることができます。

// これは素のJavaScript
function getLength(someValue) {
  return someValue.length;
}

// こちらがTypeScript
function getLengthTyped(someValue: string | any[]) {
  return someValue.length;
}

JavaScript版では、getLength(42) を呼び出すと、数値の 42 には length プロパティがないため、実行時エラーが発生します。TypeScript版では、コードエディタとコンパイラが即座に悲鳴をあげ、数値は有効な引数ではないと教えてくれます。ファイルを保存する前にバグが捕まるのです。

### トランスパイル処理

では、ブラウザがTypeScriptを実行しないのであれば、その追加された構文はどうなるのでしょうか？それはトランスパイルというプロセスで消去されます。

トランスパイルは、コンパイルの特殊なタイプで、ソースからソースへの変換です。TypeScriptコンパイラ（通常 tsc と呼ばれるプログラム）が .ts ファイルを読み込み、型エラーをチェックし、そしてどのブラウザでも理解できるクリーンな .js ファイルを吐き出します。

以下がそのビフォーアフターです：

TypeScript 入力 (.ts)

function greet(person: string, date: Date): string {
  return `Hello ${person}, today is ${date.toDateString()}!`;
}

JavaScript 出力 (.js)

function greet(person, date) {
  return "Hello ".concat(person, ", today is ").concat(date.toDateString(), "!");
}

型注釈（: string、: Date）が完全になくなっていることに注目してください。トランスパイラは、あなたの作業をチェックするためにそれらを使用し、その後、実行可能なJavaScriptを残して捨て去ります。TypeScriptのプレイグラウンドは、このトランスパイルのステップをブラウザ上で即座に行うので、結果をリアルタイムで見ることができます。

### 型チェックと型推論

TypeScriptの「脳」は、その型チェッカーです。コードを分析し、型が一致しているか検証する部分です。しかし、常に自分で型を書く必要はありません。TypeScriptは、型推論（type inference）というプロセスを通じて、多くの場合、型を自分で見つけ出すほど賢いのです。

let name = "Alice"; // TypeScriptは `name` が `string` 型だと推論する
let age = 30;     // TypeScriptは `age` が `number` 型だと推論する

// これを試すと、TypeScriptはエラーを出す:
// Type 'number' is not assignable to type 'string'.
name = 42;

let name: string = "Alice" と書く必要はありませんでした。TypeScriptは、あなたが文字列リテラルを代入したのを見て、型を正しく推論しました。これにより、完全な安全性の恩恵を受けながら、コードをクリーンで読みやすく保つことができます。明示的な型を追加する必要があるのは、関数のパラメータや空の変数のように、TypeScriptが自力で型を把握できない場合だけです。

実世界でのエピソード

### 大リファクタリング

あるスタートアップの主力製品は、巨大なJavaScriptのモノリスでした。初期のチームは速さを重視して場当たり的に開発を進め、新しいチームはそのツケを払っていました。彼らはユーザー権限を扱うコアモジュールをリファクタリングする必要がありましたが、問題は、誰も user オブジェクトがどんな形であるべきか確信が持てなかったことです。user.isAdmin なのか、それとも user.role === 'admin' なのか？ user.id は数値として来るのか、文字列として来るのか？

すべての変更がギャンブルでした。彼らはTypeScriptをファイルごとに導入することを決めました。まず、明確な User インターフェースを定義することから始めました：

interface User {
  id: number;
  email: string;
  role: 'admin' | 'editor' | 'viewer';
  lastLogin: Date;
}

すると突然、彼らのIDEがクリスマスツリーのように光り始め、コードベース内で user オブジェクトを誤って使用している箇所を一つ残らず指摘し始めました。ある関数は、新しいインターフェースには存在しない user.isAdmin にアクセスしようとしていました。別の関数は、数値ではなく文字列のIDを渡していました。リファクタリングは、恐ろしい当てずっぽうのゲームから、体系的でガイド付きのプロセスへと変わったのです。

教訓： TypeScriptは、データ構造の信頼できる唯一の情報源（single source of truth）を作ることで、混沌としたリファクタリングを安全で予測可能なエンジニアリングタスクに変えます。

### 幽霊APIバグ

あるフロントエンド開発者が、サードパーティAPIのデータを表示するダッシュボードを構築していました。APIのドキュメントには、製品の価格は 19.99 のような数値になると明確に記載されていました。彼女はそれに応じてTypeScriptのコードを書きました：interface Product { name: string; price: number; }。

彼女のコードは何週間も完璧に動いていましたが、ある日、あるユーザーから「合計」の計算結果が NaN (Not a Number) と表示されると報告がありました。何時間もデバッグした結果、彼女は、特定の珍しい製品に対して、APIが価格を文字列として返していることを発見しました："19.99"。JavaScriptでは、10 + "19.99" の結果は文字列の "1019.99" となり、その後の計算を破壊していたのです。

TypeScriptを使っていれば、彼女はこの問題を発生源でキャッチできたでしょう。入ってくるAPIデータを彼女の Product インターフェースに対して検証することで、型が一致しないというエラーは、10ステップ後で計算しようとした時ではなく、不正なデータがシステムに入った瞬間にスローされたはずです。

教訓： TypeScriptはデータ契約を強制し、外部APIからの予期せぬ変更やエラーに対してアプリケーションを回復力のあるものにします。

よくある間違いと落とし穴

  • any という逃げ道： TypeScriptには any という特別な型があります。これは本質的にコンパイラに「信じてくれ、俺が何やってるか分かってるから」と伝え、その変数の型チェックをすべてオフにします。any を使いすぎるのは、安全機能のために車を買ったのに、その機能を全部オフにしてしまうようなものです。TypeScriptを使う目的そのものを台無しにしてしまいます。
  • コンパイラエラーを無視する： TypeScriptから赤い波線が表示されても、トランスパイルされたJavaScriptは問題なく動くように見えることがあります。このエラーを無視したくなる誘惑にかられますが、これは罠です。そのエラーは、潜在的な実行時バグの警告サインなのです。コンパイラに耳を傾けましょう。彼はあなたを助けようとしているのです。
  • 型システムと戦う： 初心者は、TypeScriptが何かをさせてくれない時にイライラしがちです。コードを正しく型付けする方法を見つけ出す代わりに、型アサーション（as any）や他の回避策でコンパイラをだまそうとします。これは通常、彼らのデータフローに対する理解が不十分であり、コンパイラが正しく問題を特定していることを意味します。
  • @types パッケージを忘れる： 多くの人気JavaScriptライブラリは、独自の型定義を含んでいません。TypeScriptコミュニティは、DefinitelyTypedと呼ばれるこれらの型定義の巨大なリポジトリを維持しています。LodashやExpressのようなライブラリを使用している場合、適切なオートコンプリートと型チェックを得るために、対応する @types/lodash パッケージをインストールする必要がよくあります。

なぜ注目すべきなのか

TypeScriptに手を伸ばすべき（あるいは少なくとも検討すべき）なのは、次のような時です：

  • JavaScriptプロジェクトが数ファイル以上の規模になった時。
  • チームで作業しており、全員がデータ構造について同じ認識を持っていることを確認する必要がある時。
  • 新しい機能を書く時間よりも undefined エラーのデバッグに時間を費やしていることに気づいた時。
  • コードエディタが、驚異的なオートコンプリート、リファクタリングツール、インラインのエラーメッセージを提供してくれる、超強力なアシスタントになってほしい時。
  • 長期間にわたって保守・拡張する必要があるアプリケーションを構築している時。

要するに、TypeScriptは現代のJavaScript開発におけるプロフェッショナルの標準です。TypeScriptを学ぶことは、バグの減少、コラボレーションの容易さ、そしてより自信を持った開発体験を通じて、元が取れる投資なのです。

もっと深く知るには

  • TypeScript Official Website & Handbook: 信頼できる唯一の情報源。ハンドブックは素晴らしく、包括的なガイドです。
  • TypeScript on Wikipedia: その歴史、設計、機能についてのハイレベルな概要を知るために。
  • MDN: Understanding TypeScript: Web開発エコシステムにおけるTypeScriptの位置づけに関するMozillaの見解。
  • DefinitelyTyped: TypeScriptエコシステムを非常に豊かにしている、すべてのサードパーティの型定義のリポジトリ。
  • TypeScript Deep Dive: 基本から高度な概念まで全てを網羅した、素晴らしい詳細なオンラインブック。

エディターはどうコードを理解するのか

色分けはプログラムの実行ではなく、言語パーサーによるものです。CodeMirror と Lezer がブラウザー内で記号と構文を解析します。候補にはキーワード、対応する場合のローカル名、スニペット、小さな組み込みリファレンスが含まれます。登録済みのシンボルにカーソルを重ねるとシグネチャが表示されます。候補が出ても、その API が実行環境に存在する保証はありません。対応するパーサーは構文エラーを検出しますが、型検査や実行の代わりにはなりません。Ruby と Lua はトークンベースのモードで、診断は限定的です。リモートの言語サーバーは使わず、コードは端末内に留まります。

CodeMirror & Lezer: MIT.

理論はOK。さあ手を動かそう — 100%ブラウザ内で。

ツールを試す: TypeScript Playground