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

コードレビューの最中、もしジュニアやミドルクラスのエンジニアが次のようなコードを書いていたら、私は即座にマージを差し戻す。

// ❌ やってはいけない最悪のパターン
function UserDashboard({ users }) {
const [activeTab, setActiveTab] = useState(‘profile’);

// 条件分岐やループの中でフックを呼び出している
if (!users) {
const [loading, setLoading] = useState(true); // ← 致命的なバグの温床
return ;
}

return (

{users.map(user => {
const [isExpanded, setIsExpanded] = useState(false); // ← ループ内のフック
return ;
})}

);
}

「なぜこれが動かないのか」「なぜReactのドキュメントで『トップレベルでのみフックを呼び出せ』と厳禁されているのか」。これを単なる“お作法”として暗記しているうちは、フロントエンドのパフォーマンスチューニングや高度な状態管理において必ず致命傷を負う。

今回は、V8エンジンのメモリ管理とReactの内部ファイバー（Fiber）構造の観点から、フックの裏側で何が起きているのかを完全解剖し、実務で絶対に破綻しない設計パターンを伝授する。

—

1. なぜループや条件分岐でフックを宣言してはならないのか？

結論から言えば、Reactはフックの識別を「変数名」ではなく「呼び出し順序（インデックス）」で行っているからだ。

Reactの内部では、コンポーネントごとの状態（State）や副作用（Effect）は、単なる連結リスト（Linked List）としてメモリ上に順序よく保持されている。

V8ヒープとファイバーのメモリレイアウト

Reactのレンダリングライフサイクルにおいて、コンポーネントは`Fiber`と呼ばれるJavaScriptオブジェクトとしてV8のヒープ領域に存在する。このFiberノードは、内部に `memoizedState` というポインタを持っている。これがフックのリンクリストの先頭を指している。

1. 初回レンダリング時、`useState` が呼ばれるたびにリンクリストにノードがアペンドされ、インデックス `0`, `1`, `2`… と順番にスロットが割り当てられる。
2. 2回目以降の再レンダリング時、Reactは変数名やキーを見て状態を復元しているわけではない。「1番目に呼ばれたから `useState` のスロット0」「2番目だからスロット1」というふうに、完全な順序依存（Array-likeなアクセス）でメモリから値を引き出している。

もし、ループや条件分岐の中でフックを呼ぶとどうなるか？

// ⚠️ 条件によってフックの呼び出し順序がズレる例
let isRegistered = false;

function BadComponent() {
let name, setName;
if (isRegistered) {
[name, setName] = useState(‘John’); // 呼び出されたり、スキップされたりする
}
const [theme, setTheme] = useState(‘dark’); // インデックスが狂う！
}

初回レンダリングで `isRegistered = false` だった場合、`theme` はインデックス `0` に割り当てられる。
しかし、次のレンダリングで `isRegistered = true` に変わると、1番目に `useState(‘John’)` が呼ばれてしまうため、本来 `theme` が格納されるべきスロットに `name` の状態が上書きされてしまう。

結果として、全く関係のないコンポーネントの状態がバグり、最悪の場合はハングアップやクラッシュを引き起こす。これが、Reactが「フックをトップレベルでのみ呼び出せ」と強制する物理的理由である。

—

2. 実務で遭遇するアンチパターンと「正解の設計」

では、実際の開発で「配列の要素ごとに独立した状態を持ちたい」「動的にフックを増やしたい」という要件に直面した時、どう設計すべきなのか。

よくあるアンチパターンと、それを美しく解決するプロダクションコードを見ていこう。

❌ 悪い設計：配列ループ内でフックを呼ぶ（前述の再掲）

// 動的に増えるリストアイテムに直接フックを持たせようとする愚行
function TodoList({ todos }) {
return (

;
})}

);
}

⭕ 正しい設計：子コンポーネントを切り出す（コンポーネント分離の原則）

Reactのフックは「コンポーネントのトップレベル」であれば何個でも、どんな複雑なコンポーネントツリーでも安全に機能する。したがって、ループの各要素は独立した子コンポーネントにカプセル化するのが鉄則だ。

// 1. 各要素を担当する独立した子コンポーネント
function TodoItem({ todo }) {
// このコンポーネントのトップレベルなので安全にフックを使える
const [isEditing, setIsEditing] = useState(false);
const [text, setText] = useState(todo.text);

return (

{isEditing ? (
setText(e.target.value)} />
) : (
{text}
)}

);
}

// 2. 親コンポーネントはリストの管理に集中する
export function TodoList({ todos }) {
return (

))}

);
}

この設計であれば、V8エンジン上のFiberツリー構造も美しく保たれ、Reactの差分検出アルゴリズム（Reconciliation）も最大限に効率化される。不要な再レンダリングを防ぎ、DOM操作のパフォーマンス低下を防ぐことができる。

—

3. さらに踏み込む：状態の正規化（Normalization）による高度なアプローチ

もし、子コンポーネントに分離するだけでは解決しない、例えば「リスト全体のデータを一元管理しつつ、一部の要素の状態を非同期API連携と連動させたい」という複雑な要件がある場合はどうするか。

ここで、状態を配列のままではなくオブジェクト（マップ）として正規化するテクニックが極めて有効になる。

import React, { useState, useCallback } from ‘react’;

// 実務で使える堅牢なリスト管理パターン
export function AdvancedDashboard({ initialItems }) {
// 配列ではなく、IDをキーにした辞書型（Map/Object）で状態を保持する
// これにより、O(1)の計算量で特定要素の状態にアクセスできる
const [expandedMap, setExpandedMap] = useState({});

const toggleExpand = useCallback((id) => {
setExpandedMap(prev => ({
…prev,
[id]: !prev[id] // 不変性（Immutability）を担保した更新
}));
}, []);

return (

{initialItems.map(item => (

))}

);
}

// 子コンポーネント側では余計なフックを持たせず、純粋なプレゼンテーションに徹する
const DataCard = React.memo(function DataCard({ item, isExpanded, onToggle }) {
return (

{item.title}

{isExpanded &&

{item.heavyPayload}

}

);
});

この設計が優れている理由

1. フックの呼び出し順序違反が構造的に起こらない: ループ内でフックを排除し、親側で状態をハッシュマップとして管理しているため、Reactのインデックスベースのメモリ割り当てを完全に保護できる。
2. パフォーマンスの最適化 (`React.memo` の効力を最大化): リストの1つのアイテムを開閉しても、`expandedMap` の更新に関係のない他の `DataCard` は `React.memo` によって再レンダリングから完全にバイパスされる。巨大なDOMツリーを持つWebアプリケーションにおいて、これは致命的なパフォーマンス劣化を防ぐための必須要件だ。

—

最後に：シニアエンジニアとしての心得

JavaScriptのコードを書くとき、私たちは常に「目の前のコードがランタイムのメモリ空間でどう解釈されるか」を想像しなければならない。

Reactのフックは魔法の杖ではない。それはV8エンジンのヒープ上に展開される泥臭いリンクリストのラッパーに過ぎない。その内部メカニズム（順序依存性）を正しく理解していれば、「なぜループ内で書いてはいけないのか」という問いに対して、ドキュメントの丸暗記ではなく、自信を持ってアーキテクチャの観点から説明できるようになるはずだ。

保守性が高く、バグの影すら踏まない堅牢なコードベースを、自らの手で築き上げよう。