配列からユニオン型への昇華：`keyof typeof` がコンパイラとV8のメモリ空間に刻む痕跡
TypeScriptの型システムは、時に「単なる開発時のエディタ補助ツール」と誤認される。しかし、それは致命的な認識の甘さだ。型システムは、TypeScriptコンパイラ（`tsc`）のAST（抽象構文木）上で駆動する、純粋かつ強烈なメタプログラミングエンジンである。
今回は、定数配列から動的にユニオン型を生成する王道イディオムを取り上げる。
const ROLES = [‘admin’, ‘editor’, ‘viewer’] as const;
type Role = typeof ROLES[number];
一見、ただの便利な構文糖に思えるかもしれない。だが、この数文字の組み合わせが、TypeScriptの型推論メカニズム、コンパイル時のタプル評価、さらにはV8エンジンにおける実行時メモリの最適化にどう影響を与えているのかを、極限まで解像度を上げて分解しよう。
—
1. コンパイラ内部における `as const` とタプルの実体
まず、`as const`（Const Assertions）がコンパイラ（`checker.ts`）の内部で何を意味しているのかを理解する必要がある。
通常、JavaScriptの配列リテラルは、ミュータブルな `string[]` として推論される。これは、配列の要素が後から変更される可能性を考慮し、型をワイド（広義）に保つためだ。
// 通常の推論：広義の型
const ROLES_MUTABLE = [‘admin’, ‘editor’, ‘viewer’];
// 推論結果: string[]
ここに `as const` を付与した瞬間、TypeScriptのパーサーおよびチェッカーは、この配列を「読み取り専用の固定長タプル（Readonly Tuple）」としてマークする。
const ROLES = [‘admin’, ‘editor’, ‘viewer’] as const;
// 推論結果: readonly [“admin”, “editor”, “viewer”]
この時、コンパイラのメモリ空間上では、配列の各要素は単なる文字列型ではなく、リテラル型（Literal Type）として厳密に固定される。タプルの各インデックス（`0`, `1`, `2`）は、それぞれ `”admin”`, `”editor”`, `”viewer”` という唯一無二の型を保持したままASTに定着する。
—
2. `typeof` と `keyof` の合わせ技：インデクスアクセス型の真価
次に、`typeof ROLES[number]` という記述が、型レベルでどのように評価（Evaluation）されるのかを追う。
ステップ 1: `typeof ROLES`
`typeof` 演算子は、値空間のシンボルを型空間に射影する。これにより、値としての配列 `ROLES` は、型としての `readonly [“admin”, “editor”, “viewer”]` に変換される。
ステップ 2: `[number]` によるインデクスアクセス
ここが最も美しいポイントだ。TypeScriptのタプルや配列に対して `[number]` というインデクスアクセスを行うと、「配列のすべての数値インデックスに対応する値の型のユニオン」が返される。
これを数学的（あるいは集合論的）に表現するなら、配列のインデックスの集合 $\{0, 1, 2\}$ をドメインとし、各インデックスに対応するリテラル型をコドメインとする写像の値域（Image）の総和（Union）を求めていることになる。
type Indices = keyof typeof ROLES; // 0 | 1 | 2 | “length” | “readonly” | … (配列のプロパティ群)
type Elements = (typeof ROLES)[number]; // “admin” | “editor” | “viewer”
もしここで `keyof typeof ROLES` を使ってしまうと、Arrayプロトタイプが持つすべてのメソッド名や `length` プロパティまでがユニオンに含まれてしまい、意図した文字列リテラル型にはならない。だからこそ、配列の数値添字すべてを一度に射影できる `[number]` が不可欠なのだ。
—
3. イベントループとV8エンジンにおける実行時最適化の恩恵
この手法が優れているのは、型安全性の担保にとどまらない。「単一の真実の源泉（Single Source of Truth）」をコードベースに強制できるため、実行時のメモリ効率とV8エンジンの最適化にも直結する。
実行時のメモリフットプリント削減
しばしば、以下のような冗長なコードを見かける。
// アンチパターン：値と型が乖離し、メモリ上でも重複が生じる
const ROLES = [‘admin’, ‘editor’, ‘viewer’] as const;
type Role = ‘admin’ | ‘editor’ | ‘viewer’; // 二重管理
この二重管理は、リファクタリング漏れの温床になるだけでなく、バンドルサイズを無駄に肥大化させる。`typeof ROLES[number]` を用いることで、値の配列自体がランタイムにおける唯一のデータ実体となり、JavaScriptのヒープメモリ上でも無駄な重複オブジェクトを生成せずに済む。
さらに、V8エンジンは `as const` によってイミュータブルとみなされた配列リテラルをイニシャライザの段階で凍結し、Hidden Class（隠しクラス）の最適化対象とする。これにより、プロパティアクセスやイテレーション処理がJITコンパイラ（TurboFan）によって極限までインライン展開される。
—
4. 応用：より複雑なメタプログラミングへの拡張
この `as const` と `[number]` のイディオムを応用すれば、より高度な設定値の導出や、ランタイムのバリデーションスキーマとの完全な型同期が可能になる。
// 設定オブジェクトの配列から、許可されたペイロードのユニオンを動的に生成する
const API_ENDPOINTS = [
{ method: ‘GET’, path: ‘/api/v1/users’ },
{ method: ‘POST’, path: ‘/api/v1/users’ },
{ method: ‘DELETE’, path: ‘/api/v1/posts/:id’ },
] as const;
// パスのユニオン型を抽出
type ApiPath = (typeof API_ENDPOINTS)[number][‘path’];
// 評価結果: “/api/v1/users” | “/api/v1/posts/:id”
// 特定のメソッドに絞り込んだパスの抽出（条件付き型との組み合わせ）
type MethodPaths
Extract<(typeof API_ENDPOINTS)[number], { method: M }>[‘path’];
type PostPaths = MethodPaths<'POST'>;
// 評価結果: “/api/v1/users”
このコードでは、オブジェクトの配列から `[number]` で各要素をバラし、さらにプロパティアクセス（`[‘path’]`）を連鎖させている。コンパイラは内部の型プールでこれらを一瞬で解決し、開発者のIDEには即座に補完候補としてサニタイズされたユニオンが表示される。
—
結び：型はランタイムの「影」ではない
未熟なプログラマーは、型を「コードを書くときだけのエラーチェッカー」だと考える。しかし、シニアアーキテクトにとって、TypeScriptの型システムは「実行時コードの構造的正確性を証明するための数学的証明器」である。
`keyof` と `typeof`、そして `as const` のコンビネーションをマスターすることは、単に記述量を減らすテクニックにとどまらない。それは、コンパイラのAST評価モデルと、JavaScriptランタイムのメモリレイアウトを完全に調和させ、「バグが入り込む余地を物理的に消去したアーキテクチャ」を構築するための必須教養なのだ。
今日のビルドから、無駄な型のハードコーディングを排除せよ。真のコードは、常に値と型が完璧な調和（Single Source of Truth）を奏でている。