constの欺瞞：V8の隠しクラスとイミュータビリティの境界線
JavaScriptにおいて `const` は「定数」を定義するキーワードとして初学者のうちに教えられる。しかし、シニアエンジニアやランタイムの挙動に精通した者であれば、それが大いなる誤解であることを知っている。`const` が保証するのは「変数バインドの不変性（Immutability of Binding）」であって、「値そのものの不変性（Value Immutability）」ではない。
特にオブジェクトを `const` で宣言した際、そのプロパティが平然と書き換え可能であるという事実は、単なる言語仕様の挙動に留まらない。V8エンジン内部のメモリレイアウト、JITコンパイルにおけるインラインキャッシュ（Inline Caching）、そして「隠しクラス（Hidden Classes / Maps）」の遷移メカニズムに深く直結している。
本稿では、`const` の背後でV8がどのようにメモリを割り当て、オブジェクトの構造変化をハンドリングしているのか、その物理的実態を解き明かす。さらに、この仕様の隙をついたプロトタイプ汚染（Prototype Pollution）が、いかにしてモダンなNode.jsサプライチェーンを揺るがし、リモートコード実行（RCE）へと繋がるのか、その攻撃ベクターの深層まで踏み込んで解説する。
—
1. `const` の本質：バインドの固定とメモリ上の実態
まずはJavaScriptの字句解析（Lexical Analysis）とスコープのレイヤーから確認する。`const`、`let`、`var` は、環境レコード（Environment Records）における変数の扱いを決定づける。
`const` で宣言された識別子は、宣言されたスコープ内での再代入が禁止される。これは、V8のパーサーがAST（抽象構文木）を生成する段階で静的に検証され、違反すれば SyntaxError または TypeError がスローされる。
// バインドの不変性の例
const serverConfig = {
port: 8080,
host: ‘127.0.0.1’
};
// これはエラーになる：変数 ‘serverConfig’ が指すメモリ上のアドレス（参照）の書き換えは禁止
// TypeError: Assignment to constant variable.
serverConfig = { port: 3000, host: ‘0.0.0.0’ };
// しかし、これは成功する：オブジェクト自体の内部状態（プロパティ）の変更
serverConfig.port = 3000;
console.log(serverConfig.port); // 3000
なぜこのコードがエラーにならないのか？ それは、`serverConfig` という変数がスタック領域（あるいはレジスタ）に保持しているのは「オブジェクト本体」ではなく、「ヒープメモリ上に存在するオブジェクトへのポインタ（メモリアドレス）」だからである。`const` がロックしているのは、このポインタの値そのものであり、ポインタが指し示す先のヒープ領域の保護には一切関与しない。
—
2. V8エンジンの内部機構：隠しクラス（Hidden Classes / Maps）とプロパティの動的変更
JavaScriptは動的型付き言語であり、C++やJavaのように「クラス定義に基づいた固定のメモリレイアウト」をコンパイル時に確定できない。そのままではプロパティにアクセスするたびにハッシュマップ検索が発生し、パフォーマンスが致命的に低下する。
この問題を解決するため、V8は隠しクラス（内部的には `Map` と呼ばれる構造）という概念を導入した。
隠しクラスの遷移（Transitions）
オブジェクトに新しいプロパティが追加されるたび、V8は元の隠しクラスから新しい隠しクラスへの「遷移エッジ」を作成し、オブジェクトのプロパティオフセット（メモリー内の物理的な位置）をマッピングし直す。
以下のコードを見てみよう。
function createUser(name, role) {
this.name = name;
this.role = role;
}
const user1 = new createUser(‘Alice’, ‘Admin’);
const user2 = new createUser(‘Bob’, ‘User’);
V8の視点から、このコードの実行と隠しクラスの生成プロセスを追跡する。
1. `user1` が生成された瞬間、空の隠しクラス（例：`Map 0`）から、`name` プロパティを持つ `Map 1`、さらに `role` プロパティを持つ `Map 2` へと遷移する。
2. `user2` が生成される際、同じコンストラクタを経由することで、V8は `user1` と全く同じ隠しクラス（`Map 2`）を共有させる。これにより、インラインキャッシュ（IC）が効き、プロパティアクセスがC++の構造体メンバアクセス並みに高速化される。
`const` オブジェクトのプロパティ変更がもたらす最適化の破壊
ここで、冒頭の「`const` で定義されたオブジェクトのプロパティ変更」がV8のエンジンに与える影響が浮き彫りになる。
const user = { id: 1, name: ‘Alice’ }; // Map A
// 後から動的にプロパティを追加
user.permissions = [‘read’, ‘write’]; // Map A から Map B への強制的な遷移が発生
`user` は `const` で宣言されているため、変数のバインドはガチガチに固定されている。しかし、後から `.permissions` を追加した瞬間、V8のヒープ上では以下のようなイベントが発生する。
1. オブジェクトのインラインプロパティ領域が溢れ、バックストア（プロパティを格納する別領域の配列）の拡張または再割り当てが走る。
2. オブジェクトが保持する隠しクラスのポインタが `Map A` から新しく動的生成された `Map B` に書き換わる。
3. これまでこのオブジェクトに対して最適化されていたJITコード（TurboFanによる機械語）が無効化され（Deoptimization）、型フィードバックベクターが再構築される。
つまり、「`const` だから安全で最適化されている」という思い込みは幻想であり、オブジェクトの構造を動的にいじるコードは、V8の最適化パイプラインに対して常にコスト（Deoptのペナルティ）を支払わせているのだ。
—
3. プロトタイプ汚染（Prototype Pollution）とサプライチェーンの脆弱性
`const` が「値の不変性」を担保しないという言語仕様、およびJavaScriptのプロトタイプベースの継承メカニズムは、セキュリティ上の巨大なアキレス腱となり得る。それがプロトタイプ汚染（Prototype Pollution）である。
現代のNode.jsエコシステムにおいて、ネストされたオブジェクトのマージ処理（例：`lodash.merge` や深層クローン関数）の実装ミスを突くことで、全てのオブジェクトの根源である `Object.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;
}
この関数に、以下のような悪意あるJSONペイロード（またはパースされたオブジェクト）を入力したとする。
const maliciousPayload = JSON.parse(‘{“constructor”: {“prototype”: {“isAdmin”: true}}}’);
const targetObj = {};
vulnerableMerge(targetObj, maliciousPayload);
このマージ処理が実行されると、何が起きるか？
1. ループの中で `key` が `constructor` になり、さらにそのプロトタイプである `Object.prototype` にアクセスする。
2. 結果として、グローバルな `Object.prototype.isAdmin = true` が汚染される。
3. この瞬間、アプリケーション内で新しく生成される、あるいは既存のあらゆるプレーンオブジェクトが、意図せず `isAdmin: true` を継承してしまう。
// アプリケーション内の全く関係ない箇所で…
const regularUser = { name: ‘Guest’ };
// プロトタイプチェーン経由で汚染されたプロパティが露出する
if (regularUser.isAdmin) {
// 認証バイパス（RCEや権限昇格への足がかり）
grantAdminAccess(regularUser);
}
`const` はプロトタイプ汚染を防げるか？
ここで重要な洞察は、オブジェクトを `const` で宣言していようが、Object.prototypeの汚染の前には無力であるという点だ。
`const` はあくまで「その識別子が別のオブジェクトを指すこと」を防ぐだけであり、プロトタイプチェーンの上下関係や、祖先のプロパティが書き換えられる事象には干渉できない。V8のメモリ空間において、すべてのオブジェクトは暗黙的に `Object.prototype` へのポインタ（`__proto__`）を隠し持っており、この基盤そのものが書き換えられた場合、ランタイム上のすべての安全神話が崩壊する。
—
4. 極限の防御：ランタイムの防壁を構築する
では、こうしたV8の動的性質と脆弱性のリスクに対抗し、真の堅牢性を手に入れるにはどうすればよいか。シニアアーキテクトとして実践すべき具体的な防御策を提示する。
1. `Object.freeze()` による物理的なイミュータビリティの強制
バインドの固定ではなく、オブジェクト自体のプロパティ変更を不可能にしたい場合は、`Object.freeze()` を用いる。
const secureConfig = Object.freeze({
port: 8080,
host: ‘127.0.0.1’
});
// 厳格モード（strict mode）下では TypeError が発生し、非厳格モードでも変更は無視される
secureConfig.port = 3000;
console.log(secureConfig.port); // 8080 のまま
V8内部の挙動：
`Object.freeze()` が呼び出されると、V8はそのオブジェクトの隠しクラスを「拡張不可能（Non-extensible）」かつ「設定不可・書き込み不可（Non-configurable, Non-writable）」のフラグが立った状態に遷移させる。これにより、JITコンパイラ（TurboFan）は「このオブジェクトのプロパティは今後絶対に変化しない」という強烈な仮定（Stability Assumption）を置くことができ、プロパティアクセスを完全にインライン展開・定数畳み込み（Constant Folding）の最適化対象にできる。セキュリティとパフォーマンスの両面において最強の布陣となる。
2. プロトタイプ汚染に対する根本的対策（Nullプロトタイプの活用）
ユーザー入力や外部からのJSONをパース・処理する際、`Object.prototype` の汚染を完全に無効化する最も確実な方法は、プロトタイプを持たないオブジェクトを作成することである。
// 継承を持たない純粋なハッシュマップの作成
const safeDictionary = Object.create(null);
console.log(safeDictionary.__proto__); // undefined
console.log(safeDictionary.toString); // undefined
`Object.create(null)` で生成されたオブジェクトには `Object.prototype` が存在しない。そのため、どれほど悪意のあるペイロードが渡されようとも、`__proto__` や `constructor.prototype` を経由したグローバルな汚染の連鎖を物理的に断ち切ることができる。
Node.jsのバックエンドアーキテクチャ、特にAPIゲートウェイやマイクロサービスのペイロードバリデーション層では、辞書データやマップとして使用するオブジェクトに原則として `Object.create(null)` を強制すべきである。
—
結びにかえて
`const` はJavaScriptにおける可読性と意図の明確化において不可欠な構文だが、その挙動をランタイム（V8）のメモリ管理やセキュリティの文脈から切り離して捉えることは、重大なバグや脆弱性を生む温床となる。
- `const` はバインドを固定するだけであり、オブジェクトのミュータビリティは保証しない。
- 動的なプロパティの追加はV8の隠しクラスを混乱させ、JITの最適化（Deoptimization）を引き起こす。
- プロトタイプ汚染は `const` の防壁を軽々と飛び越え、ランタイム全体を乗っ取る。
言語の仕様の表層に捉われることなく、V8のヒープ構造、隠しクラスの遷移、そしてメモリ上のポインタの動きを脳内でトレースできるか否か。それこそが、凡百のプログラマと、システムを極限まで掌握する真のチーフアーキテクトを分かつ境界線である。