ブログ記事
型エラーを読み解けているか：鈴木僚太『プロを目指す人のためのTypeScript入門』
TypeScript を使っているのに、型エラーが出るたびに any や as で乗り切っている——それは TypeScript を使っているのではなく、型チェックをオフにし続けているに近い。
鈴木僚太（uhyo）著『プロを目指す人のためのTypeScript入門』は、型エラーを「消すもの」ではなく「読み解くもの」として扱う視点を、言語仕様の論理から丁寧に積み上げていく技術書だ。JavaScript 経験者を対象に、TypeScript というコンパイラが何を根拠にエラーを出しているのかを一つひとつ説明する。
1. any と型アサーションが「本当の危険」である理由
TypeScript の型チェックが価値を発揮するのは、開発段階でバグの可能性をコンパイラが検出してくれるからだ。ところが any 型を使うと、その検出をコンパイラが放棄する。as による型アサーションも同様で、「自分が正しいとコンパイラに強制させる」操作に過ぎない。
本書はこれを「最凶の危険機能」と評し、なぜ危険なのかを丁寧に解説している。代替として登場するのが「型の絞り込み（ナローイング）」のパターンだ。typeof 演算子や等価比較、あるいはオブジェクトにタグを持たせて型を特定する「タグ付きユニオン」を使うことで、コンパイラが変数の型を確実に推論できる状態を保てる。重要なのは、コンパイラが推論できる書き方をするということ。この視点の転換が、読んでいて一番腑に落ちるポイントのひとつだ。
flowchart LR
A["string | number"] -->|"typeof x === 'string'"| B["string\n→ 文字列操作が使える"]
A -->|"typeof x === 'number'"| C["number\n→ 数値演算が使える"]
subgraph TU["タグ付きユニオン"]
D["{ type: 'success', data }"] --> E["Success型として操作"]
F["{ type: 'error', message }"] --> G["Error型として操作"]
end
style B fill:#e8f8e8,stroke:#4caf50
style C fill:#e8f8e8,stroke:#4caf50
2. enum と namespace を使わない設計基準
TypeScript はかつて、独自の言語構文を拡張しようとした時期があった。enum や namespace はその名残だ。本書はこれらを意図的に解説から排除し、現行の ECMAScript 標準に沿った機能のみを取り上げる方針を貫いている。
この選択には明確な理由がある。古い構文を習得しても、JavaScript 標準との乖離が残り続ける。一方、ECMAScript 準拠の書き方を選ぶことで、将来的なレガシー化を避けられる。同じ理由から、本書は interface 宣言よりも type 文を優先する指針を示し、エディタ補完の観点から default エクスポートや as を使ったインポートを避けるべきとも述べている。「なぜその書き方を推奨するのか」について、実際のツール挙動に基づく論拠が提示されている点が、現場での設計議論に直接使えて実用的だ。
3. 非同期処理の解説がシングルスレッドモデルから始まる理由
Promise や async/await の説明に入る前に、本書は JavaScript がシングルスレッドでノンブロッキング I/O を扱う言語であることを確認する。多くの入門書が「こう書けば動く」というコードパターンを先に示すのと対照的だ。
実行時の制御がどのように推移するかを理解した上で Promise を見ると、失敗時のキャッチ処理で unknown 型を付与する意図が自然に理解できる。型安全を保つためにどう書くかを、実行モデルの理解と一緒に学べる。また、strict: true や noUncheckedIndexedAccess といった厳格なコンパイラオプションを積極的に有効化する姿勢も一貫している。コンパイラの検出能力を最大限に引き出す設定のなかで、自分のコードがどう評価されるかを問い続ける読書体験だ。
4. どんな詰まりに効くか
「型エラーの赤い波線が出るたびに、意味を読まずに any や as で消してその場をしのいでいる」——本書が最も効くのはこの状況だ。エラーを消す作業に見えていたものが、制御フロー解析にもとづくナローイングの仕組みを知ると、「コンパイラが今この変数をどの型だと判断しているか」を読む作業に変わる。もう一つは、レビューで「なぜその書き方なのか」を問われて言葉に詰まる場面。interface と type、null と undefined のどちらを選ぶかに、エディタ補完やツールの挙動を根拠にした説明の語彙が手に入る。
5. 向いている人・向いていない人
向いている人：
- 実務で TypeScript を書いているが、複雑な型エラーの解消法がわからず
anyやasで一時的に消している - Java や C# などクラスベースの静的型付け言語の経験があり、「型はランタイムに影響しない」「構造的部分型」という TypeScript の前提に戸惑っている
- チームの型規約やレビュー基準を決める立場で、書き方の是非を一貫して説明するための論理的な語彙を求めている
向いていない人：
- JavaScript の経験がまだ浅い人（本書は JavaScript 経験者を前提とする中級書で、プログラミングや JS 文法そのものは解説しない。全体像から入りたいなら英語の入門書『プログラミングTypeScript』を先に通しておくと接続しやすい）
- React や Vue と組み合わせた画面実装の型付けをすぐ知りたい人（本書は言語コアとコンパイラオプションに焦点を絞り、フレームワークとの連携は読者の自己学習に委ねているため）
6. TypeScript 5 系の時代に、4.6 基準の本を読む意味
本書が基準にするのは TypeScript 4.6 で、その後の 5.x 系で入った satisfies 演算子や const type parameters、刷新されたデコレータには触れていない。この範囲は公式のリリースノートで各自が補う前提になる。設定面でも、Monorepo 構成や Vite・esbuild との連携といった実務のチューニングは踏み込みが浅い。一方で、型推論・ナローイング・構造的部分型・実行モデルの解説は言語の土台にあたる部分で、バージョンが上がっても読み替えずに効く。新機能は差分として後から足せる、という順序で捉えると本書の位置づけがはっきりする。
7. 読み終えた後、どこへ進むか
本書で型を使った開発に手が慣れたら、次は型設計の質を上げる段階に入る。『Effective TypeScript 第2版』は「なぜその書き方にすべきか」を項目単位で示していく本で、動けばよい型から、読み手と将来の自分を助ける型へと設計を引き上げてくれる。本書が固めた土台の上に、判断の指針を積み増す位置づけだ。
実務での最初の一歩は、いま any や as で抑えている箇所を一つ選び、typeof や等価比較によるナローイング、あるいはタグ付きユニオンで書き直してみることだ。エラーが消えたかではなく、コンパイラが型をどう絞り込んだかを追う——そこから始めればいい。
筆者の体験から
JavaScript から TypeScript への移行を進めるチームで、導入担当をしていた頃にこの本を読むことにした。メンバーは型を書いても、エラーが出ると any や as で黙らせるのが常態化しており、筆者自身も同じだった。読んでからは、オブジェクトにタグを持たせて型を特定する考え方を知り、状態を持つデータ構造に使うようになった。enum を避けて type とリテラルユニオンに寄せる判断基準もチームに共有し、緩めだった tsconfig の厳格なオプションも一部から有効化を提案した。ただし複数パッケージ構成での tsconfig のチューニングは本書だけでは足りず、自分たちで試行錯誤するしかなかった。
管理画面で API のレスポンス状態を as で無理やり通していた、誰も触りたがらないコードがあった。タグ付きユニオンで書き直し、if 文の中でコンパイラが型を自動的に絞り込むのを見たとき、初めて型に守られている感覚をつかめた。レビューでも理由を説明でき、以降チームの基準になった。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有