先に要点
- 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 コンポーネントを、必要な箇所だけ自動でメモ化したコードに変換する公式ツール』</strong> です。 これまで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 は あらゆるコードを変換できる』 わけではなく、<strong> 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 の最適化』 を担う部分。
`新規 React 案件はほぼ無条件で導入候補、既存案件は Rules 整備とセットで段階導入』 が現実的な指針です。
AI 時代の React Compiler
AI 連携の文脈で React Compiler の意味を整理します。
AI 出力コードの最適化を肩代わり
` AI が書いたコードは useMemo / useCallback が抜けがち』。React Compiler が自動で最適化するので、`AI 出力をそのままコピペしても性能が出やすい』。
Rules of React の自動検査
` AI が Rules 違反を書いたら ESLint で即検出』 できる。`AI 駆動開発の品質ゲート』 として有効。
React の延命
` 仮想 DOM の性能上の弱点』 を Compiler が補うことで、`シグナル系へ移行する圧力』 が緩む。`React の現実的な天井が上がる』 という見方ができる。
`AI で大量に React コードを生成する時代に、人間がメモ化を意識しなくていい』 のは思った以上に大きな価値です。
React Compiler に関するよくある質問
Q. 既存の useMemo / useCallback は消すべきですか？
A. 必須ではないが、消した方がコードが綺麗になる』</strong>です。Compiler が重複して最適化することはなく、共存可能。プロジェクト全体で一気に消す』 のではなく、`触ったファイルで自然に減っていく』 流れが現実的です。
Q. React 17 でも使えますか？
A. React 17+ で公式対応』</strong>です。React 16 系は対応外。古いコードベースを Compiler 化したいなら、まず React 17 / 18 へアップデート』 が前提になります。
Q. パフォーマンスは本当に改善しますか？
A. ケースによる』</strong>のが正直なところです。既に 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 違反』 不純な計算』</strong>などです。既存の eslint-plugin-react-hooks』 より厳しめで、`安全に Compiler 変換できるか』 を判断するための情報源として動きます。
Q. ビルド時間が伸びませんか？
A. やや伸びる』</strong>です。Babel パイプラインに1つプラグインが増える』 ためで、現実的にはほとんど体感されない範囲。大規模プロジェクトで気になる』 なら、一部のフォルダだけ対象』 にする設定も可能です。
Q. 学ぶことは何ですか？
A. Rules of React の正確な理解』</strong>です。コンポーネントの純粋性』 Hooks のルール』 不変更新』 を抑えれば、Compiler は勝手に動きます。`React の正しい書き方』 を改めて確認するきっかけ、と捉えるのが理想です。
参考リンク
- React Compiler: 公式ドキュメント
- React Compiler: Working Group
- Rules of React: 公式
- eslint-plugin-react-compiler: npm
- babel-plugin-react-compiler: npm
- React 公式ブログ: Compiler 関連記事