コードレビュー：その `string` 型のパス指定、本当に安全ですか？
プルリクエストを見ていると、こんなコードにしばしば遭遇する。
// よくある実装：引数が単なる string なのでタイポし放題
function getValue(obj: any, path: string): unknown {
return path.split(‘.’).reduce((acc, key) => acc?.[key], obj);
}
「汎用的で便利だから」と `path: string` を放置していないだろうか。これでは `user.addres.zip` とタイポしてもコンパイラは沈黙し、実行時に `TypeError: Cannot read properties of undefined` が爆誕する。型安全の恩恵を自ら捨てて、テストコードや本番のクラッシュに怯える日々を送るのはもう終わりだ。
今回は、TypeScriptの Template Literal Types と 再帰的条件型（Recursive Conditional Types） を極限まで駆使し、ネストしたオブジェクトのキーパスをコンパイル時に完全に静的解析する「型安全なパス抽出エンジン」の設計思想を伝授する。
—
1. 核心に迫る：なぜ再帰的テンプレートリテラル型なのか？
TypeScript 4.1で導入された Template Literal Types は、文字列の結合だけでなく、推論（`infer`）と組み合わせることで、型レベルの「パーサー」として機能する。
オブジェクトの深さが不規則である以上、パスの検証は再帰（Recursion）で解くほかない。つまり、コンパイラの型評価器の上で以下のようなアルゴリズムを回すのだ。
1. オブジェクトの現在の階層のキーを列挙する。
2. ドット (`.`) で結合した文字列の組み合わせ（Union型）を再帰的に生成する。
3. ユーザーが入力したパスが、生成されたUnion型の中に存在するかをコンパイル時に突き合わせる。
これを実装したプロダクションコードを見ていこう。
—
2. プロダクションコード：型安全なパス抽出・値取得エンジン
以下のコードは、複雑なネスト構造を持つオブジェクトに対しても、完全な補完と型推論を維持する汎用ユーティリティだ。
/
- 指定されたオブジェクトTから、ドット区切りのパス（例: ‘a.b.c’）のUnion型を再帰的に生成する
/
export type DeepPath
? {
[K in keyof T]: K extends string | number
? T[K] extends Array
? `${K}` | `${K}.${DeepPath
: T[K] extends object
? `${K}` | `${K}.${DeepPath
: `${K}`
: never;
}[keyof T]
: never;
/
- DeepPathで指定されたドット区切りのパスに対応する値の型を逆引きする
/
type DeepValue
? Key extends keyof T
? DeepValue
: never
: P extends keyof T
: T[P]
: P extends `${number}` // 配列のインデックスアクセス対応
? T extends Array
? U
: never
: never;
/
- 実行時関数：型安全にネストしたプロパティを取得する
- @param obj 探索対象のオブジェクト
- @param path DeepPath
によって厳格に制限されたパス文字列
/
export function getNestedValue
obj: T,
path: P
): DeepValue
// 実行時の実装はシンプル。安全性はすべてTypeScriptの型システムがコンパイル時に担保する。
const travel = (target: any, segments: string[]): any => {
if (segments.length === 0) return target;
const [head, …tail] = segments;
return travel(target?.[head], tail);
};
return travel(obj, (path as string).split(‘.’)) as DeepValue
}
—
3. この設計がもたらす圧倒的な開発体験
上記のコードを適用した際、IDE（VSCode等）とコンパイラがどのように振る舞うかを確認しよう。
// — テスト用の複雑なドメインモデル —
interface UserProfile {
id: string;
name: {
first: string;
last: string;
};
settings: {
theme: ‘dark’ | ‘light’;
notifications: {
email: boolean;
push: boolean;
};
};
roles: string[];
}
const user: UserProfile = {
id: ‘usr_001’,
name: { first: ‘Taro’, last: ‘Yamada’ },
settings: {
theme: ‘dark’,
notifications: { email: true, push: false }
},
roles: [‘admin’, ‘user’]
};
// 【成功例1】IDEがパスの候補を完璧にサジェストする
const theme = getNestedValue(user, ‘settings.theme’);
// 型は ‘dark’ | だが、推論結果として正確に取得できる
// 【成功例2】配列のインデックスや要素にもアクセス可能
const firstRole = getNestedValue(user, ‘roles.0’); // 型: string
// 【コンパイルエラー例】タイポや存在しないパスは即座に弾かれる
// const invalid = getNestedValue(user, ‘settings.notifcations’);
// ❌ 2つのエラー:
// 1. 引数 ‘settings.notifcations’ はパラメータ ‘path’ に割り当てられません。
// 2. タイプ ‘”settings.notifcations”‘ はタイプ ‘DeepPath
開発者はIDEの強力なIntelliSense（補完）の恩恵を受け、キーボードから手を離すことなく正確なパスを選択できる。万が一タイポすれば、CI/CDパイプラインやビルド時にコンパイルエラーとして検知されるため、実行時エラーの可能性をゼロに収束させることが可能だ。
—
4. チーフアーキテクトからの警鐘：パフォーマンス上の注意点
高度な型定義には、必ずコストが伴う。今回の `DeepPath` のような再帰的条件型を設計する上で、以下の実務的なボトルネックに注意してほしい。
① インセプション・リミット（深度制限）への配慮
TypeScriptのコンパイラには、無限再帰を防ぐための内部深度制限（通常50階層程度）が存在する。極端に深く、かつ循環参照を持つような型（例: DOMツリーやORMの自己参照リレーション）に対してこれを適用すると、コンパイラが `Type instantiation is excessively deep and possibly infinite.` エラーを吐いて沈黙する。
- 対策: 汎用的なライブラリ層でこれを実装する場合は、再帰の深さに上限（カウンター型を用いるテクニック）を設けるか、複雑すぎるドメインモデルへの適用を避けるガードを入れること。
② IDEのレスポンス低下（CPU負荷）
巨大なスキーマ（例えば数百のプロパティを持つAPIレスポンス型など）に対して `DeepPath` を全展開させると、言語サーバー（tsserver）のメモリ消費が増大し、エディタのタイピングが重くなる原因になる。
- 対策: プロジェクト全体で使い回す巨大なスキーマオブジェクトに対しては、必要に応じて型をモジュール分割し、型推論のスコープを最小限に絞るよう設計を最適化すること。
—
結びにかえて
「動けばいいや」の `string` 型から脱却し、型システムを極限まで使い倒すこと。それは単なる自己満足ではなく、「変更に強く、バグが入り込む余地のないコードベース」をエンジニアリングで強制するための最高の手法である。
コードレビューで `path: string` を見かけたら、今日の記事を思い出してほしい。「その文字列、型で縛れますよ」と、涼しい顔してリファクタリングを提案してやろう。あなたのチームのコード品質は、そこから確実に一段上のステージへ引き上げられる。