ReactのContextの使い方とアンチパターン【プロが徹底解説】

モダンWeb開発2026.04.172026.04.17

執筆者編集部

MT Templates 編集部

監修者MT Templates 代表/編集長

大野浩史

この記事のポイント

React ContextはPropsバケツリレーを解消して状態を共有する標準機能であり、再描画を防ぐContext分割やメモ化による最適化と、規模に応じた外部状態管理ライブラリとの的確な使い分けによって保守性の高いアーキテクチャを実現します。

Reactコンポーネントの開発において、Propsのバケツリレーを解消してスマートに状態を共有したい場面は多いですよね。しかし、React Contextの正しい使い方や、再レンダリングを防ぐ保守性の高い設計にはコツが必要です。

こうした疑問にお答えします。

本記事の内容

React Contextの基本概念と具体的な実装手順
不要な再レンダリングを防ぐためのパフォーマンス対策
Reduxなど他の状態管理ライブラリとの使い分け基準

React Contextを活用すれば、複数のコンポーネント階層を飛び越えてデータを直接受け渡し、複雑なProps管理から解放されます。

「React Context APIは非推奨ではないか」「使わないほうがいいケースやアンチパターンが知りたい」といった実務的な不安も解消できるはずです。最適化の手法を身につけて、効率的なフロントエンド開発を目指しましょう。

React Contextの基礎知識

React Contextは、Reactとは何かを踏まえた上で活用する、コンポーネントツリー全体でデータを共有するための強力な仕組みです。React Contextの使い方をマスターすれば、深い階層へのデータ伝達がスムーズになります。

React Contextは主に以下の要素で構成されています。

createContext：Contextオブジェクトを生成する関数
Provider：配下のコンポーネントに対してデータを提供するコンポーネント
useContext：提供されたデータを読み取るためのReact Hooks

Propsのバケツリレーの解消

React Contextはpropsの受け渡しを効率化し、Propsバケツリレーと呼ばれる問題を解決します。この問題は、データが必要ない中間コンポーネントにまでpropsを記述することで発生します。

Contextを導入することで、データフローは以下のように改善されます。

項目	Propsによる受け渡し	React Contextによる受け渡し
データ伝達	1階層ずつ順番に渡す	必要なコンポーネントが直接取得
中間コンポーネント	利用しないpropsの記述が必要	データの記述が不要
メンテナンス性	修正箇所が多くなりがち	変更の影響範囲を最小限に抑止

バケツリレーを解消すれば、コードの可観測性が高まり、保守しやすい設計が実現可能です。

コンポーネント間での状態共有

React Contextは、アプリケーション全体で動的な状態を共有する際に非常に便利です。Providerの値を更新することで、どの階層からでも最新の状態を参照できます。

ただし、React Contextにおける再レンダリングの仕様には注意が必要です。Providerの値が変化すると、その値を参照している全てのコンポーネントが再描画されます。設計時は以下の点を意識してください。

不要な再レンダリングの防止：Contextの分割やメモ化を検討してください
状態の粒度：一つのContextに情報を詰め込みすぎないのがコツです
パフォーマンス：高頻度で更新される値は慎重に設計します

導入に適したプロジェクト規模

React Contextは、標準機能だけでグローバルな状態管理を実現できるため、小中規模のプロジェクトに最適です。特にテーマ切り替えやユーザー認証情報の管理に向いています。

Contextの導入が推奨される具体的なケースは以下の通りです。

ログインユーザーのプロフィール情報
ダークモードなどのカラーテーマ設定
多言語対応の言語設定

非常に複雑な状態遷移が必要な場合は、ReduxやZustandなど他のライブラリと比較検討してください。まずは標準のContextで対応可能か判断するのが良いでしょう。

React Contextの実装手順

React Contextの使い方は非常にシンプルで、最新の関数コンポーネントとHooksを組み合わせるのが一般的です。以下では、Contextの作成からデータの更新まで、実装の流れをステップごとに解説します。

①：createContextで作成する

まずは共有したいデータの入れ物として、Contextオブジェクトを作成しましょう。これにはReact標準のcreateContext関数を使用し、React TypeScriptで型定義を行えば値の構造をエディタが補完してくれます。

Contextを作成する際は、必ずデフォルト値を設定してください。この値はProviderの外側でコンポーネントが呼び出された場合に参照される重要なデータです。

import { createContext } from 'react';

// Contextの作成
export const UserContext = createContext({
  name: 'Guest',
  isLoggedIn: false,
  login: () => {},
});

デフォルト値にオブジェクトを指定しておくと、データの構造が明確になり開発時のエラーも防げます。React Context APIは非推奨ではありませんが、適切な初期値設定が運用の鍵を握ります。

②：Providerでコンポーネントをラップする

Contextオブジェクトが準備できたら、データを供給するためのProviderを設置します。Providerはその配下にある全てのReactコンポーネント設計されたパーツへデータを配信する役割を担います。

アプリ全体で使うなら上位層に、特定の機能内だけならそのルートに配置しましょう。複数のContextを利用する場合も、Providerをネストさせることで整理できます。

import { useState } from 'react';
import { UserContext } from './UserContext';

function App() {
  const [user, setUser] = useState({ name: 'Guest', isLoggedIn: false });

  return (
    <UserContext.Provider value={user}>
      <Header />
      <MainContent />
    </UserContext.Provider>
  );
}

コンポーネントをProviderでラップすれば、配下のどこからでもUserContextへのアクセスが可能です。React ContextならReduxのような外部ライブラリを入れずとも、手軽に状態共有が実現します。

③：value属性で値を渡す

Providerには必ずvalue属性を指定し、共有したい実データを渡します。単一の値だけでなく、複数の状態や関数をまとめたオブジェクトを渡す運用も一般的です。

渡すデータの種類によって、以下のような使い分けが考えられます。

データの種類	具体例
単一の値	ダークモードの設定情報
オブジェクト	ユーザー名や権限情報のセット
状態と関数のセット	現在の数値とそれを操作するメソッド

valueに渡した値が変更されると、そのContextを購読している全コンポーネントが再レンダリングの対象となります。大規模なアプリでは不要な処理を避ける工夫が必要ですが、小規模なら非常に便利な仕組みです。

④：useContextでデータを参照する

Providerが提供するデータを利用するには、子コンポーネント側でuseContextフックを呼び出します。以前のConsumerコンポーネントを使う方法に比べ、React Hooksの全体像で位置づけられる新しいHooks APIなら非常に簡潔に記述できるのがメリットです。

propsを何層も受け渡す苦労から解放され、コードの見通しが劇的に改善します。

import { useContext } from 'react';
import { UserContext } from './UserContext';

function UserProfile() {
  // contextから値を取り出す
  const user = useContext(UserContext);

  return (
    <div>
      <p>現在のユーザー: {user.name}</p>
    </div>
  );
}

useContextにContextオブジェクトを渡すだけで、最新の値を即座に参照可能です。Propsの記述がなくなるため、コンポーネント間の依存関係もスッキリと整理されます。

⑤：状態を更新する関数を提供する

React Contextはデータの参照だけでなく、状態の更新にも活用できます。ProviderのvalueにuseStateの更新関数を含めれば、深い階層からグローバルな状態を書き換え可能です。

状態更新を実装する際の主なステップは以下の通りです。

Provider側のコンポーネントでuseStateを定義する
状態と更新用関数をオブジェクトにまとめてvalueへ渡す
利用側のコンポーネントでuseContextを使い、その関数を実行する

// Provider側での定義例
const value = {
  user,
  updateName: (newName) => setUser({ ...user, name: newName })
};

return <UserContext.Provider value={value}>{children}</UserContext.Provider>;

このように設計すれば、データの管理と配信をProviderに集約できます。ロジックが一箇所にまとまるため、Context未使用の場合に比べてコードの品質が安定します。

React Contextのアンチパターン

React Contextは便利な機能ですが、設計を誤るとパフォーマンス低下やコードの可読性悪化を招きます。大規模な開発ほどこれらのアンチパターンが開発効率を阻害するため、正しい知識で設計することが重要です。

ここでは、React開発者が陥りやすい代表的なアンチパターンを5つの観点で詳しく解説します。

頻繁に更新される状態での利用

React Contextを頻繁に更新される状態で使うことは推奨されません。テキスト入力の同期やアニメーション中の数値管理などが該当します。

Contextの値が更新されると、Provider配下でuseContextを利用するすべてのコンポーネントが強制的に再レンダリングされます。コンポーネントが更新されたプロパティに依存していなくても再レンダリングの対象となるため、注意が必要です。

具体例：毎秒更新されるタイマーの値をContextで共有する
影響：アプリ全体のレンダリング負荷が増大し、ユーザー体験を損なう

頻繁な更新が必要な場合は、個別のStateで管理するか、RecoilやJotaiといった外部ライブラリの検討をおすすめします。React Contextを使わないという選択肢も、パフォーマンス維持には重要です。

複数状態の単一コンテキストでの一括管理

状態と更新関数を一つのContextオブジェクトにまとめて格納するのは、典型的なアンチパターンです。

一つのオブジェクトにまとめると、更新関数しか必要としないコンポーネントも、値が変わるたびに不要な再レンダリングが発生します。

項目	アンチパターンの構成	推奨される構成
格納方法	値と関数を一つのProviderで提供	値用と関数用でProviderを分割
影響範囲	値の変更時に関数のみ使う側も再描画	必要なコンポーネントのみが再描画
保守性	依存関係が複雑になりやすい	役割が明確になり可読性が向上する

役割に応じて複数のContextを使い分けることで、無駄な描画を抑制し最適化を実現できます。

Providerの過剰なネスト

共通化を優先して上位階層で大量のProviderを重ねる「Provider Wrapping Hell」も避けるべきです。

階層が深すぎるとデータの供給元が不明確になり、コンポーネントのテストも困難になります。解消するには次の指針を参考にしてください。

グローバルな設定のみをトップレベルに配置する
特定の機能に関連するContextは、その親コンポーネントに配置する
不要になったProviderは適切に削除する

コンテキストのスコープを最小限に留めることが、クリーンなアーキテクチャを維持するコツです。

不要な再レンダリングの放置

Providerに渡すvalueオブジェクトをuseMemoでメモ化せずに渡すと、親が再描画されるたびに新しいオブジェクトとして認識されます。

これにより、実質的な値に変化がなくても、配下の子コンポーネントすべてに再レンダリングが発生します。

原因：valueにインラインでオブジェクトを生成して渡している
解決策：useMemoを使用して依存配列が変化しない限り同じオブジェクトを再利用する

// 推奨：useMemoにより再レンダリングを最小限に抑える
const value = useMemo(() => ({ state, dispatch }), [state, dispatch]);

JavaScriptのオブジェクト参照の仕組みを理解し、適切にuseMemoを活用することが不可欠です。

非推奨APIの流用

React 16.3以前の旧式APIや、クラスコンポーネント時代の古い実装方法を使い続けることは避けてください。

これらは最新の並行レンダリング機能と互換性が低く、将来削除される可能性があります。

回避すべき手法：static childContextTypes や getChildContext
推奨される手法：createContext と useContext フックの組み合わせ

現代のReact Contextの使い方は、関数コンポーネントとHooksが標準です。カスタムフックとしてラップして公開することで、propsのバケツリレーを防ぎつつ安全に実装できます。

React Contextを使った状態管理アーキテクチャの選定

Reactアプリケーションを開発する際、コンポーネント間でデータを共有する手法の選定は非常に重要です。React Contextは標準機能として提供されている強力なツールですが、あらゆるケースで最適ではありません。

適切なアーキテクチャを選ぶには、アプリの規模や更新頻度、チームの習熟度を考慮する必要があります。React Context APIが公式に推奨されるのは、言語設定やテーマ切り替えなど頻繁に更新されないデータです。ビジネスロジックが複雑で更新頻度が高い場合は、外部ライブラリを検討しましょう。

ここでは、開発規模や要件に応じた4つの選定基準を詳しく解説します。

標準機能のみのシンプルな設計

小規模なアプリや外部ライブラリへの依存を減らしたい場合は、React標準のContext APIが鍵となります。useStateやuseReducerと組み合わせる設計は、シンプルで非常に効果的です。

この手法は追加のインストールが不要で、Reactの基本原則を守りやすい点がメリットです。ただし、再レンダリング問題によるパフォーマンス低下を防ぐため、以下の点に注意してください。

状態と更新関数を分割する。値と更新関数を別々のContextで提供すれば、参照のみのコンポーネントは再描画されません。
Providerの肥大化を防ぐ。一つのProviderに多くを詰め込みすぎず、適切に複数のContextを使い分けることが大切です。

標準のContext APIと外部ライブラリの特性を以下に整理しました。

項目	標準Context API	外部状態管理ライブラリ
学習コスト	低い（基本知識のみ）	中〜高（独自のAPI学習が必要）
パフォーマンス	頻繁な更新には不向き	高（最適化機能が組み込み済み）
ボイラープレート	少ない	ライブラリにより異なる