フレームワーク活用ガイドひとことで言うと#
UIを「原子（Atoms）→分子（Molecules）→有機体（Organisms）→テンプレート（Templates）→ページ（Pages）」の5階層で設計する方法論。化学の概念をデザインに応用し、小さなパーツから組み上げることで一貫性のあるUIを効率的に作れる。
押さえておきたい用語#
- Atoms（アトムズ）
- これ以上分解できないUIの最小単位のこと。ボタン、入力フィールド、ラベル、色、フォントなどが該当する。
- Molecules（モレキュルズ）
- 複数のAtomsを組み合わせた1つの機能を持つ小さなコンポーネントのこと。検索フォーム（入力＋ボタン＋ラベル）などが該当する。
- Organisms（オーガニズムズ）
- Moleculesを組み合わせた画面の中で独立したセクションを指す。ヘッダー、商品一覧、フッターなどが該当する。
- コンポーネント駆動開発（Component-Driven Development）
- 小さなUI部品から段階的に組み上げる開発手法である。アトミックデザインの考え方をコードに反映した実装アプローチ。
アトミックデザインの全体像#
こんな悩みに効く#
- 画面ごとにデザインがバラバラで統一感がない
- 同じようなボタンやフォームを毎回ゼロから作っている
- デザイナーとエンジニアで「この部品はどこまで共通？」の認識がずれる
基本の使い方#
これ以上分解できない最小のUI要素を洗い出す。
- ボタン、テキスト入力欄、ラベル、アイコン、色、フォント
- HTMLタグレベルで考えるとわかりやすい（
<button>,<input>,<label>） - 単体では意味を持たないが、すべてのUIの土台になる
まずはプロジェクトで使う色、フォント、アイコンセットを決めることから始める。
Atomsを組み合わせて1つの機能を持つ小さなコンポーネントを作る。
- 検索フォーム＝テキスト入力（Atom）＋ボタン（Atom）＋ラベル（Atom）
- カード＝画像（Atom）＋タイトル（Atom）＋説明文（Atom）
- ポイントは**「1つのこと」をするコンポーネント**であること
「この分子は何をするものか？」を一言で説明できなければ、分割が足りない。
有機体: 分子を組み合わせた、画面の中で独立したセクション。ヘッダー、フッター、商品一覧、サイドバーなど。
テンプレート: 有機体を配置した画面のワイヤーフレーム。実際のコンテンツはまだ入っていない。レイアウトの骨格を定義する。
ページ: テンプレートに実際のコンテンツ（写真、テキスト）を流し込んだもの。本番に最も近い状態で、エッジケース（長い文章、画像なし等）の検証もここで行う。
具体例#
状況: 月間売上3,000万円のアパレルEC。商品ページのデザインが担当者ごとにバラバラで、60画面中にボタンのスタイルが7種類、フォントサイズが15パターン存在。リデザインプロジェクトが始動。
Atoms: プライスタグ（¥表記）、星アイコン、「カートに入れる」ボタン、商品画像、テキスト（商品名、説明文）
Molecules:
- 評価コンポーネント＝星アイコン×5 ＋ レビュー数テキスト
- 価格表示＝定価（取り消し線）＋ セール価格 ＋ 割引率バッジ
Organisms:
- 商品詳細セクション＝商品画像ギャラリー＋商品名＋価格表示＋評価＋カートボタン＋説明文
- おすすめ商品セクション＝セクションタイトル＋商品カード×4
Template / Page: 実データ（「ワイヤレスイヤホン XYZ」¥12,800、★4.2、レビュー328件）を流し込んで検証
| 指標 | 導入前 | 導入6ヶ月後 |
|---|---|---|
| ボタンスタイル数 | 7種類 | 3種類 |
| 新画面のデザイン期間 | 5日 | 2日 |
| UI不一致のバグ報告 | 月18件 | 月2件 |
アトミックデザインの5階層で整理したことで、「カートボタンのデザインを変えたい」→Atomを1つ修正するだけで全60画面に反映される体制になった。
状況: 従業員150名のBtoB SaaS企業。デザイナー4名がそれぞれ独自にコンポーネントを作成しており、Figmaファイル内に「ほぼ同じだが微妙に違う」コンポーネントが200個以上存在。
取り組み:
- 2日間のワークショップで全コンポーネントを棚卸し
- Atoms: 32個（色16色、フォント5段階、アイコン48個等）
- Molecules: 18個（検索バー、カード、バッジ等）
- Organisms: 12個（ヘッダー、サイドバー、データテーブル等）
| 指標 | 整理前 | 整理後 |
|---|---|---|
| コンポーネント総数 | 200個超 | 62個 |
| 新機能のデザイン期間 | 2週間 | 1週間 |
| デザインレビュー指摘数 | 平均8件 | 平均2件 |
200個を62個に統合した過程で、チーム全体の「コンポーネントとは何か」の共通認識が揃ったことが最大の収穫だった。開発速度は2倍に向上し、デザインレビューの指摘も平均8件→2件に減少した。
状況: 創業8ヶ月のヘルステックスタートアップ。エンジニア3名・デザイナー1名。MVP開発を急ぐ中、最初からアトミックデザインの考え方でFigmaとReactのコンポーネントを設計。
最小限のAtoms定義:
- カラー: プライマリ、セカンダリ、エラー、成功の4色＋グレースケール5段階
- フォント: 見出し2段階＋本文＋キャプションの4サイズ
- スペーシング: 4px, 8px, 16px, 24px, 48pxの5段階
1年後の効果:
- 画面数が8→45に増えたが、コンポーネント数は32→48の微増で収まった
- 新メンバー（デザイナー2名追加）が初日からコンポーネントを使って戦力化
- 技術負債による大規模リファクタリングが不要
| 指標 | 1年後の実績 |
|---|---|
| 画面数の増加 | 8→45（5.6倍） |
| コンポーネント増加率 | 32→48（1.5倍に抑制） |
| 新メンバーの初アウトプットまで | 平均3日 |
画面数が5.6倍に増えたにもかかわらず、コンポーネント数は1.5倍に抑制。「スタートアップだから後でやる」ではなく、最小限のAtomsを最初に決めておくだけで、成長期の技術負債を大幅に抑制できた。
やりがちな失敗パターン#
- 階層の分類に時間をかけすぎる — 「これはMoleculeかOrganismか」の議論は不毛になりがち。完璧な分類より、チーム内で認識が揃っていればOK
- 最初から全パーツを定義しようとする — 必要になったタイミングで追加していく方が現実的。使わないコンポーネントを大量に作っても管理コストが増えるだけ
- デザインだけで完結してしまう — アトミックデザインの真価はコードのコンポーネント設計と連動してこそ発揮される。デザイナーとエンジニアで共通言語にする
- FigmaとコードでAtomの定義がずれる — デザイントークン（色・フォント・余白の値）をFigmaとコードで同期させないと、結局バラバラになる。デザイントークンの一元管理が必須
まとめ#
アトミックデザインは「小さいパーツから大きな画面を組み立てる」という、UIデザインの設計思想。すべてのUIを5つの階層で整理することで、一貫性・再利用性・保守性が飛躍的に向上する。デザインシステムを作るなら、まずこの考え方を土台にしよう。