型判定の沼：なぜ「たかが `typeof`」でプロダクションが落ちるのか
フロントエンドのアーキテクチャがどれほど洗練されていようとも、アプリケーションの根底にあるのは「データ」と、それをさばくJavaScriptの泥臭い現実だ。
特に「型判定」という、一見すると入門書の最初に出てくるような初歩的なトピック。これを甘く見たがために、本番環境で突然の `TypeError` が走り、Sentryの通知音に夜中たたき起こされた経験はないだろうか？ 私はある。何度もね。
JavaScriptの型システムは、その歴史的経緯と、V8などのJSエンジンが裏でやっている最適化（隠れクラスやインラインキャッシュなど）の都合上、一筋縄ではいかない。今回は、自前で書いた「ナイーブな型判定」と、`lodash.is` や `is.js` といった歴戦のライブラリが提供するメソッドの裏側を、メモリ効率、ブラウザの実行コンテキスト、そして実務での生存戦略という観点から徹底的に解剖しよう。
—
1. `typeof` と `instanceof` の限界：V8の裏側とiframeの罠
まず、JavaScriptのプリミティブな型判定がいかに「信用ならないか」をおさらいする。
`typeof null` が `’object’` を返すのは、JavaScript史における最も有名な不具合（初期実装の型タグのビット表現に起因するもの）であり、今更直すと世界中のWebサイトが壊れるため永遠に修正されない。また、配列も、正規表現も、日付も、すべて `typeof` にかければ `’object’` だ。これでは実務で使えない。
では、`instanceof` はどうか？
// アプリケーションコード
const isMyArray = myData instanceof Array;
一見正しそうに見える。しかし、お前たちのアプリケーションが、単一のグローバルコンテキストだけで動いているとでも？
例えば、iframeを多用するウィジェット型アーキテクチャや、Micro Frontendsで複数の異なるオリジン・realm（大域実行環境）から渡ってきたオブジェクトを判定する場合、`instanceof` は無残に裏切る。
各 `iframe` は独自の `Array` コンストラクタ（つまり別の `window.Array`）を持っている。別コンテキストで作られた配列は、親ウィンドウの `Array.prototype` を共有していないため、`[] instanceof window.parent.Array` は `false` になるのだ。
プロダクションでの正しい「素の判定」：`Object.prototype.toString.call`
フレームワークやライブラリに頼らず、ネイティブで最も信頼できるのは、あの有名な `Object.prototype.toString` を借用する方法だ。
function getExactType(value) {
// [object TypeName] という文字列から型名だけを抽出する
// Symbol.toStringTag を持つカスタムオブジェクトにも対応させる現代的アプローチ
const stringified = Object.prototype.toString.call(value);
return stringified.slice(8, -1).toLowerCase();
}
console.log(getExactType([])); // ‘array’
console.log(getExactType(null)); // ‘null’
console.log(getExactType(/regex/)); // ‘regexp’
しかし、このアプローチをそのまま自前で何千回もループの中で呼び出すのは、パフォーマンス（特にメモリ割り当てとGCの観点）において褒められたものではない。文字列操作や正規表現、あるいはプロパティアクセスが毎度発生するためだ。
—
2. ライブラリ（lodash.is等）の内部実装とパフォーマンスのリアル
「じゃあ、`lodash` 使っとけば安心だな！」と思ったそこの君。半分正解で、半分は思考停止だ。
`lodash` の型判定メソッド（`_.isArray`, `_.isPlainObject`, `_.isDate` など）は、長年コミュニティで踏まれてきた地雷原をすべて避けて通れるように作られている。しかし、それらが「魔法のように速い」わけではない。
lodashの巧妙な最適化と現実
例えば、`lodash` の `isPlainObject` の実装を覗いたことがあるだろうか？ プレーンなオブジェクト（`{}` や `new Object()` で作られたもの）を判定するのは、実はJavaScriptにおいて非常にコストが高い。
// lodashの内部思想に近いプレーンオブジェクト判定の概念コード
function isPlainObject(value) {
if (value === null || typeof value !== ‘object’) {
return false;
}
// プロトタイプチェーンの終端チェック
const proto = Object.getPrototypeOf(value);
if (proto === null) {
return true; // Object.create(null) のケース
}
// コンストラクタのチェック（iframeを跨いだオブジェクト対策も含む）
const Ctor = Object.prototype.hasOwnProperty.call(proto, ‘constructor’) && proto.constructor;
return typeof Ctor === ‘function’ && Ctor instanceof Ctor && Function.prototype.toString.call(Ctor) === Function.prototype.toString.call(Object);
}
この判定、めちゃくちゃ重い。
プロトタイプチェーンを辿り、コンストラクタの文字列表現を比較する（`Function.prototype.toString` を使うのは、別のコンテキストで作られたObjectコンストラクタを検知するためだ）という処理は、V8のインラインキャッシュ（IC）を激しく汚染する可能性がある。
ベンチマークの罠
「ライブラリのメソッドは最適化されているから速い」というのは神話だ。
個別のユーティリティをインポートする場合（`import isPlainObject from ‘lodash.isplainobject’` など）、バンドルサイズは最小限に抑えられるが、もしバリデーションロジックの中でこれを毎秒数万回呼び出すような設計にしていれば、V8のJITコンパイラは最適化を諦め、メガモフィック（多態的）な状態に陥る。
フレームワークのレンダリングループや、巨大なリアクティブストアの差分検出（Diffing）の最中に、重い型判定を挟むのはアーキテクチャ上の自殺行為だ。
—
3. 堅牢なWebアプリケーションのためのアーキテクチャ戦略
では、我々シニアエンジニアはどのように型判定と向き合うべきか？
実務で破綻しないための3つの鉄則を授けよう。
規約 1: 「境界（Boundary）」で型を確定させ、内部では信じ抜け
APIレスポンス、URLクエリ、ユーザー入力などの「外部世界」から入ってくるデータは、すべて型不明の汚染されたデータとして扱え。
ここでこそ `Zod` や `Valibot`、あるいは厳密なカスタム型ガード関数を使い、データの境界（Network Boundary）で一度だけパースと型チェックを行え。
import { z } from ‘zod’;
// スキーマ定義による厳格な境界防衛
const UserSchema = z.object({
id: z.string().uuid(),
age: z.number().int().positive(),
});
// 境界を通過したデータは、以降のアプリケーション内では「型安全」であり、
// 無駄な runtime の型チェック（typeof や lodash）を排除できる。
function processUser(rawInput: unknown) {
const result = UserSchema.safeParse(rawInput);
if (!result.success) {
// 早期リターンまたはエラーハンドリング
throw new ValidationError(result.error);
}
// ここから先は純粋なTypeScriptの型が保証され、余計なランタイムコストがかからない
const user = result.data;
updateUI(user.age);
}
アプリケーションの内部ロジックで毎度 `_.isObject()` や `typeof` を多用している時点で、アーキテクチャの設計ミス、あるいは「境界でのバリデーション放棄」を疑うべきだ。
規約 2: ホットパス（Hot Path）での重い判定を避ける
アニメーションのフレーム内、無限スクロールのスクロールイベント、大量のリストを描画する仮想スクロールの計算内など、パフォーマンスが命取りになる「ホットパス」で型判定をしてはならない。
どうしても必要な場合は、判定結果をメモ化するか、データの構造自体をフラットに保つこと。オブジェクトの形状（Hidden Class）を維持し、V8がインラインキャッシュを効かせやすいコードを書くのがシニアの流儀だ。
規約 3: 自前実装するなら「ユースケースを絞る」
汎用的なライブラリは、あらゆるエッジケース（iframe、古いIEの残滓、カスタムオブジェクト）を考慮しているため、コード量が多くなりがちだ。
もし、あなたのアプリケーションが特定のコンテキストしか持たず、iframeも使わない、JSONのシリアライズ・デシリアライズされたデータしか扱わないのであれば、過剰な汎用性を持つ巨大なライブラリをインポートする必要はない。
// アプリケーションの要件に特化した、高速かつ最小限の型ガード
export const isObject = (val) => val !== null && typeof val === ‘object’;
export const isArray = Array.isArray; // ネイティブが最速
これで十分だ。無駄な抽象化は、バンドルサイズを肥大化させるだけでなく、脳内のメンタルモデルをも複雑にする。
—
まとめ
型判定とは、単なる「JavaScriptの仕様の穴埋め」ではない。
それは、「信頼できない外部の世界」と「信頼したい内部の世界」の境界線をどこに引き、メモリとCPUのコストをどこに配分するかという、極めて高度なアーキテクチャの意思決定なのだ。
「なんとなく `lodash` を入れておく」「とりあえず `typeof` で凌ぐ」というフェーズはもう卒業しよう。V8の挙動を愛し、データの流れる境界を見極め、アプリケーションの心臓部を真に堅牢なコードで満たしてほしい。
コメント