React Compilerとは｜自動メモ化の仕組みと使い方・導入判断

React Compilerとは｜ビルド時にメモ化を埋め込む仕組み

結論から言えば、React Compilerは実行時に動くライブラリではなく、ビルド時にコードを書き換えるツールです。あなたの書いたコンポーネントを読み、再レンダリングのたびに作り直す必要のない値を見つけ、それをキャッシュするコードへ変換します。

Reactチームは公式ドキュメントで、コンパイラが最適化する対象を2つ挙げています（React Compiler の概要｜React）。

1. 親の再レンダリングが子へ連鎖的に波及するのを止める

2. コンポーネント内で行われる重い計算の結果をキャッシュする

どちらも、従来は開発者がReact.memoやuseMemoを手で貼って対処してきた領域です。

ビルド時にメモ化コードを埋め込むとはどういうことか

コンパイラを通したコードは、ビルド後にキャッシュ用の配列を持つ形へ書き換わります。公式ドキュメントが示す出力例では、react/compiler-runtime からキャッシュ関数を読み込み、「前回と同じ入力なら保存済みの値を返し、違うなら作り直して保存する」という分岐が自動で挿入されます。

ポイントは、この判定が値の中身ではなく参照の一致で行われることです。ここはuseMemoの第2引数と同じ考え方なので、手動メモ化を理解している人ほど挙動を予測しやすくなります。

useMemo・useCallback・React.memoとの違い

3つのAPIとの関係は、置き換えというより「自動化と手動の使い分け」です。

Reactチームは、新規に書くコードはコンパイラに任せ、useMemo・useCallbackはエスケープハッチ、つまりコンパイラに任せず手動で意図を固定したい場面の例外的な制御手段として残す方針を示しています。たとえばEffectの依存関係を厳密に制御したい場面では、これまでどおりuseCallbackを明示したほうが意図が伝わります。

v1.0に至るまでの経緯と、対応するReactのバージョン

React Compilerは2024年に実験版として公開され、リリース候補を経て2025年10月7日に1.0へ到達しました。npmで公開されているbabel-plugin-react-compilerは、2026年11月11日に確認した時点では1.0系が配布されています。npmの最新版は変動するため、導入時にあらためて確認してください。

バージョン番号が長く動いていないことは、必ずしも開発の停滞を意味しません。公式ブログでは今後の方向性として、swcやoxcといった高速な実行基盤への対応にも触れられています。

対応するReactのバージョンは、公式ドキュメント上はReact 17以降です。ただし追加設定なしで素直に動くのはReact 19で、17や18で使う場合はコンパイラ設定に最小ターゲットを指定し、react-compiler-runtime を依存関係へ追加する必要があります。参画先がReact 18のままというケースは珍しくないので、ここは着手前に確認しておきたい点です。

名前が似ていて混同しやすいので整理しておくと、React Compilerは機能そのものの名前、babel-plugin-react-compilerはそれをBabel経由で適用するためのプラグイン、react-compiler-runtimeはReact 17・18で動かすときに追加するランタイムパッケージです。以降の手順はこの3つを区別して読んでください。

Q. React 19へ上げないと導入できませんか。

A. できます。React 17・18でもtarget指定とランタイムパッケージの追加で動きます。ただし公式が最適としているのは19系なので、アップグレード計画がある現場では、先にReact本体を上げてからコンパイラを入れたほうが検証は1回で済みます。

React Compilerが最適化するもの・しないもの

コンパイラは万能ではありません。どこまでやってくれるのかを誤解したまま入れると、効果測定の前提そのものを誤りやすくなります。

自動でメモ化される範囲

対象はReactのコンポーネントとフックです。関数名が大文字で始まるコンポーネント、useで始まるカスタムフックが解析対象になり、その内部で作られるオブジェクト・配列・関数・計算結果が必要に応じてキャッシュされます。

JSX要素そのものもキャッシュの対象です。props が変わっていない子要素は、同じ要素オブジェクトが再利用されるため、子コンポーネントの再レンダリングがそこで止まります。React.memo を全箇所に貼って回るのと近い効果が、コードを汚さずに得られる形です。

コンパイラが手を出さない範囲

公式ドキュメントが明示しているのは次の2点です。

• Reactのコンポーネント・フック以外の関数はメモ化しない。モジュールのトップレベルに置いた重い処理は、呼び出し側のコンポーネント内でキャッシュされることはあっても、関数そのものが最適化されるわけではない

• 複数のコンポーネント間でキャッシュを共有しない。同じ計算を別々のコンポーネントで行えば、それぞれでキャッシュされる

加えて、ネットワーク待ちや巨大なDOM更新など、再レンダリング回数とは別の原因で遅いものは当然改善しません。Reactの描画が遅いのか、APIの応答が遅いのかを先に切り分けておかないと、導入の効果測定そのものが成立しなくなります。

効果が出やすいケース・出にくいケース

MetaのQuest Storeでの導入事例では、公式ブログ上で、初期読み込みとページ間遷移に関する一部指標で最大12%の改善、特定のインタラクションで2.5倍以上の改善、メモリ使用量は中立という結果が報告されています。ただしこれは大規模アプリ1件での実績であり、どのアプリでも同じ幅が出ると考えるのは危険です。

公式ドキュメントの説明と一般的なReactのパフォーマンス特性を踏まえると、次のような条件がそろうほど体感差が出やすいと考えられます。

• 1画面に多数のコンポーネントが並び、親の状態更新が広く波及している

• フォームや検索UIなど、入力のたびに再レンダリングが走る画面がある

• 手動メモ化が部分的にしか入っておらず、抜けが多い

逆に、すでにReact.memoとuseMemoを丁寧に貼り込んである小規模アプリでは、体感できる差はほとんど出ないこともあります。そもそもReactは最適化なしでも十分速い場面が多い、というのが公式ドキュメントの立場でもあります。

React Compilerの使い方｜導入手順とビルドツール別の設定

導入は「準備 → プラグイン追加 → ビルドツール設定 → 確認」の4段階で進みます。詳細な記述はReact Compiler のインストール｜Reactが一次情報です。

前提：Rules of Reactに準拠しているか確認する

最初にやるのは設定ではなく、コードがReactのルールを守っているかの確認です（Rules of React｜React）。コンパイラはRules of Reactを前提に安全な書き換えを判断するため、propsやstateを直接書き換えている箇所があると、コンパイラが最適化をスキップしたり、既存のルール違反が導入時の検証で表面化したりします。

確認は手作業ではなくESLintで行います。対応バージョンのeslint-plugin-react-hooksにはコンパイラ由来のルールが統合されており、推奨プリセットを有効にすると「最適化できないコンポーネント」を警告として検出できます。ただしFlat Configへの移行状況や既存のESLint設定、モノレポ構成によって手間は変わります。かつて別パッケージとして存在した eslint-plugin-react-compiler は、この統合にともない役割を終えました。

ここで出た警告を潰す作業が、実務では最も時間を食います。小〜中規模の既存プロジェクトでも、警告件数が多い場合は解消に数日〜数週間かかることがあると見込んでおくと計画がぶれません。

基本の導入手順

共通の流れは次のとおりです。

1. babel-plugin-react-compiler を開発依存として追加する。公式はバージョンを固定する指定（save-exact 相当）を推奨している

2. eslint-plugin-react-hooks を最新版へ更新し、推奨プリセットを有効にする

3. 使っているビルドツール側でプラグインを有効化する

4. 開発サーバーを起動し、React DevToolsで最適化されているか確認する

1番でバージョンを固定するのは、コンパイラのメモ化挙動が将来のバージョンで変わりうるためです。テストが薄い状態でキャレット指定にしておくと、マイナー更新で挙動が変わったときに原因の切り分けが難しくなります。

ビルドツール別の設定と、現行手順を確認するときの注意点

ここが日本語の解説記事で情報が古くなりやすい部分です。とくにVite周辺は、@vitejs/plugin-reactのメジャーバージョンやoxcへの対応状況によって設定方法が変わるため、2025年時点の記事と現行の手順が異なる場合があります。

次の表は2026年11月11日時点で各公式ドキュメントを確認した内容です。いずれもバージョン依存が大きいため、導入時点のバージョンの公式ドキュメントで必ず裏取りしてください。

Next.jsについて補足すると、Next.jsはプロジェクト全体にBabelプラグインを通すのではなく、JSXやフックを含むファイルだけを対象に絞り込む独自の最適化をSWC側に持っています。素のBabelプラグインをそのまま全ファイルに通す構成よりビルドが速くなる仕組みで、詳細はreactCompiler｜Next.jsに書かれています。

なお、新規作成であれば悩む場面は少ないはずです。create-viteやcreate-next-appでは、バージョンやテンプレートによって、プロジェクト作成時にReact Compilerの有効化を選べる場合があります。Next.jsの全体像から確認したい場合はNext.jsとは？React基盤のフレームワークの特徴・できること・年収・将来性をフリーランス視点で解説、バンドラーまわりの前提を整理したい場合はWebpackとは｜モジュールバンドラーの仕組み・Viteとの違い・基本設定が参考になります。

効いているかを確認する2つの方法

設定しただけで安心せず、必ず確認します。方法は2つです。

React DevToolsで見るのが最も早い方法です。ブラウザ拡張のReact Developer Toolsを入れて開発モードで起動すると、対応バージョンでは最適化されたコンポーネント名の横にバッジ（執筆時点の表示は「Memo ✨」）が付きます。表示仕様はDevToolsのバージョンで変わりうるため、バッジが見当たらない場合はDevToolsの更新も確認してください。

ビルド出力を直接見る方法も確実です。出力されたコードに react/compiler-runtime からの読み込みとキャッシュ判定の分岐が含まれていれば、変換は走っています。CIで確認したい場合はこちらが向きます。

Q. バッジが付かないコンポーネントがあります。壊れているのでしょうか。

A. 多くはルール違反が原因です。ESLintの警告を確認してください。propsの直接変更、レンダー中の副作用、フックの条件付き呼び出しが典型例です。コンパイラは安全に最適化できないと判断したとき、黙って対象外にします。

段階的に導入する3つの方法

既存の大規模プロジェクトへ一度に全面適用する必要はありません。公式も段階的な導入｜Reactとして3つの方法を案内しています。ただし設定方法や対応状況はビルドツールごとに異なるため、利用中の環境が対応しているかを確認したうえで選んでください。

ディレクトリ単位で区切る

Babelの overrides 設定で、適用対象のパスを限定する方法です。「新しく作るディレクトリだけ有効にし、安定したら対象パスを足していく」という進め方ができます。既存コードへ影響を与えずに実績を作れるので、合意形成が必要なチームで最も通しやすい選択肢です。

"use memo" でコンポーネント単位にオプトインする

コンパイラの compilationMode を annotation に切り替えると、"use memo" を書いたコンポーネント・フックだけがコンパイル対象になります。関数の先頭にディレクティブを1行置くだけなので、「この画面だけ試したい」という要望に即応できます。

Next.jsでも next.config の reactCompiler に同じ compilationMode を指定でき、ページ単位でのオプトインが可能です。

フィーチャーフラグで本番だけ切り替える

gating オプションを使うと、自前のフラグ関数の戻り値によって、実行時に最適化版と非最適化版を切り替えられます。A/Bテストで効果を測りたい場合や、問題が起きたときにデプロイなしで戻したい場合に有効です。

ただし両方のコードがバンドルに含まれる構成では、バンドルサイズが増える可能性があります。増加幅は構成次第なので、計測したうえで判断してください。検証期間を区切って使うのが現実的で、たとえば「2週間計測して問題がなければフラグごと撤去する」といった出口を最初に決めておくと、設定が残り続ける事態を避けられます。

既存のuseMemo・useCallbackはどうするか

ここが導入時に最も判断を迷う論点です。結論としては、一括削除は避け、分類してから手をつけるのが安全です。

消していいもの・残すもの

Reactチームは、既存のメモ化はそのまま残すか、慎重にテストしてから削除するよう案内しています。削除するとコンパイラの出力が変わる可能性があるためです。実務では、テストが薄いコンポーネントほど残す判断に倒したほうが無難です。

なお、既存のメモ化保証をコンパイラが維持するかどうかは設定で変えられます。これはReact Compilerの environment 設定にある enablePreserveExistingMemoizationGuarantees で、指定する場所はビルドツールによって異なります。Next.jsでの書き方はreactCompiler｜Next.jsを確認してください。既定値は実装やバージョンで異なる可能性があるため、暗黙の既定に依存せず明示的に指定しておくほうが、後から入ったメンバーも挙動を追いやすくなります。

"use no memo" で個別に除外する

どうしても挙動が合わないコンポーネントは、関数の先頭に "use no memo" を置けば対象外にできます。原因調査中の一時的な退避として使うもので、恒久的な解決策ではありません。置いた箇所と理由をコメントやIssueに残し、期限を切って棚卸しする運用にしておかないと、理由不明のディレクティブが残り続けます。

導入判断チェックリスト｜進めるべき案件・見送るべき案件

ここまでの内容を、現場で判断するための形に整理します。該当する項目が多いほど、その方向の判断が妥当になります。

導入を進めやすい条件（技術面）

• React 19系を使っている、またはアップグレード計画がある

• ESLintがCIで動いており、ルール違反を機械的に検出できる

• 主要画面にテスト（単体・E2Eのいずれか）がある

• 再レンダリング起因の体感遅延について、具体的な指摘や計測結果がある

導入を進めやすい条件（体制・契約面）

• 契約・稼働の見通しが数か月あり、段階導入を見届けられる

• 設定変更をレビューし、本番へ出す判断ができるメンバーが現場にいる

見送り・後回しが妥当な条件（技術面）

• React 16系以前で、本体のアップグレードが先に必要

• propsの直接変更やレンダー中の副作用が広範囲に残っている

• テストがほぼなく、挙動変化を検知する手段がない

• ビルド時間がすでに限界で、これ以上の増加を許容できない

見送り・後回しが妥当な条件（体制・契約面）

• リリース直前で、変更の影響範囲を絞りたい局面にある

• 短期の参画で、導入後の経過を見届けられる人が残らない

最後の点は補足が要ります。コンパイラは解析を行うぶんビルド時間に影響します。Next.jsのように対象ファイルを絞る最適化が入っている環境では影響は小さく局所的ですが、素のBabel構成で全ファイルに通すと無視できない増加になることがあります。導入前後でビルド時間を計測し、CIの制限時間に収まるかを確認しておくと安全です。

Q. 既存プロジェクトに入れる場合、どのくらいの工数を見ておけばよいですか。

A. ビルド構成が標準的であれば、設定だけなら半日程度で終わることもあります。ただし現実の工数はESLint警告の件数とコードベースの規模で決まります。目安として、警告が数十件なら1〜2週間、数百件規模なら段階導入を前提に数か月のスパンで考えると計画が破綻しにくくなります。いずれも規模や既存の実装状況で大きくぶれるため、着手前にESLintを走らせて件数を数えるのが、最も確実な見積もり方法です。

フリーランスエンジニアがReact案件で確認・提案すること

ここからは、参画する立場で押さえておきたい実務の話です。React Compilerは自分ひとりの判断で入れられる類の変更ではないため、確認と提案の順序が成果を左右します。

参画前・参画直後に確認する3点

1. Reactのバージョン。17・18ならtarget指定とランタイム追加が必要になり、19なら素直に入る。面談時の技術スタック確認で聞いておける

2. ESLintとCIの状態。ルールがCIで強制されているか、警告が放置されているか。後者なら導入前の地ならしが仕事の中心になる

3. ビルドツールとそのバージョン。とくにViteは、プラグインのメジャーバージョンによって設定方法が変わる。「Viteだから大丈夫」ではなくバージョンまで確認する

導入を提案するときは数値で示す

既存コードへ手を入れる提案は、体感ではなく数字で通ります。提案前に用意しておきたいのは次の3つです。

• 現状の計測値。React DevTools Profilerで、問題の画面のレンダリング回数と所要時間を記録する

• 影響範囲。ESLintの警告件数と、対象ディレクトリのファイル数

• 段階導入の計画。どのディレクトリから始め、どの時点で範囲を広げるか

「速くなります」ではなく「この画面の再レンダリングが◯回から◯回に減り、作業は新機能ディレクトリ限定で2週間」と出せると、判断する側も答えやすくなります。短期の参画では、契約期間内に完了する範囲まで切り出すことも重要です。途中で抜けることになった場合に備え、設定の意図と残作業をドキュメントに残しておくと、更新の判断にも効いてきます。

React案件でのスキルとしての位置づけ

React Compilerの設定作業そのものは、慣れれば難しいものではありません。価値が出るのは、Rules of Reactに沿った設計へコードベースを寄せていく力のほうです。コンパイラが最適化を諦めるコードは、そもそも読みづらく壊れやすいコードでもあります。警告を潰す作業は、結果としてコードベースの健全性を上げる仕事になります。

React周辺の案件動向や求められるスキルの幅はReactフリーランス単価相場｜案件動向・スキル別レンジ・獲得の実務で、Next.js寄りの案件についてはNext.js案件の単価相場｜必要スキル・経験別レンジと探し方で整理しています。自分の経験でどのくらいの単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめました。

複数の案件を比較して決めるときの優先順位については、案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位が判断の軸になります。React案件そのものを探す場合は、React案件の一覧から条件を絞り込めます。

よくある失敗と対策

ルール違反でコンパイル対象から外れていた

最も多いパターンです。設定は正しいのに最適化されない。原因はほぼRules of React違反で、propsの直接変更、レンダー中の副作用、フックの条件付き呼び出しが三大要因です。

対策は単純で、ESLintの警告を先に全部見ることです。導入前に件数を数え、潰してから有効化すれば、「効かない」という状態に遭遇せずに済みます。

手動メモ化を一括削除して壊した

「もう要らないから」と既存のuseMemo・useCallbackをまとめて消すと、外部ライブラリへ渡している関数やEffectの依存が崩れ、無限ループや再取得の多発につながります。

対策は、前章の分類表に沿って残すものを先に決めることです。削除は1ディレクトリずつ、テストを通しながら進めます。

ビルド時間が伸びてCIが詰まった

解析処理が増えるぶん、ビルド時間には影響があります。Next.jsのように対象を絞る最適化が入っていれば増加は限定的ですが、構成によっては体感できる差が出ます。

対策は、導入前後でビルド時間を記録しておくことです。段階導入なら範囲を広げるたびに計測し、許容できる範囲で止める判断ができます。

古い手順をそのまま適用してしまった

Vite環境で特に起きやすい失敗です。@vitejs/plugin-reactのメジャーバージョンやoxc対応の進み方によって、以前の指定方法がそのままでは通らない場合があります。検索で出てくる解説記事の多くは2025年時点の構成を前提にしているため、自分が使っているプラグインのバージョンに対応した公式ドキュメントを読むのが結局いちばん早くなります。

まとめ

React Compilerは、手動メモ化の多くを肩代わりするビルド時ツールです。入れるかどうかの判断は、Reactのバージョン・ESLintの整備状況・テストの厚みの3点でほぼ決まります。

• 2025年10月7日にv1.0が公開され、Reactチームは本番利用可能と位置づけている

• 対象はReactのコンポーネントとフック。それ以外の関数や、再レンダリング以外が原因の遅さには効かない

• ビルド構成が標準的なら設定自体は半日程度で終わることもあり、時間がかかるのはESLint警告の解消と既存メモ化の棚卸し

• ディレクトリ単位・"use memo"・フィーチャーフラグの3通りで段階的に入れられる

• 既存のuseMemo・useCallbackは一括削除せず、Effectの依存安定や外部ライブラリ向けのものは残す

• Viteはプラグインのメジャーバージョンで手順が変わるため、公式ドキュメントで現行の記述を確認する

次のステップとしては、まず手元のプロジェクトでESLintを最新構成にして警告件数を数えてみてください。その数字が、導入可否と工数の両方を判断する材料になります。

参照した一次情報は次のとおりです。

• React Compiler v1.0｜React Blog

• React Compiler の概要｜React

• React Compiler のインストール｜React

• 段階的な導入｜React

• Rules of React｜React

• reactCompiler｜Next.js

• React Compiler｜Expo Documentation