【上級者向け】constによる参照の固定と「不変性」の誤解：オブジェクトのプロパティ変更が隠しクラスに与える影響
JavaScriptを日常的に書くエンジニアであれば、変数の宣言に `const` を使うことはもはや無意識の反射運動になっているはずだ。「この変数は再代入されない」という意図を明確にするために `const` を選び、コードの安全性を高める。これは現代のJavaScript開発において疑う余地のないベストプラクティスである。
しかし、シニアエンジニアやコアなランタイムの挙動に関心を持つ者であれば、一度立ち止まってこう自問したことがあるはずだ。
「`const` は、本当にオブジェクトを『イミュータブル（不変）』にしているのだろうか？」
答えは明確に「ノー」だ。`const` が保証するのは、あくまでも変数束縛（Variable Binding）の固定、すなわち「その識別子が指し示すメモリ上のアドレス（参照）の書き換え禁止」に過ぎない。オブジェクトの内部状態、すなわちプロトタイプチェーンの向こう側や、ヒープ上に確保されたデータ構造そのものは、`const` であろうと平然と書き換えることができる。
この誤解は単なるセマンティクスの問題にとどまらない。`const` で宣言されたオブジェクトであっても、そのプロパティを動的に追加・変更・削除し続ける行為は、V8エンジン内部のJITコンパイルと隠しクラス（Hidden Classes / Maps）の最適化メカニズムを破壊し、パフォーマンスを地の底へと突き落とす最大の要因となり得るのだ。
本稿では、V8エンジンのメモリ空間とJITコンパイルの深層に潜り込み、オブジェクトの可変性がランタイムに与える物理的な影響と、本当の意味での「不変性（Immutability）」がもたらす極限の最適化の恩恵を技術的に解き明かす。
—
1. V8エンジンの視点：`const` オブジェクトのプロパティ変更は何を引き起こすか？
まず、JavaScriptエンジン（ここでは代表としてGoogle ChromeやNode.jsの基盤であるV8を想定する）が、メモリ上でオブジェクトをどのように扱っているかを理解する必要がある。
C++などの静的言語であれば、構造体（Struct）のメンバのオフセットはコンパイル時に確定する。しかし、動的言語であるJavaScriptでは、オブジェクトのプロパティを後から自由に追加・変更できる。これでは、プロパティにアクセスするたびにハッシュマップのような動的なルックアップ（O(1)〜O(N)のコスト）が発生し、到底ネイティブに近い速度での実行など望めない。
この問題を解決するためにV8が採用しているのが 「隠しクラス（Hidden Classes）」、内部実装用語で言うところの `Map`（ECMAScriptの `Map` オブジェクトではなく、V8内部のC++クラス `i::Map`） である。
隠しクラスとトランジションツリーの崩壊
V8は、オブジェクトの構造（プロパティの有無と順序）ごとに「隠しクラス」を動的に割り当てる。同じ構造を持つオブジェクトは同じ隠しクラスを共有し、プロパティのメモリ上のオフセットを固定化することで、インラインキャッシュ（Inline Caching: IC）を有効化し、プロパティアクセスをC++の構造体メンバアクセスと同等の速度にまで引き上げる。
ここで、次のようなコードを考えてみよう。
// const で宣言されているため、変数 binding 自体は変更不可能
const user = {};
// プロパティを後から動的に追加する
user.id = 1;
user.name = ‘Alice’;
user.role = ‘admin’;
一見、何の問題もない通常のコードに見える。しかし、V8のランタイムの視点では、このコードは以下のような「隠しクラスの遷移（Transition）」の連鎖を引き起こしている。
1. `const user = {};`
- 空のオブジェクトが生成される。初期隠しクラス `Map 0` が割り当てられる。
2. `user.id = 1;`
- `id` プロパティが追加され、V8は新しい隠しクラス `Map 1` を生成する（`Map 0` からのトランジション）。
3. `user.name = ‘Alice’;`
- `name` プロパティが追加され、隠しクラスは `Map 2` へ遷移する。
4. `user.role = ‘admin’;`
- `role` プロパティが追加され、隠しクラスは `Map 3` へ遷移する。
このトランジションの過程で、V8はオブジェクトのプロパティ格納領域（Properties Store）を動的に再割り当て（リロケーション）し、メモリの断片化やヒープの肥大化を誘発する。
さらに深刻なのは、「プロパティの追加順序」や「削除」が引き起こす最適化の破綻だ。
// 別のアコードで同じようなオブジェクトを作るが、順序が違う
const admin = {};
admin.role = ‘admin’;
admin.name = ‘Alice’;
admin.id = 1;
`user` と `admin` は論理的には全く同じプロパティを持っているにもかかわらず、追加順序が異なるため、全く異なる隠しクラスが割り当てられる。これにより、これらを受け取る関数（例えば `function processUser(u) { return u.id; }`）のインラインキャッシュ（IC）は「メガモルフィック（Megamorphic：多態的）」状態へと格下げされ、V8のJITコンパイラ（TurboFan）による最適化コードの生成が諦められ、低速なインタープリター実行やスタブ呼び出しへとフォールバックしてしまう。
—
2. メモリ空間の真実：ヒープレイアウトとガベージコレクション（GC）の負荷
プロパティの動的な変更は、CPUサイクルの無駄遣い（ICのミス）だけでなく、V8のガベージコレクション（GC）エンジンに対しても多大な負荷をかける。
V8のヒープは、大きく「新生代（Young Generation：Scavenger）」と「老年代（Old Generation：Mark-Sweep-Compact）」に分かれている。
動的にプロパティが追加・削除されるオブジェクトは、そのサイズが予測できず、インプレース（同一メモリ領域内）での更新が不可能になると、ヒープ内の別の領域に新しいメモリブロックを確保してデータをコピーする必要が生じる。
これにより、新生代領域でのメモリ割り当て頻度が劇的に上昇し、微小な停止時間（Stop-the-World）であるScavenge GCが頻発する原因となる。
また、`delete` 演算子を使用した場合の惨劇は特筆に値する。
const config = { host: ‘localhost’, port: 8080, debug: true };
// デバッグフラグを削除する
delete config.debug;
`delete` を実行すると、V8はそのオブジェクトを「ディクショナリモード（Dictionary Mode）」へと強制降格させる。これは隠しクラスによる高速なオフセットアクセスを放棄し、内部的にハッシュテーブルを使った低速なルックアップへ切り替える操作である。一度ディクショナリモードに落ちたオブジェクトが、元の高速な隠しクラスモードに戻ることは二度とない。
—
3. 本当の「不変性（Immutability）」：オブジェクトの構造的完全性と最適化の極限
では、真の意味でパフォーマンスを極限まで引き出し、V8のJIT最適化を最大限に享受するための設計とは何か？
それは、「オブジェクトの生成時にその構造を完全に確定させ、二度と変更しない（構造的イミュータビリティ）」 ことである。
Object.freeze() と V8の最適化
しばしば `Object.freeze()` はセキュリティ（プロトタイプ汚染対策）やデータ整合性の文脈で語られるが、実はV8のランタイム最適化にとっても強力なシグナルとなる。
// オブジェクトの構造と値を同時に確定させ、フリーズする
const user = Object.freeze({
id: 1,
name: ‘Alice’,
role: ‘admin’
});
`Object.freeze()` が適用されたオブジェクトは、V8内部で「拡張不可能（Non-extensible）」かつ「設定不可・書き込み不可」のフラグが立ち、コンパイラは「このオブジェクトの構造とプロパティ値は今後一切変化しない」という強い仮説（Assumption）を立てることができる。
これにより、TurboFanなどのJITコンパイラは、プロパティアクセスのコードを「定数折りたたみ（Constant Folding）」 や 「値のインライン展開（Inlining）」 の対象として扱い、プロパティのフェッチ自体を完全に排除したマシン語コードを生成することが可能になる。
—
4. 実践：モダンJSにおけるイミュータブル設計とパフォーマンストレース
実際のプロダクションコードにおいて、どのようにこの知見を適用すべきか。以下の比較例を見てほしい。
アンチパターン：可変な設定オブジェクトの構築
// 悪い例：プロパティを後から追加・変更する
function createServerConfig(options) {
const config = {}; // 動的拡張の温床
config.port = options.port || 3000;
config.env = options.env || ‘development’;
if (options.ssl) {
config.cert = options.ssl.cert;
config.key = options.ssl.key;
}
return config; // 毎回異なる隠しクラスを持つ可能性があり、ICが破綻する
}
このコードでは、`options.ssl` の有無によってオブジェクトの隠しクラスが分岐し、V8のインラインキャッシュを激しく汚染する。
最適化パターン：形状の固定とオブジェクトスプレッド・Freeze
// 良い例：形状（Shape）を完全に一致させ、Object.freezeで最適化を確定させる
function createServerConfig(options) {
// 常に同一のプロパティセットを持つオブジェクトリテラルを一括生成する
const config = {
port: options.port ?? 3000,
env: options.env ?? ‘development’,
cert: options.ssl?.cert ?? null,
key: options.ssl?.key ?? null
};
// 構造の不変性を保証し、V8のインラインキャッシュ最適化をブーストする
return Object.freeze(config);
}
このアプローチでは、どの引数パターンであっても生成されるオブジェクトの隠しクラス（Map）は完全に同一のものに収束する。V8は単一の隠しクラスに対する最適化コードを維持し続け、CPUキャッシュ効率と実行速度は理論上の最高値に近づく。
—
5. セキュリティの深層：プロトタイプ汚染（Prototype Pollution）とランタイムの防壁
最後に、この「オブジェクトの構造と可変性」にまつわる挙動が、セキュリティ、特にプロトタイプ汚染（Prototype Pollution）の脆弱性とどのように直結しているのかを論じておこう。
プロトタイプ汚染は、攻撃者が悪意ある入力（JSONのパース結果やクエリパラメータなど）を通じて、Objectのプロトタイプ（`Object.prototype`）に任意のプロパティを注入する攻撃手法である。
// 攻撃ペイロードの例（再帰的マージ等を通じて侵入）
// Object.prototype.isAdmin = true;
もしアプリケーション側で、オブジェクトのプロパティ存在確認を安易に行っていたり、動的なプロパティ探索に依存している場合、この汚染によって予期せぬコードパスが実行され、最悪の場合はリモートコード実行（RCE）へと繋がるサプライチェーン攻撃の踏み台にされる。
イミュータブル設計と `Object.create(null)` による防壁
このセキュリティリスクに対して、ランタイムレベルで最も堅牢な防壁となるのが、「プロトタイプを持たないオブジェクトの活用」 と 「徹底した構造の固定」 である。
/
- プロトタイプチェーンを持たない、完全に独立した安全なデータコンテナを生成する
- @param {Object} rawData
/
function createSecureContext(rawData) {
// Object.prototype を継承しない（__proto__ が存在しない）
const secureMap = Object.create(null);
// 必要なプロパティだけを安全にマッピング
secureMap.id = String(rawData.id);
secureMap.permissions = Array.isArray(rawData.permissions)
? Object.freeze([…rawData.permissions])
: [];
// 外部からの改変を完全に遮断
return Object.freeze(secureMap);
}
`Object.create(null)` によって生成されたオブジェクトは、`Object.prototype` から一切のメソッドやプロトタイプを継承しない。そのため、仮にグローバルな `Object.prototype` が攻撃者によって汚染されたとしても、このオブジェクトの挙動が書き換わることは構造的に不可能となる。
さらに、これに `Object.freeze()` を組み合わせることで、メモリ上の安全性が担保されるだけでなく、V8エンジンにとっても「予測可能で安全な固定構造」として認識され、セキュリティとパフォーマンスの双方を同時に最高水準で達成することができる。
—
結言
`const` は魔法の杖ではない。それは単なる文法上の制約に過ぎない。
真にハイパフォーマンスでセキュアなJavaScript/Node.jsアプリケーションを構築するためには、言語仕様の表面的な理解にとどまり、その裏で稼働するV8エンジンの隠しクラス、JITコンパイル、ヒープメモリの動態にまで想像力を巡らせる必要がある。
「変数を `const` にする」ことの本当の意味は、再代入を防ぐことではない。「データ構造を固め、ランタイムに迷いを与えず、予測可能な高速化の軌道に乗せる」 という、エンジニアリングとしての意志表示なのだ。この知見を胸に、明日からのコードの「構造」を見直してほしい。ランタイムは、確かなパフォーマンスの向上という形で必ず応えてくれるはずだ。