constの幻想とV8の物理現実：イミュータブルな設計の限界とプロトタイプ汚染の深層
JavaScriptエンジニアの多くが最初に犯す誤解の1つが、「`const`で宣言された変数はイミュータブル（不変）である」という神話だ。
結論から言えば、`const`は値の不変性を保証するものではない。`const`が強制するのは「変数束縛（Variable Binding）の再代入不可」という、極めて限定的な構文上の制約に過ぎない。V8エンジンをはじめとするモダンJSランタイムのメモリ空間において、`const`が指し示す実体が何であるかを理解していないならば、あなたの書くコードは常に予期せぬ状態変化とセキュリティリスクの隣り合わせにある。
本稿では、V8のヒープアロケーションと隠しクラス（Hidden Class / Map）の物理最適化の観点から`const`とオブジェクトの可変性を解剖し、さらにはその脆弱性がサプライチェーン攻撃におけるリモートコード実行（RCE）にどう結びつくのか、ランタイムの防壁を突破・防御する極限の知見を共有する。
—
1. V8エンジンのメモリ空間における `const` とポインタの真実
まず、JavaScriptの変数がメモリ上でどのように扱われているかを低レイヤから見直そう。
V8エンジンにおいて、プリミティブ型（数値や文字列など）の変数は多くの場合、即時値（SMI: Small Integer）としてスタック上にインライン化されるか、ポインタを介してヒープ上の不変な領域を指す。そのため、`const a = 42;` と書いた場合、`a`への再代入はV8のパーサーおよびバイトコード生成器（Ignition）の段階で静的に弾かれる。
しかし、オブジェクトや配列の場合、変数が保持しているのは「オブジェクトそのもの」ではなく、V8のヒープメモリ空間上に確保されたインスタンスへの「メモリアドレス（ポインタ）」である。
// constで宣言された定数オブジェクト
const serverConfig = {
host: ‘127.0.0.1’,
port: 8080
};
// これはエラーになる（変数束縛への再代入）
// serverConfig = { host: ‘0.0.0.0’, port: 9000 };
// しかし、プロパティの書き換えは完全に成功する
serverConfig.port = 3000;
console.log(serverConfig.port); // 3000
なぜこれが許されるのか？ Ignitionが生成するバイトコードや、最適化コンパイラ（TurboFan）が推論する型フィードバックにおいて、`const`は「変数が指すアドレスの変更禁止」を意味するだけであり、そのアドレスが指すヒープ領域のメモリ保護を行っているわけではないからだ。TurboFanは、プロパティの書き換えを「インラインキャッシュ（IC）」を更新する通常のストア命令として高速に処理する。
—
2. `Object.freeze()` の限界：シャロー（浅い）凍結とV8の隠しクラス最適化
では、オブジェクト自体の書き換えを防ぎたい場合はどうすればいいのか。多くの開発者は `Object.freeze()` を選択する。だが、ここにもV8のアーキテクチャに起因する重大な罠と限界が存在する。
const deepConfig = Object.freeze({
app: {
name: ‘CoreService’,
env: ‘production’
}
});
// トップレベルの変更は防がれる（厳格モードではTypeError）
deepConfig.app = null;
// ── 致命的な罠 ──
// ネストされたオブジェクトは凍結されていないため、書き換えが可能
deepConfig.app.env = ‘development’;
console.log(deepConfig.app.env); // ‘development’
V8の隠しクラス（Hidden Class / Map）とフリーズのコスト
JavaScriptはプロトタイプベースの動的言語であり、C++のような静的構造体を持たない。そのため、V8はオブジェクトのプロパティ構造を効率的に追跡するために「隠しクラス（内部的には `Map` と呼ばれる）」を動的に生成する。
`Object.freeze()` を呼び出すと、V8はそのオブジェクトの内部フラグを「拡張不可（Non-extensible）」「設定不可（Non-configurable）」「書き込み不可（Non-writable）」に書き換える。これに伴い、V8の最適化エンジンは当該オブジェクトを「辞書モード（Dictionary Mode）」にフォールバックさせたり、インラインキャッシュの最適化パスから外したりすることがある。
つまり、やみくもな `Object.freeze()` の多用は、V8のJITコンパイルにおける最適化の恩恵をスポイルし、メモリ消費量とGC（ガベージコレクション）のオーバーヘッドを増大させるという、パフォーマンス上のトレードオフを伴うのだ。
—
3. プロトタイプ汚染（Prototype Pollution）とRCEの危険水域
オブジェクトの可変性がもたらす最悪の脅威が、プロトタイプ汚染（Prototype Pollution）である。これは、`const`や`Object.freeze()`の概念すら木端微塵に砕き、アプリケーション全体を乗っ取る高度な脆弱性ハックの温床となる。
攻撃者は、再帰的なオブジェクトのマージ処理（Deep Merge）やクエリパラメータのパース処理の不備を突き、言語の根幹である `Object.prototype` や `Array.prototype` を書き換える。
// 脆弱なマージ関数のシミュレーション
function vulnerableMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
vulnerableMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// 悪意あるペイロードの注入
const maliciousPayload = JSON.parse(‘{“__proto__”: {“polluted”: “RCE_RISK_DETECTED”}}’);
const safeObj = {};
vulnerableMerge(safeObj, maliciousPayload);
// 全てのオブジェクトのプロトタイプが汚染される
const innocentObj = {};
console.log(innocentObj.polluted); // ‘RCE_RISK_DETECTED’
サプライチェーンからRCEへの飛躍
この汚染がなぜ恐ろしいのか。Node.jsのバックエンド環境において、テンプレートエンジン、ORM、ルーター、あるいは子プロセスを生成する `child_process.exec()` のオプションオブジェクトが、知らず知らずのうちにプロトタイプを継承している場合がある。
攻撃者が `Object.prototype` に `shell` や `execArgv` といった特定のプロパティを注入することに成功した場合、正当なコードが内部で設定オブジェクトを参照した瞬間に、意図しないシステムコマンドがV8のランタイムプロセスからホストOSへとスパンされ、リモートコード実行（RCE）へと直結する。`const`でどれだけ変数を固めようとも、ランタイムのプロトタイプチェーンそのものが書き換えられていれば、防御壁は完全に無力化される。
—
4. イミュータブルな設計の限界を突破するベストプラクティス
では、我々アーキテクトはどのようにしてこの不可変性の幻想と戦うべきか。実務において採用すべき極限の防衛策を提示する。
① ディープフリーズの実装（再帰的凍結）
もし小〜中規模の不変設定を安全に扱いたい場合は、自前でディープフリーズ用のユーティリティ関数を実装し、ビルド時や初期化時に一度だけ実行する。
function deepFreeze(obj) {
// オブジェクトのプロパティ名を取得
const propNames = Object.getOwnPropertyNames(obj);
// プロパティが持つオブジェクトも凍結する
for (const name of propNames) {
const value = obj[name];
if (value && (typeof value === ‘object’ || typeof value === ‘function’)) {
deepFreeze(value);
}
}
return Object.freeze(obj);
}
② プロトタイプ汚染の根絶（Null Prototypeの活用）
辞書オブジェクト（ハッシュマップ）としてオブジェクトを使用する場合、`Object.prototype` を継承しないオブジェクトを作成するのが最も確実な防衛策だ。
// プロトタイプを持たない純粋なハッシュマップの生成
const safeDictionary = Object.create(null);
// __proto__ による汚染が物理的に不可能になる
safeDictionary[‘__proto__’] = ‘safe’;
console.log({}.polluted); // undefined
③ モダンな言語仕様（Records & Tuples）の視野
TC39のステージ3（※環境による）に位置する Records and Tuples は、JavaScriptに真のイミュータブルなプリミティブ値（構造的等価性を持つオブジェクトや配列）をもたらす革命的な提案である。将来的にこれが標準化されれば、`const`の曖昧さに頼る必要性は劇的に減少する。
—
結びにかえて
`const` は魔法の盾ではない。それは単なる「変数の再代入防止フィルター」に過ぎない。
V8エンジンのメモリ構造、隠しクラスの動的変化、そしてプロトタイプチェーンの仕組みを深く理解しているシニアエンジニアであれば、言語の表面的な構文に惑わされることはないはずだ。可変性と不変性の境界線を正確にコントロールし、ランタイムの足元をすくわれない堅牢なアーキテクチャを構築してほしい。コードの安全性を担保するのは、フレームワークの機能ではなく、あなたの低レイヤへの深い洞察力そのものなのだから。