コンパイラを味方にせよ：テンプレートリテラル型で実現する「文字列の型安全」という聖域
TypeScriptをただの「型補完ツール」だと思っているなら、それは宝の持ち腐れだ。TypeScriptの型システムは、コンパイル時にコードを解析する「静的解析エンジン」である。
今回は、実務で頻出する「文字列操作」を型システムに組み込み、ランタイムにバグを落とす前にコンパイルエラーとして叩き潰すための「テンプレートリテラル型（Template Literal Types）」の実践的アプローチを伝授する。
—
1. 文字列は「型」になり得るか？
多くのエンジニアが、APIのパスやCSSのクラス名を `string` 型で放置している。これは地雷原を歩くようなものだ。`string` と書いた瞬間に、その変数は「何でもあり」のブラックボックスと化す。
我々が目指すべきは、「文字列のフォーマットを型レベルで定義し、バリデーションをコンパイル時に完結させる」ことだ。
基本概念：型レベルの計算
テンプレートリテラル型は、単なる文字列結合ではない。TypeScriptの型推論エンジンが、型定義内の文字列の組み合わせを計算し、許容される集合を構築する。
type Method = ‘GET’ | ‘POST’;
type Resource = ‘users’ | ‘posts’;
// 型レベルでURLの構造を定義する
type ApiRoute = `/${Resource}/${string}/${Method}`;
// OK: コンパイラが許容する
const validRoute: ApiRoute = ‘/users/123/GET’;
// Error: 型定義に適合しないため、コンパイル時に赤線が出る
const invalidRoute: ApiRoute = ‘/products/123/DELETE’;
// Type ‘”/products/123/DELETE”‘ is not assignable to type ‘”/users/123/GET” | …’
—
2. 実践：保守性を最大化する「パス・ビルダー」の設計
プロダクションコードでは、単なる型定義だけでなく、型と実体を同期させる必要がある。ここで `as const` と `infer` を組み合わせた、現場で即戦力となるテクニックを紹介する。
シナリオ：ネストされたAPIエンドポイントの型安全な構築
特定のルール（`/{version}/{resource}/{id}`）に従わないURLを一切許容しない設計だ。
type Version = ‘v1’ | ‘v2’;
type Resource = ‘users’ | ‘orders’;
// 型安全にパスを生成するユーティリティ関数
function createPath
version: V,
resource: R,
id: string
): `/${V}/${R}/${string}` {
return `/${version}/${resource}/${id}`;
}
// 実行例
const path = createPath(‘v1’, ‘users’, ’42’);
// 推論結果: `/${‘v1’}/${‘users’}/${string}`
// 型の制約により、存在しないリソースやバージョンを指定すると即座にエラー
// createPath(‘v3’, ‘products’, ‘1’); // エラー: Argument of type ‘”v3″‘ is not assignable to ‘Version’
この設計の肝は、関数の引数に型制約をかけつつ、戻り値にテンプレートリテラル型を指定することだ。これにより、呼び出し元は「自分が何を作っているか」を常に型として認識できる。
—
3. 注意点：パフォーマンスと「型爆発」の境界線
テンプレートリテラル型は強力だが、「型爆発（Type Explosion）」という代償がある。
TypeScriptのコンパイラは、テンプレートリテラル型が複雑になると、その組み合わせを全て計算しようとする。もし `A | B | C` のような巨大なユニオン型を組み合わせて数千通りのパスを生成させれば、IDEの動作は重くなり、コンパイル時間は指数関数的に増大する。
- 避けるべき記述:
- 無限に再帰するテンプレートリテラル型
- 巨大なユニオン型同士をテンプレートリテラルで結合すること
- 指針:
- パスの構造が複雑すぎる場合は、テンプレートリテラル型で全てを定義しようとせず、インターフェースで構造を定義した後に、必要な部分のみ型を絞り込む。
—
4. なぜこれが「美しいコード」なのか
私がコードレビューでこの手法を推奨する理由は、単にバグが減るからではない。「ドキュメントとしての型」が成立するからだ。
1. 自己文書化: コードを読むだけで、その関数がどのようなURLを生成するか一目瞭然である。
2. リファクタリング耐性: リソース名が変更された際、型定義を書き換えれば、プロジェクト全体で変更が必要な箇所がコンパイルエラーとして即座に浮き彫りになる。
3. ランタイムコストゼロ: この型情報はコンパイル時に消滅する。実行時にはただの文字列結合が行われるだけで、パフォーマンス低下は一切ない。
最後に：型を「制約」と捉えるな
初心者は型を「守ってくれる壁」だと考える。しかし、熟練者は型を「設計図そのもの」と捉える。
テンプレートリテラル型を使いこなすことは、文字列という混沌としたデータに、プログラムの意思を刻み込む行為だ。君たちの書くコードが、コンパイラの力によって堅牢に守られ、数年後の自分やチームメイトを救うことを願っている。
さあ、エディタを開いて、曖昧な `string` を全て排除しに行こう。