React Compiler とは何か？useMemo / useCallback を自動化する公式コンパイラの仕組みと採用判断

Q: Q. 既存の useMemo / useCallback は消すべきですか？

A. 必須ではないが、消した方がコードが綺麗になるです。Compiler が重複して最適化することはなく、共存可能。「プロジェクト全体で一気に消す」 のではなく、「触ったファイルで自然に減っていく」 流れが現実的です。

Q: Q. React 17 でも使えますか？

A. React 17+ で公式対応です。React 16 系は対応外。古いコードベースを Compiler 化したいなら、「まず React 17 / 18 へアップデート」 が前提になります。

Q: Q. パフォーマンスは本当に改善しますか？

A. ケースによるのが正直なところです。「既に useMemo / useCallback が完璧」 なコードでは差は小さい。「書いていなかった / 書き忘れていた」 コードでは大きな改善が見えます。「Profiler で前後比較」 してから判断するのが安全。

Q: Q. Vite で使えますか？

A. 使えます。「@vitejs/plugin-react」 の 「babel.plugins」 に 「babel-plugin-react-compiler」 を追加する設定が公式に示されています。Next.js では 「experimental.reactCompiler」 オプション1つで有効化されます。

Q: Q. eslint-plugin-react-compiler はどんな違反を検出しますか？

A. Hooks のルール違反」 「mutate 違反」 `不純な計算などです。「既存の eslint-plugin-react-hooks」 より厳しめで、「安全に Compiler 変換できるか」 を判断するための情報源として動きます。

Q: Q. ビルド時間が伸びませんか？

A. やや伸びるです。「Babel パイプラインに1つプラグインが増える」 ためで、現実的にはほとんど体感されない範囲。「大規模プロジェクトで気になる」 なら、「一部のフォルダだけ対象」 にする設定も可能です。

Q: Q. 学ぶことは何ですか？

A. Rules of React の正確な理解です。「コンポーネントの純粋性」 「Hooks のルール」 「不変更新」 を抑えれば、Compiler は勝手に動きます。「React の正しい書き方」 を改めて確認するきっかけ、と捉えるのが理想です。

先に要点

React Compiler は Meta が開発する 公式 React コンパイラ。「useMemo / useCallback / React.memo」を手で書かなくても、必要な箇所だけ自動でメモ化 してくれる。
動作原理は関数の挙動が「Rules of React」に準拠していることを静的解析 → 安全に変換可能と判断した部分を自動メモ化。「不純な関数」や「Hooks のルール違反」は自動的に変換対象から外す。
「eslint-plugin-react-compiler」で事前に Rules 違反を検出、「babel-plugin-react-compiler」で本体のコンパイルを行う。Next.js / Vite からも標準オプションで有効化できる。
本命の効果は 大規模 React アプリの体感速度向上 + コードの可読性向上(useMemo / useCallback を消せる)。「小規模アプリで効果が体感しづらい」のは正常で、「Rules を守れているか」の自己チェックツールとしても価値がある。

React Compiler ってよく聞くけど、結局何が変わるの？ useMemo 全部消していいの？ 「Rules of React って何？」 ── 2024 年から段階的に提供された React Compiler は、「React の書き方そのもの」を変える可能性を持つ大きな進化です。

ざっくり言うと、React Compiler は あなたが書いた React コンポーネントを、必要な箇所だけ自動でメモ化したコードに変換する公式ツール です。これまで「useMemo」「useCallback」「React.memo」を手で書いていた最適化を、コンパイラが安全な部分だけ自動で適用してくれる ようになります。

この記事では、2026 年 5 月時点の React Compiler(stable 系)をベースに、仕組み・何が嬉しいか・Rules of React・採用判断軸 を整理します。仕様は活発に変化しているので、最終確認は公式ドキュメントを見るのが安全です。

何を解決するか — useMemo 問題

「useMemo / useCallback」を手で書く労力は、React 開発者なら誰もが知る悩みです。

①書くべきタイミングが曖昧

「全部に useMemo を書くべきか、書かないべきか」で意見が割れる。書かないと再レンダーで「子コンポーネントが無駄に再実行」されるが、書きすぎるとコードが読みにくくなる。

② 依存配列のミス

「[user.id]」と書くべきところを「[user]」と書いて、毎回違う参照になる罠。「Linter で気付けない依存ミス」で性能が出ない、というのは現場の頻出問題。

③ コードがうるさい

「const x = useMemo(() => ..., [a, b, c])」「const f = useCallback(() => ..., [a])」がコードの大半を占める。「ロジックの本筋が見えにくい」状態になる。

④ 過剰な最適化

「全部にメモ化したつもりが、メモ化のコストで逆に遅くなる」ケースも。「いつ最適化すべきか」の判断は熟練を要する。

React Compiler は どうメモ化すべきかをコンパイラに任せる ことで、これらをまとめて解消する設計です。

基本の動作イメージ

最小例で「何が変換されるか」を見ます。

Compiler 適用前のコード:

function UserCard({ user }: { user: User }) {
  const greeting = `こんにちは、${user.name} さん`;
  const handleClick = () => alert(greeting);

  return (
    <div onClick={handleClick}>
      <h3>{user.name}</h3>
      <p>{greeting}</p>
    </div>
  );
}

Compiler 適用後の概念的なコード(実際には bytecode に近い形):

function UserCard({ user }: { user: User }) {
  // Compiler が自動で「user.name と greeting が変わったかどうか」を追跡
  const $ = useMemoCache(/* slot 数 */);
  const greeting = $.memo(user.name, () => `こんにちは、${user.name} さん`);
  const handleClick = $.memo(greeting, () => () => alert(greeting));

  // 以下同様
}

手動で書いてた最適化が消える

「useMemo / useCallback / React.memo」をもう書かなくていい。「書いたコードのまま、適切にメモ化されたコードに変換される」。

依存配列のミスがなくなる

「どの値に依存するかをコンパイラが正確に追う」ので、人間が「[user]」と書く間違いが構造的に消える。

不純な関数は変換しない

「Math.random()」「Date.now()」を直接呼ぶような 不純な関数は自動で変換対象外。「Rules of React」を守っていないコードは安全のためメモ化しない。

既存コードのまま使える

「手書きの useMemo / useCallback」が残っていても、Compiler は重複してメモ化しない。「既存コードを少しずつ整理する」流れが取れる。

「コードを書く側からは何も変わらない」が、「動作は最適化されている」のが React Compiler の魅力です。

Rules of React — 動作の前提

React Compiler は「あらゆるコードを変換できる」わけではなく、Rules of React に従ったコード でだけ安全に動作します。

コンポーネントは純粋関数

「同じ props を渡せば同じ結果を返す」が原則。「コンポーネント内で外部状態を直接変更」や「Math.random」を直接呼ぶ」のは違反。

Hooks のルール

「 Hooks は関数の最上位でしか呼ばない」「条件分岐内で呼ばない」などの既存ルールを守る。「違反していると Compiler が変換しない」。

不変更新

「 props や state を直接 mutate しない」が原則。「obj.x = 1」ではなく「setObj({ ...obj, x: 1 })」のように書く。

eslint-plugin-react-compiler

「 Rules 違反を ESLint レベルで検出してくれる公式プラグイン」。「Compiler を使う前に、まずこの Linter で違反を潰す」のが推奨フロー。

「これまでも推奨されていた書き方」を守れていれば、React Compiler が問題なく動く、というのが基本のルールです。

導入方法

React Compiler を導入する手順を整理します。

読み込み中...

「既存の React アプリに ESLint + Babel を加えるだけ」で導入できる、というのが他の「総入れ替え」系のフレームワーク移行と違うところです。

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

「React Compiler を入れて、どこで効果が出るか」を整理します。

効果が大きい

① 大規模 React アプリ(コンポーネント数が多く、深いツリー)、② リスト系 UI(「map」が大量にある)、③ 状態が頻繁に変わるダッシュボード、④ 既に useMemo / useCallback が散在していて整理したいコード。

効果が小さい

① 小規模 SPA(元から速い)、② すでに RSC / Server Components 中心で、クライアント側の再レンダーが少ない、③ 既に手動メモ化が完璧に整っているコード(差分が小さい)。

副次的価値

「 useMemo / useCallback を消せるのでコードが読みやすくなる」ことそのものが大きな価値。「性能改善」より「保守性改善」が主目的でも採用する価値がある。

Rules of React の自己チェック

「 ESLint プラグインで Rules 違反が出る」のが、「知らずに違反を書いていた」ことを気付かせてくれる。「Compiler を入れる前提で Lint を回す」だけでも、コードベース全体の健全性が上がる。

「性能改善」だけでなく、「コードの規律改善」という側面が React Compiler の隠れた利点です。

どこで詰まりやすいか

便利な反面、現場で踏みやすい注意点も整理します。

①Rules 違反のあるレガシーコード

「古いコードベースで意識せずに Rules 違反していた」と、ESLint プラグインが大量の警告を出す。既存違反を一気に直す 作業が地味に時間を食う。

② 想定外の参照変化

` Compiler 適用後、依存先の参照が「想定より頻繁に変わる」」ケースがごく稀にある。「useEffect で意図しない再実行」など。React DevTools のプロファイラで確認するのが安全。

③ 「use no memo」の濫用

「困ったら use no memo で逃げる」を癖にすると、Compiler の意味がなくなる。「Rules 違反を直して memo に戻す」が本来の対処。

④ Fast Refresh / HMR との整合

HMR 環境で「Compiler を経由したコード」がうまくホットリロードしない場面があった(2024〜2025)。2026 年現在は概ね解消されているが、「遭遇したらバージョン確認」が安全。

「Rules of React を守ることのご褒美として React Compiler が動く」という関係性を理解すると、ハマりにくくなります。

採用判断のチェックリスト

「React Compiler を入れるべきか」の判断軸を整理します。

向いている

① 中〜大規模 React / Next.js アプリ、② パフォーマンスの底上げ + コード整理を同時にやりたい、③ Rules of React に従っていることを自信を持って言いたい、④ チームで「useMemo を書く / 書かない」の議論を終わらせたい。

慎重に

① 古い React 16 系の大規模レガシー(対応外)、② Rules 違反が大量にあるコードベースで時間がない、③ ビルド時間に余裕がない CI 構成。

RSC / Server Actions との関係

「クライアント側でだけ働く」。RSC や Server Actions はサーバ側で動くので、Compiler の最適化対象外。「クライアント Components の最適化」を担う部分。

他フレームワークとの比較

「シグナル系(Solid / Svelte)は元から仮想 DOM コストがない」が、「React の仮想 DOM + 自動メモ化」の組み合わせで近い性能領域を狙うのが React Compiler の戦略。

「新規 React 案件はほぼ無条件で導入候補、既存案件は Rules 整備とセットで段階導入」が現実的な指針です。

AI 時代の React Compiler

AI 連携の文脈で React Compiler の意味を整理します。

AI 出力コードの最適化を肩代わり

「 AI が書いたコードは useMemo / useCallback が抜けがち」。React Compiler が自動で最適化するので、「AI 出力をそのままコピペしても性能が出やすい」。

Rules of React の自動検査

「 AI が Rules 違反を書いたら ESLint で即検出」できる。「AI 駆動開発の品質ゲート」として有効。

プロンプトの軽量化

「パフォーマンス最適化のためのメモ化を AI に依頼」する必要が減る。「AI に書かせるコードがシンプルになる」ことで、トークン消費とミスが減る。

React の延命

「仮想 DOM の性能上の弱点」を Compiler が補うことで、「シグナル系へ移行する圧力」が緩む。「React の現実的な天井が上がる」という見方ができる。

「AI で大量に React コードを生成する時代に、人間がメモ化を意識しなくていい」のは思った以上に大きな価値です。

React Compiler に関するよくある質問

Q. 既存の useMemo / useCallback は消すべきですか？

A. 必須ではないが、消した方がコードが綺麗になるです。Compiler が重複して最適化することはなく、共存可能。「プロジェクト全体で一気に消す」のではなく、「触ったファイルで自然に減っていく」流れが現実的です。

Q. React 17 でも使えますか？

A. React 17+ で公式対応です。React 16 系は対応外。古いコードベースを Compiler 化したいなら、「まず React 17 / 18 へアップデート」が前提になります。

Q. パフォーマンスは本当に改善しますか？

A. ケースによるのが正直なところです。「既に useMemo / useCallback が完璧」なコードでは差は小さい。「書いていなかった / 書き忘れていた」コードでは大きな改善が見えます。「Profiler で前後比較」してから判断するのが安全。

Q. Vite で使えますか？

A. 使えます。「@vitejs/plugin-react」の「babel.plugins」に「babel-plugin-react-compiler」を追加する設定が公式に示されています。Next.js では「experimental.reactCompiler」オプション1つで有効化されます。

Q. eslint-plugin-react-compiler はどんな違反を検出しますか？

A. Hooks のルール違反」「mutate 違反」 `不純な計算などです。「既存の eslint-plugin-react-hooks」より厳しめで、「安全に Compiler 変換できるか」を判断するための情報源として動きます。

Q. ビルド時間が伸びませんか？

A. やや伸びるです。「Babel パイプラインに1つプラグインが増える」ためで、現実的にはほとんど体感されない範囲。「大規模プロジェクトで気になる」なら、「一部のフォルダだけ対象」にする設定も可能です。

Q. 学ぶことは何ですか？

A. Rules of React の正確な理解です。「コンポーネントの純粋性」「Hooks のルール」「不変更新」を抑えれば、Compiler は勝手に動きます。「React の正しい書き方」を改めて確認するきっかけ、と捉えるのが理想です。

参考リンク

React Compiler: 公式ドキュメント
React Compiler: Working Group
Rules of React: 公式
eslint-plugin-react-compiler: npm
babel-plugin-react-compiler: npm
React 公式ブログ: Compiler 関連記事