コードレビューをしていて、未だにレガシーなコードベースの中で `(function() { … })();` という記述を見かけることがある。即時実行関数（IIFE: Immediately Invoked Function Expression）だ。
「なぜこれを使っているのか？」と聞くと、多くのジュニア〜中堅エンジニアは「グローバル汚染を防ぐため」と教科書通りの答えを返す。それは歴史的背景としては正しい。しかし、現代のモダンなフロントエンド開発において、IIFEはすでにその役目を終えたレガシーハックであり、下手に使い続ければV8エンジンの最適化を阻害し、バンドラーのツリーシェイキング（Dead Code Elimination）を殺す毒になり得る。
今回は、IIFEが担ってきた歴史的役割のメカニズムをV8のスコープチェーンの観点から解体し、なぜ私たちが即座にES Modules（ESM）へ移行すべきなのか、その技術的根拠をプロダクションコードの設計パターンと共に叩き込む。
—
1. なぜIIFEが必要だったのか？ —— V8のスコープとグローバル汚染の歴史
JavaScriptの黎明期、言語仕様には「モジュール」という概念が存在しなかった。当時存在したのは、関数スコープ（Function Scope）とグローバルスコープ（Global Scope）のみである。
ブラウザ環境において、すべてのスクリプトタグで宣言されたトップレベルの変数や関数は、最終的にグローバルオブジェクト（ブラウザなら `window`）のプロパティとしてアタッチされる。これにより何が起きるか？
// Aさんが書いたライブラリ
var userId = 12345;
// Bさんが書いた業務コード（Aさんの存在を知らない）
var userId = “admin-user”;
// 💥 意図せず上書きされ、認証システムが崩壊する
console.log(userId); // “admin-user”
このグローバル名前空間の衝突（グローバル汚染）を防ぐ唯一の防壁が「関数スコープ」だった。JavaScriptでは、関数内部で宣言された変数は外部からアクセスできない。この言語仕様の特性をハックし、「定義と同時に実行する関数」を作ることで、一時的なプライベートスコープを強制的に作り出したのがIIFEである。
// IIFEによるスコープの隔離
(function() {
var userId = 12345; // この変数はグローバルを汚染しない
console.log(“セキュアなスコープ内:”, userId);
})();
// 外からはアクセス不能
// console.log(userId); // ReferenceError: userId is not defined
—
2. IIFEの構造とV8ランタイムへの影響
IIFEの構文は、パーサーに対して「これは関数宣言ではなく、関数式（Function Expression）である」と明示するために存在する。
// パーサーに「式」であることを伝えるためのグループ化演算子 ( )
(function(global) {
// 依存関係のインジェクション
var privateData = “secret”;
global.myLibrary = {
getData: function() { return privateData; }
};
})(window);
V8エンジン内部での挙動とパフォーマンスの罠
V8（ChromiumのJavaScriptエンジン）は、コードの実行前にパースとAST（抽象構文木）の生成を行い、スコープの解析（Scope Analysis）を行う。
IIFEを用いる場合、V8はそれを「即座に実行されるスコープ」として処理するが、以下の問題がつきまとう。
1. クロージャの生成コスト: IIFE内部の関数が外側の変数を参照していなくても、構文構造上、スコープチェーンの構築やコンテキストの生成といったオーバーヘッドが発生する。
2. バンドラーの最適化阻害: WebpackやRollupなどのモダンバンドラーは、静的解析（Static Analysis）によって「使われていないコード（Dead Code）」を削ぎ落とす（ツリーシェイキング）。しかし、IIFEの内部で行われる動的なオブジェクトの拡張やグローバルへの代入は静的解析を極めて困難にし、結果として不要なコードがバンドルサイズを肥大化させる。
—
3. 現代的代替案：ES Modules（ESM）への完全移行
現代のフロントエンド開発において、スコープの隔離にIIFEを使う理由はもはや1ミリもない。ブラウザのネイティブサポート、そしてViteやWebpackといったモダンバンドラーの標準であるES Modulesが、そのすべてをエレガントに解決しているからだ。
ESMにおいて、すべてのJavaScriptファイルは自動的に独自の「モジュールスコープ」を持つ。ファイル内で宣言された変数や関数は、明示的に `export` しない限り、他のファイルから一切アクセスできない。
プロダクションコード例：モジュールによるカプセル化と依存性注入
かつてIIFEで行っていた「プライベート変数の保持」と「パブリックAPIの公開」は、ESMを使えば以下のように美しく、かつ静的解析しやすい形で記述できる。
// — ユーザー管理モジュール (userStore.js) —
// モジュールスコープ（外部からは完全に見えないプライベートな空間）
let currentUser = null;
const SESSION_TIMEOUT = 30 60 1000; // 30分
/
- ユーザーセッションを初期化する（内部処理）
/
function validateSession() {
// 複雑なセッション検証ロジック
return currentUser !== null;
}
// — パブリックAPIの公開 (Named Export) —
/
- 現在のユーザーを設定する
- @param {Object} user
/
export function setCurrentUser(user) {
if (!user || typeof user.id !== ‘string’) {
throw new TypeError(‘無効なユーザーオブジェクトです’);
}
currentUser = user;
}
/
- 現在のユーザー情報を取得する（イミュータブルにクローンを返す）
- @returns {Object|null}
/
export function getCurrentUser() {
if (!validateSession()) return null;
// 参照透過性を保つため、スプレッド構文でシャローコピーを返す
return { …currentUser };
}
このモジュールを別ファイルで利用する場合：
// — アプリケーションのエントリーポイント (main.js) —
import { setCurrentUser, getCurrentUser } from ‘./userStore.js’;
// 他のファイルの変数と衝突する心配は一切ない
setCurrentUser({ id: ‘u-9988’, name: ‘Taro Engineer’ });
console.log(getCurrentUser());
// 出力: { id: ‘u-9988’, name: ‘Taro Engineer’ }
// プライベート変数には直接アクセスできないため、バグの温床を断絶できる
// console.log(currentUser); // SyntaxError または ReferenceError
—
4. チーフアーキテクトからの提言：レガシーな思考からの脱却
コードレビューにおいて、IIFEを見かけたらこう指摘してほしい。
> 「このIIFEは何のために存在していますか？ グローバル汚染を防ぎたいのであれば、ファイル単位でモジュールスコープを提供するESMを使いましょう。もしクロージャとして即時実行の初期化処理を行いたいだけなら、通常のブロック文（`{ … }`）と `let` / `const` によるブロックスコープで十分ではないですか？」
もし、モジュールシステムが使えない極限の環境（古いインジェクションスクリプトなど）でない限り、IIFEを書くべき理由は現代のWeb開発において絶滅している。
V8エンジンの特性を理解し、バンドラーが効率的にインライン展開やツリーシェイキングを行える「静的構造」をコードに与えること。それこそが、モダンWebエンジニアに求められる真のコード品質なのである。