Context再レンダリング地獄からの脱出：Reactアーキテクトが直伝する、極限のパフォーマンス最適化
こんにちは。日々、巨大なReactアプリケーションのパフォーマンスプロファイリングとコードレビューに明け暮れるチーフアーキテクトの私だ。
君も経験があるはずだ。グローバルな状態を管理するために軽率に導入した `useContext`。アプリが成長し、ツリーの深さが増すにつれて、入力フォームに1文字打ち込むだけで、画面全体のコンポーネントが盛大に再レンダリングを始める。React DevToolsのプロファイラーを開けば、コンポーネントツリーが真っ赤に燃え上がり、CPU使用率は跳ね上がり、ユーザーからの「なんかこのアプリ重いんだけど」という無慈悲なフィードバックが飛んでくる。
「ReactのContextは状態管理の銀の弾丸ではない」——これは耳にタコができるほど聞いたセリフだろう。しかし、なぜContextはこれほどまでにパフォーマンスを破壊するのか。そして、ReduxやZustandといった外部の状態管理ライブラリに逃げ込むことなく、純粋なReactのプリミティブだけで、この「再レンダリング地獄」をどうやってねじ伏せるのか。
今回は、ブラウザのレンダリングパイプラインとReactの内部 reconciliation（調停）のメカニズムまで踏み込みながら、Contextを極限まで最適化するためのアーキテクチャを解説しよう。
—
なぜ `useContext` はすべてのコンポーネントを燃やすのか？
まず、Reactの内部挙動を正しく理解しよう。多くのエンジニアが犯す最大の勘違いは、「Contextの値の一部が変更されたとき、そのプロパティを使っているコンポーネントだけが再レンダリングされる」という誤解だ。
現実は残酷だ。`useContext` をフックしているコンポーネントは、Contextのオブジェクト参照が変わった瞬間、選択しているプロパティに関わらず無条件で再レンダリングの対象になる。
例えば、以下のようなコードを書いていないだろうか？
// よくある「アンチパターン」のContext
interface AppContextType {
user: { name: string; email: string };
theme: ‘light’ | ‘dark’;
updateTheme: (theme: ‘light’ | ‘dark’) => void;
}
const AppContext = createContext
この設計の何が地獄かというと、ユーザーの名前（`user.name`）を画面の隅っこで表示したいだけのコンポーネントがあったとしよう。ユーザーがダークモードに切り替えた瞬間（`updateTheme` が呼ばれ、新しいオブジェクトが生成される）、`theme` しか使っていないはずのそのコンポーネントも含め、`AppContext` を購読しているすべてのコンポーネントが容赦なく再レンダリングされる。
これが、Contextが「状態の爆弾」と呼ばれる理由だ。
—
解決策1：状態と更新関数の分離（State / Dispatch Separation）
最初に行うべき極めて実用的な防衛策は、「頻繁に変わる値（State）」と「絶対に変わらない関数（Dispatch）」を同じContextに混ぜないことだ。
Reactの `useReducer` や `useState` が返すディスパッチ関数（あるいはメモ化されたコールバック）は、そのライフサイクルを通じて参照が完全に維持される（Stale Closureにさえ気を付ければ、再生成されることはない）。
これをContextに適用すると、以下のようになる。
import React, { createContext, useContext, useReducer, useMemo, ReactNode } from ‘react’;
// 状態とアクションを完全に分離する
interface State {
count: number;
text: string;
}
type Action =
| { type: ‘INCREMENT’ }
| { type: ‘SET_TEXT’; payload: string };
const initialState: State = { count: 0, text: ” };
// 1. 値を保持するContext
const StateContext = createContext
// 2. 更新関数を保持するContext（参照が一生変わらない）
const DispatchContext = createContext
export const AppProvider: React.FC<{ children: ReactNode }> = ({ children }) => {
const [state, dispatch] = useReducer((state: State, action: Action): State => {
switch (action.type) {
case ‘INCREMENT’:
return { …state, count: state.count + 1 };
case ‘SET_TEXT’:
return { …state, text: action.payload };
default:
return state;
}
}, initialState);
return (
{children}
);
};
// 専用のカスタムフックを用意し、型の安全性を担保する
export const useAppState = () => {
const context = useContext(StateContext);
if (!context) throw new Error(‘useAppState must be used within an AppProvider’);
return context;
};
export const useAppDispatch = () => {
const context = useContext(DispatchContext);
if (!context) throw new Error(‘useAppDispatch must be used within an AppProvider’);
return context;
};
このアーキテクチャの美しさは、「ボタンのクリックイベントを発火させるためだけに `dispatch` を取得するコンポーネント」は、`State` がどれだけ高速に変化しようとも、一切再レンダリングされないという点にある。`DispatchContext` の値は永遠に不変だからだ。
—
解決策2：セレクターパターンの自作と `useMemo` による防衛
しかし、`State` 側はどうだろうか？ `count` が変わったとき、`text` しか使っていないコンポーネントは依然として再レンダリングされてしまう。
ここで、Reduxの `useSelector` のような仕組みをContextベースで自作する。React 18以降のConcurrent Renderingを見据えた、極めて堅牢なセレクターの実装を見てほしい。
import React, { createContext, useContext, useState, useMemo, ReactNode, useCallback } from ‘react’;
interface GlobalState {
user: { id: string; name: string };
settings: { theme: ‘light’ | ‘dark’; notifications: boolean };
}
const StoreContext = createContext<{
state: GlobalState;
subscribe: (listener: () => void) => () => void;
} | null>(null);
// ※実務ではuseSyncExternalStoreを使うのが現代の正解だが、
// Contextの仕組みを理解するためにここではあえて自作パターンの概念を示す。
もっと手っ取り早く、かつ現場で即座に使えるアプローチとして、「子コンポーネントの `React.memo` と Contextの分割」を組み合わせる手法がある。
例えば、頻繁に変わる値ごとにContextを細分化するのだ。
const UserContext = createContext<{ name: string } | null>(null);
const SettingsContext = createContext<{ theme: string } | null>(null);
「いやいや、Contextを何個も作るなんてボイラープレートが増えて冗長だ！」というツロ声が聞こえてきそうだが、パフォーマンスの最適化とコードの簡潔さはトレードオフだ。アプリケーションのボトルネックがどこにあるかをプロファイラーで見極めた上で、必要に応じてContextを分割するのがプロの仕事というものだ。
—
究極兵器：`useMemo` でレンダープロップス／childrenを包む
もう一つの強力なテクニックは、コンポーネントのツリー構造そのものをメモ化することだ。親コンポーネントが再レンダリングされても、`children` として渡されたJSXが再評価されるのを防ぐ。
import React, { useState, useMemo, ReactNode } from ‘react’;
interface HeavyTreeProps {
children: ReactNode;
}
// 親がどれだけ再レンダリングされても、このコンポーネント自体は再評価されない
const MemoizedContainer = React.memo(({ children }: HeavyTreeProps) => {
console.log(‘HeavyTree rendered!’);
return
;
});
export const ParentComponent: React.FC = () => {
const [count, setCount] = useState(0);
// 重い計算や、関係のない状態の変動
return (
{/ この中にある重いコンポーネント群は、countの変動から完全に保護される /}
);
};
const ComplicatedSubTree: React.FC = () => {
return
;
};
Reactのレンダリングにおいて、親が再レンダリングされると、その子孫もデフォルトではすべて再レンダリングの判定を受ける。しかし、`React.memo` や、状態を持つコンポーネントを末端に押し下げる（Colocation）テクニックを使うことで、不要な差分検出（Reconciliation）のコストを劇的に削減できる。
—
チーフアーキテクトからの提言
Contextは手軽で素晴らしい機能だが、大規模なアプリケーションにおいて「すべての状態を1つの巨大なContextにブチ込む」という設計は、自らパフォーマンスの時限爆弾を抱えるようなものだ。
1. State（状態）と Dispatch（更新関数）は必ずContextを分ける。
2. 状態は粒度を細かく分割し、必要なコンポーネントだけが購読するようにする。
3. どうしようもない重いツリーは `React.memo` と `children` のバケツリレーで守り抜く。
4. どうしても複雑なセレクターや派生状態のメモ化が必要になったら、素直に `useSyncExternalStore` や Zustand などの外部ストアの導入を検討する。
Reactは非常に素直なライブラリだ。我々開発者がコンポーネントのライフサイクルとメモリ上の参照関係を正しく把握し、意図通りにコントロールしてやれば、ブラウザは軽快に応えてくれる。
さあ、今すぐ君のアプリのプロファイラーを開き、無駄に再レンダリングされているコンポーネントたちを救い出してやってくれ健闘を祈る。
コメント