Vercel公式React Best Practicesを読み解く：AIコーディング時代に有効なルールとアンチパターン化しうるルールの見極め方

お疲れ様です！IT業界で働くアライグマです！

結論から言うと、Vercel公式の「React Best Practices」はすべてを鵜呑みにするのではなく、自社のプロジェクト規模やチーム構成に合わせて取捨選択すべきです。

「Vercelが公式に出したベストプラクティスだから全部従おう」「SNSで賛否が分かれているけど、結局どれが正しいの？」——こんな声をよく耳にします。

今回は、2026年1月に公開されたVercel公式のReact Best Practicesについて、PjMとして複数のReact/Next.jsプロジェクトを見てきた経験を踏まえて、40以上あるルールを「どの条件下で有効か」「どこがアンチパターンになりうるか」という観点から検証していきます。

React Best Practicesとは何か（背景と概要）

まず、今回話題になっている「React Best Practices」の位置づけを整理しておきましょう。

Vercelによる公式発表

2026年1月、Vercelは「Introducing React Best Practices」として、公式ブログで40以上のルール集を公開しました。これは「Vercelが10年以上にわたって蓄積してきたReactとNext.jsの最適化ノウハウを体系化したもの」と説明されています。

8つのカテゴリに分類された力の入ったルール集で、以下のような構成になっています。

• コンポーネント設計：単一責任の原則、Props drilling回避など
• 状態管理：useState vs useReducer、グローバル状態の扱い
• パフォーマンス：メモ化戦略、レンダリング最適化
• Server Components：RSC（React Server Components）の活用方針
• データフェッチ：SWR/React Query、Suspenseの使い方
• ルーティング：App Router移行、動的ルーティング設計
• スタイリング：CSS Modules vs Tailwind、CSS-in-JS
• テスト：単体テスト、E2Eテスト戦略

SNSでの反応と賛否

公開直後からSNSでは賛否が分かれています。Zennで公開されたレビュー記事「React Best Practicesはむしろアンチパターン説」では、Claude Sonnetにルールのコードレビューをさせた結果が共有され、「一部のルールは特定の前提を満たさないとアンチパターンになる」という指摘がありました。

多くのプロジェクト現場でも、「ベストプラクティス」が文脈を無視して適用されると逆効果になるケースがよく見られます。

詳しくはNext.jsからViteへの移行判断ガイドの記事でも、フレームワーク選定時の評価軸について触れています。

IT女子 アラ美

公式が出しているなら、とりあえず全部守ればいいんじゃないですか？

ITアライグマ

残念ながら、それは危険です。プロジェクトの規模やチームの成熟度によって、最適解は変わります。大切なのは「なぜそのルールが有効か」を理解することですね。

ルール別の有効性評価（ケーススタディ）

ここでは、40以上あるルールの中から代表的なものを取り上げ、「どの条件下で有効か」を検証します。

強く推奨できるルール（12件）

以下のルールは、ほぼすべてのプロジェクトで有効です。

• key propsには安定したIDを使う：配列のindexをkeyにすると、並び替え時にDOMの再利用が正しく行われない。これはReactの基本原則
• useEffectの依存配列を正しく設定する：ESLintのexhaustive-depsルールを有効にすべき。無限ループやstale closureを防ぐ
• ErrorBoundaryを設置する：障害時のグレースフルデグラデーションに必須

条件付きで有効なルール（8件）

以下のルールは、特定の条件を満たすと有効になります。

• React.memoを適切に使う：「適切に」が曲者。過度なメモ化はかえってパフォーマンスを悪化させる。プロファイラで計測してから適用すべき
• Context APIでグローバル状態を管理する：小規模なら有効だが、頻繁に更新される状態には向かない。Jotai/Zustandの方が適切な場合も多い
• Server Componentsをデフォルトにする：Next.js App Routerでは有効だが、既存のPages Routerプロジェクトでは移行コストが大きい

前提次第で評価が分かれるルール（14件）

以下のルールは、プロジェクトの前提によって評価が大きく変わります。

• CSS-in-JSを避ける：Vercelの立場ではTailwindを推奨するのは当然だが、既存のstyled-components資産が大きいプロジェクトでは移行コストが現実的でない
• カスタムフックで処理を抽象化する：抽象化レイヤーを増やすと、AIツール（Cursor/Copilot）がコンテキストを理解しにくくなる場合がある
• コンポーネントを細かく分割する：単一責任の原則は重要だが、過度な分割は可読性を下げる

詳しくはFastAPIで構築するモジュラーモノリスの記事でも「適切な粒度」について触れていますが、フロントエンドでも同じ問題が発生します。

IT女子 アラ美

AIツールがコンテキストを理解しにくくなるって、具体的にはどういうことですか？

ITアライグマ

たとえば、処理が5階層のカスタムフックに分散していると、Cursorが「この関数は何をしているか」を推論するのに必要なファイルが増えて、精度が落ちることがあります。

AIコーディング時代に求められる設計指針

ここでは、Claude Code/Cursor/GitHub Copilotなどの「AIコーディングツール」が普及した現代において、React Best Practicesをどう読み替えるべきかを考えます。

状況（Before）

当初、あるNext.jsプロジェクトのチームではVercelのBest Practicesに従い、以下の方針を採用しました。

• 構成：Next.js App Router + React Server Components
• 抽象化：すべてのデータ取得ロジックをカスタムフックに抽出
• コンポーネント：1ファイル1コンポーネント、50行以下を原則化
• 問題：Claude CodeやCursorでコード生成・修正を依頼すると、文脈が分散しすぎてハルシネーションが増えた

行動（Action）

1週目に以下の検証を行いました。

1. 抽象化レイヤーの見直し：カスタムフックの階層を3階層→2階層に削減。共通化よりも「AIが理解しやすいか」を優先基準に変更した
2. コロケーション原則の導入：関連する処理を同一ファイル・同一ディレクトリにまとめた。たとえばfeatures/user/配下にコンポーネント・フック・型定義を集約した
3. 明示的なコメントの追加：AIがコンテキストを把握しやすいよう、各ファイルの冒頭に「このモジュールの責務」を30文字以内で記述するルールを追加した

結果（After）

• AI生成コードの精度向上：Cursorでの「この関数を修正して」という指示の成功率が体感で30%改善した
• コードレビューの効率化：PRあたりの指摘件数が平均8件→5件に減少
• オンボーディング時間：新規参画者が機能追加できるようになるまでの期間が2週間→10日に短縮

ハマりポイント

最初は「抽象化を減らす＝DRY原則に反する」という抵抗がチーム内にありました。しかし、「AIがコンテキストを理解できないコードは、人間にとっても理解しにくい」という視点を共有することで合意形成できました。詳しくはadversarial-specで仕様策定を自動化するの記事で紹介したように、AIを活用した仕様策定も有効です。

IT女子 アラ美

抽象化を減らすと、同じコードがあちこちに出てきて保守性が下がりませんか？

ITアライグマ

確かにその懸念はあります。ただ、AIがすばやく修正できるコードは、多少の重複があっても保守コストが低いという経験則があります。バランスが大切ですね。

実務での評価フレームワーク

ここでは、新しいベストプラクティスが発表されたときに、自分のプロジェクトで有効かどうかを判断するためのフレームワークを整理します。

5つの評価軸

1. プロジェクト規模：個人開発か、10人以上のチームか。規模が大きいほど「標準化」の価値が上がり、ルール遵守のメリットが増える
2. チームの成熟度：React経験が浅いチームには「原則を守る」指針が有効。熟練チームには「例外を許容」した方が生産性が上がる
3. 既存資産：すでにstyled-componentsで10万行あるプロジェクトでは、Tailwind移行のコストが現実的でない
4. AIツールの活用度：Cursor/Copilotを積極的に使うチームでは、「AIが理解しやすい構造」を優先すべき
5. パフォーマンス要件：Core Web Vitalsが厳格に求められるプロジェクトでは、RSC（React Server Components）への移行優先度が上がる

チェックリスト

新しいルールを導入する前に、以下を確認しましょう。

• このルールの「なぜ」を説明できるか？
• 自分のプロジェクトの前提と一致しているか？
• 導入コストと得られるメリットを定量化できるか？
• 段階的に導入できるか、一括で入れ替える必要があるか？

詳しくはGitHub Copilotを極めるの記事で、AIツール活用時の設計指針を紹介しています。

本記事で解説したようなAI技術を、基礎から体系的に身につけたい方は、以下のスクールも検討してみてください。

比較項目	DMM 生成AI CAMP	Aidemy Premium
目的・ゴール	ビジネス活用・効率化非エンジニア向け	エンジニア転身・E資格Python/AI開発
難易度	初心者◎プロンプト作成中心	中級者〜コード記述あり
補助金・給付金	最大70%還元リスキリング補助金対象	最大70%還元教育訓練給付金対象
おすすめ度	S今の仕事に活かすなら	AAIエンジニアになるなら
公式サイト	詳細を見る	−

IT女子 アラ美

AIスキルを身につけたいけど、どのスクールを選べばいいかわからないです…

ITアライグマ

現場で即・AIを活用したいならDMM 生成AI CAMPがおすすめです！プロンプト中心で初心者でも取り組みやすいですよ。

まとめ

Vercel公式のReact Best Practicesは、貴重なナレッジの体系化です。しかし、盲目的に適用するのではなく、自分のプロジェクトの文脈で評価することが重要です。

• 強く推奨できるルール（12件）：key props、useEffectの依存配列、ErrorBoundaryなど。ほぼすべてのプロジェクトで有効
• 条件付きで有効なルール（8件）：React.memo、Context API、RSCなど。前提条件を確認してから適用する
• 前提次第のルール（14件）：CSS-in-JS回避、過度な分割など。プロジェクトの状況によってはアンチパターンになりうる
• AIコーディング時代の視点：「AIが理解しやすいコード」を設計指針に加える。過度な抽象化はAIの文脈理解を妨げる

新しいベストプラクティスが出たときは、「なぜこのルールが有効なのか」を理解した上で、自分のプロジェクトに合った形で取り入れてください。

IT女子 アラ美

結局、全部のルールを覚える必要があるんですかね……。

ITアライグマ

いいえ、まずは「強く推奨」の12件を押さえておけば大丈夫です。残りは必要になったときに判断すればいいので、焦らずいきましょう。

厳しめIT女子 アラ美による解説ショート動画はこちら