やあ、調子はどうだい？
最近、コードレビューをしていて一番頭を抱えるのが、この「Propsのバケツリレー」なんだよね。
親から子へ、子から孫へ、孫からひ孫へ……。画面の最深部にある小さなボタンのスタイルや状態を変えたいだけなのに、その間にある無関係なコンポーネントたちが「私は中身を知らないけれど、とりあえず次の奴に渡しますよ」というメッセンジャーの役割を強制されている。
気づけばコンポーネントの型定義（TypeScriptのInterface）は無駄に肥大化し、どこかで一つでもプロパティの名前を変えようものなら、中間パーツが総崩れする。
……おっと、君も心当たりがあるかい？
今回は、このReact開発における永遠の課題とも言える「バケツリレー問題」の本質と、それをスマートに解決するためのContext APIや状態管理ライブラリの正しい使い分けについて、現場のリアルな視点からガッツリ解説していこう。
—
なぜバケツリレーは「悪」なのか？ ブラウザの裏側とReactの再描画
まず大前提として、なぜPropsを何層も下にバケツリレーするのが実務的にヤバいのか。技術的な理由を整理しておこう。
Reactは、状態（State）が変化したときに、そのコンポーネント以下を再評価（Re-render）して仮想DOMの差分をとる仕組みだよね。
バケツリレーの何が問題かというと、「本当はそのデータに興味がない中間コンポーネントまで、親の状態変化に巻き込まれて無駄に再描画される」というコストが発生することだ。
例えば、`App`コンポーネントで管理している「ログインユーザーのテーマ設定（ダークモード）」を、5階層下の`ProfileButton`で使いたいとする。
途中の階層にある`Layout`や`Sidebar`といったコンポーネントは、テーマがダークになろうがライトになろうが、HTML構造としては何も変わらないはずだ。しかし、Propsとしてそのテーマ変数を受け回しているがために、`App`のStateが更新されるたびに、中間コンポーネントたちも連鎖的に再評価の嵐にさらされることになる。
これが小規模なアプリならブラウザのパワーでごり押せるけれど、実務で扱うような数千ノードを抱える大規模SPA（シングルページアプリケーション）では、確実にUIの「カクつき（Jank）」やパフォーマンス低下の原因になる。
—
解決策の引き出し：Context API vs 状態管理ライブラリ
このバケツリレーを断ち切るためのアプローチとして、主に以下の2つの選択肢が実務では使われる。
1. React標準の `Context API`
2. 外部の状態管理ライブラリ（Zustand, Jotai, Redux Toolkitなど）
よくある勘違いが、「とりあえず何でもかんでもReduxやZustandに入れればいいや」という思考停止パターン。逆に「外部ライブラリの依存を減らすために無理やりContextをネストさせる」のも悪夢を見る。
ここでシニアとしてのアドバイスだ。
- Context API は、「めったに変わらないが、アプリケーションの広範囲で参照したいグローバルな設定（テーマ、言語ロケール、認証ユーザー情報など）」に使う。
- Zustandなどの軽量状態管理ライブラリ は、「頻繁に更新され、かつ特定のコンポーネント群で共有したい状態（ショッピングカートの中身、複雑なフォームの状態、UIの開閉トグルなど）」に使う。
Contextは、「値が更新されると、それを購読している子孫コンポーネントがすべて強制的に再描画される」という特性を持っている。だから、高頻度で変わるデータをContextのど真ん中に置くと、パフォーマンスチューニングで頭を抱えることになるんだ。この点を絶対に忘れないでほしい。
—
実践！ 綺麗なコードで見る「Context API」の正しい型付け
百聞は一見にしかず。実務でそのまま使える、認証情報（User）を例にしたContext APIの堅牢な実装を見ていこう。TypeScriptの型付けもしっかり行う。
import React, { createContext, useContext, useState, ReactNode } from ‘react’;
// 1. 扱うデータの型定義
interface User {
id: string;
name: string;
role: ‘admin’ | ‘editor’ | ‘viewer’;
}
// 2. Contextが提供する値の型定義
interface AuthContextType {
user: User | null;
login: (userData: User) => void;
logout: () => void;
}
// 3. デフォルト値をundefinedとして作成（Provider外で使われた時の検知用）
const AuthContext = createContext
// 4. Providerコンポーネントの実装
interface AuthProviderProps {
children: ReactNode; // チルドレン属性の正しい型付け
}
export const AuthProvider: React.FC
const [user, setUser] = useState
const login = (userData: User) => {
// ここでAPI通信やトークン保存の処理が入るイメージ
setUser(userData);
};
const logout = () => {
setUser(null);
};
return (
{children}
);
};
// 5. 現場で重宝する「カスタムHook」によるラップ
// これにより、使う側で毎回 useContext(AuthContext) を書く手間とnullチェックを省ける
export const useAuth = (): AuthContextType => {
const context = useContext(AuthContext);
if (context === undefined) {
throw new Error(‘useAuth must be used within an AuthProvider’);
}
return context;
};
使う側のコード（深層コンポーネント）
さて、これをどう使うか。途中にいる無関係なコンポーネント（LayoutやPage）を一切スルーして、最深部のボタンから直接ユーザー情報を呼び出してみよう。
import React from ‘react’;
import { useAuth } from ‘./AuthProvider’; // 先ほどのカスタムHookをインポート
export const DeepNestedButton: React.FC = () => {
// バケツリレーなしで、必要なデータと関数を直接取得！
const { user, logout } = useAuth();
if (!user) {
return
ログインしていません。
;
}
return (
ようこそ、{user.name} さん（権限: {user.role}）
);
};
どうだい？ これなら中間コンポーネントの型定義を汚染することもなければ、不要なPropsの受け渡しでコードが汚れることもない。美しく、メンテナブルな構造だよね。
—
シニアからの実践的なアドバイス
最後に、現場で設計に迷ったときの指針をいくつか授けておこう。
1. 「まずはPropsでいいか」の罠に落ちない
「とりあえず数階層だからPropsでいいや」と安易に始めると、後から仕様変更で「さらに2階層下にこのデータを渡して」と言われた瞬間に地獄を見る。コンポーネントのツリー構造が深くなりそうだと予見できるなら、最初からContextや状態管理のスコープを検討する勇気を持とう。
2. Contextの乱立に気をつけろ
「状態ごとにContextを作ろう」といって、`ThemeContext`, `UserContext`, `NotificationContext`, `SettingsContext`……と何でもかんでもContextで包みまくると、今度はJSXのツリーがProviderだらけ（いわゆる「Providerのピラミッド」）になって可読性が死ぬ。関連するドメインごとにうまくまとめるか、複雑なものはZustand等の軽量ストアに逃がすバランス感覚がプロの腕の見せ所だ。
フロントエンドのアーキテクチャに「絶対的な正解」はない。しかし、「なぜその選択をしたのか」をチームメンバーにロジカルに説明できるコードこそが、優れたエンジニアの証だ。
今回の解説が、君の次のリファクタリングや新規設計のヒントになれば最高に嬉しいね。さて、美味しいコーヒーでも飲んで、またコードを書くとしようか！
コメント