こんにちは！フロントエンドからNode.jsの深層まで、JavaScriptのエンジンが奏でる鼓動を日々感じているアーキテクトの私です。
今回は、JavaScriptの歴史と進化を語る上で避けて通れない、「IIFE（即時実行関数）」と、それが現代のモダン開発でどのように「ES Modules（ESM）」へとバトンタッチされたのかについて、本質を徹底的に解き明かしていきましょう。
「なぜ昔のコードには変な書き方が多いのか」「現代の開発ではどう書くべきなのか」。ここをクリアすれば、JavaScriptの変数スコープとモジュールシステムの基本はバッチリマスターできますよ。それでは、一緒に深淵を覗いてみましょう。
—
1. そもそもなぜ、変数管理やスコープで苦労するのか？
JavaScriptという言語は、誕生当初、ブラウザでちょっとしたインタラクション（ボタンを押したら色が変わるなど）を動かすための「おもちゃの言語」として作られました。そのため、言語の設計思想として「変数はとりあえずグローバル空間（どこからでも見つかる場所）に置いておけば動く」という非常に緩いアプローチをとっていました。
しかし、Webサイトが「単なる文書の閲覧場所」から「リッチなWebアプリケーション」へと進化するにつれ、この緩さが大問題を引き起こすようになります。
グローバル汚染（Global Pollution）の恐怖
もしあなたが、自分で書いたJavaScriptファイルと、どこからか持ってきた外部ライブラリ（例えばjQueryや、古い解析ツールなど）を読み込んだとき、両者が同じ名前の変数（例：`count`や`user`や`config`）を使っていたらどうなるでしょうか？
// 3rdパーティーのライブラリ
var user = “Guest”;
// あなたが書いたコード
var user = “Admin”; // ← 前の変数を意図せず上書きしてしまい、バグが爆誕！
JavaScriptには長らく、「ファイルごとに独立したスコープを作る」という標準機能がありませんでした。すべての変数が一つの大きなグローバルオブジェクト（ブラウザなら `window`）のプロパティとして相乗りしてしまい、あちこちで変数が衝突する「グローバル汚染」にエンジニアたちは頭を悩ませていたのです。
—
2. 救世主としての登場：IIFE（即時実行関数）の仕組み
この「グローバルを汚したくない」「変数を関数の中に閉じ込めたい」という切実な願いから生まれたのが、IIFE（Immediately Invoked Function Expression：即時実行関数式）です。
まずは、その姿形を見てみましょう。
// IIFEの基本形
(function() {
var secretMessage = “私は外からは絶対に触れません”;
console.log(“IIFEが即座に実行されました！”);
})();
// この外側からは…
// console.log(secretMessage); // ❌ ReferenceError: secretMessage is not defined
コードの解剖とV8エンジンの挙動
「なぜこれで変数が隠せるのか？」、そのメカニズムをJavaScriptエンジンの視点から紐解きます。
1. 関数式としての評価:
JavaScriptでは、文の先頭に `function` が来ると「関数宣言」とみなされ、名前がないとエラーになります。そこで、全体を丸括弧 `( … )` で囲むことで、これを「関数式（値としての関数）」に強制変換しています。
2. 即時実行:
末尾の `()` は、「この関数を定義した瞬間にその場で実行しなさい」という命令です。
3. プライベートスコープの形成:
JavaScriptでは「関数だけが新しいスコープ（変数の有効範囲）を作れる」という鉄則があります。IIFEの中で宣言された `var` や `let` は、その関数の壁の中に完全に閉じ込められ、外側の世界からは一切見えなくなります。
これにより、グローバル空間を汚染することなく、安全に一過性の処理やライブラリの初期化を行うことができるようになったのです。これが、かつてのモダン開発を支えた知恵でした。
—
3. 現代的代替案：ES Modules（ESM）への完全移行
IIFEは素晴らしい発明でしたが、あくまで「言語仕様にモジュール機能がなかった時代のエセ・モジュールパターン」です。コードが複雑になるにつれてファイル分割が難しくなり、ビルドツール（WebpackやViteなど）の助けが必要でした。
そして現在。JavaScriptは言語仕様（ES6 / ECMAScript 2015以降）として、ES Modules（ESM）という公式のモジュールシステムを手に入れました。
現代の開発現場において、もはやIIFEを手書きする必要はほぼありません。ファイルそのものが自動的に独立したスコープを持つようになったからです。
現代の標準：ファイルスコープと `import / export`
ファイルがそのまま1つの「モジュール（カプセル化された空間）」になります。
// auth.js （一つの独立したファイル＝モジュール）
// この変数は、このファイルの外（グローバル）には絶対に漏れません！
const internalToken = “secret_abc123”;
// 外の世界に公開（export）したいものだけを明示的に指定します
export function login(username) {
console.log(`${username} がログインしました。トークンを使います: ${internalToken}`);
}
// main.js （別のファイル）
// auth.jsから必要なものだけを安全にインポートする
import { login } from ‘./auth.js’;
login(“Alice”);
// console.log(internalToken); // ❌ 参照エラー！外からは見えないよう完璧に守られています。
なぜESMが素晴らしいのか？
- 自動的なカプセル化: ファイル単位でスコープが切られるため、IIFEでわざわざ関数全体を囲む必要がなくなりました。
- 依存関係の明確化: どのファイルがどのファイルを必要としているか（`import` / `export`）が静的に解析できるため、V8エンジンやバンドラが不要なコードを削ぎ落としたり（Tree Shaking）、効率的な最適化を行えます。
—
4. 陥りやすい罠：変数宣言（var / let / const）との関係
ここで、初学者や他言語からの移行者がよくハマる「スコープと巻き上げ（Hoisting）の罠」について補足しておきます。
IIFEや古いコードを読むとき、あるいは現代のコードを書くとき、以下の違いを体に叩き込んでおきましょう。
// 【罠】varを使った場合のスコープ抜け
(function() {
if (true) {
var oldVar = “私は関数スコープ”;
}
console.log(oldVar); // ❌ 出力されてしまう！（if文やブロックを無視して関数全体に漏れる）
})();
// 【正解】let / constを使った場合のブロック単位の閉じ込め
{
let modernLet = “私はブロックスコープ”;
const modernConst = “私もブロックスコープ”;
}
// console.log(modernLet); // ❌ ReferenceError: スコープの外なのでアクセス不可！
知見のポイント:
IIFEはあくまで「関数スコープ」を作る仕組みです。しかし、現代のESM環境では、関数だけでなく `if` 文や `for` 文などの「ブロック（`{}`）」単位で変数を閉じ込められる `let` と `const` が標準です。
したがって、変数を隠蔽したいがためにIIFEを使う必要性は完全に消え去り、「モジュールファイル ＋ `const`/`let`」の組み合わせが、最も堅牢でモダンなアプローチとなります。
—
まとめ：歴史を知り、未来のコードを書く
いかがだったでしょうか？
1. IIFE（即時実行関数）は、かつてJavaScriptにモジュール機能やブロックスコープが無かった時代に、グローバル汚染を防ぐために生み出された偉大な防衛策でした。
2. しかし現代では、言語仕様としてES Modules（`import`/`export`）とブロックスコープ（`let`/`const`）が標準装備されています。
3. これにより、ファイルそのものがモジュールとなり、コードの安全性とメンテナンス性は劇的に向上しました。
歴史的なコードベース（レガシーなライブラリや古いプラグイン）を読む際には今でもIIFEに出会うことがあります。「あぁ、これは昔のエンジニアがグローバル汚染と戦った証なんだな」と背景を理解して読めるようになると、あなたのコードリーディング能力は一段と深まりますよ。
ここをクリアできれば、JavaScriptの変数管理とスコープの仕組みはもうバッチリです。自信を持って、モダンなモジュール開発に飛び出していきましょう！