アトミックデザインとは？5階層の分類基準とReactコンポーネント設計・3階層縮退

アトミックデザイン（Atomic Design）は、UIコンポーネントを「原子・分子・有機体・テンプレート・ページ」の5階層に分けて考えるUI設計の考え方です。2013年6月10日にBrad Frost氏がブログ記事「Atomic Web Design」で提唱し、2016年公開の同名書籍で体系化されました。ただし現場では「分子と有機体の線引きで議論が止まる」「もう古いのではないか」という声も根強くあります。この記事では原典の定義を逐語で確認したうえで、階層を分ける実務的な基準、Reactでのフォルダ構成、そして3階層に縮退させてよい条件までを整理します。

まとめ

アトミックデザインの5階層は、原典が「relatively（比較的）」という相対表現でしか定義していません。絶対的な線引きは最初から存在せず、チームで決めるべき設計判断です。

分子と有機体は「単体で意味を持つか」「業務ドメインの知識を含むか」で切ると運用が安定します。実装では5階層をそのままフォルダに写す必要はなく、画面数が多くドメインが分かれるプロダクトでは機能単位の構成に寄せたほうが破綻しません。

「古い」と言われるのは手法が陳腐化したからではありません。Brad Frost氏自身が「a mental model（思考の型）」と位置づけたものを、分類ルールとして承認フローに載せた結果です。画面数10未満の小規模サイトや寿命1年未満のキャンペーンサイトでは、分類コストが再利用の利得を上回るため採用を見送ってください。以下、原典の定義から順に見ていきます。

アトミックデザインの5階層と原典の定義に残る相対性

Brad Frostの原典による5階層の定義

アトミックデザインは化学の比喩を借りた設計モデルです。原子が結合して分子になり、分子が集まって有機体を構成するという構造を、UIの組み立てに当てはめています。原典であるオンライン書籍 Atomic Design（(c) 2016 Brad Frost）の第2章は、各階層を次のように位置づけています。

ここで注意したいのが、原典の英語定義です。分子は「relatively simple groups of UI elements functioning together as a unit」、有機体は「relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms」と書かれています。「relatively simple」「relatively complex」と書いてあるだけで、何と比べて単純なのか、どこから複雑なのかは示されていません。この相対性が、後述する分類論争の出発点になります。日本語で体系的に学ぶなら、五藤佑典氏の『Atomic Design ～堅牢で使いやすいUIを効率良く設計する』（技術評論社）が国内の定番書です。

分子と有機体を分ける実務上の判断基準

原典が絶対基準を置いていない以上、チームが基準を決めなければ議論は終わりません。運用で機能する切り分けは2つあります。

1つ目は「単体で画面に置いて意味が通るか」です。ラベルと入力欄とボタンを束ねた検索フォームは、それ単体で置いても何をする部品か分かりますが、扱う対象は決まっていません。これが分子です。一方、商品名・価格・サムネイル・カート追加ボタンを束ねた商品カードは、ECという文脈がなければ成立しません。これが有機体です。

2つ目は「業務ドメインの知識を含むか」という軸です。分子までは業務を知らないエンジニアでも作れるのに対し、有機体は「価格は税込表示が原則」「在庫切れ時はボタンを無効化する」といった業務ルールを内包します。この線で切ると、分子は共通ライブラリへ、有機体はプロダクト固有のディレクトリへ、という配置がそのまま決まります。

迷ったときは分子に置いてください。有機体から分子への降格は参照元が減るだけですが、分子から有機体への昇格は、共通部品として使われていた箇所すべての差し替えが発生します。

テンプレートとページの役割分担

テンプレートは原典で「the page’s underlying content structure rather than the page’s final content」に焦点を当てるものと説明されています。商品名が5文字のときも80文字のときも崩れないか、レビューが0件のときに空白が残らないか。こうした構造の妥当性を検証するのがテンプレートの役割です。

ページは「real representative content」を流し込んだ具体例です。原典はページを、デザインシステムそのものの有効性を検証する場と位置づけています。つまりページで崩れが見つかったら、直すべきはページではなく、下位の分子や有機体の設計です。この往復を設計に組み込まないと、ページ側で個別のCSS上書きが増え、階層構造が有名無実になります。

UIコンポーネントとコンポーネントベース開発が指すもの

UIコンポーネントの定義と粒度の考え方

コンポーネントとは、見た目（マークアップとスタイル）・振る舞い（イベント処理）・状態を1つのまとまりとして閉じ込めた、再利用可能な部品を指します。Reactでは関数がコンポーネントの単位になり、Web Components標準ではカスタム要素として定義します。この部品を積み上げて画面を組む進め方がコンポーネントベース開発（コンポーネント指向）で、アトミックデザインは、その部品をどの粒度で切るかに名前を与えたものです。

粒度の目安として、本記事ではpropsの数を10個までとする運用ルールを推奨します。propsが10個を超えたコンポーネントは、複数の関心事を1つに詰め込んでいる可能性が高くなるためです。バリエーションを増やしたくなったら、propsを足す前に分割を検討してください。

コンポーネント指向で変更コストが変わる仕組み

ボタンの角丸を4pxから8pxに変える、という変更を考えてください。ページ単位でHTMLとCSSを書いていれば、ボタンを含む全ページを開いて修正し、修正漏れを目視で探すことになります。原子としてボタンを1ファイルに切り出していれば、変更は1ファイルで完結し、参照しているすべての画面に反映されます。

これがコンポーネントベース開発の最大のメリットです。代償は、部品を切り出す設計と、どの部品がどこで使われているかを追える仕組み（カタログ）の維持コストにあります。この差は画面数に比例して開くため、画面数が多く長期運用されるプロダクトほど効果が出て、小規模サイトでは投資が回収できません。採否の判断基準は後の章で具体的な条件として示します。

Reactプロジェクトのフォルダ構成とStorybookでの階層可視化

5階層をそのままフォルダ構成に写す場合

もっとも素直な構成は、階層名をそのままディレクトリ名にする方法です。学習コストが低く、設計の意図がファイルツリーを見るだけで伝わります。

src/
  components/
    atoms/
      Button/
        Button.tsx
        Button.stories.tsx
      Input/
    molecules/
      SearchForm/
      LabeledInput/
    organisms/
      ProductCard/
      GlobalHeader/
    templates/
      ProductListTemplate/
  pages/
    products/index.tsx

この構成が有効なのは、プロダクトが単一ドメインで、コンポーネント総数が本記事の目安とする100を超えない範囲です。それを超えると、organisms配下が数十ディレクトリのフラットな列になり、目的のファイルを名前で探すことになります。

機能単位構成へ寄せる場合の分岐条件

ドメインが複数に分かれるプロダクトでは、階層名ではなく機能名を第一階層に置く構成が扱いやすくなります。レバテックが2025年7月10日に公開した記事（2025年12月24日更新）も、分類の議論に時間を費やしたチームがあったという問題意識から、機能中心のフォルダ構成と3層への簡略化を提案しています。

src/
  shared/ui/          共通の原子・分子（Button, Input, SearchForm）
  features/
    cart/
      ui/CartSummary.tsx
      model/useCart.ts
    product/
      ui/ProductCard.tsx
  app/routes/         ページ相当

切り替えの判断はこう決めてください。「このコンポーネントはどの機能に属するか」を即答できないファイルが増えてきたら階層名構成のまま、逆に「このボタンはカート専用だ」と機能で言い切れるファイルが大半を占めるなら機能単位構成へ寄せます。両方を中途半端に混在させる構成が、もっとも保守しづらくなります。

Storybookのtitleで階層を表現する書き方

フォルダ構成とは別に、カタログ上の並び順としてアトミックデザインの階層を表現できます。Storybook（2026年8月時点のnpm最新は10.5.6、2026年8月3日公開）では、Component Story Formatのtitleにスラッシュ区切りの文字列を渡すと、サイドバーが階層構造になります。

import type { Meta, StoryObj } from '@storybook/react-vite'
import { Button } from './Button'

const meta: Meta<typeof Button> = {
  title: 'Atoms/Button',
  component: Button,
}
export default meta

export const Primary: StoryObj<typeof Button> = {
  args: { variant: 'primary', children: '購入する' },
}

import元はフレームワークパッケージに合わせて置き換えてください。Next.jsなら@storybook/nextjs-viteです。@storybook/react-viteの型定義ファイルは先頭で@storybook/reactを再エクスポートしているため、MetaとStoryObjはどちらの経路でも同じ型を指します。

フォルダは機能単位、Storybookのtitleは階層単位、という使い分けができます。実装の都合とデザイナー向けの見え方を分離できるため、機能単位構成へ移行したあともカタログとしての階層は維持できるわけです。導入手順はStorybookの使い方｜インストールからストーリー作成・Next.js連携・テストまで実装手順で解説にまとめました。差分の目視確認を自動化したい場合はChromaticとは何か？Storybook連携も検討対象になります。

「アトミックデザインは古い」と言われる理由と現在の位置づけ

分類論争が起きる構造的な原因

「古い」という評価の大半は、手法そのものではなく運用の失敗を指しています。原典の第2章にはこう書かれています。

「Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time.」

直線的な工程ではなく、UIを「全体」と「部品の集合」として同時に捉えるための思考の型である、という宣言です。ところが実際の現場では、原子から順に作る工程表として運用され、レビューで「これは分子か有機体か」を決着させる会議が生まれます。定義が「relatively」でしかない以上、この会議は原理的に結論が出ません。手法が古いのではなく、思考の型を承認フローに変換したことが問題です。

3階層へ縮退させる条件

分類コストを下げる現実解が、MoleculesとTemplatesを省いた3階層への縮退です。Atoms（最小部品）、Organisms（機能単位の部品）、Pages（画面）だけに絞ります。

縮退してよいのは、次の条件を満たす場合です。デザイナーと実装者が同じリポジトリを見ており、コンポーネント総数が前述の目安である100未満で、テンプレートの構造検証をデザインツール側（Figmaのバリアント等）で済ませられるプロジェクト。この条件下では、中間階層を持つ利得より分類にかかる時間のほうが大きくなります。

逆に縮退すべきでないのは、複数プロダクトで共通ライブラリを配布している場合です。共通ライブラリに載せてよい部品（ドメイン非依存＝分子まで）とプロダクト固有の部品（有機体）の境界が、そのままパッケージ境界になります。ここで分子を潰すと、配布物にドメイン知識が混入し、利用側プロダクトが不要な業務ルールを引きずることになります。

採用すべきでないプロジェクトの条件

アトミックデザインを採用しないほうがよい場面は、はっきり指定できます。本記事では次の3条件のいずれかに当てはまるプロジェクトを対象外とします。

• 総画面数が10未満のコーポレートサイトやランディングページ
• 公開後の運用期間が1年未満と決まっているキャンペーンサイト
• デザイナー1名・実装者1名で完結し、口頭で合意が取れる規模のチーム

これらのケースでは導入しないでください。階層設計とレビューに費やす時間を回収できるだけの再利用が発生しないためです。画面数10未満の案件で「とりあえずアトミックデザインで」と決めると、部品の切り出しとレビューがそのまま納期を圧迫します。必要なのは階層構造ではなく、色・余白・フォントの定義を共有することです。

デザインシステムとDesign Tokensから見た階層の位置

トークンとコンポーネントの責務の分かれ目

アトミックデザインは部品の組み立て方を扱いますが、その部品が使う色や余白の値そのものは扱いません。ここを担うのがデザイントークンです。Design Tokens Community Group（W3Cのコミュニティグループ）が策定中の Design Tokens Format Module 2025.10（2026年7月30日版）は、トークンをJSONで表現する形式を定めています。値は$value、種別は$typeというキーで書きます。

{
  "color": {
    "brand-primary": {
      "$type": "color",
      "$value": {
        "colorSpace": "srgb",
        "components": [0, 0.4, 0.8]
      }
    }
  }
}

ただし同文書には「Do not attempt to implement this version of the specification.」という注意書きが明記されています。策定途上のドラフトであり、この版に準拠した実装を組むのは時期尚早です。現時点では、トークンの命名と値を一元管理するという考え方だけを取り入れ、フォーマットは各ツールの形式に合わせるのが現実的でしょう。責務の分け方としては、値の定義はトークン、値の組み合わせ方はアトミックデザインの階層、と整理してください。デザインシステム全体の構成要素はデザインシステムとは？構成要素・作り方とデザインガイドラインとの違いを解説で扱っています。

公開されているデザインシステムでの階層の扱い

公開されているデザインシステムを見ると、アトミックデザインの階層名がそのまま採用されているとは限りません。デジタル庁デザインシステムはGitHubでコンポーネントを公開しており、Storybook上でカタログを確認できます。入手手順はデジタル庁デザインシステムのコンポーネント入手｜GitHub 2リポジトリとStorybook手順にまとめました。自社で階層名を決める前に、公開システムがどの粒度でコンポーネントを切っているかを実物で確認しておくと、机上の分類議論を短縮できます。

導入で失敗する典型パターンと回避策

命名規約とフォルダの二重管理

よくある失敗は、ディレクトリで階層を表し、さらにファイル名にもAtomButtonのような接頭辞を付ける二重管理です。階層を変更するたびにファイル名の一括置換が発生し、Gitの履歴も追いにくくなります。階層の表現はフォルダかStorybookのtitleのどちらか一方に寄せ、ファイル名にはコンポーネント名だけを書いてください。

デザインツールと実装で階層がずれる問題

デザインツール側で「Button／Primary」と命名されている部品が、実装ではatoms/Buttonにvariant="primary"で表現されている、といったずれは起きます。デザインツールはバリアント単位で見た目を並べ、実装はprops単位でロジックを束ねるため、分割の単位が構造的に一致しないからです。

問題は、ずれそのものではなく、どちらを正とするかを決めていないことにあります。推奨する運用は、命名の正をデザインツール側に置き、実装のフォルダ構造は実装都合で決めてよいと明示することです。そのうえで、Storybookのtitleをデザインツールの命名に合わせます。デザイナーはカタログ上の名前で会話でき、実装者はディレクトリを自由に再編できます。両者を1対1で一致させようとする運用は、片方を変えるたびにもう片方の変更を強制するため、長続きしません。

よくある質問

「アトミック」という言葉は何に由来しますか？

化学の原子（atom）に由来します。物質が原子から分子、さらに複雑な構造へと組み上がるという化学の階層を、UIの組み立てに当てはめた比喩です。Brad Frost氏が2013年6月10日のブログ記事「Atomic Web Design」で用いた命名で、Atoms・Molecules・Organisms という並びも化学の用語をそのまま踏襲しています。なお、原子力や物理学の原子論とは関係ありません。データベースのトランザクションで使う「アトミック（不可分）」とも別の概念です。

Atomic Designを学ぶための公式資料や書籍は何ですか？

一次資料はBrad Frost氏のオンライン書籍 Atomic Design です。atomicdesign.bradfrost.com で全章が無料公開されており、(c) 2016 の表記があります。各階層の定義や、思考の型としての位置づけはこの第2章に書かれています。日本語で読むなら、五藤佑典氏の『Atomic Design ～堅牢で使いやすいUIを効率良く設計する』（技術評論社、2018年4月25日発売、A5判320ページ、ISBN 978-4-7741-9705-0）が定番です。実装寄りの内容を含むため、Reactでの適用を検討している場合はこちらが参考になります。

VueやAngularでもアトミックデザインは使えますか？

使えます。アトミックデザインはコンポーネントの粒度を決める考え方であり、特定のフレームワークに依存しません。Vueの単一ファイルコンポーネント、AngularのComponent、Svelteのコンポーネント、Web Componentsのカスタム要素、いずれでも同じ階層設計を適用できます。原典が提唱された2013年時点ではReactは公開直後であり、そもそも特定フレームワークを前提にしていません。Storybookも主要フレームワークに対応しているため、カタログ運用の方法も共通です。

アトミックデザインとコンポーネントライブラリの違いは何ですか？

コンポーネントライブラリは実体（コードとして配布される部品の集合）で、アトミックデザインはその部品をどう切り分けるかの設計指針です。Material UIやChakra UIといった既製ライブラリを使う場合、原子にあたる部品はライブラリ側が提供済みなので、自社で設計するのは分子より上の層になります。既製ライブラリを採用しているのに原子から自作すると、二重管理になり更新のたびに差分が発生します。導入時はまず、ライブラリがどの階層まで供給しているかを線引きしてください。

稼働中のプロジェクトに後からアトミックデザインを導入できますか？

できますが、既存コンポーネントを一括で階層へ振り分ける進め方は避けてください。動いているUIを分類し直す作業は、機能追加を止めたまま数週間を消費し、途中で放棄されると階層あり・なしのファイルが混在した状態が残ります。現実的なのは、新規に作る部品からルールを適用し、既存部品は改修が発生したタイミングで移す方法です。まずStorybookに既存コンポーネントを登録して一覧化し、重複している部品を洗い出すところから始めると、移行の対象と優先順位が数字で見えます。

関連記事

• デザインシステムとは？構成要素・作り方とデザインガイドラインとの違いを解説
• Storybookの使い方｜インストールからストーリー作成・Next.js連携・テストまで実装手順で解説
• デジタル庁デザインシステムのコンポーネント入手｜GitHub 2リポジトリとStorybook手順
• Chromaticとは何か？Storybook連携で広がるUI開発の可能性