constがもたらす幻想と、V8ヒープの深層：オブジェクトの可変性が「隠しクラス」を破壊するメカニズム
JavaScriptの開発現場において、`const`の登場は変数宣言のセマンティクスを劇的に変えた。「再代入不可」という強固な制約は、コードの意図を明確にし、予期せぬバグの温床となる副作用を排除するための防壁として機能している。
しかし、シニアエンジニアやランタイムの挙動に精通したアーキテクトであれば、誰もが知っているはずだ。`const`が担保するのはあくまで「変数のバインディング（参照先）」の固定であって、その指し示すオブジェクトの「内部状態（State）」の不変性ではない。
この「参照の不変性」と「状態の可変性」の乖離は、単なる言語仕様の理解にとどまらない。V8エンジンのJITコンパイル、インラインキャッシュ（IC）、そしてオブジェクトの物理構造である「隠しクラス（Hidden Class / Map）」の最適化機構において、致命的なパフォーマンス劣化を引き起こすトリガーとなり得るのだ。
本稿では、`const`で宣言されたオブジェクトに対するプロパティの動的変更が、V8のメモリ空間と実行パイプラインにどのような地殻変動をもたらすのか。その低レイヤの真実を、ランタイムの内部挙動とともに解き明かしていく。
—
1. `const`の正体：レキシカル環境とバインディングの不変性
まず、言語仕様（ECMAScript Specification）の観点から`const`を再定義する。
`const`で宣言された識別子は、環境レコード（Environment Record）内における「バインディング」のイミュータビリティを強制する。V8の内部実装において、スコープが生成される際、レキシカル環境（Lexical Environment）には変数名とメモリアドレス（あるいはポインタ）の対応表が構築される。
`const`はこの対応表の書き換えを静的（かつ動的）に禁止する。
const serverConfig = {
port: 3000,
host: ‘127.0.0.1’
};
// これは SyntaxError または TypeError になる（再代入の禁止）
// serverConfig = { port: 8080, host: ‘0.0.0.0’ };
しかし、`serverConfig`という変数名が保持しているのは、ヒープメモリ（Heap Memory）上に確保されたオブジェクト実体への「参照（メモリポインタ）」に過ぎない。オブジェクトのプロパティを書き換えるコードは、ポインタ自体の値を変更するのではなく、ポインタが指し示すヒープ領域のデータを書き換えているだけである。そのため、以下のコードは何のエラーも発生せずに実行される。
// プロパティの変更はエラーにならない
serverConfig.port = 8080;
console.log(serverConfig.port); // 8080
ここに、多くの開発者が陥る「`const`を使っているからこのオブジェクトは安全（イミュータブル）だ」という致命的な誤解がある。
—
2. V8の心臓部：隠しクラス（Hidden Class / Map）とインラインキャッシュ
では、この「`const`で固定された変数の中にある、可変なオブジェクトのプロパティ変更」は、V8エンジンの実行時最適化において何を意味するのだろうか。
動的型付き言語であるJavaScriptでは、C++やJavaのように「構造体のオフセット（メモリ上の位置）」をコンパイル時に静的に決定することができない。通常の動的言語であれば、プロパティアクセスは毎回ハッシュマップのルックアップ（O(1)とはいえ高コスト）が必要になる。
この絶望的なオーバーヘッドを解決するためにV8が導入したのが「隠しクラス（V8用語では `Map` と呼ばれる構造）」である。
隠しクラスの遷移と「デオプティマイゼーション」
V8は、オブジェクトにプロパティが追加・削除されるたびに、その構造を表す「隠しクラス」を動的に生成し、オブジェクトのメタデータとしてアタッチする。
// 1. 空のオブジェクト生成（Map 0）
const packet = {};
// 2. ‘type’プロパティ追加（Map 1へ遷移）
packet.type = ‘SYN’;
// 3. ‘payload’プロパティ追加（Map 2へ遷移）
packet.payload = 0x00;
インラインキャッシュ（IC）は、この隠しクラスの構造（オフセット）を記憶することで、次回のプロパティアクセスをハッシュルックアップなしの「メモリオフセットの直接参照（Megamorphic/Monomorphic な高速パス）」へと昇格させる。これがV8の超高速JITコンパイル（TurboFan）の根幹を支えている。
しかし、ここで`const`オブジェクトの「可変性」が牙をむく。
function processPacket(packet) {
// V8はこのアクセスを最適化し、特定の隠しクラス（Map）を前提としたマシン語を生成する
return packet.payload;
}
const req = { type: ‘ACK’ };
processPacket(req); // ここでICが「reqはMap Aの構造を持つ」と学習する
// — 別の場所で、後からプロパティが動的に追加される —
req.payload = 0x01; // reqの隠しクラスが Map A から Map B へ強制遷移！
processPacket(req); // 再びprocessPacketが呼ばれたとき、隠しクラスのミスマッチが発生！
この瞬間、V8のエンジン内では「デオプティマイゼーション（Deoptimization：最適化の破棄）」が発生する。JITコンパイルされた高速な機械語（Machine Code）は捨てられ、ランタイムはインタプリタ（Ignition）または低速なベースラインコンパイル済みの状態へとフォールバックする。
`const`で参照をガチガチに固定していても、その内部でプロパティの動的な追加・削除・型変更が横行していれば、V8のメモリ空間上ではオブジェクトの形状（Shape）がめまぐるしく変わり、CPUキャッシュ効率は最悪の状態に陥るのだ。
—
3. イミュータブル設計：V8のポテンシャルを極限まで引き出す作法
シニアエンジニアが目指すべきは、`const`という「文法上の安心感」に酔うことではなく、V8の隠しクラスを安定させ、インラインキャッシュをヒットさせ続けるコードベースの構築である。
そのためには、以下の3つの鉄則をアーキテクチャレベルで強制する必要がある。
1. オブジェクトの形状を初期化時に完全に定義する（Constructor Pattern）
オブジェクトを生成する際は、後からプロパティを動的に追加するのではなく、初期化の段階ですべてのキーを（必要であれば `undefined` や `null` を初期値として）定義し、隠しクラスの遷移パスを一本化（Monomorphic）する。
// 【アンチパターン】隠しクラスが頻繁に遷移し、ICが汚染される
const userA = {};
userA.name = ‘Alice’;
userA.age = 30;
// 【推奨パターン】同一のコンストラクタまたはファクトリ関数を通り、同一の隠しクラスを維持する
class User {
constructor(name, age) {
this.name = name; // 常に同じ順序、同じプロパティで初期化
this.age = age;
}
}
const userB = new User(‘Bob’, 25);
2. オブジェクトの凍結（`Object.freeze`）のコストとトレードオフ
「本当に不変にしたい」のであれば、`const`ではなく`Object.freeze()`を用いるべきだ。
const immutableConfig = Object.freeze({
host: ‘localhost’,
port: 8080
});
// 厳格モード（strict mode）ではTypeErrorが発生し、非厳格でも値は変更されない
immutableConfig.port = 9000;
ただし、V8の低レイヤの観点から注意すべき点がある。`Object.freeze()`は、V8に対して「このオブジェクトの構造と値は今後一切変更されない」という強力なヒントを与える。V8はこれを検知してさらなる最適化（定数畳み込みなど）を行う場合がある一方で、オブジェクトにフラグを設定するためのメタデータ操作コストが発生する。
極めてパフォーマンスがシビアなホットパス（Hot Path）では、むやみに`Object.freeze`を乱用するのではなく、「設計規約としてプロパティを変更しない（Mutateしない）」ことを徹底しつつ、イミュータブルなデータ構造の更新には構造的共有（Structural Sharing）のパターンを採用するのがプロフェッショナルのアプローチである。
—
4. セキュリティの深層：プロトタイプ汚染とランタイム防壁
`const`による参照固定の限界と、オブジェクトの可変性がもたらすリスクは、パフォーマンスの領域にとどまらない。悪意ある攻撃者がサプライチェーンを突いてコード実行（RCE）を誘発する「プロトタイプ汚染（Prototype Pollution）」の脆弱性も、まさにこの「JavaScriptのオブジェクトの可変性」を根幹としている。
以下の脆弱なマージ関数を考えてほしい。
function merge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
merge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
もし、攻撃者が外部APIやJSONパースを経由して、以下のような悪意あるペイロードを送り込んだとしたらどうなるか？
{
“__proto__”: {
“isAdmin”: true
}
}
`merge`関数が再帰的に実行される過程で、`target.__proto__`、すなわちすべてのオブジェクトのプロトタイプである `Object.prototype` に `isAdmin = true` が書き込まれてしまう。
const maliciousPayload = JSON.parse(‘{“__proto__”: {“isAdmin”: true}}’);
const userConfig = {};
merge(userConfig, maliciousPayload);
// なんと、何の関係もない空のオブジェクトですら isAdmin が true になる！
const innocentUser = {};
console.log(innocentUser.isAdmin); // true ！！
`const`でどれほど厳重に変数を保護していようとも、ランタイム全体で共有されているプロトタイプチェーンの根底が書き換えられてしまえば、アプリケーションのセキュリティモデルは一瞬で崩壊する。
防御の極意：ランタイムの硬化（Hardening）
この脆弱性からランタイムを守るためには、オブジェクトの可変性を言語レベルで封じ込める必要がある。
1. プロトタイピングの凍結
アプリケーション起動時に、コアとなるグローバルプロトタイプを凍結する。
Object.freeze(Object.prototype);
Object.freeze(Array.prototype);
Object.freeze(Function.prototype);
これにより、万が一プロトタイプ汚染の攻撃コードが実行されても、V8は不変領域への書き込みエラー（またはサイレント無視）を発生させ、システムへの侵入を防ぐことができる。
2. 安全なマージ・パースの採用
ユーザー入力を扱う際は、`__proto__`, `constructor`, `prototype` といった危険なキーの代入を完全に弾くバリデーションを挟むか、Mapオブジェクトを活用してプロトタイプチェーンを持たないデータ構造を選択する。
—
5. 結言
`const`は魔法の杖ではない。それは単に「変数への再代入を防ぐための構文上の制約」に過ぎない。
シニアエンジニアとして、またシステムアーキテクトとして私たちが直視すべきは、その向こう側にあるV8エンジンの実世界——ヒープメモリの割当、隠しクラスの遷移、インラインキャッシュの明暗、そしてオブジェクトの可変性が内包するパフォーマンスとセキュリティのリスクである。
言語の仕様の表層に惑わされることなく、ランタイムの物理的な挙動を脳内で完全にトレースし、最適化された、そして堅牢なコードを紡ぎ出すこと。それこそが、真にJavaScriptを掌握したエンジニアの境地である。