Interfaceの `readonly` と不変性の境界線：コンパイラ保証からランタイム防壁へのアプローチ
TypeScriptの `readonly` 修飾子について、単なる「書き込み禁止の糖衣構文」や「IDEの赤波線を出すためのLint的なもの」と捉えているうちは、この言語の型システムの本質を半分も見落としていると言わざるを得ない。
シニアエンジニアやアーキテクトが対峙すべきは、「型システムにおける静的不変性（Static Immutability）」と「ランタイムにおける動的可変性（Runtime Mutability）」の間に横たわる深い断絶である。TypeScriptのコンパイラはコードをJavaScriptへとトランスパイルする際、`readonly` キーワードを完全に消し去る。生成されるJSコードには、何らのプロパティガードも存在しない。
本稿では、インターフェースにおける `readonly` がコンパイル時評価においてどのように振る舞い、大規模アプリケーションのメモリ最適化やイベント駆動アーキテクチャの安全性にどう寄与するのか、その極限の知見を紐解く。
—
1. コンパイル時保証の本質：型システムにおける「視点の制限」
TypeScriptの `readonly` は、メモリ上のオブジェクトを不変（Immutable）にするわけではない。それは単に、「ある型をとおしてプロパティにアクセスした際の手続き的書き込みを型チェッカーがコンパイル時に拒絶する」という、開発者の視点を縛るための静的アサーションに過ぎない。
以下のコードを見てほしい。
interface SecurePayload {
readonly id: string;
readonly metadata: {
readonly version: number;
flag: boolean;
};
}
function processPayload(payload: SecurePayload) {
// コンパイルエラー: Cannot assign to ‘id’ because it is a read-only property.
// payload.id = “new-id”;
// 【警告】ネストしたオブジェクトの落とし穴
// metadata自体は readonly だが、その中の flag は readonly ではない。
// さらに、metadataオブジェクトそのものの構造は深い階層で書き換え可能。
payload.metadata.flag = false; // <-- これはコンパイルを通過してしまう
}
なぜ `readonly` は「浅い（Shallow）」のか？
TypeScriptの `readonly` はデフォルトで浅い。もし深い不変性（Deep Immutability）を担保したい場合、手動で全ての階層に `readonly` を付与するか、Mapped Typesを用いた再帰的ユーティリティ型（`DeepReadonly
しかし、ここでアーキテクトが考慮すべきは「コンパイル負荷（Type Instantiation Depth）」だ。深すぎる再帰的型評価は、TypeScriptコンパイラ（tsserver）の型推論エンジンに負荷をかけ、IDEのレスポンス低下やCI上のビルド遅延を引き起こす。パフォーマンスと安全性のトレードオフをどこに設定するかは、アーキテクトの腕の見せ所である。
—
2. 構造的型付け（Structural Subtyping）と `readonly` の共変・非共変性
TypeScriptは公称型（Nominal Typing）ではなく構造的型付けを採用している。この性質上、`readonly` 修飾子の有無は型の互換性（Assignability）に厳密な影響を与える。
原則として、「mutable（書き込み可能）な型は、readonlyな型に代入できるが、その逆はできない」。
interface MutableConfig {
endpoint: string;
timeout: number;
}
interface ReadonlyConfig {
readonly endpoint: string;
readonly timeout: number;
}
let mutable: MutableConfig = {
endpoint: “https://api.internal”,
timeout: 5000,
};
// 安全性の証明:
// 読み取り専用を要求する関数や変数に対して、mutableなオブジェクトを渡すことは完全に安全。
// なぜなら、受け取り側は書き込みを行わないことが保証されているからだ。
const strictConfig: ReadonlyConfig = mutable;
// 逆は不可能（コンパイルエラー）
// let broken: MutableConfig = strictConfig;
// 理由: strictConfigをとおして書き込みが行われるリスクを排除するため、コンパイラが遮断する。
この特性を利用すると、外部から受け取った予測不能なオブジェクトを安全にラップし、ドメイン層のコアロジックへ「読み取り専用の防壁」として渡す設計パターンが極めてエレガントに成立する。
—
3. ランタイム防壁とメモリ最適化のパラドックス
前述した通り、`readonly` はランタイムには存在しない。では、セキュリティ上の理由や、マルチスレッド（Web Worker）間、あるいは厳密なイベントループのキュー消費において「絶対に書き換えられたくない」場合はどうすべきか。
ここで、TypeScriptの型システムとJavaScriptのランタイム機能を融合させる必要がある。
`Object.freeze()` との統合
型安全性をコンパイル時に担保しつつ、実行時（Runtime）の改ざんを防ぐには、`Object.freeze()` との型アサーションを組み合わせるのが鉄則である。
// 1. 型定義でコンパイル時の防壁を作る
export interface ImmutableSystemState {
readonly nodeEnv: ‘production’ | ‘development’;
readonly clusterId: number;
}
// 2. ランタイムでオブジェクトの不変性を強制するファクトリ関数
function createSystemState(env: ‘production’ | ‘development’, id: number): ImmutableSystemState {
const state: ImmutableSystemState = {
nodeEnv: env,
clusterId: id,
};
// 実行時におけるプロパティの追加・削除・変更を封じる
// V8エンジン等のJSエンジンに対して、このオブジェクトをfrozenに指定する
return Object.freeze(state);
}
const state = createSystemState(‘production’, 42);
// ランタイムエラー（Strictモード下）または静寂な無視:
// 実行時に値を変えようとすると、TypeError が発生する。
// (state as { clusterId: number }).clusterId = 100; -> Uncaught TypeError: Cannot assign to read only property ‘clusterId’
メモリ最適化の視点：V8 Hidden Classes (Shapes) との対話
現代のJavaScriptエンジン（Google V8など）は、オブジェクトのプロパティ構造（Hidden Class）が変化しないオブジェクトに対して、メモリレイアウトを最適化し、インラインキャッシュ（IC）を効かせることで高速なプロパティアクセスを実現している。
`Object.freeze()` を適用することで、V8はそのオブジェクトが「二度と拡張も変形もされない（Extensible = false, Configurable = false）」ことを確信し、最適化されたメモリ領域（Fast Properties）に固定化する。つまり、`interface` の `readonly` による設計思想と、ランタイムの `Object.freeze()` は、「静的な型安全性の最大化」と「V8ランタイムのメモリ・実行速度の極限化」を同時に達成する最高のペアなのだ。
—
4. イベントループと非同期キューにおける「状態の凍結」
高スループットなNode.jsバックエンドや、複雑なフロントエンドの状態管理（Reduxや独自Fluxアーキテクチャ）において、イベントループのキューに積まれたメッセージ（アクションやペイロード）が、非同期処理の途中で別コンテキストからミューート（改ざん）されるバグは、最も追跡が困難な悪夢の一つである。
ここで `readonly` インターフェースを徹底したアーキテクチャが真価を発揮する。
// イベントオブジェクトの型定義
interface NetworkEvent
readonly timestamp: number;
readonly payload: Readonly
}
class EventDispatcher {
private queue: NetworkEvent
// イベントをキューにエンキュー
public dispatch
// 実行時にも凍結を強制し、非同期処理中の意図しない書き換えを完全に封殺
this.queue.push(Object.freeze({ …event, payload: Object.freeze(event.payload) }));
this.scheduleFlush();
}
private scheduleFlush() {
// マイクロタスク（Promise）またはマクロタスク（setImmediate / setTimeout）での処理
queueMicrotask(() => {
this.flush();
});
}
private flush() {
while (this.queue.length > 0) {
const event = this.queue.shift();
if (!event) continue;
// コンシューマ側で万が一書き換えようとしても、型レベル・ランタイムレベル双方が拒絶する
this.processConsumer(event);
}
}
private processConsumer(event: NetworkEvent
console.log(`Processing event at [${event.timestamp}]:`, event.payload);
// event.payload.foo = “bar”; // <-- コンパイルエラー & ランタイムエラー
}
}
このパターンにより、データフローは完全に「一方向（Unidirectional）」かつ「純粋（Pure）」なものとなり、並行処理（Concurrency）における競合状態（Race Condition）の発生確率を数学的にゼロへと近づけることができる。
—
5. チーフアーキテクトからの提言
TypeScriptの `readonly` は、単なるコーディング規約の補助ツールではない。それは、システム全体のデータフローにおける「責務の境界線」を明確に引くための、極めて強力なアーキテクチャ・プリミティブである。
1. インターフェースの境界では常に `readonly` をデフォルトとする：
特にAPIレスポンス、設定ファイル、イベントペイロードなど、外部から流入するデータや共有されるべきステートは、最初から書き込み権限を剥奪した状態で型を定義すべきだ。
2. 深い不変性（Deep Immutability）が必要な箇所では、ランタイムの防御を怠らない：
型システム（Compile-time）の防壁の向こう側には、必ず `Object.freeze()` などのランタイム（Run-time）の防壁を配置し、言語の隙間を完全に塞げ。
3. 過剰な型エンジニアリングを避ける：
無限に複雑な再帰型でコードを難解にするのではなく、適切なランタイムの不変化ユーティリティとシンプルな `readonly` の組み合わせで、保守性と実行速度のバランスを支配せよ。
コードの信頼性は、偶然の産物ではない。それは、コンパイラの挙動とランタイムのメモリ構造の双方を熟知したエンジニアが、意図的に構築した「防壁の堅牢さ」の総和に他ならない。