【テクニカル・上級編】 Readonly – TypeScript実践ガイド

Readonlyの幻想と、現場のTypeScriptアーキテクチャ

フロントエンドの規模が肥大化し、状態管理が複雑怪奇を極めると、我々を最も悩ませる悪夢は何だろうか？
そう、「意図しないミューテーション（状態変異）」だ。

Reduxのreducerでうっかりstateを直接いじってしまい、ReactのVDOM差分検出がバグり散らかす。あるいは、APIクライアントから返ってきた不変であるべきレスポンスオブジェクトを、下流のコンポーネントが勝手に書き換えてしまい、画面のあちこちで表示が矛盾を起こす……。
こういう「深夜のデバッグ大会」を、君も一度や二度、いや、エンジニア人生で数え切れないほど経験してきたはずだ。

TypeScriptの `Readonly` は、こうした不毛なバグを防ぐための最も身近な防壁である。しかし、公式ドキュメントに書いてあるような「プロパティを読み取り専用にします」というお題目だけを信じて実務のコードベースに放り込むと、痛い目を見る。

今日のテーマは、この `Readonly` を単なる「型安全のおまもり」で終わらせず、ブラウザのメモリ効率、フレームワークのレンダリング最適化、そして非同期処理の競合回避という「現場のリアルな戦場」でどう武器として使い倒すかだ。
ギークな視点から、その深層を紐解いていこう。

—

コンパイル時の幻影：JavaScriptランタイムとメモリ効率の現実

まず、大前提として心に刻んでおかなければならない事実がある。
`Readonly` は、コンパイル時（TypeScriptの型チェック時）にのみ存在する「幻影」である。

JavaScriptのランタイムにトランスパイルされた瞬間、`Readonly` は綺麗さっぱり消え去る。オブジェクトが `Object.freeze()` されるわけでもなければ、V8エンジン上で読み取り専用のメモリセグメントに配置されるわけでもない。

type User = {
id: number;
name: string;
};

// コンパイル時はエラーになるが…
const user: Readonly = { id: 1, name: ‘Alice’ };
// user.name = ‘Bob’; // Error: Cannot assign to ‘name’ because it is a read-only property.

// ランタイム（JS）では普通に書き換えが可能
(user as { name: string }).name = ‘Bob’;
console.log(user.name); // ‘Bob’ (平然と書き換わる)

「じゃあ、意味ないじゃん」と思ったそこの君。待ってほしい。
TypeScriptの真価は、ランタイムの保護ではなく、開発者の認知負荷の軽減と、IDEによる早期バグ検知にある。

しかし、もしあなたが「絶対にランタイムでも書き換えられたくない、堅牢なデータ構造を作りたい」と考えるなら、`Readonly` だけでは不十分だ。
V8エンジンのガベージコレクタやメモリ効率の文脈において、不変性（Immutability）を担保するためには、型システムとランタイムの保護（`Object.freeze` や `structuredClone`）を組み合わせるアーキテクチャ設計が必要になる。

—

ネストしたオブジェクトの罠：浅い（Shallow）イミュータビリティの限界

`Readonly` の最大の実用上の罠は、それが「シャロー（浅い）」であるという点だ。
つまり、トップレベルのプロパティしか読み取り専用にしてくれない。

type DeepUser = {
id: number;
profile: {
address: {
city: string;
};
};
};

type ReadonlyUser = Readonly;

const john: ReadonlyUser = {
id: 1,
profile: {
address: {
city: ‘Tokyo’,
},
},
};

// これはちゃんとコンパイルエラーになる
// john.id = 2;

// しかし、ネストしたプロパティはスルーされてしまう！
john.profile.address.city = ‘Osaka’; // おっと、書き換えられてしまった！

大規模なフロントエンドアプリケーションでは、APIレスポンスは深くネストしたJSONツリーであることが多い。
この浅い `Readonly` を使っているだけでは、巨大なステートツリーの深部でいつの間にかミューテーションが発生し、Reactなどのフレームワークが「あれ、参照が変わってないから再描画しなくていっか」と誤認し、UIがスタックする致命的なバグを踏むことになる。

解決策：DeepReadonlyの自作と、型パターンの極み

これを防ぐには、再帰的なユーティリティ型、通称 `DeepReadonly` を定義するのがシニアの常套手段だ。

// 再帰的にすべてのプロパティをReadonlyにする型
export type DeepReadonly = T extends (infer R)[]
? ReadonlyArray>
: T extends Function
? T
: T extends object
? { readonly [K in keyof T]: DeepReadonly }
: T;

// 使用例
type SafeUser = DeepReadonly;

const safeJohn: SafeUser = {
id: 1,
profile: {
address: {
city: ‘Tokyo’,
},
},
};

// トップレベルも、ネストした深部も、すべてコンパイル時に完璧にガードされる
// safeJohn.profile.address.city = ‘Osaka’; // Error!

この `DeepReadonly` をドメインモデルやAPIクライアントの返り値の型に適用するだけで、コードベース全体の安全性は劇的に跳ね上がる。

—

非同期の競合と、状態管理（State Management）におけるアーキテクチャ

SPA（Single Page Application）のアーキテクチャにおいて、非同期通信（PromiseやObservable）と状態管理の競合は頭痛の種だ。
例えば、ユーザーがボタンを連打したことで、同一の非同期リクエストが複数走り、古いレスポンスが新しいレスポンスを上書きしてしまう「レースコンディション（競合状態）」は実務で頻発する。

ここで `DeepReadonly` をストア（Redux、Zustand、あるいは独自のカスタムフックによる状態管理）の型定義に組み込むことで、「コンポーネント側から勝手に状態を書き換える不届き者」を物理的に排除できる。

// Zustandなどのストア定義を想定
interface AppState {
readonly currentUser: DeepReadonly | null;
readonly isLoading: boolean;
// 状態の更新は必ず専用のセッター（アクション）を経由させる強制力を持たせる
fetchUser: (id: number) => Promise;
}

データフローを一方向に強制する（Unidirectional Data Flow）上で、`Readonly` は強力なコンパイラレベルの強制力として機能する。
「誰がどこでこの状態を変えたんだ？」という泥沼のデバッグ作業から、君を解放してくれる最後の砦なのだ。

—

レンダリング最適化（Reactなど）との蜜月関係

最後に、フレームワークのパフォーマンス最適化の文脈に触れておこう。
Reactの `React.memo` や、VueのComputed properties、SolidJSのリアクティブシステムなど、現代のモダンフロントエンドフレームワークは「参照の同一性（Reference Equality）」をベースに無駄な再レンダリングを削ぎ落としている。

イミュータビリティが担保されているデータ構造（つまり `Readonly` や `DeepReadonly` によって守られ、変更時は必ず新しいオブジェクトをシャローコピーして生成する構造）であれば、比較アルゴリズムは `===`（参照比較）だけで済む。

もしデータがミュータブル（可変）であれば、変更を検知するために深いツリーの走査（Deep Equality Check）が必要になり、CPUに甚大な負荷をかけることになる。これはブラウザのメインスレッドをブロックし、Jank（カクつき）の原因となる。

つまり、`Readonly` を適切に使いこなすことは、単なる型安全の追求だけでなく、ブラウザのメインスレッドの負荷を最小限に抑え、フレームワークのレンダリングパフォーマンスを限界まで引き出すための「低レイヤーに直結したアーキテクチャ戦略」なのだ。

—

まとめ

TypeScriptの `Readonly` は、一見すると地味なユーティリティ型に思えるかもしれない。
しかし、その限界（シャローであること）を知り、`DeepReadonly` へと昇華させ、ランタイムの特性やフレームワークのレンダリングメカニズムと結びつけて運用できた時、それはあなたのコードベースを圧倒的に堅牢で高速にする最強のアーキテクチャ武器へと変わる。

公式マニュアルを読んだだけで満足するな。
型システムの裏側にあるJavaScriptの挙動とメモリの世界に思いを馳せながら、より洗練されたコードを書き続けよう。

ハッピー・コーディング。