コードレビューをしていて、最も頻繁に遭遇する誤解の一つがこれだ。
> 「`const`で宣言しているから、このオブジェクトはイミュータブル（不変）であり、安全だ」
結論から言おう。`const`は何のイミュータブル性も保証しない。 保証されているのは「再代入の禁止（Assignment Immutability）」だけであり、メモリ上のヒープ領域に存在するオブジェクトの中身が書き換えられることに対しては、`const`は無力である。
今回は、JavaScriptの変数束縛の裏側と、V8エンジンにおける「隠しクラス（Hidden Class / Map）」の挙動、そしてそれがフロントエンドのパフォーマンスに与える決定的な影響について、チーフアーキテクトの視点から紐解いていく。
—
1. `const`の正体：ポインタの固定とヒープの変質
JavaScriptにおいて、プリミティブ型（`string`, `number`, `boolean`等）は値そのものがコールスタックに保存されるため、`const`による束縛はそのまま値の固定を意味する。
しかし、オブジェクトや配列などの参照型（Reference Types）の場合、変数に格納されているのは「値そのもの」ではなく、ヒープメモリ上のアドレスを指すポインタに過ぎない。
const user = { name: ‘Alice’, role: ‘admin’ };
// これはエラーになる（再代入の禁止）
// user = { name: ‘Bob’, role: ‘user’ };
// だが、これは平然と成功する（プロパティの書き換え）
user.role = ‘guest’;
console.log(user.role); // ‘guest’
`const`が防いでいるのは、`user`という変数に別のオブジェクトの参照を上書きすることだけだ。オブジェクトの内部がどう書き換えられようと、V8のパーサーとランタイムは文法エラーを出さない。これが「`const`＝不変」という誤解の正体である。
—
2. V8エンジンの「隠しクラス（Hidden Class）」と最適化の破壊
では、`const`で守られた（つもりの）オブジェクトのプロパティを後から自由に変更すると、V8エンジン内部では何が起きているのか？ ここからが本題だ。
JavaScriptは動的言語であり、C++やJavaのようにコンパイル時にオブジェクトのメモリレイアウト（構造）が確定しない。このままではプロパティにアクセスするたびにハッシュルックアップが発生し、実行速度が致命的に遅くなる。
これを解決するため、V8は「隠しクラス（Hidden Class / 内部的には Map と呼ばれる）」という概念を導入している。
1. シェイプの特定: オブジェクトが生成されると、V8はそのプロパティの構造（プロパティ名とオフセットの順序）を表す「隠しクラス」を割り当てる。
2. インラインキャッシュ（IC）: 同じ隠しクラスを持つオブジェクトへのアクセスは、メモリ上のオフセットが固定されるため、C++並みの高速なプロパティアクセスが可能になる。
動的なプロパティ追加・削除が引き起こす「最適化のロールバック」
ここで、実務でやりがちな「後からのプロパティ追加」のコードを見てみよう。
// 【アンチパターン】動的にプロパティを追加・変更するコード
function createUser(name) {
const user = {}; // 空のオブジェクトで初期化
user.name = name; // 隠しクラス C0 → C1 へ遷移
if (/ 条件分岐 / true) {
user.active = true; // 隠しクラス C1 → C2 へ遷移
} else {
user.permissions = [];
}
return user;
}
このコードを実行すると、V8のヒープ内では隠しクラスの動的な遷移ツリーが生成される。もし、コードの実行パスによってプロパティの追加順序や構造がバラバラになると、V8のインラインキャッシュはヒットしなくなり、メガモーフィック（Megamorphic）と呼ばれる最悪の状態に陥る。
結果として、JITコンパイラ（TurboFan）による最適化がリセットされ、ガベージコレクション（GC）の負荷が跳ね上がり、メインスレッドのブロッキング（フレームレートの低下）を引き起こす。これが、オブジェクトの構造を動的にいじることの真のコストだ。
—
3. 堅牢かつハイパフォーマンスな設計：オブジェクトの「形状固定」
では、実務のフロントエンド開発やAPI連携において、どう設計すべきか。答えは「オブジェクトの形状（Shape）を生成時に完全に固定し、後からの動的な追加・削除を一切行わないこと」だ。
TypeScriptの型定義や`Object.freeze`（※開発時のみ、本番の過剰な適用はパフォーマンスに影響するため注意）を活用し、イミュータブルなデータフローを構築する。
以下に、実務のプロダクションコードで即座に使える、堅牢でV8フレンドリーな設計パターンを示す。
【プロダクションコード例】形状が保証されたファクトリ関数とイミュータブル更新
/
- @typedef {Object} UserProfile
- @property {string} id
- @property {string} name
- @property {string} role
- @property {boolean} isActive
/
/
- ユーザーオブジェクトの「形状」を完全に固定して生成するファクトリ関数。
- これによりV8は単一の隠しクラスを維持し、インラインキャッシュを最大限に最適化する。
- @param {string} id
- @param {string} name
- @param {string} role
- @param {boolean} isActive
- @returns {UserProfile}
/
function createProfile(id, name, role, isActive) {
return {
id,
name,
role,
isActive
// オブジェクトリテラルのプロパティ順序とキーを絶対に後から崩さない
};
}
/
- イミュータブルに状態を更新するヘルパー関数
- スプレッド構文を使用しつつ、新しいオブジェクトでも形状を完全に一致させる。
- @param {UserProfile} profile
- @param {Partial
} updates - @returns {UserProfile}
/
function updateProfile(profile, updates) {
// 常に同じキーの順序とセットを持つ新しいオブジェクトを返す
return {
id: profile.id,
name: updates.name !== undefined ? updates.name : profile.name,
role: updates.role !== undefined ? updates.role : profile.role,
isActive: updates.isActive !== undefined ? updates.isActive : profile.isActive,
};
}
// — 使用例 —
// 1. 初期化（隠しクラス確定）
const initialUser = createProfile(‘usr_01’, ‘Taro Engineering’, ‘developer’, true);
// 2. 更新（新しいオブジェクトを生成するが、V8の隠しクラスは同一のものが再利用される）
const updatedUser = updateProfile(initialUser, { role: ‘architect’ });
console.log(updatedUser);
// 出力: { id: ‘usr_01’, name: ‘Taro Engineering’, role: ‘architect’, isActive: true }
この設計がもたらすメリット
1. V8の最適化維持: すべてのインスタンスが全く同じプロパティの順序とキーを持つため、V8は同一の隠しクラスを共有し、プロパティアクセスが高速化される。
2. 予測可能なデータフロー: リアクティブなUIフレームワーク（ReactやVueなど）において、参照の変更（`initialUser !== updatedUser`）が確実に行われるため、不要な再レンダリングやバグを防げる。
3. メンテナンシビリティ: 「どこでどのプロパティが後から追加されたか」を追う必要がなくなり、コードベースの認知負荷が劇的に下がる。
—
チーフアーキテクトからの提言
コードレビューで `const user = {}; user.name = …;` というコードを見かけたら、こう問いかけてほしい。
> 「そのオブジェクト、V8の隠しクラスを何回遷移させているか知っているか？」
モダンなJavaScriptを書くということは、単に動くコードを書くことではない。言語のランタイム仕様とメモリモデル（V8の挙動）に敬意を払い、ハードウェアの能力を限界まで引き出すコードを書くことだ。
`const`は魔法の盾ではない。真の堅牢性とパフォーマンスは、開発者自身による「オブジェクトの形状の美しさへのこだわり」によってのみもたらされる。次のスプリントから、君のコードベースの「形状」を最適化しよう。