「Create React App(CRA)は非推奨らしい」と聞いて驚いた方も多いのではないでしょうか。長らくReactの入門ツールとして定番だったCRAですが、React 18以降のアップデートやモダンな開発要件の変化に伴い、いまや公式ドキュメントでも新規採用が推奨されなくなっています。
では、なぜそのような扱いになったのか?すでに使っているプロジェクトはどうすべきなのか?そして、今からReactで開発するなら何を使えばいいのか?――この記事では、そんな疑問をクリアにしながら、これからのReact開発にふさわしい環境選びと移行方法について詳しく解説します。
なぜCreate React App(CRA)は非推奨になったのか?公式見解と技術的理由

「非推奨」は本当?React公式の見解と現在のステータス
2022年後半から2023年にかけて、React公式チームは「Create React App(CRA)を新規アプリケーションでは非推奨とし、既存アプリケーションはフレームワークへの移行、またはVite、Parcel、RSBuildなどのビルドツールへの移行を推奨する」と正式に発表しました。この発表は、長年にわたってReact開発のスタンダードとして君臨してきたCRAに対する事実上の「引退宣言」といえるでしょう。
公式発表の背景と経緯
CRAは2016年にリリースされ、当時はReactアプリケーションを構築するための明確な方法が存在しなかった状況を解決するために開発されました。JSX、リンティング、ホットリロードなどの基本機能をサポートするために、複数のツールを手動で設定する必要があり、これを正しく行うのは非常に困難でした。CRAは、複数のツールを単一の推奨設定に統合することで、これらの問題を解決し、Reactチームが新しいツール機能(Fast Refresh、React Hooks lintルールなど)を幅広いユーザーに提供することを可能にしました。
しかし、現在CRAには積極的なメンテナーがおらず、これらの問題を解決する多くの既存フレームワークが存在するため、CRAを非推奨にすることを決定したと公式チームは説明しています。
現在のステータス
- メンテナンスモード: CRAは完全に廃止されるのではなく、メンテナンスモードで継続されます
- React 19対応: 新しいバージョンのCRAがReact 19と互換性を持つようにリリースされました
- 新規インストール時の警告: 新しいアプリケーションをインストールする際に、非推奨の警告が表示されます
- 公式サイト・リポジトリの更新: CRAの公式サイトとGitHubリポジトリに非推奨の通知が追加されました
ビルド速度・Eject構造・最新技術との非互換がもたらす課題
CRAが非推奨になった背景には、現代のフロントエンド開発における深刻な技術的課題があります。これらの課題は、開発者の生産性とユーザー体験の両方に大きな影響を与えています。
1. ビルド速度の深刻な遅延
CRAの最も顕著な問題の一つは、プロジェクトの規模が大きくなるにつれて顕著になるビルド速度の遅さです。特に以下の場面で開発者は深刻な影響を受けます:
- 開発サーバーの起動時間: 中規模以上のプロジェクトでは、
npm start
実行から実際にブラウザで確認できるまでに30秒〜数分かかることも珍しくありません - Hot Module Replacement(HMR)の遅延: コードの変更を保存してからブラウザに反映されるまでの時間が長く、開発フローが頻繁に中断されます
- プロダクションビルド:
npm run build
の実行時間が長時間に及び、CI/CDパイプラインのボトルネックとなります
これらの問題は、CRAが内部的に使用しているWebpackの設定や、最適化されていないデフォルト設定に起因しています。
2. Eject構造の複雑さと保守性の問題
CRAの「Eject」機能は、カスタマイズが必要な場合に設定ファイルを露出させる仕組みですが、これには重大な課題があります:
- 一方向の操作: 一度
npm run eject
を実行すると、元に戻すことができません - 設定の複雑化: Eject後は100以上の設定ファイルが生成され、その多くは相互に依存しています
- アップグレードの困難: Eject後はCRAのアップデートを受けることができず、手動でのメンテナンスが必要になります
- 学習コストの増大: 生成された設定ファイルを理解・管理するためには、Webpack、Babel、ESLintなどの深い知識が必要です
3. モダンバンドラーとの技術格差
近年登場したVite、Parcel、esbuildなどのモダンバンドラーと比較して、CRAは以下の点で大きく劣っています:
- ESM(ES Modules)ベースの開発: ViteなどはESMを活用して高速な開発環境を提供していますが、CRAは従来のバンドル方式に依存しています
- ネイティブコンパイル: esbuildやSWCなどのネイティブコンパイラーを使用するツールに比べて、Babelベースのコンパイルは明らかに遅いです
- Tree Shaking: 最新のバンドラーは高度なTree Shakingを提供していますが、CRAのデフォルト設定は最適化が不十分です
4. 設定の柔軟性不足
CRAは「設定不要」を売りにしていますが、これが逆に以下の制約を生み出しています:
- TypeScriptの高度な設定: 厳密なTypeScript設定やパスマッピングなどを行う際の制約
- CSSフレームワークの統合: TailwindCSSやStyled-componentsなどの統合時の複雑さ
- モノレポ対応: MonorepoやWorkspaceの設定が困難
- エイリアスやパス解決: 複雑なプロジェクト構造でのパス解決の制約
最新React(React 19)やモダン開発要件との互換性・今後のリスク
React 19の登場とともに、CRAが抱える互換性の問題はより深刻になっています。これらの問題は、今後のReact開発において重大なリスクとなる可能性があります。
React 19の新機能との互換性問題
React 19では以下の重要な機能が導入されましたが、CRAはこれらの機能を十分に活用できません:
- React Server Components(RSC): Server Componentsは、ルーティングとデータフェッチングをサーバーに移動し、レンダリングするデータに基づいてクライアントコンポーネントのコード分割を行うことができ、最適なローディングシーケンスを実現するためのJavaScriptの送信量を削減します
- Actions: フォーム処理やサーバーサイドのデータ操作を簡潔に記述できる新しいパターン
- Suspense for Data Fetching: データフェッチングの完全な統合とパフォーマンス最適化
- Concurrent Features: 同時実行機能による優れたユーザー体験
Server Componentsの活用困難
Server Componentsはサーバーを必要とせず、ビルド時にCIサーバーで実行してStatic Site Generation(SSG)アプリケーションを作成したり、ランタイムでWebサーバー上で実行してServer-Side Rendering(SSR)アプリケーションを作成したりできます。しかし、CRAはクライアントサイドのみの環境に特化しており、これらの機能を活用することができません。
データフェッチングの制約
CRAではデータフェッチングはコンポーネントがレンダリングされた後に行われるため、ネットワークウォーターフォールが発生します。これは、コードのダウンロードと並行してデータをフェッチングする代わりに、アプリケーションがレンダリングされるときにデータをフェッチングすることで発生します。
モダンなフレームワークでは、以下のような最適化が標準的に提供されています:
- ルーターレベルでのデータローディング: ルートレベルでデータの依存関係を指定し、ルーターがデータフェッチングを最適化
- パラレルフェッチング: コードのダウンロードと並行してデータをフェッチング
- プリフェッチング: ユーザーが必要とする前にデータを事前取得
コード分割の制約
CRAでは特定のコード分割ソリューションが含まれていません。React.lazyを使用したコード分割は可能ですが、これはコンポーネントがレンダリングされるまでコードがフェッチされないため、ネットワークウォーターフォールの原因となります。
最適なコード分割には以下の要素が必要です:
- ルーターとの統合: ルーティングシステムとの緊密な統合
- データローディングとの連携: データフェッチングとコード分割の最適化
- キャッシュ戦略: 効率的なキャッシングメカニズム
- Import on Interaction: ユーザーインタラクションに基づくコード分割
今後のリスク要因
CRAを使い続けることで、以下のようなリスクが予想されます:
- セキュリティリスク: 積極的なメンテナンスが行われないため、セキュリティ脆弱性への対応が遅れる可能性
- パフォーマンスの劣化: 最新の最適化技術を活用できないため、競合他社との差が拡大
- 開発者体験の悪化: 遅いビルド速度や制約の多い開発環境による生産性の低下
- 採用の困難: 非推奨技術を使用することで、優秀な開発者の採用が困難になる可能性
- 技術的負債の蓄積: 将来的な移行コストが時間とともに増大
これらの課題を解決するためには、Next.js、Vite、Remixなどのモダンなフレームワークやビルドツールへの移行が不可欠です。次のセクションでは、これらの代替ツールについて詳しく解説します。
新規プロジェクトはこれ!CRAに代わるモダンな開発環境【2025年版】

Vite・Next.js・Remix・Parcel徹底比較!最適なツールの選び方
CRAの代替として注目されているモダンな開発環境を、実際の開発現場での使用経験に基づいて徹底比較していきます。それぞれのツールが持つ特徴と、どのような場面で最適なのかを詳しく解説します。
Vite(ヴィート)
Viteは、Vue.jsの作者であるEvan Youが開発したビルドツールで、ESM(ES Modules)ベースの超高速な開発環境を提供します。

メリット:
- 圧倒的な開発速度:HMR(Hot Module Replacement)が非常に高速で、ファイル変更後の反映が瞬時
- 軽量な設定:設定ファイルが最小限で、すぐに開発を始められる
- プラグインエコシステム:豊富なプラグインによる拡張性
- TypeScript完全対応:追加設定なしでTypeScriptが使用可能
- モダンブラウザ最適化:開発時はESMを直接使用し、本番環境では最適化されたバンドルを生成
デメリット:
- SSR機能なし:サーバーサイドレンダリングは別途フレームワークが必要
- 学習コスト:新しいツールのため、CRAに慣れた開発者には最初は戸惑いがある
- エコシステムの成熟度:比較的新しいツールのため、一部のライブラリで互換性の問題が発生することがある
Next.js
Vercelが開発するReactフレームワークで、フルスタックアプリケーション開発に特化しています。

メリット:
- フルスタック機能:API Routes、SSR、SSG、ISRなど完全なWebアプリケーション開発機能
- ファイルシステムルーティング:直感的なルーティング設定
- 最適化機能:画像最適化、コード分割、パフォーマンス最適化が自動
- 企業採用実績:大手企業での採用実績が豊富で、情報やコミュニティが充実
- Vercelとの親和性:デプロイメントが非常に簡単
デメリット:
- 学習コスト:多機能ゆえに覚えることが多い
- 設定の複雑性:高度なカスタマイズには深い理解が必要
- バンドルサイズ:機能が多い分、最小構成でもファイルサイズが大きくなりがち
Remix
Shopifyが買収したReactフレームワークで、Web標準に忠実な設計思想を持ちます。

メリット:
- Web標準準拠:FormData、fetch APIなど、Web標準を活用した開発
- 優れたUX:ネストしたルーティングによる部分的な画面更新
- データローディング:効率的なデータフェッチング機能
- エラーハンドリング:きめ細かいエラーバウンダリー機能
- プログレッシブエンハンスメント:JavaScriptが無効でも動作する設計
デメリット:
- 学習コスト:独特の設計思想のため、習得に時間がかかる
- エコシステム:比較的新しいため、サードパーティライブラリの対応が限定的
- 情報の少なさ:日本語での情報が少ない
Parcel
設定不要(Zero-configuration)をコンセプトとしたビルドツールです。

メリット:
- 設定不要:設定ファイルを書かずに多くの機能が利用可能
- マルチフレームワーク対応:React以外のフレームワークも同様に扱える
- 高速ビルド:並列処理による高速なビルド
- 豊富な対応形式:HTML、CSS、JS、画像など様々なファイル形式に対応
デメリット:
- カスタマイズ性:細かい設定変更が困難
- エコシステム:他のツールと比較してプラグインが少ない
- 企業採用実績:大規模開発での採用事例が限定的
開発体験とパフォーマンス比較表
項目 | Vite | Next.js | Remix | Parcel |
---|---|---|---|---|
開発サーバー起動速度 | ★★★★★ | ★★★☆☆ | ★★★★☆ | ★★★★☆ |
HMR速度 | ★★★★★ | ★★★☆☆ | ★★★★☆ | ★★★★☆ |
ビルド速度 | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ |
設定の容易さ | ★★★★☆ | ★★★☆☆ | ★★☆☆☆ | ★★★★★ |
SSR/SSG対応 | ☆☆☆☆☆ | ★★★★★ | ★★★★★ | ☆☆☆☆☆ |
エコシステム成熟度 | ★★★★☆ | ★★★★★ | ★★★☆☆ | ★★★☆☆ |
開発速度とビルド速度が劇的に向上!Viteの導入と使い方
Viteが他のツールと比較して圧倒的に高速な理由は、ESM(ES Modules)ベースの開発環境にあります。従来のバンドラーは開発時でもすべてのファイルをバンドルしていましたが、Viteは開発時にはESMを直接使用し、必要な部分のみを動的にロードします。
Viteの技術的優位性
- ESMベースの開発:モダンブラウザが直接ESMを理解するため、バンドル処理が不要
- esbuildの活用:Go言語で書かれたesbuildによる超高速な前処理
- オンデマンドコンパイル:変更されたファイルのみをコンパイル
- 効率的なキャッシュ:ブラウザキャッシュを最大限活用
Viteプロジェクトの作成手順
# Reactプロジェクトを作成
npm create vite@latest my-react-app -- --template react
# プロジェクトディレクトリに移動
cd my-react-app
# 依存関係をインストール
npm install
# 開発サーバーを起動
npm run dev
TypeScript対応プロジェクトの場合
# TypeScript + Reactプロジェクトを作成
npm create vite@latest my-react-ts-app -- --template react-ts
Viteの主要設定(vite.config.js)
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
// <https://vitejs.dev/config/>
export default defineConfig({
plugins: [react()],
server: {
port: 3000,
open: true, // ブラウザを自動で開く
},
build: {
outDir: 'dist',
sourcemap: true,
},
resolve: {
alias: {
'@': '/src', // パスエイリアスの設定
},
},
})
実際の開発速度の違い
CRAとViteの開発サーバー起動時間を比較すると、以下のような差が生まれます:
- CRA(Create React App):初回起動 15-30秒、変更反映 2-5秒
- Vite:初回起動 1-3秒、変更反映 0.1-0.5秒
この差は、プロジェクトの規模が大きくなるほど顕著になります。中規模以上のプロジェクトでは、CRAの開発サーバー起動に数分かかる場合もありますが、Viteでは常に数秒で起動します。
Viteでよく使用される追加プラグイン
# PWA対応
npm install @vite-pwa/vite-plugin-pwa
# CSS前処理
npm install -D sass
# ESLint連携
npm install -D @vitejs/plugin-eslint
設定例(拡張版)
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { VitePWA } from '@vite-pwa/vite-plugin-pwa'
export default defineConfig({
plugins: [
react(),
VitePWA({
registerType: 'autoUpdate',
workbox: {
globPatterns: ['**/*.{js,css,html,ico,png,svg}']
}
})
],
server: {
port: 3000,
open: true,
hmr: {
overlay: false // エラーオーバーレイを無効化
}
},
build: {
rollupOptions: {
output: {
manualChunks: {
react: ['react', 'react-dom'],
router: ['react-router-dom'],
}
}
}
},
resolve: {
alias: {
'@': '/src',
'@components': '/src/components',
'@utils': '/src/utils',
}
}
})
プロジェクト規模別「最適ツール」選定フローチャート
適切な開発環境を選択するためには、プロジェクトの特性と要件を正確に把握することが重要です。以下のフローチャートを参考に、最適なツールを選択してください。
ステップ1:プロジェクトの性質を確認
個人開発・学習目的・プロトタイプ作成
- 推奨ツール:Vite
- 理由:最小限の設定で高速な開発環境を構築でき、学習コストが低い
- 適用場面:個人ポートフォリオ、技術検証、小規模な実験プロジェクト
シンプルなランディングページ・企業サイト
- 推奨ツール:Vite + React Router または Next.js
- 理由:静的サイト生成(SSG)が必要な場合はNext.js、クライアントサイドのみでよい場合はVite
- 適用場面:コーポレートサイト、商品紹介ページ、イベントサイト
中規模SPA(Single Page Application)
- 推奨ツール:Vite + React Router
- 理由:高速な開発環境と柔軟なルーティング設定が可能
- 適用場面:管理画面、ダッシュボード、社内ツール、業務システム
大規模Webアプリケーション・ECサイト
- 推奨ツール:Next.js または Remix
- 理由:SSR、SEO対応、スケーラビリティが必要
- 適用場面:ECサイト、メディアサイト、大規模なWebアプリケーション
ステップ2:技術要件の確認
SEO対応が必要な場合
SEO重要度:高
↓
サーバーサイドレンダリング必要
↓
Next.js または Remix を選択
開発速度を最重要視する場合
開発速度:最優先
↓
設定の複雑さを避けたい
↓
Vite または Parcel を選択
チーム開発規模による選定
個人開発(1名)
- 推奨:Vite
- セットアップ時間:5分以内
- メリット:学習コストが低く、即座に開発開始可能
小規模チーム(2-5名)
- 推奨:Vite または Next.js
- セットアップ時間:10-30分
- メリット:チーム内での統一した開発環境の構築が容易
中規模チーム(6-20名)
- 推奨:Next.js
- セットアップ時間:1-3時間
- メリット:豊富なドキュメントとコミュニティサポート
大規模チーム(21名以上)
- 推奨:Next.js または 独自ビルドシステム
- セットアップ時間:1日-1週間
- メリット:企業レベルでの採用実績と長期サポート
プロジェクト要件別最適解
パフォーマンス重視
- Vite:開発時のパフォーマンス最優先
- Next.js:本番環境でのパフォーマンス最適化重視
- Remix:ユーザー体験を重視したパフォーマンス
学習コスト重視
- Vite:CRAからの移行が最も簡単
- Parcel:設定不要で即座に開始可能
- Next.js:豊富な学習リソースが利用可能
将来性・拡張性重視
- Next.js:最も成熟したエコシステム
- Vite:急速に成長中のエコシステム
- Remix:新しいWeb標準に準拠した設計
実際の選定フロー例
プロジェクト開始
↓
「SEOが重要?」
├─ Yes → Next.js または Remix
│ ├─ Web標準重視 → Remix
│ └─ 豊富な機能・安定性重視 → Next.js
│
└─ No → 「開発速度重視?」
├─ Yes → Vite
│ ├─ 設定したくない → Parcel
│ └─ 高速開発重視 → Vite
│
└─ No → 「チーム規模は?」
├─ 大規模 → Next.js
└─ 小規模 → Vite
このフローチャートを使用することで、プロジェクトの特性に最も適した開発環境を効率的に選択できます。重要なのは、プロジェクトの要件を正確に把握し、将来の拡張性も考慮した選択を行うことです。
既存CRAプロジェクトの移行ガイドと今後のReact開発ベストプラクティス
ViteやNext.jsへの具体的な移行手順と注意点
既存のCRAプロジェクトを現代的な開発環境に移行する際は、段階的なアプローチを取ることが重要です。ここでは、最も需要の高いViteとNext.jsへの移行手順を詳しく解説します。
CRAからViteへの移行手順
ステップ1:依存関係の整理
まず、現在のCRAプロジェクトの依存関係を確認し、Viteで必要な依存関係に置き換えます。
# CRA関連のパッケージを削除
npm uninstall react-scripts
# Viteと必要なプラグインをインストール
npm install -D vite @vitejs/plugin-react
ステップ2:設定ファイルの作成
プロジェクトルートに vite.config.js
を作成します。
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [react()],
server: {
port: 3000,
open: true,
},
build: {
outDir: 'build', // CRAと同じ出力ディレクトリを維持
},
resolve: {
alias: {
'@': '/src',
},
},
// 環境変数のプレフィックスを設定
envPrefix: 'REACT_APP_',
})
ステップ3:package.jsonスクリプトの更新
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview",
"serve": "vite preview"
}
}
ステップ4:index.htmlの移動と修正
CRAではpublic/index.html
がベースとなりますが、Viteではindex.html
をプロジェクトルートに配置する必要があります。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8" />
<link rel="icon" type="image/svg+xml" href="/vite.svg" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Vite + React</title>
</head>
<body>
<div id="root"></div>
<!-- CRAと異なり、直接scriptタグでエントリーポイントを指定 -->
<script type="module" src="/src/main.jsx"></script>
</body>
</html>
ステップ5:エントリーポイントの調整
src/index.js
をsrc/main.jsx
にリネームし、必要に応じて内容を調整します。
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.jsx'
import './index.css'
ReactDOM.createRoot(document.getElementById('root')).render(
<React.StrictMode>
<App />
</React.StrictMode>,
)
CRAからNext.jsへの移行手順
Next.jsへの移行は、より大きな構造変更を伴います。
ステップ1:Next.jsのインストール
# CRA関連のパッケージを削除
npm uninstall react-scripts
# Next.jsとその依存関係をインストール
npm install next react react-dom
ステップ2:ディレクトリ構造の再構築
my-app/
├── pages/ # 新規作成
│ ├── _app.js
│ ├── _document.js
│ └── index.js
├── public/ # 既存のまま
├── src/ # 既存のコンポーネントはそのまま
└── styles/ # 新規作成
└── globals.css
ステップ3:pages/_app.jsの作成
import '../styles/globals.css'
function MyApp({ Component, pageProps }) {
return <Component {...pageProps} />
}
export default MyApp
ステップ4:メインコンポーネントの移植
既存のsrc/App.js
の内容をpages/index.js
に移植します。
import { useState, useEffect } from 'react'
import styles from '../styles/Home.module.css'
export default function Home() {
// 既存のApp.jsのロジックをここに移植
return (
<div className={styles.container}>
{/* 既存のJSXをここに移植 */}
</div>
)
}
ステップ5:package.jsonの更新
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint"
}
}
環境変数の移行
CRAからVite/Next.jsへの移行では、環境変数の扱いが変わります。
CRA → Vite
# CRA(.env)
REACT_APP_API_URL=https://api.example.com
# Vite(.env)
VITE_API_URL=https://api.example.com
CRA → Next.js
# CRA(.env)
REACT_APP_API_URL=https://api.example.com
# Next.js(.env.local)
NEXT_PUBLIC_API_URL=https://api.example.com
TypeScriptプロジェクトの移行
TypeScriptを使用している場合の追加手順:
Viteの場合
# TypeScript関連の依存関係を追加
npm install -D typescript @types/react @types/react-dom
Next.jsの場合
# TypeScript設定を追加
npm install -D typescript @types/react @types/react-dom @types/node
移行時の重要な注意点
- 絶対パスインポート:CRAの
jsconfig.json
やtsconfig.json
のbaseUrl
設定は、新しい環境に合わせて調整が必要 - プロキシ設定:CRAの
package.json
にあるproxy
設定は、Viteではvite.config.js
のserver.proxy
、Next.jsではnext.config.js
のrewrites
で対応 - 画像・静的ファイル:Next.jsでは
public
フォルダの扱いが若干異なるため、画像パスの確認が必要 - CSS Modules:ファイル名規則が異なる場合があるため、スタイルファイルの命名を確認
移行時によくあるトラブル・既存コード修正のポイント
実際の移行作業では、様々なトラブルが発生することがあります。ここでは、よく遭遇する問題とその解決策を詳しく解説します。
1. 環境変数が認識されない問題
症状:process.env.REACT_APP_XXX
がundefined
になる
原因:ViteではVITE_
、Next.jsではNEXT_PUBLIC_
プレフィックスが必要
解決策:
// CRA
const apiUrl = process.env.REACT_APP_API_URL
// Vite
const apiUrl = import.meta.env.VITE_API_URL
// Next.js
const apiUrl = process.env.NEXT_PUBLIC_API_URL
2. パスエイリアスが動作しない問題
症状:@/components/Button
のような相対パスが解決されない
解決策(Vite):
// vite.config.js
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path'
export default defineConfig({
plugins: [react()],
resolve: {
alias: {
'@': path.resolve(__dirname, './src'),
'@components': path.resolve(__dirname, './src/components'),
},
},
})
解決策(Next.js):
// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
webpack: (config) => {
config.resolve.alias = {
...config.resolve.alias,
'@': path.resolve(__dirname, './src'),
}
return config
},
}
module.exports = nextConfig
3. CSS/SCSSファイルのインポートエラー
症状:CSS ModulesやSCSSファイルが正しく読み込まれない
解決策(Vite):
# SCSS対応
npm install -D sass
// vite.config.js
export default defineConfig({
plugins: [react()],
css: {
preprocessorOptions: {
scss: {
additionalData: `@import "@/styles/variables.scss";`
}
}
}
})
4. 動的インポートの問題
症状:React.lazy
や動的インポートが期待通りに動作しない
解決策:
// CRA
const LazyComponent = React.lazy(() => import('./LazyComponent'))
// Vite(同じ構文だが、場合によってはパスの調整が必要)
const LazyComponent = React.lazy(() => import('@/components/LazyComponent'))
// Next.js(dynamic importを推奨)
import dynamic from 'next/dynamic'
const LazyComponent = dynamic(() => import('@/components/LazyComponent'))
5. テスト環境の設定問題
症状:Jest/React Testing Libraryのテストが動かない
解決策(Vite):
# Vitestをインストール
npm install -D vitest @testing-library/react @testing-library/jest-dom
// vite.config.js
export default defineConfig({
plugins: [react()],
test: {
environment: 'jsdom',
setupFiles: ['./src/setupTests.js'],
},
})
6. ESLintとPrettierの設定
症状:既存のリンタールールが適用されない
解決策:
# Vite用のESLint設定
npm install -D eslint @vitejs/eslint-config-react
// .eslintrc.js
module.exports = {
extends: [
'@vitejs/eslint-config-react',
// 既存のルールを維持
],
rules: {
// カスタムルール
},
}
7. プロキシ設定の移行
症状:開発環境でのAPI通信が失敗する
解決策(Vite):
// vite.config.js
export default defineConfig({
server: {
proxy: {
'/api': {
target: '<http://localhost:8080>',
changeOrigin: true,
rewrite: (path) => path.replace(/^\\/api/, ''),
},
},
},
})
8. ビルド時のパブリックパス問題
症状:本番環境でのアセット読み込みに失敗
解決策:
// vite.config.js
export default defineConfig({
base: process.env.NODE_ENV === 'production' ? '/my-app/' : '/',
build: {
outDir: 'dist',
assetsDir: 'assets',
},
})
移行チェックリスト
移行作業を確実に進めるためのチェックリストを活用してください:
事前準備
移行作業
動作確認
今後のReact開発トレンドと「正しい」開発環境の作り方
React開発エコシステムは急速に進化しており、2025年以降の開発において考慮すべき重要なトレンドがあります。
React 19とサーバーコンポーネントの影響
React 19では、サーバーコンポーネント(Server Components)が安定版として提供され、これまでの開発パラダイムを大きく変える可能性があります。
サーバーコンポーネントの特徴
- サーバーサイドでのコンポーネント実行
- クライアントサイドJavaScriptバンドルサイズの削減
- データフェッチングの最適化
- SEOとパフォーマンスの向上
対応状況
- Next.js 13+:App Routerでサーバーコンポーネントを完全サポート
- Remix:Web標準に準拠したアプローチでサーバーコンポーネントに対応
- Vite:プラグインによる部分的なサポート(開発中)
実装例(Next.js App Router)
// app/page.js(サーバーコンポーネント)
async function HomePage() {
// サーバーサイドでデータを取得
const posts = await fetch('<https://api.example.com/posts>').then(res => res.json())
return (
<div>
<h1>Latest Posts</h1>
{posts.map(post => (
<PostCard key={post.id} post={post} />
))}
</div>
)
}
// components/PostCard.js(サーバーコンポーネント)
function PostCard({ post }) {
return (
<article>
<h2>{post.title}</h2>
<p>{post.excerpt}</p>
<LikeButton postId={post.id} /> {/* クライアントコンポーネント */}
</article>
)
}
バンドルレス開発の普及
従来のバンドラーベースの開発から、ESMを直接活用するバンドルレス開発が主流になりつつあります。
バンドルレス開発のメリット
- 開発サーバーの高速起動
- 変更の即座な反映
- メモリ使用量の削減
- 大規模プロジェクトでのスケーラビリティ向上
主要なバンドルレス開発ツール
- Vite:開発時バンドルレス、本番時最適化バンドル
- esbuild:Go言語ベースの高速バンドラー
- SWC:Rustベースの高速コンパイラ
- Turbopack:Vercelが開発中の次世代バンドラー
TypeScriptファーストの開発
TypeScriptの採用率が急速に増加しており、新規プロジェクトでは最初からTypeScriptを採用することが推奨されています。
TypeScriptファースト開発環境の構築
# Vite + TypeScript
npm create vite@latest my-app -- --template react-ts
# Next.js + TypeScript
npx create-next-app@latest my-app --typescript
推奨されるTypeScript設定
{
"compilerOptions": {
"target": "ES2020",
"lib": ["DOM", "DOM.Iterable", "ESNext"],
"allowJs": true,
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"noFallthroughCasesInSwitch": true,
"module": "ESNext",
"moduleResolution": "bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"noEmit": true,
"jsx": "react-jsx"
},
"include": [
"src"
]
}
マイクロフロントエンドアーキテクチャ
大規模なアプリケーションでは、マイクロフロントエンドアーキテクチャの採用が増加しています。
マイクロフロントエンド対応ツール
- Module Federation:Webpackベースのマイクロフロントエンド
- Single-spa:フレームワーク非依存のマイクロフロントエンド
- Nx:モノレポ管理ツール
- Lerna:パッケージ管理ツール
正しい開発環境の構築指針
1. プロジェクトの特性に応じた選択
- パフォーマンス重視:Vite + React
- SEO重視:Next.js + App Router
- Web標準準拠:Remix
- 企業開発:Next.js + TypeScript
2. 必須の開発ツール構成
# 基本構成
- ビルドツール: Vite / Next.js / Remix
- 言語: TypeScript
- リンター: ESLint + Prettier
- テスト: Vitest / Jest + React Testing Library
- Git hooks: Husky + lint-staged
3. 開発効率を向上させる追加ツール
# 開発体験向上
- Storybook: コンポーネント開発
- Chromatic: ビジュアルテスト
- React DevTools: デバッグ
- VS Code拡張: ES7+ React/Redux/React-Native snippets
4. CI/CDパイプラインの構築
# GitHub Actions例
name: CI/CD Pipeline
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '18'
- run: npm ci
- run: npm run lint
- run: npm run test
- run: npm run build
5. パフォーマンスモニタリング
- Web Vitals:ページパフォーマンス測定
- Lighthouse CI:継続的なパフォーマンス監視
- Bundle Analyzer:バンドルサイズ分析
- React Profiler:レンダリング性能分析
将来を見据えた開発環境の選択
2025年以降のReact開発において、以下の点を考慮した開発環境を構築することが重要です:
- サーバーコンポーネント対応:Next.js App RouterやRemixの採用
- バンドルレス開発:Viteやesbuildの活用
- TypeScriptファースト:最初からTypeScriptで開発
- パフォーマンス重視:Core Web Vitalsの最適化
- 開発者体験:高速な開発環境とデバッグツール
- スケーラビリティ:大規模開発に対応できるアーキテクチャ
これらの要素を組み合わせることで、現在だけでなく将来のReact開発トレンドにも対応できる、堅牢で効率的な開発環境を構築できます。
よくある質問(FAQ)
-
create-react-appを使い続けても問題ないですか?
-
短期的には、現在稼働しているCRAプロジェクトをすぐに停止する必要はありません。既存のプロジェクトが特定の要件を満たしており、パフォーマンスやセキュリティのリスクが許容範囲内であれば、そのまま運用を続けることは可能です。しかし、新規プロジェクトでのCRAの採用は強く推奨しません。長期的に見ると、メンテナンスの停滞、最新React機能への非対応、パフォーマンスの課題、セキュリティリスクの増加など、多くのデメリットが生じ、結果的に技術的負債となる可能性が高いです。
-
React初心者なのですが、CRAを使わない場合、何から学ぶべきですか?
-
Reactの学習を始める場合、ViteとNext.jsのどちらかを強く推奨します。
- Vite + React: より純粋なReact(SPA開発)の基本を学びたい初心者にはViteが最適です。設定が非常にシンプルで、開発サーバーの起動やHMRが驚くほど高速なため、ストレスなくReactのコードに集中できます。
- Next.js + React: WebサイトやWebアプリケーション全体を構築したい場合はNext.jsがおすすめです。ファイルシステムルーティングやデータフェッチの概念も同時に学ぶことができ、より実用的なスキルが身につきます。公式ドキュメントも非常に充実しています。
まずはViteでReactの基礎を固め、その後Next.jsでより高度なWeb開発の概念を学ぶ、というステップも効果的です。
-
企業やチームでCRAを使っていますが、どのように移行を進めるべきですか?
-
企業やチームでの移行は、段階的に慎重に進めるのが現実的です。
- 新規プロジェクトでの導入: まずは新規プロジェクトでViteやNext.jsを導入し、チーム内で新しい開発環境の知見と経験を蓄積します。
- 技術選定の根拠共有: 本記事のような情報をもとに、CRAの課題とモダンな代替ツールのメリット(開発効率、パフォーマンス、将来性など)を明確に説明し、上司やチームメンバーの理解を得ます。
- 小規模な既存プロジェクトからの移行: まずは比較的小規模で影響範囲の少ないCRAプロジェクトを選び、ViteやNext.jsへの移行を試行します。ここで得られた知見や課題を共有し、移行手順を確立します。
- 段階的な大規模プロジェクトの移行: 大規模なプロジェクトでは、一度に全てを移行するのはリスクが高いです。機能単位やモジュール単位で徐々に移行していく「ストラングラーパターン」のような手法も検討できます。
- 学習とトレーニング: 新しいツールやフレームワークの学習時間とトレーニング機会をチームに提供し、スムーズな移行をサポートします。
-
CRAにしかない機能や特徴は、他の代替ツールでどう代替できますか?
-
CRAにはService WorkerによるPWA(Progressive Web App)のサポートや、
eject
によるWebpack設定のカスタマイズ機能がありました。- PWA: Viteでは
vite-plugin-pwa
のようなプラグインを導入することでService Workerやマニフェストファイルの設定を簡単に行い、PWAに対応できます。Next.jsでも同様のプラグインや独自のPWA対応策があります。 - Webpack設定のカスタマイズ: CRAの
eject
やreact-app-rewired
で実現していたWebpackのカスタマイズは、Viteではvite.config.js
内で直接Rollupプラグインを利用したり、シンプルなViteプラグインを開発することで同等以上の柔軟性を提供します。Next.jsやRemixはフレームワークとして提供しているため、個別のバンドラー設定よりもフレームワークの規約に従うことで、より最適化されたビルドを享受できます。
- PWA: Viteでは
まとめ
Create React App(CRA)の非推奨化は、React開発者にとって大きな転換点となっています。本記事では、CRAの現状から最新の代替ツール、そして実践的な移行方法まで詳しく解説してきました。
まず押さえておきたいのは、CRAが「完全に使用不可」になったわけではないという点です。しかし、モダンな開発環境と比較すると、開発速度やビルドパフォーマンスの面で明らかに劣っているのが現実です。特に以下の課題は無視できません:
- 開発サーバーの起動が遅い(大規模プロジェクトでは数分かかることも)
- ホットリロードの反応が鈍い(変更反映に2-5秒)
- 最新のReact機能への対応が遅れがち
- eject後のメンテナンスが困難
これらの問題を解決するため、2025年現在では以下のモダンなツールが主流となっています:
新規プロジェクトで選ぶべきツール
- Vite:圧倒的な開発速度と軽量な設定が魅力
- Next.js:SEO対応やフルスタック開発に最適
- Remix:Web標準に準拠した次世代フレームワーク
- Parcel:設定不要で即座に開発開始可能
特にViteは、ESMベースの開発環境により従来の10倍以上の速度を実現しており、個人開発から中規模なSPAまで幅広く対応できます。一方、SEOが重要なWebサイトや大規模なアプリケーションでは、Next.jsの採用が増加しています。
既存のCRAプロジェクトをお持ちの方は、段階的な移行を検討することをお勧めします。移行作業では以下の点に注意が必要です:
移行時の重要ポイント
- 環境変数のプレフィックス変更(REACT_APP_ → VITE_ / NEXT_PUBLIC_)
- パスエイリアスの設定調整
- CSS/SCSSファイルのインポート方法
- テスト環境の再構築
- プロキシ設定の移行
移行作業は一見複雑に思えますが、本記事で紹介した手順に従えば、多くの場合は数時間から1日程度で完了できます。特に重要なのは、移行前の準備として既存プロジェクトのバックアップを取り、依存関係を整理しておくことです。
最後に、どのツールを選択するかは、あなたのプロジェクトの特性と要件によって決まります。個人開発や学習目的であればVite、SEOが重要なサイトであればNext.js、Web標準を重視するならRemixと、目的に応じて最適なツールを選択してください。
重要なのは、新しい技術に対して恐れるのではなく、積極的に学び、実践することです。CRAの非推奨化は確かに大きな変化ですが、同時により良い開発環境を手に入れる絶好の機会でもあります。
この記事が、あなたのReact開発をより効率的で楽しいものにする一助となれば幸いです。モダンな開発環境で、快適なコーディング体験を手に入れましょう。

