Atomic Designを大規模システム開発へどう適用するか？

この記事は「ビギナーズ Advent Calendar 2025」の19日目の記事です。

初めに

モダンなフロントエンド開発現場では、UIコンポーネントとして画面の共通部品を構築・再利用します。規模の比較的大きな開発では、開発時にUIコンポーネント分割方針をあらかじめ検討をする必要があり、その方針としてAtomic Designを採用することがあります。Atomic Designは再利用性や保守性が高いといったメリットがある一方で、

• そのまま各開発プロジェクトへ適用することが難しい
• 開発規模が大きくなるほど運用が難しく感じる

といった声をよく聞きます。私自身も、大規模フロントエンド開発の現場でAtomic Designを適用する中で、同じような課題感を持ちました。
本記事では私がAtomic Designを適用した開発を経験する中で感じた課題感やその解決案をご紹介します。皆さんがUIコンポーネント設計を検討する際のご参考となれば幸いです。

なお、Atomic Designの定義は以下で確認できます。
https://bradfrost.com/blog/post/atomic-web-design/

Atomic Design実適用時の課題

大規模なフロントエンド開発を前提とした場合、Atomic Designをそのまま適用すると、主に次の2点が課題になると感じました。

1. MoleculesとOrganisms等、コンポーネント単位の境界が曖昧で、開発者や PM 間の認識がずれやすい
2. Atom / Molecules ディレクトリ内に複数機能のソースコードが混在し、複数人での編集時にヒューマンエラーが生じやすい

1の課題については、小規模なフロントエンド開発ではMoleculesとOrganismsを統合し一つのコンポーネント単位としたり、ページバリエーションも少ないのでTemplatesを省略したりと各コンポーネント単位の役割を明確化することで解決できますが、大規模開発では設計するコンポーネント数も多くページバリエーションも多様なため、小規模なフロントエンド開発と同様の解決策は取れないでしょう。

また2の課題についても、複数機能のAtomやMoleculesが同一ディレクトリに混在する状態では、担当チームが異なる場合に意図しない修正や削除が発生しやすくなります。特に大規模開発では複数チームが並行して開発を進めるため、このようなディレクトリ構成では変更の影響範囲が見えづらく、レビュー時の負担も増大します。さらに、機能追加時にどのディレクトリに配置すべきか判断に迷うケースも発生し、開発効率の低下につながります。

解決の方向性

これらの課題を解消するために、Atomic Designを次の2つの観点で「現場向けにカスタマイズ」する方向で解決案を検討しました。

• Molecules / Organismsを「組み立て部品」と「セクション」で区別
• ディレクトリ構成にドメイン境界の概念を導入する

Molecules / Organismsを「組み立て部品」と「セクション」で区別

まずはレイヤーごとの責務を、名前の付き方で区別します。

• Molecules：画面の「組み立て部品」として扱うコンポーネント
  • 例：テキストフィールド、検索ボックスなど
  • 「◯◯フィールド」「◯◯ボックス」といった“部品名”で呼べるもの
• Organisms：画面の「セクション」として扱うコンポーネント
  • 例：ユーザー検索セクション、プロフィール編集エリア、共通ヘッダー など
  • 「◯◯セクション」「◯◯エリア」「ヘッダー」といった“セクション名”で呼ばれるもの
    というように、「部品か」「セクションか」 という軸で定義します。

こうしておくことで、あるコンポーネントを実装する際に名前ベースで機械的に判断しやすくなり、
MoleculesとOrganismsの判断が難しくても「これは部品化してMoleculesに落とそう」といった会話がしやすくなり、Molecules / Organismsの認識を揃えやすくなるといった効果が期待できます。

ディレクトリ構成にドメイン境界の概念を導入する

次に、ディレクトリ構成に 機能（ドメイン）単位 や チーム単位 の境界を導入します。具体的には、

• まず機能や開発チームごとにディレクトリを切る
• その配下にAtomic Designのレイヤー（atoms / molecules / organisms）を配置する
• 共通利用する UI コンポーネントはcommonとして別ディレクトリにまとめる

という構成にします。これにより、

• 「どのチームがどの領域を担当しているか」がディレクトリから一目で分かる
• 変更の影響範囲をある程度ディレクトリ単位で限定できる

といったメリットがあります。

解決案

上記の方向性を踏まえた解決案を整理すると、次の3点になります。

1. Molecules / Organismsを「組み立て部品」と「セクション」で区別しコンポーネントを整理
2. 機能や開発チームごとにディレクトリを分割した上で、その配下にコンポーネント単位のディレクトリを作成
3. 複数機能・複数チームで共通利用するコンポーネントは、共通コンポーネントとして別途ディレクトリ（common）を用意

これを反映したディレクトリ構成例は以下のとおりです。

src/
├── components/
│   ├── common/              # 全機能で共通利用するコンポーネント
│   │   ├── atoms/
│   │   │   ├── Button/
│   │   │   ├── Input/
│   │   │   └── Label/
│   │   └── molecules/
│   │       ├── FormField/
│   │       └── SearchBox/
│   │
│   ├── features/            # 機能ごとのコンポーネント
│   │   ├── user/           # ユーザー管理機能
│   │   │   ├── atoms/
│   │   │   │   └── UserStatusBadge/
│   │   │   ├── molecules/
│   │   │   │   └── UserCard/
│   │   │   └── organisms/
│   │   │       ├── UserList/
│   │   │       └── UserEditForm/
│   │   │
│   │   └── product/        # 商品管理機能
│   │       ├── atoms/
│   │       │   └── PriceLabel/
│   │       ├── molecules/
│   │       │   └── ProductCard/
│   │       └── organisms/
│   │           ├── ProductList/
│   │           └── ProductEditForm/
│   │
│   └── templates/
│       ├── UserPageTemplate/
│       └── ProductPageTemplate/
│

このディレクトリ構成では、ボタンや入力フィールドなどの汎用的なUIパーツはcommon配下に配置し、各機能固有のコンポーネントはfeatures配下の各機能ディレクトリに配置します。

まとめ

本記事では、Atomic Designを実適用する際の課題を整理し、その改善案について検討してみました。Atomic Designの実適用におけるベストプラクティスといった話題は、数多く議論がなされてきた内容かと思いますが、その結論はいまだ出ていないと考えています。ぜひ、みなさんの開発環境・チーム構成・運用ルールに照らし合わせて、「自分たちにフィットする設計・ディレクトリ構成とは何か」を考えてみてください。