constの幻想とV8の肉弾戦：隠しクラスの破壊とイミュータビリティの限界
JavaScriptのコードベースにおいて、`const`の濫用は一種の宗教儀式のようになっている。「再代入できない＝安全である」という短絡的な思考は、大規模アプリケーションのパフォーマンスを静かに蝕む。
シニアエンジニアやコアランタイムを追う者であれば、`const`が保証するのはスタック上のポインタの固定（Bindingのイミュータビリティ）であって、ヒープ上に展開されるデータ構造の不変性ではないことなど百も承知のはずだ。
だが、問題はそこにとどまらない。`const`で縛られたオブジェクトのプロパティを平然と書き換える行為が、V8エンジンのJITコンパイラが命を賭して構築した「隠しクラス（Hidden Classes / Maps）」の最適化パイプラインをどう破壊し、メガモーフィック（Megamorphic）な地獄へと誘うのか。その低レイヤのメカニズムまで踏み込んでいる者はどれほどいるだろうか。
本稿では、`const`の限界を出発点とし、V8のメモリレイアウト、隠しクラスの遷移、そしてそれが引き起こすパフォーマンスの劣化とセキュリティ上のリスク（プロトタイプ汚染に至る文脈）まで、ランタイムの深淵を解剖する。
—
1. `const`の正体：レキシカル環境とポインタの固定
まず、言語仕様のレイから確認しておこう。ECMAScript仕様において、`const`は変数 `Binding`（バインディング）に対するものであり、値そのものに対するものではない。
const systemConfig = {
timeout: 5000,
retries: 3
};
// これはエラーになる（ポインタの再代入の禁止）
// systemConfig = { timeout: 10000, retries: 5 };
// しかし、これは成功する（プロパティの書き換え）
systemConfig.timeout = 10000;
このコードが実行される時、V8のメモリ空間（Heap）では何が起きているのか。
`systemConfig`という識別子は、現在のレキシカル環境（Lexical Environment）の環境レコード（Environment Record）に登録され、その値（スロット）にはヒープ上に確保されたオブジェクト実体へのポインタ（メモリアドレス）が格納される。`const`は、このスロットへの書き込み権限をコンパイル時に剥奪するだけの構文上の制約に過ぎない。
したがって、ポインタの指し示す先にあるオブジェクトの構造を変更することは、JavaScriptの言語仕様上、完全に合法である。しかし、これがV8エンジンの実行時最適化にとっては「悪夢」の始まりとなる。
—
2. V8の隠しクラス（Hidden Classes / Maps）とインラインキャッシュ（IC）の崩壊
動的言語であるJavaScriptでは、オブジェクトのプロパティアクセスは本来、ハッシュマップ的なルックアップ（O(1)〜O(N)のコスト）を必要とする。しかし、これでは毎秒数百万回の操作が要求される現代のWebアプリケーションやNode.jsサーバーを動かすことはできない。
そこでV8は、C++のような静的型付き言語のクラス構造をエミュレートするため、「隠しクラス（内部的には `Map` と呼ばれる）」を動的に生成する。
隠しクラスの遷移（Transitions）
以下のコードを見てほしい。
function createUser(name, role) {
this.name = name;
this.role = role;
}
const userA = new createUser(‘Alice’, ‘Admin’);
const userB = new createUser(‘Bob’, ‘User’);
1. `new createUser(…)` が呼ばれた瞬間、空のオブジェクトに対して隠しクラス `C0` が割り当てられる。
2. `this.name = name` が実行されると、V8は `C0` から新しい隠しクラス `C1` への遷移（Transition）を作成し、プロパティ `name` のオフセット（メモリ上の位置）を記録する。
3. `this.role = role` が実行されると、`C1` から `C2` へ遷移する。
結果として、`userA` と `userB` は同じ隠しクラス `C2` を共有し、V8のインラインキャッシュ（Inline Caches: IC）によって、プロパティアクセスは単なる「メモリのオフセット参照（C言語の構造体アクセスと同等）」に高速化される。
`const`オブジェクトの動的変更がもたらす悲劇
ここで、冒頭の `const` の話に戻る。開発者が「`const`で宣言しているから安全だ」と信じ込み、後から動的にプロパティを追加したり、削除したり、あるいは異なる順序で代入したりするとどうなるか。
const server = {}; // Map C0
// 別のモジュールや条件分岐で後からプロパティを追加
if (process.env.NODE_ENV === ‘production’) {
server.port = 443; // Map C0 -> C1 (port)
server.ssl = true; // Map C1 -> C2 (ssl)
} else {
server.ssl = false; // Map C0 -> C3 (ssl) ！！！
server.port = 80; // Map C3 -> C4 (port) ！！！
}
お気づきだろうか？ プロパティの追加順序が分岐によって異なると、V8は全く異なる隠しクラスのツリー構造を生成してしまう。
同じ `server` という変数（`const`でガチガチに固定されているにもかかわらず！）であっても、実行パスによってV8から見た「オブジェクトの形状（Shape）」が変わり果ててしまうのだ。
これが進行すると、V8のJITコンパイラ（TurboFan）は最適化コードを諦め、遅い汎用的なルックアップ処理へフォールバックする。これがメガモーフィック（Megamorphic）状態である。`const`を使っていようが関係ない。ランタイムの物理最適化層において、オブジェクトの構造変化は毒なのだ。
—
3. 実践：V8の挙動を脳内トレースするコードと最適化の作法
シニアエンジニアとして、私たちはこのV8の特性をハックし、常に「モノモーフィック（Monomorphic）」な状態を維持するコードを書かなければならない。
以下のコードは、オブジェクトの形状を完全にイミュータブル（構造的にも固定）に保ち、V8の隠しクラス遷移を破綻させないための実践的なパターンだ。
‘use strict’;
/
- 良い例: オブジェクトの形状（Shape）をコンストラクタまたは
- 初期化時に完全に確定させ、後からの動的追加・削除を一切行わない。
/
class OptimizedTransaction {
constructor(id, amount, currency) {
// すべてのプロパティを常に同じ順序、同じ初期値（あるいはundefined）で定義する
this.id = id;
this.amount = amount;
this.currency = currency;
this.status = ‘PENDING’; // 状態の変化は値の書き換えであって、構造の変化ではない
}
}
// constでバインディングを固定
const tx1 = new OptimizedTransaction(‘tx_001’, 1000, ‘JPY’);
const tx2 = new OptimizedTransaction(‘tx_002’, 250, ‘USD’);
// 値の書き換えは隠しクラス（Map）の遷移を引き起こさないため、ICは高速にヒットし続ける
tx1.status = ‘COMPLETED’;
console.log(tx1, tx2);
避けるべきアンチパターン：「delete」演算子の呪い
プロパティの削除を行う `delete` 演算子は、V8の最適化にとって最悪のアンチパターンである。
// 絶対にやってはいけないアンチパターン
const payload = { userId: 42, token: ‘secret’, tempToken: ‘xyz’ };
// deleteを使うと、オブジェクトは「辞書モード（Dictionary Mode）」に格下げされる
delete payload.tempToken;
`delete` を実行した瞬間、V8はそのオブジェクトを高速な隠しクラスベースのストレージから、遅いハッシュテーブルベースのストレージ（Dictionary Mode）へと強制送還する。こうなると、いかに `const` で宣言してようが、そのオブジェクトへのアクセスはV8の最適化恩恵から完全に切り離される。
—
4. セキュリティの深層：プロトタイプ汚染（Prototype Pollution）とランタイムの防壁
ここまでの議論はパフォーマンスの話だが、この「オブジェクトの可変性」と「プロトタイプの構造」は、セキュリティにおいて最も危険な脆弱性、プロトタイプ汚染（Prototype Pollution）の根源でもある。
サードパーティ製のライブラリが不安全な深層マージ（Deep Merge）処理を行っている場合、攻撃者はJSONペイロードを操作して以下のようなリクエストを送り込む。
{
“__proto__”: {
“isAdmin”: true
}
}
JavaScriptの動的なプロパティ代入の仕組みをつき、`Object.prototype` そのものが書き換えられると、アプリケーション内のすべてのオブジェクト（`const`で宣言されていろうがなかろうが）がその汚染されたプロパティを継承してしまう。
防御の極限：Object.freeze とランタイムの硬化
このサプライチェーン攻撃に対する決定的な防壁の一つが、`Object.freeze()` である。
const secureConfig = Object.freeze({
apiKey: ‘super-secret-key’,
database: Object.freeze({
host: ‘localhost’,
port: 5432
})
});
// 厳格モード（use strict）下では、変更を試みるとTypeErrorがスローされる
try {
secureConfig.apiKey = ‘hacked’;
} catch (e) {
console.error(‘防御成功:’, e.message);
}
`Object.freeze()` は単なる論理的な不変性の強制ではない。V8エンジン内部において、そのオブジェクトのMapフラグを書き換え、プロパティの書き込み、削除、新規追加をランタイムレベルで完全に封印する。これにより、プロトタイプ汚染や意図しない隠しクラスの遷移を物理的に阻止し、JITコンパイラに対しても「このオブジェクトの構造は永遠に変わらない」という強力なヒントを与えることができる。
—
結言
`const` は魔法の杖ではない。それは単なる文法上の安全装置に過ぎない。
真にセキュアで、V8エンジンのポテンシャルを極限まで引き出すハイパフォーマンスなJavaScript/Node.jsアプリケーションを構築したいのであれば、私たちはコードを書く際につねに以下の問いを持たなければならない。
1. そのオブジェクトの物理的な構造（Shape）は、ライフサイクルを通じて完全に一定か？
2. `delete` や動的なプロパティ追加によって、隠しクラスをメガモーフィックな泥沼に落していないか？
3. 外部からの不審な入力を受け取るデータ構造は、適切に凍結（Freeze）されているか？
ランタイムの挙動を支配する者だけが、JavaScriptを真に掌握することができる。表面的な構文の美しさに惑わされず、ヒープの底でううめくV8の鼓動を感じながらコードを紡ぎ出してほしい。