Reactフックの裏側：なぜ「ループ内で宣言してはいけないのか」をV8ヒープとリンクトリストの物理的実態から解剖する
Reactのドキュメントを開けば、「フックをループや条件分岐、ネストされた関数内で呼び出してはいけない」という鉄の掟が書かれている。多くのジュニアからミドルクラスのエンジニアは、これを「Reactのルールだから」と呪文のように暗記し、ESLintの `react-hooks/rules-of-hooks` に従うことで日々の開発を乗り切っている。
しかし、シニアエンジニアやフレームワークの内部構造に踏り込むアーキテクトであれば、こう問いかけるはずだ。
「一体、ランタイムの何がそれを許さないのか？」
DOMの差分計算や仮想DOMの抽象化レイヤーの話ではない。もっと下層、V8エンジンのメモリ空間、JITコンパイルされたバイトコード、そしてコールスタックとヒープの物理的な挙動のレベルで何が起きているのか。本稿では、Reactの内部ファイバー（Fiber）構造とJavaScriptのスコープメカニズムを直結させ、この「フックの順序依存性」の正体を極限まで剥き出しにして解説する。
—
1. 宣言的UIの裏に隠された「厳密な順序依存リンクトリスト」
まず大前提として、JavaScriptのランタイムはReactが「どのコンポーネントのどのフックを指しているか」を魔法のように知っているわけではない。V8の視点から見れば、関数コンポーネントとは単なるプレーンな関数（あるいはJITによって最適化された機械語の塊）に過ぎず、実行されるたびにコールスタックにフレームが積まれ、ローカル変数はスコープチェインまたはヒープ上のコンテキストとして処理される。
Reactが状態（State）を維持できるのは、コンポーネントごとの「Fiber（ファイバー）」と呼ばれる内部オブジェクトの中に、フックの連結リスト（Linked List）を保持しているからだ。
Fiber Node
└── memoizedState (Pointer to the first Hook in the list)
├── Hook 1 (useState: count) —> next —> Hook 2 (useEffect) —> next —> null
│ └── memoizedState: 0 └── create: fn
└── memoizedState: “active”
コンポーネントが初回マウント（Mount）される時、Reactは `useState` や `useEffect` が呼ばれた順序通りに、次々と `Hook` オブジェクトを生成し、双方向または単方向のリンクトリストとして繋ぎ合わせていく。
ここで重要なのは、キーや名前ではなく、「インデックス（呼び出し順序）」だけでフックの状態を識別しているという事実だ。
—
2. ループ内でフックを宣言したときにV8ヒープとファイバーで何が起きるか
では、もし条件分岐やループの中でフックを呼び出すとどうなるか。コード例を見てみよう。
import React, { useState } from ‘react’;
function BrokenComponent({ items }) {
// ⚠️ 厳禁：条件分岐やループ内でのフック呼び出し
const [isReady, setIsReady] = useState(false);
const itemStates = [];
for (let i = 0; i < items.length; i++) {
// ループ回数が動的に変わる、あるいは途中でスキップされる可能性のあるフック
const [itemState, setItemState] = useState(items[i]);
itemStates.push([itemState, setItemState]);
}
return (
{/ 描画処理 /}
);
}
このコードが再描画（Update）時にどう解釈されるかを、ReactのReconciler（調停者）の視点とV8のメモリ管理の視点から追跡する。
初回マウント時 (`items = [‘A’, ‘B’]`)
1. `useState(false)` → Hook 1 (memoizedState: `false`) を作成。ポインタが次へ移動。
2. ループ1回目 (`i = 0`)：`useState(‘A’)` → Hook 2 (memoizedState: `’A’`) を作成。ポインタが次へ移動。
3. ループ2回目 (`i = 1`)：`useState(‘B’)` → Hook 3 (memoizedState: `’B’`) を作成。ポインタが次へ移動。
結果：リンクトリストの長さは 3。
更新時：items が `[‘A’, ‘B’, ‘C’]` に増えた場合、あるいは `[]` に減った場合
Reactが再描画のためにコンポーネントを再実行する際、フックのポインタは先頭（Hook 1）から順にインクリメントされながら、保存されていた状態（`memoizedState`）を割り当てていく。
もしループの反復回数が変わり、あるいは途中で `if` 文によってあるフックがスキップされたとしよう。
V8のヒープ上では、本来 `Hook 2`（アイテムBの状態）が結びつけられるべき場所に、新しく挿入されたアイテムのデータや、ずれたインデックスのデータが強制的に上書きされてしまう。
これにより何が起きるか？
- 状態の破壊とすり替わり（State Corruption）： 全く関係ないコンポーネントの状態や、別のアイテムの入力値が別の変数にアサインされる。
- 致命的なランタイムエラー： React内部のインデクサが期待するフックの型（例：`useMemo` が期待された場所に `useState` が来るなど）が一致せず、`Invariant Violation`（致命的例外）がスローされ、アプリケーション全体がクラッシュする。
V8のJITコンパイラ（TurboFanなど）は、オブジェクトの形状（Hidden Class / Shape）の遷移を最適化のベースにしているが、Reactのレイヤーにおけるこのような「動的なリンクトリストの不整合」は、JavaScriptエンジンの最適化範囲を遥かに超越した、アプリケーションロジックレベルの致命的な構造矛盾を引き起こす。
—
3. クロージャとスコープチェーンの罠：実務でのデバッグ手法
この問題は、単にクラッシュするだけならまだマシである。最悪なのは、「動いてしまうが、値がバグる（Stale State / 幽霊のような状態汚染）」ケースだ。
ループや非同期処理、コールバック関数の中でフックや変数を扱う際、JavaScriptのクロージャ（Closure）の挙動とスコープチェーンが絡み合うことで、さらに複雑なバグが生まれる。
以下のコードを見てほしい。一見正しく動くように見えるが、V8のレキシカル環境（Lexical Environment）の参照を意識すると、大きな欠陥があることがわかる。
import React, { useState, useEffect } from ‘react’;
function PollingComponent({ resourceIds }) {
// ❌ 危険なアンチパターン：動的配列に基づくフックの乱用とクロージャのキャプチャ
const [dataCache, setDataCache] = useState({});
resourceIds.forEach((id) => {
// ループ内でフックを使っているため、すでにRules of Hooks違反
const [status, setStatus] = useState(‘idle’);
useEffect(() => {
// このクロージャは作成された瞬間の id や status のスコープをキャプチャする
const interval = setInterval(() => {
fetchData(id).then(res => {
setStatus(res.status);
});
}, 5000);
return () => clearInterval(interval);
}, [id]); // 依存配列に id を指定していても、フック自体の順序が崩壊するリスクがある
});
return
;
}
なぜこれが「バグの温床」になるのか？
1. フックのインデックスの不安定性: `resourceIds` の要素数が動的に変化、あるいは順序が入れ替わった瞬間、Reactはどの `setStatus` がどの `id` に対応しているのかを見失う。
2. メモリリークとタイマーの暴走: 削除されたはずの `id` のインデックスに新しい別のリソースが割り当てられ、古いタイマーがバックグラウンドで走り続ける。V8のガベージコレクタ（GC）は、クロージャがスコープチェーンを通じて参照を保持し続けている限り、メモリを解放できない。
—
4. 正しいアーキテクチャ設計：フックを「フラット」に保つ極意
シニアエンジニアとして、この制約を回避するためのモダンなアーキテクチャ指針を明示する。ルールは極めてシンプルだ。
1. フックは常に「コンポーネントのトップレベル」で呼び出す
条件やループを持ち込まず、毎回のレンダリングで完全に同一の順序・同一の回数でフックが評価されることを保証する。
2. ループや条件分岐が必要な場合は「子コンポーネント」に切り出す
動的なリストや配列を処理する場合は、リストの各要素を独自のコンポーネント（Child Component）に委譲する。これにより、各子コンポーネントのインスタンスごとに独立したFiberと、安定したフックのリンクトリストが確立される。
リファクタリングされた堅牢なコード例：
import React, { useState, useEffect } from ‘react’;
// リストの各要素を独立したコンポーネントに分離
function ResourceItem({ id }) {
// このコンポーネント内でのフックの順序は常に一定（トップレベルで1回ずつ呼ばれる）
const [status, setStatus] = useState(‘idle’);
useEffect(() => {
let isMounted = true;
const interval = setInterval(async () => {
try {
const res = await fetchData(id);
if (isMounted) setStatus(res.status);
} catch (err) {
if (isMounted) setStatus(‘error’);
}
}, 5000);
return () => {
isMounted = false;
clearInterval(interval);
};
}, [id]);
return
;
}
// 親コンポーネントは単純にマッピングするだけ
function PollingDashboard({ resourceIds }) {
return (
))}
);
}
この設計であれば、`resourceIds` の数がどれだけ変動しようとも、各 `ResourceItem` インスタンス内部のフックのリンクトリスト構造は常に `[useState, useEffect]` の2つで完全に固定される。ReactのReconcilerは効率的に差分検出し、V8のヒープ上でも予測可能でクリーンなメモリレイアウトが維持される。
—
結び：ランタイムと対話せよ
Reactのフックにおける「ループ内での宣言禁止」というルールは、制約という名の足かせではない。それは、V8という高速なJavaScriptランタイム上で、動的なUIの状態をO(N)の極めてシンプルかつ予測可能なアルゴリズムで同期させるための、極限まで洗練された物理的必然の設計なのだ。
フレームワークの仕様を表面的なお作法として覚えるのではなく、その背後にあるV8のヒープ、メモリレイアウト、そしてランタイムの挙動までを脳内で完全にトレースし尽くすこと。それこそが、トラブルシューティングを極め、真に堅牢なスケーラブル・アーキテクチャを構築するシニアエンジニアの条件である。