【テクニカル・上級編】Interfaceの「readonly」修飾子とImmutabilityの強制：不変データ構造の設計 – TypeScript コア・型システムの基礎解析バイブル

型システムの檻を極めよ：再帰的イミュータビリティとコンパイル時の防御壁

TypeScriptの `readonly` 修飾子。多くのエンジニアはこれを「型安全性向上のためのちょっとした便利機能」と捉えている。だが、大規模システムやメモリ保護が求められるクリティカルなコンテキストにおいて、それは「ランタイムの脆弱性を防ぐためのコンパイル時防壁」である。

今日は、インターフェースにおける `readonly` の限界と、それを突破してネストされた構造まで完全に不変（Immutable）化する、真のアーキテクトのためのテクニックを深掘りする。

—

1. readonly の欺瞞：浅い保護の罠

TypeScriptの `interface` における `readonly` は、あくまでコンパイル時のアサーションに過ぎない。以下のコードを見てほしい。

interface State {
readonly config: {
readonly apiEndpoint: string;
};
}

const state: State = { config: { apiEndpoint: “https://api.example.com” } };

// コンパイルエラー：Cannot assign to ‘apiEndpoint’ because it is a read-only property.
// state.config.apiEndpoint = “malicious-url”;

// しかし、型アサーションやランタイムの自由度により防壁は容易に突破される
(state.config as any).apiEndpoint = “hacked-url”;

なぜこれが起きるのか。TypeScriptの型システムは「構造的部分型（Structural Subtyping）」に基づいている。`readonly` はプロパティの書き込み権限を制限するメタデータに過ぎず、オブジェクトの参照そのものをフリーズ（`Object.freeze`）するわけではないからだ。

コンパイラは「ここには書くな」と警告するが、ランタイムのV8エンジンは、あなたがメモリ上のアドレスを直接操作することを止めてはくれない。

—

2. 再帰的イミュータビリティの実装：DeepReadonly

再帰的イミュータビリティは、単なるプログラミングの趣味ではない。複雑な状態遷移を持つステート管理において、予期せぬサイドエフェクトを根絶するためのアーキテクチャ上の必須事項だ。

以下は、コンパイラの型推論エンジンを酷使し、あらゆるネストを網羅する `DeepReadonly` の実装である。

プリミティブ以外の型を再帰的にreadonly化する

/
type DeepReadonly = T extends Function
? T
: T extends Array
? ReadonlyArray>
: T extends object
? { readonly [P in keyof T]: DeepReadonly }
: T;

interface ComplexConfig {
settings: {
timeout: number;
endpoints: string[];
};
logger: () => void;
}

// すべての階層がreadonlyとなる
const config: DeepReadonly = {
settings: { timeout: 3000, endpoints: [“/a”] },
logger: () => console.log(“log”)
};

// コンパイル時防御：すべての階層が読み取り専用
// config.settings.timeout = 5000; // Error
// config.settings.endpoints.push(“/b”); // Error

なぜこの実装が重要なのか

この型定義は、条件付き型（Conditional Types）とマップ型（Mapped Types）を組み合わせたものだ。コンパイラは `T` を再帰的に辿り、全てのリーフノードまで `readonly` を付与する。これにより、開発者が意図せずネストされた配列の `push()` を呼び出すような、メモリ破壊的行為をコンパイル時に検知できる。

—

3. ランタイムの防壁：メモリ保護とイベントループ

コンパイル時の型は、JSに変換されると消滅する。本気でイミュータビリティを担保するなら、型定義とランタイムの `Object.freeze` をペアにする必要がある。

なぜランタイムで凍結するのか

JavaScriptのイベントループ内において、非同期処理の間にオブジェクトが書き換えられると、予測不能なバグが生じる。特に、Web Workerやクロスコンテキストな通信を行っている場合、メモリが共有されているかのように振る舞う箇所で「書き込み」は最大の脆弱性だ。

`deepFreeze` を適用することで、ランタイムは `TypeError` を投げ、不正な状態遷移を即座に停止させる。これは「Fail-Fast（高速な失敗）」の原則に基づいている。

—

4. アーキテクトの視点：型安全性とパフォーマンスのトレードオフ

「すべてを `DeepReadonly` にすれば最強か？」と言われれば、答えは「否」だ。

1. コンパイル速度への影響: 極端に複雑な再帰型は、TypeScriptの型チェッカー（tsc）のメモリ消費を増大させる。型推論の深さが限界に達すると、プロジェクトのビルド時間は指数関数的に伸びる。
2. 実行時のオーバーヘッド: `Object.freeze` はランタイム最適化を阻害する可能性がある。V8のHidden Class遷移が固定されるため、パフォーマンスに敏感なホットパスでは慎重に使用すべきだ。

結論：型は防壁、ランタイムは砦

TypeScriptの `readonly` は、あなたの意図をコンパイラに伝え、無能なバグを門前払いするための防壁だ。しかし、真に堅牢なシステムを構築するなら、その防壁を突破された後の砦（ランタイムでの不変性）を忘れてはならない。

大規模アーキテクチャにおいて、型は単なるラベルではない。データがシステムを巡る際の「ルール」そのものだ。このルールを掌握した者だけが、制御不能な複雑性から解放された、真のエンジニアリングを手に入れることができる。

さあ、次は君のコードベースで、どの階層が「不変であるべき」かを確認してみる番だ。