Atomic Designとは

はじめに

UIの設計において「このコンポーネントはどの粒度で分割すべきか」「再利用可能なUIパーツをどう体系化すべきか」といった課題に直面したことはないでしょうか。プロジェクトが大規模化するにつれて、UIコンポーネントの管理は複雑さを増し、一貫性のあるデザインを維持することが困難になります。

こうした問題を解決するために注目されているのが、Atomic DesignというUI設計手法です。Atomic Designは、化学における物質の構成（原子から分子、有機体へ）にヒントを得て、UIを5つの階層で体系的に構築する方法論を提供します。

本記事では、Atomic Designの基本概念から導入のメリット・デメリット、他手法との比較まで、技術やフレームワークに依存しない形で包括的に解説します。

本記事で学べること

Atomic Designの誕生背景と基本思想の理解
5つの階層構造（Atoms, Molecules, Organisms, Templates, Pages）の役割と設計基準
Atomic Design導入時のメリット・デメリットの把握
他のUI設計手法との比較と使い分け
プロジェクトへの導入判断と実践的なポイント

対象読者

UI設計に体系的なアプローチを取り入れたい方
デザインシステムの構築に興味がある開発者・デザイナー
コンポーネントの再利用性を高めたいチーム
Atomic Designの導入を検討している技術リーダー

Atomic Designの定義

Atomic Designは、2013年にWebデザイナー・開発者のBrad Frost氏が提唱したUI設計手法です。公式サイト（atomicdesign.bradfrost.com）では、以下のように定義されています。

Atomic design is a methodology for creating design systems. （Atomic Designは、デザインシステムを構築するための方法論です。）

この手法の核心は、UIを「分解可能な構成要素の階層」として捉え、最小単位のUI要素（Atoms）から段階的に組み上げて完成したページを構築するという考え方にあります。

Atomic Design誕生の背景

Atomic Designが生まれた2013年頃は、Webサイトやアプリケーションの大規模化・複雑化が急速に進んでいた時代です。当時、UI開発の現場では以下のような課題が顕在化していました。

課題	詳細
デザインの一貫性の欠如	プロジェクトが拡大するにつれて、同じ機能を持つUIでも見た目や挙動が異なるケースが増加
コンポーネントの重複開発	類似したUIパーツが複数箇所で独立して開発され、メンテナンスコストが増大
デザイナーと開発者の認識齟齬	UI要素の粒度や命名に共通言語がなく、コミュニケーションコストが発生
スケーラビリティの限界	既存のページ単位の設計では、新規ページ追加時に再利用できる資産が少ない

Brad Frost氏は、これらの課題を解決するために化学の概念を借用しました。物質が原子（Atom）から構成され、原子が結合して分子（Molecule）を形成し、さらに複雑な有機体（Organism）へと組み上がっていくように、UIも階層的に構築できるのではないかと考えたのです。

化学のアナロジーと設計思想

Atomic Designにおける「原子」「分子」「有機体」という命名は、単なるメタファー以上の意味を持ちます。化学では、同じ原子でも組み合わせ方次第で全く異なる物質が生まれます。UIも同様に、基本要素の組み合わせ方によって多様なインターフェースを構築できるという発想です。

graph LR
    subgraph 化学の世界
        H[水素原子] --> H2O[水分子]
        O[酸素原子] --> H2O
        H2O --> Cell[細胞]
    end
    
    subgraph UIの世界
        Button[ボタン] --> Form[フォーム]
        Input[入力欄] --> Form
        Form --> Header[ヘッダー]
    end

ただし、Brad Frost氏自身も述べているように、このアナロジーに厳密にこだわる必要はありません。重要なのは「UIを階層的に構築する」という思想であり、チームが理解しやすい独自の命名規則を採用することも推奨されています。

Atomic Designの5階層構造

Atomic Designでは、UIを以下の5つの階層に分類します。各階層の役割と設計基準を詳しく見ていきましょう。

graph TD
    A[Atoms<br/>最小単位のUI要素] --> B[Molecules<br/>Atomsの組み合わせ]
    B --> C[Organisms<br/>独立した機能を持つセクション]
    C --> D[Templates<br/>ページのレイアウト構造]
    D --> E[Pages<br/>実際のコンテンツを含む最終UI]
    
    style A fill:#e1f5fe
    style B fill:#b3e5fc
    style C fill:#81d4fa
    style D fill:#4fc3f7
    style E fill:#29b6f6

Atoms（原子）

Atomsは、Atomic Designにおける最も基本的な構成要素です。これ以上分解できない最小単位のUI要素を表します。

Atomsの特徴

単一責務: 1つのAtomは1つの機能のみを担う
独立性: 他のコンポーネントに依存しない
高い再利用性: アプリケーション全体で繰り返し使用される
デザイントークンの適用先: 色、サイズ、フォントなどの基本スタイルを定義

Atomsの具体例

カテゴリ	具体例
フォーム要素	ボタン、入力フィールド、チェックボックス、ラジオボタン、セレクトボックス
テキスト要素	見出し、ラベル、段落テキスト、リンク
メディア要素	画像、アイコン、アバター
その他	区切り線、ローディングインジケーター、バッジ

Atomsの設計指針

Atomsを設計する際は、以下のポイントを意識します。

汎用性を優先する: 特定のコンテキストに依存しない設計にする
バリエーションを考慮する: サイズ、色、状態（通常・ホバー・無効）などの差分を吸収できる設計にする
アクセシビリティを組み込む: キーボード操作、スクリーンリーダー対応を基本要件とする

Molecules（分子）

Moleculesは、複数のAtomsを組み合わせて構成される小さなコンポーネントです。単独では意味を成さないAtomsが、Moleculesとして組み合わさることで初めて具体的な機能を持ちます。

Moleculesの特徴

Atomsの組み合わせ: 2つ以上のAtomsで構成される
単一の機能: 1つのMoleculeは1つの具体的な機能を提供する
再利用可能: 異なるコンテキストでも利用できる汎用性を持つ

Moleculesの具体例

Molecule	構成するAtoms
検索フォーム	入力フィールド + 検索ボタン
ラベル付き入力欄	ラベル + 入力フィールド + エラーメッセージ
メディアオブジェクト	画像 + テキスト
ナビゲーションリンク	アイコン + リンクテキスト
価格表示	通貨記号 + 金額テキスト + 税表記

Moleculesの設計指針

シンプルに保つ: Moleculesは「1つのことを適切に行う」コンポーネントであるべき
機能的なまとまり: 論理的に関連するAtomsのみを組み合わせる
コンテキスト非依存: 特定のページやセクションに依存しない設計にする

Organisms（有機体）

Organismsは、AtomsやMoleculesを組み合わせて構成される、独立した機能を持つUIセクションです。Moleculesが「機能的なまとまり」であるのに対し、Organismsは「意味的なまとまり」を形成します。

Organismsの特徴

独立したUIセクション: 単独で意味を持ち、完結した機能を提供する
複雑な構造: 複数のMoleculesとAtomsで構成される
コンテキスト依存の開始: 特定のドメインや用途に関連した設計になりやすい

Organismsの具体例

Organism	構成要素
ヘッダー	ロゴ + ナビゲーション + 検索フォーム + ユーザーメニュー
フッター	ロゴ + リンクリスト + SNSアイコン + コピーライト
商品カード	商品画像 + 商品名 + 価格表示 + カートボタン
コメントセクション	コメントリスト + コメント投稿フォーム + ページネーション
サイドバー	検索フォーム + カテゴリリスト + 人気記事リスト

Organismsの設計指針

自己完結性: Organism単体で意味のある機能を提供できること
再利用性の検討: 複数ページで使われる可能性があるOrganismは汎用的に設計する
責務の明確化: 1つのOrganismが担う責務を明確に定義する

Templates（テンプレート）

Templatesは、Organismsを配置してページのレイアウト構造を定義する階層です。実際のコンテンツは含まず、UIの「骨格」を表現します。

Templatesの特徴

レイアウトの定義: コンテンツの配置場所を決定する
コンテンツ非依存: 具体的なデータや文言は含まない
ワイヤーフレーム的役割: ページ全体の構造を可視化する

Templatesの具体例

Template	配置するOrganisms
ホームページテンプレート	ヘッダー + ヒーローセクション + 商品一覧 + フッター
記事詳細テンプレート	ヘッダー + 記事本文エリア + サイドバー + 関連記事 + フッター
ダッシュボードテンプレート	サイドナビゲーション + メインコンテンツエリア + トップバー
ログインテンプレート	ヘッダー + ログインフォーム + フッター

Templatesの役割

Templatesは、デザイナーと開発者の間の「共通言語」として機能します。具体的なコンテンツを挿入する前の段階で、ページ構造についての合意形成を図ることができます。

graph TB
    subgraph Template["記事詳細テンプレート"]
        Header["ヘッダー<br/>(Organism)"]
        Main["メインエリア"]
        Sidebar["サイドバー<br/>(Organism)"]
        Footer["フッター<br/>(Organism)"]
        
        Header --> Main
        Main --> Footer
        Sidebar --> Footer
    end

Pages（ページ）

Pagesは、Templatesに実際のコンテンツを流し込んだ最終的なUIです。ユーザーが実際に目にする画面を表します。

Pagesの特徴

具体的なコンテンツ: 実際のテキスト、画像、データを含む
Templatesのインスタンス: 1つのTemplateから複数のPagesが生成される
最終的な検証場所: UI全体の整合性を確認する

TemplatesとPagesの関係

graph LR
    Template[記事詳細テンプレート] --> Page1["記事A<br/>（Page）"]
    Template --> Page2["記事B<br/>（Page）"]
    Template --> Page3["記事C<br/>（Page）"]

Pagesは、以下の観点での検証に使用されます。

レイアウトの妥当性: 実際のコンテンツを入れた際にレイアウトが崩れないか
エッジケースの確認: 極端に長いテキストや画像がない場合の表示
パフォーマンス: 実データを表示した際の読み込み速度

Atomic Designのメリット

Atomic Designを導入することで得られる主なメリットを解説します。

再利用性の向上

Atomic Designでは、Atomsを基盤として上位の階層を構築するため、コンポーネントの再利用性が自然と高まります。

従来の開発	Atomic Design
ページごとにUIを作成	Atomsを組み合わせてUIを構築
類似コンポーネントが乱立	単一ソースからの派生
修正時に複数箇所を変更	Atomレベルの修正が全体に反映

デザインの一貫性

Atomsレベルでデザイントークン（色、サイズ、フォントなど）を定義することで、アプリケーション全体でデザインの一貫性を保てます。

graph TD
    Token["デザイントークン<br/>（色、フォント、スペーシング）"]
    Token --> Atom1["ボタン"]
    Token --> Atom2["入力フィールド"]
    Token --> Atom3["見出し"]
    
    Atom1 --> Molecule["フォーム"]
    Atom2 --> Molecule
    Atom3 --> Molecule

チーム間のコミュニケーション改善

Atomic Designは、デザイナーと開発者の間の共通言語として機能します。「このMoleculeを使って」「Organismレベルで再設計が必要」といった会話が可能になり、コミュニケーションコストを削減できます。

スケーラビリティ

新しいページやセクションを追加する際、既存のAtoms、Molecules、Organismsを組み合わせることで効率的に開発できます。UIの資産が蓄積されるほど、開発速度は向上します。

テスト容易性

各階層が独立しているため、単体テストが書きやすくなります。Atomsは独立してテスト可能であり、上位階層はモックを使用したテストが容易です。

Atomic Designのデメリット

Atomic Designは万能ではありません。導入を検討する際には、以下のデメリットも考慮する必要があります。

初期学習コスト

Atomic Designの概念を理解し、適切にコンポーネントを分類できるようになるまでには時間がかかります。特に、MoleculesとOrganismsの境界は曖昧になりやすく、チーム内での認識統一が必要です。

過度な抽象化のリスク

再利用性を追求するあまり、過度に抽象化されたコンポーネントを作成してしまうことがあります。このようなコンポーネントは、設定項目が多くなりすぎて使いにくくなったり、特定のユースケースに対応できなくなったりします。

小規模プロジェクトでのオーバーヘッド

小規模なプロジェクトや短期間のプロジェクトでは、Atomic Designの階層構造がオーバーヘッドになる場合があります。ボタン1つを作るのにも、ディレクトリ構造やファイル分割を意識する必要が生じます。

厳密な分類の困難さ

実際のプロジェクトでは、あるコンポーネントがMoleculesなのかOrganismsなのか判断に迷うケースが頻繁に発生します。この曖昧さがチーム内での議論を引き起こし、開発速度を低下させる可能性があります。

階層の境界	判断が難しい例
Atoms vs Molecules	ラベル付きチェックボックスは1つのAtomか、2つのAtomsの組み合わせか
Molecules vs Organisms	カードコンポーネントはMoleculeか、Organismか
Organisms vs Templates	ページ固有のレイアウトをどこまでOrganismとして扱うか

他のUI設計手法との比較

Atomic Designは数あるUI設計手法の1つです。他の主要なアプローチと比較してみましょう。

BEM（Block Element Modifier）との比較

BEMは、CSSの命名規則に焦点を当てた手法です。

観点	Atomic Design	BEM
焦点	コンポーネントの階層構造	CSSクラスの命名規則
粒度	5階層で定義	Block、Element、Modifierの3要素
適用範囲	設計からコード全体	主にCSS/HTMLの構造化
併用	可能（相互補完的）	可能

BEMとAtomic Designは競合する手法ではなく、併用することでより堅牢なUI設計が可能になります。Atomic DesignでコンポーネントのThe階層を定義し、BEMで各コンポーネント内のCSS構造を整理するアプローチが有効です。

OOCSS（Object-Oriented CSS）との比較

OOCSSは、CSSをオブジェクト指向的に設計する手法です。

観点	Atomic Design	OOCSS
原則	階層的な構造化	構造とスキンの分離、コンテナとコンテンツの分離
再利用単位	コンポーネント（5階層）	CSSオブジェクト
抽象度	具体的な分類基準あり	原則ベース

SMACSS（Scalable and Modular Architecture for CSS）との比較

SMACSSは、CSSを5つのカテゴリに分類する手法です。

カテゴリ	SMACSS	Atomic Design対応
Base	要素のデフォルトスタイル	デザイントークン
Layout	ページのレイアウト	Templates
Module	再利用可能なパーツ	Atoms, Molecules, Organisms
State	状態を表すスタイル	各階層の状態管理
Theme	テーマによる上書き	デザイントークンの切り替え

手法選択のガイドライン

graph TD
    Start[プロジェクト特性の確認] --> Q1{デザインシステムを<br/>構築するか？}
    Q1 -->|Yes| AD[Atomic Design推奨]
    Q1 -->|No| Q2{CSS設計の<br/>改善が目的か？}
    Q2 -->|Yes| CSS[BEM/OOCSS/SMACSS]
    Q2 -->|No| Q3{小規模/短期<br/>プロジェクトか？}
    Q3 -->|Yes| Simple[シンプルな構成]
    Q3 -->|No| Hybrid[複合アプローチ検討]

Atomic Design導入時のポイント

Atomic Designをプロジェクトに導入する際の実践的なポイントを解説します。

導入すべきシーン

Atomic Designが効果を発揮するプロジェクトの特徴を挙げます。

長期運用が見込まれるプロジェクト: UIの資産化によるメリットが大きい
複数人での開発: 共通言語としてのAtomic Designが活きる
デザインシステム構築: Atomic Designはデザインシステムの基盤として最適
類似UIが多い: コンポーネントの再利用効果が高い
デザイナーと開発者の協業: 共通フレームワークとして機能

導入を慎重に検討すべきシーン

以下のケースでは、Atomic Designの導入効果が限定的になる可能性があります。

小規模・短期プロジェクト: 設計コストが開発コストを上回る
プロトタイプ開発: 素早い検証が優先される
チームがAtomic Designに不慣れ: 学習コストが障壁になる
UIの変更が頻繁: 階層構造がかえって足枷になる

段階的な導入アプローチ

Atomic Designを一度に完全導入するのではなく、段階的に取り入れることを推奨します。

graph LR
    Phase1["Phase 1<br/>Atomsの整理"] --> Phase2["Phase 2<br/>Moleculesの抽出"]
    Phase2 --> Phase3["Phase 3<br/>Organismsの定義"]
    Phase3 --> Phase4["Phase 4<br/>Templates/Pagesの統合"]

Phase 1: Atomsの整理

まずは既存のUIから基本要素（ボタン、入力フィールド、アイコンなど）を抽出し、Atomsとして整理します。この段階ではデザイントークンの定義も行います。

Phase 2: Moleculesの抽出

Atomsの組み合わせパターンを分析し、頻繁に使われる組み合わせをMoleculesとして切り出します。

Phase 3: Organismsの定義

ページ内の独立したセクション（ヘッダー、フッター、カード一覧など）をOrganismsとして定義します。

Phase 4: Templates/Pagesの統合

ページのレイアウトパターンを分析し、Templatesとして抽象化します。最終的にPagesとしてコンテンツを流し込む構成を完成させます。

チーム内でのルール策定

Atomic Designを効果的に運用するためには、チーム内での明確なルール策定が不可欠です。

策定すべきルール	内容例
分類基準	「Atomsは単一のHTML要素に対応」「Moleculesは2-3個のAtomsで構成」など
命名規則	ファイル名、コンポーネント名の付け方
ディレクトリ構成	各階層のファイル配置ルール
レビュー基準	新規コンポーネント追加時のレビュー観点
ドキュメント	各コンポーネントの用途と使用例の記載方法

よくある失敗パターンと対策

失敗パターン	対策
階層の境界で議論が長引く	判断基準を事前にドキュメント化し、迷ったら「より小さい階層」に分類する
過度に汎用的なコンポーネント	YAGNI原則を適用し、実際に必要になってから汎用化する
Atoms/Moleculesが増えすぎる	定期的な棚卸しを行い、未使用コンポーネントを削除する
デザインと実装の乖離	デザイナーもAtomic Designの概念を共有し、設計段階から階層を意識する

Atomic Designと現代のUI開発

コンポーネントベース開発との親和性

現代のUI開発では、React、Vue.js、Angular、Svelteなど、コンポーネントベースのライブラリ・フレームワークが主流です。これらとAtomic Designは非常に相性が良く、多くのプロジェクトで組み合わせて使用されています。

Atomic Designの各階層は、コンポーネントベース開発における以下の概念と対応します。

Atomic Design	コンポーネントベース開発
Atoms	Presentational Components（見た目のみ）
Molecules	小さなComposed Components
Organisms	Feature Components / Container Components
Templates	Layout Components
Pages	Route-level Components / Screen Components

デザインシステムとの関係

Atomic Designは、デザインシステム構築のための代表的な手法として広く認知されています。デザインシステムとは、UIの一貫性を保つための包括的なガイドラインとコンポーネントライブラリのことです。

graph TD
    DS["デザインシステム"]
    DS --> Principles["デザイン原則"]
    DS --> Token["デザイントークン"]
    DS --> AD["Atomic Design<br/>コンポーネントライブラリ"]
    DS --> Guide["使用ガイドライン"]
    
    AD --> Atoms
    AD --> Molecules
    AD --> Organisms
    AD --> Templates
    AD --> Pages

Atomic Designをデザインシステムの中核として採用することで、以下のメリットが得られます。

コンポーネントの構造化と分類が明確になる
デザイナーと開発者の共通言語として機能する
スタイルガイドの自動生成が容易になる（Storybookなどとの連携）

Storybookとの連携

Atomic Designは、Storybookのようなコンポーネントカタログツールとの相性も優れています。Atomic Designの各階層をStorybookのカテゴリとして整理することで、コンポーネントの発見性と管理性が向上します。

まとめ

Atomic Designは、UIを5つの階層（Atoms, Molecules, Organisms, Templates, Pages）で体系的に構築する設計手法です。化学のアナロジーを借りて、最小単位のUI要素から段階的にページを組み上げるアプローチを提供します。

Atomic Designの主なポイント

観点	内容
基本思想	UIを階層的に構築し、再利用性と一貫性を高める
メリット	再利用性向上、デザイン一貫性、チームコミュニケーション改善、スケーラビリティ
デメリット	学習コスト、過度な抽象化リスク、小規模プロジェクトでのオーバーヘッド
導入推奨シーン	長期運用、複数人開発、デザインシステム構築
導入非推奨シーン	小規模・短期プロジェクト、プロトタイプ開発

Atomic Designは万能な手法ではありませんが、適切なプロジェクトに導入することで、UI開発の効率性と品質を大きく向上させることができます。チームの状況やプロジェクトの特性を踏まえて、導入を検討してみてください。

参考リンク

Atomic Design by Brad Frost - Brad Frost氏による公式サイト。Atomic Designの概念と実践について詳しく解説されています。
Atomic Design Methodology | Brad Frost - Atomic Designの原点となった2013年のブログ記事。
Pattern Lab - Atomic Designに基づいたデザインシステム構築ツール。
Storybook - コンポーネントカタログツール。Atomic Designとの組み合わせに最適。

はじめに#

本記事で学べること#

対象読者#