厳格モード（`use strict`）とV8の防壁：暗黙のグローバル変数が破壊するランタイム最適化の真実
JavaScriptの歴史は、その極端な柔軟性と、それに起因する「カオス」の歴史でもある。10日で作られた言語という原罪を抱えながらも、Webの基盤として成長したJSは、現代においてはV8やSpiderMonkeyといった高度なJIT（Just-In-Time）コンパイラを持つランタイム上で実行される、極めてアグレッシブなハイパフォーマンス言語へと変貌を遂げた。
そのランタイムの最適化を根底から破壊し、セキュリティ上の致命的な脆弱性を生む温床となるのが、「宣言漏れによる暗黙のグローバル変数生成（Implied Globals）」である。
ECMAScript 5で導入された `”use strict”;`（厳格モード）は、単なる「お行儀の良い書き方を強制するルール」ではない。これは、V8などのエンジンがコードを最適化するためのランタイムの物理防壁であり、サプライチェーン攻撃を防ぐためのセキュリティの要塞なのだ。
本稿では、`use strict`が変数の宣言において何を引き起こし、それがV8の内部機構（Hidden Class / Shape）やスコープ解決、さらにはプロトタイプ汚染にどう影響するのかを、言語仕様とエンジン実装の低レイヤから徹底的に解剖する。
—
1. 暗黙のグローバル変数は、なぜV8の最適化を殺すのか？
通常モード（Sloppy Mode）において、次のようなコードを実行したとき、何が起きるか。
function calculateTotal(price, tax) {
// 意図せず ‘total’ の宣言（let / const / var）を忘れたとする
total = price (1 + tax);
return total;
}
`total` には宣言キーワードがない。この瞬間、JavaScriptエンジンは以下の挙動をとる。
1. 現在の実行コンテキストのスコープチェーンをグローバルオブジェクト（ブラウザなら `window`、Node.jsなら `global`）に到達するまで遡る。
2. どこにも `total` が見つからないため、グローバルオブジェクトのプロパティとして `total` を動的に新規作成する。
これが「暗黙のグローバル変数」の正体だ。これは変数ではなく、単なるグローバルオブジェクトのプロパティ追加に他ならない。
V8の隠しクラス（Hidden Class / Map）の崩壊
V8エンジンは、動的言語であるJavaScriptで静的言語並みのプロパティアクセス速度を実現するために、隠しクラス（V8用語では `Map`）という概念を使用する。
オブジェクトがどのようなプロパティをどの順序で持っているかを示す「形状（Shape）」を追跡し、インラインキャッシュ（Inline Caching: IC）を効かせることで、プロパティルックアップをメモリアドレスのオフセット計算にまで落とし込む。
しかし、関数の実行中に暗黙のグローバル変数が生成されると、グローバルオブジェクトの `Map` が動的に書き換わる（Transitionが発生する）。これにより、グローバルオブジェクトを参照しているすべてのコードのインラインキャッシュがメガモルフ（Megamorphic：最適化が無効化された状態）に陥り、V8のヒープ上での効率的なプロパティアクセスが完全に崩壊する。
—
2. `use strict` による言語仕様レベルの防壁
このバグの温床を根絶するため、ECMAScript仕様は `use strict` において厳格な文法規則を課した。
仕様書の評価アルゴリズムにおいて、厳格モードコード（Strict Mode Code）の評価時は、識別子解決（Identifier Resolution）において未宣言の識別子への代入が行われた場合、ReferenceErrorを送出することが義務付けられている。
“use strict”;
function secureCalculate(price, tax) {
// 宣言なしの代入
amount = price (1 + tax);
// => Uncaught ReferenceError: amount is not defined
return amount;
}
このエラーは、パース段階あるいはJITのバイトコード生成段階（Ignition）で検知される。ランタイムが「グローバルオブジェクトへの意図しないプロパティ動的追加」を物理的にブロックすることで、V8はグローバルスコープの `Map` の安定性を担保し、JITコンパイラ（TurboFan）が安全に機械語への最適化を行えるようになる。
—
3. サプライチェーン攻撃とプロトタイプ汚染（Prototype Pollution）のコンテキスト
厳格モードによる変数宣言の強制は、パフォーマンスだけでなく、セキュリティ（特にリモートコード実行: RCE）の文脈においても決定的な意味を持つ。
現代のNode.jsエコシステムにおいて、依存関係（npmパッケージ）の深部を突く「プロトタイプ汚染」は脅威の主流である。悪意あるペイロードがオブジェクトのマージ処理（例：深層クローン関数）などを経由して、`Object.prototype` を汚染したとする。
// 攻撃者によって Object.prototype が汚染された世界線
Object.prototype.isAdmin = true;
もし、あなたのコードで変数の宣言漏れがあるとどうなるか？
function processRequest(user) {
// role変数を宣言し忘れた！
role = user.role; // sloppy mode
if (role === ‘admin’) {
grantAccess();
}
}
1. `role` が宣言されていないため、JSエンジンはスコープチェーンを遡る。
2. ローカルスコープにも、外側にも `role` はない。
3. グローバルオブジェクトに到達する。
4. ここで、もしグローバルオブジェクト（あるいはそのプロトタイプチェーン上）に `role` というプロパティが（プロトタイプ汚染によって）存在していたら？
暗黙のグローバル変数生成ではなく、「既存の汚染されたプロパティへの代入」、あるいは予期せぬプロトタイプチェーンのルックアップを引き起こし、認証バイパスや意図しない権限昇格（RCEのトリガー）へと直結する。
`use strict` を有効にしていれば、未宣言の変数への代入は即座に `ReferenceError` としてクラッシュする。セキュリティの世界における基本原則 「Fail-Safe（安全側倒れ）」 の観点から、サイレントにバグや脆弱性を孕むより、即座に例外を投げてプロセスを落とす方が遥かに安全なのだ。
—
4. チーフアーキテクトが推奨する現代的実践
モジュールシステム（ES Modules / CommonJS）を用いる現代の開発において、実はES Modulesやクラスの内部はデフォルトで強制的に厳格モードになっている。しかし、レガシーなスクリプトファイルや、Node.jsのCommonJS環境の一部、あるいはグローバルスコープの直書きにおいては、依然としてSloppy Modeの罠が潜んでいる。
次世代の堅牢なアプリケーションを設計するにあたり、以下のプラクティスを組織全体で徹底すべきである。
1. すべてのファイルの先頭に `”use strict”;` を（必要に応じて）明記する
ESM環境であれば暗黙的だが、バンドラを通す前のソースコードや、トランスパイル前のNode.jsスクリプトの先頭には必ず配置する。
2. 静的解析（ESLint）による多重防御
ランタイムの防壁頼みにするのではなく、Lintの段階で検知する。
{
“parserOptions”: {
“ecmaVersion”: “latest”,
“sourceType”: “module”
},
“rules”: {
“strict”: [“error”, “safe”],
“no-undef”: “error”
}
}
`no-undef` ルールを有効にすることで、未宣言変数の参照を静的に完全に駆逐できる。
3. `let` と `const` の完全採用 (`var` の完全廃止)
変数の巻き上げ（Hoisting）によるバグを防ぎ、かつTDZ（Temporal Dead Zone: 一時的死空間）の恩恵を受けるために、`var` は二度と使わない。
—
結び
JavaScriptは、もはや「おもちゃのスクリプト言語」ではない。V8という極限までチューニングされた仮想マシン上で動作する、エンタープライズレベルのシステム基盤である。
そのランタイムのパフォーマンスを極限まで引き出し、悪意あるサプライチェーンの魔手からコードベースを守り抜くためには、言語仕様の根底にある挙動を完全に掌握しなければならない。`use strict` は、そのための最も小さく、そして最も強力な第一歩なのだ。