TypeScript 5.0の隠し刃：`const`型パラメータによるリテラル型推論の完全掌握
コードレビューをしていて、次のようなコードに遭遇したことはないだろうか。
// ありふれた、しかし型安全をドブに捨ているコード
function configure
return config;
}
const options = configure({
theme: “dark”,
retries: 3,
endpoints: [“/api/v1”, “/api/v2”]
});
// さて、options.theme の型は何になるか？
// 答えは string だ。 “dark” という厳密なリテラル型ではない。
フロントエンド開発やAPIクライアントの設計において、この「型のWidening（拡大）」に頭を悩ませた経験は一度や二度ではないはずだ。これを防ぐために、かつては `as const` を呼び出し側で強制したり、煩雑なジェネリクスの制約（`T extends …`）を書いたりしていた。
だが、TypeScript 5.0で導入された`const`型パラメータ（Const Type Parameters）により、そのアプローチは過去のものとなった。
今回は、コンパイラが型をどう評価し、実行時にどう結びつくのかという言語の深層を見据えながら、実務の現場でバグを根絶するための極限の設計パターンを伝授する。
—
なぜ通常のジェネリクスはリテラルを失うのか？
TypeScriptのコンパイラは、デフォルトでは「変数の再代入の可能性」を考慮して型を抽象化（Widening）する。
オブジェクトのプロパティや配列をジェネリック関数に渡した瞬間、コンパイラはそれを「変更可能な一般的なデータ構造」とみなすため、`”dark”` は `string` へ、`3` は `number` へと昇格（あるいは劣化）させられる。
これを抑制するためだけに、開発者に `as const` を強要するのはアーキテクチャの敗北だ。APIのコンシューマー（使用者）に実装詳細を意識させるべきではない。型安全性は、APIの提供者側が美しく担保し、呼び出し側には極上のDX（開発者体験）を提供すべきなのだ。
—
救世主：`const`型パラメータの構文とメカニズム
TypeScript 5.0以降、型パラメータの宣言の前に `const` 修飾子を置くことができるようになった。
function configure
return config;
}
たったこれだけだ。この `const` が付与された瞬間、コンパイラは型推論のアルゴリズムを切り替える。
呼び出し時に渡された実引数を、まるで `as const` が暗黙的に適用されたかのように、可能な限り狭いリテラル型（Narrow Literal Type）としてキャプチャするのだ。
コンパイル時の型評価の差
以下の比較を見れば、その差が圧倒的であることが一目瞭然である。
// 従来型
type Inferred1 = ReturnType
// 期待した型が失われている
// const型パラメータ
type Inferred2 = ReturnType
// 完全な読み取り専用リテラル型として保持される
—
【実践】プロダクションコードで使う極限の設計パターン
単に「リテラルが保持できる」という話にとどまらない。実務で頻出する「型安全なルーティング設定」と「環境変数・機能フラグ（Feature Flags）のバリデーション」を例に、堅牢な設計パターンを見ていこう。
パターン1: 型安全なコンポーネント・バリエーション定義
デザインシステムやUIライブラリにおいて、バリアントの定義とそのパスを完全に型安全に結びつけるケースを考える。
/
- UIコンポーネントのテーマと許可されたサイズを定義するアーキテクチャ
/
type ComponentConfig
defaultTheme: TTheme;
supportedSizes: TSizes;
// サポートされたサイズしか許容しないハンドラー
onResize: (size: TSizes[number]) => void;
};
// const型パラメータを駆使したファクトリー関数
function defineComponentConfig
config: ComponentConfig
) {
return config;
}
// — 使用例 —
const myButtonConfig = defineComponentConfig({
defaultTheme: “neon-blue”,
supportedSizes: [“sm”, “md”, “lg”, “xl”] as const, // 配列もイミュータブルに
onResize: (size) => {
// ここで size の型は “sm” | “md” | “lg” | “xl” に完全に絞り込まれている！
console.log(`Resized to: ${size}`);
}
});
// コンパイルエラーを検証
// myButtonConfig.onResize(“xxl”);
// ❌ Error: Argument of type ‘”xxl”‘ is not assignable to parameter of type ‘”sm” | “md” | “lg” | “xl”‘
このコードの美しさは、`onResize` の引数の型が、呼び出し側で渡した `supportedSizes` の配列要素から自動的に導出されている点にある。手動でユニオン型を定義し直す必要は一切ない。
—
パターン2: 非同期APIクライアントのルーティングとペイロード型推論
次はより実践的な、非同期APIのエンドポイント定義と型推論の結合だ。
// APIの定義構造
type ApiEndpoint
path: TPath;
method: TMethod;
cacheTtlMs?: number;
};
type ApiRegistry
endpoints: TEndpoints;
// 登録されたパスのみを受け入れるフェッチ関数を生成
fetcher:
};
// レジストリ構築関数
function createApiRegistry
endpoints: TEndpoints
): ApiRegistry
return {
endpoints,
fetcher: async (path) => {
// 実際はここにHTTPクライアントの処理が入る
return fetch(path).then(res => res.json());
}
};
}
// — プロダクションでの利用 —
const api = createApiRegistry([
{ path: “/api/v1/users”, method: “GET”, cacheTtlMs: 5000 },
{ path: “/api/v1/posts”, method: “GET” },
] as const);
// 成功ケース：定義済みのパスなので通る
await api.fetcher(“/api/v1/users”);
// 失敗ケース：タイポや未定義のパスは即座にコンパイルエラー
// await api.fetcher(“/api/v1/comments”);
// ❌ Error: Argument of type ‘”/api/v1/comments”‘ is not assignable to parameter of type ‘”/api/v1/users” | “/api/v1/posts”‘
バックエンドのエンドポイントを追加・変更した際、フロントエンド側で手動の型定義を書き換える必要がない。単にオブジェクトの配列を更新するだけで、IDEの補完と型安全性が完全に連動して追従する。これが、コンパイラの型推論をハックした先にあるモダンなフロントエンドアーキテクチャだ。
—
パフォーマンス上の注意点とアンチパターン
強力な `const` 型パラメータだが、銀の弾丸ではない。アーキテクトとして、以下のトレードオフを必ず念頭に置かなければならない。
1. 巨大なオブジェクト・配列でのコンパイル負荷
`const` 型パラメータは、渡されたデータ構造の「あらゆる階層」をリテラル型としてメモリ上（型空間）に保持しようとする。
数千行に及ぶJSONや、巨大なマスタデータを `const` 型パラメータを持つ関数にブッ込むと、TypeScriptコンパイラ（`tsc` または言語サービス）の型チェックが劇的に重くなり、IDEの補完がフリーズする原因になる。
> Guideline:
> 動的に生成される巨大なデータや、数千件のレコードを持つ配列に対して `const` 型パラメータを使ってはならない。それはコンパイルタイムのテロリズムである。あくまで「設定値」「ルーティング」「デザインスキーマ」といった、静的かつ数十〜数百プロパティ規模のドメインモデルに限定して適用せよ。
2. イミュータビリティとの共存
`const` 型パラメータで受け取ったオブジェクトのプロパティは、デフォルトで `readonly` （あるいはそれに類するイミュータブルな型）として扱われる。
もし関数内でそのオブジェクトを破壊的にミューテート（変更）しようとすると、容赦なくコンパイルエラーが発生する。これはバグを防ぐ意味でメリットだが、古いライブラリ等と統合する際には `as` によるアサーションが必要になるケースがあるため注意が必要だ。
—
チーフアーキテクトからの総括
型システムとは、単なる「バグ発見ツール」ではない。それは「コードの意図をコンパイラと共有し、ドメインの制約をコードそのものに語らせるための言語表現力」である。
これまで、リテラル型を維持するために `as const` という脱出ハッチに頼っていた開発プロセスを、`const` 型パラメータによってより宣言的で美しいものへと昇華させることができる。
コードレビューでこのパターンを見かけたら、あるいは導入しようとするなら、こう問いかけてほしい。
——「その型推論は、コンパイラの負荷に見合うだけのDXと堅牢性をもたらしているか？」と。
答えが「Yes」であるならば、迷わず採用せよ。あなたの書くコードベースは、もっと強靭で、もっと美しいはずだ。