Reactのコンポーネント設計で迷ったらこれ！開発効率が劇的に向上するオススメの構成パターン

Reactでアプリケーションを開発していると、「このコンポーネントはどこまで責務を持たせるべきか」「ファイルはどう分割するべきか」「状態管理をどのレイヤーに置くべきか」といった設計上の悩みに直面することがあります。
小規模な開発では問題なく見えても、機能追加やメンバー増加に伴ってコンポーネント構成の複雑さが増し、保守性や開発効率の低下を招くケースは少なくありません。

特にReactは自由度が高いライブラリであるため、同じ機能を実現する場合でも複数の設計アプローチが存在します。
そのため、明確な指針がないまま実装を進めると、プロジェクトごとに構造がばらつき、コードレビューや機能改修のコストが増大しやすくなります。

そこで重要になるのが、コンポーネントの責務を適切に分離し、再利用性と可読性のバランスを考慮した設計パターンを採用することです。
適切な構成パターンを選択することで、コードの見通しが良くなるだけでなく、テストのしやすさやチーム開発における生産性の向上にもつながります。

本記事では、Reactのコンポーネント設計で迷った際に役立つ代表的な構成パターンを取り上げ、それぞれの特徴やメリット、どのような場面で採用すべきかを整理しながら解説します。
また、実際の開発現場で頻繁に発生する設計上の課題を例に挙げながら、開発効率を高めるための考え方についても紹介します。
Reactプロジェクトの保守性や拡張性を改善したい方は、ぜひ最後までご覧ください。

Reactのコンポーネント設計が開発効率を左右する理由
1. コンポーネント設計が悪化すると発生する典型的な問題
2. 保守性と拡張性を高める設計の重要性
Reactコンポーネント設計で押さえるべき基本原則
最初に知っておきたいPresentationalとContainerパターン
カスタムフックを活用したロジック分離パターン
1. Custom Hooksで再利用性を高める方法
2. UIとビジネスロジックを切り離すメリット
Feature-Sliced Designで大規模開発に対応する
Atomic DesignはReact開発で採用すべきか
実践的なReactフォルダ構成のおすすめ例
設計パターンを選ぶ際の判断基準
Reactのコンポーネント設計は責務分離と継続的な改善が重要

Reactのコンポーネント設計が開発効率を左右する理由

ReactはコンポーネントベースでUIを構築できる優れたライブラリですが、その柔軟性の高さゆえに設計の品質が開発効率へ大きな影響を与えます。
小規模なプロジェクトでは多少設計が粗くても問題なく開発を進められる場合がありますが、機能追加や開発メンバーの増加に伴い、コンポーネント設計の良し悪しが顕著に表れるようになります。

特にReactでは、コンポーネント単位で責務を分割して機能を組み立てるため、設計段階で適切な構造を選択しているかどうかが、将来的な保守コストや開発速度を大きく左右します。

ソフトウェア工学の観点では、システムの複雑性は時間の経過とともに増大する傾向があります。
そのため、開発初期からコンポーネントの責務や依存関係を整理し、変更に強い構造を構築することが重要です。

コンポーネント設計が悪化すると発生する典型的な問題

React開発において設計が悪化すると、まず発生しやすいのが責務の肥大化です。

例えば、1つのコンポーネントの中で以下のような処理をすべて行っているケースがあります。

API通信
状態管理
データ加工
バリデーション
UI描画

このような状態になると、コンポーネントが数百行から数千行規模へ肥大化し、コードの理解が困難になります。

また、ある機能を修正した際に別の機能へ影響が及ぶケースも増加します。
これはコンポーネント間の依存関係が複雑になり、変更範囲を予測しにくくなるためです。

特にチーム開発では、設計品質の低下によって次のような問題が発生しやすくなります。

問題	原因	発生する影響
コードレビューが長引く	責務が不明確	開発速度低下
バグ修正が困難	依存関係が複雑	品質低下
再利用できない	汎用性不足	重複コード増加
新規参加者が理解しづらい	構造が統一されていない	学習コスト増加

コンピューターサイエンスでは「凝集度は高く、結合度は低く」という設計原則が重要視されます。
Reactのコンポーネント設計でも同様であり、1つのコンポーネントは明確な役割だけを持ち、他のコンポーネントへの依存を最小限に抑えることが望ましいです。

設計が悪化したプロジェクトでは、機能追加そのものよりも既存コードの理解に多くの時間を消費するようになります。
その結果、本来価値を生み出すべき開発作業に集中できなくなってしまいます。

保守性と拡張性を高める設計の重要性

Reactプロジェクトは完成した時点で終わるものではありません。
多くの場合、リリース後も機能追加や仕様変更が継続的に発生します。
そのため、初期段階から保守性と拡張性を意識した設計が必要になります。

保守性とは、既存機能を安全かつ容易に修正できる性質を指します。
一方で拡張性とは、新しい機能を既存コードへ大きな影響を与えず追加できる性質を意味します。

例えば、ボタンコンポーネントを考えてみましょう。
特定画面専用として実装すると短期間では効率的に見えますが、後から別画面でも同じデザインを利用したい場合に再実装が必要になります。

一方で、汎用的な設計を行っておけば、プロパティを変更するだけで複数箇所から再利用できます。
結果としてコード量の削減だけでなく、デザイン変更時の修正箇所も最小限になります。

さらに保守性の高い設計には次のようなメリットがあります。

テストしやすい
コードレビューしやすい
不具合を発見しやすい
新規メンバーが理解しやすい
機能追加時の影響範囲を把握しやすい

Reactのコンポーネント設計を考える際は、現在の要件だけではなく半年後や1年後の変更も想定することが重要です。

優れた設計とは、単にコードが美しい状態ではありません。
変更要求に柔軟に対応でき、チーム全体の生産性を継続的に向上させられる構造こそが、実践的な意味で優れた設計といえます。
Reactの開発効率を高めるためには、まずコンポーネント設計がソフトウェア全体の品質を支える基盤であることを理解する必要があります。

Reactコンポーネント設計で押さえるべき基本原則

Reactのコンポーネント設計を考える際、多くの開発者はフォルダ構成やライブラリ選定に注目しがちです。
しかし、実際に保守性や開発効率へ大きな影響を与えるのは、設計の根底にある原則です。

どれほど優れたフレームワークやツールを採用していても、コンポーネントの責務が曖昧であったり、状態管理が混在していたりすると、コードベースは急速に複雑化します。
反対に、基本原則を意識して設計されたプロジェクトは、規模が大きくなっても比較的安定した開発を継続できます。

ソフトウェア工学では、変更しやすさと理解しやすさが設計品質を評価する重要な指標とされています。
Reactにおいても、この考え方はそのまま当てはまります。

単一責任の原則を意識する

Reactコンポーネント設計において最も重要な考え方の一つが、単一責任の原則です。

単一責任の原則とは、「1つのモジュールは1つの責務だけを持つべきである」という設計原則です。
Reactでは、コンポーネントごとに明確な役割を持たせることを意味します。

例えば、ユーザー情報を表示する画面を考えてみましょう。
以下のような処理をすべて1つのコンポーネントに詰め込むケースがあります。

APIからのデータ取得
ローディング状態管理
エラーハンドリング
データ加工
UI表示

このような設計は初期段階では便利に見えますが、機能追加のたびにコンポーネントが肥大化し、修正コストが増大します。

より望ましい設計は、それぞれの責務を分離することです。

function UserProfile({ user }) {
  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
}

このコンポーネントは表示だけを担当しています。
データ取得や状態管理を別レイヤーへ分離することで、責務が明確になります。

責務が明確なコンポーネントには次のような利点があります。

テストしやすい
再利用しやすい
レビューしやすい
バグの原因を特定しやすい

特にチーム開発では、コンポーネント名を見ただけで役割が理解できる状態を目指すことが重要です。

再利用性と可読性のバランスを取る

React開発では再利用性が重視されることが多いため、過度な抽象化が行われる場合があります。
しかし、再利用性を追求しすぎると逆に可読性が低下することがあります。

例えば、ボタンコンポーネントを極端に汎用化したケースを考えてみましょう。

<Button
  variant="primary"
  size="large"
  shape="rounded"
  elevation="medium"
  animation="fade"
  iconPosition="left"
/>

このような設計は柔軟性が高い反面、設定項目が増え続けることで利用側の理解コストが高くなります。

設計において重要なのは、再利用性と可読性のバランスです。

以下の表は両者の特徴を整理したものです。

重視する要素	メリット	デメリット
再利用性	重複コード削減	抽象化が進みやすい
可読性	理解しやすい	重複実装が増える場合がある
バランス重視	保守性向上	設計判断が必要

コンピューターサイエンスでは「過度な一般化は複雑性を増やす」という考え方があります。

そのため、現時点で利用箇所が1か所しかない処理まで無理に共通化する必要はありません。
まずは読みやすく実装し、複数箇所で同じパターンが現れた段階で共通化するほうが、結果的に保守しやすい構造になることが多いです。

設計判断ではDRY（Don’t Repeat Yourself）だけでなく、YAGNI（You Aren’t Gonna Need It）の考え方も意識するとよいでしょう。

状態管理の責務を適切に分離する

Reactアプリケーションが複雑化する最大の要因の一つが状態管理です。

コンポーネント設計が適切でも、状態管理の責務が整理されていなければ保守性は大きく低下します。

特によく見られる問題として、すべての状態を親コンポーネントへ集約してしまうケースがあります。

初期段階では管理しやすく見えますが、アプリケーションが成長すると状態の依存関係が複雑になり、どの変更がどこへ影響するのか把握しづらくなります。

Reactでは状態を以下のように分類して考えると整理しやすくなります。

状態の種類	例	管理場所
ローカル状態	モーダル開閉	コンポーネント内部
画面共有状態	検索条件	親コンポーネント
アプリ全体状態	認証情報	Contextや状態管理ライブラリ
サーバー状態	APIデータ	React Queryなど

重要なのは、状態を必要以上に上位へ持ち上げないことです。

Reactの公式ドキュメントでも「State Lifting」は必要な範囲に限定することが推奨されています。
状態が利用される範囲を正しく見極め、その責務に応じて管理場所を決定することで、コンポーネント同士の結合度を下げられます。

優れたReact設計は、単にコンポーネントを細かく分割することではありません。
責務を明確にし、適切な抽象化を行い、状態管理を整理することで、長期的に変更しやすい構造を実現することにあります。
これらの基本原則を理解することが、保守性と開発効率を高める第一歩となります。

最初に知っておきたいPresentationalとContainerパターン

Reactのコンポーネント設計を学ぶ際、多くの開発者が一度は耳にするのがPresentationalとContainerパターンです。
これはReactがクラスコンポーネント中心だった時代から広く利用されてきた設計手法ですが、Hooksが主流となった現在でも設計の考え方として高い価値を持っています。

近年ではCustom HooksやReact Queryなどの登場によって実装方法は変化していますが、「UIの責務」と「データやロジックの責務」を分離するという基本思想は変わっていません。

実際、大規模なReactプロジェクトを分析すると、名前こそ異なるものの、多くのコードベースで同様の責務分離が行われています。
設計パターンとしての名称を知らなくても、優れた開発チームは自然と同じ方向へたどり着くことが少なくありません。

そのため、このパターンを理解することは単なる知識習得ではなく、Reactにおける責務分離の本質を理解することにつながります。

Presentational Componentの役割

Presentational Componentは、その名の通り「表示」に特化したコンポーネントです。

主な責務はユーザーインターフェースの描画であり、データ取得やビジネスロジックを持たないことが特徴です。

例えば商品情報を表示するコンポーネントであれば、受け取ったデータを画面へ描画することだけに集中します。

type ProductCardProps = {
  name: string;
  price: number;
};
export function ProductCard({
  name,
  price,
}: ProductCardProps) {
  return (
    <article>
      <h3>{name}</h3>
      <p>¥{price}</p>
    </article>
  );
}

このコンポーネントは商品データを取得しません。
API通信も行いません。
ただ渡された値を表示するだけです。

一見すると単純な設計に見えますが、この考え方には大きな利点があります。

テストが容易になる
UI確認がしやすい
再利用性が高まる
ビジネスロジックの影響を受けにくい
デザイナーとの連携がしやすい

特にコンポーネント単体で動作を確認しやすくなるため、StorybookなどのUI開発環境とも相性が良いです。

また、表示専用コンポーネントは入力と出力が明確です。
コンピューターサイエンスでいう純粋関数に近い性質を持つため、予測可能性が高くなります。

結果として、機能追加やデザイン変更が発生した際にも影響範囲を限定しやすくなります。

Container Componentの役割

Container Componentは、アプリケーションのロジックを担当するコンポーネントです。

Presentational ComponentがUIを担当するのに対し、Container Componentはデータ取得や状態管理を担当します。

例えばユーザー情報をAPIから取得し、その結果を表示コンポーネントへ渡す処理が該当します。

export function UserProfileContainer() {
  const { data, isLoading } = useUser();
  if (isLoading) {
    return <div>Loading...</div>;
  }
  return (
    <UserProfile
      name={data.name}
      email={data.email}
    />
  );
}

この例では、データ取得の責務はContainer側にあります。
一方で表示そのものは別コンポーネントへ委譲しています。

この分離によって次のような効果が得られます。

項目	Container	Presentational
API通信	担当する	担当しない
状態管理	担当する	基本的に担当しない
UI描画	最小限	主に担当する
再利用性	やや低い	高い

重要なのは、ロジックとUIが独立して進化できる点です。

例えばAPIの仕様が変更された場合でも、Container側の修正だけで済むことがあります。
逆にデザイン変更であればPresentational Componentだけを修正すれば対応できます。

責務の境界が明確になることで、開発チーム内の作業分担も行いやすくなります。

現在でも有効な活用シーン

Hooks中心のReact開発が主流となった現在、「Containerパターンは古い」という意見を見かけることがあります。

確かに、Custom Hooksによってロジックを分離できるようになったため、従来のContainer Componentを大量に作る必要は減りました。

しかし、責務分離という考え方自体は現在でも非常に重要です。

むしろ大規模開発になるほど、この思想の価値は高まります。

例えば次のようなケースでは現在でも有効です。

複雑なAPI通信がある画面
管理画面の一覧表示機能
フォーム処理が多いシステム
チーム開発を行うプロジェクト
長期間運用されるサービス

近年では以下のような構成がよく採用されます。

Page
 ├─ Custom Hook
 │    └─ API通信
 └─ UI Component

実装方法は変化していますが、本質的にはContainerとPresentationalの責務分離と同じ考え方です。

コンポーネント設計において重要なのは、特定のパターンを機械的に適用することではありません。
UIとロジックを適切に分離し、それぞれの責務を明確にすることです。

PresentationalとContainerパターンは、React設計の歴史の中で培われた重要な知見です。
現代のHooksベース開発においても、その考え方を理解しておくことで、より保守性が高く拡張しやすいコンポーネント設計を実現できるようになります。

カスタムフックを活用したロジック分離パターン

Reactの設計手法は進化を続けていますが、その中でも特に大きな変化をもたらしたのがHooksの登場です。
従来はContainer Componentに集約されていたロジックを、より柔軟かつ再利用しやすい形で切り出せるようになりました。

その中心となる仕組みがCustom Hooksです。

Custom Hooksを適切に活用すると、コンポーネントからビジネスロジックや状態管理を分離できるため、コードの見通しが大幅に改善されます。
また、複数の画面や機能で同じ処理を共有しやすくなるため、保守性や開発効率の向上にもつながります。

近年のReact開発では、コンポーネントそのものを小さく保ちながら、複雑なロジックをCustom Hooksへ集約する設計が主流になりつつあります。
そのため、Reactのコンポーネント設計を考える上で、Custom Hooksの理解は欠かせません。

Custom Hooksで再利用性を高める方法

Custom Hooksの最大のメリットは、状態管理やロジックを独立した単位として再利用できることです。

例えば、検索フォームを持つ複数の画面が存在するとします。
それぞれのコンポーネントで検索キーワードの状態管理や入力処理を実装すると、同じようなコードが各所に散在することになります。

このような場合、ロジックをCustom Hooksへ切り出すことで重複を防げます。

import { useState } from "react";
export function useSearchKeyword() {
  const [keyword, setKeyword] = useState("");
  const clearKeyword = () => {
    setKeyword("");
  };
  return {
    keyword,
    setKeyword,
    clearKeyword,
  };
}

利用側は以下のようになります。

const {
  keyword,
  setKeyword,
  clearKeyword,
} = useSearchKeyword();

この設計によって、検索キーワード管理のロジックを複数の画面から利用できるようになります。

さらに重要なのは、ロジックの修正箇所を一か所へ集約できることです。
例えば検索条件の初期値やバリデーション仕様が変更された場合でも、Custom Hooks側を修正するだけで済みます。

ソフトウェア工学では「単一の真実の源泉（Single Source of Truth）」という考え方があります。
同じロジックを複数箇所へコピーするのではなく、一か所に集約することで保守コストを削減できます。

Custom Hooksはまさにその考え方をReactで実現するための仕組みといえます。

再利用性の観点から見ると、以下のような処理はCustom Hooksとの相性が良いです。

処理内容	Custom Hooks化の効果	再利用性
フォーム管理	入力処理の共通化	高い
API通信	データ取得処理の統一	高い
認証処理	ログイン状態の共有	高い
ページネーション	一覧画面で使い回せる	高い
フィルタリング処理	条件検索の共通化	高い

このような共通ロジックを切り出すことで、コンポーネント自体は本来の役割であるUI描画に集中できるようになります。

UIとビジネスロジックを切り離すメリット

Reactアプリケーションが複雑化する大きな要因の一つは、UIコードとビジネスロジックが混在することです。

例えば、商品一覧画面のコンポーネント内に以下のような処理がすべて書かれているケースがあります。

API通信
データ整形
エラーハンドリング
ローディング制御
UI描画

この状態では、画面表示のコードを確認したいだけなのに、ロジックも同時に読まなければなりません。
その結果、コードの理解コストが上昇します。

そこで有効なのが、ビジネスロジックをCustom Hooksへ切り出す方法です。

例えば商品一覧取得処理を独立させる場合、コンポーネント側は次のようなイメージになります。

function ProductList() {
  const {
    products,
    isLoading,
  } = useProducts();
  if (isLoading) {
    return <p>Loading...</p>;
  }
  return (
    <ul>
      {products.map(product => (
        <li key={product.id}>
          {product.name}
        </li>
      ))}
    </ul>
  );
}

このコードを見ると、コンポーネントがUI描画に集中していることが分かります。

一方で、データ取得やエラーハンドリングはCustom Hooks側に閉じ込められています。

この分離によって得られるメリットは非常に大きいです。

まず、コンポーネントの可読性が向上します。
UI担当者は画面表示部分だけを確認すればよくなり、ロジック担当者はCustom Hooksだけを見ればよくなります。

また、テストの観点でも有利です。
ビジネスロジックを独立させることで、ロジック単体のテストとUIのテストを分離できます。

さらに、大規模開発では役割分担がしやすくなります。

担当領域	主な作業
UIコンポーネント	レイアウト・デザイン実装
Custom Hooks	状態管理・業務ロジック実装
API層	データ取得処理
テスト	ロジックとUIの検証

このような構造は、コンピューターサイエンスにおける関心の分離（Separation of Concerns）の考え方に基づいています。

優れたソフトウェア設計では、それぞれのモジュールが独立した責務を持ち、相互依存を最小限に抑えることが重要です。
Custom HooksはReactにおいてその原則を実現する有効な手段といえます。

現代のReact開発では、コンポーネントを細かく分割するだけでは十分ではありません。
UIとビジネスロジックを明確に切り離し、再利用可能な単位として管理することが重要です。
Custom Hooksを活用したロジック分離パターンは、そのための実践的かつ効果的なアプローチであり、保守性と開発効率の両方を高める設計手法として広く活用されています。

Feature-Sliced Designで大規模開発に対応する

Reactプロジェクトが成長すると、多くの開発チームが直面するのがディレクトリ構成の複雑化です。
開発初期はシンプルだった構造も、機能追加を繰り返すうちにコンポーネントやHooks、API処理、ユーティリティ関数が増加し、どこに何があるのか把握しづらくなります。

特に複数人で開発を行う場合、フォルダ構成の分かりやすさは生産性へ直結します。
適切な構成が存在しないと、機能追加のたびにファイル配置がばらつき、コードベース全体の一貫性が失われていきます。

こうした課題を解決するための設計手法として近年注目されているのがFeature-Sliced Design（FSD）です。

Feature-Sliced Designは、単なるフォルダ整理術ではありません。
大規模なフロントエンドアプリケーションを長期間保守することを前提に考案されたアーキテクチャ設計手法です。

Reactプロジェクトの規模が拡大するほど、その効果を実感しやすくなります。

Feature-Sliced Designとは何か

Feature-Sliced Designは、機能単位でコードを整理することを目的としたアーキテクチャです。

従来のReactプロジェクトでは、以下のような技術単位でフォルダを分割するケースが一般的でした。

components/
hooks/
pages/
services/
utils/

この構成は小規模開発では十分機能します。
しかし機能数が増えると、ある機能に関連するコードが複数フォルダへ分散し、追跡が困難になります。

例えばユーザー管理機能を修正したい場合、複数のディレクトリを横断して探さなければなりません。

Feature-Sliced Designでは、この問題を機能単位の整理によって解決します。

基本的には以下のレイヤー構造で設計されます。

レイヤー	役割
app	アプリ全体設定
pages	ページ単位の構成
widgets	複数機能を組み合わせたUI
features	ユーザー操作を実現する機能
entities	ドメインモデル
shared	共通部品やユーティリティ

重要なのは、それぞれのレイヤーに明確な責務が定義されていることです。

ソフトウェアアーキテクチャでは依存関係の管理が非常に重要ですが、Feature-Sliced Designではレイヤーごとの依存方向が整理されているため、意図しない結合を防ぎやすくなります。

結果として、機能追加や仕様変更が発生しても構造が崩れにくくなります。

フォルダ構成の具体例

Feature-Sliced Designの特徴を理解するには、実際のフォルダ構成を見るのが最も分かりやすいです。

例えばECサイトのユーザー管理機能を構築する場合、次のような構成になります。

src/
├── app/
├── pages/
│   └── profile/
├── widgets/
│   └── user-profile/
├── features/
│   ├── update-user/
│   └── delete-user/
├── entities/
│   └── user/
└── shared/
    ├── ui/
    └── lib/

従来の構成では、ユーザー関連コードが複数フォルダへ散在していました。

一方でFeature-Sliced Designでは、機能ごとに責務が整理されます。

例えばユーザー更新機能であれば以下のようなファイル群が一箇所へまとまります。

features/
└── update-user/
    ├── ui/
    ├── model/
    ├── api/
    └── lib/

これによって開発者は「ユーザー更新機能を修正したい」と思った際に、その機能のフォルダを見るだけで関連コードを把握できます。

コンピューターサイエンスでは局所性（Locality）という概念があります。
関連する情報が近くに配置されているほど理解しやすくなるという考え方です。

Feature-Sliced Designはまさにこの原則を実践した構造といえます。

また、新規参加者がコードベースを学習する際にも大きな効果があります。
機能ごとに整理されているため、学習対象を限定しながら理解を進められるからです。

中規模から大規模案件で効果を発揮する理由

Feature-Sliced Designは非常に優れた設計手法ですが、すべてのReactプロジェクトに必須というわけではありません。

小規模なWebサイトやランディングページでは、構造が過剰になる場合があります。

しかし中規模以上のプロジェクトになると、その価値が急速に高まります。

特に以下のような条件に当てはまる場合は有力な選択肢になります。

開発メンバーが複数人いる
機能追加が頻繁に発生する
長期運用を前提としている
画面数が多い
ドメイン知識が複雑である

Feature-Sliced Designが効果を発揮する理由は、機能単位で変更を閉じ込められるためです。

例えば新しいユーザー機能を追加する場合でも、既存の注文機能や決済機能へ影響を与えず開発を進めやすくなります。

これはソフトウェア工学におけるモジュール化の利点そのものです。

さらに、チーム開発との相性も非常に優れています。

観点	従来構成	Feature-Sliced Design
機能の発見性	低い	高い
責務の明確さ	やや曖昧	明確
保守性	中程度	高い
大規模開発適性	普通	高い
オンボーディング	時間がかかる	比較的容易

近年のReactアプリケーションは単なるUI表示だけでなく、複雑な業務ロジックを扱うケースが増えています。
そのような環境では、単純なコンポーネント分割だけでは限界があります。

Feature-Sliced Designは、アプリケーション全体を機能単位で整理しながら依存関係を管理できるため、中規模から大規模開発において高い効果を発揮します。
長期的な保守性と拡張性を重視するReactプロジェクトでは、積極的に検討する価値のあるアーキテクチャといえるでしょう。

Atomic DesignはReact開発で採用すべきか

Reactのコンポーネント設計について学んでいると、高い確率で目にするのがAtomic Designです。
UIを階層的に分割して管理する設計手法として広く知られており、多くのフロントエンドプロジェクトで採用実績があります。

特にデザインシステムの構築やコンポーネントの再利用性向上を目的としたプロジェクトでは、Atomic Designが有力な選択肢として検討されることが少なくありません。

一方で、近年では「Atomic Designは複雑になりやすい」「Reactとの相性を慎重に考えるべき」といった意見も見られます。
そのため、名前だけを知っている状態で安易に採用するのではなく、設計思想や適用範囲を正しく理解することが重要です。

Atomic Designは万能な解決策ではありません。
しかし適切な場面で活用すれば、保守性や再利用性の高いUI設計を実現できます。

Atomic Designの基本概念

Atomic Designは、デザイナーのBrad Frost氏によって提唱されたUI設計手法です。

名前の通り、化学における原子構造の考え方をUI設計へ応用しています。

UIを小さな部品から段階的に組み立てることで、整理されたコンポーネント構造を実現します。

Atomic Designでは一般的に以下の5つの階層が使用されます。

階層	役割
Atoms	最小単位のUI部品
Molecules	複数のAtomsを組み合わせた部品
Organisms	機能を持つUIブロック
Templates	レイアウト構造
Pages	実際の画面

例えばECサイトの商品検索画面を例にすると次のようになります。

UI要素	Atomic Design上の分類
ボタン	Atoms
テキスト入力欄	Atoms
検索フォーム	Molecules
ヘッダー	Organisms
商品一覧ページレイアウト	Templates
商品検索画面	Pages

このように、UIを段階的に組み立てていく考え方がAtomic Designの特徴です。

Reactとの相性が良いとされる理由は、React自体がコンポーネントベースの設計思想を採用しているためです。

コンポーネントを小さな単位から組み上げるという考え方は、Atomic Designの思想と自然に一致します。

そのため、特にUIコンポーネントライブラリを構築する際には有効な選択肢となります。

メリットとデメリットを比較する

Atomic Designは非常に有名な設計手法ですが、メリットだけでなく注意すべき点も存在します。

まずは代表的なメリットを見てみましょう。

UIの再利用性が高まる
デザインルールを統一しやすい
コンポーネントの責務が明確になる
デザインシステムと相性が良い
チーム間で共通認識を持ちやすい

特に大規模なサービスでは、同じデザインのボタンや入力フォームが多数登場します。

Atomic Designを採用すると、それらを共通部品として管理できるため、UIの一貫性を維持しやすくなります。

一方で、デメリットもあります。

フォルダ構造が複雑化しやすい
分類基準に迷うことがある
過度な抽象化が発生しやすい
学習コストが発生する
小規模案件ではオーバーエンジニアリングになりやすい

例えば、あるコンポーネントがMoleculesなのかOrganismsなのか判断に迷うケースは珍しくありません。

また、実際の開発現場では業務ロジックとの関係も考慮しなければならないため、Atomic Designだけでは整理しきれない場合があります。

以下に特徴を整理します。

観点	メリット	デメリット
再利用性	高い	過度な抽象化の可能性
保守性	向上しやすい	構造理解に時間がかかる
学習コスト	共通言語になる	初学者には難しい
小規模案件	やや過剰	導入コストが大きい
大規模案件	効果が高い	運用ルールが必要

コンピューターサイエンスでは、設計の複雑性は管理コストとして現れると考えられています。

そのため、Atomic Designも「使えるから使う」のではなく、「必要だから使う」という判断が重要です。

どのようなプロジェクトに向いているか

Atomic DesignはすべてのReactプロジェクトに最適なわけではありません。

実際にはプロジェクトの規模や性質によって適性が大きく異なります。

特に向いているのは、UIコンポーネントの再利用が多いプロジェクトです。

例えば以下のようなケースでは効果を発揮します。

デザインシステムを構築する場合
管理画面を複数開発する場合
長期運用を前提としたサービス
複数チームで開発する大規模案件
UIライブラリを作成する場合

これらのプロジェクトでは共通コンポーネントの数が増えるため、Atomic Designによる整理が有効になります。

反対に、以下のようなケースでは慎重な判断が必要です。

ランディングページ
小規模な業務システム
画面数が少ないサービス
短期間で終了するプロジェクト

このような案件では、Atomic Designを導入するためのコストがメリットを上回る可能性があります。

近年ではFeature-Sliced Designやドメイン駆動設計の考え方と組み合わせるケースも増えています。

例えば、機能単位のフォルダ構成を採用しながら、その内部でAtomic Designを利用する方法です。

features/
└── user-profile/
    └── ui/
        ├── atoms/
        ├── molecules/
        └── organisms/

このような構成にすると、機能ごとの責務分離とUIの再利用性を両立できます。

React開発において重要なのは、Atomic Designそのものを目的にしないことです。
あくまで保守性や再利用性を高めるための手段として活用するべきです。
プロジェクトの規模やチーム体制、将来的な運用方針を考慮した上で採用を判断することで、Atomic Designのメリットを最大限に引き出せるようになります。

実践的なReactフォルダ構成のおすすめ例

Reactのコンポーネント設計について理解が深まってくると、次に悩むのがフォルダ構成です。
どれほど優れたコンポーネント設計を採用していても、プロジェクト全体の構造が整理されていなければ保守性は低下します。

実際の開発現場では、「componentsフォルダにすべてを入れる」「機能ごとに分ける」「レイヤーごとに分ける」など、さまざまなアプローチが存在します。
しかし重要なのは、流行している構成をそのまま採用することではなく、プロジェクトの規模やチーム体制に適した構造を選択することです。

コンピューターサイエンスにおいても、優れたアーキテクチャには適材適所という考え方があります。
小規模システムに大規模向けアーキテクチャを導入すると複雑性が増し、逆に大規模システムへ簡易的な構成を適用すると保守性が低下します。

Reactのフォルダ構成も同様であり、規模に応じて適切な設計を選ぶことが重要です。

小規模プロジェクト向け構成

小規模プロジェクトでは、シンプルさを最優先に考えるべきです。

例えば、数ページ程度のWebアプリケーションや社内向けツールであれば、過度に複雑な構造はかえって生産性を低下させます。

そのような場合は、責務ごとに大まかに整理する程度で十分です。

src/
├── components/
├── pages/
├── hooks/
├── services/
├── styles/
└── utils/

この構成の特徴は分かりやすさです。

新しく参加した開発者でも、どこに何があるのか直感的に理解できます。
また、ファイル数が少ない段階では検索コストもそれほど発生しません。

小規模案件では以下の点を重視すると良いでしょう。

構造をシンプルに保つ
共通化を急ぎすぎない
フォルダ階層を深くしない
可読性を優先する

特にありがちなのが、将来的な拡張を意識しすぎて複雑な構造を導入してしまうケースです。

しかし、まだ存在しない問題を解決しようとすると、YAGNI（You Aren’t Gonna Need It）の原則に反することになります。

まずは理解しやすい構成から始めることが重要です。

中規模プロジェクト向け構成

機能数が増え、複数人での開発が始まると、小規模向け構成では限界が見え始めます。

例えば、componentsフォルダ内に数百のコンポーネントが存在するようになると、目的のファイルを探すだけでも時間がかかるようになります。

この段階では、機能単位の整理を取り入れることが有効です。

src/
├── features/
│   ├── auth/
│   ├── user/
│   └── product/
├── pages/
├── shared/
│   ├── ui/
│   └── hooks/
├── services/
└── utils/

この構成では、認証機能に関するコードはauth、商品管理はproductというように、機能ごとにコードを集約します。

その結果、ある機能を修正したい場合に関連ファイルを追跡しやすくなります。

中規模プロジェクトでは次のような課題が発生しやすくなります。

課題	原因	対策
コンポーネント増加	機能拡張	機能単位で整理
コード重複	共通化不足	shared導入
開発者間の認識差	ルール不足	命名規則統一
保守性低下	責務混在	レイヤー分離

この規模では、フォルダ構成そのものよりもルールの統一が重要になります。

例えば、API関連は必ずservicesへ配置する、共有コンポーネントはsharedへ配置する、といったルールを定義しておくことで、コードベース全体の一貫性を維持できます。

大規模プロジェクト向け構成

大規模プロジェクトでは、単純な機能分割だけでは管理が難しくなります。

数十人規模のチーム開発や長期間運用されるサービスでは、依存関係や責務の境界をより厳密に管理する必要があります。

このような場合に有効なのが、Feature-Sliced Designのようなレイヤー構造を採用した構成です。

src/
├── app/
├── pages/
├── widgets/
├── features/
├── entities/
└── shared/

この構成では、単なるフォルダ整理ではなくアーキテクチャレベルで責務を定義します。

例えばユーザー情報を扱う場合でも、データモデルはentities、ユーザー更新機能はfeatures、画面全体はpagesというように役割が明確になります。

大規模案件では以下の観点が重要です。

依存関係を制御する
ドメインごとに責務を整理する
機能追加時の影響範囲を限定する
チーム開発を前提とする

また、大規模開発ではオンボーディングも重要な課題になります。

新しい開発者が参加した際、フォルダ構成が論理的であれば学習コストを大幅に削減できます。

以下は規模別の特徴をまとめたものです。

規模	推奨構成	特徴
小規模	レイヤー分割	シンプルで理解しやすい
中規模	機能単位分割	保守性と拡張性の両立
大規模	FSDやレイヤード構成	責務管理を重視

Reactのフォルダ構成に絶対的な正解はありません。
しかし、プロジェクトの規模に応じて適切な構造を選択することで、保守性や開発効率を大幅に向上させることができます。
重要なのは最新の流行を追うことではなく、現在の課題と将来的な成長を見据えた構成を選ぶことです。
その視点を持つことで、長期的に扱いやすいReactプロジェクトを構築できるようになります。

設計パターンを選ぶ際の判断基準

Reactにはさまざまなコンポーネント設計パターンが存在します。
PresentationalとContainerパターン、Custom Hooksによるロジック分離、Atomic Design、Feature-Sliced Designなど、それぞれに特徴とメリットがあります。

しかし、重要なのは「どの設計パターンが最も優れているか」を考えることではありません。
実際のソフトウェア開発では、プロジェクトの状況やチームの特性によって最適解が変わります。

コンピューターサイエンスにおいても、アーキテクチャ設計はトレードオフの連続であると考えられています。
ある要素を重視すれば別の要素にコストが発生するため、目的に応じた選択が求められます。

Reactの設計パターン選定も同様です。
流行している手法をそのまま採用するのではなく、自分たちの開発環境に適した構成を選ぶことが重要になります。

ここでは、設計パターンを選ぶ際に特に重視すべき3つの判断基準について解説します。

チーム規模で選ぶ

設計パターンを選定する際に最初に考慮すべきなのがチーム規模です。

個人開発と10人規模のチーム開発では、求められる設計が大きく異なります。

個人開発では、コードの全体像を一人で把握できます。
そのため、多少構造が単純でも大きな問題にはなりません。

一方でチーム開発になると事情が変わります。

複数人が同じコードベースを扱う場合、設計の一貫性や責務の明確さが重要になります。
誰が見ても理解できる構造でなければ、レビューや機能追加に余計な時間がかかるようになります。

一般的な目安としては以下のように考えるとよいでしょう。

チーム規模	適した設計
1〜2人	シンプルなコンポーネント分割
3〜5人	Custom Hooksによる責務分離
5〜10人	機能単位の構成
10人以上	FSDなどのアーキテクチャ導入

特に開発メンバーが増えるほど、暗黙知に依存しない構造が重要になります。

例えば「この処理はどこに配置すべきか」という判断が開発者ごとに異なると、コードベース全体の統一感が失われます。

そのためチーム規模が大きくなるほど、設計ルールや責務分離を明確にしたパターンが有効になります。

また、将来的にメンバー増加が予想される場合は、現在の人数だけでなく将来の組織規模も考慮しておくべきです。

プロジェクト規模で選ぶ

設計パターン選定では、チーム規模だけでなくプロジェクト規模も重要な判断材料になります。

例えば、数ページのコーポレートサイトと数百画面を持つ業務システムでは必要な設計レベルが大きく異なります。

小規模なプロジェクトで過度に複雑な構造を導入すると、かえって開発効率が低下します。

一方で大規模なシステムをシンプルな構成だけで管理しようとすると、後々の保守コストが急激に増加します。

以下は規模別の考え方の一例です。

プロジェクト規模	推奨アプローチ	重視する要素
小規模	シンプルな構成	開発速度
中規模	機能単位分割	保守性
大規模	レイヤー構造導入	拡張性
超大規模	ドメイン単位設計	組織的管理

小規模案件では、ディレクトリ構造や設計ルールを厳格にしすぎないほうが効率的な場合があります。

逆に大規模案件では、最初から一定の設計指針を用意しておかないと、機能追加のたびに構造が崩れていきます。

特にReactは自由度が高いため、明確なルールがないと開発者ごとに実装スタイルがばらつきやすい傾向があります。

そのためプロジェクト規模が大きくなるほど、構造化された設計パターンの価値が高まります。

将来的な拡張性で選ぶ

設計パターンを選ぶ際に見落とされがちなのが、将来的な拡張性です。

現在の要件だけを基準に設計すると、数か月後や数年後に大きな負債となることがあります。

例えば、リリース当初は単純な管理画面だったとしても、その後の機能追加によって複雑なシステムへ成長するケースは珍しくありません。

そのため設計選定では、現在だけでなく将来の変化も考慮する必要があります。

特に以下のような観点は重要です。

機能追加の頻度
開発期間の長さ
チーム拡大の可能性
サービス成長の見込み
外部システム連携の増加

ただし、拡張性を意識しすぎることにも注意が必要です。

ソフトウェア設計には「将来必要になるかもしれない機能」を先回りして実装しすぎるアンチパターンがあります。

これは過剰設計と呼ばれ、複雑性だけが増加する原因になります。

設計選定において理想的なのは、現在の課題を解決しながら将来的な成長にも対応できるバランスを取ることです。

以下は代表的な設計パターンの特徴をまとめたものです。

パターン	学習コスト	保守性	拡張性
シンプル構成	低い	中程度	低い
Custom Hooks中心	中程度	高い	高い
Atomic Design	中程度	高い	中程度
Feature-Sliced Design	高い	非常に高い	非常に高い

React開発において最適な設計パターンは一つではありません。
チーム規模、プロジェクト規模、将来的な拡張性という3つの観点から総合的に判断することが重要です。
設計は目的ではなく、開発効率と保守性を高めるための手段です。
その本質を理解した上で選択することで、自分たちのプロジェクトに最適なコンポーネント設計を実現できるようになります。

Reactのコンポーネント設計は責務分離と継続的な改善が重要

ここまで、Reactのコンポーネント設計におけるさまざまな考え方や構成パターンについて解説してきました。
PresentationalとContainerパターン、Custom Hooksによるロジック分離、Atomic Design、Feature-Sliced Designなど、それぞれに異なる特徴があり、適した利用シーンが存在します。

しかし、最も重要なのは特定の設計パターンを採用することではありません。

React開発において本質的に重要なのは、責務を適切に分離することと、継続的に設計を改善していくことです。

実際の開発現場では、「この構成が唯一の正解」というケースはほとんどありません。
同じ要件であっても、チーム構成やプロジェクト規模、開発期間、運用方針によって最適解は変化します。

そのため、設計パターンを知識として覚えることよりも、なぜその設計が採用されているのかを理解することが重要です。

Reactのコンポーネント設計を考える際、まず意識したいのが責務の分離です。

責務分離とは、それぞれのコンポーネントやモジュールが明確な役割だけを持つ状態を指します。

例えば以下のような状態は理想的とはいえません。

UI描画とAPI通信が混在している
状態管理と表示処理が密結合している
ビジネスロジックが複数箇所へ分散している
共通化すべき処理が重複している

このような状態になると、機能追加や修正のたびに影響範囲の調査が必要となり、開発効率が低下します。

一方で責務が整理されているコードベースでは、修正対象を特定しやすくなります。

例えば次のような役割分担です。

レイヤー	主な責務
UIコンポーネント	画面表示
Custom Hooks	状態管理・ロジック
API層	データ取得
共通ライブラリ	汎用処理
ページコンポーネント	画面構成

このように責務を整理することで、各モジュールが独立して進化できるようになります。

コンピューターサイエンスでは、この考え方を関心の分離（Separation of Concerns）と呼びます。

長年にわたりソフトウェア工学で重視されてきた原則ですが、Reactのコンポーネント設計でも非常に重要な概念です。

また、React開発では設計を一度決めたら終わりではありません。

多くの開発者が陥りやすいのが、「最初から完璧な設計を作ろう」と考えてしまうことです。

しかし実際には、プロジェクト開始時点で将来のすべての要件を予測することは困難です。

例えば次のような変化は日常的に発生します。

新機能の追加
ビジネス要件の変更
チームメンバーの増加
API仕様の変更
パフォーマンス改善要求

こうした変化に対応するためには、設計そのものを継続的に改善していく姿勢が欠かせません。

ソフトウェア開発にはリファクタリングという考え方があります。

リファクタリングとは、外部仕様を変更せずに内部構造を改善する活動です。

Reactプロジェクトでも同様に、コードベースの成長に合わせてコンポーネント構成を見直すことが重要です。

例えば開発初期はシンプルな構成から始め、規模拡大に応じて機能単位へ整理していく方法があります。

初期
├─ components
├─ pages
└─ hooks
↓
成長後
├─ features
├─ entities
├─ shared
└─ pages

このように段階的に構造を進化させることで、必要以上に複雑な設計を避けながら保守性を維持できます。

また、設計の改善を行う際は、技術的な美しさだけを追求しないことも重要です。

開発現場では、しばしば「理想的なアーキテクチャ」と「実際の開発効率」の間でバランスを取る必要があります。

例えばFeature-Sliced Designは非常に優れた設計ですが、小規模な社内ツールに導入すると管理コストのほうが大きくなる場合があります。

反対に、数十人規模で開発する大規模サービスでは、単純なフォルダ構成だけでは限界があります。

つまり、設計はプロジェクトに適合して初めて価値を持つということです。

以下は各規模における設計方針の考え方です。

規模	優先事項	適した考え方
小規模	開発速度	シンプルな構成
中規模	保守性	責務分離
大規模	拡張性	アーキテクチャ管理
長期運用	継続改善	リファクタリング重視