AI時代のAtomic Design #PERSOL CAREER Advent Calendar2025

技術 デザイナー Atomic Design 新規サービス開発統括部 Developer＆Designer Advent Calendar 2025 アドベントカレンダー

はじめに

今年のDeveloper＆Designer Advent Calendar 2025の4日目を担当する、エンジニアの青木です。

この記事では、Atomic Designに基づくコンポーネント管理のベストプラクティスについて、AI活用の観点も交えて調査した結果を紹介します。

0. Atomic Designとは？

Atomic Designとは、WebデザイナーのBrad Frost氏が提唱した、UIを体系的に構築するための設計手法です。

「すべての物質は原子から構成され、原子が集まって分子となり、分子が集まってより複雑な有機体となる」という考え方に基づき、UIを以下の5つの階層に分けて設計・構築します。

5つの階層

  1. Atoms (原子)
    UIを構成する最小単位。これ以上分解できない要素を指します。
    • 例：ボタン、ラベル、テキスト入力欄、アイコン
  2. Molecules (分子)
    複数の「原子」が組み合わさって、1つの機能的な単位となったもの。
    • 例：「ラベル（原子）」＋「入力欄（原子）」＋「ボタン（原子）」＝ 検索フォーム（分子）
  3. Organisms (有機体)
    「分子」や「原子」が組み合わさった、より複雑で独立したUIセクション。
    • 例：「ロゴ（原子）」＋「検索フォーム（分子）」＋「ナビゲーション（分子）」＝ ヘッダー（有機体）
  4. Templates (テンプレート)
    ページのレイアウト構造を示すワイヤーフレーム。コンポーネントがどのように配置されるかを示す「骨格」です。具体的なコンテンツ（テキストや画像）はまだ入っていません。
  5. Pages (ページ)
    「テンプレート」に実際のテキストや画像などの具体的なコンテンツを流し込んだ、ユーザーが最終的に目にする完成形のページ。
なぜ使うのか？

この手法の目的は、UIコンポーネントの再利用性と一貫性を高め、デザイナーとエンジニアが共通の認識（共通言語）を持って開発を進められるようになることです。

たとえば、ボタン（Atoms）のデザインを変更すれば、それが使われている全ての「Molecules」や「Organisms」に自動的に反映されます。これにより、デザインシステムを効率的に管理・保守できるようになります。

1. Atomic Designの流行：なぜ支持されたのか？

2010年代中盤、ReactやVueといったコンポーネントベースのUI開発が主流になる中で、Atomic Designは画期的な設計思想として急速に広まりました。その理由は、UI開発が抱えていた課題に対する明確な解決策を示したからです。

  • 再利用性と一貫性の担保: ボタンやフォーム部品といった最小単位（Atoms）から組み上げていくことで、UIコンポーネントの再利用が促進され、サイト全体でデザインの一貫性を保ちやすくなり、開発効率も向上しました。
  • デザイナーとエンジニアの共通言語: 「Atoms」「Molecules」「Organisms」という明確な階層と命名規則は、デザイナーとエンジニアがUIの構成について議論するための共通言語となりました。これにより、デザインシステムを構築する際のコミュニケーションが円滑になりました。
  • 体系的な設計手法の必要性: フロントエンド開発において、体系的で予測可能なルールに基づいてコンポーネントを管理したいという要求に対し、その解としてAtomic Designが採用されました。

2. 現場での実践：階層構造の適用

この思想に基づき、開発現場ではUIコンポーネントのディレクトリ構造をAtomic Designの5階層にマッピングする、という実践が行われました。

/components
├── /atoms
│   ├── Button.tsx
│   └── Input.tsx
├── /molecules
│   └── SearchForm.tsx
├── /organisms
│   └── Header.tsx
├── /templates
│   └── DefaultLayout.tsx
└── /pages
└── TopPage.tsx

このようなディレクトリ構造は、一見すると非常に整理されており、どこに何があるべきかが明確であるように思われました。コンポーネントの粒度を意識する文化をチームに根付かせる上で、このアプローチは一定の効果がありました。

3. 実践から見えてきた課題：「分子か？有機体か？」

しかし、5階層モデルを実際のプロジェクトに適用していく中で、多くのチームが課題に直面しました。

  • 分類の曖昧さと認知コスト: 最も大きな課題は、「このコンポーネントはどの階層に属するのか？」という分類の曖昧さです。
    • あるコンポーネントが文脈によってMoleculeにもOrganismにもなり得るため議論が発生。「分類」そのものが目的化し、開発のボトルネックになることがありました。
    • 結果として、「とりあえずMoleculesに入れておく」といった運用になり、もともとのルールが形骸化するケースもありました。
  • ディレクトリの見通しの悪化: プロジェクトが大規模化するにつれ、AtomsやMoleculesディレクトリが肥大化。特定の機能に関連するコンポーネントが階層ごとにバラバラに配置されるため、関連するファイルを一覧できず、修正時の影響範囲の調査が困難になりました。
  • コンポーネントの依存関係とのミスマッチ: 本来Atomsは単体で成立するべきですが、実際にはアプリケーションの状態（State）や文脈（Context）に依存するケースも多く、ルールが実態とそぐわなくなりました。
  • 命名規則への理解度のばらつき: AtomsやMoleculesという化学の比喩は、設計思想を理解する上では有用ですが、必ずしもすべてのチームメンバーにとって直感的ではありませんでした。

4. 現状のベストプラクティス：思想の継承と現実的な分類

これらの課題を経て、現場では、Atomic Designのルールからは脱却しつつも、その思想は継承し、より実用的な手法が模索されるようになりました。

  • 思想と構造の分離: 「小さな部品から大きなものを作る」という思想は維持しつつも、それをそのままディレクトリ構造に反映させることは止める。
  • 役割や関心事による分類への移行: コンポーネントの粒度ではなく、コンポーネントの役割や関心事で分類する。
    • PresentationalとContainerの分離: UIの見た目に責務を持つコンポーネント（Presentational）と、ロジックや状態管理の責務を持つコンポーネント（Container）に分ける。
  • Feature-Sliced Design (FSD) の考え方: 機能（Feature）単位でコンポーネント、ロジック、APIリクエストなどをまとめて管理する設計思想。これにより、関心事が一箇所にまとまり、コードの独立性と保守性が高まる。

上記のような考え方を踏まえ、ディレクトリ構造は「粒度」だけではなく「役割」や「機能ドメイン」で分類するのが、多くの現場で得られた現実的なベストプラクティスです。

以下に具体的な事例を上げていきます。

 a. UIコンポーネントを3種類に分類

note.com

  • ui : プロジェクト固有のロジックを含まない、汎用的なコンポーネント
  • features : 特定の機能やドメインに閉じたコンポーネント
  • pages : ページ全体

b. UIコンポーネント以外のものも含めて分類

zenn.dev

  • common : 共通のスタイル定義など
  • components :
    • ui-elements : これまでの「Atoms」にあたるコンポーネント
    • ui-parts : これまでの「Molecules」にあたるコンポーネント
    • functional : 見た目を伴わない機能的なコンポーネント
    • layouts : レイアウトに関するコンポーネント
  • features : 機能ごとにUIコンポーネントや型定義、テストなど
  • pages : ページ全体

c. ドメインで分離、コンポーネントとページで分類

弊社のHiProの開発プロジェクトでは、まずトップレベルをサービス単位で分け、それぞれのサービス配下にcomponentsとpagesを配置し、Libraryにはサービス間で共通のコンポーネントを集約しています。

  • B2B/components, B2C/components
    • 各ドメイン(B2B, B2C)固有のビジネスロジックやコンテキストを持つコンポーネントを配置
  • B2B/pages, B2C/pages
    • コンポーネントを組み合わせて作られるページ
  • Library/components
    • 複数のドメインをまたいで利用される、汎用的で再利用性の高いコンポーネント

また、components配下のコンポーネントだけでなくpages配下のコンポーネントについてもStorybookで確認可能となっているのが特徴です。

個々のUIコンポーネントだけでなく、それらが組み合わさったページという単位でもStorybook化することで、以下のようなメリットが生まれます。

  • 最終的な見た目と挙動の確認: 実際のコンテンツが流し込まれた状態をStorybookで確認できるため、デザイナーやプロダクトマネージャーとの認識合わせがスムーズになる。
  • ページ単位での一貫性担保: 複数のページで共通のレイアウトやコンポーネントの組み合わせが正しく適用されているかを一覧で確認できる。
  • テストとレビューの効率化: ページ単位でのビジュアルリグレッションテストや、UIレビューが容易になる。

d. 共通コンポーネントとドメインで異なる分類

弊社のHRforecasterの開発プロジェクトでは、Atomic Designの思想を採用しつつ、ドメインの概念を組み合わせたハイブリッドモデルを採用しています。

まず、HiProと同様にドメインでディレクトリを分割しています。

  • 共通ディレクトリ: ClientとAgentで共通利用する部品
  • Client: 法人クライアント向け
  • Agent: エージェント向け

最大の特徴は、ディレクトリによってコンポーネントの分類ルールを変えている点です。

  • 共通ディレクトリ
    • components
      • atoms
      • molecules

ここではAtomic Designの分類を採用し、ドメインに依存しない汎用的なUI部品（ボタン、テキスト入力など）を配置しています。その「粒度の小ささ」や「機能の単純さ」で分類することが理にかなっているためです。

  • Client, Agent
    • components
      • organisms
      • templates
      • functions
      • layouts

ここではAtomic Designの分類とより機能的な分類とを併用し、共通ディレクトリのatomsやmoleculesを組み合わせて作る、各ドメイン固有の大きな部品（organisms）やページ構成（templates）を配置しています。
さらにロジック（functions）やレイアウト（layout）といった、粒度だけでは表現できない関心事を切り出して管理しています。

このハイブリッドモデルは、「汎用的な部品は粒度で管理し、ドメイン固有の部品は役割と粒度で管理する」という、Atomic Designとドメイン思想の良いとこ取りをした構成です。

5. AI活用という観点

今後の開発において、AIの能力を最大限に引き出す鍵となるのが「文脈（コンテキスト）」の提供です。

ドメインや役割で分割されたディレクトリ構造は、人間にとって分かりやすいだけでなく、AIにとっても「このコードがどの事業領域で、どういう意図で使われているか」を理解する強力なヒントとなります。
AI活用の観点から、この構造がもたらすメリットは以下の3点です。

文脈に即した精度の高いコード生成

AIにコード生成を依頼する際、ドメインが明確であればあるほど、出力の精度は向上します。

  • ドメイン駆動の場合: AI はディレクトリ構造からドメインを特定し、例えばAdminドメインの場合であれば「管理画面向きのデザインパターン」を踏襲して UI を生成できます。
  • 従来の分類の場合: AI は各ディレクトリ内の、例えばコンシューマ向けと管理画面向けが混在した部品群から推測しなければなりません。結果として、管理画面にコンシューマ用途のポップな部品を使うなど、文脈にそぐわない提案をする可能性があります。

ドメイン固有パターンの効率的な学習

AIが特定のドメインのルールや傾向を学習する際、関連ファイルがまとまっていることが重要です。

  • ドメイン駆動の場合: 例えばAgentディレクトリ配下に部品が配置されていれば、それらを「エージェント向けUIの教師データ群」として参照することができます。AIはそこから効率的にドメイン特有のパターンを学び取ることができます。
  • 従来の分類の場合: エージェント向けUIで使われている部品だけでなく、その他のUIへ向けた部品が含まれるため、AIがそれらの関係性や「エージェント向けのパターン」を見出すための学習コストが高くなります。

ビジネスルールを考慮した高度なリファクタリング提案

AIによるリファクタリング提案も、コードの字面だけでなく、ビジネス上の意図を汲んだものになります。

  • ドメイン駆動の場合: 例えば、ClientとAgent以下のコンポーネントで似たコードがあったとしても、AIは「ドメインが異なるため、将来的な変更サイクルの違いを考慮してあえて統合しない」といった判断が可能になります。
  • 従来の分類の場合: 文脈情報が不足しているため、「コードが似ているから共通化すべき」といった、保守性を損なう可能性のある提案をしてしまう恐れがあります。

まとめ

Atomic Designは、コンポーネントベース開発の黎明期において、UIを体系的に構築するための共通言語とルールを提供しました。しかし、その階層モデルをそのまま実装に適用すると、分類の曖昧さや見通しの悪さといった課題が生じることが明らかになりました。

現在では、4.であげたいずれの事例も、「再利用可能な部品を組み合わせてUIを構築する」という思想は継承しつつ、従来のatomsやmoleculesといった分類を簡略化するとともに、ドメインを取り入れたディレクトリ構成を採用しています。これにより、ビジネスの構造により即した軸でコンポーネントを整理し、持続可能なアーキテクチャを築くことが可能となります。

また、従来の粒度のみによる分類は、AIにとって「UIコンポーネントの文脈」を理解する上で妨げとなる場合もあります。AIに「どのコンポーネントが、どういう目的で使われるのか」を明確に伝えられるという点で、「ドメイン分割」は、AI活用観点からもメリットが大きいと考えられます。

まとめると、ディレクトリ構造は「粒度」のみではなく「役割」や「機能ドメイン」を取り入れて分類するのが、多くの現場で得られた現状のベストプラクティスと言えるでしょう。

*

青木 美穂子 Mihoko Aoki

新規サービス開発統括部 デザイン＆エンジニアリング支援部 新規エンジニアリンググループ

新卒でIT企業へ入社。コンシューマ開発、金融・保険系プロジェクトへのサービスデリバリーなどを経て、Webアプリケーションフロントエンド開発のリーダーとしてBtoBサービスの開発に携わる。

※2025年12月現在の情報です。