なぜAtomic Designを採用するのか ― UIコンポーネント設計における判断基準
Published on 2026年2月27日
アーキテクチャはじめに
コンポーネント設計手法を選定するとき、「何を採用するか」よりも先に問うべきことがある。
何のための設計手法なのか。
本記事では、UIコンポーネントの設計手法として Atomic Design を採用した判断過程を整理する。FSD（Feature-Sliced Design）との比較を通じて、Atomic Design がUIの構造化において持つ利点を明確にする。
設計手法のスコープを定める
設計手法を評価する前に、まずスコープを限定する必要がある。
本プロジェクトにおける設計手法の対象は、フロントエンドアプリケーション全体ではなく、UIコンポーネントの構造化に限定される。ここでいうUIコンポーネントとは、以下の責務だけを持つものを指す。
| UIコンポーネントが担う責務 | 具体例 |
|---|---|
| UIの描画 | 見た目・構造の定義 |
| ユーザー操作の受け取り | クリック、入力、スクロール |
| イベントの通知 | onClick / onChange / onSubmit |
| UI状態の管理 | hover / focus / open / close |
逆に、以下はUIコンポーネントの責務ではない。
- API呼び出し・データ取得
- ルーティング制御
- グローバル状態管理
- 認証・権限・業務ルール
- ドメインモデルやアプリケーション固有の型への依存
UIは「どう見え、どう操作できるか」だけを責務とする。アプリケーションの都合は一切持ち込まない。
このスコープの限定が、設計手法の選定基準を決定づける。
FSD（Feature-Sliced Design）を採用しない理由
FSD はフロントエンドアプリケーション全体のスキャフォールディング手法であり、コード体系化のルール・規約・ツールチェーンを包括的に提供する。しかし、UIコンポーネントの構造化という目的には合致しない。
1. スコープが広すぎる
FSD は「フロントエンドアプリケーション全体のアーキテクチャ」を対象としている。
UIコンポーネントの設計に必要なのは「この部品はどの粒度か」「どこに置くか」という判断基準であり、アプリケーション全体の設計規約ではない。UIの構造化のためにアプリケーション全体のアーキテクチャを規定するのは、手段としてオーバーキルになる。
2. UIに他の責務が混在する
FSD の層構造には model や data といったUI以外の関心事が含まれる。
UIコンポーネントの本質的な責務は「データを受け取り、表示する」ことに尽きる。データ取得・加工・状態管理がUIと同じ設計レイヤーに入り込むと、コンポーネントの配置基準が曖昧になる。
FSD の層構造:
app → pages → widgets → features → entities → shared
↑
model / data が混在
「このコンポーネントは features に置くべきか、entities に置くべきか」という問いが、UIの粒度ではなくビジネスロジックの境界によって決まるようになる。UIの構造化という目的に対して、判断基準が複雑すぎる。
Atomic Design を選ぶ理由
Atomic Design は純粋にUIの構造と粒度だけを基準にコンポーネントを分類する。スコープがUIに限定されているからこそ、判断基準がシンプルで迷いが生まれにくい。
UIの責務に集中できる
各階層の判断基準が「見た目の粒度と再利用性」に限定される。データの扱いやビジネスロジックがコンポーネントの配置に影響しない。
Atomic Design における問いは常に以下の形をとる。
このコンポーネントは最小単位か、組み合わせか、プロダクト固有か。
ビジネスドメインの知識がなくても、UIとしての性質だけで配置が決まる。
責務の境界が明確
データ取得・フォーム管理・状態管理・ビジネスロジックは Atomic Design の外（アプリケーションレイヤー）で扱う。Atoms / Molecules は純粋なUIパーツとして保たれる。
┌─────────────────────────────────────────────────┐
│ アプリケーションレイヤー │
│ - データ取得・状態管理・ビジネスロジック │
└─────────────────────────────────────────────────┘
↓ props
┌─────────────────────────────────────────────────┐
│ UIレイヤー（Atomic Design） │
│ - propsを受け取って表示 │
│ - イベントをコールバックで通知 │
│ - UIのみの状態（hover / focus 等） │
└─────────────────────────────────────────────────┘
この分離により、UIコンポーネントは 「何を表示するか」は知らず、「どう表示するか」だけを知っている 状態を保てる。
共通言語としての明快さ
「Atom か Molecule か Organism か」というUI粒度の議論だけでコンポーネントの配置が決まる。チーム内で「このコンポーネントはどこに置くか」を議論するとき、判断軸が一つに限定されるため合意が得やすい。
各階層の判断基準
Atomic Design の各階層を、配置の判断基準に焦点を当てて整理する。
Atoms（原子）
UIを構成する最小単位のパーツ。自分が何に使われるかは知らない。
- これ以上分解すると意味を失うもの
- UIとしての姿があるなしは関係ない（provider 的なものも含む）
- 空間の配置を定義する structure も Atoms に属する
例: Button, Input, Label, Icon, Typography
Molecules（分子）
いくつかの Atoms を組み合わせて構成される。自分は何ができるかは知っているが、何に使われているかは知らない。
- Web UIの知識や機能を持つが、特定のプロダクトについての知識を持たない
- いくらかの複雑性を持つが、これ単体では成立しない
- ここまでは共通パーツとして使いまわせる
例: FormField, SearchBox, Card, MenuItem
Organisms（有機体）
特定のプロダクトについての知識を持つ。 ここが汎用と固有の境界線になる。
- それ単体でWebサイト内で存在できる
- 何をするものかが一目でわかる（プロダクト的な意味で）
- プロダクト間では使いまわせない
例: Header, Footer, Navigation, Form
Templates（テンプレート）
レイアウトの骨組み。中身は children として受け取る。
Pages（ページ）
Templates にページ固有の Organisms を配置した完成品。
境界の明確さ
最も重要な境界線は Molecules と Organisms の間 にある。
汎用（プロダクト非依存）
Atoms ─────────────────────────
Molecules ─────────────────────
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ← ここが境界
Organisms ─────────────────────
Templates ─────────────────────
Pages ─────────────────────────
固有（プロダクト依存）
Molecules までは「このコンポーネントは他のプロジェクトでも使えるか？」に Yes と答えられる。Organisms からは「このプロダクトでしか意味を持たない」コンポーネントになる。
依存関係のルール
Atomic Design のレイヤー間には明確な依存方向がある。
Pages → Templates → Organisms → Molecules → Atoms
- 上位は下位のみ参照可能
- 同階層間の参照は原則禁止（Molecules は例外的に Molecule を含むことがある）
- 逆方向の参照は禁止
この一方向の依存関係が、コンポーネントの独立性を保証する。Atoms の変更は Molecules に影響しうるが、Organisms の変更が Atoms に波及することはない。
Atomic Design の限界と運用上の注意
Atomic Design は万能ではない。UIの粒度だけを基準にするがゆえの限界もある。
グレーゾーンは必ず発生する
「これは Molecule か Organism か」の判断が曖昧なケースは避けられない。判断基準として有効なのは「プロダクト固有の知識を持つか」という問いだが、実際には程度の問題になることがある。
対処: 設計判断に迷ったら都度チームで認識を合わせる。「このコンポーネントは他のプロジェクトでも使えるか？」を問うことで、配置を決定する。
アプリケーション全体の設計は別途必要
Atomic Design はUIコンポーネントの構造化に特化している。データフロー、状態管理、APIとの接続は別の設計が必要になる。これは欠点ではなく、スコープの限定による意図的なトレードオフである。
まとめ
Atomic Design を採用する理由は、UIコンポーネントの構造化という目的に対して 判断基準がシンプル だからに尽きる。
| 観点 | Atomic Design | FSD |
|---|---|---|
| 対象スコープ | UIコンポーネント | アプリケーション全体 |
| 分類基準 | UIの粒度と再利用性 | ビジネスドメインの境界 |
| 判断の問い | 最小単位か、組み合わせか、固有か | どの feature に属するか |
| UIへの関心事の混在 | なし | model / data が混在しうる |
設計手法の選定において最も重要なのは、解決したい問題とスコープが一致しているか である。
UIの構造化が目的なら、UIの粒度だけで判断が完結する Atomic Design が最もシンプルな選択肢になる。