こんにちは。フロントエンドの現場で日々、DOMの差分アルゴリズムやメモリ上の参照関係と格闘しているエンジニアの皆さん。
Reactアプリケーションが成長するにつれて、「なぜか再描画が走らない」「ユーザーの入力と画面の表示がズレる」「メモ化（`useMemo` / `React.memo`）を入れているのに、全く最適化が効かない」といった怪奇現象に直面したことはないだろうか？
その多くは、Reactの根幹をなす哲学――「イミュータビリティ（不変性）」の破壊が原因だ。
今回は、`useState`におけるオブジェクトや配列の扱い方を取り上げ、なぜ直接のミューテーション（破壊的変更）がReactのエンジンを狂わせるのか、ブラウザのメモリ効率やレンダリングパイプライン、そして非同期更新のコンテキストから徹底的に紐解いていこう。
—
なぜReactは「参照の比較」に命をかけているのか
まず、JavaScriptのエンジンとReactのコアアルゴリズムの挙動を思い出してほしい。
JavaScriptにおいて、プリミティブ型（数値や文字列など）は値そのものが比較されるが、オブジェクトや配列などの参照型は、「メモリ上のアドレス（どこに格納されているか）」だけが比較される。
Reactの調停者（Reconciler）は、パフォーマンスを極限まで高めるため、状態（State）やプロパティ（Props）が変化したかどうかを判定する際、深層比較（Deep Equality）を行わない。なぜなら、巨大なオブジェクトのツリー構造を毎回ディープコピーして再帰的に比較するのは、ブラウザのメインスレッドを殺すほどの重い処理だからだ。
代わりにReactは、「参照（Reference）が変わっていなければ、中身も変わっていない」という厳格な前提（Shriow Equality）のもとで動いている。
ここに、直接ミューテーションを行うことの致命的な矛盾がある。
// 【アンチパターン】絶対にやってはいけないミューテーション
const [user, setUser] = useState({ name: ‘Alice’, age: 30 });
const handleUpdate = () => {
user.age = 31; // オブジェクトの「中身」だけを直接書き換える
setUser(user); // Reactは「同じ参照だ」と判断し、変更を無視する可能性がある
};
上記のコードでは、`user`というオブジェクトのメモリ上の住所は一切変わっていない。そのため、Reactが「お、同じ参照だな。再描画の必要はないな」と判断し、画面が更新されない（あるいは、他の最適化機構が完全にバグる）という最悪の挙動を引き起こす。
—
スプレッド構文の限界と「浅いコピー」の罠
この問題を回避するため、私たちはスプレッド構文（`…`）を用いたイミュータブルな更新を叩き込まれる。
// 【基本のイミュータブル更新】
setUser(prevUser => ({
…prevUser,
age: 31
}));
これによって、JavaScriptエンジンは新しいオブジェクトのメモリ領域を確保し、古いオブジェクトとは異なる参照（Reference）を持つインスタンスを生成する。Reactはこの新しい参照を検知し、「おや、参照が変わったぞ。差分計算を走らせよう」と健全なレンダリングパイプラインを起動する。
しかし、シニアエンジニアであればここで一段深く思考を巡らせなければならない。スプレッド構文は「シャローコピー（浅いコピー）」でしかない、という事実を。
もし状態がネストしたオブジェクト構造だったらどうなるだろうか？
const [state, setState] = useState({
user: {
name: ‘Bob’,
address: {
city: ‘Tokyo’,
zip: ‘100-0001’
}
}
});
// ネストしたプロパティの不適切な更新
const handleCityChange = () => {
// これでは address オブジェクトの参照は切り替わっていない！
setState(prevState => ({
…prevState,
user: {
…prevState.user,
address: {
city: ‘Osaka’ // zip がごっそり消えるし、参照の連鎖も断ち切られている
}
}
}));
};
ネストが深くなるにつれて、スプレッド構文を何重にも手書きするのはコードの可読性を下げるだけでなく、些細なタイポで既存のプロパティを消失させる（上記のように `zip` を巻き込み忘れるなど）クリティカルなバグの温床となる。
—
非同期バグと競合状態（Race Condition）の防衛策
状態の更新が「非同期」で行われるというReactの仕様も、イミュータビリティと絡むと牙をむく。
`useState`のセッターに直接新しいオブジェクトを渡す場合、複数の更新が短時間に連続して発生すると、古いステートのスナップショットを掴んでしまい、更新が上書きされて消える「ステートの競合」が起きる。
これを防ぐには、関数型アップデート（Updater Function）とイミュータビリティを組み合わせるのが、実務における鉄則中の鉄則だ。
実践的な堅牢コード例
ここでは、ネストした複雑なオブジェクト状態を持つフォームデータを、パフォーマンスと安全性を担保しながら更新するカスタムフック的なアプローチの例を示そう。
import React, { useState, useCallback } from ‘react’;
export const ComplexProfileManager = () => {
const [profile, setProfile] = useState({
id: ‘usr_001’,
personal: {
firstName: ‘Taro’,
lastName: ‘Yamada’,
contact: {
email: ‘taro@example.com’,
phone: ‘090-0000-0000’
}
},
settings: {
theme: ‘dark’,
notifications: true
}
});
// イミュータビリティを保ちつつ、特定のネストされたプロパティを安全に更新する汎用ハンドラ
const handleNestedChange = useCallback((category, field, value) => {
setProfile(prevProfile => {
// 関数型アップデートにより、常に「最新の」prevProfileを参照する
return {
…prevProfile,
[category]: {
…prevProfile[category],
[field]: value
}
};
});
}, []);
// さらに深くネストしたプロパティ（contact.emailなど）を更新する例
const handleDeepNestedChange = useCallback((field, value) => {
setProfile(prevProfile => ({
…prevProfile,
personal: {
…prevProfile.personal,
contact: {
…prevProfile.personal.contact,
[field]: value // 該当フィールドだけを安全に差し替え、他のプロパティは参照を維持する
}
}
}));
}, []);
return (
Profile Manager (Immutable Pattern)
名前: {profile.personal.firstName} {profile.personal.lastName}
メール: {profile.personal.contact.email}
{/ 名前の更新（第1階層のネスト） /}
{/ メールの更新（第2階層のネスト） /}
);
};
このコードの美しいところは、変更されたブランチ（枝）だけ新しい参照を作り、変更されていない他のブランチ（例えば `settings` や `lastName`）は古い参照をそのまま維持（Structural Sharing / 構造的共有）している点だ。
—
構造的共有（Structural Sharing）がもたらすメモリ効率の魔術
ReduxやImmer、あるいはReact本体が内部で行っている状態管理の神髄は、この「構造的共有」にある。
全てのオブジェクトを毎回完全にディープコピーしていたら、メモリの消費量は爆発し、ガベージコレクタ（GC）の負荷が高まってフレームレートがドロップする。
しかし、不変性を守りながら「変更された部分のパスだけ新しいオブジェクトを作り、変更のない部分は既存の参照を使い回す」ことで、メモリ効率を極限まで高めつつ、Reactの差分検出アルゴリズムを高速に機能させることができるのだ。
手動でのスプレッド構文の多用がつらい場合は、実務では Immer などのライブラリを導入し、一見ミュータブルに見える記述（`draft.personal.contact.email = …`）を書きながら、内部で自動的にイミュータブルなツリーを生成させるアプローチも非常に合理的である。
—
まとめ：真にスケーラブルなコードを書くために
Reactにおけるイミュータビリティとは、単なる「お作法」や「ルールブックの縛り」ではない。
1. ブラウザのメモリとガベージコレクタへの優しさ（構造的共有）
2. Reactのレンダリングパイプラインを正確に駆動させるための唯一の言語
3. 非同期バグや競合状態を防ぐための堅牢性の担保
これらを理解しているエンジニアと、ただ動くだけのコードを書くエンジニアとでは、アプリケーションが10万行を超えたときのアーキテクチャの崩壊スピードに圧倒的な差が出る。
「なぜこの参照を変えなければならないのか？」
その背後にあるブラウザエンジンやReactの内部挙動を常に意識し、美しく、かつ鉄壁のイミュータビリティをあなたのコードベースに宿してほしい。
コメント