【実務・中級編】Reactのフック（Hooks）とスコープの罠：なぜループや条件分岐内で宣言してはいけないのか – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

React Hooksのスコープの罠：なぜループや条件分岐内で宣言してはならないのか

コードレビューをしていて、もっともゾッとする瞬間の一つがこれだ。

// ❌ 絶望的なバグを孕むアンチパターン
function Component({ items, shouldLoadSpecial }) {
if (shouldLoadSpecial) {
const [specialState, setSpecialState] = useState(null); // ここで条件分岐！
}

const [data, setData] = useState([]);

for (let i = 0; i < items.length; i++) { const [itemState, setItemState] = useState(items[i]); // ここでループ！ } // ... 以下続く } 「動くからいいじゃないか」と思ったそこのあなた。V8エンジンとReactの調停レイヤーで何が起きているかを知れば、二度とこの書き方をしなくなるはずだ。表面上の「シンタックスの美しさ」や「スコープの局所化」というエゴのために、Reactの心臓部であるFiberアーキテクチャのメモリ整合性を破壊する行為。それが、ループや条件分岐内でのHook呼び出しである。

今回は、JavaScriptの実行コンテキスト、V8のヒープとコールスタックの概念を拡張し、Reactが内部でどのように状態を管理しているのか、その根底にあるメカニズムを解剖する。

—

1. V8ランタイムとReact Fiberの裏側：なぜ「順番」が絶対なのか？

多くのエンジニアは、「ReactのHooksは内部で配列（あるいは連結リスト）を使っている」という事実を、どこかで聞きかじっているだろう。しかし、それがランタイムレベルで何を意味するのかを正確に理解している人は少ない。

JavaScriptの関数実行時、V8エンジンはコールスタック上に実行コンテキスト（Execution Context）を生成し、ローカル変数を管理する。しかし、Reactの関数コンポーネントにおける`useState`や`useEffect`の状態は、関数が終了しても破棄されては困る。そのため、これらはコンポーネントの外側、すなわちReact内部の「Fiberツリー」という巨大なヒープ上の構造体に保持される。

ここで重要なのは、Reactは変数名（例: `data` や `specialState`）を一切認識していないという点だ。

Reactが認識しているのは、「このコンポーネントのライフサイクルにおいて、何番目に呼ばれたHookか」という「順序（Index）」のみである。

実行のトレース：インデックスが狂う瞬間

もし、条件分岐（`if`）やループ（`for`）の中でHookを呼び出すとどうなるか。

レンダーA（初回）：
1. `useState` (1番目): 状態 `A` を取得
2. （条件が真）`useState` (2番目): 状態 `B` を取得

レンダーB（2回目：条件が偽に変化）：
1. `useState` (1番目): 状態 `A` を取得

ここで条件分岐がスキップされる！

2. 本来 3番目だったはずの Hook が、2番目として実行される

Reactは2番目のスロットに格納されていた「前回とは全く別の状態」を誤って読み出し、最悪の場合、型不一致によるクラッシュや、別コンポーネントのStateが混ざるというホラー映画のようなバグ（State Corruption）を引き起こす。

JavaScriptのレキシカルスコープのルール上は、ブロックスコープ（`let` / `const`）の内側であってもエラーにならない。しかし、Reactのランタイム契約（Contract）に致命的な違反をしているため、V8は静かに（あるいは盛大に）バグを奏で始める。

—

2. 実務で遭遇する「やりがちな罠」と、その正しい解法

現場のコードレビューでよく見かける「やむを得ずループや条件分岐で状態を持ちたくなった瞬間」を取り上げ、プロフェッショナルがどうリファクタリングすべきかを提示しよう。

2.1 危険なパターン：動的なリスト要素ごとの状態管理

「リストの各要素ごとに、開閉状態（accordion）を持たせたい」という要件で、次のようなコードを書く人がいる。

// ❌ 危険なコード：配列の要素数や順序が変わると状態がバグる
function ItemList({ items }) {
return (

{items.map(item => {
// 🚨 ループ（mapコールバック内）でのHook呼び出しは厳禁！
const [isOpen, setIsOpen] = useState(false);
return setIsOpen(!isOpen)} />;
})}

);
}

このコードは、`items` の順番が入れ替わったり、途中の要素が削除されたりした瞬間、インデックスと状態の紐付けが完全に崩壊する。ユーザーが「アイテムA」を開いたつもりが、「アイテムC」が開くといった、デバッグ泣かせの幽霊バグの完成だ。

✅ 正解：状態は「親」に集約し、識別子（ID）で管理する

フックの呼び出し順序を常に一定（FlatかつPredictable）に保つため、ループ内でHookを呼ぶのではなく、親コンポーネントで「どのIDが開いているか」のマップ（またはSet）を1つだけ持つのが正しい設計だ。

import { useState, useCallback } from ‘react’;

// 模範的なプロダクションコード
function ItemList({ items }) {
// フックの呼び出し順序は常に「1回のみ」。条件分岐もループもない。
// 開いているアイテムのIDをSetで管理する
const [openIds, setOpenIds] = useState(() => new Set());

const handleToggle = useCallback((id) => {
setOpenIds(prev => {
const next = new Set(prev);
if (next.has(id)) {
next.delete(id);
} else {
next.add(id);
}
return next;
});
}, []);

return (

{items.map(item => (

))}

);
}

// 子コンポーネントは純粋に描画とイベント発火に徹する
function Accordion({ item, isOpen, onToggle }) {
return (

{isOpen &&

{item.description}

}

);
}

このアプローチの優位性は、ReactのFiberツリーの整合性が完全に守られる点にある。`useState` は常にトップレベルで1回だけコールされ、状態の変化はJavaScriptのプリミティブなデータ構造（`Set`）の操作に委譲されているため、予測可能性が極めて高い。

—

3. パフォーマンスとメモリの観点：なぜ「フラットなフック宣言」がV8に優しいのか

V8エンジンは、隠れクラス（Hidden Classes / Shapes）やインラインキャッシュ（Inline Caches）を駆使して、JavaScriptのオブジェクトプロパティアクセスをC++並みに最適化している。

Reactの内部実装も同様に、Hookのリンクトラックを高速に走査できるよう、メモリレイアウトの予測可能性に依存している。

1. メモリのアロケーションコストの固定化：
トップレベルで固定数のHooksを宣言することは、コンポーネントのマウント時に必要なヒープ領域のサイズをコンパイル時（厳密には初回評価時）に確定させることを意味する。動的な条件分岐やループがあると、V8側での最適化の恩恵を受けにくくなり、ガベージコレクション（GC）のプレッシャーが増大する。
2. 再描画（Re-render）時のオーバヘッド軽減：
Reactの差分検出アルゴリズム（Reconciliation）において、フックのリスト長や順序が一定であれば、O(1)に近い極めて高速なポインタ走査で状態を復元できる。逆にこれを狂わせると、無駄な再描画やメモリリークの温床となる。

—

4. チーフアーキテクトからの提言：Linterを絶対の信頼とせよ

「ルールは分かったけれど、うっかり書いてしまうかもしれない」というエンジニアへ。

人間の記憶や注意力に頼るな。チーム開発において、このルールを人間の目だけで担保しようとすることは、アーキテクチャ上の怠慢である。

必ず `eslint-plugin-react-hooks` を導入し、CI/CDパイプラインにおいて以下のルールをエラー（`error`）として強制しなさい。

{
“plugins”: [“react-hooks”],
“rules”: {
“react-hooks/rules-of-hooks”: “error”, // フックの呼び出し規則を徹底
“react-hooks/exhaustive-deps”: “warn” // 依存配列の漏れを検知
}
}

このESLintルールは、AST（抽象構文木）レベルでコードを解析し、関数コンポーネントのトップレベル以外でHookが呼ばれている箇所や、条件分岐・ループ内に潜り込んでいる箇所を容赦なく撃ち抜いてくれる。

—

まとめ

React Hooksとスコープの関係は、単なる「お作法」ではない。それはJavaScriptのシングルスレッドランタイムと、Reactの仮想DOM・Fiberアーキテクチャが交錯する境界線における、厳格な物理法則である。

フックは常にコンポーネントのトップレベルで、毎回のレンダーで全く同じ順番・回数で呼び出さなければならない。
条件分岐やループの中で状態を持ちたくなったときは、コードの構造そのものを疑い、状態の持ち方（IDによる管理やデータの正規化）をリデザインせよ。

この鉄の掟を守ることで、あなたの書くコードはV8エンジンにとっても、ReactのFiberにとっても、そして何より未来の自分やチームメンバーにとっても、美しく、予測可能で、堅牢なプロダクションコードとなる。