TypeScriptでenumを使わない設計のメリット。代替案としてのユニオン型とas constの活用術

TypeScriptが普及し、大規模なフロントエンド開発からバックエンドのNode.js環境に至るまで、静的型付けの恩恵は欠かせないものとなりました。

2026年現在のモダンな開発現場において、型の定義方法には多くの選択肢が存在しますが、その中でも「enum (列挙型) 」の扱いは特に慎重な議論が行われています。

かつては状態管理や定数定義の定番だったenumですが、現在のベストプラクティスでは、あえてenumを使わない設計が推奨されるケースが増えています。

本記事では、なぜenumが避けられる傾向にあるのか、その具体的なデメリットと、代わりとなる「ユニオン型」や「as const」の活用術について詳しく解説します。

TypeScriptにおけるenumの特殊性と現状

TypeScriptのenumは、他の言語から移行してきた開発者にとって非常に馴染み深い構文の一つです。

しかし、enumにはTypeScriptの他の機能とは大きく異なる、「JavaScriptに変換した際にコードが残る」という特殊な性質があります。

TypeScriptの設計思想の基本は、コンパイル（トランスパイル）後に型情報が消滅し、純粋なJavaScriptになるというものです。

インターフェース (interface) や型別名 (type) は、実行時のコードには一切影響を与えません。

これに対し、enumは実行時にもオブジェクトとして存在し続けるため、バンドルサイズや動作の予測可能性に影響を与えます。

この特異性が、現代のTypeScript開発においてenumが議論の的となる最大の理由です。

なぜenumの使用は「避けろ」と言われるのか

enumを積極的に採用しない理由は、主に「型安全性の不完全さ」と「ランタイムへの影響」の2点に集約されます。

数値enumの型安全性の問題

TypeScriptの初期から存在する数値ベースのenumには、型定義をすり抜けてしまうという重大な欠陥があります。

以下のコード例を見てみましょう。

// 数値enumの定義
enum UserRole {
  Admin,
  Editor,
  Viewer
}

// 期待しない数値が代入できてしまう
const myRole: UserRole = 99;

このコードは、コンパイルエラーになりません。

enumで定義されていない数値であっても、number型であれば代入が許可されてしまうという仕様があります。

これは堅牢な型安全性を求める開発において、予期せぬバグを招くリスクとなります。

コンパイル後のコード量と複雑性

enumをJavaScriptに変換すると、即時実行関数 (IIFE) を利用した複雑なコードが生成されます。

enum Direction {
  Up,
  Down
}

上記のコードは、以下のようなJavaScriptに変換されます。

"use strict";
var Direction;
(function (Direction) {
    Direction[Direction["Up"] = 0] = "Up";
    Direction[Direction["Down"] = 1] = "Down";
})(Direction || (Direction = {}));

このように、単なる定数の定義であるにもかかわらず、複雑な代入処理が発生します。

この構造は、モダンなビルドツールによるTree Shaking (未使用コードの削除) の最適化を妨げる原因となることがあります。

小規模なプロジェクトでは無視できる差ですが、大規模なアプリケーションで多くのenumを定義すると、蓄積されたコード量が無視できないコストになります。

構造的部分型との乖離

TypeScriptは「構造的部分型 (Structural Typing) 」という考え方に基づいて設計されています。

これは、型の中身（プロパティやシグネチャ）が同じであれば、同じ型として扱うという仕組みです。

しかし、enumだけは例外的に「公称的部分型 (Nominal Typing) 」のように振る舞います。

つまり、たとえ中身が同じ文字列であっても、定義されたenum型でなければ代入できないという制約が発生します。

これはTypeScript全体の柔軟な型システムの中で、enumだけが浮いた存在になってしまう原因の一つです。

推奨される代替案1：ユニオン型 (Union Types)

enumを使わない最もシンプルな選択肢は、文字列リテラルのユニオン型を利用することです。

ユニオン型のメリット

ユニオン型は、コンパイル後に一切のコードを残しません。

また、型定義が非常に直感的であり、開発時の補完機能も十分に働きます。

// ユニオン型による定義
type Status = "pending" | "running" | "completed";

const currentStatus: Status = "running";

// 誤った値はコンパイルエラーになる
// const errorStatus: Status = "stopped";

この手法の最大の利点は、実行時のオーバーヘッドがゼロであることです。

また、外部APIから受け取った文字列をそのまま代入できるなど、構造的部分型としての柔軟性を最大限に活かすことができます。

推奨される代替案2：object + as const (Const Assertions)

「単なる型だけでなく、プログラム中で値を反復処理したい」「値に意味のある名前を付けたい」という場合には、as const を活用したオブジェクト定義が最適です。

as const の仕組み

as const は、オブジェクトのプロパティをすべて「読み取り専用」かつ「リテラル型」として扱うように指示する機能です。

// オブジェクトと as const の組み合わせ
const AppConfig = {
  ApiEndpoint: "https://api.example.com",
  Timeout: 5000,
  MaxRetries: 3
} as const;

// 型を抽出する
type AppConfigType = typeof AppConfig;

このように定義することで、AppConfig.ApiEndpoint は単なる string ではなく、"https://api.example.com" という固定の型として認識されます。

enumに近い使い勝手を実現するパターン

以下のパターンは、現在のTypeScript開発において最も推奨される設計パターンの一つです。

const UserRoles = {
  Admin: "ADMIN",
  Editor: "EDITOR",
  Viewer: "VIEWER",
} as const;

// 値の型を抽出する ( "ADMIN" | "EDITOR" | "VIEWER" )
type UserRole = typeof UserRoles[keyof typeof UserRoles];

function setPermission(role: UserRole) {
  console.log(`Setting permission for ${role}`);
}

// 安全に使用可能
setPermission(UserRoles.Admin);
setPermission("EDITOR"); // 文字列を直接渡すことも可能

この手法には、enumが持つ「値に名前を付ける」というメリットを維持しつつ、enumの欠点をすべて解消できるという強みがあります。

enumと代替案の比較まとめ

それぞれの特性を以下の表にまとめました。

用途に合わせて最適なものを選択してください。

ご覧の通り、ほとんどのケースにおいてユニオン型または as const が優位に立っています。

リファクタリングの実践：enumからas constへの移行

既存のプロジェクトでenumを多用している場合、一気にすべてを置き換えるのはリスクがあります。

まずは、数値enumを文字列enumへ、次に文字列enumを as const オブジェクトへと段階的に移行することをお勧めします。

手順1：数値enumの廃止

数値型は意図しない代入を許容するため、まずは文字列ベースの定義に変更します。

これだけで、予期せぬ数値が入り込むリスクを排除できます。

手順2：as const への置き換え

次に、enumキーワードを const オブジェクトに書き換えます。

この際、type エクスポートを併用することで、外部モジュールからは型として利用できるように工夫します。

// 移行前
export enum OrderStatus {
  Pending = "PENDING",
  Shipped = "SHIPPED",
}

// 移行後
export const OrderStatus = {
  Pending: "PENDING",
  Shipped: "SHIPPED",
} as const;

export type OrderStatus = typeof OrderStatus[keyof typeof OrderStatus];

この書き換えを行うことで、利用側のコード OrderStatus.Pending はそのままに、型定義の堅牢性と実行時の効率を向上させることができます。

パフォーマンスへの影響を考慮する

フロントエンド開発において、JavaScriptのファイルサイズはユーザー体験 (LCPなどの指標) に直結します。

enumが生成するコードは微々たるものに見えますが、ライブラリ開発などではその積み重ねが大きな差となります。

特にWebブラウザ上での実行を前提とする場合、「型はコンパイル時に消えるべき」という原則を徹底することが、高速なアプリケーションへの近道です。

高度な活用法：Type Guards との組み合わせ

as const オブジェクトを使用するもう一つの大きなメリットは、ユーザー定義型ガード (Type Guards) との相性が非常に良いことです。

const VALID_THEMES = ["light", "dark", "system"] as const;
type Theme = typeof VALID_THEMES[number];

function isTheme(value: unknown): value is Theme {
  return typeof value === "string" && (VALID_THEMES as readonly string[]).includes(value);
}

const input: unknown = "dark";
if (isTheme(input)) {
  // ここでは input は Theme 型として扱える
  console.log(`Selected: ${input}`);
}

このように、実行時のバリデーションと型定義を一つの配列やオブジェクトから一元管理できるため、コードの重複を最小限に抑えられます。

enumでは、このような「値のリストを動的にチェックする」処理が記述しにくいため、この点でも代替案に軍配が上がります。

まとめ

2026年現在のTypeScript開発において、enumを積極的に使用する理由は少なくなっています。

独自の実行時コードを生成し、型安全性に一部不安があるenumよりも、シンプルで強力なユニオン型や as const オブジェクトを選択するのが賢明です。

この記事で紹介した as const による定数管理パターンは、可読性、保守性、そしてパフォーマンスのすべてにおいて優れたバランスを持っています。

もし現在のプロジェクトで enum の使用に疑問を感じているのであれば、まずは小さな箇所からユニオン型へのリファクタリングを試してみてください。

TypeScriptの真の力を引き出すためには、言語の特性を理解し、ランタイムに不要な負担をかけない設計を心がけることが重要です。

よりクリーンで安全なコードを目指して、型定義のあり方を再検討してみましょう。