幽霊はオブジェクトの中に潜む：なぜ TypeScript で `String` を使うことは「設計の敗北」なのか
現代のフロントエンド開発において、TypeScript は単なる「型の注釈」を超え、静的解析によるランタイム挙動の予測装置として機能している。しかし、依然として多くのシニアエンジニアですら、基本型（Primitive Types）とオブジェクトラッパー型（Wrapper Objects）の境界線を曖昧に捉えている。
「`string` と `String`、どちらでも動くではないか」
もし君のチームにそう嘯く者がいたら、即座にこの記事を読ませるべきだ。これは単なるスタイルの問題ではない。メモリレイアウト、V8エンジンの最適化、そして型システムの健全性に関わる、アーキテクチャの根幹を揺るがす問題である。
—
1. 型の二重性：プリミティブとラッパーの断絶
JavaScript、そしてその上位互換である TypeScript において、`string`（小文字）と `String`（大文字）は全くの別物である。
プリミティブ（`string`, `number`, `boolean`）
これらは「値」そのものである。メモリ上では、スタック領域や定数プールに最適化されて配置される。不変（Immutable）であり、プロパティを持たない。
オブジェクトラッパー（`String`, `Number`, `Boolean`）
これらは `Object` を継承した「インスタンス」である。ヒープ領域に確保され、独自のプロパティを持つことができる。
TypeScript の型システムにおいて、この両者は「割当可能性（Assignability）」において非対称な関係にある。
/
- TypeScript における非対称な割当可能性
/
let primitive: string = “legendary”;
let wrapper: String = new String(“legendary”);
// OK: プリミティブはラッパー型に代入可能（ラッパーはプリミティブのインターフェースを包含するため）
wrapper = primitive;
// Error: ラッパー型はプリミティブに代入不可能
// Type ‘String’ is not assignable to type ‘string’.
// ‘string’ is a primitive, but ‘String’ is a wrapper object.
primitive = wrapper;
// 実行時の型も当然異なる
console.log(typeof “hero”); // “string”
console.log(typeof new String(“hero”)); // “object”
この「小文字は大文字に代入できるが、逆は不可」という挙動こそが、TypeScript コンパイラが我々に送っている最初の警告である。
—
2. V8エンジンの深淵：インラインキャッシュと隠れクラス
なぜ我々は `string`（プリミティブ）を徹底的に選ぶべきなのか。その理由は、V8 や JavaScriptCore といったランタイムエンジンの最適化戦略にある。
オートボクシング（Auto-boxing）の代償
プリミティブに対してメソッド（例: `.toUpperCase()`）を呼び出す際、ランタイムは一時的にラッパーオブジェクトを生成する「オートボクシング」を行う。
「それなら最初から `String` オブジェクトを使えば、生成コストが浮くのではないか？」
否。現代の V8 エンジンは、プリミティブに対するメソッド呼び出しを高度に最適化している。エンジンはラッパーオブジェクトを実際に生成することなく、プロトタイプメソッドを直接実行するショートカットを持っている。
一方で、`new String()` によって明示的に生成されたオブジェクトは、「隠れクラス（Hidden Class）」を汚染する。プリミティブ文字列は V8 内部で「String Interning（文字列の共有）」の対象となるが、オブジェクト化された文字列は個別のヒープメモリを占有し、比較演算（`===`）の際にもポインタ参照ではなく値の全スキャン、あるいは型変換のオーバーヘッドを強制する。
SMI (Small Integer) 最適化の喪失
`number` と `Number` の差はさらに顕著だ。V8 は 31bit（または 63bit）に収まる整数を SMI (Small Integer) として、ポインタのタグビットを利用して直接レジスタで扱う。しかし、`new Number()` を使った瞬間にこの最適化は破棄され、数値はヒープ上の「重い」オブジェクトへと成り下がる。
—
3. 型の安全性とプロトタイプ汚染への防壁
セキュリティ研究者の視点から見れば、`String` や `Number` の使用は、プロトタイプ汚染（Prototype Pollution）の影響を受けやすい脆弱なコードへの入り口になり得る。
プリミティブ型は、その性質上、個別のインスタンスにプロパティを生やすことができない。しかし、オブジェクトラッパーは `Object` であるため、動的なプロパティ追加を許容してしまう。
function processData(input: String) {
// 誰かが String.prototype やこのインスタンスに悪意あるプロパティを仕込んでいたら？
if ((input as any).admin) {
// 意図しない特権昇格のロジックが紛れ込む隙を与える
}
console.log(input.valueOf());
}
TypeScript の `string` 型（小文字）を使用していれば、コンパイラはオブジェクトとしての振る舞いを厳格に禁止する。型システムによる防壁は、ランタイムの安全性を担保するための最小単位である。
—
4. アーキテクトの決断：なぜ「小文字」が絶対なのか
我々が TypeScript を書くのは、JavaScript の動的なカオスに秩序をもたらすためだ。
1. 一貫性の保持: `string` はリテラル `”foo”` の型であり、`String` はグローバルなインターフェース定義である。この混同は、API 定義における「意図しない Nullable」や「期待しないオブジェクト構造」の混入を招く。
2. 型推論の最適化: `const x = “tech”;` と書いた際、TypeScript が推論するのは `string`（またはリテラル型 `”tech”`）である。ここで `String` を介入させることは、コンパイラの推論パスを意図的に複雑にする行為に他ならない。
3. エコシステムとの親和性: ほぼ全ての npm パッケージ、そして TypeScript 標準ライブラリ（lib.d.ts）は、プリミティブ型を前提に設計されている。
唯一の例外？
歴史的な経緯や、リフレクション、あるいは特定のメタプログラミングにおいて `String`（コンストラクタ）を参照することはある。しかし、それは「型」としてではなく「値（クラス）」としての利用に限られる。
// 許容されるケース：クラスのメタデータとして参照する場合
class Entity {
@Column({ type: String }) // これは型ではなく、ランタイムのコンストラクタ関数
name: string; // 型定義は常に小文字
}
—
結論：魂はプリミティブに宿る
シニアエンジニアの責務は、単に動くコードを書くことではない。ランタイムエンジンの鼓動を感じ、メモリの 1 バイト、CPU サイクルの 1 クロックに至るまで、その挙動を掌握することにある。
`string`, `number`, `boolean`。
これらの小文字の型を選択することは、JavaScript という言語が持つ「プリミティブの高速性」を最大限に引き出し、TypeScript の「厳密な型評価」を完遂させるための、最も基本的で最も重要な儀式である。
もし君のコードベースに `String`（大文字）が残っているなら、それは技術負債ではない。設計思想の欠如である。直ちに修正せよ。