【TypeScript】interface と type の違い・使い分け完全ガイド｜宣言マージ・拡張・union型まで実例で解説

この記事で学べること

• interface と type それぞれの基本構文と特徴
• interface だけが持つ「宣言マージ（Declaration Merging）」の仕組み
• 拡張方法の違い（extends vs &）
• type だけが使える union 型・交差型・mapped type・conditional type
• パフォーマンスとエラーメッセージの観点からの違い
• 実務での使い分け判断フロー
• よくある誤解とエラーの解決方法

前提知識：TypeScript の基本型（string, number など）と型の基礎を理解していることを前提とします。

// interface で定義
interface UserInterface {
  id:    number;
  name:  string;
  email: string;
  greet(): void;
}

// type で定義
type UserType = {
  id:    number;
  name:  string;
  email: string;
  greet(): void;
};

// どちらも同じように使える
const u1: UserInterface = { id: 1, name: "Alice", email: "a@example.com", greet() {} };
const u2: UserType     = { id: 1, name: "Alice", email: "a@example.com", greet() {} };

オブジェクトの形を定義する場合、基本的な機能は interface と type で同じです。どちらを使っても型チェックの動作に差はありません。違いが出るのは「特殊な機能を使うとき」です。

interface Animal {
  name: string;
  eat(): void;
}

interface Pet {
  owner: string;
}

// 複数の interface を extends
interface Dog extends Animal, Pet {
  breed: string;
  bark(): void;
}

// Dog は Animal + Pet + 固有プロパティを持つ
const dog: Dog = {
  name: "ポチ", owner: "田中", breed: "柴犬",
  eat() {}, bark() {},
};

interface Config {
  host: string;
}

// 同名 interface を再定義 → 自動マージされる
interface Config {
  port: number;
}

// Config は { host: string; port: number; } として扱われる
const cfg: Config = { host: "localhost", port: 3000 };

// type では同名定義はエラーになる
// type Config = { host: string };     // OK
// type Config = { port: number };     // NG: Duplicate identifier 'Config'

宣言マージの主な用途：ライブラリの型定義（.d.ts）を拡張する場面でよく使われます。例えば Express の Request に独自プロパティを追加する「モジュール拡張（Module Augmentation）」は宣言マージを利用しています。

interface Printable {
  print(): void;
  label: string;
}

class Document implements Printable {
  label = "文書";
  print() {
    console.log(this.label);
  }
}

// type でも implements は使える（どちらも同じ）
type Serializable = { serialize(): string };
class Data implements Serializable {
  serialize() { return "data"; }
}

// union 型（どちらかの型）
type StringOrNumber = string | number;
type Id = string | number | null;

// 交差型（両方の型を持つ）
type AdminUser = User & Admin;
// AdminUser は User と Admin のプロパティを全て持つ

// リテラル型の union も type でよく使う
type Direction = "left" | "right" | "up" | "down";
type HttpMethod = "GET" | "POST" | "PUT" | "DELETE";

// interface では union 型を直接定義できない
// interface Id = string | number;  // NG: 構文エラー

// プリミティブ型への別名
type UserId = string;
type Score  = number;

// タプル型
type Point = [number, number];
type RGB   = [number, number, number];
const pos: Point = [10, 20];

// 配列型の別名
type StringList = string[];
type Matrix     = number[][];

// interface ではプリミティブやタプルの別名は作れない
// interface UserId = string;  // NG

// Mapped Type: プロパティを変換
type Optional<T> = {
  [K in keyof T]?: T[K];
};

// Conditional Type: 条件分岐で型を選択
type NonNullable<T> = T extends null | undefined ? never : T;

// Template Literal Types
type EventName<T extends string> = `on${Capitalize<T>}`;
type ClickEvent = EventName<"click">;  // "onClick"

// type の & 拡張
type Animal = { name: string };
type Dog    = Animal & { breed: string };

// interface の extends
interface IAnimal { name: string; }
interface IDog extends IAnimal { breed: string; }

// プロパティが衝突した場合の挙動の違い
type A = { x: number };
type B = { x: string };
type AB = A & B;  // x: never（number & string = never）

// interface extends はプロパティ衝突でコンパイルエラー
// interface IA { x: number; }
// interface IB extends IA { x: string; }  // Error: x の型が互換しない

交差型と extends の違い：プロパティが衝突した場合、type & は never 型（到達不能な型）を生成してコンパイルエラーになりません（実行時に問題が出る可能性があります）。一方 interface extends は衝突時にコンパイルエラーを出してくれます。継承による型の整合性を保証したい場合は interface extends の方が安全です。

使い分けの判断フロー

1. union 型・タプル・プリミティブの別名が必要 → type 一択
2. ライブラリ型定義の拡張（Module Augmentation）が必要 → interface 一択
3. クラスの設計図・公開 API の型を定義 → interface を推奨
4. Mapped Type・Conditional Type を使った型変換 → type 一択
5. 単純なオブジェクト型で上記に当てはまらない → チームの規約に従う（どちらでも可）

// union 型を使うので type が適している
type ButtonProps = {
  label:    string;
  variant: "primary" | "secondary" | "danger";
  size?:   "sm" | "md" | "lg";
  disabled?: boolean;
  onClick?: () => void;
};

function Button({ label, variant, size = "md", disabled = false, onClick }: ButtonProps) {
  return `<button class="${variant} ${size}" disabled=${disabled}>${label}</button>`;
}

// express.d.ts（型定義ファイル）
// Express の Request に user プロパティを追加
import "express";

declare module "express" {
  interface Request {
    user?: {
      id: string;
      role: string;
    };
  }
}

// これで router.get 内で req.user.id が使えるようになる
// ※ type では宣言マージできないためこの用途は interface のみ

// 成功・失敗を union 型で表現
type ApiResult<T> =
  | { success: true;  data: T       }
  | { success: false; error: string };

async function getUser(id: number): Promise<ApiResult<User>> {
  try {
    const data = await fetchUser(id);
    return { success: true, data };
  } catch (e) {
    return { success: false, error: String(e) };
  }
}

// 呼び出し側で型が絞り込まれる
const result = await getUser(1);
if (result.success) {
  console.log(result.data.name);   // User 型
} else {
  console.error(result.error);
}

// ❌ 誤解① interface で union 型を作ろうとする
// interface Status = "active" | "inactive";  // NG: 構文エラー
// ✅ 正解: type を使う
type Status = "active" | "inactive";

// ❌ 誤解② 同名 type を再定義しようとする
// type Config = { host: string };
// type Config = { port: number };  // NG: Duplicate identifier 'Config'
// ✅ 正解: interface で宣言マージ、または交差型を使う
interface Config { host: string; }
interface Config { port: number; }  // OK: マージされる

// ❌ 誤解③ & 拡張でプロパティ衝突を見落とす
type A = { x: number };
type B = { x: string };
type C = A & B;  // x: never — コンパイルエラーにならないが使えない
const c: C = { x: 1 };  // Error: number は never に代入不可

interface vs type — 結論

• union 型・タプル・プリミティブ別名が必要 → type
• 宣言マージが必要（ライブラリ拡張など） → interface
• Mapped / Conditional / Template Literal Types → type
• クラスの implements・OOP 設計 → interface（どちらでも動くが意図が明確）
• どちらでもよい単純なオブジェクト型 → チーム規約に統一（TypeScript 公式は interface を推奨）
• プロパティが衝突する可能性がある拡張 → interface extends（コンパイルエラーで検知できる）