学習ガイド

TypeScript 入門完全ガイド|JavaScript 経験者が最短で習得する 12 ステップ

18分で読めます
この記事のポイント

JavaScript 経験者向けに、TypeScript を 1 ヶ月で実務レベルまで引き上げる完全ガイド。tsconfig の strict 設定、ジェネリクス、Utility Types、Discriminated Union を 12 ステップで体系的に解説します。

editor

チョットデキル編集部

チョットデキルの編集部です。プログラミング学習に役立つ情報をお届けします。

「JavaScript はある程度書けるけれど、TypeScript の typeinterface の違いが分からない」「現場で TS のコードを読まされて、ジェネリクスや Utility Types で詰まる」と感じていませんか。

2026 年の現在、フロントエンドからバックエンド、社内ツールまで、新規の Web プロダクトはほぼ TypeScript が前提です。JavaScript の経験者が最短で TypeScript を実務レベルに引き上げるには、文法を端から舐めるのではなく、型システムの考え方を 12 ステップで段階的に身に付けるのが効率的です。この記事では、JS 経験者が 1 ヶ月で「現場の TS コードを読み書きできる」状態に到達するための完全ガイドを解説します。


TypeScript 完全ガイド とは

TypeScript の型システム・コンパイル設定・React/Next.js での実践まで、現場で必要な全範囲を 1 本にまとめたガイドです。JavaScript 経験者が 1 週間で TypeScript に移行できる学習順を提示します。

TL;DR 早わかりサマリー

  • TypeScript は「JS に型注釈を足した別言語」ではなく「JS の暗黙の前提を明示化する仕組み」と捉えると学習コストが半減する
  • 文法暗記より「type で表現できないことは何か」「any を避けるとどう書くか」の感覚を先に身に付けるのが近道
  • 12 ステップ約 30 時間で、tsconfig の strict 設定、ジェネリクス、Utility Types、Discriminated Union まで実務級に到達できる
  • 学習の順序は基本型 → ジェネリクス → Utility Types → 型ガード → 設計の 5 ブロックに集約される

1. なぜ 2026 年に TypeScript を学ぶのか

新規の Web プロジェクトで TypeScript を採用しない理由は、もはやほぼ存在しません。Next.js、Remix、Nuxt、Astro、SvelteKit といった主要フレームワークは TS をデフォルトに据えており、求人票でも「TypeScript 必須」が標準になりました。

理由は 3 つあります。1 つ目は エディタ補完の精度 です。VS Code の補完が型情報を使って正確に効くため、ライブラリのドキュメントを開く頻度が半分以下になります。2 つ目は リファクタ耐性 です。関数の引数を 1 つ増やしただけで、影響範囲が即座に赤線で見えます。3 つ目は AI 連携 です。Copilot や Claude にコードを書かせる際、型情報があると AI の出力品質が体感で 2 倍くらい変わります。

逆に言えば、JS だけで生きていく道はもう新規案件では選びにくくなっています。既存の JS プロジェクトのメンテナンスは残りますが、転職・副業の市場価値で見れば TS の習得は最優先の投資です。


2. JS 経験者が最初に学ぶべきこと

JS 経験者の TS 学習で最大の落とし穴は「文法から順に学ぼうとする」ことです。stringnumberboolean の基本型からスタートすると、退屈すぎて 3 日で脱落します。

JS 経験者がまず触るべきは、次の 3 つです。

1 つ目は 既存の JS コードを .ts にリネームしてみる ことです。VS Code が即座にエラーを出してくれるので、TS が何を「危険」と判断するかが体感で分かります。 2 つ目は strict: true で書いてみる ことです。noImplicitAnystrictNullChecks が有効になり、暗黙の undefined の怖さが見えます。 3 つ目は 型推論に任せる感覚を掴む ことです。変数宣言にいちいち型を書くと冗長になります。「明示するのは関数の引数と戻り値だけ」が基本姿勢です。

この 3 つを 1 日でやってしまうと、その後の学習効率が一段上がります。


3. tsconfig 設定の最重要項目

tsconfig.json には数十のオプションがありますが、最初に押さえるべきは 5 つだけです。

  • strict: true — 厳格チェックの一括有効化。これだけで未来の自分が救われます
  • target: "ES2022" — モダンブラウザと Node.js を対象にする場合の現実的な妥協点です
  • module: "ESNext" または "NodeNext" — バンドラーや Node のバージョンに合わせて選びます
  • moduleResolution: "Bundler" — Vite/Next/esbuild 時代の標準です
  • noUncheckedIndexedAccess: true — 配列アクセスが undefined を返す可能性を型に反映します。最初は煩わしく感じますが、本番障害を確実に減らします

特に noUncheckedIndexedAccess は型チェック時にすぐ効果が現れます。arr[0] の型が T | undefined になるため、undefined チェックを強制されます。これが本番障害を未然に防ぎます。


4. 基本型と型注釈の書き方

TypeScript の基本型は JavaScript のプリミティブにほぼ 1 対 1 で対応しています。

TypeScript

const name: string = "山田"; const age: number = 30; const isActive: boolean = true; const tags: string[] = ["AI", "Web"]; const profile: { name: string; age: number } = { name: "山田", age: 30 };

関数の型注釈は次の通りです。

TypeScript

function greet(name: string, age: number): string { return `${name} さんは ${age} 歳です`; } const greet2 = (name: string, age: number): string => `${name} さんは ${age} 歳です`;

JS 経験者の最初の癖は「すべての変数に型注釈を書く」ことですが、これは冗長です。代入から推論できる場合は型注釈を省きます。書くのは関数の引数と戻り値、API レスポンスなどの境界部分だけで十分です。


5. type と interface の使い分け

両者で表現できることは 90% 重なっています。簡単な指針は次の通りです。

  • オブジェクトの形を定義するだけなら interface
  • Union、Intersection、関数型、リテラル型などを使うなら type
  • ライブラリの型を拡張する必要があるなら interface(宣言マージが効きます)

TypeScript

interface User { id: string; name: string; } type UserId = string; type Status = "pending" | "active" | "banned"; type Callback = (err: Error | null, data?: User) => void;

チーム規約で「全部 type」「全部 interface」と決めているチームも多く、その場合はチームに合わせます。1 人で書く分には「迷ったら type」で実害は出ません。


6. ジェネリクスを 10 分で理解する

ジェネリクスは「型を引数として受け取る関数・型」です。最も典型的な例は配列です。

TypeScript

function first<T>(arr: T[]): T | undefined { return arr[0]; } const firstNum = first([1, 2, 3]); // number | undefined const firstStr = first(["a", "b"]); // string | undefined

T はプレースホルダで、呼び出し時に具体的な型に置き換わります。<T extends ...> で T に制約をかけることもできます。

TypeScript

function keys<T extends object>(obj: T): (keyof T)[] { return Object.keys(obj) as (keyof T)[]; }

ジェネリクスを使うべきタイミングは「同じロジックを複数の型で再利用したい」ときです。逆に、特定の型しか想定しないなら無理にジェネリクス化しなくて構いません。


7. Utility Types で実務 8 割をカバーする

実務で頻繁に使う Utility Types は 6 つです。

  • Partial<T> — すべてのプロパティを optional に
  • Required<T> — すべてのプロパティを必須に
  • Readonly<T> — すべてのプロパティを readonly に
  • Pick<T, K> — 指定したプロパティだけを取り出す
  • Omit<T, K> — 指定したプロパティを除く
  • Record<K, V> — キー K、値 V の辞書型

TypeScript

interface User { id: string; name: string; email: string; } type UserUpdate = Partial<User>; type UserPublic = Omit<User, "email">; type UserDict = Record<string, User>;

Partial は API の PATCH リクエストで、Omit はレスポンスから機密情報を除く用途で頻出します。この 6 つを覚えるだけで、実務の 8 割の型操作はカバーできます。


8. Union と型ガード

複数の型を取りうる値は Union で表現します。

TypeScript

type Result = | { status: "success"; data: string } | { status: "error"; message: string }; function handle(r: Result) { if (r.status === "success") { console.log(r.data); // 自動で絞り込まれる } else { console.log(r.message); } }

これが Discriminated Union と呼ばれるパターンで、status のリテラル値で型が絞り込まれます。実務で頻出します。

typeofinstanceofin 演算子も型ガードとして働きます。複雑な分岐がある場合は、独自の型ガード関数を定義することもできます。

TypeScript

function isUser(v: unknown): v is User { return typeof v === "object" && v !== null && "id" in v; }

JavaScript の動的さを TS の型システムに橋渡しする際、型ガードが大活躍します。


9. 型エラーの読み方

TypeScript のエラーメッセージは慣れるまで読みづらいですが、構造は単純です。

プレーンテキスト

Type 'string' is not assignable to type 'number'.

これは「string を number に代入できない」というだけのメッセージです。長いエラーでも、まず「何を何に入れようとして失敗したか」だけを読み取れば 8 割解決します。

複雑なジェネリクスの型エラーは、IDE のホバーで「期待する型」と「実際の型」を見比べるのが近道です。それでも分からなければ、変数に意図する型を明示的に注釈してみると、どこでズレているか可視化されます。

学習段階では、TS のエラーは「敵」ではなく「将来の自分を助けてくれる先輩」と捉えるマインドセットが大事です。詳しいエラー対応の習慣は エラーが怖くなくなる:読み方と解決法 と相性が良いです。


10. React + TypeScript の頻出パターン

フロントエンド志望なら、React と TS の組み合わせは避けて通れません。頻出パターンを 4 つ押さえれば実務レベルです。

TypeScript

// Props 定義 type ButtonProps = { label: string; onClick: () => void; variant?: "primary" | "secondary"; }; const Button: React.FC<ButtonProps> = ({ label, onClick, variant = "primary" }) => { return <button onClick={onClick}>{label}</button>; }; // useState const [count, setCount] = useState<number>(0); const [user, setUser] = useState<User | null>(null); // イベントハンドラ const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => { console.log(e.target.value); }; // children type CardProps = { children: React.ReactNode };

React.FC は議論のある書き方ですが、初学者は使ってしまって構いません。慣れてきたら関数宣言で書くスタイルに移行してください。React の基礎は JavaScript入門 のあとに学ぶと、TS との接続もスムーズです。


11. Node.js + TypeScript の構成

バックエンドで TS を書くなら、2026 年時点の構成は次の通りです。

  • ランタイムは Node.js 22 系か Bun。Bun はネイティブで TS を解釈するので開発体験が良いです
  • ビルドは tsc --noEmit で型チェックのみ。実行は tsx または bun で直接 TS を動かす方が高速です
  • フレームワークは Hono、Express、Fastify が選択肢。Hono は Cloudflare Workers でも動くため、エッジ志向なら筆頭候補です

API のレスポンス型は Zod でランタイムバリデーションも兼ねるのが定番です。

TypeScript

import { z } from "zod"; const UserSchema = z.object({ id: z.string(), name: z.string() }); type User = z.infer<typeof UserSchema>; const user = UserSchema.parse(await fetch("/api/user").then((r) => r.json()));

Zod は外部入力の検証と型生成を 1 つの定義でまかなえるため、API 境界の安全性が一段上がります。


12. 学習ロードマップ 12 ステップまとめ

最後に、JS 経験者が 1 ヶ月で TypeScript を実務級まで引き上げる 12 ステップを整理します。

1 既存の JS プロジェクトを .ts にリネームし、エラーを眺める(30 分) 2 tsconfig.jsonstrict: true を有効化して赤線を埋める(2 時間) 3 基本型と型注釈、関数の引数・戻り値の書き方を写経(2 時間) 4 typeinterface の使い分けを実際に試す(1 時間) 5 ジェネリクスで「配列の先頭を返す」関数を 5 種類書いてみる(2 時間) 6 Utility Types(Partial、Pick、Omit、Record)を 1 つずつ自分のコードで使う(3 時間) 7 Union と型ガードで、API レスポンスのエラーケースを表現する(2 時間) 8 React + TS で useState、Props 定義、イベントハンドラを書く(3 時間) 9 Zod を導入し、外部入力のバリデーション + 型生成を体験する(2 時間) 10 既存ライブラリの .d.ts を読み、ジェネリクスの実例に触れる(2 時間) 11 ESLint + Prettier + TypeScript の構成をゼロから組む(2 時間) 12 ミニアプリを 1 本 TypeScript で完成させ、GitHub に公開(10 時間)

合計約 30 時間です。週 10 時間ペースで進めれば 3 週間で到達できます。全体観は プログラミング学習のはじめ方 と合わせて読むと、TS だけに偏らない設計感覚が育ちます。


よくある質問

Q. TypeScript を学ぶ前に JavaScript はどこまで理解しておくべきですか

A. 関数、配列・オブジェクト操作、async/await、ES Modules までは押さえてからの方が学習がスムーズです。クラスや prototype は後回しで構いません。

Q. any は使ってはいけませんか

A. 原則禁止です。どうしても型が決まらない場合は unknown を使い、使用前に型ガードで絞り込みます。any は型システムの保護を全部捨てる宣言なので、コードレビューで真っ先に指摘される箇所です。

Q. interfacetype、どちらを使うべきか毎回迷います

A. チーム規約があればそれに従ってください。なければ「ライブラリの型拡張は interface、それ以外は type」で運用するとブレません。

Q. ジェネリクスがどうしても理解できません

A. 「配列の型を一般化したもの」と思って、Array<T> の T が stringnumber に置き換わるイメージから入るとよいです。自分で抽象化する前に、ライブラリのジェネリクスを「読む」ことに慣れる方が先です。

Q. tsconfig の strict はいきなり有効にしてよいですか

A. 新規プロジェクトなら最初から有効、既存プロジェクトなら段階的に有効にするのが現実的です。noImplicitAnystrictNullChecks → 残りの strict の順で 1 つずつ消化すると無理がありません。

Q. TypeScript の学習にどれくらいの時間がかかりますか

A. JS 経験者なら、本ガイドの 12 ステップロードマップをひと通り終えるのに 30 時間が目安です。そこに実務パターンや実際のプロジェクト経験まで含めると合計 80〜100 時間、週 10 時間ペースで 2〜3 ヶ月です。


ハンズオン Step-by-Step

Node.js 20 以上が入っていれば、ターミナルだけで TypeScript の型を体験できます。

Step 1. TypeScript を入れる

プロジェクト用フォルダを作り、TypeScript と ts-node を導入します。

ターミナル

mkdir ts-demo && cd ts-demo npm init -y npm i -D typescript ts-node @types/node npx tsc --init

Step 2. 型付き関数を書く

hello.ts を作って次を貼ります。引数 name に string の型が付いている点に注目してください。

TypeScript

function hello(name: string): string { return `こんにちは、${name}さん`; } console.log(hello("生田"));

Step 3. 実行する

ts-node で直接実行できます。出力に「こんにちは、生田さん」と出れば OK。

ターミナル

npx ts-node hello.ts

Step 4. 型エラーをわざと起こす

数字を渡すとコンパイル時にエラーが出るのが TypeScript の強みです。

TypeScript

// hello(123); // ← これは型エラー

Step 5. interface でオブジェクト型を定義

オブジェクトの形を型として表現します。これがあるだけで、エディタ補完が劇的に改善します。

TypeScript

interface User { id: number; name: string; email?: string; // ? は任意プロパティ } const u: User = { id: 1, name: '田中' };

次は React + TypeScript の組合せに進むと、型の恩恵が最大化します。

まとめ

TypeScript は JavaScript の上位互換です。既存の JS コードをそのまま .ts にリネームしてもコンパイルが通ることがその証拠です。TS が加えるのは型注釈によって JS の暗黙の前提を明示化する仕組みであり、型情報はコンパイル後に消去されます。文法を端から覚えようとせず、まず既存の JS コードを .ts 化して赤線を見るところから始めてください。

最初の 2 週間で strict: true、ジェネリクス、Utility Types、Discriminated Union を押さえれば、現場の TS コードを読むのに必要な土台はほぼ揃います。残りはフレームワーク固有のパターン(React、Next.js、Hono など)を学ぶフェーズです。

学習の入り口は JavaScript入門実践 JavaScript を一通り済ませてから TS に移るのが最短ルートです。全体ロードマップは プログラミング独学完全ロードマップ 2026、Web 開発の方向性なら React 入門完全ガイド もあわせて読むと、自分の学習計画が立てやすくなります。今日 30 分で .ts ファイル 1 つを書き始めるだけで、1 ヶ月後の自分は別人になっています。

次に読むべきリソース

出典・参考リンク

本記事の主張・数値・仕様に関する根拠は、以下の一次情報・公式ドキュメントを参照しています。リンク先の更新により内容が変わる場合があるため、最新情報は各公式サイトで確認してください。

この記事について

  • 監修: 生田 陸人 (LuaGate エンジニア / 大手 IT 企業現役エンジニア)
  • 公開: 2026-05-28
  • 最終更新: 2026-05-28
  • カテゴリ: プログラミング入門
  • 検証環境: TypeScript 5.4 / Node.js 20 / ECMAScript 2024
  • 編集ポリシー: 公式ドキュメント・公的統計を一次情報として優先し、社内エンジニアが実機検証した内容のみを掲載しています。修正提案や事実誤認の指摘は チョットデキル運営 までお寄せください。
01/04