配列の要素型を動的に取得する：Indexed Access Typesの極限応用
コードレビューをしていて、もっとも頭痛がする瞬間の一つがこれだ。
// ❌ やりがちなアンチパターン：リテラル型や定数の「二重管理」
const ROLES = [‘admin’, ‘editor’, ‘viewer’] as const;
// わざわざ手動で型を切り出している（つもりになっている）
type Role = ‘admin’ | ‘editor’ | ‘viewer’;
function handleRole(role: Role) {
// …
}
おいおい、待ってくれ。`ROLES` という「真実のソース（Single Source of Truth）」がコードの片方にあるのに、なぜ人間が手動でユニオン型をタイポの危険を冒しながら再定義しているんだ？もし将来 `’moderator’` が追加されたとき、人間が両方を同時に書き換える保証はどこにある？保証など存在しない。だからバグが生まれるのだ。
TypeScriptを真に掌握するエンジニアであれば、型は「書くもの」ではなく、値や既存の構造から「導出するもの」だと知っているはずだ。
今回は、配列の型定義から自由自在に要素型を抽出し、DRY原則を極限まで高める Indexed Access Types（インデックスアクセス型） の実践的な応用パターンを、プロダクションコードの文脈で叩き込む。
—
1. Indexed Access Types の基本メカニズム
TypeScriptのIndexed Access Typesは、JavaScriptのプロパティアクセス構文（`obj[key]`）を型空間に持ち込んだものだ。
配列（あるいはタプル）に対してこれを行う場合、数値のインデックス型（`number`）や特定の数値リテラルを指定する。
const CONFIGS = [
{ retries: 3, timeout: 1000 },
{ retries: 5, timeout: 3000 },
] as const;
// 配列自体の型から要素の型を抽出する
type ConfigItem = typeof CONFIGS[number];
// 評価結果: { readonly retries: 3; readonly timeout: 1000; } | { readonly retries: 5; readonly timeout: 3000; }
ここで `typeof CONFIGS` は readonly なタプル型を返す。そのタプル型に対して `[number]` でアクセスすることで、「その配列に格納されうるすべての要素のユニオン型」がコンパイラによって動的に評価・生成される。これがすべての基礎だ。
—
2. 実務の現場で直面する：非同期API・コンポーネント設計の応用パターン
では、これをフロントエンド開発やAPI連携の実務でどう応用するのか。ありがちな「甘い設計」と、プロフェッショナルな設計を比較しよう。
シナリオ：ステータス管理とテーブルコンポーネントの型安全な結合
バックエンドから取得するステータス定義や、UIで表示するカラム定義の配列があるとしよう。これをコンポーネントのプロパティに安全に流し込む設計を考える。
❌ 非効率で脆弱な設計
// 散らばった型定義とリテラル
type UserStatus = ‘ACTIVE’ | ‘INACTIVE’ | ‘SUSPENDED’;
interface TableColumn {
key: string;
label: string;
}
const USER_STATUSES: UserStatus[] = [‘ACTIVE’, ‘INACTIVE’, ‘SUSPENDED’];
const COLUMNS: TableColumn[] = [
{ key: ‘name’, label: ‘名前’ },
{ key: ‘status’, label: ‘ステータス’ },
];
これの何が問題か？ `COLUMNS` の `key` が `’name’` や `’status’` というただの `string` に落ちているため、実態のデータ構造と完全に遊離している。コンポーネントの引数でタイポしてもコンパイラは何も守ってくれない。
🚀 完璧なプロダクションコード：Indexed Access Typesによる完全自動同期
/
- 1. 真実のソース（Single Source of Truth）を定数として定義し、as const で凍結する
/
const TABLE_CONFIG = [
{ field: ‘id’, label: ‘ID’, sortable: true },
{ field: ‘name’, label: ‘ユーザー名’, sortable: true },
{ field: ‘role’, label: ‘権限’, sortable: false },
{ field: ‘lastLoginAt’, label: ‘最終ログイン’, sortable: true },
] as const;
/
- 2. 配列の型から、行データのキーやカラム設定の型を動的に導出する
/
// カラム設定のオブジェクト型そのもの
type TableColumn = typeof TABLE_CONFIG[number];
// 許可されたフィールド名のユニオン型 (‘id’ | ‘name’ | ‘role’ | ‘lastLoginAt’)
type TableField = TableColumn[‘field’];
// 特定のフィールドの設定だけを抽出する高度なテクニック
type ExtractColumn
Extract
// 例: ‘role’ カラムの設定型は { readonly field: “role”; readonly label: “権限”; readonly sortable: false; } になる
type RoleColumnDef = ExtractColumn<'role'>;
/
- 3. 導出された型をフル活用するコンポーネント関数
/
function renderCell
field: TField,
// 条件付き型とIndexed Accessを組み合わせ、フィールドに応じた厳密な値の型を強制することも可能
value: unknown
): void {
// 実装ロジック…
console.log(`Rendering field [${field}] with value:`, value);
}
// 使用例
const targetField: TableField = ‘name’; // OK
// const invalidField: TableField = ‘age’; // ❌ コンパイルエラー: Type ‘”age”‘ is not assignable to type ‘TableField’.
このアプローチの強みは、`TABLE_CONFIG` の配列要素を1つ追加・削除・変更するだけで、そこから派生するすべての型（`TableField`, `ExtractColumn` など）がコンパイル時に自動再計算される点にある。人的ミスが入り込む隙間が一切ない。
—
3. パフォーマンス上の注意点とTypeScriptコンパイラの裏側
「型を動的に複雑に計算しすぎると、IDE（VSCode）のレスポンスやビルド速度（tsc）が落ちるのではないか？」
鋭い指摘だ。チーフアーキテクトとして、この懸念には明確に答えておく必要がある。
1. `as const` の多用によるメモリ消費:
`as const` をつけると、プリミティブ型ではなく「リテラル型」としてメモリ上に型のツリーが保持される。数千行に及ぶ巨大なJSONや配列に `as const` を貼ると、型チェッカーのメモリ消費量が増加し、IDEでのホバー表示が重くなる原因になる。
- 対策: UIの設定値やステータス定義など、人間が認知できる規模（数十〜数百件程度）の配列に限定して使うこと。数万件のデータ構造の型をこれで解決しようとしてはいけない（それはそもそもDBやAPIの責務だ）。
2. 型評価のキャッシュ（Type Deepening）:
TypeScript 4.x以降、コンパイラの型チェックアルゴリズムは非常に洗練されている。今回紹介した `typeof ARR[number]` のような基本的なIndexed Accessは、コンパイラ内部で高度に最適化されるため、パフォーマンスのボトルネックになることはまずない。
—
テクニカルリードからの総括
コードの保守性を下げる最大の悪因は「同じ意味を持つ情報を、複数の場所に手動で書き散らすこと」だ。
今回紹介した Indexed Access Types を用いた配列の要素型抽出は、単なる小手先のテクニックではない。「値の構造を型に奉仕させるのではなく、値の構造から型を完全に従属させる」という、堅牢なアーキテクチャ設計の基本思想そのものだ。
今日からあなたのプロジェクトにある「手動で書かれたユニオン型や設定の型定義」を見直してほしい。そして、`typeof … [number]` に置き換え、コードベースをより一層「自己防衛的」で美しいものに昇華させてくれ。