やあ。フロントエンドの最前線で戦う君たちへ。
今日は、TypeScriptにおける「縁の下の力持ち」、`Record
新人研修やチュートリアルサイトでは「オブジェクトを作るための便利なユーティリティ」と一言で片付けられがちだけど、実務の現場でこいつをどう使いこなすか、あるいは「なぜあえて使わない判断をするのか」という線引きこそが、シニアと中級者を分ける境界線だったりするんだ。
肩の力を抜いて聞いてくれ。
—
Record とは何か？その「実体」を暴く
まず、技術的な定義を再確認しよう。`Record
// 定義を覗いてみると、実はこれだけの記述なんだ
type Record
[P in K]: T;
};
単純だろ？ `keyof any` は `string | number | symbol` を指す。つまり、「何らかのキー集合に対して、特定の型を持つ値を割り当てる」という行為を、型システム上で宣言しているに過ぎない。
なぜこれが「強力」なのか
現場でよく遭遇する「APIからのレスポンスをマッピングする」といったケースにおいて、この型は極めて強力だ。例えば、特定のステータスコードに応じたメッセージを管理するようなケースを見てみよう。
type StatusCode = ‘200’ | ‘404’ | ‘500’;
// Recordを使えば、キーの漏れを許さない堅牢な辞書が作れる
const statusMessages: Record
‘200’: ‘Success’,
‘404’: ‘Not Found’,
‘500’: ‘Server Error’,
};
// もしキーが足りないと、TypeScriptは即座にコンパイルエラーで止めてくれる
// これこそが、ランタイムエラーを未然に防ぐ「型」の恩恵だ
—
現場で直面する「落とし穴」
だが、ここからが本題だ。`Record` には、現場のエンジニアを苦しめる「特有の挙動」がある。
1. キーが「存在しない」可能性を無視しがち
`Record
const userRoles: Record
// コンパイラは「stringが返る」と信じているが、実行時にはundefinedの可能性がある
const role = userRoles[‘guest’];
console.log(role.toUpperCase()); // ランタイムエラー！「undefinedのtoUpperCaseは呼べない」
実務では、`Record
2. 「薄い型」で満足してはいけない
中級者によくあるのが、何でもかんでも `Record
実務で差がつく！現場のプラクティス
では、どう書くのが「正解」に近いのか。一つの指針を示そう。
/
- 特定のIDをキーに、ユーザー情報を保持するテーブル構造
- Recordを使うことで、検索の高速化と型の整合性を両立できる
/
type User = { id: string; name: string; email: string };
// キーをstringとするのではなく、IDのブランド型や特定のユニオン型にするのがコツ
type UserMap = Record
const users: UserMap = {
“u001”: { id: “u001”, name: “Alice”, email: “alice@example.com” },
};
// 安全にアクセスするためのヘルパー関数を用意するのも良い戦略だ
function getUserById(map: UserMap, id: string): User | undefined {
return map[id]; // undefinedを許容する設計にすることで、堅牢性が上がる
}
—
最後に：TypeScriptは「道具」であって「目的」ではない
`Record
- キーが固定されているなら `Record` を使うべき。
- キーが動的で、存在しない可能性が高いなら `Map` や `Partial` を使うべき。
- そもそもオブジェクトである必要があるか？ `Array.find` で済むなら、無理に辞書構造にする必要はない。
ブラウザの裏側では、結局のところただのハッシュマップ（オブジェクト）として処理されているだけだ。その裏側の挙動を想像しながら、型システムという「守護霊」をどう使いこなすか。
君たちのコードが、明日もバグなく、誰にとっても読みやすいものであることを願っている。もし行き詰まったら、またいつでも聞きに来てくれ。プロフェッショナルの現場は、そうやって議論しながら最適解を見つけていくものなんだから。
それじゃ、コードに戻ろうか。健闘を祈る。
コメント