React Compiler とは何か、AIに実装させる時代に使うべきか
まとめ
- React Compiler は、これまで手動で書いていたメモ化（
useMemo/useCallback/React.memo）を、ビルド時に自動で適用してくれる最適化コンパイラ。 - コードの意味は変えず、合わないコードは最適化をスキップする安全設計なので、導入して壊れるリスクは低い。
- AIに実装を任せる運用とは相性が良い。メモ化はAIでも人間でも貼り忘れ・貼りすぎ・依存配列ミスが起きやすい定番バグ源で、その判断ごと肩代わりできる。
- 新規または育成中のプロジェクトなら最初から入れておくのが一番ラク。
React Compiler とは
React Compiler は、旧称 “React Forget” として開発されていた、React コード向けの最適化コンパイラ。Babel プラグインとしてビルドパイプラインに組み込み、ビルド時にコードを変換する。
やることは一つ。コンポーネントの再レンダリングを解析して、必要な部分だけ自動でメモ化する。今まで開発者が手作業でやっていた最適化を、そのまま肩代わりしてくれる。
従来のReactで再レンダリングのパフォーマンスを気にするなら、こういう職人芸を積む必要があった。
- どの値が再計算されると重いかを見極める
useMemo/useCallbackを適切な箇所に貼る- 依存配列（deps）を正しく書く（ここが定番のハマりどころ）
React.memoでコンポーネントを包む
React Compiler を入れると、このリストがほぼ丸ごと要らなくなる。コンパイラが解析して勝手にメモ化してくれるからだ。
導入の前提条件
無条件でどこでも効くわけではなく、いくつか前提がある。
| 条件 | 内容 |
|---|---|
| React バージョン | 17+ で動作するが、19 が本命。古いほど設定が面倒 |
| ルール遵守 | 純粋なレンダリングと Hooks のルールを守ったコードであること |
| ESLint 併用 | eslint-plugin-react-compiler を入れ、コンパイラが嫌がるコードを検出させる |
押さえておきたいのは、React のルールを守っていないコードはコンパイラが最適化をスキップするところ。無理に最適化してバグを埋め込むのではなく、判断できない箇所には手を出さない。この設計のおかげで「入れたら壊れた」が起きにくい。
AIに実装させる運用との相性
最近は実装の大半をAIに書かせている。この運用と React Compiler は、思ったより噛み合う。
メモ化がAIの苦手分野とちょうど重なるからだ。useMemo / useCallback / 依存配列は、AIが生成したコードでも貼り忘れ・貼りすぎ・deps の書き間違いが起きやすい。で、これをレビューで毎回チェックすることになって、地味にしんどい。
React Compiler を入れれば、この判断をまるごとコンパイラに任せられる。AIには「メモ化は気にせず素直なコンポーネントを書け」でよくて、最適化が正しいかを自分がレビューで確かめるコストが消える。AIに書かせる運用の弱点は、この「細かい正しさを人間が検証するコスト」だと思ってるので、そこを一つ潰せるのは大きい。
使うべきか、急がなくていいか
導入をおすすめするケース。
- 新規プロジェクト、またはこれから育てるプロジェクト。最初から入れておけば手動メモ化との整理が発生しない。
- AIに実装の大半を任せる運用。前述のとおりレビュー負荷が下がる。
逆に急がなくていいケース。
- パフォーマンスで今困っていない小規模アプリ。入れても害はないが体感効果は薄い。
- 手動
useMemoが大量にある既存の古いコード。併存はできるが、移行時に少しノイズが出る。
注意点
過剰に期待しないための線引きも書いておく。
React Compiler が効くのは、あくまでメモ化で防げる再レンダリングの範囲。ネットワーク待ちやアルゴリズム的な重さは別問題で、そこは守備範囲外。
あと「最適化の知識が要らなくなる」は半分だけ本当。メモ化を貼る作業は減るけど、「なぜメモ化が必要なのか」という理解自体は、デバッグやパフォーマンス調査のときにやっぱり効く。知識が退化するというより、単純作業から解放されるだけ、というのが正直な感覚。